How to Test Your AI Chatbot Before Launch: A Complete Checklist

In a fourteen-month window, three companies learned in public what happens when a customer-facing chatbot ships without adversarial testing. A Chevrolet dealership's assistant was talked into agreeing to sell a Tahoe for one dollar and calling the offer legally binding. DPD disabled its support bot after a customer got it to swear and write a poem about being the worst delivery service in the world. And a British Columbia tribunal ordered Air Canada to compensate a passenger who had followed a bereavement fare policy the airline's chatbot invented, rejecting the argument that the chatbot was a separate legal entity responsible for its own actions.

None of those were exotic failures. All three were reproducible in under ten minutes by anyone who thought to try, which is the definition of a testing gap rather than a technology limitation. The Air Canada decision in particular set the operating assumption every team should now work from: what your chatbot says, your company said.

This is the checklist that prevents those outcomes. It is organised as seven layers, run roughly in order, because each layer catches what the previous one cannot. A customer-facing bot in a low-risk domain can move through it in about a week; a regulated one should expect several.

Layer 0: Write the Evaluation Contract First

Before running a single test, write down three things and get product, engineering, and support to sign off on all three.

The scope. What the bot is for, and explicitly what it is not for. A bot scoped to "answer questions about our product and hand off everything else" is testable. A bot scoped to "help customers" is not.

The risk tier. What is the worst thing a wrong answer can cause? Mild confusion, a refund dispute, a regulatory breach, or physical harm? The tier sets your thresholds and it is the only reason the same bot can be safe on a coffee subscription site and unsafe on a pharmacy site.

The thresholds. Numbers, agreed in advance, that decide launch. Industry practice puts the tolerable hallucination rate around 5 percent for general customer-facing use and below 1 percent for medical or legal contexts, with faithfulness above 0.75 and answer relevance above 0.70 as common production floors.

Thresholds written after the results arrive are not thresholds. They are rationalisations.

Layer 1: Test Retrieval Before You Test Answers

In a retrieval-augmented chatbot, most wrong answers are not generation failures. They are retrieval failures wearing a generation costume: the model wrote a reasonable answer from the wrong passages. Testing the finished answer first tells you something is broken without telling you what, so retrieval testing comes first.

Take 30 to 50 questions with known answers and, for each one, check whether the passage containing the correct answer appears in what the system retrieved. That is precision and recall at the retrieval layer, and Precision@5 above 0.8 is a reasonable production baseline for a knowledge base of business documentation.

Three things to look for specifically:

• Silent gaps. The correct passage does not exist in the corpus at all. This is a content problem and no amount of prompt work fixes it.
• Near misses. The right document is retrieved but the wrong section of it. Usually a chunking or document structure problem.
• Contradiction pairs. Two retrieved passages disagree. The model will pick one, and you will not be able to predict which.

If retrieval is failing, stop here and fix the data. Everything downstream inherits it, and the mechanics of doing that are covered in the guide on improving chatbot accuracy through better training data.

Layer 2: Build a Golden Dataset and Score Against It

A golden dataset is a fixed list of questions with approved answers, and it is the backbone of every layer after this one. Build it from real usage rather than imagination: exported support tickets, site search logs, and sales call notes. A minimum viable set is around 50 questions; a production-grade set for a customer-facing bot is closer to 500.

Compose it deliberately, in roughly these proportions:

• Normal cases (60 percent). The questions from the head of your volume distribution, phrased the way customers actually phrase them, including misspellings and shorthand.
• Edge cases (25 percent). Multi-part questions, questions with a false premise ("why does your enterprise plan not include SSO?" when it does), questions about things you deliberately do not cover, and follow-ups that depend on the previous turn.
• Adversarial cases (15 percent). Covered in layer 4.

Score every answer on three axes rather than one: correct (the facts are right), grounded (the facts came from your documents and not from the model's general knowledge), and complete (the customer can act on it without asking again). An answer can be correct and useless, and the difference between a passable and an excellent bot lives mostly in the third column. The characteristics that separate them are worth studying in the piece on what makes a great chatbot response.

Layer 3: Measure Hallucination Explicitly

Grounding a model in your own documents reduces fabrication substantially, but nowhere near to zero, and the gap is exactly why this layer exists. Stanford HAI's study of legal research tools found general-purpose models hallucinating on the majority of legal queries, while retrieval-grounded legal tools cut the rate to roughly a sixth of that, still far too high to leave unmonitored.

The lesson from that spread is not that RAG fails. It is that grounding moves a system from unusable to usable, and testing moves it from usable to trustworthy. Measure your own rate rather than assuming the platform's.

Four probe types reliably surface fabrication:

1. The false premise probe. Ask about a feature, plan, or policy that does not exist. A grounded bot says it has no information. An ungrounded one describes it in convincing detail.
2. The specificity probe. Ask for a number the documents do not contain: an exact SLA in minutes, a precise weight limit, a named integration. Fabrication shows up first in specifics.
3. The adjacent-domain probe. Ask something plausible but outside scope. Bots trained on a narrow corpus often answer from general knowledge without signalling the switch.
4. The citation probe. Ask where the answer came from. If the bot cites a document that does not exist, the answer did not either.

Layer 4: Run the Adversarial Pass

This is the layer the three companies in the opening skipped. The OWASP Top 10 for LLM Applications is the standard reference, and prompt injection has held the top position since the list was created. Every item below has a documented real-world instance behind it.

Record the number of attempts, the number blocked, the exact text of anything that got through, the mitigation applied, and the re-test result. "We tried some jailbreaks and it seemed fine" is not evidence.

Two notes on judgement. Bots reachable without authentication need a stricter pass than internal ones, because the attacker population is everyone. And a bot with tool access, one that can actually issue a refund or update a record, needs authorisation enforced in code, since instructions in a system prompt are a guideline to the model rather than a permission boundary.

Layer 5: Test the Edges and the Handoff

Most of a bot's reputation is made in the small share of conversations it cannot resolve.

• Refusal quality. Verify the bot says it does not know rather than guessing, and that the refusal offers a next step instead of ending the conversation.
• Escalation triggers. Test explicit requests ("let me talk to a human"), implicit frustration ("this is useless"), repeated failures on the same question, and the categories your policy routes to people. Confirm the transcript travels with the handoff so the customer does not repeat themselves. If handover is new to your setup, the guide to AI-to-human handover covers the configuration.
• Out-of-hours behaviour. Escalation with nobody on shift must degrade into contact capture, not a promise nobody will keep.
• Conversation memory. Ask a question, then a follow-up that only makes sense in context ("and what about the annual plan?"). Then change topic entirely and confirm the old context is dropped rather than contaminating the new answer.
• Language handling. If your audience is multilingual, verify the bot answers in the language it was asked in even when the source documents are in another.

Layer 6: Validate Latency, Cost, and Load

Correct and slow is a failed test. Measure at production concurrency, not on an idle staging box:

• Time to first token under one second. Perceived responsiveness is dominated by this number, not by total completion time.
• p95 response latency, not the average. The average hides the experience of the customers most likely to complain.
• Cost per conversation at projected volume, including the retrieval calls. Multiply by your worst realistic month before signing off.
• Behaviour under load. What the widget does when the backend is slow or down. A spinner that never resolves is worse than an honest error with an email fallback.

Layer 7: Test the Interface, Not Just the Model

The model is one component of a product that also has a widget, a mobile viewport, and users who navigate by keyboard.

• Open the widget on a small phone screen and confirm it does not cover the checkout button, the cookie banner, or the navigation.
• Send a very long answer and confirm it scrolls rather than overflowing.
• Tab through the widget with the keyboard, and check contrast in both light and dark themes.
• Reload mid-conversation and confirm history survives.
• Test on the pages that matter commercially: checkout, pricing, and signup, not just the homepage.

The Go or No-Go Decision

Make the launch call against the contract from layer 0, not against a general feeling that it seems to work well.

• Go. All layers pass their agreed thresholds, with evidence attached.
• Conditional go. Failures exist in layers 5 through 7, each with a named owner and a committed fix date, and the risk is accepted in writing.
• No-go. Any unresolved failure in layers 1 through 4. Retrieval failures, ungrounded answers, prompt injection, unauthorised actions, and cross-tenant data access are not launch-with-caveats problems.

A soft launch is the sensible middle path: enable the widget on a low-traffic page or for a fraction of sessions, watch every transcript for a week, and expand once the live failure rate matches what testing predicted.

After Launch, the Checklist Becomes a Regression Suite

The golden dataset does not retire on launch day. Re-run it whenever the knowledge base changes, whenever the system prompt changes, and whenever the underlying model version changes, because a model upgrade can silently alter behaviour that previously passed. Keep the adversarial battery on a schedule rather than running it once. And read real transcripts weekly, since production traffic will surface question phrasings no test set anticipated, and those become new golden entries.

Platforms differ in how much of this they make observable. In Paperchat, the conversations view keeps full transcripts with the escalation and handover state attached, which is what makes weekly review a fifteen-minute job rather than a data export project, and it is where most post-launch golden dataset entries come from.

The Bottom Line

The chatbot failures that become news stories are almost never sophisticated. They are the first thing a curious person tried, on a system nobody had adversarially tested, deployed by a company that assumed the vendor had handled it. A structured pass over retrieval, answer quality, hallucination, adversarial input, escalation, performance, and interface catches essentially all of them, and it takes days rather than months.

The Air Canada ruling settled the question of who owns the output. Testing is how you make sure you can live with owning it.