Business Automation
Designing the Human Step Into an Automated Process
A human placed in an automated flow to 'check the output' will approve almost everything. Give them a decision, the context to make it, and a way to disagree.
Most automated processes keep a person somewhere in the flow, usually to review output before it commits. It is a sensible instinct and it is often implemented in a way that guarantees the review is worthless: a queue of items, each with an approve button, and no indication of which ones deserve attention.
Automation bias sets in quickly
When a system is right most of the time, reviewers stop reviewing. This is well documented and it happens within weeks, not years. The measurable symptom is a falling override rate against an unchanged underlying error rate — the reviewer has become a click, not a control.
A reviewer who approves 99.9% of items is not reviewing. They are confirming.
Only route what needs a decision
The single most effective change is to stop sending confident cases to a human at all. Let the automation commit those, sample them separately for assurance, and route only genuine exceptions to the queue. A queue of twelve real problems gets read; a queue of four hundred mostly-fine items does not.
Give the reviewer what a decision requires
• Why this item was routed — the specific rule or low-confidence field.
• The evidence, in the same screen: the source document, the matched record, the history.
• What happens on approve and on reject, stated plainly.
• Similar past cases and how they were decided.
• A confidence figure, if the system has one, and what it means.
Make disagreement cheap
If approving takes one click and rejecting requires a free-text justification and a second confirmation, you have designed an approval machine. The two paths should cost the same. Where a reason is genuinely needed, offer a short picklist of the common ones — which also gives you data on why the automation is getting things wrong.
Watch the reviewer, not just the process
Instrument the human step as carefully as the automated ones:
• Override rate, tracked over time — a steady decline is the warning sign.
• Time spent per item; sub-second decisions are not decisions.
• Agreement between reviewers on the same case, sampled occasionally.
• Queue age, because a backlog converts review into rubber-stamping.
Rotate and re-baseline
Vigilance on a monotonous queue degrades no matter how well the screen is designed. Rotate reviewers, keep the volume per person low enough that attention is plausible, and periodically seed known-bad cases to confirm the control still catches them. If the seeded cases sail through, the control has failed regardless of what the process map says.
Automation bias is real and fast. We measured our reviewers' override rate: 0.4% in month one, 0.05% by month four. Same error rate in the underlying system. They had simply stopped looking.
Making 'reject' as cheap as 'approve' is the design detail that mattered most for us. Rejecting used to require a free-text reason and two more clicks, so nobody did it.
Showing confidence and the reason for routing changed reviewer behaviour immediately. 'Low confidence: supplier name fuzzy-matched' gets read. A bare queue item gets approved.