ON THIS PAGE · 5 SECTIONS▾
Picture a typical success story. An automation goes live to process incoming orders. It handles the great majority without any help, the team is delighted, and the weekly hours saved look impressive. Six months later, a customer complains that their order never arrived. Someone goes looking and finds a queue of a few hundred items, some of them months old, that the automation set aside because they didn't fit. Nobody was watching it. Nobody was sure whose job it was.
This is one of the most common ways automation projects go wrong, and it has nothing to do with the clever part. The automation did exactly what it was designed to do. The failure was in what happened to the work it couldn't do.
01#Every automation creates exceptions
No real process is perfectly uniform. Orders arrive with a missing reference. Invoices don't match their purchase orders by a few cents. A customer's name is spelled differently in two systems. A form is filled in with the answer in the wrong field. Before automation, a person handled these as part of their normal work, often without noticing they were exceptions at all.
Automation separates the routine from the unusual. The routine items flow through untouched. The unusual ones need somewhere to go. If you don't design that somewhere deliberately, you get a default: a folder, a status flag, an error log, or an email to a shared inbox. Defaults have no owner.
The share is small; the impact isn't
The exceptions are usually a small fraction of total volume, which is why they are easy to overlook. But they are disproportionately important. They are the items where something has already gone a little wrong, and they are often the customers or suppliers most likely to complain. An order that silently waits for three months does more damage to trust than a hundred orders processed a few minutes faster.
Exceptions pile up faster than people expect
A small fraction of a large volume is still a lot of items. And unlike the routine work, exceptions don't clear themselves. If the queue grows by a dozen items a day and nobody works it, after a quarter you have a backlog that takes a week to clear and contains problems that are now much harder to fix.
02#Design the exception path first
When planning an automation, most teams start with the happy path: what happens when everything is correct. We find it more useful to start with the question "what happens when it isn't?" For every step where the automation might not be able to proceed, decide four things.
Where the item goes
A single, visible queue, in a tool the owning team already uses every day. Not a log file, not a folder on a server, not a separate dashboard nobody opens. If the team works in a ticketing system, exceptions become tickets. If they work from a shared inbox, exceptions arrive there with a clear subject line.
Who owns it
A named team or role, written down, with a backup. "Accounts payable owns unmatched invoices; the team lead covers when they're away." Not "operations", not "whoever sees it first".
How quickly it must be handled
A deadline appropriate to the cost of delay. Perhaps a day for a customer order, a week for a supplier record with a typo. The deadline makes the queue manageable: anything past it is a problem to escalate, not just a number.
Why it was set aside
The automation should say, in plain language, what it couldn't do and why. "Order total is €12.40 higher than the quote; no approval found." A person reading that can act in seconds. A person reading "Error code 47" has to investigate first, and the queue gets slower.
03#Watch the queue, not just the automation
Most automation dashboards report the success rate: the share of items handled automatically. That number is useful, but it can look healthy while the exceptions quietly rot. Add three more measures, and look at them every week:
- Queue size. How many exceptions are waiting right now.
- Oldest item. How long the oldest exception has been waiting. This is the single best early warning: if it starts creeping up, the queue is not being worked.
- Past deadline. How many items have missed their deadline, with an alert to the owner's lead when the count rises above zero.
None of these are hard to build. They are just easy to forget, because they measure the part of the system that nobody was excited about.
04#Close the loop
The exception queue is also the best source of improvements you will ever have. Every exception is a small piece of evidence about how the real process differs from the one you designed for.
Once a month, look at the exceptions by reason. Some will reveal a missing rule that can be added safely: the same small rounding difference, approved by hand every time, can become an automatic tolerance. Some will reveal a problem upstream: a supplier who always sends the wrong reference, which is better fixed by talking to the supplier than by more code. Some will remain genuinely unusual, and that is fine. They are exactly the cases a person should be looking at.
Over time, the queue shrinks, not because anyone is ignoring it, but because each recurring reason has been dealt with at its source.
05#A simple test before go-live
Before any automation goes live, ask these questions out loud:
- When this can't handle an item, where does the item go?
- Who is responsible for it, by name or role?
- How soon must it be dealt with?
- How would we know if the queue was being ignored?
If any of the answers is "we'll sort that out later", the automation isn't ready.
Automate the routine. Own the exceptions. Do both from day one.
The routine work is where automation saves time. The exceptions are where it keeps, or loses, the trust of your customers and your team.