Nobody Reads Your Knowledge Base
Probably not even you! Naughty.
Let me open with a question that I already know the answer to: when was the last time anyone in your organisation actually READ your knowledge base?
Not wrote an article for it. Not pasted a link into a chat while quietly praying. Read it. The way a customer would read it. Starting from a problem, hoping to find a way out.
If your answer is anything other than a pained “Uhhhhhh . . .”, congratulations, you are in a vanishingly small club and you may spend the rest of this article feeling smug. Everyone else, come sit by me. I’ll even bring some snacks. No (extremely hypocritical) judgement over here. I have built support organisations from nothing, I have preached the gospel of self-service to anyone who would stand still long enough, and I have ALSO shipped a knowledge base, felt enormously proud of it, and then not meaningfully looked at it again until something was on fire (I may as well get the phrase “Do as I say, not as I do” . . . uhm “did” tattooed somewhere. It comes up A LOT).
I keep coming back to this topic though. The knowledge base is the only part of a support operation that scales for free. I know, right? Crazy talk. When did YOU last encounter something that was free? Every other improvement has an ongoing bill attached. More agents cost salary. Better tooling costs licences. Coaching costs hours, every week, forever. A good article costs you once, and then it answers the same question ten thousand times without a sick day or a bad mood. Nothing else in the entire support world has that return profile.
And yet. AND YET. We still let them rot.
So let’s talk about why, because the reasons are remarkably consistent. I have inherited, audited, or rebuilt support functions at companies of wildly different shapes and sizes, and the same three failures show up every single time. EVERY time.
Nobody owns it. The typical knowledge base was created in a burst of enthusiasm by somebody who has since changed roles, changed companies, or changed careers entirely. It has been updated ever since by “whoever has a minute”, and I regret to inform you that nobody has a minute. The result is articles from three product versions ago sitting directly beside the one written last Tuesday, with nothing to tell your customer which is which.
They find out, of course. The hard way. Once.
In my humble (but right) opinion, an out-of-date article is worse than no article at all, because a missing answer may frustrate the customer but it will still send them to the queue. It may annoy or overwhelm you, but look at it as a reason to update things. It’s what we do! But a wrong answer walks them confidently into a wall. Now they may not trust ANY of your articles, including the good ones. You didn’t lose one answer, you lost the whole library (”trust”, as I find myself repeating in about every third thing I write, is the entire game. If you lose it that early, why even take the field?).
Your customers do not speak product. This one stings because the work was actually done. The article exists. It is even accurate, which as we just covered is a small miracle. But it was titled and written by the person who built the feature, in the language of the person who built the feature. You called it “Configuring authentication token rotation”. Your customer is typing “why do I keep getting logging out”.
Those two people are describing the same problem and they will never EVER find each other.
Whenever I start with a new team, one of the first things I ask for is the search data from whatever platform hosts their help content (oh dear saints and all the little fishies, let them have configured their help center to properly collect the data. And I’ll do a dance for the ones that integrated into other systems!). But specifically I want to see the dead ends. Searches that returned nothing, and articles that customers read immediately before contacting support anyway, which is a customer telling you, quite politely, that your article did not do its one job (and less politely that your article SUUUUUUUUCKED). Every platform on the market collects this. A lot of folks don’t configure it and almost nobody looks at it. Which makes Ash sad.
Go pull yours up. Seriously. I’d say I’ll wait, but if it’s not configured then we might be here a while . . .
That reaction you are having right now? I have watched it land on a lot of faces, and it is always the same short journey: from “oh no” to “well, THAT explains a few things.”
It was written by experts, for experts. The curse of knowledge is a real, documented thing: once you understand a system deeply, you lose the ability to remember what not understanding it felt like. So the article gets written by your most knowledgeable person (sensible!), and comes out complete, precise, technically flawless, aaaaaaaaaaand COMPLETELY useless to a stressed customer at 11pm who just wants to know why the doowacky won’t do the thingy the way they think it should. It MUST be broken!
The fix is almost embarrassingly simple: before a new feature goes live, the article needs to be ready. And before the article goes live, someone who did NOT write it has to solve a real problem using only that article. Not proofread it. USE it. If they cannot, the article is not done, which means that the feature isn’t either!
So, in the immortal words of John Oliver: What can we actually DO about all of this?
One thing, and I promise it is not exciting: we treat the knowledge base like a product instead of a pile of documents. Products have fancy things like owners, roadmaps, and usage data that a human reviews and acts on. The moment a knowledge base gets those three things, it starts getting better every month instead of quietly degrading. I have personally seen this play out enough times that I no longer consider it a theory.
The concrete version that I have seen work goes thusly (how’s this for solid next steps, eh?):
Get yourself a product owner with actual time. One person accountable for the health of the library. When an article has not been reviewed in a set period, or the product changed underneath it, or the data says customers are bouncing off it, that person gets a nudge and has the hours to act on it. Since this is someone’s real job function, they are both empowered to spend the time AND to chase down the people who they need to action on it. Pretending it can happen “in the gaps” is precisely how we all got here.
A feedback loop from the queue. When agents keep answering the same question, the reflex needs to NOT be to just shrug and keep trying harder. It needs to be to ask specific internal troubleshooting questions: Does an article exist? Can a normal human find it? Can a normal human read it? Is it factually correct? If yes to all of the above, why are these humans not finding it? Fix whichever one or more failed, as part of the normal work.
Two audiences, two formats, two repositories. Your customers need explanations. Your agents, thirty seconds into a live chat, need answers. Those are different documents that happen to share facts. Teams that serve both audiences with one set of articles end up serving neither, and the agents quietly build a shadow library of personal notes instead . . . which is how an organisation ends up with fifteen slightly different versions of the truth. I tend to call the public-facing one a help center and the internally-facing one a knowledge base, but you do what’s right for your team!
None of this is glamorous. I’m not going to say that nobody gets invited onto a conference stage to talk about their article review cadence (because I saw that Write the Docs is coming up, and I’m willing to bet that those folks are TOTALLY going to be talking about this exact topic! I love my writing nerds). But a knowledge base that is actually cared for is going to lower contact volume, help your reps, and give customers the thing many (most? Dare I say all?!) of them actually prefer . . . solving the problem themselves without talking to anyone. That’s the good stuff. That’s the whole point of self-service.
But somebody should own it. They NEED to own it. Which means they should have actual, real time to own it.
So that’s it. That’s the entire strategy. It fits on a sticky note. I said that it was free at the beginning of my article . . . and I lied. I do that sometimes, apparently. It is not free . . . and pretending it was is actually how we all ended up with libraries nobody reads, and with an article named after the thing your customers are not doing. Don’t do that.