The exception path is the real automated workflow

What the paper develops

When a team tells me their workflow is automated, I ask to see the exception queue. The answer shows whether anyone owns the cases the automation leaves behind.

What I have seen behind that request is a companion inbox, such as a shared mailbox, where everything the automation could not handle quietly piles up. No classification, no owners, no service expectation. The automation handles its routine volume well. The operation's actual risk, cost, and reputation live in the rest. That is what I observed, not a measured rate. No source in the paper counts how common an unowned exception queue is, so treat the request as a test to run on your own workflow.

There is a reason to expect the cases left over to be the hard ones, and it is the paper's reasoning, not a measured result. Automation is built for the cases that can be recognized and handled by rule or by model, and teams usually automate the easiest first. The cases left with people tend to be the ones it could not handle: the ambiguous, the malformed, the conflicting, the novel, and the unsafe. Lisanne Bainbridge made a related point about industrial control rooms in 1983, so carrying it to business work is an analogy.

The paper's position is that a workflow should not be called automated until its exception path, meaning what happens to every case the automation cannot handle, exists, has owners, and has been rehearsed. The happy path, the cases that run straight through, is the optimization. The exception path has six parts, in operating order, and each depends on the one before.

Classify exceptions

Replace the manual-review bucket with a named list of why processing stopped: bad data, low confidence, policy conflict, failed dependency, suspected harm, novel case. Each class implies a different urgency, skill, and fix.

Detect and contain

The automation must know when it is out of its depth, and stop moving. The failure this prevents is the plausible guess, which turns detectable exceptions into undetected errors.

Route with context

Deliver a decision package, not an alarm: what came in, what was attempted, why it stopped, who is affected, and the clock. Rebuilding context adds nothing to the decision, and the automation already had it.

Assign response ownership

Two owners, not one. Someone resolves this case. Someone else fixes the cause that keeps producing cases like it. Without the second owner, the queue becomes a permanent institution.

Recover to a known state

Resolved means the world is restored: every touched application corrected, partial actions unwound, customers repaired. A case fixed in one application and left wrong in two others is deferred, with interest.

Learn and redesign

Read the queue quarterly as the improvement budget. Measure causes retired, not volume suppressed. A class that vanished because the threshold moved is a risk transfer, not a win.

For a live workflow, start with the queue you already have: open it, classify a sample, and triage by severity before designing anything. A first sort can turn up items that could not wait, such as an aged compliance notice. If exceptions are scattered across email and chat, build the sample from complaints, reversals, and the cases the people who fix them remember. As a planning estimate, a first sort takes a few working days for the workflow owner and the people who work the queue.

Then make the standard binding: a workflow is automated when its exception path is designed, staffed, measured, and rehearsed. Not when its happy path demonstrates throughput. A team that cannot show the taxonomy, the containment test, the context package, the owners, and the rehearsed recovery has a demo with an inbox.

The white paper works through all six parts with their typical failures, the readiness review, the objections and limits, including what the evidence does not show, the build sequence for live workflows, and what the work costs.