Skip to content
Chatbotscape
Editorial flat-vector illustration for How to Add a Human Approval Step to Your Chatbot's Actions
Published 7 min read

How to Add a Human Approval Step to Your Chatbot's Actions

Quick answer: List every action your bot can take, mark the ones that move money, cannot be undone or touch personal data, and make those pause for a person. Give the reviewer the customer's message, the exact action and the amount. Let them approve, edit or reject. Tell the customer what is happening while they wait, and each month check how many requests were approved untouched. If it is nearly all of them, the rule is probably too wide.

Step 1: List what the bot can actually do

Open your bot's tool or action list. If you use a platform, look at its integrations and connected workflows. Write one line per action: "look up order", "issue refund", "change delivery address", "send discount code", "export customer data".

Include actions reachable in more than one way. If a refund can be made by a refund tool or by a generic "update order" tool, both belong on the list. A gate on one path does nothing if the other is open. The AI agent integration guide shows how these connections are usually set up.

Step 2: Sort the actions into three tiers

For each action, ask three questions: can it be undone, does it move money or change a customer record, and does it expose personal data? These questions are our rule of thumb, not an industry standard.

  • Tier 1, automatic. Read-only or easily reversed: order status, store hours, tagging a chat.
  • Tier 2, automatic with a limit. Allowed up to a ceiling: a refund under a set amount, one discount code per customer.
  • Tier 3, approval needed. Money above the ceiling, irreversible changes, data exports and deletions, bulk messages.

Write the ceilings as numbers in a short policy page that a manager signs off. Review it with your guardrails, since a limit that the model is merely asked to respect is weaker than one your code enforces.

Step 3: Design the review screen

The reviewer's screen decides whether approval means anything. Show:

  • the customer's last messages, as sent;
  • the exact action the bot proposes, with every parameter: order number, amount, address, recipient;
  • what the bot's own answer to the customer said, if different;
  • any relevant record, such as the order total or the date of purchase;
  • a plain reason the request was held, such as "refund over $30".

Offer four buttons: approve, edit (for example, change the amount), reject with a note and hand off to a person. LangChain's documentation describes a similar set of decisions (approve, edit, reject and respond) for gated tool calls, and n8n's shows the tool name and parameters to the reviewer with approve and deny. Do not use a free-text reply to stand in for a rejection on an action with side effects: LangChain's documentation warns that the model treats such a message as a successful result.

Step 4: Pause the action and resume it safely

Technically, the flow has four parts.

  1. The model proposes the action, as in function calling. Your code does not run it yet.
  2. Your code checks the tier. If the action needs approval, it saves the pending request, including who asked and what was proposed, and sends it to the review channel.
  3. The system waits. LangChain's documentation says you must configure a checkpointer so the paused state persists across interrupts, so plan where pending requests are stored. A request held only in memory is lost on a restart.
  4. When a person decides, your code runs, edits or cancels the action and tells the bot the result, so its next message to the customer is accurate.

Use one record per request with a unique ID and a status such as pending, approved, rejected or expired. Make approving idempotent, so a double click does not refund twice. Write every decision, with the reviewer's name and time, to your audit log.

n8n lets the approval request go to a different channel than the one the customer is using, such as Slack or Microsoft Teams. That is convenient, but check that the channel is one your team actually watches.

Step 5: Look after the customer who is waiting

An approval step adds waiting time, so decide what the customer hears.

  • Say it plainly. "I have asked a team member to check this refund. You will get a reply here by 5 p.m." Only promise a time you can keep.
  • Set an owner and a deadline. Someone is responsible for the queue each day, and requests older than your limit are escalated.
  • Set a timeout. If no one decides within the limit, the request expires, the customer is told, and a person follows up. Do not let an expired request run by default.
  • Offer another route. If the customer wants a person now, use the escalation playbook.

Step 6: Review the queue every month

Look at the numbers:

  1. Decision mix. What share was approved unchanged, edited or rejected?
  2. Time to decision. Median and slowest.
  3. Volume per reviewer. Is the queue small enough to read properly?
  4. Misses. Were any actions that should have been gated run automatically? Look for them in the production monitoring records.
  5. Test the gate on purpose. Have someone try to get the bot to take a gated action by another route, using the methods in the red teaming guide. Messages that try to steer the bot are a form of prompt injection.

If almost every item is approved untouched, either the rule is catching harmless cases, or reviewers are not reading. Raise the ceiling for the harmless cases and keep the careful review for the rest.

Check the arithmetic

An invented month, not a measurement. A shop's agent handles 500 refund requests. Refunds under $30 run automatically.

  • 380 requests are under $30 and 120 go to review. Check: 380 + 120 = 500.
  • Of the 120 reviewed, 108 are approved unchanged, 6 are edited and 6 are rejected. Check: 108 + 6 + 6 = 120. Approved unchanged: 108 ÷ 120 = 90%. Edited: 5%. Rejected: 5%.
  • If the six rejected requests averaged $85, that is 6 × $85 = $510 not paid. This assumes the rejections were correct, which a later review should confirm.
  • If reviewing takes about 45 seconds a case, 120 × 45 = 5,400 seconds = 90 minutes. At an assumed $25 an hour, 1.5 × $25 = $37.50.

On these made-up numbers the review costs less than the refunds it stopped. Your numbers will differ, and a 90 percent unchanged rate is also a prompt to ask whether the $30 line is in the right place.

Common mistakes

  • Gating too much. Reviewers start clicking through.
  • A thin review screen. "Approve?" with no amount or context.
  • Gating one tool, not the outcome. The bot reaches the same result another way.
  • Pending requests held only in memory. A restart loses them.
  • No timeout. Requests sit for days, or run by default.
  • No record of who decided. You cannot answer a dispute.

FAQ

How do I add human approval to an AI chatbot?

List its actions, pick the risky ones, pause those before they run, show a reviewer the exact action, and run, edit or cancel it on their decision.

Which chatbot actions should need approval?

Usually those that move money above a limit, cannot be undone, change records or expose personal data. Read-only lookups usually do not.

What happens to the customer while they wait?

Tell them a person is checking, give a time you can keep, and expire the request with a human follow-up if no decision is made in time.

Is this the same as handing the chat to a human?

No. A handoff transfers the conversation. An approval step keeps the bot in the chat and puts a person's decision in front of one action.

Can I do this without writing code?

Some workflow tools, such as n8n, offer a review setting for tool calls. Check the current documentation for your tool and test it on your own actions.