Guide · Updated
How to launch an AI support chatbot for your SaaS
An AI support chatbot answers customer questions from your own docs, links the page it used, and hands the rest to a person. Whether you call it a docs chatbot, a help center chatbot, or a knowledge base chatbot, the same three things decide if it helps: the content it reads, what it does when that content is silent, and whether anyone keeps the content current.
What is an AI support chatbot?
An AI support chatbot is a chat window that answers product questions by finding the right page in your documentation, writing a short answer from it, and linking that page. It is not a general chatbot with your logo on it. When the docs do not cover a question, a good one says so and hands off instead of guessing.
The names change with where the bot lives. A docs chatbot sits on a developer docs site. A help center chatbot sits on support articles. A knowledge base chatbot reads an internal or public article library. Under the hood they are the same system: search your content, answer from what it finds, cite it, and refuse when it finds nothing solid.
What should a SaaS support chatbot answer, and what should it hand off?
Let it answer documented, repeatable questions: setup, integrations, plan limits, public billing rules, troubleshooting steps, and how a feature works. Hand off anything that depends on one customer's account, money already charged, security, or a promise only a person can make. A short table keeps everyone honest about the split.
| Question | Who answers | Why |
|---|---|---|
| How do I set up recurring invoices? | Chatbot | Documented, same answer for everyone |
| What does the Pro plan include? | Chatbot | Public pricing page |
| Why was my card charged twice? | Person | Needs account and payment data |
| Can you extend my trial? | Person | A decision, not a fact |
| Is my data affected by this incident? | Person | Security, needs care and accountability |
The example uses Ledgerloop, an invoicing SaaS we use in examples. Your own list comes from your last hundred support conversations: sort them into “the docs answer this” and “a human has to look”.
Which content should the chatbot read?
Point it at the pages a customer should trust: your help center or docs site, getting started guides, integration guides, troubleshooting articles, the pricing page, and release notes. Leave out the marketing homepage, old blog posts, private drafts, and anything that contradicts the product docs, because a bot cannot tell which of two conflicting pages is right.
- Include: help articles, docs, API reference, pricing and plan limits, changelog, support policies
- Exclude: login pages, app shells, outdated announcements, internal notes, pages you would not send a customer
- Fix before launch: duplicate articles, two pages that disagree on a limit, giant pages that mix five topics
If you have almost no docs yet, write your ten most asked answers first. A chatbot over thin docs is a polite way of saying “I don't know” very often.
How do you stop it from making things up?
You stop invented answers with three rules, not a clever prompt. Answer only from retrieved pages. Show the page you used. When retrieval comes back weak, say the docs do not cover it and offer a person. A bot that answers everything confidently looks great in a demo and costs you in production, where one invented plan limit becomes a refund request.
Citations do double duty. Customers can check the answer and keep reading. Your team can open the cited page when an answer is wrong and see whether the problem was retrieval (wrong page picked) or content (the page itself is wrong or missing). We go deeper on this in Why AI customer support needs citations.
Where should the chatbot live: help center, docs, or inside the app?
Start where people already look for answers: the help center or docs site. Visitors there are trying to solve something, and every question maps cleanly to an article. Add the widget to the app or marketing site once you know which questions come up and how often the bot hands off.
Inside the app, questions get more account specific (“why can't I see the export button?”), so the handoff path matters more. On the marketing site, questions lean toward pricing and fit, which the pricing page and a few comparison answers usually cover.
How do you launch it without embarrassing yourself?
Test it on real questions before any customer sees it. Pull ten questions from recent tickets, including two your docs do not cover. A launch ready bot cites the right page on the eight and declines the two. If it invents an answer, fix the source page or what it reads, not the prompt.
- Pick the source: your help center or docs, not the whole website.
- Import or crawl it, then read the list of pages it found.
- Ask your ten real questions and score each answer: right page, faithful to the page, honest refusal when uncovered.
- Write a clear handoff message and decide where handoffs go (email, Slack, your helpdesk).
- Put it on the help center first, then expand.
- Read every refused question for the first two weeks. That list is your docs to do list.
What should you measure after launch?
Measure whether customers got correct answers, not only how many chats happened. Track the share of questions answered from docs, the handoff rate, “not helpful” votes, which pages get cited most, and the questions it could not answer. The last one is the most valuable: it tells you exactly which articles are missing or unclear.
Deflection matters, but a chatbot that deflects with wrong answers just moves the ticket to next week. If the same topic keeps coming back after the bot answered it, the article behind the answer needs work.
Why is a chatbot only as good as the docs behind it?
The chatbot repeats whatever your docs say, so it gets worse every time you ship and the docs don't change. Rename a setting, change a limit, or move a button, and the bot keeps citing the old article with full confidence. Most teams launch the bot, then quietly lose trust in it over a few releases without knowing why.
So plan for two kinds of upkeep. When code changes, the articles it affects need edits; see What is documentation drift?. When customers ask things the docs never covered, those questions need new articles; see How to find what's missing from your help center. A chatbot with both loops gets better after launch instead of drifting.
How does usedocs handle this?
usedocs is a help center with the chatbot built in. It answers from your published articles with a link to the source and says so when the docs do not cover a question. Handoffs go to your team by email, with alerts in Slack, Discord, or Teams. The widget adds a Home screen, saved conversations, help search, your changelog, and a contact form.
It also keeps the docs behind the answers current. Merged pull requests become proposed edits to the articles they affect, and questions it could not answer become ranked gaps with drafted articles. You approve both in one review queue. Plans start with a 7 day free trial, no credit card, then $99/mo with 2,000 AI conversations a month.
FAQ
Can an AI support chatbot replace human support?
No. It can take the repetitive documented questions off your plate, but account problems, billing disputes, and anything it can't find in the docs should go to a person.
Is a docs chatbot the same as a help center chatbot?
Yes, in how it works. Both search your content and answer from it with a citation. The difference is only which pages it reads and where the widget sits.
Is a chatbot better than site search?
They do different jobs. Search finds pages when people know the right words. A chatbot matches the way customers actually phrase things and answers across pages, with links to keep reading.
Should a support chatbot answer billing questions?
Public ones, yes: plan limits, what each plan includes, how to change plans. Questions about a specific charge or refund should hand off to a person.
What content should I give it first?
Your help center or docs, the pricing page, integration guides, troubleshooting articles, and the changelog. Skip marketing pages and old posts.
How often should it resync with the docs?
Whenever the docs change. A bot trained once is a bot trained on last quarter, so prefer a tool that reads your published articles directly or resyncs after every release.
Use usedocs for this
usedocs answers from your help center with a link to the source, says so when the docs can't answer, and keeps the docs current from your code and your customers' questions.