How to make a chatbot answer with your business data

To make a chatbot answer with your business data instead of making it up, you have to give it your real documents —prices, terms, frequently asked questions— and force it to answer only from them. You do it in three pieces: gather and update your texts, index them so the chatbot searches for the piece that answers each question, and set the rule that if something isn't in your documents, it says it doesn't know and hands off to a person. This is called RAG: search your data before answering.

It isn't training an artificial intelligence from scratch, which is expensive and almost never necessary. It's taking a model that already exists and giving it a source: your documents. Like handing someone very well-read your prices folder and telling them "you only answer with what's in here; if it's not, say so".

Why doesn't a "normal" chatbot know your business?

Because it learned from general internet text, not from your prices or your returns policy. It can talk about almost anything on the surface, but about your specifics it knows nothing. And here's the problem: when you ask it something it doesn't know, many models don't say "I don't know", they fill the gap with something that sounds right. It's what's called hallucinating: making up an answer with total confidence.

A chatbot that invents the delivery time or pulls a price out of thin air isn't a helper; it's a problem with good writing. That's why the job isn't just "put in a chatbot", it's tying it to your data and taking away its permission to improvise.

What is "giving it your data" (RAG in plain terms)?

It's putting a search step before the answer. Instead of the chatbot answering from memory, it first searches your documents for the piece related to the question, and only then writes the answer using that piece. The acronym is RAG (retrieval-augmented generation), but the idea is simple: search before you speak.

The advantage is twofold. It answers with your own, up-to-date information, with no need to retrain anything when you change a price: you change the document and that's it. And you can ask it to say where it got the answer, so you or the customer can check it. A chatbot that cites its source is a chatbot you can audit.

How do you do it, step by step?

Six steps, and the first three are tidying your house, not technology:

1. Gather your real texts. Prices, terms, shipping and returns, FAQs, hours. Everything a customer asks and someone answers.
2. Clean them and bring them up to date. Remove what's expired, unify what contradicts itself. The chatbot repeats what you give it: old prices in, old prices out.
3. Chunk and index them. Split the documents into short pieces and store them so the chatbot can search for the piece that answers each question.
4. Connect it with the cite-or-stay-quiet rule. Answer only from your documents and, if it can't find it, say it doesn't know and hand off to a human.
5. Test with real and trick questions. What your customers ask, plus some that aren't in the documents, to check it says "I don't know" instead of making up the answer.
6. Keep it up to date. Every time a price or a term changes, update the documents. It's only as good as how recent what you gave it is.

The step that decides whether this goes well is the second. Half the value of a chatbot with your data is in having your data tidy, which it almost never is. Tidying your answers folder helps you even if you never build the chatbot in the end.

How is it different from a generic chatbot?

In where it gets what it says, and in what it does when it doesn't know:

Look at the last row: the worst case of a well-tied chatbot is that it stays quiet when it should answer, and that's fixed by adding the missing document. The worst case of the generic one is that it lies, and you don't see that until a customer gets angry.

How do I stop it making things up?

With the cite-or-stay-quiet rule, and by checking it on purpose. The configuration tells it to answer only from your documents and, if the answer isn't there, to admit it doesn't have it and hand off to a person. It sounds obvious, but it's exactly what a badly built chatbot doesn't do: it prefers looking good to staying quiet.

And then you test with bad intent: you slip in questions whose answer isn't in your texts and check it says "I don't know this" instead of improvising. That trick-question test is what separates a chatbot you can trust from one that one day blurts out an invented delivery time in front of a customer.

How much does it cost and how long does it take?

Less than people think, because nothing is trained. With the documents already tidy, building a chatbot that searches them and answers with the cite-or-stay-quiet rule is a matter of days, not months. The bulk of the work —and the time— is gathering and cleaning your texts, which is precisely the part that doesn't depend on technology.

The running cost is the model's per-query cost (cents per conversation) plus the maintenance of keeping the documents current. What it saves is the time of answering the same questions for the umpteenth time and being available at eleven at night without anyone having to be.

When is it NOT worth it?

• When you get four questions a month. Answering them by hand works out better than building and maintaining anything.
• When your data changes by the hour and no one will maintain it. A chatbot with expired information gives worse answers than having none: it looks official and gets it wrong.
• When what's needed is to decide, not to inform. If most queries call for negotiating, weighing up a case or giving judgement, that's a person's job. The chatbot handles the repetitive, not the delicate.

What mistakes do people usually make?

Almost all come from skipping the boring part and trusting the magic one.

• Giving it the documents dirty. If your texts contradict each other or have old prices, the chatbot will repeat the contradiction with total confidence.
• Not setting the stay-quiet rule. Without it, the chatbot fills gaps. It's the mistake that ends in a made-up answer in front of a customer.
• Not testing with trick questions. If you only test what you know is there, you never see what it does when it doesn't know, which is what really matters.
• Building it and forgetting it. Prices change, terms change, and the chatbot keeps saying what it said six months ago because no one touched the documents.

Frequently asked questions

Do I need to train my own AI for this?

No. Training a model from scratch is expensive, slow and almost never necessary. What you do is take an existing model and give it your documents as a source, so it searches them and answers from those texts. It's like handing someone very well-read your prices folder and telling them to answer only with what's in there.

How do I stop the chatbot making up answers?

With two things. First, that it answers only from your documents and not from its general knowledge. Second, the cite-or-stay-quiet rule: if the answer isn't in your texts, it has to say it doesn't know and hand off to a person, rather than filling the gap. Then you test on purpose with trick questions to confirm it stays quiet when it should.

Do my data stay in the model or leak to others?

It depends how it's built. If you use a serious service with a data agreement, your documents are used to answer your customers and not to train anyone's model. And if the matter is sensitive, it can be built so the data never leaves your control. It's a decision to make at the start, not after.

When is it NOT worth building a chatbot with my data?

When you get four questions a month: you answer them by hand and that's it. When your data changes by the hour and no one will keep it up to date, because a chatbot with expired information gives worse answers than none. And when what's needed is a person to negotiate or decide, not one to repeat information.