Name the exception before you automate the happy path.

The clean path is not the hard part

Most automation plans begin with the ordinary case. An order arrives with complete information. A request matches a known template. A status update can be trusted. The sequence looks short on a whiteboard, so the team builds that path first and promises to handle the unusual cases later.

Later arrives quickly. Duplicate references, missing fields, conflicting statuses and corrections after the process has started are not rare edge cases. They are the work someone already absorbs with judgment. When automation only covers the clean sequence, those people still do the connecting—only now they also have to notice when the new path silently skipped them.

A useful design question is not “how do we automate the happy path?” It is “what happens when this item cannot follow the ordinary route?” Answer that with an owner, evidence and a recovery step before you wire the rest. The happy path will still matter. It simply should not be the only path you design.

Teams skip this step for understandable reasons. The clean path is easier to demo, easier to estimate and easier to celebrate. Exception design looks like delay. In practice it is the opposite: it prevents a release that only works when nothing unusual happens.

Find the judgment that already keeps things moving

Sit with the person who resolves the awkward cases. Ask what first signaled the problem, what they needed to know, and what they could safely decide. You are looking for the judgment the system currently lacks: which field to trust, who to ask, whether to pause or proceed, and how to leave a record of what changed.

Write those answers down as operating facts, not as software features. Who becomes responsible when the normal path fails? What context must travel with the item so that person can act without reconstructing the story from chat history? How does anyone else see whether the issue is waiting, being handled or resolved?

This observation often reveals that the “exception” is already a process. It simply lives in someone’s head. Encoding the happy path without that knowledge creates a fast route for ordinary work and an invisible backlog for everything else. The people who currently catch those cases will still catch them—unless the new system gives them a clearer place to stand.

Capture a few concrete examples while you are there. A duplicate reference. A missing required field. A status that usually means one thing and occasionally means another. Those examples become test cases later. Without them, “exception handling” remains an abstract checkbox.

Name owner, evidence and recovery

Treat the exception path as a first-class design. Three decisions make it usable.

Owner. One role can accept the item and is expected to resolve it or escalate it. “The operations team will notice” is not ownership. A named queue, inbox or assignment that someone monitors is. If two teams both assume the other owns the unusual case, the item waits.

Evidence. Carry the record the owner needs: the original request, the fields that failed validation, the last successful step, relevant history and any human notes. A notification without that context only creates another handoff. Prefer one coherent packet over a trail of partial messages.

Recovery. Define how the item returns to a known state—retry after a correction, cancel and restart, or continue with an explicit override that is attributed and timestamped. Decide what happens when a connected system is unavailable. Separate retries that are safe from actions whose outcome must be checked first.

These decisions do not require a large platform. They require clarity about responsibility and state. On Sutton|Place, TWIMCO kept supplied assertions distinct from verification results and made disclosure an explicit action with an actor and timestamp. The same discipline applies to exception work: unusual cases stay inspectable instead of disappearing into an inbox. A pending check is not a confirmation. An override is not an invisible edit.

Wire the happy path after the exception has a home

Once the exception path is named, the clean sequence becomes easier to automate honestly. You know where incomplete work goes. You know who owns it. You know what “done” means for both routes.

Build the ordinary path with the same observability. Show whether an item completed, waited for a person or failed in a defined way. Prefer a small, testable boundary—“when routing fails, gather context and assign review”—over a vague ambition to automate an entire department. A bounded first path is easier to trust and easier to revise.

Work through real examples with the team: duplicates, missing information, a correction mid-process and a temporary outage. Include the case where two systems disagree. If people cannot tell whether the automation handled the item or abandoned it, the happy path is not ready, no matter how clean the demo looks.

Resist the urge to hide exceptions behind a generic “failed” status. Failure without a next owner is just a quieter form of the original problem.

When you do wire the happy path, keep the exception route in the same operational language. Use the same notions of waiting, assigned and resolved. People should not have to learn one vocabulary for success and another for trouble.

A practical check before you build

Pick one recent exception and walk it with the person who fixed it. Write the owner, the evidence they used and the recovery they chose. Ask whether that path would still work if they were on leave. If the answer depends on tribal knowledge, you have found design work that belongs before the automation, not after it.

Then ask a second question: if the automation takes the ordinary cases, does the remaining work still land somewhere visible? Teams sometimes automate the easy volume and leave the hard volume without a queue, a schedule or a named reviewer. That is not a successful first release. It is a transfer of burden.

The goal is not to eliminate judgment. It is to make judgment reachable: the right person sees the right context, and the record shows what happened next.

Share the written exception path with whoever will live with the automation after launch. If they cannot recognize their own judgment in it, revise until they can. Automation that ignores the people who currently hold the process will not earn their trust.

Put this into practice

TWIMCO’s work on Sutton|Place began with distinctions the business relies on—who supplied information, who checked it and who may decide—and continues as further operating problems emerge. If you are scoping a first automation, start by naming the exception path, then explore business automation with that design in hand. Bring the awkward cases to the conversation early. They are usually the clearest guide to what the system must protect.