Where Automation Stops and People Start

The instinct with automation is to aim for complete coverage — handle every case, remove the person entirely. It's usually the wrong target.

A process that handles 85% of cases cleanly and routes the rest to a person is better than one that attempts 100% and mangles the hard cases. The hard cases are where the money, the relationships and the risk are.

The design question isn't how much you can automate. It's where the handoff goes and what happens there.

Design the exception path first

Most automation is built happy-path first, with exception handling bolted on when something breaks in week three. Invert it.

Before building, list what can go wrong at each step:

• Input missing or malformed
• A value outside the expected range
• The external system is down or slow
• A duplicate
• A case the rules genuinely don't cover
• Something that looks fine but isn't — the dangerous category

Then decide, for each: stop and escalate, or continue with a default?

The bias should be strongly toward stopping. Continuing on a guess is how automations produce output that's wrong in ways nobody notices for a month.

Fail loudly, and stop

The worst behaviour an automation can have is to continue past something it didn't understand.

| Behaviour | Result | |---|---| | Stops and alerts | Someone handles it. Best case. | | Stops silently | Work queues up invisibly. Bad. | | Continues with a default | Confidently wrong output. Worst. | | Retries forever | Looks fine, does nothing. Also worst. |

Where an automation cannot proceed correctly, it must stop and say so — to a person, in a place they'll see, with enough context to act.

An error message that says "workflow failed" is nearly useless. One that says which record, which step, and what was unexpected is actionable.

The exception has to land somewhere

This is where most exception handling actually fails. Not in detection — in what happens next.

An exception needs:

• A destination. A queue, an inbox, a channel. Somewhere specific.
• An owner. A named person, not "the team."
• A deadline. How long can this sit before it's a problem?
• Enough context to act. Which record, what happened, what the automation expected.

An exception queue nobody watches is the same as no exception handling at all — worse, because everyone believes the case was handled.

Put a check on the queue itself. If exceptions sit longer than their deadline, that's a signal, and it belongs in the weekly review alongside everything else that quietly drifts.

Assist rather than automate

The underused middle setting. Plenty of steps aren't fully automatable but can be reduced to a review:

• Draft, don't send. The automation prepares the reply; a person approves it.
• Calculate, don't decide. The system produces the number; a person decides what to do.
• Flag, don't act. Surface the anomaly; a person judges whether it matters.
• Pre-fill, don't submit. Everything is ready; a person confirms.

This converts twenty minutes of work into two, without removing judgement from a decision that needs it. For anything with real consequence — money leaving, a client seeing it, a commitment being made — assist is usually the right setting rather than full automation.

Track the exception rate

One number, reviewed monthly: what proportion of runs ended in an exception?

It tells you things nothing else does:

• Rising. The process changed underneath the automation, or an input source degraded. This is the early warning for automation debt.
• Very low, near zero. Either genuinely stable, or the automation is swallowing cases it should be escalating. Worth spot-checking a sample of "successful" runs.
• Consistently high. The process wasn't stable enough to automate. Consider going back to manual and re-mapping.

Some exceptions are signals

The most valuable output of an exception queue is the pattern in it.

If the same exception occurs repeatedly, it isn't an exception — it's an unhandled part of the process. Two options, and both are better than continuing to handle it by hand:

• Encode it. It's predictable enough to be a rule now.
• Change the process so it stops arising.

Review the queue monthly and ask what recurred. Handling the same exception manually forty times is the automation equivalent of not writing the SOP.

Keep people on the parts that need them

Four things that should stay with a person, however good the tooling gets:

• Judgement calls where the right answer depends on context you can't encode
• Anything relational — a person will notice they're talking to a template
• High-consequence irreversibles — money out, contracts, anything hard to undo
• The genuinely novel — by definition there's no rule for it yet

Automation is at its best doing the volume so that people have time for these. Aimed at replacing them, it produces a business that handles routine cases efficiently and important ones badly.

The mistakes

1. Happy path only. Breaks on the first variation.
2. Continuing on a default. Confidently wrong output.
3. An unwatched exception queue. Everyone assumes it was handled.
4. Unactionable errors. "Workflow failed" tells nobody anything.
5. Not tracking the rate. You miss the drift until something visible breaks.
6. Handling the same exception forever. It should have become a rule or a process change.

What to do next

Take your most important automation and answer three questions: what does it do when something is wrong, where does that land, and who is looking at it. If any answer is unclear, that's the gap — and it's the one most likely to cost you something.