A chatbot can help customers find information, choose a service or reach a person outside normal opening hours. It does not automatically improve sales or customer experience: the outcome depends on the use case, knowledge sources, interface, oversight and what happens when the system reaches its limits.
A chatbot needs a bounded task
Begin with the problem the chatbot should solve. Useful cases may include answering recurring questions, narrowing a service choice, directing someone to an appointment, checking an order status or collecting relevant context for a human adviser. Define the objective from both the user's and the business's perspective before choosing a product.
A chatbot cannot compensate for a deficient website. Pricing context, delivery terms, contact details and other essential information should remain available without a conversation for search engines and for people who do not want to use a bot. If question volume is low or every answer requires a case-specific expert assessment, clearer content and an accessible contact route may be the better investment.
Rules, generative AI or a hybrid?
A rules-based bot guides users through predefined choices. It is predictable and suits bounded processes, but has limited flexibility with free-form questions. A generative chatbot can interpret natural language and compose answers from a knowledge base, but it can also produce incorrect information in a confident tone.
For many companies, a hybrid is sensible: identify the free-form question, constrain the answer to approved sources and handle critical stages such as personal-data collection or booking through a controlled flow. Choose the approach according to the impact of an error, the information that must be maintained, integration needs and the level of oversight required.
| Approach | Best suited to | Primary risk |
|---|---|---|
| Rules-based | bounded choices and standardised processes | the flow does not cover the real question |
| Generative | broad knowledge and varied questions | an incorrect or unsupported answer |
| Hybrid | advice followed by a controlled transaction | unclear boundaries and ownership |
Knowledge sources, boundaries and testing determine answer quality
An AI chatbot does not simply learn a company website reliably. The implementation needs approved sources, update cycles, a retrieval and citation method, and situations in which the bot must not answer. Prices, availability, contractual terms and other changing facts should come from a current system or direct the user to a source the business can maintain.
NIST identifies confident presentation of false information as a material generative-AI risk. Testing therefore needs more than a few straightforward questions. Include ambiguous wording, spelling errors, missing context, conflicting sources, out-of-scope requests and cases where the correct behaviour is to decline or transfer the conversation to a person.
- named and approved sources with accountable owners
- subjects the chatbot may and may not answer
- a process for uncertain, outdated or conflicting information
- test data, acceptance criteria and regression testing after changes
Human handover and accessibility are core requirements
Tell users immediately what the bot can do, what it cannot do and how to reach a person. A handover button is not enough if no one receives the conversation: define service hours, expected waiting time, the responsible team and whether the conversation history transfers. Complaints, safety matters and other consequential situations need a justified path beyond open-ended automation.
The chat interface should work by keyboard, with a screen reader and on a small display. Focus, status messages, errors and new replies need to be communicated clearly, and the widget must not cover essential page content. Users should be able to close it, find the same basic information elsewhere and return to the conversation without losing control.
Plan privacy, transparency and security before launch
Establish what conversation data is stored, for which purpose and legal basis, for how long, and which suppliers process it. Collect only information the use case needs and discourage unnecessary sensitive data where possible. Contracts should also cover use of data for model development, subprocessors, locations, access controls, deletion and incident handling.
The European Commission states that the AI Act's Article 50 transparency obligations have applied since 2 August 2026. An AI system intended to interact directly with people must be designed so that a person is informed that they are interacting with AI unless this is obvious from the circumstances and context. Procurement should establish who provides the notice and how other applicable duties are assessed. This article is not legal advice.
A pilot should demonstrate value without generic ROI promises
There is no universal payback period or traffic threshold at which a chatbot becomes worthwhile. Limit a pilot to one useful case, document the baseline and agree success and stop criteria in advance. Costs should include implementation, integrations, knowledge maintenance, quality assurance and human work rather than only the software subscription.
Useful measures include resolution rate, successful handovers, unanswered questions, incorrect-answer rate, customer feedback and qualified enquiries. Conversation volume alone does not establish value. Each finding needs an owner who can correct the content, boundary or operating process.
- a bounded use case and documented baseline
- acceptance testing for answer quality, privacy and accessibility
- a human-handover process with an agreed service level
- ownership, cost and reporting for ongoing maintenance
When you want to assess a chatbot as part of a usable and measurable website, explore our business website service.
Sources and further reading
The sections on AI transparency, risk, data protection and accessibility are based on official material from the European Commission, EDPB, NIST and W3C.
