---
title: "How to Add an AI Chatbot to Your Help Centre"
canonical: https://supportpages.io/guides/add-an-ai-chatbot-to-your-help-centre
updated: 2026-08-13
---

An assistant that answers from your documentation, with its failure modes handled before launch rather than discovered by a customer. The central fact to plan around: a retrieval bot is an amplifier. It inherits every gap, contradiction and out-of-date page in your corpus, and restates them fluently enough that readers stop checking.

## Before you start

You need a corpus worth retrieving from, a working escalation path to a human, and a decision about conversation logging that your privacy notice covers. Customers paste order numbers, email addresses and occasionally credentials into chat boxes, so those transcripts need the same handling as support tickets.

Audit the documentation first. If you already know that a third of your articles describe last year's interface, a bot will surface them more efficiently than your search box currently does.

## Steps

1. **Fix the worst of the corpus before launching anything.**
   Start with the highest-traffic articles and anything touching billing, security or data deletion. A retrieval system cannot tell a current page from a stale one, and confidence is uniform across both.

2. **Choose retrieval over fine-tuning.**
   Retrieval lets you correct an answer by editing an article. A fine-tuned model bakes today's documentation into weights and needs re-training to fix a typo in your pricing.

3. **Scope the source set explicitly.**
   Documentation and help articles in; marketing pages, old release notes, the blog and aspirational roadmap posts out. Most early wrong answers trace back to a page that was never meant to be an authority.

4. **Require a citation on every answer.**
   Each response links the article it came from. This gives the reader a way to verify, gives you a way to debug, and makes the "no source found" case visible instead of silently filled in.

5. **Define and test the refusal.**
   Write the exact wording for "I don't have information about that", then test it against a list of questions you know are uncovered. A bot that never refuses is a bot that invents, and you find out from a customer.

6. **Put escalation to a human on every response, one click.**
   Not in a menu, not after three failed attempts. The measure of a good deployment is how quickly a stuck person reaches someone, not how long the bot keeps them.

7. **Forbid whole categories outright.**
   Account-specific questions, refunds, security commitments, legal terms and pricing exceptions route straight to a person. These are the answers where being wrong costs real money.

8. **Test against real transcripts, not invented questions.**
   Take fifty genuine tickets, run them through, and read every answer with the actual resolution beside it. Invented test questions are written in your vocabulary, which is the vocabulary the bot handles best and customers use least.

9. **Say plainly that it is a bot.**
   A human name and an avatar buy a small amount of warmth and cost a large amount of trust the moment somebody works it out.

10. **Read the unanswered log weekly.**
    Every question the bot could not answer is a documentation gap with a customer attached. This log is the most valuable thing the deployment produces, and it is the thing teams most often never open.

## Common mistakes

**Launching over a corpus you already know is stale.** The bot does not average out bad pages, it retrieves them faster. Deployment converts a documentation problem you could ignore into a support incident you cannot.

**Measuring success by containment rate.** A conversation "contained" by the bot looks identical to a customer giving up. Rewarding containment rewards making escalation harder, and the damage shows up in churn rather than in the chat dashboard.

**Letting it answer account-specific questions from general documentation.** "How do I cancel?" is documentation. "Will I be charged if I cancel today?" depends on the account, and a plausible general answer to it is a billing dispute.

**Treating citations as decoration.** A link that does not actually contain the claimed answer is worse than no link, because it transfers your documentation's authority to something the model assembled.

**Never reading the logs.** The conversations are a ranked list of what to write next, and they go unread in most deployments because nobody owns them.

## When this stops scaling

The bottleneck is corpus coverage and freshness, not the bot. A deployment behaves well while your documentation covers most of what people ask and describes the current product. It degrades on the schedule your product ships: every release that changes a screen or a flow adds a set of confidently wrong answers, and no bot configuration compensates for that.

The practical threshold is when the product changes faster than anybody is updating the articles - for most teams, weekly releases against documentation reviewed quarterly. Past that point, work on the corpus rather than the bot. Generating articles from the codebase and flagging them when a merged change makes them wrong is the approach [SupportPages](https://supportpages.io) takes, and any method that keeps articles current will do. The order matters more than the tooling: a bot on top of current documentation is useful, and a bot on top of stale documentation is a faster route to a wrong answer.