Quick answer: AI process mining produces automation candidates worth building only when it is run as a method rather than a dashboard. The method has three parts: confirm your event log can support the claim you want to make, separate real bottlenecks from artefacts of how the log was written, then push every surviving finding through a filter that sorts it into delete, fix procedurally, or automate. Most teams skip to the third part and automate findings that were never real.
This article is the method. If you already have tool output sitting in a tab you do not trust, start at the artefact test and work forward — you can apply the filter to your own findings this week.
What an event log has to contain before any finding is trustworthy
Process mining reconstructs what happened from records the business already writes. Four fields are mandatory. Without all four, you are not mining a process, you are plotting a table.
| Field | What it must be | What goes wrong without it |
|---|---|---|
| Case ID | A stable identifier for the thing moving through the process — invoice, shipment, ticket, order | Activities cannot be stitched into a path; every event looks independent |
| Activity | A name for the step that occurred | Steps collapse into one another and variant counts become meaningless |
| Timestamp | When the step occurred, not when it was recorded | Durations are fiction and ordering is unreliable |
| Resource | The person, team, queue, or system that acted | Handoffs are invisible, so rework loops cannot be attributed |
Three more fields are optional in theory and decisive in practice: the case start and end markers that let you say a case is finished rather than merely quiet, the exception or reason code that lets you distinguish a delay from a dispute, and the case attributes — vendor, region, customer tier, amount — that let you find out the process is really several processes wearing one name.
The most common data problem is not a missing field. It is a timestamp that means something other than what you assume. Before believing any duration in your tool, answer one question for each activity: is this timestamp written when the work happened, or when a batch job noticed the work happened? If a nightly job stamps a whole day's approvals at 02:00, every approval in your log takes a multiple of 24 hours, and the approval step will top your bottleneck chart forever.
The artefact test: is this a real bottleneck?
A bottleneck is a place where work waits for capacity or a decision. An artefact is a place where the log makes work appear to wait. They look identical on a chart. Four checks separate them, and each one takes minutes.
1. The clustering check. Plot the durations for the suspect step. Real waiting produces a spread — some cases fast, some slow, a long tail. Artefacts produce clusters: everything landing on the hour, the same handful of durations repeating, or a spike at exactly 24 hours. Clusters mean you are measuring a job schedule, not a queue.
2. The zero-duration check. Count the cases where the step takes zero or near-zero time. If a step is instant for most cases and hours for the rest, you may have two different events sharing one activity name — one written on entry, one written on completion. Split them before drawing conclusions.
3. The resource check. Look at who performed the step. If the resource is a service account, an integration user, or blank, the timestamp almost certainly reflects a system write rather than a human decision. That does not make the step unimportant, but it does mean the delay lives upstream of where the chart points.
4. The case-count check. Compare the number of cases entering the step with the number leaving it. A large gap usually means cases are ending elsewhere, being renamed, or being merged — not that the step is slow. Reconcile the counts before you optimise anything.
A finding that survives all four checks is describing something that actually happens to real work. Only those findings should reach the filter.
The four-gate filter: what to do with a finding that is real
Every surviving finding falls into exactly one of four outcomes. Run the gates in order and stop at the first one that answers.
Gate 1 — Does the step change any outcome?
Take the step and compare cases that went through it against cases that skipped it, or compare the state of the case before and after. If the outcome is the same either way, the step is not control. It is habit.
Approval layers are where this shows up most. A review that approves ninety-nine point something percent of what reaches it, with no visible change to the cases it touches, is adding latency and calling it governance. The right move is to delete it, or to set a threshold so it only sees the cases where the answer might be no.
Outcome: delete the step. Do not automate it. An agent that performs a pointless approval faster has made the process worse, because now nobody will ever question it again.
Gate 2 — Is the decision already written down?
If a human is applying a rule that exists in a policy document, a training deck, or a wiki page, you do not have a judgement problem. You have a routing problem that was never configured.
This is the gate most teams fail. They see analysts making a decision two hundred times a day, conclude that the decision is hard, and scope a model. Then they read the policy and discover the analysts are executing four if-statements from memory. A deterministic rule in the workflow tool solves it in an afternoon and never drifts.
Outcome: fix it procedurally. Configure the rule where the work lives. Revisit only if the exceptions to the rule turn out to be the actual volume.
Gate 3 — Is the decision reversible, and will you find out when it is wrong?
Now you are in genuine automation territory, and this gate decides whether it is safe. Two properties matter and both are required.
Reversible means a wrong answer costs a correction, not an incident. Reprioritising a queue is reversible. Releasing a payment is not.
Observable means the process produces a signal telling you the answer was wrong — a reopen, a reversal, a complaint, a manual override, a downstream failure. If a wrong answer looks exactly like a right answer forever, you cannot run the automation safely at any confidence level, because you will never learn.
| Reversible | Observable | What to build |
|---|---|---|
| Yes | Yes | Agent decides, humans audit a sample |
| Yes | No | Build the feedback signal first, then automate |
| No | Yes | Agent recommends, human approves, evidence shown |
| No | No | Leave it with a human and improve the information they get |
Outcome: automate at the level the table allows. The failure mode here is picking a lane by ambition rather than by the two properties.
Gate 4 — Does the volume justify the build?
A finding can be real, unwritten, reversible, and observable, and still not be worth automating. The rough test: multiply the number of cases per month by the minutes of human attention each one takes, and compare against the effort to build and maintain the automation for a year — including the cost of someone reviewing its output.
Findings that fail this gate are not dead. They are the second cohort. Rank them and revisit when volume grows or when the same capability serves several of them at once.
Outcome: queue it, and say so explicitly. An unranked backlog of "good ideas we did not do" quietly becomes an argument that process mining did not work.
Where the filter usually lands
The genuinely automatable set is smaller than the tool's opportunity list suggests, and considerably more likely to work. A meaningful share of findings die at Gate 1, because organisations accumulate review steps and never remove them. Another large share stop at Gate 2 — rules that exist but are not configured anywhere the system can see.
That is the honest value of the method. It is not that process mining finds more automation. It is that it stops you building the wrong three things first. Gate 2 findings are usually RPA or plain configuration, which is the distinction our AI vs RPA framework draws; only Gate 3 findings need a model. And when you price the result, count delay removed and exception volume prevented rather than labour saved alone — the argument in our AI ROI calculation framework.
Where the technique pays off first
Mine the workflows with high exception volume and contested ownership first, because those are the places nobody can describe accurately from memory.
Finance and back-office. Invoice exception clusters, duplicate-review loops, and coding decisions that vary by analyst. Gate 2 catches most coding rules; Gate 3 usually lands on exception triage.
Warehouse operations. Replenishment exceptions, slotting decisions, and planner-to-floor handoffs. Worth mining before committing to robotics, because physical throughput is often downstream of a weak decision layer — see AI warehouse automation.
Logistics and fleet. Delayed pickups, appointment misses, detention risk, and rerouting calls, where the event graph already exists across TMS, telematics, and EDI. Our logistics operations write-up covers what becomes automatable.
Support and service operations. Misrouted tickets, unnecessary tier transfers, and repeat contacts. In customer support operations the highest-value target is routing and resolution preparation, not a general-purpose chatbot.
A 90-day sequence that fits the method
Weeks 1–2. Pick one workflow with real exception volume. Define the business metric before you extract anything: cycle time, touched cases, analyst hours, SLA misses.
Weeks 3–4. Extract the event log and check the four mandatory fields. Answer the timestamp question for every activity. Fix or exclude what you cannot trust — this is the step teams skip and the reason findings collapse later.
Weeks 5–6. Reconstruct the real paths, separate happy path from exception path, and run the artefact test on the top findings.
Weeks 7–8. Push survivors through the four gates. Delete Gate 1 steps. Configure Gate 2 rules. Rank what remains.
Weeks 9–12. Build one Gate 3 automation, with the feedback signal wired in from the first day rather than added later.
Less exciting than deploying an agent across the operation. It is also the sequence that produces something still running in month six.
Frequently Asked Questions
What is AI process mining?
AI process mining reconstructs how work actually flows by analysing event data that business systems already record — case IDs, activity names, timestamps, and the resource that acted. The useful output is not a map of activities but a ranked set of decision points, delays, and rework loops that can be tested for whether they are worth changing.
What data do I need to start process mining?
Four fields per event at minimum: a stable case ID, an activity name, a timestamp reflecting when the work happened, and the resource that performed it. Exception codes and case attributes such as vendor or amount make the analysis considerably more useful. Before trusting any duration, confirm each timestamp is written at the moment of the work rather than by a batch job.
How do I know whether a bottleneck is real?
Run four checks. Durations that cluster on round numbers indicate a job schedule rather than a queue. A step that is instant for most cases and slow for the rest usually means two events share one activity name. A service account as the resource means you are seeing a system write, not a human decision. And case counts that do not reconcile between entry and exit mean cases are ending or being renamed elsewhere.
What should we automate first after a process-mining exercise?
Whatever survives all four gates: a step that changes the outcome, is not already governed by a written rule, is reversible, produces a signal when it is wrong, and happens often enough to justify the build. In practice that is usually prioritisation, routing, classification, or preparing a recommendation for human review.
Do we need AI agents to benefit from process mining?
No. Findings that die at the first gate are fixed by deleting a step, and findings that stop at the second are fixed by configuring a rule. Both deliver value without a model. Process mining becomes more valuable alongside agents because it tells you which decisions are safe to delegate — not because agents are the point.
How long does it take to see value?
If the event data is accessible, the major findings surface within a few weeks, and Gate 1 and Gate 2 fixes can ship immediately after. A bounded automation on a single decision class typically fits a 60- to 90-day window. Untrustworthy event data is what stretches timelines, not the analysis.
Need help with AI implementation?
We build production AI systems that actually ship. Not demos, not POCs—real systems that run your business.
Get in Touch