AI Chatbots for Business Websites: What They Can Handle

An AI chatbot on a business website handles repetitive, factual questions well, provided it answers only from your own approved content: opening hours, published prices, policies, service areas, booking and order status. It handles complaints, exceptions, judgement calls and questions it has no source for badly, and it can be confidently wrong. The difference between a useful chatbot and a liability is mostly in the design around the model: what it is allowed to answer from, when it hands over to a person, and how it treats personal data.

This guide is about chatbots on your website. Automating enquiries that arrive by form or email is covered in AI automation for customer enquiries, and WhatsApp has its own rules, covered in WhatsApp Business automation. An earlier version of this page quoted a '40% ticket deflection' figure as typical. It came from no source I could cite and has been removed: what a chatbot resolves depends entirely on your questions and your content.

How a modern website chatbot works

Most business chatbots worth having are the second type, with a little of the third. The model is not answering from general knowledge. It retrieves passages from a knowledge base you control and writes a reply from them. When that knowledge base is thin or out of date, the bot either says it does not know, which is fine, or fills the gap, which is not.

The third type is starting to become an AI agent, with the guardrails that implies; AI agents for small businesses covers those.

What a website chatbot handles well

• Questions with one settled answer: hours, parking, areas covered, what is included in a service, how long a typical job takes.
• Policy questions: returns, cancellations, deposits and guarantees, as long as the policy is written down and current.
• Finding the right page: 'do you do loft conversions?' answered with a sentence and a link.
• Out-of-hours capture: taking a name, contact details and a description so someone can follow up in the morning.
• Booking and order lookups, where it is connected to the system and the customer can be identified safely.

What it handles badly

• Complaints. An upset customer wants a person. A bot that tries to resolve a complaint usually makes it worse.
• Exceptions and discretion: refunds outside policy, discounts, 'can you fit me in today?'
• Prices that depend on a visit or a conversation. Unless your pricing is published and fixed, the bot should explain what affects the price and offer a quote, not invent a figure.
• Anything sensitive: health details, financial difficulty, safeguarding concerns.
• Questions your content does not answer. This is where confident wrong answers come from.

You are responsible for what it says

A chatbot speaks for your business. In Moffatt v Air Canada, a decision of a Canadian tribunal in February 2024, the airline's website chatbot gave a customer wrong information about bereavement fares. Air Canada argued the chatbot was responsible for its own actions; the tribunal rejected that and held the airline liable, as the American Bar Association's summary explains.

That case is Canadian and I am not a lawyer, but the principle is not exotic: information you give customers on your own website is yours, whichever tool produced the words. In practice:

• the bot answers only from content you have approved
• it says it is not sure and shows how to reach you, rather than guessing
• prices, policies and promises in its knowledge base are kept current
• you review transcripts and fix the source content when it gets something wrong

Design the handoff before the bot

The handoff to a person is the most important part of the design, and the part most often left until last.

Hand over when:

1. the visitor asks for a person, in any wording
2. the conversation is a complaint, or the visitor is clearly frustrated
3. the question involves money outside published prices, or an exception to policy
4. the bot has failed to answer twice
5. the topic is sensitive

When it hands over, pass the whole transcript and the visitor's contact details to whoever picks it up, so the customer does not have to repeat themselves. Out of hours, the handoff is a promise: take the details, say honestly when someone will reply, and make sure that reply happens. A handoff that leads to silence is worse than no chatbot at all.

Tell visitors at the start that they are talking to an automated assistant, and keep a visible way to reach a person throughout the conversation.

UK GDPR before you launch

Chat transcripts are personal data, often more of it than a contact form collects, because people type freely. Before launch:

• Say so in your privacy notice: that a chatbot is used, who provides it and what happens to conversations.
• Have a processor agreement with the chatbot provider, and check where conversations are stored and processed.
• Check whether conversations are used to train the provider's models, and switch that off if you can.
• Set a retention period for transcripts and make sure the tool honours it.
• Discourage sensitive data. The bot should not ask for health or financial details it does not need, and should never take card details in chat.
• Check the cookies. Chat widgets often set cookies or use browser storage; if that is not strictly necessary, it belongs under your consent banner.

GDPR and AI automation for UK businesses covers lawful basis, international transfers and automated decisions in more depth.

Building the knowledge it answers from

The quality of the answers is capped by the quality of the content behind them. Start with the questions you already answer every week, written down properly on your website: service pages, a clear FAQ page, published policies. Then point the chatbot at those pages rather than at a separate document nobody maintains. Improving the bot and improving the website become the same job.

Review a sample of transcripts every week for the first couple of months. Every question it could not answer is either a gap in your website or a question it should hand over.

How to tell whether the chatbot is helping

Record a baseline before launch, then track:

• the share of conversations resolved without a handoff, by your own definition of resolved
• how many conversations are handed over, and why
• wrong or poor answers found in transcript reviews
• enquiries and bookings that started in chat
• complaints that mention the chatbot

Ignore vendor benchmarks for deflection. Your number depends on your questions, not theirs.

A worked example: a wedding venue

Say a venue gets the same twenty questions by phone and email: capacity, available dates, catering options, whether dogs are allowed, the published package prices, parking and nearby accommodation. That is a good fit. The chatbot answers from the venue's own pages, links to the brochure and shows the viewing calendar.

It hands over for bespoke pricing, a date marked as held, a complaint, or a question about a past event. Out of hours it takes the couple's details and says the team replies within one working day, and the venue makes sure that happens. The venue is hypothetical, but the shape applies to most service businesses.

Next step

List the twenty questions your team answers most often and check each has a clear, current answer on your website. If most do, a chatbot is worth considering; if most do not, fix the website first, because the bot can only be as good as that content. Contact form best practices covers the simpler alternative, the AI automation service builds chatbots with the handoff and data protection designed in, and the AI business automation guide puts chat in context with everything else you could automate.