Ticket Replay: JSM process mining without the six-figure project

Every JSM ticket in your instance already carries a complete event log. Open any issue, append ?expand=changelog to the REST URL, and you get a chronological list of every status transition, assignment, field change and timestamp for that ticket's whole life [1]. A queue's worth of those is an event log in the textbook sense [2] — the same shape the enterprise process-mining platforms ingest. The audit you've been quoted seven figures for is, in its data layer, already in your ticket history.

The data layer for process mining is, in other words, already sitting in your JSM tenant. Jira just doesn't draw the picture — that's what a JSM-focused tool does. The phrase we use for the read of those tickets — pulling out paths, variants, bottlenecks, rework — is Ticket Replay, and the work is less procurement than the category has led you to believe.

Why "RFP a process mining tool" stalls

The serious enterprise platforms are real, and they are good. SAP Signavio, Apromore, iGrafx, ProcessMind, ARIS, and the rest of the category — all do exactly what they say [3]. They are also priced for organisations with eighteen-month adoption budgets. A published Forrester Total Economic Impact composite for the category-leading platform paid $1.26M in software alone in year one, scaling to $5.25M by year three across fourteen processes [4]. Entry-tier annual pricing typically lands around $150k; implementations run 8–18 months [5]. A 60-person JSM team will not get this past procurement; a 6,000-person enterprise often spends 24 months trying.

Meanwhile the data is sitting in JSM. Three patterns repeat in the conversations:

• The team knows the incident process is broken somewhere but can't say which step, in which queue, for which severity band.
• The change-advisory step keeps approving the same changes the same way; nobody can produce evidence of where the dwell actually concentrates.
• A request type called "Other" or "Generic" eats 30–40% of the queue, the rework rate is high, and nobody can decompose it because there's no view of what the variants inside it actually are.

These are not tooling questions. They are read-the-data questions. The seven-figure platform will answer them eventually. A JSM-focused read of the changelog will answer them this week.

The dashboard you've been quoted a million dollars for is already in your ticket history — one API call away.

What's actually in the changelog

A standard JSM workflow generates an event log without you doing anything. The REST endpoint /rest/api/3/issue/{KEY}?expand=changelog returns every field change since creation, each with a created timestamp and from / to values [1]. Filter histories[].items[] for field == "status" and you get the issue's status trace, for example: Open → Triage → In Progress → Waiting on Customer → In Progress → Resolved → Closed. That trace is the unit of analysis in process mining [2]. A queue's traces, taken together, form the event log.

The trace says nothing on its own. Three transformations turn it into something useful:

• Cluster traces by activity sequence. Identical sequences are the same variant. A queue of 400 incidents typically resolves into 5–50 distinct variants — not the five-step happy path your workflow diagram suggests [6].
• Build the directly-follows graph. For every pair of statuses (A, B) that appears back-to-back across the event log, record the count. The graph through those edges is your process map — the actual one, not the documented one [2].
• Annotate edges with dwell time. Each transition A → B carries a distribution of "how long did the issue sit in A before transitioning to B." Bottlenecks light up as edges with median dwell well above the queue's median.

None of this requires a seven-figure cross-system platform. The Jira REST API already exposes every transition; a JSM-focused tool that reads the changelog will plot all three artefacts for a single queue, on its own.

The four reads you can run by Friday

Four artefacts matter most. None of them takes longer to build than to interpret.

• Variant map. Top variants ranked by share of cases. Answers: "what share of this queue actually follows the path we documented?" If the top three cover under 50%, the type itself is a decision tree wearing a single label.
• Bottleneck heatmap. Median dwell time per edge in the directly-follows graph. Names the slow step by status pair, not by intuition.
• Rework graph. Every backward transition — re-opens, status reverts, re-routes. Concentration in one assignee group is usually a coaching problem; concentration on one transition is usually a workflow problem.
• Conformance check. For each variant, did the issue hit every mandatory step (verification, approval, change reference) before closure? Variants that skip steps quietly are the audit risk.

One queue, walked through

Take a typical mid-market Incident queue: 312 resolved tickets over six months. Run the four reads.

• Fourteen variants emerge. The top three cover 71% of cases — variant stability is okay.
• The long tail (29%) splits into a different story. Most of those are P2 incidents that took an approval detour through a CAB that wasn't actually required for that severity, and the detour added a median 23 hours of dwell.
• Rework rate sits at 9%, but 70% of the re-opens trace to a single assignee group — not a process problem, a coaching one.
• Conformance on the P3 path: 18% closed without severity classification being set. That's the audit gap.

The output is not "buy a tool." The output is: split the request type, drop the CAB step for P3, coach one group, add a closure guard on severity. None of those is a procurement question.

Ticket Replay as the on-ramp

The enterprise process mining platforms still earn their fees. They run across systems (JSM and the CMDB and the ERP and Slack), they handle event logs in the tens of millions, they ship conformance against modelled processes, they do prescriptive analytics. None of that is wasted spend at scale.

What's wasted is treating the entry-level read of one tool's own data as if it required the same investment. Ticket Replay is to the seven-figure platforms what FitSM is to ITIL: lighter, accessible to a single admin, built on the same primitives, and the right starting point. Run it on one queue, write the report, fix the four things it surfaces, repeat next quarter. If after a year your reads keep crossing system boundaries — JSM into the CMDB, into Confluence, into finance — that's when the seven-figure platform earns its quote. Most teams don't get there for years.

The data is already in your hands. Open one queue. See what you've got.