How to prepare a chatbot knowledge base that stays on topic

A chatbot knowledge base needs answers a person could also follow without inventing missing conditions. Collecting company pages is only the starting point: separate topics, resolve conflicting rules and explain exceptions. This guide focuses on editing source answers so an assistant has dependable material for a relevant response.

What makes a source answer usable for AI?

A source answer is a self-contained explanation of one rule: who it applies to, what is possible and what happens next. “You can change your appointment” is incomplete. Add the deadline, the channel and the route after the deadline; keep those conditions alongside the main rule rather than on a distant page.

Begin by finding sentences that depend on nearby text: “this plan”, “the option above” or “we will do it later”. Replace them with a plan name, action or stage. A knowledge fragment may be used without the preceding paragraph, so it needs to remain meaningful on its own. Do not copy the whole policy into every card; add only the conditions required to settle that card’s question. Self-contained fragments matter because the chatbot retrieves individual passages for each question instead of learning whole documents; the comparison of RAG vs fine-tuning explains the difference.

The role of knowledge is covered in AI in customer support; this guide focuses on what the assistant should actually say.

What to prepare before making a change

Collect real question variants, an answer approved by the process owner and the words customers use. Include synonyms naturally. Avoid five copies under different headings: those duplicates tend to drift apart when a deadline or eligibility condition changes.

• Each answer has one intent and names the relevant service.
• The condition, exception and next step sit beside the main rule.
• The process owner resolves conflicting versions before testing begins.
• Internal abbreviations are explained and pronouns have an obvious reference.

Prepare a discrepancy table with the customer question, the agent’s current answer, the website answer and the owner’s decision. “Days” and “business days” are a factual difference, not a style preference. Keep an unresolved entry out of published knowledge. This table is easier to approve than a polished document in which contradictory passages still describe incompatible rules.

A procedure your team can use

Edit the process people ask about most often before tackling the longest document. Work with a small set of answer cards your team can review together. Keep a separate list of unresolved business questions: an undecided policy is not a problem the model should solve.

1. Name the need.Write the customer question and remove side issues. Two independent decisions need two cards.
2. Agree on one version.Compare the agent instruction with the public offer and name who approves any discrepancy.
3. Add boundaries.State eligibility and the exception route instead of an unexplained instruction to contact support.
4. Check practical use.Ask someone else to answer a rephrased question using only the card, without additional context.

After editing, test a card with a question that contains less information than the original FAQ. Instead of asking whether cancellation is possible through a link before a stated deadline, try “I cannot attend; what should I do?”.

A good answer does not invent a date the customer never supplied and explains how to check the condition. Test a question about two services separately to detect rules being transferred between offers.

The distinction between a short FAQ and a complete instruction in building a knowledge base and FAQ helps you decide where each card ends.

A worked example and decision record

An example consultation card reads: “Cancel through the link in your confirmation until the deadline shown in the offer. After that deadline, message the team; the request needs an individual review.” This is an editing example, not a universal cancellation policy.

Remove “we will always move your appointment” if your team cannot guarantee it. Put finding a new slot in a separate card so an answer about cancellation does not pretend to create a booking.

↔ Scroll the table sideways to see all columns.

Use the same service name in the question, answer and condition. If customers use an informal name, include it as a synonym rather than creating a separate policy. For an introductory consultation, state the meeting’s outcome and the work it excludes.

This prevents an accurate cancellation instruction from being paired with a mistaken idea of what was purchased. Read the card without its heading as well: if the relevant offer remains clear, the fragment is suitable for independent use.

Include an incorrect answer in your example record too. “Your appointment has been cancelled” is wrong when the assistant only explains a policy and has not performed the action. “You can cancel through the link” describes permission and the next step. Comparing this pair helps editors and reviewers distinguish information from execution even when both sentences sound friendly and confident.

Exceptions you need to handle

The most troublesome duplicates look consistent at first: an FAQ gives one rule while the service page gives another. Do not polish a sentence with no accountable owner. Agree on the policy first, then simplify the wording.

Avoid “usually” in exception descriptions if nobody knows who can approve a different outcome. Rather than “we usually accept late cancellations”, explain that the team reviews the request and give the contact route. Keep the internal approval process out of the public answer. Customers need an actionable route; staff need a separate instruction describing the permissions required to make a decision.

NIST addresses trustworthiness in generative systems. The answer-card editing procedure is our proposed team workflow. NIST: generative AI risk profile.

If readable sources still produce invented facts, investigate seven causes of chatbot hallucinations.

Put the prepared process into practice

Once the cards are organised, use them as knowledge sources in Meet AI. The app requires an active installation and an eligible plan; publish the knowledge and inspect private test answers with their source citations. Source refresh is manual, so editing a website does not by itself make the revised answer active. Before adding a website or sitemap as a source, decide which pages to exclude from the website import so the cart, tags and expired promotions stay out of the knowledge base.

For the first review of active knowledge, choose questions about deadlines, service scope and exceptions. Read the cited fragment for every answer and check whether it supports the whole claim rather than just the general topic. Record which card needs editing instead of “the AI is bad”. If the source lacks a rule, repair the card before publishing again, then repeat exactly the same test.

Before launch, compare the cards with chatbot testing questions to cover refusals and exceptions as well.

Practical questions and answers

These answers clarify how to introduce chatbot knowledge base and can help your team agree on the operating rules.

Must every answer be short? Make it as short as a complete rule allows. Do not remove a condition to fit two sentences. Split a longer procedure into distinct stages while preserving the information needed at each stage.

Do I need to rewrite all documentation? Begin with common questions and conflicting policies. Keep technical documentation where it belongs; bring the parts needed in customer conversations into the knowledge source.

Who approves an answer? The process owner approves facts and the editor checks clarity and completeness. One person may hold both roles, provided the responsibility for each decision is explicit.