Answer
How should an AI workflow handle exceptions?
Route them to a person with the context attached, and count them by type. An unowned exception path becomes a hidden backlog.
Route them out of the automated path to a named person, with enough context that resolving one takes a minute rather than an investigation, and count them by type so the recurring kinds can be designed away.
Every automation has a happy path that gets designed carefully and an exception path that gets whatever is left. That allocation is backwards in effect if not in intent: once the automation runs, the happy path handles itself and every remaining minute of human attention is spent on exceptions. The quality of the exception handling is what determines whether the automation actually saved anything.
The first requirement is that an exception leaves the automated path rather than being guessed at. A workflow that handles an unusual item by picking the most plausible interpretation has converted a visible exception into an invisible error, which is a worse outcome than stopping. This is the same argument as failing safely, applied to the specific case where the input is legitimate and unusual rather than broken.
The second is context. An exception arriving as an item identifier and an error is a research task; the same exception arriving with what the workflow understood, what it could not resolve, and what it would have done gives someone enough to decide in under a minute. This difference determines whether exceptions get handled promptly or accumulate, and accumulation is the failure mode that ends automations.
The third is ownership. Exceptions need a named person and a place they appear that person already looks. A queue nobody owns fills up; a queue in a system nobody opens fills up more quietly. The most reliable arrangement puts exceptions into whatever list the responsible person already works from, rather than creating a new place to check.
The fourth is counting by type, and it is where the durable value sits. Exceptions cluster: one supplier's invoices always fail, one enquiry format is never parsed, one category always needs review. A count by reason turns a stream of individual problems into a short list of design changes, most of which are cheap. Businesses that do not count handle the same exception forever without noticing it is the same one.
The fifth is deciding what an acceptable exception rate is, in advance. A workflow sending a fifth of its items to a person is doing something useful; one sending most of them has not automated the process, it has added a step to it. Stating the threshold beforehand prevents the slow drift where an automation gradually stops covering the work while everyone continues to describe it as automated.
The exception path is where the work goes once the automation is working, which is why it deserves more design than the happy path.
Siddharth Sharma, Context Theory
Related questions
Should the workflow attempt the unusual case if it is fairly confident?
Only where a wrong result is cheap and detectable, and confidence is a poor basis for the judgement in any case. The safer arrangement is to define the cases it handles by their characteristics rather than by how sure it is, so the boundary is a property of the input rather than of the moment.
How do you stop the exception queue becoming a second job?
By counting types and fixing the top two. Most exception volume comes from a small number of recurring causes, and addressing them usually removes the majority. A queue that stays large after that is telling you the process is more varied than the automation assumed, which is a scoping problem rather than a staffing one.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Firms that never responded to a web enquiry at all | 23% | Category-wide |
2026 speed-to-lead benchmark · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | Once an automation is running, the happy path consumes no human attention and every remaining minute is spent on exceptions, so exception handling quality determines whether the automation saved anything. | Recording where human time on the process is spent after the automation is live. |
| Response | An exception delivered with what the workflow understood, what it could not resolve and what it would have done can be decided in about a minute, while one delivered as an identifier and an error becomes a research task. | Timing resolution of exceptions delivered with and without workflow context attached. |
| Constraint | Exceptions cluster by cause — a particular supplier, format or category — so counting by reason converts a stream of individual problems into a short list of cheap design changes. | Grouping a month of exceptions by reason and checking the concentration. |
| Buying behaviour | Stating an acceptable exception rate in advance prevents the drift in which an automation gradually covers less of the work while continuing to be described as automated. | Comparing the current proportion of items routed to a person against the proportion at launch. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one