Where the automation stops, somebody has to start

Picture a plant automating goods-in. Delivery notes and material certificates are read by a model, compared by code with the purchase order and the specification, and lots that match are released to stock without anybody touching them. The happy path is a few weeks of work.

Everything else is what happens when something does not match: a certificate value outside the specification, a quantity that differs from the order, a lot number the scan made unreadable. On most automation diagrams that branch is a single arrow labelled manual handling. In operation it is where the cost, the risk and most of the complaints live.

What a bad hand-off looks like

The raw case is dropped in a queue. The person gets the document and a status that says failed, and redoes the whole case from scratch. The automation saved nothing on precisely the cases that are expensive.

Nobody owns the queue. Exceptions land in a shared mailbox or on a dashboard. Each shift assumes another one is dealing with them, and the oldest item is older than anyone realises.

There is no safe state. The case is neither accepted nor rejected. The material sits on the dock or, worse, gets used, because nothing in the system blocked it.

The decision never comes back. The person resolves it directly in the ERP. The pipeline never learns what happened, the case stays open or is counted as a failure, and the same exception arrives again tomorrow.

What should land in front of the person

A hand-off is an interface, and it deserves the same design attention as anything a customer sees. The test is simple: can the person make the decision in the time it takes to read it?

Infographic

What a good hand-off contains

• The proposalWhat the system read and what it intended to do.
• Why it stoppedWhich check failed, and against which record.
• The evidenceThe document excerpt next to the value it was compared with.
• One questionA specific decision to make, not a case to redo.
• What is heldWhat stays blocked until somebody decides.
• Owner and deadlineWho has it, by when, and what happens if nobody acts.

The single question matters most. “Certificate value outside specification — accept under concession, quarantine or reject?” is a decision. “Goods-in failed for this delivery” is a job. Where a default can honestly be proposed, a good hand-off includes it with its reasoning, so that the person confirms or overrides rather than starting from nothing.

Who takes it when nobody is there

Automated processes run outside working hours, and so do their exceptions. For each class of exception, decide in advance which of three things happens when there is nobody to ask.

Wait safely. The case is parked in a defined state — the lot in quarantine, the order on hold — and nothing downstream can use it. Waiting has to be a real status in the system, not a case stuck in limbo.

Continue what does not depend on it. The other lines on the same delivery go through. One bad certificate should not hold up a whole truck.

Call somebody. Where waiting costs more than a phone call, and to a named person on a rota rather than a distribution list.

These decisions belong to the people who handle the exceptions today, and they should be made before go-live, while those people are still in the room.

Getting the decision back in

The person’s decision should be made inside the hand-off, not in another system, so that it re-enters the pipeline as an input. The case continues from where it stopped instead of starting again, and the decision is stored together with who made it and why.

Stored decisions then become the most useful data the process produces. The same exception resolved the same way many times over is a candidate for change, and behind it there is usually a tolerance that is wrong, a supplier mapping that is missing or a reference record nobody created. Changing the rule is still a reviewed change, not something the system does to itself.

Anything that matches no known class stays a stop and a call. The difference is that the call now reaches a named person, with everything they need on one screen.

Start with the exceptions

Before automating the happy path, take a quarter’s worth of real exceptions, sort them into classes, and for each class write down what the person needs to see, what question they answer and what is held while they decide. That document is the exception design, and it specifies more of the build than the happy path does.

Exception classes with a defined response, and a record of every decision taken, are also exactly what unattended production rests on. They are the core of dark factory context development, which starts with the people who handle the exceptions now.