Maintain customer-chatbot prices, products and policies

Questions and owners. Start with the questions the chat should answer. Opening hours, technical product information and return conditions need different subject owners. Personal order information belongs in an authorised system lookup, rather than a shared knowledge collection available to every website visitor.

Create a source register for the chatbot that records these fields:

• document
• owner
• audience
• market
• language
• validity

Separate public material from internal procedures. A public FAQ can explain how to submit a complaint without exposing an internal goodwill limit or an employee's case note.

Access and linked content. Microsoft's SharePoint knowledge integration documentation illustrates how authentication and source configuration affect access. Links inside registered documents do not mean every linked destination is automatically ingested. Source checked on 26 September 2026. Operationally, a stored link is not evidence that its target is available to the bot.

A useful entry answers a specific question together with its conditions. “Returns are free” is insufficient when that only applies to certain countries, product categories or reasons. Keep the relevant market, exception and next step together in the approved source.

The table is a proposed template for one knowledge entry: seven fields, each with an example editorial record.

This is a proposed editorial model, not the schema required by a particular product. A simple register can be sufficient initially. What matters is that changes, responsibility and validity remain discoverable.

Authoritative version. Compare the website, PDFs, help centre and internal templates for the same rule. If three sources give different deadlines, the bot should not decide company policy. The responsible person must establish the authoritative version and correct or withdraw the others.

Precedence rule. Define an understandable precedence rule, such as an explicitly approved current policy taking priority over an archived announcement. A recent file timestamp does not establish current business validity: an old PDF may have been uploaded again yesterday. Keep effective dates separate from technical ingestion dates.

Unresolved conflicts. An unresolved conflict should trigger a cautious response or clarification. It is an editorial defect that needs an owner, rather than a reason to instruct the bot to sound more confident. Record the conflict so the team can see that it remains unresolved.

Change. A fictional business shortens Saturday support from 18:00 to 14:00. Its website is updated, but an old PDF and a French translation still state 18:00. A maintenance process checking only successful ingestion could leave both statements available.

Workflow. The proposed workflow starts with a change notice from the service lead. The editor identifies all affected sources and language versions, updates them and marks superseded material. The retrieval index is then refreshed. The team tests “Are you available on Saturday at 16:00?”, a French equivalent and a question about the next available contact route.

Expected answer. The expected answer includes more than the number 14. It should explain the service route actually available outside staffed hours. The evidence record identifies the updated source and the bot version used during review. This makes the later result reproducible without pretending that a synthetic scenario is a customer deployment.

Language is not country. An English-language question does not establish the customer's country. In a fictional business, a UK installation team and an Austrian installation team may have different service hours, contact routes and available appointment types. Translating both pages into English must not merge those policies.

Entry fields. Each knowledge entry should identify its service or product, applicable market, language, effective period and owner. Ask for the service location when it materially changes the answer. Do not infer eligibility from spelling, IP address or the language of the conversation alone.

The table lists five proposed regression cases for market, language and effective date, each with the expected result.

Review record. Keep a dated review record with the source version and actual answers after a change. These are proposed tests, not a measured accuracy score. Apply the same checks after changing the model or retrieval settings, because an unchanged source collection can still produce different answers.

When an answer is wrong, first check whether the correct source was available. Then check:

• whether it was retrieved for that request
• whether the answer accurately represented it

These three failures need different corrections.

Corrections. If the source is missing, repair publication or permissions. If retrieval misses it, improve structure, titles and unambiguous terminology. If the correct passage is retrieved but misused, inspect response rules, conflicting passages and model limitations. Replacing every document would often be unnecessary and make the original fault harder to understand.

Source links. Source links help, but also need verification. A link to a lengthy policy is only partly useful when the asserted statement does not appear there. Samples should therefore compare the precise claim with the relevant source section, including any exception or qualification.

Three patterns come up again and again in practitioners' reports on chatbot rollouts. They are not results from a particular client project, but typical failure modes.

The whole website as a source. Importing the entire website often brings in the old newsletter archive or expired campaign pages. The bot then quotes terms from years ago, correctly taken from a real source but no longer valid. Exclude archives, press releases and expired pages explicitly, or mark them with an end date.

The support mailbox as a knowledge source. The mailbox seems to contain everything customers have ever asked. It also contains outdated answers and, above all, personal data collected to handle one request, not as a knowledge base for every visitor. The GDPR ties data to the purpose for which it was collected (Art. 5(1)(b)), and the senders were usually not informed about such further use (Art. 13 and 14). Use the mailbox at most as a source of questions, and rewrite the answers as approved knowledge entries.

The referral that leads nowhere. A bot that answers difficult questions with "Please contact customer service" but cannot say how to reach it is worse than no bot. The handover route, with phone number, form and opening hours, therefore belongs in the knowledge base as its own maintained entry. The article on chatbot handover to customer service describes how to design the handover to people.

Test what it must not do. Check not only that the bot gives correct answers, but also that it refrains from what it should not do: no information on internal goodwill limits, no legal or tax advice, no invented contact details. Define edge cases in which it gives no answer and refers to a person instead, and add those cases to the regression questions.

Regression questions. Maintain a stable set of important questions and add cases from real failed interactions, reviewed with appropriate data minimisation. Test new content against related topics too: changing delivery times should not accidentally change return deadlines.

Proportionate review. Critical changes may require a second subject reviewer. A spelling correction can justify a lighter check. Match review effort to the consequence of error instead of making every edit follow an unnecessarily elaborate process.

Previous version. Keep the previous approved version accessible to operators, with a clear way to withdraw a faulty update. Restoring an old version must not silently restore rules that have since become invalid; the service owner should decide which temporary response is appropriate.

Establish who reports new products, price changes, holiday hours and incidents. Periodic reviews supplement these events rather than replacing them. Outdated sources need an expiry rule or an explicit withdrawal process.

Operational handover should include the source register, unresolved conflicts, test cases and substitutes. Measure how quickly important changes reach the chat and how often missing knowledge causes escalation. The knowledge base then becomes a maintained service resource with known limits and checkable statements.

These pages cover the service overview and the related decisions for maintaining chatbot knowledge:

• AI chatbots for customer service
• Keep RAG knowledge current through updates and deletion
• Diagnose wrong RAG answers and useful abstention
• Launch and operate a chatbot with clear release criteria
• Measure resolved chatbot requests and remaining work

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.