AI and integrations
AI chatbots for business websites: uses, limitations and human handover
A useful chatbot has a defined job, dependable information and a clear route to a person. Start with the customer questions you can support well.
An AI chatbot can help a visitor find an answer, narrow down a service or leave the information your team needs for a useful reply. It can also give a confident answer your business never approved. The difference often begins with how narrowly its job is defined.
Before choosing a provider, collect the questions your team actually receives. Identify which have dependable answers and which need judgement or access to live systems. That exercise gives you a more useful starting point than a feature list.
Choose one useful customer task first
Start with a task you can explain in a sentence. A support assistant might help visitors find instructions for an existing product. A service assistant might explain your published process and collect a short project brief. A property assistant could help someone find the right enquiry route, while leaving availability confirmation to the team or an authorised live data source.
Consider whether a clear FAQ, better navigation or a short form would solve the same problem. Use conversation where it makes the task easier for the customer. Keep the original contact route available so nobody has to use a chatbot to reach your business.
Keep approved information separate from live actions
Make a small, maintained source of approved information: services, opening hours, process descriptions and product documentation. Assign an owner to keep it current. If two pages disagree, resolve the underlying information before feeding both to an assistant.
Live information needs a different arrangement. A chatbot cannot reliably confirm a booking, property availability or a payment just because it has read a page about them. Those actions require the right system integration, access controls and a clear confirmation step. Explain when the assistant is sharing published guidance and when a person still needs to confirm the answer.
Give every conversation an exit
- Understand
Define the question or task.
- Answer
Use approved, current information.
- Escalate
Pass uncertainty to the right person.
- Confirm
Check the request was received.
Give uncertain answers a safe exit
Generative systems can produce inaccurate answers that sound convincing. The NIST generative AI risk profile identifies this risk as confabulation. A sensible website assistant needs explicit handling for missing information and questions outside its scope.
For example, when a customer asks whether a service includes a specific guarantee, the assistant should use an approved policy or pass the question to your team. It should not improvise commercial promises. Test questions with false assumptions too, such as a request to explain a discount that does not exist.
Design the handover before launching the chat
Make “speak to a person” an obvious option. State whether the next step is live chat, an email or a callback request, and give a response expectation your team can actually meet. If nobody is online, say so clearly.
With the visitor informed about the data being shared, pass a concise summary and only the details needed to continue. Your team should be able to see what was asked, what the assistant answered and what is still unresolved. Test that the destination inbox or CRM receives the request. A successful-looking chat window is not proof that a human ever received the handover.
The same delivery check matters outside chat. Our enquiry journey guide shows how to follow a message through to the receiving team.
Be deliberate about data and permissions
List the information the assistant collects, the services it sends that information to and how long records are kept. Avoid asking for passwords, payment-card details or sensitive documents in a general website chat. Make the privacy information accessible where the conversation begins.
If the assistant can use tools, give each integration the smallest access it needs. Start with read-only lookups where practical. Actions such as changing records, placing an order or sending a message need separate controls and testing. A visitor message or an uploaded page should never be treated as permission to expand the assistant’s access.
Test real conversations before widening the scope
Build a small test set from actual questions, with personal details removed. Include unclear wording, outdated information, requests for a person, attempted misuse and situations where the right answer is “I need the team to confirm that.” Review the full conversation, including delivery of any follow-up request.
- Did the visitor complete the intended task?
- Were answers supported by current approved information?
- Did uncertain questions reach the right person?
- Could the team correct an answer and update the source?
Keep reviewing conversations after launch, with appropriate privacy controls. Expand only when the narrower task works reliably enough for the business. A useful assistant should save the visitor effort and give your team better context, rather than merely increase the number of chats.
Sources and further reading
Technical references used for this guide. The checklists and examples are our practical recommendations, adapted to the subject.
WordPress development, website care and practical web integrations. Meet the agency.
