Design the Exception Path Before It Designs Itself

Every process documentation effort produces the same artifact: a clean diagram of how work flows when everything goes right. Order in, steps in sequence, result out. The happy path.

Then reality arrives. The customer who wants to change the order after submission. The payment that fails. The application with a name mismatch. The delivery to an address that does not exist in the carrier's system. None of these are on the diagram. All of them landed on someone's desk this week.

The happy path is not where operations get expensive. The exceptions are. And in most businesses, the exception path was never designed — it grew, one improvisation at a time, into a tangle that only two people understand.

Exceptions Are a Volume Class, Not an Accident#

The word exception suggests rarity. The numbers say otherwise. In the operations we map, somewhere between 15 and 30 percent of cases deviate from the standard flow in a way that requires a decision. That is not an edge case. That is a second product line.

The cost asymmetry is what makes it dangerous. A standard case might take 20 minutes of handling across its life. An exception case takes the same 20 minutes plus a diagnosis, a judgment call, often an internal conversation, sometimes a customer apology. Three to five times the handling cost is typical. Multiply by a quarter of your volume and the conclusion is plain: the undesigned part of your process is consuming more capacity than the designed part.

There is a second-order cost too. Exceptions interrupt. They arrive mid-task, demand attention, and force context switches on your most experienced people — because improvised decisions migrate to whoever has the most judgment. Your best people end up staffing the exception desk by default. That is exactly backwards from where you want their hours.

The Three Legitimate Routes#

Every recurring exception deserves one of exactly three fates.

1. Absorb it. If the exception is frequent enough, it is not an exception — it is an unacknowledged feature of your demand. Redesign the standard process to handle it natively. The rush order becomes a priority tier with its own rules and price.
2. Route it. Give it a designed variant: a defined trigger, a defined handler, a defined resolution. The payment failure gets an automatic retry, then a templated customer email, then a 5-day hold, then closure. Nobody improvises.
3. Refuse it. Some exceptions exist only because the business never said no. The order type you lose money on every time, the customization that breaks downstream steps. Refusal is a valid design decision, and it is kinder delivered at intake than discovered at delivery.

What is not on the list: handle it case by case. That is the default today, and it is the most expensive option in disguise, because it converts every occurrence into a fresh decision made by an interrupted person.

Build the Exception Register#

You do not need workflow software to start. You need a list. For one process, have the team log every deviation for two weeks — one line each: what happened, who handled it, how long it took, how it was resolved.

Two weeks of honest logging produces the agenda. The top three patterns by time consumed get a route decision — absorb, route, or refuse. The once-a-year oddities stay improvised, which is fine; improvisation is the right tool for genuinely rare events.

The Decision That Prevents Regrowth#

One more design element keeps the tangle from growing back: decide who owns new exceptions. When a never-seen-before case appears, the handler should know exactly two things — how to resolve this instance, and where to log it so the pattern gets a route if it repeats.

That single rule changes the trajectory of a process. Without it, every novel case quietly becomes precedent, and precedent becomes an unwritten rule that lives in one person's head. With it, the process has a feedback loop: reality teaches, the design responds.

The happy path will always be the smaller part of operational truth. Map it, yes. Then spend your real design effort where your real hours go.

“

An exception with a designed path is just another process. An exception without one is a fire drill that repeats forever.