What an AI chatbot needs to know before it goes live

You train a chatbot on your own business by writing down what it is allowed to say, where each answer came from, and what it must refuse — then keeping that written record current. The model is the easy part and it is largely interchangeable. What decides whether the bot is useful or embarrassing is the material you hand it, and almost nobody budgets for that.

We build these. The knowledge base takes longer than everything else combined, every time.

What goes into a chatbot's knowledge base

Not your website. That is the first assumption worth removing.

A website is written to persuade someone who is already reading it in order. A knowledge base is read one fragment at a time, out of order, by a machine that cannot tell which fragment is current. Those are different jobs and they need different writing.

What actually belongs in it:

• The answers to the questions you are already asked. Pull them from your inbox and your phone log, not from your marketing. The gap between the two is usually large and always instructive.
• Prices, terms and availability — or an explicit instruction not to discuss them. One or the other. Silence on this is what produces invented numbers.
• The boundaries of what you do. Which services, which locations, which sizes of job. A bot with no edges will cheerfully take on work you cannot deliver.
• Where each fact came from. Not for the reader — for you, six months later, when something is wrong and you need to know which document to fix.
• Who to hand off to, and when. The most valuable sentence most bots can say is "let me put you through to someone."

Why a chatbot repeats your worst page

A chatbot has no way of knowing which of your pages is out of date.

Everything you give it carries the same authority. The service page you rewrote last month and the one nobody has touched in two years look identical to the model, and if the old one is more detailed it will often win, because more detail looks more like an answer. The bot does not become wrong on its own. It faithfully repeats something you already had, to a customer, in a conversation, one sentence at a time — which is a far more convincing delivery than the buried page it came from.

This is the honest reason knowledge-base work is slow. Building the bot surfaces every inconsistency in your own material at once, and the only way through it is to decide what is true. Most of that work would have been worth doing anyway. It is just that nothing else ever forced it.

If you are choosing between building and buying, this is also the part that no platform does for you: build or buy an AI chatbot, and who ends up owning it.

What the bot must be told to refuse

A useful chatbot is defined as much by its refusals as its answers, and refusals have to be written down explicitly. A model will not infer them.

At minimum, decide in advance what happens when someone asks for:

• A price you do not publish. Either it quotes the published range, or it says it cannot and offers a human. Never "roughly."
• Advice in a regulated area — legal, medical, tax, financial, immigration. If your business touches one of these, the refusal language should be written by whoever is accountable for it, not by the person configuring the bot.
• A commitment. Availability, delivery dates, approval, outcomes. A bot that says "we can definitely do that by Friday" has made a promise on your behalf.
• Something outside your scope. The graceful version is a handoff, not an apology.
• Personal information about someone else. Decide this before launch, not after the first request.

Write the refusal as the sentence you want it to say. A rule phrased as a prohibition tends to produce an awkward non-answer; a rule phrased as the actual sentence produces the actual sentence.

Who keeps it current after launch

This is the question that gets skipped, and it is the one that determines whether the thing is still useful in a year.

Name a person. Not a team — a person. Give them a standing slot to review what the bot was asked and what it answered, and the authority to change the source material rather than patch the bot. If the fix always happens in the bot's configuration, the underlying document stays wrong and the same error comes back through a different question.

Tie it to something that already happens. Whatever your weekly or monthly review is, the chatbot log belongs in it — the questions it could not answer are the most honest customer research you have, and they cost nothing to collect. If you do not have that review yet, we wrote about building one.

Start narrower than you think

The most common failure we see is scope, not technology. A bot asked to answer everything answers nothing well, and every additional topic multiplies the material someone has to keep true.

Pick the five questions you answer most often. Do those completely, including the refusals and the handoff. Ship it. Then widen it based on what people actually asked, which will not be what you predicted.

That is the same principle we apply to automation generally — the highest-leverage thing first, not the most impressive thing first: what to automate first. And it is worth saying plainly that a chatbot is often not the right first project. If the underlying process is unclear, a bot will make the confusion faster rather than smaller. Sometimes the useful answer is that something needs fixing, not automating.

The model, meanwhile, matters far less than any of this: the model matters less than the workflow.

Where we sit in this

SB Intelligence builds and delivers these, including our own — Mango, the assistant we are building for our own site, which is where most of what is written above came from the hard way.

We do not sell a platform subscription, and we are not the right people to tell you what your regulatory obligations are in a regulated field — that belongs with whoever is accountable for compliance in your business. What we do is scope the thing honestly, build the knowledge base with you, and say so when a chatbot is not the project you need.

The AI and automation page covers how that engagement works.

Do this before anyone builds you anything

Write down the ten questions you are asked most. Not the ones you wish people asked — the actual ten, from your inbox and your phone. Then check whether your own site answers them. Most of the value people expect from an assistant turns out to be content that was never written, and finding that out costs you an hour rather than a project.

What needs someone who has shipped one: the guardrails and the test set — deciding what it must never say, and then proving it does not say it. That is the part that is invisible until it fails in front of a customer.

And the question only you can answer: is there a real person available when it hands over? An assistant that promises a human nobody staffs is worse than no assistant at all.