How to build a knowledge base your bot can actually answer from

The knowledge base is the part of Replai that decides whether it is useful. The bot answers from it and from nothing else: not from the internet, not from what a language model assumes about bakeries or clinics. If a fact is not in there, the bot says it will check with the team.

That behaviour is the product working. It is also why an empty knowledge base produces a bot that is worse than no bot.

Start with the questions, not the documents

Before opening the page, write down the questions you actually answer. Not the ones you wish customers asked. The real ones, in the words they use.

For most businesses the list is short and boring:

• How much is it
• Are you open now
• Do you deliver to me, and what does that cost
• Is it in stock
• Where are you
• Can I return it

Six answers covers a startling share of message volume. That list is the specification. Everything below is just getting it into the system.

The three ways in

Text is the one to start with. Give it a title you will recognise later and paste the content. Plain text is fine; it does not need formatting. A price list pasted straight out of a spreadsheet works.

URL points at a page you already maintain. This is the fastest start if you have a website, and the best choice for anything that changes on the site anyway, like an opening-hours page.

File takes a PDF, DOCX or TXT. Use it for things that only exist as documents: a rate card, a menu, a policy.

What goes in, and what does not

This is the distinction that causes the most trouble, so it is worth being blunt about it.

Facts about your business go in the knowledge base. Prices, hours, delivery areas, policies, stock, addresses, product details.

Rules about how the bot behaves go in the system prompt. Tone, length, when to hand over to a person, what it must never guess at.

Mixing them breaks both. A knowledge base full of instructions means the bot sometimes quotes its own rules to a customer. A system prompt full of prices means changing a price is an edit to the bot's personality, and prices change far more often than personality does.

The test is simple: if it would still be true if a different company used your bot, it is an instruction. If it is specific to you, it is a fact.

Build from your past chats

If the number has history, there is a faster route than typing.

This reads the replies you and your team have written to customers and proposes the answers behind them. Two details make it trustworthy: it ignores the bot's own replies, so it cannot learn from its own mistakes, and nothing is saved until you confirm it.

It is most useful for the answers you have never written down anywhere, which tend to be exactly the ones customers ask most.

Check what is actually ready

The summary counts sources, ready and failed separately, and the difference matters. A file can upload perfectly and still fail to process, most often because it is a scan with no extractable text. A source that is not ready is not being used, and nothing in the chat will tell you that.

Test it before you trust it

Send the bot the question your customers ask most, from a different phone, and compare the answer with what you would have said.

Three things to look for:

Is it right? Not plausible. Right. A wrong price sent confidently is worse than no answer.

Is it complete? "We deliver" is not the answer to "do you deliver to Eastfield". If the answer is missing the part the customer actually needed, the source is missing a detail.

Does it refuse well? Ask something deliberately not in the knowledge base. The bot should say it will check with the team. If it invents an answer instead, the system prompt is not telling it to stay inside its sources, which is the next guide.

What to do next

With the facts in place, the remaining question is how the bot uses them: how it speaks, how long its replies are and when it should stop and fetch a human. That is the system prompt.