Designing Exception Handling People Can Live With
Every process has cases that do not fit. The difference between automation people trust and automation people work around is almost entirely in how those cases are handled.
Automation projects are specified around the happy path and judged on the exception path. The demonstration shows a case flowing cleanly from start to finish; the reality is that somewhere between five and thirty per cent of cases will not fit, and how those are handled determines whether the team adopts the process or quietly builds a spreadsheet beside it.
Exception handling is not error handling. An error is something going wrong. An exception is a case the process was not designed for, which is a normal and permanent property of real business processes rather than a defect to be eliminated.
Four kinds of exception, handled differently
- 1Transient failures. A system was briefly unavailable, a request timed out, a rate limit was hit. These should be retried automatically with a sensible backoff and should never reach a person. If they do, the retry policy is wrong.
- 2Data exceptions. A field is missing, a value fails validation, a reference does not match anything. These need a person, but a specific one, with the document and the offending value in front of them and the ability to correct and continue.
- 3Policy exceptions. The case is valid but falls outside the rules, an amount over a threshold or a supplier not on the approved list. These need a decision maker rather than a corrector, and the decision needs recording with its justification for audit.
- 4Unknown-unknowns. The case does not resemble anything anticipated. These go to whoever owns the process, and every one should be reviewed, because they are how you discover the process is broader than you mapped.
Collapsing these four into a single failed queue is the most common design mistake in the field. It produces a queue containing timeouts, typos and genuine policy decisions all mixed together, reviewed by whoever has time, which means the important cases wait behind the trivial ones.
Park the case, do not fail it
When a case cannot proceed, the workflow should stop and hold it in a defined state rather than terminating. The case retains everything gathered so far, the step it stopped on, the reason, and the timestamp. Nothing is discarded and nothing needs to be reconstructed.
The reason this matters is what happens next. If the case failed, resolving it means starting again, which is both slow and dangerous, because any side effects already committed will be repeated. If the case is parked, resolving it means the workflow continues from precisely where it stopped, with the earlier steps intact and un-repeated.
Resume from the step that stopped. A process that restarts from the beginning after every exception will duplicate side effects, and your team will learn not to trust it.
Give the reviewer everything at once
The quality of an exception queue is measured by how long it takes to resolve one case without leaving the screen. A reviewer should see the reason the case stopped in plain language, the source document or record, the values extracted or calculated, what the process expected, the case history, and the actions available to them.
Every additional system a reviewer has to open to make a decision adds minutes and errors. A queue that requires opening three other applications to resolve a single item is not an exception queue, it is a to-do list that has been made harder to use, and the team will treat it accordingly.
Instrument the exception rate
The exception rate is the most sensitive early warning signal an automated process has. It should be monitored per exception type, with an alert when a rate moves outside its normal range.
A rate that climbs sharply almost always means something upstream has changed: a supplier altered their invoice layout, a source system started populating a field differently, a policy was updated without the workflow being told. Catching that on the day it happens turns a two-hour fix into a two-week clean-up avoided. A rate that falls to zero is equally worth investigating, because it usually means a validation rule has stopped firing rather than that quality has suddenly become perfect.
Set an explicit target, and defend it
Decide during design what proportion of cases should complete without human involvement, and treat it as a design constraint rather than an aspiration. Eighty per cent straight through with a clean, fast path for the remaining twenty is a strong outcome for a first process, and considerably better than ninety-five per cent achieved by letting the workflow guess at cases it does not understand.
Pushing the rate higher by lowering confidence thresholds is the most expensive mistake available here. Errors that flow silently into finance or customer systems cost far more to unwind than the review time saved, and each one erodes the trust that made the automation possible in the first place.