Automation with people in the loop

Automating is not a choice between "a machine does it" and "a person does it". Almost every well-designed process combines both, and the quality of the design lives exactly at the boundary: at which points a person looks, decides or can stop things, and where the process runs on its own. The decision this article deals with is where to place those human review points — and, just as importantly, where they don't belong. Badly placed, they turn the automation into an approval queue that saves nothing; missing where they were needed, they leave delicate decisions running with nobody watching.

Neither fully automatic nor fully reviewed

The two extremes fail predictably. A process where every step waits for an approval keeps all the bottleneck of the manual process and adds the cost of the automation on top: you've built a machine for queueing. At the other extreme, a fully automatic process applied to decisions that called for judgement — a missed payment that was actually the bank's error, a complaint handled as a routine enquiry — produces mistakes signed in the company's name with no author to ask.

The way out is not a generic middle ground but a criterion applied step by step: each review point gets added or removed for a concrete reason, not out of vague caution or habit.

Two questions that place each point: impact and ambiguity

For every step in the process where a decision is taken or executed, two questions are enough to know whether it needs a person in front of it.

What happens if it goes wrong? That's impact: some errors are cheap and reversible — a mislabelled internal record gets corrected and no harm done — and some are expensive or hard to undo: an incorrect charge, a commitment made to a customer, data leaving the company.

Can a written rule take the decision? That's ambiguity: some decisions resolve with a clear condition — if the amount matches, reconcile — and some call for context no rule captures: intent, history with that particular customer, nuances of wording.

Crossing the two organises the design. Low impact and a clear rule: automatic, no review; checking there is wasted time. High impact but a clear rule: automatic, with a log of what was done and sample-based review, because the risk isn't in the decision itself but in the rule degrading without anyone noticing. High ambiguity with low impact: automatic with after-the-fact review, so you learn from mistakes without slowing the flow. And the quadrant that justifies this article: high impact and high ambiguity. There, the person doesn't review what the machine did — the person decides, and the automation works for them: it gathers the information, prepares the proposal, leaves everything ready. The difference between "the person decides with everything prepared" and "the person redoes the work in order to trust it" is the difference between a good automation and an alibi.

Review by exception, not by default

The most common design error is placing review as a toll: everything passes through a person, always. The design that works inverts the burden: the process separates the clear from the doubtful, the clear goes through on its own, and only the doubtful waits for a person. In a customer-reply queue, standard enquiries go out without a stop; the ones that mention a complaint, touch an amount outside the usual range, or simply don't match any known pattern get held for human eyes.

That way, review doesn't slow the process, because the process doesn't depend on it to move forward in the common case. And it leaves a useful maintenance signal: if over time almost everything ends up in the doubtful queue, the problem isn't that the person is redundant — it's that the rule separating clear from doubtful is badly tuned. If almost nothing arrives, it's worth checking that the rule hasn't grown too bold.

A review that always says yes is theatre

A review point only truly exists if the person can say no. If the reviewer has no time to look, doesn't have the necessary information in front of them, or has no real authority to stop the process, the control point is a click by another name. And it's worse than having no review at all: it gives the feeling of control without the substance, and it dilutes responsibility — "someone approved this" — precisely in the cases where knowing who answered for what mattered most.

The signs are easy to recognise: everything gets approved, it gets approved in seconds, nobody remembers the last time something was rejected. When they appear, there are two honest ways out: give the review teeth — allocated time, the information next to the decision, real power to stop — or remove it and replace it with honest sampling. What makes no sense is keeping the ritual for the reassurance it appears to provide.

Where reviews don't belong

Removing reviews is design work too. They tend to be redundant in three places: steps inherited from the manual process — "someone always signed this off" — whose original reason nobody can explain any more; decisions with an objective rule and a small cost of error, where review only adds waiting; and duplicated reviews, two people looking at the same thing because nobody decided which of them was accountable. In all three cases, the removal should be explicit and come with a net: take out the review, keep a log of what the process does, so you can look back if something changes.

Three questions before adding (or removing) a review point

1. If this step goes wrong with nobody watching, what does it cost and can it be undone?
2. Can a written rule take the decision, or does it need context only a person has?
3. Does the person reviewing have the time, the information in front of them, and real authority to say no?

The first two tell you where review belongs; the third tells you whether the one you have is worth anything. Designing this way isn't distrust of the automation or of the people: it's deciding, before the process runs, who answers for what. Keeping people in control of what matters is one of the principles we work by — it's part of our approach.