Think Build Implement Repeat
Business Automation

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

  1. Low confidence. The system is unsure — extraction below a threshold, an ambiguous match.
  2. High value. Above a monetary threshold, regardless of confidence.
  3. External consequence. Anything that sends a message, moves money or commits you to a third party.
  4. 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?

Low enough that the automation saves real time, high enough that consequential errors are caught. For document processing, somewhere between 10% and 30% is common initially, falling with tuning.

Who should do the review?

Someone who knows the domain well enough to spot a wrong answer quickly. Review by someone without that knowledge is a rubber stamp with extra steps.

What if reviewers start approving without looking?

That is a design signal: either the review rate is too high, the interface is too slow, or the queue is too large. Sample the approvals to check, and fix the cause rather than the behaviour.

Should confidence thresholds be adjustable?

Yes, by a business user rather than a developer. They will need tuning as you learn where the errors actually are.

Keep reading

Automation that checks everything twice?

That is a threshold design problem and it is fixable. Tell us what your review queue looks like.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

Business AutomationCustom Software Development