Knowledge base explained: what it holds, and what keeps it alive
A knowledge base is a structured, searchable collection of articles that answer the questions customers and agents actually ask, maintained as a byproduct of resolving contacts rather than as a separate documentation project. It is the content layer underneath every help centre, chatbot and portal, and the thing that quietly decides whether any of them work.
Also called a knowledge management system, a help centre when it is public, or a solutions database in older ticketing tools. The term is used loosely enough that it is worth asking which one someone means.
What goes in a knowledge base?
The useful distinction is between content written from what the product does and content written from what customers ask. Only the second kind reduces contacts.
- Troubleshooting articles. Symptom first, in the customer's words, then the check, then the fix. Titled the way people search, not the way the product team names components.
- How-to and task articles. One task per article. Length is not the enemy; scope creep is.
- Known error records. Confirmed defect, current workaround, expected resolution. The single highest-value content type during an incident, and the one most often kept in a chat thread instead.
- Policy and entitlement answers. Returns windows, warranty terms, escalation rights. Written once and cited, so five agents do not give four answers.
- Internal-only procedure. Access steps, refund thresholds, escalation contacts. Never published externally, and generally the part with no owner.
Internal versus external knowledge base
Most operations run both, and the mistake is running them as two disconnected libraries.
The internal base serves agents and needs system detail, thresholds and internal language. The external base serves customers and needs plain language and no assumed access. When they are separate projects, the customer-facing article and the agent's actual procedure drift apart, and the customer who read the article gets contradicted on the phone.
The workable pattern is one source, with sections flagged internal, published outward once they are safe to publish. Agents write against the case they just solved. An editor promotes what is ready.
How is a knowledge base kept current?
Knowledge-Centered Service (KCS), developed by the Consortium for Service Innovation, is the reference model, and its central idea is that articles are captured inside the workflow of solving a contact, not in a documentation sprint afterwards. Agents create and improve articles as they resolve issues, and demand decides what exists: an article gets written because someone asked, and improved because someone reused it.
The Consortium reports that organisations adopting KCS see resolution times improve by 25 to 50 percent in the first three to nine months, with improvement in customer success with self-service arriving later, typically in the nine to eighteen month band. The order matters: agent-side gains land first, customer-side gains follow, and programmes justified purely on customer deflection tend to get cancelled before the second phase arrives.
Knowledge base: a worked example
A team of 22 agents inherits a 900-article knowledge base. Search logs show 60 percent of successful searches land on 40 articles, and 480 articles have not been opened in a year. They archive the 480, rewrite the top 40 against the phrases customers actually type, and add a one-click "this did not answer my question" link that files the gap as a work item. Contact volume does not move for six weeks. First contact resolution moves first, because agents stopped improvising.
How to tell whether a knowledge base is working
Article count and pageviews measure effort, not effect. Four measures that survive scrutiny:
- Search success rate. The share of searches that end in an article being opened rather than a new search or an exit. Failed searches are your content backlog, already written by customers.
- Article-to-ticket rate. Of the people who read a given article, how many filed a ticket within 24 hours? A high rate on a high-traffic article is a rewrite instruction.
- Agent reuse rate. How often an agent links an existing article to a contact instead of typing a fresh answer. Low reuse means agents do not trust it, which is a content quality signal, not a compliance problem.
- Surveyed resolution. Ask the reader whether it answered the question. This is also the only defensible input to a ticket deflection figure.
Why knowledge bases rot
- Nobody owns it. Written during an onboarding project, maintained by whoever has time, which is nobody by month four.
- Written by people who do not take contacts. Product and marketing describe the intended behaviour. Support needs the behaviour customers actually hit.
- No trigger on product change. A release ships, three articles become wrong, and the first person to find out is a customer.
- Titles in internal language. The article exists and the search never finds it, so the same answer gets written a second time.
- Volume treated as the goal. An article count target produces 900 articles and 40 useful ones, plus a search index too noisy to work.
- Capture measured, reuse ignored. Rewarding article creation without measuring whether anything gets reused builds a library nobody reads.
The knowledge base is also where handle time is genuinely won. Most of the hold time inside average handle time is an agent hunting for an answer the business already has somewhere, and it is the one component you can compress without pushing the cost into a repeat contact. It is the same content, at the same time, that determines whether a self-service portal resolves anything at all.