Before accepting a quote for an AI chatbot, give each vendor the same questions and failure tests from your real customer workflow. A demonstration that answers five easy prompts does not show what happens when a customer is angry, asks for a refund, uses another language or submits personal information. A small Singapore business should agree the bot's boundaries, handoff and data terms before paying for a build.

What may the bot say and do?

List the approved sources it may use: current product pages, opening hours, service areas, booking rules and an escalation path. Mark topics it must not decide, such as refunds outside written policy, medical or legal advice, or a promise of stock that the system cannot verify. Decide whether it merely drafts a response or sends one, and whether it can take a transaction. The IMDA starter kit for testing LLM applications provides a current framework for thinking about safety and reliability tests; the firm's own acceptance criteria should reflect its customer risks.

IMDA's generative-AI chatbot transparency guidance is also relevant to how a user understands that they are speaking with a bot and what information supports its responses. The PDPC obligations overview gives the data-protection context when customers enter personal details. Ask the vendor where conversations are stored, whether they are used to train a model, who can review them and how deletion or export works. A vendor must answer for the exact proposed configuration, not just a generic platform.

How do you build a useful 20-question test set?

Use five ordinary questions, five ambiguous ones, five cases requiring a human and five deliberately difficult or out-of-scope prompts. For a fictional repair business, ordinary questions might ask opening hours or whether a diagnostic visit is offered. Ambiguous questions might omit the appliance model or address. Human cases might involve a disputed invoice or a safety concern. Difficult prompts might ask the bot to invent a discount, disclose another customer's booking or ignore the company's refund rule. Write the expected safe response beside each question before the vendor runs the test.

Score each response for factual correctness, clarity, appropriate uncertainty, handoff and absence of invented promises. A response can fail even if it sounds friendly. Re-run the set after the vendor changes instructions, the source documents or the model. Test the language and phrasing your customers use, including common Singapore terms and any language the vendor claims to support. A translated greeting does not prove the bot can handle a complaint accurately in that language.

Which commercial terms belong in the quote?

Ask for setup work, content preparation, integrations, monthly platform fee, usage or message charges, monitoring, retraining, support hours, change requests and exit or export costs. Identify who owns the approved source material and who can turn off automated replies during an incident. Require a pilot with measurable acceptance criteria and a stop rule. For example: the business will review all 20 cases and pause launch if the bot invents a price, fails to escalate a safety question or exposes test personal data. That is an illustrative acceptance rule, not proof that a vendor passes.

The AI-agent-versus-chatbot guide helps set autonomy, the customer-enquiry approval guide defines human handoff, and AI guides collect related decisions. You may send Methodology a question about a test brief as an editorial enquiry. We do not certify a vendor, guarantee a business result or share your enquiry with one without separate permission.

Common questions

Is a polished vendor demo enough to accept a chatbot quote?

No. Run the same ordinary, ambiguous, human-handoff and out-of-scope tests on the proposed configuration and review the commercial and data terms.

Should a chatbot answer every customer question?

No. Define topics it may answer and cases it must hand to a person, especially where facts are missing or consequences are serious.

Does the repair-business example describe a tested supplier?

No. It is a fictional 20-question method for checking a proposed bot before purchase or launch.

Sources

Something changed or worth adding?

Send a correction or suggestion