A chatbot knowledge base needs maintenance whenever the business information behind it changes. Prices, opening hours, service areas and contact routes can become wrong while the assistant continues to sound perfectly natural.
The practical task is to connect a business change to a source update and an answer check. Someone needs to know which information is authoritative, who can approve it and how to confirm that the assistant is using the current version.
I would keep this process small enough to follow during an ordinary working week. A short source register and a repeatable question set are a useful start. Buying another tool will not decide who owns the delivery policy.
Decide which source wins
List the information customers regularly ask about and identify the source that should answer each question. Your website, an FAQ and a product document may all mention delivery, but they should not make different promises.
Choose one authoritative source for each rule. Other pages can explain the same information, but they need to stay aligned with it. Where a rule depends on a location, product or customer type, make that condition explicit.
This is particularly important for historical material. A dated campaign page can be useful as an archive while being unsuitable as a source for current availability. Decide what your assistant may use rather than assuming every publicly accessible page is current operating guidance.
Google's people-first content guidance concerns web content, not chatbot configuration. Its emphasis on trustworthy, useful information is still relevant to the source pages you publish. A chatbot cannot make an unclear service description more authoritative simply by repeating it conversationally.
Give every important topic an owner
The owner should be the person who can confirm the underlying business rule. Marketing may edit the website, but operations may need to approve a delivery promise. Support may identify a recurring question while the service lead decides the actual answer.
Keep the distinction visible. A technical administrator can confirm that an update ran; that does not mean they can approve new pricing or a refund exception. Assign a backup owner for information that must change when the usual person is unavailable.
A simple register can look like this. The entries below describe an example process, not a claim about how any particular xbot account is configured.
| Topic | Authoritative source | Business owner | Check after a change |
|---|---|---|---|
| Opening hours | Current location page | Location manager | Ask about a normal day and an exception |
| Service scope | Approved service description | Service lead | Ask what is included and excluded |
| Delivery information | Current delivery policy | Operations | Ask about different destinations |
| Contact and escalation | Current support page | Support lead | Follow the link or send an agreed test |
| Pricing | Approved price page or quotation route | Commercial owner | Check conditions and avoid unsupported estimates |
Tie updates to the business event
Do not rely only on a calendar reminder. Add a source check to the task that changes the business rule. When a location changes its hours, the task is unfinished until the public page and the assistant's relevant answer have been checked.
Write down what changed, which sources were updated and when the change takes effect. A future price increase is different from a correction that applies immediately. If old and new information must coexist briefly, make the effective dates clear.
Check your actual setup's update behaviour. Does it read the source on demand, refresh on a schedule or require an explicit update? These are configuration questions to verify, not features to assume. A page edit and a completed knowledge update may be separate events.
After updating, ask the assistant the affected question in a new conversation. Then ask a related follow-up. A correct first answer is useful evidence, but the follow-up may reveal an old condition or a conflicting page.
Remove contradictions before polishing prompts
Suppose one page offers collection from a location and another says all orders are delivered. The assistant may select either source or combine them incorrectly. Making the instruction more emphatic does not resolve the business contradiction.
First establish the real rule with its owner. Update the authoritative page and then review duplicates, menus, campaign content and downloadable files that repeat the old version. Where content should remain historical, label or exclude it appropriately for your setup.
Use the same care for missing information. If the business has not approved a standard delivery estimate, the assistant should not turn an old example into a promise. The appropriate response may be to ask for more detail or direct the customer to a person.
Check both languages after a policy change
For a Finnish and English site, maintain meaning across languages. The task is not complete when one page has been translated if the other version still describes a different service.
Keep a small set of paired questions about the important rule. Ask naturally in each language and compare the answer's meaning. Watch for differences in eligibility, exclusions, timing and the contact route.
You can also ask a question that uses a Finnish sentence and an English product name. That reflects a normal customer conversation. The assistant should not lose the policy condition because the wording differs from a heading on the source page.
Record a confirmed language difference as a source or answer defect. Avoid fixing it by quietly giving one audience a different business promise.
Keep a useful failure log
When a customer exposes a gap, record only what is needed to reproduce the issue. Remove personal information and private account details. A synthetic version of the question is often enough for the maintenance test.
Separate the observed problem from your explanation of its cause. The assistant gave the old closing time is an observation. The source refresh failed is a hypothesis until someone checks the refresh and the sources used.
NIST's AI Risk Management Framework treats AI risk management as an ongoing activity. For this maintenance process, the practical lesson is to keep measuring behaviour as conditions change. A successful launch test is not evidence that every later source update has worked.
Give each issue a specific next action: correct a source page, remove an obsolete document, verify an update or improve the fallback route. Rerun the original question after the change and retain the result with the issue.
Choose a review rhythm you can sustain
Use event-driven checks for business changes and a recurring review for things that might otherwise be missed. Review frequency should reflect how quickly information changes and what a wrong answer could cause.
A seasonal service needs a check before the new season begins. A stable company description may need less frequent attention. Neither deserves an invented guarantee that a particular schedule eliminates all errors.
Start with the topics that cause the most confusion or carry the greatest consequences. Confirm that their owners, sources and contact paths are current. Then expand the register when a real need appears.
If you want help defining the first chatbot knowledge base for your business, talk to xbot about the questions you answer repeatedly and who owns those answers. Those two inputs make the ongoing maintenance much easier to organise.