Build a knowledge base your chatbot can trust
A practical framework for turning scattered product knowledge into answers that are accurate, maintainable, and useful to customers.
A chatbot is only as useful as the material it can retrieve. Most teams discover this after launch: the widget is fast, the model is capable, and the answers are still unreliable because the underlying knowledge base is a pile of stale pages, duplicated PDFs, and internal shorthand.
The fix is not simply “add more documents.” A useful knowledge base is an information product. It has an owner, a scope, a review rhythm, and a structure that makes the right answer easy to find.
Start with questions, not files
Before importing content, collect the questions customers already ask. Use support tickets, sales-call notes, search queries, and transcripts from your existing inbox. Group them by intent rather than by the department that owns the answer.
| Customer intent | Example question | Best source |
|---|---|---|
| Evaluate | “What does the Standard plan include?” | Current pricing page |
| Implement | “How do I add the widget to a Next.js site?” | Integration guide |
| Troubleshoot | “Why is my bot not appearing?” | Troubleshooting runbook |
| Compare | “Can I use this with multiple brands?” | Product limits and plan guide |
| Escalate | “Can someone review my account?” | Support and handoff policy |
This list becomes your coverage map. It also tells you what not to import. A ten-year-old sales deck may contain useful context, but it should not outrank the current pricing page when the two disagree.
Give every source an owner and a freshness rule
Every source should answer three operational questions:
- Who owns the truth? A named team or person, not “the company.”
- When should it be reviewed? Use a date or a trigger such as every pricing change.
- What should happen when it is wrong? Define the correction path before launch.
A lightweight source register works well:
Source: Pricing and plans
Owner: Revenue operations
Review trigger: Any packaging or price change
Canonical URL: https://example.com/pricing
Fallback: Ask the visitor to contact sales
The register can live in a spreadsheet or an internal document. Its purpose is not bureaucracy; it prevents a chatbot from quietly becoming the most visible copy of an outdated policy.
Write for retrieval, not just for humans
Human readers can infer missing context from a page. Retrieval systems work better when each section is explicit and self-contained. Prefer headings such as Who can use SSO? over vague headings such as More details. Put the product name, plan name, platform, and version in the text when they matter.
Weak:
It is available on higher plans and can be enabled from settings.
Stronger:
Single sign-on (SSO) is available on the Chatty Business plan. Workspace administrators can enable it from Settings → Security → SSO after adding the identity provider metadata.
The stronger version contains the subject, eligibility, location, and prerequisite in one retrievable unit.
Remove contradictions before indexing
Contradictions are more dangerous than missing information because they give the assistant two plausible answers. During cleanup, search for:
- Multiple prices for the same plan
- Old product names and renamed features
- Different limits in marketing and documentation
- Instructions that assume different dashboard versions
- “Coming soon” language for features already released
If two sources must coexist, label their scope. For example: “For workspaces created before January 2026…” is far safer than leaving the reader to guess why two workflows differ.
Make the first version narrow
Launch with the ten to twenty intents that matter most to customers. A focused knowledge base gives you a measurable baseline and makes errors diagnosable. Add content when you can answer one of these questions:
- Did customers ask for it?
- Does it reduce a support or sales bottleneck?
- Is the source authoritative and maintained?
If the answer is no to all three, keep it out for now. More context is not automatically better context.
A launch checklist
- Top customer intents are listed and prioritized
- Every source has an owner and review trigger
- Pricing, limits, and availability have one canonical source
- Headings and sections name their subject explicitly
- Old versions are removed or clearly scoped
- Unknown-answer and human-handoff paths are documented
- A small set of real questions is ready for evaluation
Chatty works best when it is given a curated body of truth rather than a raw export of everything the company has ever written. Treat the knowledge base as a maintained product, and the quality of the conversation improves with every content review—not just with every model upgrade.