Designing the Exception Path

Every workflow design I have ever been handed opens with the clean case: the invoice arrives complete, the entity submits on time, the statement ties, the model classifies it correctly and the record moves on. That path gets the diagram, the demo and most of the build effort. It is also the path that was never expensive.

The other case is where enterprise work actually lives. The submission that never arrived. The line nobody can map. The two systems that disagree. The item that is entirely valid but larger than anyone in the room may approve. In eighteen years of finance and treasury systems I have never seen a process where the straight-through volume was the problem, and rarely seen a design document give the other volume more than a paragraph.

The exception path is not the edge of the workflow. It is the workflow.

The clean case is the smallest part of the build

There is a structural reason for this, and it is not carelessness. The clean case can be specified in advance — it is what the process owner describes when asked how the work runs. The exception path cannot, because the people doing the work have absorbed it: the chasing, the workaround, the spreadsheet, the colleague who knows which of the two systems is usually right. None of that is written down, so a design built from interviews reproduces the clean case faithfully and inherits the rest by accident. AI sharpens the asymmetry, because a model handles the ordinary case impressively on the first attempt and makes a pilot look finished long before it is — one of the reliable reasons pilots stall short of running the work.

How an item becomes an exception

Detection is a design decision, not a side effect. There are five distinct ways an item leaves the happy path, and a design should say which ones it has.

Confidence below threshold. The model declines to commit, or commits weakly. This is the trigger everyone builds, and it has a limitation worth being honest about: it catches uncertainty, not error. The item the model gets wrong while sounding certain does not trip it.

Validation failure. A deterministic rule says no. It does not balance, the format is invalid, the code is not in the list, the date is out of range. The cheapest and most reliable exceptions you have, because they are certainties rather than estimates.

Missing evidence. Nothing arrived. This one is detected only by a clock — at a cut-off, against an expected list — which is why it is so often missed. Nothing raises an alert about a file that failed to turn up unless someone decided in advance that it was due.

Conflicting sources. Two systems disagree and both are internally valid. The most expensive class, because there is no error to find; there is a reconciliation to perform and a judgement about which source governs.

Policy limit. Nothing is wrong with the item at all. It exceeds a threshold, sits outside a tolerance, or involves a counterparty seen for the first time. Not a failure — a decision that must be taken by someone holding the right to take it, which is the matrix in human decision rights doing its job.

One of these is probabilistic and four are deterministic. A design that considers only the first has built an exception path for the component it just added, and left the process's real exceptions to be found in production.

And an exception is a state, not a message. A failure that produces a log line or an email has not been detected in any useful sense — it has been announced. Detection creates a record, and everything below depends on that record existing.

The queue is a real object with real fields

A queue is not a filter over a table. It is a first-class part of the system, and it holds more than most designs give it.

An owner who is a person. Not a team, not a mailbox, not a role eleven people share. Assign by exception class, so the person routinely handling unmappable lines is the one who gets good at them.

An age. Exceptions do not resolve themselves; they get old. A queue showing a count but not an age is hiding its own failure — twelve items open looks identical whether the oldest is an hour or a quarter.

A priority derived from risk and deadline, not arrival order. First in, first out feels fair and produces the wrong sequence: it treats a small mapping query and a break in a funding position as peers.

A service level per class. A single blanket target is either too slow for the urgent exceptions or unachievable for the hard ones.

A capacity. The field nobody puts on the design, and it decides everything. If exceptions arrive faster than they are cleared, no interface improvement rescues the queue — the backlog grows until someone declares an amnesty.

The anti-pattern is everywhere: exceptions routed to a shared mailbox. Email has no ownership, no ageing, no priority and no shared view, so the queue's true state lives in the head of whoever reads it most often. That is the same argument as everything else about the state a workflow has to hold — the work has to be resumable by someone who was not there yesterday.

Escalation has to change something

Escalation is not sending the same problem to a larger audience. It has two triggers, and both should fire automatically. Time: the item has aged past its service level, so ownership moves. Authority: resolving it needs a right the current owner does not hold — a write-off, a tolerance override, a payment above their limit — so it moves to someone who does. That second trigger is where the exception path and the decision-rights matrix meet, and where a queue quietly becomes part of the control environment.

Whichever fires, escalation must change who owns the item or what may be decided about it. If it only adds recipients, it is a status report with an urgent subject line.

The other end of the queue is skipped almost universally: the terminal state. Some items will never be resolved, and there has to be an authorised way to close them — accepted with a reason, written off, closed unresolved with a named owner. Without one, the tail of the queue becomes a permanent shadow backlog everybody has learned to scroll past.

What the person resolving it needs to see

The measurement that matters here is touches per exception, and the target is one. Every additional touch is a person rebuilding context they should have been handed.

So the screen carries, in one place: the item and its source evidence; the specific reason it stopped; the assembled context — related documents, prior correspondence, the master data involved; similar past cases and what was decided about them; the actions available and what each one does; and somewhere for the reason to be recorded.

"The specific reason" deserves emphasis, because it is where AI-era queues fail in a new way. A confidence score is not a reason. "Low confidence, 0.41" tells the resolver a component was unsure and nothing about what to do. "The remittance names an entity that is not in the mapping table" tells them what happened and what would fix it. Translating the first into the second is a design obligation.

This is also where a model earns most of its keep — not deciding, but assembling. Gathering the documents, correspondence and prior cases around a broken item is exactly the reading-and-synthesising work models are good at, and exactly the work that consumes a specialist's afternoon today. The cash-forecasting teardown shows it on a real process: five classes, each with its own detection, route and resolution.

Resolution needs a shape

A resolution is a decision, and decisions have a structure: what was decided, on what basis, by whom, and what now happens to the item — reprocessed, corrected at source, overridden with a reason, rejected, or closed. Record the action as a code from a fixed list, chosen to be analysable later, and the reason separately in a sentence. Free text alone is where learning goes to die: fine for nuance, useless for pattern, and after a year you have a mountain of comments and no idea which class costs the most.

Write-back is what stops the queue being permanent

This is the part almost always missing, and it decides whether the exception path shrinks over time or becomes a permanent staffing line. Every resolution should be capable of producing one of four things.

A fix at source. The mapping now exists, the master data is corrected, the bank detail is registered. That item can never raise this exception again.

A rule. The pattern is now understood well enough to be deterministic, so the next occurrence never becomes an exception at all. The best outcome available and the most under-used: a good exception path is a machine for discovering rules nobody had written down.

A reference example. For classes that stay genuinely judgemental, the resolved case becomes context for the next similar one, so the assembly improves even where the decision cannot be automated.

An upstream change. The uncomfortable one, and often the largest. Many exceptions are caused before the workflow begins: a form field never made mandatory, a template two regions never agreed, a supplier who sends PDFs because nobody asked otherwise. Fixing those removes the exception rather than processing it faster.

A resolution that produces none of the four is a mark against the design, not the person. It means an indistinguishable item arrives again next month and costs the same.

"

Every exception you resolve without changing anything is one you have agreed to resolve again, for as long as the process exists.

Track the class mix, not only the total. A flat rate can hide real progress — one class eliminated while volume grew — and equally the opposite, where the easy class was fixed and a harder one expanded underneath it.

An exception rate is a measurement, not a feeling

Ask a room what proportion of items go straight through and you will get a number. Ask where it came from and you will get a pause. The estimate is almost always optimistic, because the people answering describe the process as designed while the exceptions live in the workarounds around it.

Define it before measuring: exceptions raised per item processed, by class, over real volume, across a period long enough to include a month end — period ends are when the volume and the awkwardness both peak. Most processes can be measured today, without building anything, because the current way of working already produces exceptions. They are just called chasing, rework, or Friday's list.

Then hold three numbers rather than one. The rate — what share of items stop. The cost — average effort to clear one, by class, since a rare exception taking two days can outweigh a common one taking two minutes. The tail — the age of the oldest unresolved item, which tells you whether the queue is a process or a pile.

Those numbers are load-bearing well beyond the queue. They set the staffing and the service level you can promise. They determine whether a step can defensibly run with autonomy rather than as augmentation, since a long tail of odd cases is an augmentation design more or less forever. And they decide whether the business case is real: a redesign that halves touch time on the clean case while leaving a fifth of items queued has not changed the economics of anything.

Which leads to the sentence I would put on the front of any AI workflow design: a design that cannot state its expected exception rate is not finished. Not wrong, not unambitious — unfinished, the way a building with no drainage is unfinished.

Design it first, not last

The instruction is simple and it inverts the usual order. Take the design, walk through each step, and for every one ask what happens when it does not work. If the answer is "it goes to the team", the step has no exception path — it has a hope.

Name the detection, the queue, the owner, the clock, the escalation, the resolution codes and the write-back, and do it before the clean case is built. The clean case will be built anyway, and at a fraction of the effort. More of this method sits in the AI workflow design notes.

Something else follows from getting it right, worth wanting for its own sake: the specialists stop spending their days on assembly and start spending them on the handful of items each week that genuinely need a person who knows what they are looking at. That is the whole argument for redesigning enterprise work around AI, and it lives in the queue rather than in the demo.

See also the cash-forecasting teardown and human decision rights in AI-native workflows.