The Step Where a Person Decides

Design · June 22, 2026 · 9 min read

Most automated processes contain at least one point where a person has to say yes. Refunds above a threshold. Changes to a customer’s credit terms. A robot being released onto a factory floor after maintenance. A schedule that would send an engineer three hours out of their territory.

These steps get designed last and thought about least. They are treated as a gap in the automation — a place where the machine stops and waits — rather than as part of the machine. That framing is the source of nearly every problem they cause.

A human step has all the properties of a step

It can fail. It can time out. It has a latency distribution, and that distribution has a very long tail. It can be retried, in the sense that the request can be re-sent to someone else. It produces an output that the rest of the workflow depends on. It needs an audit record.

None of that is special because a person is involved. What is special is the scale of the numbers. A service call that takes two seconds at the median might take thirty at the worst. An approval that takes ten minutes at the median takes four days when the approver is on annual leave and the workflow has no idea that concept exists.

So the design questions are the ordinary ones, asked with the right magnitudes. What is the timeout? What happens when it expires? Who is the fallback? Is the step idempotent — if the same approval request is delivered twice, does the workflow proceed twice?

Review versus rubber-stamping

The reason a human step exists is to inject judgement the system cannot supply. Whether it actually does depends almost entirely on how often the answer is yes.

An approval queue where nearly everything is approved does not produce judgement. It produces a click. The approver learns, correctly, that the expected value of careful reading is low, and adapts by not reading carefully. This is not a discipline failure; it is a rational response to a queue with poor precision, and no amount of training reverses it.

Which gives a diagnostic worth running on any approval step in production: what proportion of items are rejected or modified? If that number is very small, the step is not doing what it was built to do. Two responses are available, and both are better than leaving it as is.

The first is to narrow the trigger so the step only fires on cases that are genuinely ambiguous. If nine in ten refunds under some amount are approved without a second thought, the threshold is in the wrong place, and moving it converts a large queue of non-decisions into a small queue of real ones.

The second is to change the default. A step that requires positive action to proceed is a bottleneck; a step that proceeds unless someone objects within a window is a safety valve. These carry different risk, and the choice should follow reversibility: if the action can be cheaply undone, notify and proceed; if it cannot, wait for the affirmative.

Context has to arrive with the request

The most common practical failure is that the approver cannot decide without opening three other systems. The request says a customer wants a refund. It does not say what they bought, when, what they have already been refunded, whether they have complained before, or what the person requesting on their behalf recommended.

So the approver either goes and finds all that, which makes the step slow enough that it becomes the bottleneck everyone complains about, or they approve on insufficient information, which makes the step decorative. Usually it starts as the first and decays into the second.

Assembling context is unglamorous work and it is the highest-leverage thing you can do to a human step. The rule of thumb is that everything needed for the common case should be in the request itself, with links out for the unusual case. If the approver has to leave to handle the median item, the step is underbuilt.

Timeouts, escalation and the leave calendar

Every human step needs an answer to “and if nobody responds?” — because eventually nobody will. The person left. The rota was wrong. The notification went to a channel that was archived.

The options are the familiar ones: escalate to a second party after a period, fall back to a default action, or fail the workflow explicitly and surface it. The one option that must not be available is wait indefinitely and silently, which is the behaviour you get by not deciding. Work parked in a human step with no timeout does not appear in error dashboards, because nothing errored. It sits there looking like normal in-progress work, sometimes for months.

Escalation deserves a caution. Escalating to a manager after a delay tends to push decisions towards people with less context rather than more. Escalation by breadth — offering the item to a pool rather than an individual — usually performs better, and it removes the single-point dependency that made the timeout necessary in the first place.

Recording the decision, not the click

The audit value of a human step is not that someone approved. It is why. A record showing an identity and a timestamp answers who to blame; a record showing the reason answers whether the process is working.

This does not require a free-text essay. A short list of structured reasons, chosen at the point of decision, produces something you can aggregate. Six months later that aggregate is what tells you which rule is producing the rejections, and therefore which rule to change so the step stops being needed.

An approval queue that never shrinks is a queue nobody is learning from.

The step you should be trying to delete

The healthiest way to hold a human-in-the-loop step is as a temporary measure with an exit condition. It exists because the system cannot yet distinguish the cases confidently. As the reasons for rejection accumulate and get encoded, the proportion of items needing judgement should fall, and the trigger should narrow to match.

That does not mean the goal is zero. Some decisions should stay with a person permanently, because they carry consequences that a policy cannot anticipate, or because accountability has to attach to a name. Those steps are worth their latency.

The ones worth removing are the steps that exist because nobody has revisited a threshold since the pilot, and which now consume real attention to produce a predetermined answer. They look like control. They are mostly delay.