Ask five people how an important business process works and you may get five different answers.
The manager describes the intended process. The team member describes the practical workaround. The CRM shows one sequence. The spreadsheet shows another. Email contains exceptions that never made it into either system.
This gap matters because many automation projects start with the intended process rather than the real one.
If you automate the process people describe instead of the process the business actually runs, you can make the mismatch faster.
The official process is rarely the whole process
Most operating processes contain invisible work. Someone checks a record before moving it forward. A team member copies information into a second system because an integration is missing. An approval waits because the approver is unclear. A customer exception is handled through messaging rather than the workflow. A report is manually corrected before management sees it.
These steps often disappear from process documentation because they were never deliberately designed. They emerged as adaptations.
That is precisely why they need to be understood before automation.
Map the work before choosing the automation
A useful workflow map does not need to become a consulting diagram with hundreds of boxes. It needs to expose the operating facts that affect execution.
At minimum, identify:
- what triggers the work;
- which person or system owns each stage;
- what information is required;
- which systems are touched;
- where decisions occur;
- what conditions cause exceptions;
- where work waits;
- where information is re-entered;
- what indicates completion; and
- what happens when the happy path fails.
That map turns “automate this process” into a more useful set of questions.
Look for four kinds of friction
1. Waiting
Work is ready to move but cannot because it is waiting for a person, approval, missing information or another system.
2. Rework
A task is repeated because information was incomplete, entered incorrectly or changed downstream.
3. Handoffs
Responsibility moves between people or teams and context is lost, delayed or reconstructed.
4. Exceptions
The workflow handles the normal case, but anything unusual leaves the system and becomes a manual recovery exercise.
These are often better automation targets than the obvious task at the centre of the process.
Process intelligence adds evidence
Interviews and workshops remain useful, but businesses increasingly have another source of evidence: the event data already generated by the systems doing the work.
Process mining uses records from systems of record to reconstruct how processes actually execute. Microsoft describes process mining as a way to visualise real process behaviour, compare variants, identify root causes and uncover opportunities for improvement and automation. Its 2026 Power Automate roadmap continues to expand process intelligence, object-centric process mining, KPI analysis and workflow observability.
The important idea is larger than one product: operational decisions can increasingly be based on observed execution rather than only on memory and opinion.
Do not confuse process mining with automatic truth
System data is powerful, but it is not complete by default. If important work happens outside the recorded systems, the event log will not magically reveal it. If timestamps are unreliable or users bypass the intended fields, analysis can still mislead.
A strong diagnosis combines system evidence with operating context. Data can show that a case spent three days in a stage. A conversation may reveal that the team was waiting for information that the system never records.
The goal is to understand the operating reality, not to defend a particular methodology.
What should be automated after the process is understood?
Once the process is visible, automation opportunities become easier to classify.
Deterministic automation
Use rules for predictable actions: moving data, assigning work, triggering notifications, creating records or enforcing known conditions.
AI-assisted work
Use AI where language, classification, summarisation or probabilistic judgment genuinely adds value.
Human decisions
Keep people where context, accountability, negotiation or exceptional judgment matters.
Process removal
Some steps should not be automated at all. They should be deleted because they exist only to compensate for a poor system or an outdated control.
This last category is often overlooked. Removing a useless step is usually more robust than automating it.
A practical diagnostic before any automation project
Before approving an automation, ask:
- Can we describe the start and end of the workflow clearly?
- Do we know who owns each stage?
- Do we know where the required data comes from?
- Do we know the common exception paths?
- Can we identify the largest waiting and rework points?
- Are we automating a necessary step or preserving an unnecessary one?
- What should happen if the automation fails?
If several of those answers are unclear, implementation is premature.
What better looks like
A well-designed workflow is understandable enough that people can explain it, systems can support it, automation can execute the repeatable portions and management can see when it is not behaving as expected.
That does not mean eliminating every exception. It means exceptions are known, owned and handled deliberately rather than becoming hidden side processes.
The payoff is wider than automation. Once the real workflow is visible, the business can make better decisions about software, roles, service levels, reporting and operational improvement.
When to act
If automation discussions repeatedly begin with a tool demonstration, staff disagree on how the process works, important work is happening in spreadsheets or chat, or exceptions routinely escape the formal workflow, start with diagnosis.
The fastest route to better automation is sometimes to delay the automation long enough to understand what it should actually do.