Designing for the Ten Percent of Cases That Break Your Workflow

Ninety percent of the requests move through the workflow exactly as designed — clean input, standard steps, predictable output. The remaining ten percent don’t fit any of the defined paths, and the workflow has nothing to say about what happens to them, because it was built around the typical case and the atypical ones simply weren’t part of the design conversation. So those cases get handled through email threads, side conversations, and whatever the most experienced person on the team happens to remember from the last time something similar came up. It works, in the sense that the case eventually gets resolved. It works badly, in the sense that it’s undocumented, inconsistent, and entirely dependent on whoever happens to catch it.

This gap is worth taking seriously because the exceptions aren’t a rounding error — they’re often disproportionately the cases that matter most. A workflow built entirely for the routine case implicitly assumes the irregular ten percent isn’t worth designing for, but that ten percent frequently includes the highest-value customers, the highest-risk situations, or the cases where getting it wrong actually costs something. Optimizing the workflow purely for the common case while leaving the uncommon case to informal handling means the least-designed part of the process is handling some of its highest-stakes work.

Why the Exception Path Gets Skipped During Design

Designing a workflow for the typical case is genuinely easier and produces a clean, presentable process diagram. Designing for every conceivable exception up front is neither realistic nor a good use of time, because most exceptions are rare enough, individually, that building a dedicated path for each one would be wasted effort relative to how often it would actually get used. This is a reasonable trade-off in principle. The mistake isn’t skipping detailed exception paths during initial design — it’s failing to build any general mechanism at all for what happens when a case clearly doesn’t fit, leaving a total void rather than a deliberately lightweight fallback.

The Difference Between No Exception Path and a Deliberate One

A workflow without any exception handling doesn’t actually prevent exceptions from happening — it just means exceptions get handled entirely outside the system, informally, by whoever’s available and willing to take it on. A workflow with a deliberate, even minimal, exception path gives those same cases somewhere legitimate to go: a defined route to a specific person with the authority and context to handle non-standard cases, along with an expectation that the resolution gets logged somewhere the rest of the team can see, rather than existing only in one person’s memory and a scattered email thread.

Approach to exceptions	What happens in practice
No exception path defined	Handled ad hoc, undocumented, inconsistent
Generic “escalate to manager” catch-all	Slightly better, but often overloads one person with everything unusual
Defined exception path with clear ownership	Consistent handling, some documentation, sustainable over time
Common exception types identified and given mini-paths	Best coverage, but requires ongoing investment as patterns emerge

Identifying Which Exceptions Are Actually Common Enough to Deserve a Path

Not every exception needs its own dedicated sub-workflow — some genuinely are one-off oddities that a general escalation path handles fine. But if a team looks back at the last several months of exceptions and finds the same handful of patterns recurring — a particular kind of customer request, a specific data quality issue, a certain regulatory situation — those patterns have effectively graduated from true exceptions into a second, less common but still recognizable case type that deserves its own defined path, even a lightweight one, rather than continuing to be routed through the generic catch-all indefinitely.

Logging Exception Handling Even When It’s Improvised

For genuinely novel exceptions that don’t yet warrant a dedicated path, the single highest-value habit is simply logging how they got resolved, even informally. This serves two purposes: it builds a record that makes the next similar exception easier to handle, since someone can look up how a comparable case was resolved before rather than starting from scratch, and it creates the raw material needed to eventually identify which exceptions are common enough to deserve formal paths of their own, which is much harder to do if past resolutions were never recorded anywhere.

Giving the Exception Handler Real Authority, Not Just Responsibility

A defined exception path fails if the person it routes to doesn’t actually have the authority to resolve what lands in front of them. A common design mistake is naming an exception handler who then has to escalate most cases further anyway, because the workflow gave them responsibility for exceptions without the actual decision-making power those exceptions usually require. This just adds a step without adding resolution capability, and it’s worth checking, honestly, whether the person or role designated to handle exceptions genuinely can close most of them, or whether the path just relocates the bottleneck by one hop without actually shortening it.

Watching for Exception Volume Creeping Above the Ten Percent

A workflow’s exception rate is itself a useful piece of information about whether the underlying process still matches reality. If the share of cases falling outside the standard path starts climbing — from ten percent toward twenty or thirty — that’s usually a sign the “typical case” the workflow was designed around has shifted, and what used to be the common path may no longer actually represent most of the real volume. At that point the right response often isn’t a bigger exception path — it’s redesigning the core workflow itself to reflect what’s actually typical now.

Building the Exception Path Into the Original Design, Not as an Afterthought

The workflows that handle irregular cases best aren’t the ones that anticipated every possible exception in advance — that’s neither possible nor efficient. They’re the ones that built a deliberate, lightweight fallback mechanism into the original design from the start: a clear route, a person with real authority, and a habit of logging what happened. That small amount of upfront structure is what separates a workflow that degrades gracefully when reality doesn’t match the diagram from one where the exceptions simply fall through the cracks and get absorbed, invisibly and inconsistently, by whoever happens to be standing nearby when the case lands.