An AI chatbot for your website should help visitors finish a task: understand a service, find a policy, prepare an enquiry, or reach the right person. A convincing conversational style is not enough. If the answers are unreliable or the chat blocks normal navigation, the feature can create more work than it removes.
Before choosing a widget, write a short service description for the chatbot itself: who it helps, which questions it answers, what it must not promise, and how a visitor can bypass it. That definition becomes the basis for its knowledge, interface, and tests.
Start with approved questions and answers
Collect the questions your customers actually ask. Group them by topic and identify the authoritative page or document for each answer. Opening hours, supported services, booking steps, and published policies are easier starting points than bespoke pricing or advice that depends on a customer's circumstances.
Create a small knowledge inventory with an owner and review date. Remove outdated offers and conflicting versions. A chatbot cannot resolve a policy disagreement that the business has not resolved. Better information architecture may reduce support requests even before AI is introduced.
Choose retrieval before unrestricted improvisation
A retrieval-based assistant searches approved material and supplies relevant passages to the model. This can make answers more grounded, but retrieval is not a guarantee of accuracy. Documents may be missing, questions may be ambiguous, and a model can still produce an unsupported conclusion.
Require the assistant to say when information is unavailable. For example: “I cannot confirm a delivery date from the published information. Would you like the contact details?” is better than a confident invented deadline. Where practical, link the answer to the relevant service or policy page so visitors can inspect the source.
Design the human handoff first
Keep a visible contact route outside the conversation. If the visitor requests a person, receives repeated unhelpful answers, or asks something outside the approved scope, offer a clear next step. Explain whether the handoff is live chat, an email, or an enquiry form; do not imply instant staff availability unless it exists.
If a transcript is transferred, tell the visitor what will be shared and avoid collecting unnecessary personal information. Preserve the user's message if submission fails. A chatbot should not be the only route to a quote, a complaint, or an accessible form.
Assume some input will be hostile
Visitors and retrieved documents can contain instructions that attempt to override the assistant's intended behavior. OWASP's prompt-injection guidance explains this risk. Treat external text as data, restrict tool permissions, and validate actions outside the model rather than trusting a prompt alone.
For an initial support assistant, read-only access is often sufficient. Do not give it broad access to email, order changes, or administrative functions merely because an integration makes that easy. Keep secrets off the browser and prevent chat responses from exposing internal instructions or private records.
Make the interface useful on a phone
Avoid automatically opening a large dialog over the page. Give the launcher an accessible name, keep keyboard focus visible, and ensure the conversation can be closed without losing the underlying task. Test with the mobile keyboard open; message controls should remain usable rather than disappearing behind it.
Load nonessential chat code when needed instead of competing with the main content. Check the effect on mobile Core Web Vitals. A support feature should not slow every visitor's first impression when only some visitors use it.
Test answers, boundaries, and operations
- Ask common questions in different wording.
- Test an answer that is absent from the knowledge base.
- Try conflicting, outdated, and misleading information.
- Request an unauthorized action or private record.
- Check keyboard navigation, mobile layout, and human handoff.
- Confirm logs, retention, error alerts, and ownership.
Common questions
Will a chatbot replace a good FAQ?
No. Clear, indexable service and FAQ pages remain valuable. Chat can help visitors navigate them, but it should not hide essential information inside a conversation.
How should success be measured?
Track successful task completion, unanswered questions, correction rates, and useful handoffs. A long conversation is not automatically a successful conversation.
For the wider process, see what to automate first. If your website needs a carefully scoped assistant, discuss its knowledge and boundaries before selecting the widget.