FajarMost AI chatbots fail for boring reasons. The model is rarely too weak. More often nobody built an escalation path, nobody capped the token spend, and nobody wrote an evaluation before launch. The consequences are real: in Moffatt v. Air Canada (2024), a Canadian tribunal held the airline responsible for wrong information its website chatbot gave a customer.
This is the pre-launch checklist our team works through. It has 17 items in four groups.
Grounding and Knowledge (Items 1 to 4)
1. Ground Factual Answers in Retrieved Content
If the bot answers questions about your product, prices or policies from the model’s general training, it will sometimes produce confident nonsense. Factual answers should come from a retrieval step over your docs, help center or database, with the model told to answer only from that context. Retrieval has failure modes of its own, covered in RAG in production: what breaks.
2. Give the Bot a Way to Say It Does Not Know
The system prompt needs a literal instruction for the case where the context does not answer the question: say so, and offer to connect the user with a person. Bots without an approved exit invent one. Test this path with questions whose answers are deliberately missing from your content.
3. Give Every Document an Owner and a Review Date
Stale content does slow damage. If nobody owns the pricing page in the index, the bot will quote last quarter’s prices. Re-run ingestion when content changes, not on a weekly timer.
4. Test With Real User Phrasing
Your team asks questions the way your docs are written. Customers do not, and they often call a feature by a different name. Pull 100 real queries from the support inbox or search logs and run them before launch.
Escalation and Safety (Items 5 to 8)
5. Build the Human Handoff First
The most important feature of a customer-facing bot is a working handoff to a person, with the transcript and the retrieved documents attached so the agent does not start from zero. We build it before prompt tuning starts.
6. Define Hard Escalation Triggers
Some topics should go to a person however confident the bot is: legal threats, medical or safety issues, mentions of self-harm, account cancellation or deletion, repeated frustration. Agree the list with your legal and support leads, implement it with keyword rules and a classifier, and test each trigger.
7. Guard Both Input and Output
The OWASP Top 10 for LLM Applications puts prompt injection first, and also lists system prompt leakage and misinformation. Input checks catch injection attempts and off-topic use. Output checks catch leaked instructions, unapproved competitor comparisons, and commitments such as refunds or discounts that the bot has no authority to make.
8. Put the Bot’s Authority in Code
Can the bot issue a refund, and up to what amount? Each action needs an allowlist with limits, agreed with the business owner and enforced by permission checks in the API. A prompt is a request to the model. A permission check is a control. OWASP calls the failure here excessive agency.
Evaluation and Quality (Items 9 to 12)
9. Write Evals Before Tuning Prompts
Build a set of 50 to 150 real questions with graded reference answers, split across easy, hard and must-escalate cases. Run it on each prompt or model change.
10. Calibrate the Model Judge Against People
Grading with a strong model makes evals affordable, but check the judge first: have a person grade 50 outputs, have the judge grade the same 50, and compare. The paper Judging LLM-as-a-Judge found strong judges agreeing with humans more than 80% of the time, and documented position and verbosity biases. If agreement on your data is lower than that, tighten the rubric.
11. Test Multi-Turn Conversations
Single-question evals miss how real conversations degrade: a topic change mid-thread, a correction, a huge pasted block, a follow-up that depends on something said three turns earlier. Script at least 20 such scenarios.
12. Hold a Red-Team Hour
Put five colleagues in a room with one instruction: break it. Extract the system prompt, make it promise a refund, make it criticize a competitor. Log the attempts and fix the top findings.
Operations and Cost (Items 13 to 17)
13. Cap Cost per Conversation and per Day
Set a token budget per conversation and a daily spend ceiling with alerts, for example at 50% and 80%. One retry loop, or one person scripting requests against the endpoint, can multiply a monthly bill. OWASP lists this risk as unbounded consumption.
14. Rate Limit per User and per IP
Without per-user limits, the bot becomes a free model API for anyone who finds the endpoint. Limit conversations per hour and messages per minute, and require a session identity even for anonymous visitors.
15. Log Conversations, and Decide What Happens to the Data
Store transcripts with the retrieved documents, model and prompt version, latency, token counts, escalations and user feedback. Set a retention period, and redact personal data you do not need.
Customers will ask whether their conversations are used to train AI models. Our answer is: not by us. We use providers’ API tiers whose terms exclude training on your data, and we confirm the current terms with you. OpenAI’s API data controls page, for instance, states that API data is not used for training unless you opt in. Terms change, so check them again at launch.
16. Measure Resolution, Not Deflection
Deflection rate flatters a bad bot: one that frustrates users into giving up “deflects” very well. Track resolution rate, escalation rate, a per-conversation thumbs rating, and the reopen rate on conversations the bot marked as resolved.
17. Plan the Model Swap Before You Need It
Models are deprecated, prices change, and better ones arrive. Keep the model name, prompts and generation settings in config, and keep the eval suite ready so a new model can be qualified quickly. Our comparison of GPT, Claude and Gemini covers the selection criteria.
How to Run the Checklist
Items 1 to 8 are build requirements: they go into the plan as tickets with owners, with the handoff (item 5) built first. Items 9 to 12 form a release gate about two weeks before launch, and the date moves if the eval thresholds are not met. Items 13 to 17 are verified in production, not staging, because cost caps have a habit of existing in a config file and not in the deployed environment. For a wider governance frame, see the NIST AI Risk Management Framework.
Then launch in stages: internal staff for a week, then a small share of real users, then a quarter, then everyone, reviewing resolution rate, escalation rate and cost per conversation at each step. A retrieval bug caught at a small share of traffic is a quiet fix. At full traffic it is a customer-trust problem.
Notice what is missing from this list: picking the perfect model, fine-tuning, agent frameworks. Those choices usually matter less than grounding, escalation, evals and cost controls. A first version of a chatbot typically takes 4 to 6 weeks, and much of that time belongs to the items above. If you are planning one, our AI and automation team can help, and you can get a quote once you know the use case.
