Think Build Implement Repeat
London, UK +44 7367 067226
WhatsApp FOLLOW f in X
  1. Home
  2. Blog
  3. Deciding When Your Automation Should Stop and Ask
Business Automation

Deciding When Your Automation Should Stop and Ask

Human-in-the-loop design for automation: four triggers for review, thresholds per field, fast review screens, tracking the review rate and a stop button.

Updated 2 min readBy SpiderHunts Technologies

Free estimateNo obligation

Get a free estimate

Tell us what you need. A senior engineer reads every enquiry.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →

Quick answer — TL;DR

Route to a human on low confidence, high value, external consequence or anything irreversible. Everything else should proceed automatically. Too much review makes automation pointless; too little makes it dangerous.

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.

FAQ

Frequently asked questions

The questions readers ask us after this guide.

Still have a question?

Ask us directly — a senior engineer will get back to you.

Ask about your project

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

More on Business Automation

Start here

Automation that checks everything twice?

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

  1. You tell us what you needTwo minutes on the form, or a message on WhatsApp.
  2. A senior engineer reviews itAnd comes back with questions, a realistic range and an honest view on fit.
  3. Free 30-minute scoping callWe talk through scope, options and a realistic estimate — with no obligation.
Free estimateNo obligation

Talk to someone who builds this

Send a short brief and we will come back with an honest view and a realistic range.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →