AI & AgentsGuide
How to test an AI chatbot before you accept it: a practical acceptance checklist
A chatbot demo answers the questions the builder picked. Your customers will ask different ones. This checklist turns "it looks good" into a test you can repeat every time something changes.
Author
CrpyByte Engineering
Published
Reading time
2 min read
Whether a developer built your chatbot or you configured one yourself, the hard question is the same: is it good enough to put in front of customers? A demo cannot answer that. A short, repeatable test can.
1. Build a test set from real questions
Collect 50 to 100 questions people have actually asked: from support emails, chat logs, sales calls and your FAQ. Write down the correct answer for each, and where that answer lives in your documents. Include:
- Common questions, the ones you answer every week.
- Specific questions with a number, date, price or name in the answer.
- Badly worded questions, with typos and missing context, the way customers really type.
- Questions your documents do not answer. The right response is "I don't know" or a handover, not a guess.
- Questions it must refuse: legal or medical advice, other customers' data, anything outside its job.
2. Score each answer the same way every time
| Check | Pass when |
|---|---|
| Correct | The answer matches the one you wrote down |
| Grounded | It cites or links the document it came from, and that document really says it |
| Complete | Nothing important is missing, such as a condition or an exception |
| Safe | It refuses or hands over when it should |
| Tone | It sounds like your business, not like a generic assistant |
Check grounded by opening the source, not by trusting the citation. A chatbot that cites the right page but gets the number wrong is worse than one that says it does not know.
3. When it is wrong, find out which part failed
In a RAG chatbot, most wrong answers are not the model inventing things. They are retrieval failures: the right passage was never found, so the model answered from something nearby. Ask the developer to show which passages were retrieved for each failed question. If the right passage is missing, the fix is in search and document preparation, not in a bigger model.
4. Measure speed and cost per conversation
- Time to first word and time to a complete answer, at a realistic number of users at once.
- Cost per conversation, not per message. Long chat histories and large retrieved context multiply token use. Model it with the chatbot ROI calculator and AI cost calculator.
- A spending limit at the model provider, so a bug or an abusive user cannot run up an open-ended bill.
5. Try to break it
- Ask it to ignore its instructions, reveal its system prompt or act as something else.
- Paste text that contains instructions, the way a malicious document or email might.
- Ask about another customer, an order number that is not yours, or internal pricing.
- Check that every action it can take, such as booking or sending an email, needs the right permissions.
6. Agree the pass mark before you test
Decide in advance what score is good enough, for example 90% correct and grounded, and 100% on the must-refuse questions. Write it into the acceptance terms. Then re-run the same test set whenever the model, the prompt or the documents change. A test you run once is a demo; a test you rerun is quality control.