Why automation projects stall
The usual order of events is that a tool is chosen first and the process it was meant to automate is examined second. The build goes fine. Then go-live arrives, the real cases start flowing through, and a third of them don’t fit the path that was built.
What happens next is predictable. The team keeps a manual route open “just for the exceptions”, the exceptions turn out to be most of the volume, and within a few months the automation handles the easy cases nobody was struggling with anyway. The problem was never the tool. The process it encoded wasn’t the one being run.
The map everyone agrees on
Most organisations have a documented process. It is usually accurate about intent and quietly wrong about practice, because it describes how the work was designed rather than how it survived contact with reality.
- 01Exceptions were never written down. The happy path got documented once. The fifteen ways a case can go sideways live in people’s heads.
- 02Shadow steps accumulate. A spreadsheet that tracks what the system can’t, a chat group where approvals really happen, a personal inbox that acts as a queue.
- 03Judgment is invisible. A step reads “review and approve”, which hides the experience someone applies to decide what good looks like.
If you can’t say who does the step, on which system, and what they do when it goes wrong, you don’t have a map yet. You have a diagram.
How to map what actually happens
Mapping honestly takes days, not weeks, and it is mostly a matter of watching rather than asking.
- Sit with the people doing the work and follow real cases end to end, rather than interviewing them about the process in the abstract.
- Sample across the range: a straightforward case, an awkward one, and one that went wrong and had to be unpicked.
- Record the system of record at every step, including the unofficial ones. Spreadsheets and chat threads count.
- Count how much volume actually follows the happy path. This single number decides how much automation is worth building.
- Play the map back to the team and let them correct it. The corrections are the most valuable part of the exercise.
What to record at every step
A step is only properly mapped when three things are written down. Anything less and you will discover the gap during build.
Trigger
What starts the step, and how the person responsible finds out it is waiting for them.
Watch for steps triggered by someone remembering.
Decision
What judgment is applied, and whether there is a written rule behind it or just experience.
Watch for rules that differ by who is on shift.
Evidence
What the step produces, where it is stored, and who needs to find it again later.
Watch for evidence that only exists in an inbox.
Alongside the map, four numbers per step are usually enough to decide what to do: volume, time taken, how often the work has to be redone, and what share of cases leave the happy path.
What not to automate
An honest map makes the exclusions obvious, and they matter as much as the inclusions.
- Steps that exist only to correct a broken step upstream. Fix the upstream problem and the work disappears instead of getting faster.
- Judgment calls with real consequences and no written rule. Keep a person in place and automate the preparation around them.
- Low-volume work with high variation, where handling the exceptions costs more than the manual effort ever did.
- Anything you could simply delete. The cheapest automation is removing a step nobody can justify.
In short
Key takeaways
- The documented process and the real one are different. Automate the real one.
- Map by watching real cases across the full range, not just the happy path.
- Measure the exception rate before choosing a tool. It decides what is worth building.
