Everyone assumes a review gate is a tax on throughput. Measured against the task it replaces, it is the cheapest thing in the building — but only if you build the interface properly.
The most common objection to an approval queue is the reasonable one: if a human has to look at everything anyway, what have you actually saved?
It is a good question and it has a numeric answer. In a supervised support deployment, median time for a reviewer to clear a proposed action was eight seconds. The task that proposal replaced — doing a short-shipment credit by hand in the ERP — took a median of four minutes twenty.
Thirty-two to one. That ratio, not the model's accuracy, is the business case.
Eight seconds is not luck. It is a design target, and everything about the review surface is built backwards from it.
One decision per screen. No list to scan, no tabs, no scrolling. The proposal, the diff against current system state, and the cited evidence fit in one view. If a reviewer has to scroll to decide, the proposal is carrying too much surface.
A diff, not a description. "Ship-to: Site 4, 220 Quarry Rd → 1400 Marsh St" is read
in under a second. A paragraph explaining that the customer has requested a change of delivery address is
read in six and understood no better.
Evidence as chips, not prose. The reviewer needs to know what the decision rests on, not to read the model's reasoning. A signed proof of delivery showing 8 units against an invoice for 12 is the whole argument.
Keyboard, always. J and K to move, A to approve, R to reject, E to escalate. The mouse costs about two seconds per decision, which at a thousand decisions a week is a full working day.
Bulk approval for runs. Twelve identical low-risk proposals should be one keystroke, not twelve.
Rejection reasons in one key. Not a free-text box. A fixed taxonomy of six to nine reasons, each on a single key.
If we could keep only one field from the entire system it would be this one.
A queue that records yes and no tells you an accuracy percentage. A queue that records why tells you what to fix. "Wrong policy applied" is a retrieval problem. "Right action, wrong amount" is an arithmetic problem you solve by recomputing values deterministically. "Should have escalated" is a missing structural rule. "Tone wrong for this customer" is a prompt problem. Same rejection rate; four completely different engineering weeks.
It costs one keystroke to capture and it is the highest-quality training signal your company generates. Most systems throw it away.
Once you have a real seconds-to-decide number, the conversation about AI in your company changes shape entirely. It stops being a debate about whether the model can be trusted — an unanswerable question — and becomes arithmetic about throughput at a given precision floor. Operations people are extremely good at that conversation. They have been having it about every other process for their whole careers.
And it reframes autonomy as an optimisation rather than a leap. At 32:1 you are already capturing most of the value with a human on every single action. Graduating an action type to automatic is the last few percent, taken only when the data says it is safe. That is a much easier thing to say yes to than "trust the robot".
Support automation, AI phone agents, n8n back-office work, and the engineering loop itself — always behind a gate you control.