A customer hit "Was this helpful? No" on one of our KB articles last quarter. I opened the article to see why. It was referencing a UI menu that we had renamed eight months earlier. The screenshot showed a button that no longer existed. The steps were for a workflow we had completely changed. The article had been published, never touched again, and had served customers wrong answers for the better part of a year.
That is KB rot. And nearly every support team has it. The problem is not that teams build bad knowledge bases. The problem is that they build reasonable ones, ship them, and then treat them like reference books instead of living documents. Features change. Pricing changes. Interfaces get redesigned. The KB stays the same. Six months later, customers follow an article and end up more confused than when they started.
The fix is not a big rebuild. It is a simple audit followed by a light maintenance routine. Here is both.
The Signs Your KB Has Rotted
You often cannot see KB rot from the inside. Articles look fine. The KB is "there." But there are reliable signals if you look for them.
- Agents stop linking to it. If your agents are copy-pasting answers from memory or Slack instead of sending KB links, it usually means they stopped trusting what is in there. Ask three agents this week: when did you last link a customer to the KB for a common question? If the answer is "a while ago," that is the signal.
- Tickets repeat topics you know are in the KB. If customers keep asking questions you already have articles for, two things are possible: the articles are hard to find, or the articles are wrong. Either is a KB problem.
- Deflection rate is flat or dropping. If you run a chatbot or help widget and its containment rate has been declining for months without a corresponding rise in ticket complexity, stale content is likely pulling it down.
- "Not helpful" ratings cluster on specific articles. Most platforms that serve KB articles (Zendesk Guide, Help Scout Docs, Intercom Articles) log feedback. If you have never looked at the negative feedback list, do that today. Cluster the unhelpful votes and you will find your worst offenders.
- New agents give wrong answers using KB articles. This is the most damaging one. A new hire who trusts the KB is the customer who gets misinformation at scale.
The One-Day Audit
You do not need a week to audit a knowledge base. You need a structured half-day and a spreadsheet. Here is how I run it.
Step 1: Pull the full article list with last-modified dates. Export this from your platform. Every article older than six months is a candidate for review. Every article older than twelve months is mandatory.
Step 2: Tag each article by category. I use four buckets: Pricing and billing, Product how-to, Account and access, Policy and legal. Articles in the first two categories go stale fastest. Anything touching pricing, free trial limits, or feature names should be treated as perishable.
Step 3: Walk through each article as a customer. For each candidate article, follow the steps yourself. Does the UI match? Does the menu path exist? Does the outcome described actually happen? This is tedious, but it is the only reliable method. Screenshots lie; reading the article as text does not catch a renamed button.
Step 4: Flag each article as Pass, Update Needed, or Delete. Delete is underused. Some articles should be retired, not updated. If you rewrote a feature from scratch and the old flow is gone entirely, delete the old article. A missing article is better than a wrong one.
Step 5: Note what is missing. While auditing, keep a running list of questions that come in frequently but have no KB article. These gaps are your next build list, not a rebuild list.
- Agents avoiding the KB, answering from memory
- Customers following steps that no longer work
- Deflection rate declining with no clear cause
- New hires trained on stale information
- Agents linking to KB confidently for routine questions
- Articles match the live product
- Deflection recovering as customers self-serve successfully
- New hires onboarded on accurate content
What Makes a KB Article Actually Good
Auditing surfaces the rot. But fixing it means knowing what good looks like. Here is the standard I use when rewriting or creating articles.
One article, one job. Every KB article should answer exactly one question. "How do I reset my password" and "How do I change my email" are different articles, not a combined one. Customers searching for one will scan past the other and think they did not find what they needed.
Lead with the outcome, not the steps. The first sentence should tell the customer what they are going to be able to do after reading. "You can reset your password from the login page without contacting support" tells them immediately whether to keep reading.
Number the steps. No exceptions. Prose instructions for multi-step processes fail at scale. Customers lose their place, skip a step, and end up back in your queue. Numbered steps are not a stylistic choice; they reduce repeat tickets.
Screenshots that age gracefully. A screenshot of a settings panel will be wrong within two product cycles. Either avoid screenshots for navigational steps, or annotate them lightly enough that a renamed button does not break the whole image. I increasingly prefer text descriptions over screenshots for step-by-step flows.
An explicit "last reviewed" date. Put it at the bottom: "Last reviewed: July 2026." It tells the customer whether to trust the article and tells your team when it is due for its next check.
A good KB article is not one that covers everything. It is one that leaves the customer knowing what to do next, without needing to open a ticket to clarify the article itself.
The 30-Minute Weekly Maintenance Routine
The audit gets you current. The routine keeps you there. This is what I run every week, and it takes about 30 minutes.
- Check negative feedback from the past 7 days. Open your KB platform's feedback dashboard. Any article with two or more "not helpful" votes this week gets flagged for immediate review.
- Scan the ticket queue for repeat patterns. Pull tickets from the past week where agents used a saved reply or macro that included a KB link. If the same question came in five times, either the article is hard to find or the article is not solving the problem. Both are worth investigating.
- Review any product changes from the past 7 days. This is the one people miss. Sync with your product team or subscribe to the internal changelog. Any feature change, pricing update, or UI edit triggers a KB check. Who owns that article? Is it still accurate?
- Add one missing article per week. The audit surfaced a gap list. Work through it, one article per week. This is how the KB actually grows to match your product rather than lagging two years behind it.
Thirty minutes. Weekly. That is it. The discipline is not in the time, it is in actually doing it every week rather than batching it for a mythical "KB sprint" that never ships.
Who Owns This
The routine above only works if someone owns it. "Everyone is responsible" means no one is. In my experience, the right owner is the support lead or ops person, not a content writer who is not close enough to the ticket queue to know what is breaking.
At the US top company I work with, the support team triages article feedback during weekly syncs. Any "not helpful" cluster from the week gets assigned to the agent who most recently worked that issue type. They know the current answer. They write the update. The lead reviews and publishes. Total time per updated article: roughly 20 minutes, because the person writing it already knows the answer.
That is the model that scales. You are not hiring a KB manager. You are building a lightweight process where the people closest to the problems own the documentation of the solutions.
One More Thing
The KB is also one of the best recruiting signals for new support hires. Before you hire someone, show them your knowledge base and ask them to find the answer to a common customer question. If they find it in under two minutes, your KB is working. If they struggle, you have just been reminded what your customers experience every time they try to self-serve.
That test has never steered me wrong.
If you want to compare notes on KB structure or share what has worked on your team, drop me a message. Always glad to see how other teams are approaching this.
Comments