A chatbot that says "I'm not sure, let me connect you with someone" is more useful than one that confidently invents a return policy you don't have. In our experience, most businesses launch a chatbot with almost nothing behind it: maybe a homepage and an FAQ page, then wonder why it makes things up or gives vague non-answers. The fix isn't a smarter bot. It's better source material.
Why Chatbots Guess in the First Place
Most AI chatbots, whether built on ChatGPT, Claude, or a customer-service platform like Intercom or Zendesk, don't know anything about your business by default. They generate answers by pattern-matching against whatever text you give them (your "knowledge base") plus general internet knowledge. If your knowledge base is thin, outdated, or contradictory, the bot fills the gaps with guesses that sound confident but are wrong.
This is often called a hallucination, but it's really a documentation problem. The bot isn't broken. It's working with bad or missing inputs.
Step 1: Audit What You Already Have
Before writing anything new, collect every piece of content that already describes your product or business. This typically includes:
- Product pages and spec sheets
- Pricing pages
- FAQ pages
- Return, shipping, and warranty policies
- Past support tickets or email threads with common questions
- Sales scripts or onboarding decks
- Internal wikis or Slack pinned messages
Put all of it in one folder or document. You'll likely find three problems right away: information that's outdated, information that contradicts itself across pages, and big gaps where nothing exists at all. Fix the contradictions first. If your website says returns are accepted within 30 days but your support team tells customers 14 days, the chatbot will pick one at random, and it might be the wrong one.
Step 2: Write Down What's Only in People's Heads
The biggest gap is usually the knowledge that never got written down because your team just knows it. Things like:
- Why a feature works one way and not another
- What to tell a customer whose order is delayed past the promised date
- Which product tier is actually recommended for which use case
- Edge cases: international shipping rules, discontinued products, known bugs
A simple way to surface this: ask your support or sales team to list the ten questions they answer most often that aren't covered on your website. Write those answers as short, plain documents. This single exercise usually closes more gaps than anything else you'll do.
Step 3: Format Content So the Bot Can Actually Use It
A chatbot doesn't read a 12-page PDF the way a person does. It works better with content broken into small, self-contained chunks, each one answering a single question clearly. Long, meandering pages with the answer buried in paragraph four tend to confuse retrieval, especially in simpler chatbot tools.
A useful format is a straightforward Q&A pair:
Question: What is your return policy for opened electronics? Answer: Opened electronics can be returned within 30 days of delivery if all original packaging and accessories are included. A 15% restocking fee applies. Items marked "final sale" cannot be returned.
This structure does two things. It gives the bot a clean, complete answer to retrieve, and it forces you to notice when your own policy is actually ambiguous, because you have to write the exact rule instead of gesturing at it.
If you have dozens of products, consider a standard template for each one:
- What it is (one sentence)
- Who it's for
- Key specs or features
- Common questions and answers
- What it is NOT (common confusion with a similar product)
That last point matters more than it seems. Telling the bot what a product isn't prevents it from blending two similar SKUs into one wrong answer.
Step 4: Feed the Content Into Your Chatbot Tool
How you do this depends on your platform, but the general options are:
- Direct upload: Many tools (custom GPTs, Claude Projects, most helpdesk bots) let you upload documents directly as a knowledge base.
- Connected knowledge base: Tools like Intercom or Zendesk can pull from your existing help center articles automatically, which is why cleaning those articles first (Step 1) matters so much.
- Retrieval setup (RAG): For custom builds, a developer sets up a system that searches your documents and feeds the relevant chunk to the AI model before it answers. This is more technical but gives the most control over accuracy.
Whichever method you use, smaller and more current beats large and stale. A tight set of 50 accurate documents will typically outperform 500 documents where half are outdated.
Step 5: Test With the Questions Customers Actually Ask
Once the bot is loaded, don't just ask it easy questions to confirm it works. Test it the way a skeptical customer would:
- Ask the same question three different ways and see if the answers match.
- Ask about a product you don't sell and confirm it says so instead of inventing one.
- Ask an edge-case question ("Can I return a gift without a receipt?") that isn't explicitly documented, and see what it does with the gap.
- Ask something outside its scope, like a general how-to question, and check it doesn't pretend to be an expert on things it wasn't trained on.
Write down every wrong or shaky answer. Each one usually points to a missing or unclear document. Go fix that specific document rather than trying to patch the bot's behavior with a vague instruction like "always be accurate."
Step 6: Give It Permission to Say "I Don't Know"
This is the step most businesses skip, and it's the one that prevents the most damage. In your chatbot's instructions or system prompt, explicitly tell it what to do when it doesn't have an answer. For example:
"If the answer isn't in the provided documents, say you're not certain and offer to connect the customer with a team member. Do not guess or make up policy details."
A bot that admits uncertainty protects your business. A bot that confidently states a wrong shipping timeline or a made-up discount code creates a real problem you'll have to clean up later, sometimes with an unhappy customer attached.
Step 7: Treat the Knowledge Base as a Living Document
Product details change: prices update, policies shift, new items launch, old ones get discontinued. A chatbot trained once and never touched again will slowly drift out of date. Set a recurring reminder, monthly for fast-moving businesses, quarterly for stable ones, to review and update the source documents. Whenever your team changes a policy or launches a product, add it to the checklist of things to update in the chatbot's knowledge base at the same time you update the website.
Common Mistakes to Avoid
- Uploading your entire website as one giant file. This buries key answers and makes retrieval unreliable. Break content into focused chunks instead.
- Leaving contradictions across pages. If two documents disagree, the bot will pick one unpredictably.
- Assuming the bot understands context it hasn't seen. If your support team knows "Model X" replaced "Model Y" last year but no document says so, the bot won't know either.
- Never testing with real edge cases. Easy test questions hide the actual gaps.
- Forgetting to set an "I don't know" fallback. This is the cheapest fix with the biggest downside risk if skipped.
Quick Action Summary
- Collect every existing piece of product content in one place and resolve contradictions first.
- Interview your support or sales team for the unwritten answers they give customers daily.
- Rewrite content as short Q&A pairs, one clear answer per chunk.
- Load the content into your chatbot tool, favoring accuracy over volume.
- Test with real, tricky, and out-of-scope questions before launch.
- Instruct the bot to say "I don't know" instead of guessing.
- Review and update the knowledge base every time your product or policies change.