The exception problem: why automation projects overrun

Ask someone to describe a business process and you get the happy path. Order arrives, stock is checked, invoice is raised, payment is reconciled. Four steps, obviously automatable, should take a fortnight.

Then you sit with the person who actually runs it and it becomes: order arrives, unless it is from one of three accounts with bespoke terms, unless it is a rush order which skips the stock check, unless it is December when the cut-off moves, unless the customer is on credit hold in which case sales has to approve it, unless the value is under $200 in which case nobody bothers.

Those five exceptions are more engineering than the four steps. This is the single most reliable cause of automation projects costing more and taking longer than quoted, and it is entirely predictable.

Why exceptions dominate the work

The happy path is linear. Exceptions are combinatorial.

Four sequential steps are four units of work. Add five independent conditions and you are no longer building one path — you are building a decision structure where conditions interact. Is a rush order from a credit-held account in December approved automatically or not? Nobody has ever written that down, because in the manual process a person just decided.

You do not have to build every combination — most collapse into sensible defaults. But you do have to think about every combination, decide which collapse and which do not, and test the ones that survive. That thinking is the work, and it is invisible to anyone estimating from a flowchart.

On a mature process, exception logic is routinely 60 to 70% of the build. On the estimate it is usually 0%.

Why nobody mentions them

Not evasion. Four honest reasons.

They are genuinely tacit

The person handling exceptions often does not experience them as exceptions. They have absorbed the rule so completely that it feels like the process rather than a deviation from it. Asked "what are the exceptions," they say "there aren't really any" — and then handle six in an afternoon without remarking on any of them.

This is why we shadow the work rather than interview about it. Watching someone do the job for two hours surfaces more than a day of questions.

The person describing it does not do it

Managers describe processes as designed. The people running them describe processes as they are. These differ, always, and the difference is entirely exceptions — accumulated workarounds for problems the original design did not anticipate.

Exceptions live in individuals, not documents

The reason the December cut-off moves is a customer complaint from years ago. The person who was there knows. It is written nowhere. When they are on leave, their cover gets it wrong, and everyone treats that as an unfortunate one-off rather than evidence of undocumented logic.

Admitting them feels like admitting mess

There is a mild embarrassment in explaining that your ordering process has fifteen special cases. It shouldn't — every process does, and a process with none has usually just pushed its exceptions somewhere less visible. But the instinct is to present the tidy version, and the tidy version is what gets quoted against.

How to surface yours before anyone quotes

You can do most of this yourself in an afternoon, and it will improve any quote you receive from anyone.

1. Shadow, don't interview

Sit with the person doing the work for two hours and watch. Every time they pause, hesitate, check something, or open a system you did not expect — that is an exception. Ask what they were thinking. The answer is usually a rule nobody wrote down.

2. Sample the last fifty real transactions

Not typical ones. The actual last fifty, in order. Count how many went through the happy path exactly. In our experience it is usually 60 to 80% — and the remaining 20 to 40% is your exception inventory, with real frequencies attached rather than guesses.

3. Ask three specific questions

Vague questions get vague answers. These do not.

• "When was the last time you had to do something different from normal here?" Anchoring on a specific recent event gets you a real case rather than an abstraction.
• "What goes wrong when you're on holiday and someone covers?" This is the highest-yield question in the entire audit. Whatever your cover gets wrong is exactly what is undocumented.
• "Which customer or supplier is annoying to deal with, and why?" Annoyance is almost always a proxy for bespoke handling.

4. Look for the shadow spreadsheet

Almost every process has one — a personal tracker somebody maintains alongside the official system. Its columns are a precise map of what the official system does not capture, which is to say, a map of your exceptions.

What to do with them once you have them

Finding exceptions does not mean building all of them. Four options, and choosing well is most of the value.

Eliminate

Some exceptions have outlived their reason. The December cut-off addressed a problem in a system you no longer use. Before encoding a rule, ask why it exists — a meaningful share cannot survive the question. Eliminating an exception is the cheapest possible way to handle it.

Standardise

Three customers have bespoke terms for historical reasons. Could they have the same terms as each other? Often yes, and nobody has asked in years. Collapsing three exceptions into one is nearly as good as removing them.

Automate

If it is frequent and the rule is clear, build it. High-frequency exceptions are not really exceptions; they are unacknowledged parts of the process and belong in the main path.

Route to a human

The most underused option. If an exception occurs twice a month and the rule is genuinely judgement-dependent, do not build it — detect it and hand it to a person with the context assembled.

What this means for the quote

A quote produced without exception discovery is a quote for the happy path. It will be lower than the real number and it will move. Whether it moves via a change request, a "clarification," or a project that quietly runs late depends on the firm — but it moves.

This is the main reason we insist on an audit before quoting a build, and why the audit involves shadowing rather than a workshop. It is also why our builds are fixed price: having done the discovery, the estimating risk is ours to carry. If we miss an exception we should have caught, we absorb it. That is only a fair commitment to make after looking properly.

If you are evaluating proposals, the question to ask is simply: how did you arrive at this number, and who did you watch? A firm that quotes from a one-hour call with a manager has priced a process that does not exist.