Where a human still has to review the work

Human in the loop automation means a person still checks the work before a customer sees it, pays it, or loses the chance to undo it. Write that line down. "We will review the important stuff" is not a line, because nobody agrees what important means at 6 p.m.

If the action is public, billed, or permanent, the draft waits. If the action is internal, reversible, and cheap to fix, the automation can finish and leave a log a person can read later. The rest of this piece is how to sort a real workflow into those two piles.

Write the line before you build the flow

Draw three columns on one page: the customer will see it, the customer will pay it, the customer cannot undo it. Every step in the automation goes in a column, or it goes in a fourth column labeled "log only." If a step fits two of the first three, it stays with a person. Do this before you pick a tool. Tools are happy to send. They will not invent your standard.

Name the reviewer. A queue that says "the team" belongs to no one. A queue with a role, and a second person for the days that role is out, will actually get read. The backup matters more than the software. An unread review step is an automated send with extra delay.

Write what "reviewed" means in one sentence. For a support reply, it might mean "the facts match the account, and the promise is one we can keep." For a refund, it might mean "the amount matches the order, and the reason is one we allow." Vague review becomes either a rubber stamp or a rewrite of the whole task. Both waste the automation.

Keep the list short enough to reread when someone proposes a new step. A policy no one can find will be replaced by whatever the tool does by default.

Anything a customer will see

Public replies, status pages, emails, and messages in a community are customer-visible. A draft can be prepared by software. The first version of a new kind of message should have a person on it until the template has survived real cases without a correction.

The visible message still has to be understandable on its own. The W3C's WCAG 2 overview organizes web content under four principles: perceivable, operable, understandable, and robust. An automated email or a status page is content. If it tells the customer something failed, the sentence should say what failed and what to do next. A code, or a cheerful "all set" that hides a failure, fails that test even if a human clicked approve without reading.

Review the template, not only the individual send, when the same error keeps getting through. If reviewers are fixing tone every time, the template is wrong. If they are fixing facts every time, the automation is pulling the wrong record. Those are different repairs. A human in the loop is not a substitute for a bad source.

Internal notes can skip the review, with a limit. The note must not be pasted into a customer channel by the next step. If your tool chain makes that paste easy, treat the note as customer-visible anyway. Accidents count. The customer does not care that the message was "only internal" after they have read it.

Anything a customer will pay

Money is a review category of its own. A correct-looking charge that is wrong costs trust that a wording fix cannot buy back. Baymard Institute's 2025 compilation of cart-abandonment research is a reminder of how brittle that trust is. The average documented abandonment rate across 50 studies is 70.22%. In the reason breakdown, not trusting the site with credit card information is listed at 19%. Separately, Baymard states that 17% of US online shoppers have abandoned an order because checkout was too long or complicated.

Use those figures as design constraints, not as a slogan. A person should see unusual charges, refunds, and any price the customer did not already confirm. The customer should see the amount before money moves. And the review you add must not become a second, slower checkout. Baymard's 17% is the warning against a review theater of extra steps, extra accounts, and extra waits. The human check belongs on the exception. The ordinary, already-confirmed total can go through.

Define "unusual" with numbers you already use. A refund over the amount of the order. A second charge on the same day. A discount code the automation invented because a field was empty. Those are review items. A standard renewal the customer already accepted is not, as long as the receipt matches the agreement and a person can pull it back the same day if the source data was wrong.

Never let an automation raise a price on its own because a model "thought" the customer would pay more. That is not a review item. That is a decision you should not automate at all.

Anything the customer cannot undo

Deletion, public posting, sent contracts, and revoked access sit in the third column. If the customer cannot reverse it from their side, a person reverses it on yours before it happens, or you build a real undo and test it.

Undo has to be practical. A button labeled undo that only files a ticket is not undo. A restore that works until the nightly job is undo with a deadline, and the interface should say the deadline. If you cannot build that, keep the person on the send button.

"Cannot undo" also includes social undo. A message in a community can be deleted and still have been seen. Treat the first post of a new bot, a new alert type, or a new customer email as hard to undo. Review those until the pattern is dull. Dull is the goal. Dull means the template matches what a careful person would have sent.

Some irreversible steps are internal, such as overwriting a production record. Put those in the same column. The customer may not see the write, but they will see the damage. A person confirms the write, or the system keeps the previous version and the automation only proposes the change.

Make the review shorter than the old chore

A review step that takes longer than doing the task by hand will be skipped, and then you have the risk without the time saved. Show the reviewer the diff: what the automation wants to send or charge, and the one source it used. Hide the rest behind a disclosure. Ask for a yes, a small edit, or a stop. Do not ask them to rebuild the work in the approval screen.

If reviewers always stop the item, the automation is not ready to be in front of customers. If they always approve without edits, you can narrow the review to exceptions and keep a sample audit each week. The sample is how you notice drift. A week of perfect approvals followed by a quiet change in the source data is how bad messages start shipping again.

Retire review steps that no longer catch anything, and write down the date you retired them. A loop full of ceremonial checkboxes trains people to click through the one checkbox that still matters.

Hanabi's services include this kind of automation when the workflow is specific: a clear input, a clear output, and a line where a person remains. The line is the design. The tool is not.

How the interface earns trust before that review is the neighboring question. Designing an AI feature people can trust is the next piece if the draft itself needs a visible source, a limit, and an edit, so the reviewer is not the first person asked to notice a guess.