What goes into a chatbot knowledge base before launch

What does a support chatbot need to know before it goes live? The exact rules your shop applies to each common request, written in full sentences, plus a clear list of what the bot must not answer. If a rule lives only in your head, the bot will fill the gap with a guess.

That is the whole job. A chatbot built on a language model is good at wording an answer and bad at knowing your policy. The knowledge base is where the policy comes from. If you want to see what this site is about first, start with the about page.

Why not just point the bot at the website?

You can, and many people start there. The trouble is that a shop site is written for browsing, not for answering. The returns page says "within 30 days", while the product page says "final sale", and a customer asks about the final-sale item. A person knows which line wins. A bot sees two sentences and picks one.

The usual build has three steps: prepare the help content, connect it to a language model, then test and tune the tone. Most of the effort sits in step one, and that step is yours, not the software's.

What goes in, by type of request

The examples below are illustrations, not real customers.

Refunds and returns. The time window and where it starts counting (order date or delivery date). Who pays return shipping. Items that cannot be returned. What "refund" means: original payment method, store credit, or both. And the one the bot must not guess: whether an exception can be made.

Order status. Where the tracking number comes from, how long a carrier scan usually lags, and what to say when the tracking page shows nothing. The bot should also know what it cannot see. If it has no live order data, it must say so instead of inventing "your parcel is on its way".

Plan or subscription changes. How to upgrade, downgrade or cancel, when the change takes effect, and whether the current period is refunded. Write the billing date logic out in plain words, with one worked example.

Delivery and address changes. Until what point an address can still be edited, and what happens after the order is packed.

Product questions. Sizes, materials, compatibility. Only facts you can stand behind. If a spec is missing, the right answer is "I don't have that detail", not a likely-sounding one.

How should each answer be written?

As a short, complete statement with its conditions attached. Compare two entries.

Weak: "Returns accepted within 30 days."

Better: "Unused items can be returned within 30 days of delivery. Return shipping is paid by the customer unless the item arrived damaged. Sale items marked final sale cannot be returned."

The second one answers the follow-up questions before they are asked. Put the date or version of the policy at the top of the document, so you know when it is stale.

When is it better to bring in a human?

Anything about money outside the written rules: a refund after the window, a chargeback threat, a damaged item with a dispute about who is at fault. Also anything the knowledge base does not cover. Write an explicit line for these cases, something like "If the customer asks for an exception, offer to pass the chat to a person and do not promise an outcome."

Three things to check on your own shop

1. Pick your five most frequent request types and confirm each has a written rule with its conditions, not just a headline.
2. Find two places where your site contradicts itself (returns versus final sale is a common one) and settle which rule wins.
3. Write a "never answer, pass to a person" list before launch, and ask the bot those questions yourself to see what it says.

If the bot gets the third check wrong, fix the knowledge base before you fix the wording. Tone is the easy part. Missing rules are what customers remember.