Automation needs an exception path.
A workflow is not reliable because it can process the standard case quickly. It is reliable because it knows what to do when the case is not standard.
This problem appears after a promising automation has moved beyond the demonstration.
A form sends new leads into a CRM. An AI tool classifies requests and drafts a response. A publishing system turns approved source material into several formats. An order triggers confirmation, fulfillment, and reporting. The common cases move without much attention.
Then something does not fit.
The form arrives without a company name. The request includes a legal question. Two customer records appear to describe the same person. The approved source contradicts the current website. An order contains a combination the fulfillment system cannot handle.
The automation keeps moving because moving is what it was built to do.
That is where quiet damage begins.
Teams usually get automation wrong by designing the happy path in detail and treating every other case as an error to be cleaned up later.
The diagram looks convincing. Information enters on the left, passes through a neat sequence of steps, and produces an outcome on the right. Each step removes manual effort. The business case counts the minutes saved when everything works.
Real work is less orderly.
Inputs are incomplete. Policies conflict. Customers change their minds. A source becomes outdated. A request crosses a boundary that was obvious to an experienced employee but invisible to the system.
These are not rare technical failures. They are part of the job.
When the workflow has no defined response, one of two things happens. The system makes a decision it should not make, or a person discovers the problem somewhere downstream and repairs it by hand.
The first outcome creates risk. The second creates hidden labor.
Neither appears in the original automation estimate.
The better way to think about automation is as a bounded operating system.
It should have a clear job, a clear definition of the cases it can handle, and a clear way to stop when those conditions are not met. The exception path is not evidence that the automation failed. It is evidence that the team understood the work.
A useful exception path answers four questions.
First, what should cause the system to stop?
The trigger might be missing information, low confidence, conflicting records, a sensitive topic, an unusual dollar amount, or a request that falls outside an approved policy. The rule needs to be specific enough for the system to act on it.
“Send difficult cases to a person” is not a rule. “Pause any response that cites an unapproved source or includes a customer commitment” is closer.
Second, where does the case go?
An exception should not disappear into a general inbox or become another unowned notification. It needs a visible destination, a named role, and enough context for that person to make the next decision.
That may be a review queue, a service ticket, a content editor, an account owner, or a subject expert. The right destination depends on the consequence of getting the case wrong.
Third, what evidence travels with it?
A person should not have to reconstruct the entire workflow to understand why it stopped. The exception should include the original input, the rule that was triggered, the relevant source material, what the system already did, and the decision now required.
Without that evidence, escalation merely moves the confusion.
Fourth, how does the workflow resume?
Some cases should return to the automated path after correction. Others should be completed manually. A few should stay outside the system because they require judgment every time.
That decision matters. If every exception becomes a new feature request, the workflow will grow until its rules are harder to understand than the process it replaced.
Taste applies to operational systems too. Good design is visible in what the system refuses to do.
This is especially important when AI is involved. A conventional rule can often fail loudly: a required field is empty, an integration returns an error, or a value falls outside a known range. AI can produce a plausible answer even when the source is weak, the request is ambiguous, or the task exceeds its role.
Fluency is not a stop condition.
The team has to define one.
That does not mean every output needs approval. It means review should match consequence. A low-risk internal summary may continue with a visible uncertainty note. A public claim, pricing decision, employment answer, or customer commitment may need a person before it moves.
The goal is not to eliminate exceptions. It is to make them legible.
Once exceptions are visible, they also become useful evidence. A recurring missing field may point to a poor form. Repeated source conflicts may reveal weak content ownership. A crowded review queue may show that the automation’s job is too broad. A category that never needs intervention may be ready for less oversight.
The exception path helps the team improve the system without pretending the work is simpler than it is.
The practical next step is to take one active automation and list the five cases most likely to require judgment.
For each case, name the stop condition, the owner, the evidence they need, and the way work resumes. Then test those cases on purpose.
If the only documented path is the one where every input is complete and every decision is obvious, the workflow is not finished.
The fix is not more automation. It is a designed way out.