Automations are usually built in the order they are imagined: make the normal case work, ship it, deal with the awkward cases when they turn up. That order is backwards, and you can see it in every workflow that quietly stopped being trusted.
The normal case is not where the risk lives. It is high volume and low consequence — if it breaks, it breaks visibly and often, so somebody fixes it that week.
The happy path is the easy part
A small share of cases will be ones the workflow cannot decide: an unusual discount, an address that does not validate, a customer who is both a supplier, an order for something discontinued last quarter. Individually rare, collectively certain.
These are also, reliably, the cases that matter most. An awkward order is awkward because something about that customer or that deal is unusual, and unusual things tend to be the ones people notice being handled badly.
Design the exception first
Decide, before anything is built, what happens when the workflow cannot proceed. Who receives it. What arrives with it. Whether the customer is told anything in the meantime. How the person hands it back once resolved.
That decision shapes the rest of the build: what gets logged, how much context travels with a record, whether steps are reversible, and where the workflow is allowed to pause rather than fail. Retrofitting it means rewriting most of that.
A shared mailbox nobody owns is where exceptions go to age. Name the role that receives them and make it visible when one is waiting.
The original message, what the workflow already worked out, and one line saying what it could not determine. If the person has to go and reconstruct the case, the automation has moved work rather than removed it.
Once the person decides, the workflow should pick the case up and finish it. Exceptions that end in someone doing the whole job by hand are how a workflow becomes shelfware.
Silence is the failure mode
A manual process fails loudly: somebody is holding the thing that will not go through, and they say so. An automated one fails silently by default. Nothing is on anybody's desk, so nothing is escalated, and the first anyone hears is a customer asking where something is.
An automation that never asks for help is not confident. It is hiding something.
So make the exception rate a number somebody looks at weekly. If it drops to zero, that is not a triumph — it usually means cases are being forced down the happy path when they should not be. A steady, small, visible exception rate is the sign of an automation working exactly as designed.
