The happy path illusion

Every process map shows a happy path: the clean, linear flow from start to finish where everything works as designed.

Happy paths are great for onboarding slides and vendor demos. They're terrible for understanding actual operations.

Real operations live in the exceptions.

Why exceptions dominate operational reality

In most workflows, the "standard" case happens less often than expected:

  • Customer requests don't match the predefined categories
  • Data arrives incomplete, late, or in the wrong format
  • Approvals get stuck because the approver is unavailable
  • Upstream systems behave unexpectedly
  • Business rules have exceptions that weren't documented

Teams spend enormous energy handling these exceptions—often more than they spend on the happy path.

The cost of unmanaged exceptions

When exceptions aren't managed systematically:

  • Inconsistency — Different people handle the same exception differently
  • Delays — Work waits while someone figures out what to do
  • Tribal knowledge — Exception handling becomes expertise that lives in people's heads
  • Automation resistance — "We can't automate this—too many exceptions"
  • Team burnout — Handling constant exceptions is exhausting

Exceptions aren't bugs in the process. They're features of operational reality that need to be designed for.

The 80/20 myth

Organizations often plan for the "80% case" and treat exceptions as rare. In reality, that 20% of exceptions often consumes 80% of operational effort. Ignoring exceptions in process design is ignoring where the actual work happens.

How to design for exceptions

  1. Map exception patterns — What actually happens when the standard path doesn't apply?
  2. Categorize by frequency — Which exceptions are truly rare vs. routinely "rare"?
  3. Create explicit rules — When X happens, do Y—not "use judgment"
  4. Assign ownership — Who's responsible for handling each exception type?
  5. Build escalation paths — When rules don't cover it, where does work go?

This isn't overcomplicating the process—it's aligning the process with reality.

Why automation fails on exceptions

Automation works on the happy path because the happy path has clear rules.

Automation fails on exceptions because:

  • Exception rules weren't defined before automation
  • The automation can't tell the difference between "standard" and "exception"
  • No one planned what happens when automation encounters something unexpected

The result: automation handles happy paths, humans handle exceptions, and the human workload doesn't actually decrease.

Stable automation requires stable exception handling first.

The stability principle

A workflow is stable when exceptions are as well-managed as the happy path. Not eliminated—managed.

Exception management means:

  • Knowing what exceptions exist
  • Having rules for the common ones
  • Having ownership for the uncommon ones
  • Having escalation paths for the truly novel ones

Master the edges, and the center takes care of itself.