AI for process improvement: start from the event log, not the flowchart

Put five people in a room to map the returns process and you'll get a clean flowchart with seven boxes. Export the status history of last quarter's returns tickets and you may find nineteen distinct paths, three of which loop back to the start. (Illustrative, but anyone who has done it will recognise the shape.)

The second map is the true one. Process mining, as Celonis describes it, works from the "digital footprint" every step leaves in transactional systems, which Celonis calls "event log data", and shows "how your processes actually run – not how you think they do" (Celonis). You don't need a process-mining platform for a first version. Any system that records status changes with timestamps has the raw material: Jira, Linear, a helpdesk, an order system.

You need one row per event: a case ID (the ticket or order), the status or activity, and a timestamp. Export that, upload it to Claude with code execution on (ChatGPT's data analysis works too), and ask for the map:

The attached CSV has one row per status change: case_id, status, changed_at (UTC), changed_by.

Using code, not estimation:
1. Report the number of rows, distinct cases and the date range. List rows with missing or unparseable values, exclude them, and give the count.
2. Build the transition table: for each pair of consecutive statuses (from, to), the number of cases and the median and 90th-percentile time between them.
3. List the 10 most common end-to-end paths with their case counts and share of all cases.
4. Flag loops: cases that return to an earlier status, counted by the status they return to.
5. Count cases still open at the end of the data. Keep them out of duration figures, but report them separately.

Show the code. Don't describe the process in words until the tables are done.

The last line matters. Ask for the narrative first and the model will write the workshop version, then find numbers to fit it.

The setup below connects Claude to Jira or Linear directly. For a full status history across thousands of tickets, an export or a warehouse table is still safer than a chat connector: Claude caps tool results at roughly 150,000 characters (Anthropic, Building connectors), and the BigQuery server returns at most 3,000 rows (Google Cloud).

With the transition table in hand, the bottleneck tends to jump out, and it's rarely where people expected. Teams look for the slow task. The time usually goes in the wait before it: a ticket sits in "Awaiting approval" for two days so that someone can spend four minutes approving it.

That's the idea behind flow efficiency: active time as a share of elapsed time. Cycle time tells you how long the whole thing takes. The transition table tells you where it goes.

Using the transition table you built:
1. Classify each status as active (someone is working on it) or waiting (queued, blocked, awaiting someone). If a status is ambiguous, ask me. Don't guess.
2. For each waiting status, give total case-hours spent there in the period and its share of all elapsed time.
3. Rank the top three by total case-hours, not by median. A short wait every case hits can cost more than a long one few cases hit.
4. For the top one, compare the cases that waited longest with those that waited least: what differs (team, category, priority, day of week, assignee)? Report counts, not impressions.

Two checks before you believe the ranking. Are statuses used consistently? If one team moves tickets to "In progress" when they pick them up and another when triage finishes, the numbers mix two meanings. And are nights and weekends inside the wait times? An SLA measured in business hours won't reconcile with a wait measured in calendar hours. The "ask me, don't guess" line is there because otherwise the model will classify every status, confidently.

The prompts on this page depend on definitions: which statuses count as waiting, business or calendar hours, which tickets are in scope. Type them into every chat and they'll drift. Put them in Claude once.

1. Create a project per process you're improving, "Process: returns" say (Anthropic: what are projects?). Upload the status list and the latest export, and paste these instructions (illustrative):

This project analyses the [returns] process.
Case = [ticket / order]. Events = status changes in [Jira project KEY].
Waiting statuses: [Awaiting approval, Blocked, Queued]. All others active.
Durations in business hours: [Mon-Fri 09:00-17:30, timezone].
Exclude cases labelled [test] or [internal].
Calculate in code. Before any conclusion, state the row count, the date
range and what you excluded. Never classify a status not listed here;
ask me.

1. Switch on code execution in settings, so every number comes from a calculation rather than an estimate (Anthropic: create and edit files).

2. Connect the ticket system read-only. Add the server under Customize > Connectors (Anthropic: custom connectors). For Linear, use the read-only URL https://mcp.linear.app/mcp/readonly (Linear docs). The Atlassian Rovo MCP server searches Jira with JQL; it can also edit and transition issues, so switch those tools off in the chat's "Search and tools" menu. If event logs already sit in a warehouse, the BigQuery MCP server has an execute_sql_readonly tool, and Snowflake's managed server keeps SQL read-only by default.

3. Save the measurement plan as a skill. Once you've written the before-and-after plan below, put its definition and guardrail metrics in a Claude skill (Anthropic: how to create custom skills). Anyone who asks "did the change work?" then gets the same ruler.

4. Turn write tools off before Research. If you use Claude's Research to look up how other teams run a process, Anthropic warns that connector tools can run without approval there.

If your company runs ChatGPT, a ChatGPT project holds the same instructions and its data analysis runs the code; the prompts work unchanged.

Ask an assistant why approvals got slower and it will tell you, fluently, in one paragraph: approvers are overloaded. It might even be true. The trouble is that it's one story, and once a story is written down the team stops looking.

Anthropic's guidance for research tasks takes the opposite line. Its sample prompt asks Claude to "develop several competing hypotheses", to "track your confidence levels" as evidence comes in, and to "verify information across multiple sources" (Anthropic, Prompting best practices). Applied to a process problem:

Problem: median time in "Awaiting approval" rose from [X] to [Y] hours between [period 1] and [period 2].
Data: the attached event log, transition table, assignee list and ticket categories.

1. Give at least four competing explanations. At least one must be about measurement (a change in how statuses are used, a new ticket type, missing data) rather than about the process.
2. For each, say what we'd expect to see in the data if it were true, and what we'd expect if it were false.
3. Run the checks you can with this data, using code. Report what you found, with counts.
4. Rate each explanation: supported, contradicted or untested. Say what data would settle the untested ones.

Do not pick a winner before step 4.

The measurement hypothesis earns its place. A wait time that jumps the same week a new ticket category appears is often a change in what's being measured, not in how the work is done.

Then do the part the model can't: go and ask. Two conversations with approvers will test the surviving hypotheses faster than another query. The AI's job here is narrower than it looks. It makes sure you ask about more than one cause.

Most process improvements are declared rather than measured. Someone changes the approval rule, the next month looks better, and a slide says "cycle time down 30%". Maybe. Or maybe it was a quiet month.

Write the measurement plan before you change anything, and have the assistant hold you to it:

We plan to [change] on [date]. Write a measurement plan:
- the primary metric, with an exact definition: start event, end event, which cases are in and out, calendar or business hours
- a baseline period and a comparison period of equal length
- metrics that must not get worse (reopen rate, error rate, customer contacts)
- things that could move the metric without our change (season, volume, staffing, new categories)
- the result that would make us say it didn't work

Keep the definition fixed. If I later ask for results with a different definition, point out the change.

After the change, run the identical query on both periods. Four things to check before calling it a win:

1. Same definition. The query text should differ only in its dates.
2. Comparable populations. Similar volume and mix of categories in both periods. If the mix shifted, report by category.
3. Medians and tails. The median can improve while the 90th percentile gets worse, and the tail is where the complaints come from.
4. Guardrail metrics. Faster with more rework isn't better. Issue reopening rate is the usual one to watch.

The last line of the prompt does the quiet work. A definition that drifts between the before and after numbers can manufacture any improvement you like.

Three failure modes come up again and again.

• The wrong population. Cycle time calculated on closed tickets only flatters every process, because the slowest cases haven't closed yet. The model won't mention it unless asked.
• Valid SQL, wrong question. On realistic enterprise schemas, the best agent in the original Spider 2.0 paper solved 21.3% of tasks, against 91.2% on the older academic Spider 1.0 (Lei et al., 2024). Agents have improved since; joins, date columns and status mappings on your own schema are still where they slip.
• Long tool chains. In a 2026 study of 14 models, factual accuracy fell by about 42% as tool calls grew from 2 to 150 (Onweller et al., Cited but Not Verified). An analysis that pulls hundreds of tickets one call at a time gives an error plenty of chances to creep in.

A two-minute check

1. Compare the count. Does the number of cases match what your ticketing tool shows for the same filter?
2. Trace one case. Read a ticket's history in the source system and compare it with the model's transitions.
3. Ask what's out: "Which cases did you exclude, and why? How many are still open?"
4. Separate data from interpretation: "Which of your conclusions came from a calculation, and which are your interpretation?" The interpretation is where the first plausible story hides.
5. Re-run in a fresh chat. Anthropic notes that inconsistencies across repeated outputs "could indicate hallucinations" (Anthropic, Reduce hallucinations).

Count does step 4 for a whole answer. Connect it to Claude as a custom connector, ask it to audit the analysis, and each claim is labelled Citation, Assumption, Model knowledge or Hallucination, with the reasoning chain from the prompt through each query to the source. The canvas is also an analytics workspace that connects to your warehouse and runs SQL and Python, so a wrong filter can be fixed and re-run there. The general method is in how to check AI answers.

How can AI be used for process improvement?

Can AI do root cause analysis?

Do I need process mining software?

What data do I need to analyse a process with AI?