Most automations that fail in production do not fail on the happy path. They fail on the third Tuesday, when a record arrives without a field somebody assumed was always present, and nobody finds out for a week.
Those cases are entirely discoverable in advance. They just are not discoverable by asking someone to describe the process, because people describe processes as they are supposed to work. The exceptions live in muscle memory, and they only surface when you follow a real instance through.
What a map has to contain
Not a flowchart. A record of what actually happens.
| Element | The question it answers |
|---|---|
| Trigger | What starts this, exactly? A time, an event, a person noticing something? |
| Steps | What happens, in order, with who does it |
| Decisions | Every point where the path forks, and the rule that decides |
| Inputs | What information each step needs, and where it comes from |
| Handoffs | Every point where it moves between people or systems |
| Waiting | Where it sits, and for how long |
| Exceptions | What happens when the expected thing does not happen |
| Outcome | How you know it finished, and who confirms |
The last two carry most of the value. The first six are usually already understood.
Follow one real instance
The single most useful thing you can do is take one live case and follow it from trigger to completion, recording what happens rather than what should.
Three things reliably surface that no interview produces:
- Undocumented steps. Someone checks something before proceeding. It is not in any process description because it is not officially part of the process. Automate without it and you have removed a check nobody knew existed
- Actual waiting time. Two hours of work spread over four days. The four days are the customer's experience, and they are the thing worth fixing
- Silent workarounds. A spreadsheet that reconciles two systems. A message someone sends to unblock things. These exist because the official process does not work, and automating the official process leaves the workaround stranded
Recording decisions properly
Every decision point needs a rule that can be written down. Where one cannot be written, that is the finding.
| What you hear | What it means | What to do |
|---|---|---|
| "If X then Y, otherwise Z" | A rule | Record it and move on |
| "Usually Y, but sometimes Z" | An unstated condition | Keep asking until it surfaces |
| "It depends" | Judgement, not procedure | Record who decides and what they weigh |
| "Ask Sarah" | Sarah holds undocumented rules | Interview Sarah specifically |
| "We just know" | Tacit knowledge | Follow three instances and infer the pattern |
"It depends, ask Sarah" is not a failure of the mapping. It is the most valuable thing you will find. It tells you exactly where the process depends on a person, and therefore exactly where automation should stop and hand over rather than attempt to continue.
Mapping frequently shows that the process itself is the problem rather than the manual effort, which is why
the process redesign that usually comes before automation.Exceptions are the deliverable
Treat the exception list as the primary output, not an appendix.
For each step, ask:
- What if the input is missing?
- What if it is malformed or in the wrong format?
- What if the person responsible is unavailable?
- What if the external system is down?
- What if this has already been done?
- What if it needs to be undone?
That last one — reversal — is the most commonly forgotten and the most expensive. An automation that creates records, sends notifications and updates three systems needs a defined answer for what happens when it ran on the wrong record. If nobody has thought about it, the answer is discovered under pressure.
Separate waiting from working
Record these as different things, because they have different fixes.
Working time is when someone is actively doing something. Automation reduces it by doing the work faster.
Waiting time is when nothing is happening — awaiting approval, awaiting a reply, awaiting a batch job. Automation reduces it by removing the wait entirely, which is usually the larger win.
A process with twenty minutes of work spread across three days is a waiting problem. Automating the twenty minutes saves twenty minutes. Removing the waiting saves three days, and the customer only ever noticed the three days.
What the map tells you
When it is finished, it answers the automation question directly:
| Finding | Implication |
|---|---|
| Every decision has a written rule | Genuinely automatable |
| Some decisions are judgement | Automate around them — hand off, do not attempt |
| Steps exist that nobody can justify | Redesign first. The automation may become unnecessary |
| Most elapsed time is waiting | The win is removing waits, not speeding up work |
| Exceptions outnumber the happy path | Not stable enough. Fix the upstream cause |
| The process differs per person | Standardise before automating, or you encode one person's version |
The fifth row is a stop signal. If exceptions outnumber the main path, the process is not a process yet — it is a set of related judgements, and automating it produces a system that escalates most of its cases.
A workable format
Formal notation is rarely worth it. This is enough for almost every business process and, crucially, people will actually read it:
PROCESS: [name]
OWNER: [who is accountable]
RUNS: [frequency]
TRIGGER
[what starts it]
STEPS
1. [action] — [who] — [inputs needed]
Decision: [if applicable, with the rule]
Exception: [what happens when it goes wrong]
Waits: [duration, if it waits here]
2. …
EXCEPTIONS (consolidated)
[every failure mode found, with current handling]
JUDGEMENT POINTS
[decisions that are not rules, and who makes them]
OUTCOME
[how you know it finished]
[who confirms]
OBSERVED
Instances followed: [how many]
Working time: [x]
Elapsed time: [y]
[the gap between x and y is where the opportunity is]
The last block matters. Working time versus elapsed time is the number that justifies the project, and it is measurable rather than estimated.
What to do with it afterwards
Keep the map. It is more durable than any automation built from it.
Platforms change and workflows get rebuilt, but the process understanding transfers directly — as noted when comparing automation platforms, teams whose process knowledge exists only inside a tool are far more locked in than the pricing page suggests.
The map is also what makes the next conversation possible: whether this should be automated at all, which is a different question and worth asking before anyone opens a platform.
Want this handled properly?
You now know what the work involves. If you would rather not do it yourself, that is what we do.