The automation handles most of it. Who handles the rest?
Automation is sold on the ordinary case. Eight orders in ten go through without anyone touching them, and that is a real gain.
The interesting question is the other two. The order with a note in the comments field. The customer whose address will not validate. The booking made for a service you stopped offering. These do not stop existing because the workflow could not handle them. They go somewhere, and in most small businesses nobody has decided where.
Three places the leftovers can land
Somebody's inbox. The workflow emails an error and a person deals with it. This is the good case, as long as it is one named person rather than a shared address that everyone assumes someone else is reading.
A queue nobody opens. The platform keeps a list of failed runs. It exists, it is accurate, and the last time anyone looked at it was during setup.
Nowhere. The run stops, the record is neither processed nor kept anywhere you would find it, and the only trace is that something a customer expected never happened.
The third is more common than people think, and it can be the default.
The safety net that ships switched off
Make has a feature called incomplete executions. When a scenario hits an error, the unfinished run is stored so it can be retried or resolved later — a protection against losing the work that was in flight.
Its documentation states: "Incomplete executions are disabled by default."
Read that with a real workflow in mind. Unless somebody went into the scenario settings and turned it on, a run that fails partway does not queue up anywhere to be dealt with. The order that failed to sync is not waiting in a tray. There is no tray.
The documentation also notes that storage for incomplete executions is bounded by your plan's allowance, and that exceeding it produces an error — so even with the net switched on, it is a net with a size. Both facts point the same way: the leftovers need somebody to look at them, promptly, rather than accumulating until the platform objects.
That is one vendor's design, not a universal one. But it is the right question to ask of whatever you use: when a run fails halfway, what happens to the thing it was carrying — and did anyone choose that answer?
The exceptions are not random
Owners tend to picture the leftover pile as chaos. It is usually four or five recurring situations, and once written down they stop being surprises.
Look at what actually shows up: the record missing a field the automation requires. The customer who exists twice. The order edited after it was placed. The unusual-but-legitimate case — the corporate booking, the split payment, the delivery to a different country. And the reverse, where the automation succeeds and should not have: a refund processed for an order that was already refunded by hand.
That last category deserves attention because it never appears in an error queue. Nothing failed. The workflow did exactly what it was told about a situation nobody thought to describe.
Making the leftovers a list
Decide who owns them, by name. Not a role, not a shared mailbox. One person, with a stated expectation of how often they look — daily for anything customer-facing.
Find out where they currently go. For each important automation: what happens when it fails? If the answer is "I do not know", that is the answer, and it means nowhere.
Turn on whatever your platform offers, then test it. Enable the failure queue, then deliberately break one run and confirm it appears where you expect. A safety feature nobody has tested is a belief, not a net.
Write down the four or five recurring exceptions, with what to do about each. This is the difference between an exception costing five minutes and costing an interruption plus a decision.
Count them monthly. The number matters more than any individual case. Twenty a month is a process working normally; two hundred means the automation is mis-specified, and you are staffing around a design problem.
When the pile is telling you something
A rising exception count is not a staffing problem, it is a design signal.
If a fifth of your orders land in the leftovers, the rule is wrong: the cases you called exceptional are ordinary and the workflow should handle them. If the same exception recurs every week, it is not an exception at all, it is an unimplemented branch. If exceptions cluster around one customer type, that customer type was never in the design.
The useful discipline is to read the pile as feedback rather than as work. Every recurring item is either something to automate properly or something to declare out of scope on purpose — and the second is a legitimate answer, as long as somebody made the decision.
When this needs more than a queue
For one or two workflows, a named owner and a written list of the common cases is the whole solution.
It gets harder when automations chain, because a failure in step two leaves steps three and four in an undefined state: the invoice exists, the stock does not, the customer got the confirmation. Then the exception is not one record needing attention, it is a partial transaction that has to be finished or unwound by hand, and doing that safely means knowing what each step already did.
Working out where your chains can stop halfway, and what it takes to finish or reverse them, is one of the things a process audit covers: $299, three business days, and a list of what your automation currently hands back to you.
Related: why automations fail silently, and how to make them speak up covers the reporting side — whether anyone is told at all. This one is about what happens to the work itself.