Point an AI chatbot at your documentation and have it stay honest

Pointing a bot at your documentation takes about five minutes in the dashboard. The harder question is what it does when your pages do not cover what somebody asked.

We use Deacon here, our own AI customer support agent, because we can show you what it does at each step instead of describing it in general. The free plan takes no card if you want to follow along.

What trains straight away and what waits

Getting your content and learning your content are two different steps, and knowing which one you are in tells you what your visitors are being told right now.

Anything you hand over outright trains on the spot. Paste an FAQ, upload a file, write an answer, and it is cut up and learned without you pressing anything. The dashboard shows Training… and then Trained.

A website crawl is the one that waits. It fetches pages and lists them for you, and none of them is learned until you say which ones you want and press Retrain agent. That is deliberate, because a crawl of your own site always finds more pages than you want it learning from.

An edit to something already trained waits too. The source is tagged Changed, the version your visitors have been getting keeps answering, and the new one goes in at the next retrain. So there is never a window where your bot knows nothing because you were halfway through rewriting a page.

Getting your content in

Four ways, and the dashboard labels them Add website, Add file, Add text and Add Q&A.

A website crawl walks the pages it can find from the address you give it and turns each one into clean text, leaving the menus and cookie banners behind. Pages arrive as they are found. You can also paste a single page’s address when you only want one article.

A file can be a PDF, a Word document, a spreadsheet export or plain text. A PDF is read page by page by a model that can see it, so a scan, a table or a diagram survives as text instead of coming back empty. Pasted text is the fastest route for an FAQ you have already written somewhere else.

A written question and answer is the most precise thing you can give it. You write the exact question and the exact wording you want a customer to get, and that wording is what they get.

What you choose to include

A crawl finds pages. It does not put any of them into the index, and this is the part people expect to work the other way round.

Every page the crawl found arrives switched off, and you tick the ones you want. That is on purpose. A crawl of your own site will turn up your careers page and a launch announcement from two years ago, and you do not want either of those answering a customer.

Ticking a page does not go and fetch it again. The text is already held, so including one you missed, or taking one back out, costs nothing.

A crawl with nothing ticked reads Not indexed. Pages you have ticked are tagged New, and they read Trained once the retrain has run. A crawl that could not finish is tagged Failed with the reason attached, rather than quietly producing nothing.

What a retrain actually does

A retrain never goes back out to your website. Fetching is its own step, and you ask for it when you want it. So pressing the button is cheap and predictable, and it cannot quietly cost you a crawl of a thousand pages because you wanted to add one more file.

What it does is take everything you have included and not yet trained, cut it up, and learn it. When the last piece lands the tags flip to Trained and the widget is answering from it. There is no separate deploy step.

How a long document becomes an answer

A forty-page guide cannot be handed to a model every time somebody asks a question, so every document is cut into passages of a few hundred words, split along its own headings where it has them. Each passage is meant to answer a question on its own.

The trouble is that a passage on its own can be meaningless. “Drag the orange arrow to rotate” tells you nothing about which product or which screen. So before it is stored, each passage gets a short sentence in front of it saying where it came from and what it is about. Without it, that passage can come back for a question about a completely different screen.

Then each passage is turned into 1,536 numbers. Those numbers are a position on a map of meanings, where passages that mean similar things sit near each other whatever words they use. “How do I get my money back?” and “Refunds are issued within fourteen days” end up close together despite sharing almost no vocabulary.

Why an exact error code still finds the right page

A map of meanings has one blind spot, and it is exact strings. Somebody typing “error TS-999” does not want approximately similar passages. They want the one with TS-999 in it.

So alongside the map there is a keyword index over the same passages. A question searches both, and the best few results from each are merged. That is what gets an error code or a product name to the passage that carries it.

What a visitor gets

The passages that came back, and the conversation so far, go to a model with a narrow brief. The four rules in that brief, and why a bot without them invents things, are in why support bots make things up.

When two passages disagree, the answer you wrote wins, because you wrote it to replace an older page.

If the winning passage came from a page on your site, the answer carries a link to it. A passage that came from a file, pasted text or an answer you wrote has no address, so there is nothing to link to and no link is shown. So add your help pages as a website source, not only as files, and your customers get something they can go and read for themselves.

When nothing covers the question, Deacon says so in the language the visitor wrote in, and asks for an email address if it does not already have one. The question and the transcript land in your dashboard.

What none of this can fix

No tool in this category checks your content against reality. A page that is out of date produces a confident answer that is out of date, with a link to the page it came from.

If your documentation is thin you will get a lot of “I don’t know” in the first week. That is the correct answer to give a customer. Every question Deacon could not answer is waiting in your dashboard with a box to write the answer once.

A web page that is mostly a diagram with no text around it comes back thinner than it looks to you. Put the same thing in a PDF and it survives, because a PDF gets read by a model that can see it.

What to check before you trust it

Read what it fetched, not just the page count. Every tool shows you a number. Fewer show you the text they actually pulled out of each page, and that is where you find the one that came back as a cookie banner.

Then ask it a question your help pages do not cover, and ask it for a price you have never written down. If it answers either of them, read why support bots make things up before you put it on your site.

The install guide has the dashboard side of all of this, in order.