The exception is the process
The automation handles eighty per cent of cases. The other twenty were always where the time went.
Eighty per cent automated. The same hours spent.
The cases that took the time were the ones the process document never described.
Automation is scoped against the standard case because that is what a process document describes. But the standard case was never the expensive part — it was already fast. The exceptions were where the time went, and they are still being handled by hand, by the same people, with the automation running quietly beside them.
Somebody maps the process. It has seven steps, three decision points and a clear happy path. The automation is built against it, tested, and released.
Afterwards, the team is spending roughly the same amount of time on the work as before.
The process document described the standard case, because that is what a process document is. It is written by asking somebody what they do, and what they describe is the version that runs cleanly — the one they can articulate. The version they cannot articulate is the accumulation of exceptions, and that is where the hours went.
An exception is not a rare event. It is a case the standard route cannot take, and in most operations the exceptions are neither rare nor exceptional. They are the returns processed differently for one supplier, the accounts that need a manual check because of a decision made in 2019, the region with different paperwork.
Each one is individually reasonable and none of them appears in the map.
The parts of a process nobody can describe are the parts that take the time. That is why they cannot be described — they are held in judgement rather than in steps.
The result is a specific and quiet failure. The automation works. It handles the cases it was built for, and those cases now take almost no time. The exceptions continue exactly as before, and the total time barely moves — because the exceptions were most of it.
Worse, the exceptions get harder. The people handling them now do so less often, so the knowledge stays sharp in fewer heads. And the automation running beside them creates a second path to reconcile, which is work that did not exist before.
Map the exceptions before the standard case. Sit with somebody for a day and record every case that does not go the straight way, and why. That list is the actual specification and it takes a day to produce.
Count them before scoping. If the exceptions are a small share of volume, automate the standard case and leave them. If they are a large share, automating the standard case will not move the total time — and that is worth knowing before the budget is committed rather than after.
Automate the exception route, or state that it stays manual. Both are acceptable. What is not is building for the standard case and hoping the exceptions shrink, which is the common arrangement and the one that produces nothing.
- A process document describes the case somebody can articulate
- The exceptions are where the hours are, and they are usually not rare
- Count them before scoping, because the count decides whether the project is worth doing
- Automating beside a manual exception route adds reconciliation work that did not exist before
This describes automation projects we have reviewed after delivery, usually because the expected time saving did not appear. Projects that delivered their saving are not brought to us.
Counting the exceptions before scoping is the whole of it, and it takes an afternoon. Where it turns out the automation is worth building, that is what we do.
Limits
Engagement observation, not a study
Drawn from automation projects we reviewed after delivery, usually because the expected time saving did not appear. Projects that delivered their saving are not brought to us.
The proportions vary by operation
Where the exceptions sit as a share of hours differs sharply between operations and we have not measured it systematically. The point is that the two numbers differ, not that they differ by a particular amount.
Some exceptions should not be automated
A meaningful share exist because of a decision nobody has revisited, and removing the reason is better than building around it. This describes what happens when neither is done.
Questions
How do we find the exceptions?
Sit with the person doing the work for a day and record every case that does not go the straight way. It is not an interview — people cannot recall exceptions reliably, but they handle them in front of you.
What if there are too many to automate?
Then that is the finding, and it is worth having before the budget is committed. Some operations are exception-heavy by nature and the right answer is to reduce the exceptions rather than to automate around them.
Is high coverage not good?
It depends entirely on whether the covered cases were the expensive ones. Coverage measured in cases and coverage measured in hours are different numbers and usually far apart.
Does this apply to AI specifically?
More than to conventional automation, because AI is often introduced precisely for the judgement-heavy cases — and then scoped against the standard ones anyway.
What about exceptions that appear later?
They will. A route for handling a case the system cannot take is a permanent requirement rather than a transitional one.
Should we automate the exceptions instead?
Sometimes. More often the useful move is to find out why they exist, because a meaningful share of them are decisions nobody has revisited.
Govil, A. (2026). The exception is the process. The Field Report, XONIK.