Adding an AI Assistant to Your Website Without Embarrassing Your Brand

Most website chatbots I test fail in one of two ways. Either they are a glorified FAQ that answers nothing, or they are a general-purpose AI model with a logo on top that will cheerfully invent a refund policy, recommend a competitor or write a poem about your pricing. Neither helps a customer. Both end up in screenshots. A good AI assistant is closer to a well-trained new hire than a magic box: a narrow job, the right information, clear rules and a manager to hand over to. Here is how I set one up.

Pick one narrow job

"Answer customer questions" is not a job. It is a category. Start with something specific and measurable:

• Answer pre-sale questions about products, sizing and delivery on an online store.
• Help visitors find the right service page and book a call.
• Answer "where is my order?" by looking up a real order status.
• Point existing customers to the right help article.

A narrow job gives you a narrow set of content to ground it in, a clear definition of success, and fewer ways to go wrong. You can widen the scope once the first job works.

Ground it in your own content

The most important technical decision is where the answers come from. A bare language model answers from its general training, which knows nothing reliable about your delivery times or your returns window. The fix is retrieval, often called RAG (retrieval-augmented generation): when a question comes in, the system searches your own content, such as help articles, product data and policies, and passes the most relevant passages to the model with an instruction to answer only from them.

That has practical consequences for your site:

• Your content has to be good first. If the returns policy is vague on the website, the assistant will be vague too.
• Keep sources current. Re-index when products, prices or policies change, ideally automatically.
• Link to the source. Answers that cite the page they came from are easier to trust and easier to check.

Well-structured pages help here just as they help search engines, which is the same argument I make in SEO-friendly website structure.

Guardrails and refusals

An assistant that says "I don't know" at the right moment is worth more than one that always has an answer. Write the rules down and test them:

• Stay on topic. Questions outside the job get a polite redirect, not an essay.
• No invented facts. If the answer is not in the retrieved content, say so and offer a human.
• No commitments. The assistant does not agree discounts, refunds or delivery dates unless it is reading them from a live system.
• No advice it is not qualified to give. Legal, medical and financial questions go to a person.
• Resist manipulation. People will type "ignore your previous instructions". Test for it, and never give the assistant access to anything it must not reveal.

Before launch, I write a list of awkward questions, including rude ones, off-topic ones, attempts to extract the instructions and questions about competitors, and run them all. Then I run them again after every change to the prompt or the content.

Always offer a way to a human

The hand-off is where most bots fail. Customers should be able to reach a person at any point, not only after three failed attempts. Good hand-offs:

• Trigger automatically on frustration, repeated questions, or sensitive topics like complaints and cancellations.
• Pass the conversation so far to the human, so the customer does not have to repeat themselves.
• Are honest about response times outside working hours, and fall back to a short, well-designed form. The principles in website form UX best practices apply.

Privacy and data handling

People type surprising things into chat boxes: order numbers, addresses, health details, occasionally card numbers. Treat the chat as a data collection form, because that is what it is.

• Tell people they are talking to an AI, and link to your privacy policy from the widget.
• Know where conversations are stored, for how long and who can read them. Set a retention period.
• Check whether your AI provider uses submitted data for training, and choose settings or a plan that does not.
• Mask obvious sensitive data before anything is logged.
• If you have UK or EU visitors, data protection rules apply to chat transcripts like any other personal data.

The wider set of checks is in the website security checklist for 2026.

Give it your tone of voice

An assistant speaks for your brand in every conversation, so write its voice down properly. A useful brief covers:

• Three or four words for how it should sound, with an example answer for each.
• Words and phrases to avoid, including anything your brand would never say.
• Length: short answers by default, with a link for more detail.
• How to apologise, and how not to over-apologise.
• No fake human. A friendly, clearly labelled assistant beats a made-up name and a stock photo.

Do not let the widget slow the site down

This is the part I see neglected most. Many chat widgets load a large bundle of JavaScript on every page, straight away, for a feature most visitors never open. That code competes with your own on the main thread and can hurt Interaction to Next Paint, the Core Web Vital that measures how quickly a page responds to taps and clicks, where "good" is 200 ms or less. I cover the metric in INP explained.

The fix is simple: render a lightweight button yourself and only load the real widget when someone uses it.

<button id="chat-launcher" type="button">Ask a question</button>
<script>
  document.getElementById("chat-launcher").addEventListener("click", () => {
    const s = document.createElement("script");
    s.src = "/chat-widget.js";
    s.async = true;
    document.body.appendChild(s);
  }, { once: true });
</script>

In a real build you also want the widget to open itself once loaded, and a loading state on the button. Make the launcher keyboard-accessible with a clear label, announce new messages to screen readers, and do not let it cover the basket button or cookie controls on mobile. Accessibility is not optional in a chat window any more than anywhere else.

Measure whether it is working

Decide what success looks like before launch, based on the job you picked:

• Resolution rate: conversations that ended without needing a human, checked by reading a sample rather than trusting the bot's own opinion.
• Hand-off rate and reasons: the questions it cannot answer tell you which content is missing from your site.
• Conversions: bookings, sales or enquiries from people who used the assistant.
• Bad answers and complaints: log them, fix the content or rules, and re-test.
• Site speed: compare your Core Web Vitals before and after launch.

Read real transcripts every week for the first couple of months. It is the fastest way to learn what customers actually want, and it often improves the website as much as the bot.

What not to do

• Do not pop the chat open automatically on page load.
• Do not hide your phone number or email address behind the bot.
• Do not launch without testing the awkward questions.
• Do not connect it to systems that can change orders or accounts until a read-only version has earned trust.
• Do not set it up and forget it. Your content changes, and so should the assistant.

AI is useful here, but only with the same care as any other part of the build, which is the argument I make in how AI is actually changing web development.

Thinking about an AI assistant for your site? Tell me what you want it to handle and I will tell you whether it is worth building, and how to do it without slowing your site down.