Deciding When Your Automation Should Stop and Ask
Last updated:
Both extremes fail
An automation that asks a human about everything has moved work rather than removed it. One that asks about nothing will eventually do something expensive without anyone noticing.
The design question is where the boundary sits, and it should be set deliberately rather than by default.
Four triggers for human review
- Low confidence. The system is unsure — extraction below a threshold, an ambiguous match.
- High value. Above a monetary threshold, regardless of confidence.
- External consequence. Anything that sends a message, moves money or commits you to a third party.
- Irreversibility. Anything that cannot be undone easily.
The irreversibility test is the one to apply hardest. A wrong decision that can be corrected in a click is a nuisance; one that cannot is an incident.
Set thresholds per field, not per process
Different fields deserve different treatment. A supplier name being wrong is recoverable; a bank account number being wrong is not. Confidence thresholds should reflect the consequence of that specific field being wrong.
This is more work to design and it is what allows most records to flow through automatically while the dangerous ones are checked.
Make review fast
- Show the source alongside the extracted or decided value
- Highlight exactly what needs attention rather than presenting everything
- Default the cursor to the uncertain field
- Allow keyboard-only completion
- Capture the correction so the same case is not queried repeatedly
A review interface that takes ten seconds per item makes a 20% review rate perfectly workable. One that takes two minutes does not.
Watch the review rate as a metric
Track the proportion of items requiring human attention over time. It should fall as the system learns and the thresholds are tuned.
A review rate that is flat after three months means either the thresholds are wrong or the corrections are not feeding back.
Have a stop button
Someone should be able to pause the automation entirely, quickly, without a developer. When something is going wrong at volume, the ability to stop it in seconds is worth a great deal.
Design it in from the start, and make sure the people who would need it know where it is.
Frequently asked questions
What review rate should we aim for?
Who should do the review?
What if reviewers start approving without looking?
Should confidence thresholds be adjustable?
Automation that checks everything twice?
That is a threshold design problem and it is fixable. Tell us what your review queue looks like.
Related services
What we build for problems like this one