A customer asking a chatbot about returns wants the actual return policy. A fast, confident answer is unhelpful if it promises a refund the business cannot provide. That makes a chatbot project a service-design task before it is a technology purchase.
Whether you run a small business or are considering building chatbots for clients, start with a narrow service you can maintain. A first version might answer questions about opening hours, published shipping options, and where to find an instruction sheet. It should have a clear route to a person when those sources are insufficient.
Write down what the chatbot can do
Choose a limited list of question types. For each, identify the approved page or document that contains the answer, the person responsible for it, and the date it was checked. Resolve contradictory policies before connecting them to AI.
Separate answering from acting. Explaining the published refund process is different from approving a refund or changing an order. Keep a first pilot read-only: no charges, account changes, bookings, or promises made on a customer’s behalf.
Specify what happens outside that scope. “I cannot confirm that here; contact this team” is a useful answer when paired with a working contact route. An instruction to “always be helpful” should not override a missing fact.
Make the customer handoff work
Tell visitors they are talking to an automated assistant. Put the human contact option where it can be found without an argument. State actual support hours and expected response times only when the business can support them.
A handoff should not make people repeatedly explain a problem. Decide what information may be passed to staff, tell users how the conversation is handled, and avoid collecting unnecessary details. A general FAQ bot rarely needs a password, payment-card number, identity document, or full medical history.
Ask the provider where conversations are stored, who can access them, how long they are retained, whether they are used to train models, and how deletion works. Check the answers in the product’s current documentation and agreement. A setting in one plan may not apply to another.
Test answers against a written answer sheet
Create fictional test questions and expected outcomes before the vendor demonstrates the bot. Include routine questions and difficult variations:
- A straightforward question with a clear answer in the approved source.
- The same question with a typo or indirect wording.
- A question about an expired promotion or an unavailable product.
- A complaint that needs a person rather than a reassuring sales response.
- A request for another customer’s order or contact details.
- A demand that the chatbot ignore its instructions and invent a discount.
Check whether it cites the relevant source, preserves conditions and exceptions, and acknowledges when it cannot answer. Do not count a pleasant-sounding response as correct until someone compares it with the policy.
For example, an exchange window of “30 days after delivery” is not interchangeable with “30 days after purchase.” A customer asking about an opened item may need an exception that a generic summary omits. These are illustrative tests, not claims about a particular platform.
Treat security as more than a prompt
OWASP’s prompt-injection guidance explains that user input and material from external sources can alter a model’s behavior. Connecting a chatbot to a document library does not by itself remove that risk.
Have the implementer restrict access to approved information and enforce permissions outside the language model. Ask them to demonstrate that one user’s session cannot retrieve another user’s data. Do not put secrets in the chatbot’s instructions and assume a sentence saying “never reveal this” protects them.
If the bot later gains the ability to perform actions, that is a new project scope. It needs explicit authorization rules, independent validation, logs, and a way to stop or reverse mistakes. It should not inherit broad account privileges merely because a demonstration went well.
Price the ongoing service
Request an itemized quote covering setup, integration, usage limits, overage charges, maintenance, and support. Identify who updates answers when the business changes a policy and who responds when the chatbot fails. If you sell this service, describe those responsibilities and exclusions in the proposal.
A recurring fee should correspond to real work or service provided, not a promise that AI will run itself. For help evaluating a supplier, see what to ask before hiring an AI consultant.
Run a limited pilot and review a privacy-conscious sample of conversations. Track correct answers, successful handoffs, repeated misunderstandings, and staff time needed to fix problems. The number of conversations handled is not enough: customers may be trapped in unhelpful exchanges.
Keep an ordinary contact page available and assign someone who can disable the chatbot promptly. Expand its scope only when the evidence supports doing so. The goal is a customer who gets a dependable answer or reaches the right person with less effort.
AI disclosure: This article was written and revised with AI assistance. Sources checked September 25, 2026. See our disclaimer.