Keeping Your Knowledge Base Current: Who Updates What?

An assistant that still quotes July's delivery time in September creates exactly the follow-up question it was meant to remove. The model answers cleanly - it simply answers from a state that no department in the business stands behind any more. This article covers the part that begins after go-live: which content type is reviewed on which cadence, who owns it, when an entry expires, and which source wins when two of them disagree.

Enlarge graphic

Labels in the illustration

• Content type
• Cadence
• Owner
• Expiry
• Last checked
• Status
• Prices, discounts
• on change
• Sales
• 90 days
• 02 Sep 2026
• current
• Opening hours
• monthly
• Reception
• 30 days
• 01 Sep 2026
• current
• Delivery times
• weekly
• Logistics
• 14 days
• 08 Sep 2026
• due
• Documents, terms
• quarterly
• Legal
• 180 days
• 12 Jun 2026
• due
• Forms, processes
• half-yearly
• Support
• 365 days
• 20 Feb 2025
• overdue
• current: checked within cadence
• due: cadence ending
• overdue: expiry date passed
• Precedence: database before website text before manual note
• Sourced answers name their source

Knowledge base maintenance plan

Why a knowledge base ages unnoticed

A knowledge base does not age evenly. The text about company history lasts years, the delivery time lasts weeks, the promotional price lasts days. Because all three sit in the same repository and cost the same effort to write, they look equally valuable in daily operations - and are touched equally rarely. The break also does not show up where it happens: whoever maintains the price in the shop sees the change on the product page immediately. That an assistant next to it is answering from last month's catalogue export stays invisible, because that export sits silently in the background.

The gap grows with success. 41 per cent (Bitkom) of companies with 20 or more employees now use AI, another 48 per cent (Bitkom) are planning or discussing it, and two thirds of those already using it want to expand further (66 per cent, Bitkom). Every additional use case hangs on content that somebody has to keep current. Across the EU, 19.95 per cent (Eurostat) of enterprises with ten or more employees used at least one AI technology in 2025, and 34.70 per cent (Eurostat) of those used it for marketing or sales - exactly where prices, promotions and deadlines change fastest. The second reason lies in the data itself: 61 per cent (Bitkom) of companies barely use the potential of their existing data, or do not use it at all. An assistant makes that gap visible, because it answers from holdings that were previously only filed away - the price list in the sales folder, the form on the intranet, the shipping table in the wiki. What sat unchanged there for two years was a dead folder. From go-live onwards it is an answer to customers, in the support assistant just as much as on the website.

Five content types, five half-lives

The maintenance plan does not start with a cadence, it starts with a sort. Every content type gets a row, and every row answers four questions: how often is it checked? Who checks it? After how many days does an entry count as expired? Where does the value come from in case of doubt? Only when those four answers stand per row is the plan an operating tool rather than a statement of intent. The split below has proven itself as a starting point; the numbers are starting values that you adjust to your actual change frequency after the first quarter. The same split applies to the website assistant as to the shop, only the weights shift.

Two rows deserve a reason. Prices sit on "on every change" rather than on a calendar cadence, because section 3 (1) of the German Price Indication Ordinance requires the total price to be stated, and a mismatch between the answer and the checkout is noticed immediately. Legal texts, by contrast, sit on quarterly with an expiry of 180 days: they change rarely, but a change shifts the entire answering situation - and an unchecked version typically stays undetected longer than a wrong price, which the first order exposes.

Who maintains what: ownership belongs to the content

Ownership that covers the whole knowledge base is not ownership. "Marketing looks after the assistant" typically ends with prices, legal texts and shipping rules sitting with people who are not allowed to decide them. Tie responsibility to the content type instead: whoever sets the price in daily business also owns the price row in the maintenance plan. That costs one more conversation during setup and saves every single "who is responsible for this?" in operations. How closely timeliness and intended use are connected is put in one sentence by the British data quality framework.

In other words: timeliness is not a property of the content but of the lag between change and availability - measured against the intended use. The framework lists timeliness as a quality dimension of its own alongside completeness, uniqueness, consistency, validity and accuracy; it takes these six dimensions from DAMA UK (Government Data Quality Framework). Timeliness is illustrated with an example in which an agreed limit of two days is exceeded by one day, which breaches the agreed rule. Every row of your maintenance plan needs exactly that calculation: agreed lag, actual lag, difference. Anyone who only agrees on "regularly" cannot form the difference.

• Subject-matter ownership: whoever decides the value in daily business also releases it for the knowledge base. Without that person a change gets entered, but nobody stands behind it.
• Editorial ownership: one role keeps wording, language and references consistent - particularly when the assistant answers in several languages.
• Technical ownership: one role looks after the connections that feed content in automatically and reports when a source goes quiet.
• Cover: every row needs a second person. Holidays and illness typically fall into the weeks with the most changes.
• Escalation: a row whose expiry date has been exceeded by more than 30 days goes to management - not as an accusation but as a capacity question.

These five roles are not an org chart, they are five names per row; in small businesses the same name appears several times. What matters is that the names are written down. The maintenance plan we hand over at go-live is therefore a table of people, not of departments.

Expiry date, cadence and the precedence rule

Cadence and expiry date are two different things, and confusing them is a common mistake in day-to-day maintenance. The cadence says when somebody looks. The expiry date says from when an entry counts as unconfirmed if the check did not happen. The cadence is the intention, the expiry date is the safety net underneath. Together they form four building blocks that every row of the plan carries.

Without a precedence rule, an assistant can answer the same question differently depending on which passage it hits, and the business then looks for the cause in the model rather than in the repository. With a precedence rule, the contradiction turns into a report: the assistant answers from the higher-ranking source and notes that a lower-ranking source deviates. That report is the real gain, because it shows the place where content is being maintained twice. How an answer is bound to its source in the first place is covered in detail in preventing hallucinations.

Pull automatically instead of typing it in

Every row in the maintenance plan that a person has to work through competes with daily business - and 66 per cent (Bitkom) of companies name a lack of time as an internal obstacle to digitalisation, well ahead of a lack of financial resources (48 per cent, Bitkom). An effective maintenance measure is therefore to delete the row altogether: whatever the assistant can pull from a live source itself needs no calendar slot.

Three routes are common. The first is recurring ingestion of website and shop content: the assistant re-reads pages and categories at a fixed interval, detects changes and replaces the old state. The second is a query at the moment of the question - stock, price or, with a connected inventory system, order status are not stored but fetched while answering; how that runs via tool control in the Custom package is described in the article on tool calls. The third is the return channel from conversations: what users asked and the assistant could not answer becomes a maintenance task with a frequency attached instead of a hunch. This sorting decides how much manual work is left.

• Pull automatically wherever a machine-readable source exists: prices, stock, delivery times and, through the connection to the inventory system, order status. This content does not belong in a hand-maintained text file.
• Re-read periodically wherever a page carries the truth but offers no interface: service pages, location pages, help articles, blog posts describing procedures.
• Maintain editorially wherever wording and judgement matter: legal texts, goodwill rules, escalation paths, statements about deadlines and commitments.
• Deliberately leave out whatever the assistant should not answer: individual conditions, internal margins, unfinished product plans. A deliberately empty area is better maintained than an outdated one.

The change log: what has been answered differently since when

A maintenance process without a log produces an awkward question the moment somebody complains about an answer: what exactly did the assistant say on 14 November? The change log answers it. Every change to the knowledge base gets an entry with four fields - what was changed, who changed it, when it took effect and which source the new value came from.

The log pays back twice. In the short term it makes errors findable: a wrong answer can be traced to an entry instead of to a feeling. In the long term it delivers the change frequency per content type, and with it the basis for turning the cadence from a starting value into a measured one. Anyone who sees after two quarters that the shipping table changed eleven times and the terms once corrects the plan with numbers rather than instinct. That movement is exactly what separates a maintenance process from a maintenance intention.

The maintenance plan belongs in the calendar, not in someone's head

A maintenance plan that exists as a document gets read; a maintenance plan that exists as a series of appointments gets worked through. Create a recurring task per row: with the owner as the responsible person, with a duration that matches the scope - fifteen minutes for opening hours, an hour for legal texts - and with a link to the source to be opened. An appointment without a source link gets postponed, because searching takes longer than checking.

Do not bundle the appointments. A shared "knowledge base day" once a quarter sounds efficient and typically fails in two places: it hits all owners at the same time, and it lengthens the lag between change and availability for exactly the content that needs the shortest lag. Weekly rows stay weekly, even when they only cost two minutes. The effort of a row is measured by the checking, not by the appointment.

Plan two additional special sessions per year. The first is in September and aligns the knowledge base with the season: order cut-offs, holiday opening hours, shipping deadlines, return periods, availability between the years. The second is in January and clears up: expired promotions, year numbers in texts, price dates, forms carrying a year. How to absorb the seasonal load on top of that is described in the article on peak season support spikes.

Changing tariffs, terms and deadlines is not a retail-only topic. In advisory sectors the entire information situation shifts at the turn of the year, and the assistant has to answer from the new state before the first question arrives; the article on the switching season for insurance brokers shows that case in detail. In such sectors the maintenance plan is not a by-product of the assistant but the basis on which it runs.

How you notice that maintenance is working

The success of a maintenance process shows not in the number of maintained entries but in three observations from conversations. First, the share of answers in which the assistant hands over to a person because it cannot support the statement goes down. Second, the number of repeat questions about the same matter within one conversation goes down. Third, the topics shift: instead of "is that price still correct?" you get questions that sit deeper. Five metrics make those observations checkable.

• Expiry rate: share of entries whose expiry date has passed. A value below 5 per cent is a realistic operating target, zero per cent is not.
• Check lag: median between a change in the source and its effect in the assistant, per content type. This number implements the timeliness dimension (Government Data Quality Framework).
• Zero-result rate: share of questions without a supportable answer. It shows gaps, not errors - how to evaluate them in the shop is covered in zero results in site search.
• Contradiction reports: number of cases in which two sources deviated on the same question. When it falls, duplicate maintenance has been reduced.
• Handover rate: share of conversations passed to a person. It should fall, but not towards zero - 62 per cent (Bitkom) of online shoppers would most prefer a quickly reachable human contact when they have a problem with their order.

These five numbers sit in conversation analytics and can be read monthly; their direction over three months matters more than their absolute value. They also put expectations of the assistant in perspective: customer service via chatbots currently convinces half of the users of such an offering (50 per cent, Bitkom), while human contact satisfies 86 per cent (Bitkom). That distance is not an argument against the assistant but a message about content: part of the dissatisfaction comes from answers that were not wrong but outdated. The classic FAQ page convinces only 60 per cent (Bitkom) of its users, and only 28 per cent (Bitkom) would turn to an FAQ page at all when they have a problem with an order, while 36 per cent (Bitkom) want automated help in customer service - a maintained knowledge base is the answer to both findings.

What XICBOT brings to day-to-day maintenance

The knowledge base in XICBOT is built as an object to be maintained, not as a one-off import. Every source keeps its versions with a timestamp, website and file sources also their origin; website sources can be given a refresh cadence of their own, and a source whose confirmation is overdue is marked as stale in the source list instead of staying in effect unnoticed. Ownership and expiry date per content type live in the maintenance plan, not in the software. Website and shop content is re-read at a fixed interval, so service pages, category texts and help articles follow along without manual work.

Values that change hourly do not belong in a repository. Via tool control in the Custom package the assistant fetches stock, price, delivery date and, with a connected inventory system, order status from your system at the moment of the question; the shop assistant likewise queries price and availability of a named item in the shop when answering. What arrives there is the state of your system, not the state of an export. Existing processes can be extended through custom functions when your case goes beyond the standard.

The third ingredient is the return channel. Conversation analytics shows which questions were left without a supportable answer, which phrasings appear more often and where the knowledge base has a gap - sorted by frequency rather than by impression. Which content belongs in it in the first place is described in building a knowledge base; how the state is accepted before go-live is covered in acceptance testing. We hand over the maintenance plan as a table with cadence, ownership and expiry date at go-live; the documentation explains how it is run in operations. If you would like it tailored to your content types, talk to us.

Frequent questions