How do I keep my knowledge base up to date automatically?

Every knowledge base starts out correct. You write your articles at a moment when you know how things work, you publish, and it all checks out. Then something changes. A price, a delivery time, a button that moves, a procedure someone adjusts because the old one stopped working. Usually so small that nobody thinks about the knowledge base. Six months later your documentation answers questions about a version of your company that no longer exists.

Why that happens structurally, and why reports do not solve it, is something we wrote out earlier in Why your documentation always goes out of date. If your product ships every week and your docs trail behind it, Keep documentation in sync with a product that ships weekly covers that angle. This post is about knowledge base maintenance in a support team. Which signals you already have, what you can pull out of them automatically, and where a human stays in charge.

Why the review calendar stalls

The standard approach is a calendar. Every article gets an owner and a review date, and each quarter someone works down the list. On paper it fits nicely. In a company of fifteen people it goes quiet within two quarters, and there is a good reason for that: most of that work is pointless. You reread articles that are still perfectly correct, while the article that is genuinely wrong is not on the list because its turn comes up in November.

A calendar assumes every article deserves the same attention. In practice a small share of your articles takes nearly all of it, and that share keeps shifting. Your customers point it out to you every day. You only have to listen in the right place.

The three ways a knowledge base goes stale

It helps to split staleness up, because each of the three kinds asks for a different response.

There is knowledge that is missing. Someone asks a question that is documented nowhere. A colleague answers from memory, the customer is helped, and the answer disappears again. This is the most common kind and at the same time the easiest to solve, because the answer has just been typed.

There is knowledge that is outdated. The article exists, it is written neatly, and it describes how things went last year. This is the most dangerous kind, because the customer has no reason at all to doubt it.

And there is knowledge that is incomplete. The article exists, it is even correct, but it does not go far enough. The customer reads it, is left with the question, and emails anyway. On your dashboard that article looks healthy. It gets read.

The signals you already have today

You need no extra tooling to know where it hurts. These signals are sitting ready at just about every company.

The same question keeps coming in even though the article exists. That means the article is impossible to find, unclear, or simply wrong. Whatever the cause, your customer is not getting anywhere with it.

Someone searches your site and gets nothing back. That is the sharpest signal there is, and also the most ignored. Watch the difference between a gap and a wording problem. If someone searches for "cancel subscription" and your article is called "Termination procedure", no knowledge is missing. A word is missing.

Your colleagues stop linking the article. In a small team that is the most reliable quality verdict that exists. Anyone who types the answer out instead of pasting the link made that decision deliberately.

New employees get stuck on a step. Every new colleague is a free test of your documentation, exactly once. Note where they stall, because within a month they will find it by themselves and that signal is gone.

And then there is the article with plenty of visitors that still produces a ticket. Outdated screenshots are the classic cause there.

What you can genuinely automate

This is where the word "automatically" has to be made honest. Automation takes over the spotting. The decision moves, it does not disappear.

A system can collect those signals, group them and put them in order. It can see that five people asked the same thing this week without getting an answer. It can find two articles that contradict each other. It can write a draft based on an answer a colleague just sent, with the customer's question as the title. That is real work you no longer do yourself.

What stays human work: checking whether it is correct. Deciding whether this becomes a new article or an addition to an existing one. Guarding the tone. And above all, deciding what you leave undocumented.

That is also where the trap sits. Detection is not the problem. Every tool can show you a list of gaps. It goes wrong at the queue nobody empties, because that queue is extra work sitting next to the real work. A system that produces fifty suggestions a week and no moment at which someone handles them has moved your problem rather than solved it.

So the measure that counts is the time between "something is wrong here" and "it is corrected and online". As long as that stays short, your knowledge base stays correct.

How this works in Sarrai

We made that part as small as we could. Sarrai answers questions from your knowledge base and tracks how certain it was of each answer. That certainty is the engine.

If Sarrai could not answer the question, your employee is asked when sending their reply whether it may become a draft article. One click, and the customer's question becomes the title, the answer becomes the content.

If Sarrai was unsure, the system compares the articles it used with what your employee answered, and proposes right away which article should be updated and how.

If Sarrai was certain and your employee answered something else anyway, that is the most interesting case of all. That is an article that looks complete and is no longer correct. Without the comparison you never find it.

Every proposal lands in one approval inbox. You see where the proposal came from, which conversation triggered it and what exactly would change. Approve, adjust and approve, or reject. The digging is done, you decide.

On top of that, reporting shows you the patterns that only become visible across a hundred conversations, such as searches that return nothing or articles that get read and still produce a question.

What you can do on Monday

You do not have to wait for any of that to start. Open your search statistics and look at where people find nothing. Ask your colleagues which article they deliberately stopped sending. And agree that one person has a fixed moment each week to work through the open proposals, even when there are only three.

A knowledge base stays up to date when updating it is so small that it always fits, even on a busy day. Your whole solution sits in that.