Smart Statistics · Business improvement insight
Before You Automate: Is Your Business Ready for Process Mining?
A service request takes days to complete, yet each visible task seems quick. The temptation is to automate the busiest-looking step. The delay may actually sit in an unrecorded handover, a missing piece of information or repeated clarification.
Process mining can help reconstruct the routes cases take through a business. Its usefulness depends on whether the recorded events represent the work well enough to support a decision. Start by testing that evidence, before choosing what to automate.
Illustrative example · Service-request pilot
Where does the journey split?
Source: service-system event history. Route counts reconciled; off-system conversations not yet checked. Workflow: request received → review → clarification if needed → fulfilment → closure.
The first question is about evidence
Do you have a history of what happened, or just a table of what is true now?
A status snapshot
A row saying “Closed” tells you the current state. It does not tell you how often the request returned to review or how long it spent between recorded steps.
An event history
A sequence of dated activities tied to the same request can reveal routes and repetition. Microsoft identifies case ID, activity and timestamps as core process-mining inputs. [1]
A business explanation
The log may show a loop without explaining it. A specialist request may legitimately need another review. Validate the apparent problem with the people doing the work.
Readiness means more than a successful import. You need a defined case, meaningful events, interpretable time and someone able to change the process after the findings are checked.
Follow one request before analysing thousands
For a UK business-services team, define a case as one service request from receipt to closure. Do not use the customer as the case: a customer may have several simultaneous requests. Agree whether a reopened request continues the original case or becomes a linked new one.
| Case ID | Activity | Timestamp (UTC) |
|---|---|---|
| SR-1042 | Request received | 2026-11-02 09:00 |
| SR-1042 | Review completed | 2026-11-02 10:00 |
| SR-1042 | Clarification requested | 2026-11-02 10:05 |
| SR-1042 | Information received | 2026-11-03 14:00 |
| SR-1042 | Request closed | 2026-11-03 16:00 |
This journey spans 31 elapsed hours. It does not establish 31 hours of staff effort. There is no record here of when someone started working, paused, switched tasks or spoke to the customer.
Microsoft distinguishes single-timestamp event logs from activity logs with start and end times. Its statistics documentation explains that, without event duration, the interval between events is treated as waiting time and active time cannot be calculated. Read those labels in the context of your capture method. [2]
Have an operator reconstruct this case from the original records. Then inspect a direct case, a reopened case, a cancelled case and an unfinished case. If the reconstructed journey disagrees with the export, fix the interpretation before presenting a process map as fact.
Choose the investigation route
| What you have | Best next move | What to avoid |
|---|---|---|
| Reliable event history, repeated cases and uncertain routes | Run a bounded process-mining pilot around one operational question. | Loading every available system before agreeing the case boundary. |
| Current status only, with little usable history | Design event capture and observe cases prospectively. | Inventing intermediate events from the latest status. |
| A simple, known route with a known queue problem | Start with a focused queue or cycle-time analysis in Excel or Power BI. | Adding specialist tooling when a smaller analysis answers the question. |
| Work mainly happens in calls, email or informal handovers | Combine interviews and observation with a sample case review. | Treating the visible system fragment as the entire process. |
For Power Automate Process Mining, Microsoft documents event-data preparation and connectors including SQL Server and Dataverse. [1] Treat extraction, access, environment setup and licensing as separate readiness checks. Do not assume an existing Microsoft 365 or Power BI licence covers the intended deployment; confirm the applicable entitlements with your administrator before procurement.
Protect the analysis from convincing errors
Keep case identity stable
Preserve identifiers as text, including leading zeroes. Distinguish repeated source events from legitimate repeated work. Keep a source event ID where available so duplicate extraction can be investigated without deleting real rework.
Make the clock explicit
Record the source time zone and conversion rule. Check UK daylight-saving transitions and tied timestamps. A batch update time may reflect system processing rather than the moment the work occurred; document that limitation.
Include unfinished journeys
A completed-case cohort can hide the longest-running requests. Report open cases separately and state the extraction cutoff. Do not compare their current age directly with completed-case duration as if both were final outcomes.
Keep people in context
Start with teams and process stages, not employee league tables. Agree the permitted purpose, access and retention with the relevant owners. Restrict names and free text unless they are necessary to answer the approved question.
A route association is a lead to investigate, not proof of cause. Difficult requests may both take longer and require specialist review. Removing the review could make service quality worse while making the map look simpler.
Commission a pilot with an exit decision
Keep the first investigation narrow enough that someone can act on the findings. A useful brief is: “Which avoidable clarification loops extend service-request completion, and what should change at intake?”
- Agree the boundary. The operations owner defines receipt, closure, cancellation and reopening. Record the business question, included request types and excluded channels.
- Prove the extraction. The system owner supplies a read-only export covering an agreed representative period. The analyst reconciles distinct cases and event counts to the source, records exclusions and checks key activities for missing history.
- Validate the interpretation. Operators review sampled journeys and the activity dictionary. Keep the original activity codes alongside normalised labels so the mapping remains traceable.
- Test a small intervention. If missing information drives avoidable clarification, trial clearer intake questions with one comparable team. Assign a service-quality guardrail as well as a speed measure.
- Decide whether to extend. The sponsor reviews evidence, extraction effort, operational benefit and remaining blind spots. Continue, improve capture or stop. A finding that the data cannot answer the question is a valid pilot outcome.
At the pilot review, show median and upper-percentile elapsed duration, the share of completed cases with clarification, open-case age and the agreed quality measure. Define the percentile method and use comparable request types and periods. Keep calendar elapsed time separate from working-time measures; neither is automatically labour cost.
Business impact to test: fewer avoidable clarification cycles, more predictable completion and fewer failed handovers. Confirm any time saving through observation or suitable duration data before converting it into a financial benefit. The dashboard figures above are illustrative, not evidence of a customer result.
Can your evidence support a pilot?
This assessment runs only in your browser. It sends nothing and does not save responses. A score cannot compensate for missing case identity or event history.
Frequently asked questions
Can a current-status spreadsheet support process mining?
A current-status table alone usually cannot reconstruct the journey. You need historical activities linked to cases and timestamps, or a plan to start capturing that history.
Does the time between events measure staff effort?
No. It measures an interval between recorded events. Without suitable duration data and validation, it cannot separate active work from waiting, off-system activity or delayed recording.
Should every repeated activity be automated away?
No. Repetition may represent a necessary control or a complex request. Investigate the cause and test service quality before removing or automating a step.
What is a sensible first process-mining project?
Choose one repeated process with accessible event history, a clear case boundary, an operational question and an owner who can test a small improvement.
Find the right problem before building the automation
Smart Statistics can help assess your event data, define a focused investigation and connect the findings to practical reporting and process improvements.