Process Mining for Automation: Find the Right Work

Is your process slow because people spend time working on it or because cases sit in a queue?

Patrick Chemoul, CEO of Dopweb

November 6, 2026

Branching process paths on an event graph

Process mining reconstructs how cases move through your systems using recorded events. For automation planning, it helps identify common paths, rework loops, and waiting time. Validate the event data with the people who handle the cases before deciding what to automate.

What data do you need for process mining?

A useful event log includes a case ID, activity, and timestamp. A purchasing system might record request submitted, assigned, returned, approved, and completed. Join data from multiple systems only when you can match cases reliably. If the same request appears under different IDs, establish the mapping before analyzing the path.

Check what the event log cannot see

Work may happen by email, in spreadsheets, or outside the system. Some activities are recorded in batches long after they occurred. Look for impossible sequences and explain missing events. Review a sample of individual cases with staff so you know whether the event represents actual work, a change in status, or simply a later update.

Example: find rework in a purchasing queue

A distributor suspects that approvals are slow. Its records show that many requests move straight through, while some bounce between purchasing and finance because a vendor detail is missing. Instead of speeding up every approval, the team can validate the required fields before assigning the request. That change targets a specific reason for rework.

Separate handling time from elapsed time

A request may spend two days waiting for a missing field and only a few minutes being reviewed. Shortening that delay helps the requester. It does not necessarily free two days of staff capacity. If you need both measures, collect active handling time separately and check whether the system actually records it. Use staff observations where the event data is too coarse.

In one simulation of 160 requests, 100 go straight through, 40 are returned for a vendor detail, and 20 follow another path. Returns for that reason affect 25% of the sample. Check whether the 40 requests cluster around one source or form before applying a new rule to every request.

100 straight-through requests 40 vendor-detail returns 25% of the sample

In a separate simulated comparison, median elapsed time falls from 54 to 36 hours after introducing a completeness check. The difference is 18 hours of elapsed time. Measure staff handling and rework separately to see how much capacity the change actually released.

54 h baseline median elapsed time 36 h after the check 18 h shorter elapsed time

How do you turn findings into an automation decision?

Choose a recurring pattern, verify its cause, and ask whether the input is reliable enough for a rule. A missing required field may be handled by the intake form. If the information arrives in a variable supplier packet, an extraction step can suggest values for review. See intelligent document processing for the controls that keep this extraction verifiable.

Run a small validation workshop

Select actual cases from the main path and rework loop. Ask staff what happened between events and where the reliable record lives. Decide which exception must remain human-owned and what the first change should achieve. Microsoft’s process mining overview explains how event data supports this kind of analysis.

Measure the process again after the change

Track returns, active handling, and elapsed time across comparable cases. Watch for requests moving outside the workflow because staff find it harder to use. Confirm that quality remains stable. If the change only shifts work into a new queue, review its design before expanding it to more teams.

How do you prepare a useful event extract?

Choose a period with completed cases and track cases still open separately. Standardize activity names and time zones, and document changes to the source systems. If an approval appears in two logs, determine whether the records represent two business actions or two copies of the same event. Keep enough context to trace the decision.

How much detail belongs in the process map?

Include steps that change case state or reveal rework. Individual system clicks can obscure the reason a case returned to intake. When the map shows an unexpected transition, inspect the underlying cases with staff. Make sure combining activities does not hide a handoff between teams that uses separate records.

How do you present findings to stakeholders?

Show a common path, a costly exception, and one gap in the event data. Discuss which finding the team can verify and which needs better instrumentation. If an exception is infrequent but delays important requests, compare its impact with the higher-volume paths before deciding what to automate first.

See the intelligent automation guide to see how this step fits into the full workflow.

Separate necessary rework from avoidable rework

A return can reflect a legitimate change in the request or a field that should have been collected at intake. Review the original request, the recorded return reason, and the work performed next. A completeness rule can address the missing field. An actual change needs a supported revision path. If your logs do not show the reason, add it before drawing conclusions. This prevents you from treating every repeated step as waste.

How Dopweb helps prioritize automation

We map your process with the people who run it, inspect the available events, and identify a change your team can measure. We connect the relevant tools and design the test and fallback before rollout. If an AI step is useful, we scope its data and monitor retries. Explore AI Agents & Workflow Automation.

About the author — Patrick Chemoul, CEO of Dopweb
Patrick Chemoul leads Dopweb, an agency helping businesses with websites, software, and automation. The agency also provides AI agent integration and team training. Learn about Dopweb.

Frequently Asked Questions

Use a case ID, an activity, and a timestamp. Verify how cases match across systems.

Elapsed time includes waiting. Measure active handling separately before estimating the capacity released.

Compare frequency, reliability of the inputs, rework, and the impact of an incorrect action.

Review sample cases with staff, document the gap, and avoid drawing conclusions about work you cannot observe.

Let’s Talk About Your Project

Tell us which process you want to improve. We’ll help define a first workflow your team can test.