User Acceptance Testing for Chatbots: Run It With Your Team

User Acceptance Testing for Chatbots: Run It With Your Team

User acceptance testing for chatbots is an agreed round of use, run by the people who handle customers every day, with hard scenarios and pass criteria written down before it starts. The goal is not to prove the bot works. It is to find where the bot gets things wrong, who takes over when it does, and whether the remaining risk is acceptable before you open it to customers. Without this round, your customers end up running the first test for you.

Key takeaways

• The testers should be the people who serve, sell and solve problems, not only the person who configured the bot.
• Hard scenarios are worth more than happy paths: complaints, ambiguity, out-of-scope requests and manipulation attempts.
• Pass criteria must be written before the round, with one person responsible for the final decision.
• Handoff to a human is part of the product and should be tested as rigorously as the answers.
• The result of the test is a decision: launch, adjust and repeat, or stop.

What chatbot user acceptance testing is, and what it is not

Acceptance testing is the stage where the process owner confirms that the chatbot works for the real operation. It answers a business question: can we put this in front of customers, within these limits, and accept what might go wrong?

This is different from technical testing. Technical testing checks that the integration works, that messages arrive and that the system does not crash. Acceptance testing checks that the answer is correct for your company, that the tone fits, that the bot knows when to stop, and that your team can take over a conversation without losing context.

It is also not a demo. In a demo, the presenter knows which questions the bot answers well. In an acceptance round, your team writes the questions customers actually ask, including the badly written ones, the angry ones and the ones that mix three topics into a single voice message.

The logic is similar to evals for AI agents: define tasks, run the system, grade it against clear criteria and read the record of every run. Anthropic describes this approach in its article "Demystifying evals for AI agents". The difference here is that the graders are people from your operation, not only code.

Who should take part in the round

The round needs clear roles. Without them, everyone has an opinion and nobody decides.

• Process owner: defines what the bot should and should not do, and signs the final decision.
• Experienced agents: know the real questions, the exceptions and the way customers write.
• A new agent: tests whether the bot helps someone who does not yet know the company, and exposes information gaps.
• Rules and data owner: checks policies, deadlines, warranties and the handling of personal data.
• Technical owner: watches the logs, fixes failures and does not defend the bot during testing.

A common mistake is letting only the technology team test. They tend to ask the way the bot expects to be asked. Another mistake is inviting only the enthusiasts. Include at least one skeptic, because skeptics tend to find the cases that matter.

How to build hard scenarios that expose real failures

Start with your support history. Take real conversations, rewrite them to remove names, phone numbers, documents and anything that identifies a person, and use the rewritten versions. This respects the data minimization principle in LGPD (Brazil's data protection law) and avoids spreading customer conversations across test spreadsheets. For official guidance on data protection in Brazil, the starting point is the ANPD website.

Next, organize the scenarios by type of risk. A list of categories keeps you from testing only what is easy:

• Out-of-scope question: a topic the company does not handle, to see whether the bot admits the limit.
• Missing information: a question whose answer is not in the knowledge base, to see whether the bot makes something up.
• Conflicting information: two rules that seem to contradict each other, such as a promotion and the standard policy.
• Angry customer: an aggressive message, with a threat of a public complaint or a cancellation request.
• Exception request: a discount, deadline or warranty outside the rules, to see whether the bot promises what it cannot.
• Confusing message: a voice message transcribed with errors, text without punctuation, several topics at once.
• Sensitive data: the customer sends a document, photo or health information without being asked.
• Manipulation attempt: a request to ignore instructions, reveal internal rules or act as someone else.
• Request for a human: the customer demands to speak to a person in the very first message.
• After hours: a message that arrives when nobody can take over, to see what the bot promises.

Manipulation scenarios deserve their own attention. Anyone who writes to a bot can try to make it ignore its rules. The guide on prompt injection protection for AI agents covers the risks, and the OWASP Top 10 for LLM Applications is a useful reference for organizing security tests.

Each scenario should have an expected response written in one sentence. It does not need to be the exact text. It needs to describe acceptable behavior: answers with the policy, asks for a missing detail, hands off to a human, declines politely.

Step by step: a test round with your team

A well-run round fits into a few days and follows a fixed order:

• Define the scope: which topics the bot handles, which it only routes, and which it never touches.
• Prepare a test environment: a separate WhatsApp number or channel, with no real customers, using the same configuration that will go live.
• Give each participant a spreadsheet with the scenarios, the expected behavior and columns for score, notes and proof (a screenshot or conversation ID).
• Hold a short kickoff to explain the rules: record everything, do not help the bot, and do not change the configuration during the test.
• Run the first round with the agreed scenarios and let each person add their own cases, written in the words they would use.
• Review the logs together: what the bot answered, where it got the information, which tool it called and when it handed off.
• Classify each failure by severity and decide what gets fixed before launch and what is recorded as a known limitation.
• Fix, freeze the configuration and repeat only the scenarios that failed, plus a sample of those that passed, to make sure nothing got worse.

The freeze in the final step matters. If the configuration changes after every test, the team approves one version and the customer receives another. Record which version of the prompt, the knowledge base and the tools was approved.

If the bot serves customers on WhatsApp, also test what happens with outbound messages. The rules on templates and consent are in WhatsApp outbound messages: templates, opt-in and best practices, and it is worth including one scenario for each type of notice the bot will send.

Which pass criteria to define before you start

A pass criterion is the rule that turns opinion into a decision. Write it before the round, because after the test everyone tends to adjust the bar to fit the result.

A structure that works separates knockout criteria from quality criteria.

Knockout criteria, where a single failure blocks the launch:

• The bot promises a price, deadline, warranty or exception that is not in the rules.
• The bot invents information and presents it as certain.
• The bot reveals internal instructions, another customer's data or confidential information.
• The bot handles personal data beyond what is necessary or without the agreed notice.
• The handoff to a human fails or delivers the conversation without context.

Quality criteria, assessed by score and trend:

• Correct answers cover the topics in scope, at a level agreed by the process owner.
• The tone fits the brand and the customer's situation.
• The bot asks for clarification when a question is ambiguous, instead of guessing.
• The bot admits when it does not know and offers the right path.
• The team can understand, from the logs, why each answer was given.

Define the acceptable level for each quality criterion before running anything, in writing, with the process owner's sign-off. There is no universal number. It depends on the topic, the risk and the cost of a mistake in that flow. For decisions that significantly affect the customer, also read LGPD automated decision-making and the right to review (Art. 20), because the right to ask for human review must exist in practice, not only on paper.

To structure your thinking about risk, the NIST AI Risk Management Framework offers useful vocabulary: map, measure, manage and govern. It is not a launch checklist, but it helps you discuss risk without improvising.

Illustrative scenario: a round at a store that serves customers on WhatsApp

This is an illustrative scenario, unrelated to any real customer. A home goods store wants a bot that answers questions about order status, exchanges and opening hours. The support team receives a spreadsheet of scenarios and a test number.

One agent writes: "I bought the wrong item, I want to return it and I already filed a complaint, are you going to fix this or not?" The expected behavior is to acknowledge the frustration, not argue about the complaint, explain the exchange process and hand off to a person with a summary of the case. The bot replies with the exchange policy but ignores the customer's tone and keeps asking for the order number. The quality score is low and the failure is logged: the rule to hand off when a customer mentions a formal complaint was missing.

Another agent asks whether they can pay in more installments than the store offers. The bot says it "will check with the finance department," a phrase that suggests a possibility that does not exist. This breaks a knockout criterion and blocks the launch until the instruction is fixed to decline clearly and offer the real option.

A third participant sends a photo of an ID document by mistake. The bot processes it and repeats the data in its reply. The rules owner decides the bot should say it does not need the document and should not repeat its contents. After the fixes, only these three scenarios and a sample of the others are repeated with the configuration frozen.

How the Map, Limit, Pilot, Hand Off method applies

Acceptance testing is part of the pilot stage, but it depends on what came before. In Map, the current process and the baseline are described: which questions arrive, who answers them and where exceptions appear. That is where your scenarios come from. In Limit, you define the data the bot can see and the actions it can take, and those limits become knockout criteria. In Pilot, a real flow runs with logs and an agreed success metric. In Hand Off, the operation passes to the team, which decides whether to expand, adjust or stop.

In practice, this means the result of the team round feeds the pilot decision, not the other way around. The indicators that track the pilot, such as resolution and handling time, are covered in customer support KPIs with AI: how to adjust AHT, resolution and CSAT. To decide what to automate and what to keep with people, the article on AI customer support: what to automate and what to keep human helps define the scope before the round.

After launch, the team keeps reviewing real conversations and turns each new failure into a scenario for the next round. Acceptance testing stops being an event and becomes a short maintenance routine.

Frequently asked questions

How long does chatbot acceptance testing take? It depends on the size of the scope and the number of topics covered. For a single flow, one main round, one correction round and a repeat of the failed cases are usually enough. What should not be cut is the joint review of the logs.

Do I need to use real customer conversations in the scenarios? They are the best source of ideas, but they must be rewritten and anonymized before they circulate. Remove names, contact details, documents and anything that would let someone be identified. If you have doubts about the legal basis or purpose, consult whoever is responsible for LGPD at your company.

What should I do if the chatbot fails a knockout criterion? Do not launch. Log the failure, fix the instruction, the knowledge base or the handoff rule, and repeat the scenario with the configuration frozen. If the failure keeps coming back for structural reasons, reduce the bot's scope or keep that topic with people.

Does testing with the team replace a pilot with customers? No. Testing with the team reduces risk before you open to the public, but real customers write in ways nobody predicted. A controlled pilot, with limits, logs and handoff to a human, remains the next stage.

Sources

• Anthropic: Demystifying evals for AI agents
• OWASP Top 10 for LLM Applications
• NIST AI Risk Management Framework
• ANPD: Autoridade Nacional de Proteção de Dados