Human-in-the-loop design: approval steps clients trust

A person belongs in an automation wherever a mistake would be expensive or impossible to undo: anything that moves money, makes a commitment, touches medical or legal content, or contacts someone the business has never spoken to. Everything else can run on its own, logged and sampled. Three patterns cover almost every case: approve-before-send, route-on-doubt, and review-after-the-fact. The craft is putting the approval where the approver already works so it costs seconds, not a new habit.

Why do clients trust the exception path more than the automation?

Because they have been burned by tools that guessed. A business owner reading a proposal is looking for the sentence "a person approves X". It answers their real question, which is never "how smart is it?" but "what happens when it's wrong?". Design the approval first and the owner relaxes about everything else.

Pattern 1: approve before send

The automation drafts; a person approves; then it sends. Use it for quotes, anything with a price, replies to complaints, medical or legal wording, and first messages to new contacts. Make the approval one tap where the approver lives: a WhatsApp message with "Send" and "Edit", an email with two links, a sheet row with a checkbox. Include the draft and the context in the same message so no one has to open another system.

Pattern 2: route on doubt

The automation handles the in-pattern cases and hands the rest to a person with everything they need: the original message, what the automation understood, why it stopped. Triggers for routing: the model reports low confidence, the input mentions a listed keyword (pain, refund, lawyer, cancel), the customer replied twice, or a required field is missing. The person's reply goes back through the same channel so the customer notices nothing.

Pattern 3: review after the fact

For low-risk, high-volume actions such as tagging leads or logging calls, let it run and review a sample weekly: ten random runs, five minutes. Every wrong case becomes a rule. This is how an automation earns more autonomy over time, with evidence.

Keeping approvals fast

What the model must never be allowed to do alone

Give the model only the actions the task needs. In practice: it may draft, classify and look things up on its own; it may send only after approval or within a narrow, tested pattern; it may never delete, pay, promise a date, or change its own instructions because a customer asked. Customer text is input, never instruction. Put these limits in the brief so the client sees them.

Writing it into the proposal

One sentence per pattern, in the owner's words: "Quotes and anything about price go to you for a one-tap approval on WhatsApp. Messages mentioning pain or an emergency go straight to the front desk with the original text. Everything else runs on its own and we review ten runs together every Friday." That paragraph sells the project.

Best fit and not a good fit

Best fit: any automation that talks to customers or touches money. Not a good fit: purely internal data moves with no customer contact; there, logging and a weekly sample are enough.

What to do this week

Take your current automation and write the three sentences above for it. Then build the approval into the channel the approver already uses, and remove one place where the automation currently guesses.