What is a knowledge base, and how do you build one?
By Gregory Culpin
What a knowledge base is, how it differs from a document management system or a wiki, and the three questions to ask about any article in yours.
A knowledge base is a library of organised, dated and maintained articles where your teams and your customers find an answer without having to ask anyone for it. The same phrase covers a software company's public help centre and an IT department's internal reference.
The definition fits in one sentence, and it says nothing about what separates a useful knowledge base from a shared drive with a search box. That difference does not show up in a feature list. It shows up article by article: does the one you just opened have an owner, a date when someone last checked it, and a rule that says who may read it?
What a knowledge base holds
A knowledge base gathers what your organisation knows in written, searchable form: procedures, step-by-step guides, answers to frequent questions, product sheets, incident write-ups. It serves two audiences, and most organisations need both.
The external knowledge base is public. It is the help centre your customer opens at 22:00 to reset a password. It brings the request count down, and it can be measured: views per article, share of requests solved without contact, tickets raised on a subject already documented.
The internal knowledge base is for your teams only. It carries what cannot be published: what to do with an unhappy customer, the exact configuration of a laptop, the floor price in a negotiation, what a project taught you when it went wrong. It is the one that costs the most when it is missing, because the answer then sits in three people's heads.
Why the phrase means two different things
Knowledge base covers two ideas with separate origins, and the confusion is old.
The first comes from the artificial intelligence work of the 1970s and 1980s. In an expert system, the knowledge base is the part that holds the facts and the rules, kept separate from the inference engine that applies them. In that sense a knowledge base is what a program reads, not what a person reads.
The second comes from customer support in the 1990s: the help centre, the FAQ, the troubleshooting article. That is the everyday meaning today, and the one most software vendors use.
The two meanings have met again over the past two years, which is why the phrase is back. As soon as you connect an AI agent to your content, your help centre becomes what an expert system's knowledge base always was: the material the program reads in order to answer. An out-of-date article no longer inconveniences one reader. It produces a wrong answer at scale.
Knowledge base, document management, wiki: what each is for
Most organisations have more than one of these tools. They usually have a document management system, often a wiki or a collaborative space, and sometimes a knowledge base. Mixing them up is expensive, because each one is expected to do something different.
| What people look for there | What an AI agent finds there | |
|---|---|---|
| Document management | proof: the authentic document, its version, its archive | whole files, from which it has to extract an answer without knowing if it still applies |
| Wiki | work in progress: a team's notes, drafts and discussions | pages, without knowing which are still right |
| Knowledge base | the answer: what to do, checked and dated | an answer, with the person responsible and the date it was last checked |
A document management system keeps track of what was signed or decided, and it does that well. A wiki makes writing easy, which is its strength at ten people. Above that it degrades quickly, because nothing obliges a page to be reviewed: we covered that limit in wiki, intranet and knowledge management. A knowledge base answers a different question: what should be done in this case, and who stands behind the answer?
These tools complement each other, and one solution often covers several of these needs: a document management system can publish procedures, and a knowledge base can store files and hold drafts. The choice therefore comes down to the primary use. A tool built for proof handles the review of answers badly, and a tool built for answers is not meant to hold the legal archive. Name the use that comes first, then check that the secondary uses fit in the same tool without getting in the way of its main job.
Among our customers, it is often the wiki that a knowledge base replaces: people can still write together, and governance moves to the front, article by article. The knowledge base can also connect to Google Drive or OneDrive, or act as a light document management system for a few reference documents: those are secondary uses, not its strength. So the document management system keeps its place: the signed contract stays there, and the knowledge base says what to tell a customer asking for a refund, linking to the contract if needed.
The three-question test
Open your knowledge base, pick an article at random, and ask these three questions about it.
Who owns it? A person, not a team. A page nobody is responsible for will never be corrected, because everyone assumes somebody else is handling it.
When was it last checked? The date it was written tells you nothing. What counts is the day someone reread it and confirmed it was still right. With no review date, a knowledge base goes stale quietly, and the first person to notice is a customer.
Who may read it? A knowledge base without read rights ends up holding only what can be shown to everyone, which is the least useful material there is. Price lists, incidents and sales arguments stay in people's inboxes instead.
If all three answers come easily for an article picked at random, your knowledge base works. If they take an investigation, you have a shared drive with a search box.
How to build a knowledge base
The hard part is not the tool. It is deciding what to write and who writes it. Five decisions make the difference.
Start from questions, not from documents. Do not copy the folder tree of the shared drive. Take the last hundred requests your support desk, customer service or IT team received, count the repeats, and write the twenty answers that come up most. Twenty accurate articles beat two thousand whose state nobody knows.
Match the format to the question. An article works when the answer is the same for everyone. As soon as it depends on the reader's situation, a decision tree does better: a short run of questions takes the user or the support team to the right conclusion without making them read the whole documentation. A good tree copies nothing. It strings together articles that already exist, or you maintain the same procedure in two places.
Name an owner before the article is written. This is the decision that prevents decay, and the least popular one, because it turns a one-off contribution into a standing commitment. Put it in that person's workload.
Set a review date on the day you publish. Six months for a stable procedure, six weeks for a price or a configuration. When the date arrives, the owner is notified, and the article stays flagged for checking until they have reread it.
Split by team. An organisation of a thousand people does not write in one space. The platform stays shared, and the content lives in separate spaces, one per team or business area, each with its own owners and rights. L'Oréal Opérations runs 113 of them, in about fifteen families by business area, for 22,000 people.
What AI agents change for your knowledge base
The question put to knowledge bases has changed. It is no longer whether a person can find the answer, but whether an AI agent can give it on their behalf without getting it wrong.
That changes the work. Keyword search forgave a great deal: a reader who found two contradictory procedures took the more recent one, or asked a colleague. An AI agent has no such reflex. It reads both, averages them, and returns an answer that exists nowhere in your content.
Four things then matter more than they used to.
- A duplicate becomes an error. Two versions of one procedure are no longer an inconvenience. They are a source of wrong answers.
- Read rights have to hold inside the answer. If the AI agent answers from everything it has read, it will one day quote a board-level document to an intern. Rights have to apply at the moment of the answer, and not only when a page is displayed.
- The content has to stay text. An AI agent reads text, not a layout. An article and a decision tree written in Markdown import and export without loss, and the AI agent receives the owner, the review date and the approval status along with them, which is what it needs to judge whether it can use the answer.
- The source has to be cited. An answer with no link back to the article it came from cannot be checked, so it will not be used for a decision anyone is accountable for.
This is what we call the foundation: the layer of governed content the AI agents answer from. We set it out in why enterprises fail at the knowledge foundation, and the signs of drift in how to keep an AI knowledge base healthy.
Common questions
A library of organised, dated and maintained articles where your teams and your customers find an answer without having to ask anyone for it. It holds procedures, step-by-step guides, answers to frequent questions and product sheets. What separates it from a shared drive is not the search box. It is that every article has a named owner, a review date and read rights.
Start from the questions you receive, not from the documents you already have. Take the last hundred requests to your support desk, count the ones that repeat, and write the twenty most frequent answers. Give every article an owner before it is written, set its review date on the day you publish, and split content by team rather than putting everything in one place. The tool comes after those four decisions.
It depends on who reads it. For a public FAQ attached to tickets, the module in your ticketing tool is usually enough. For a product documentation portal, dedicated tools exist. For knowledge that has to serve several departments and feed AI agents, the question becomes one of a platform. We compared the market in two guides: knowledge base software and customer service knowledge base.
A document management system keeps the proof: the authentic document, its versions and its archive. A knowledge base gives the answer: what to do in a given case, with someone who stands behind it. The two complement each other: the document management system keeps the signed contract, and the knowledge base says what to tell the customer about it. One solution can cover part of both needs, provided you know which one comes first.
The one reserved for your teams and never published. It holds what you do not show outside: procedures, configurations, sales arguments, lessons learned, floor prices. It is the harder one to maintain, because nothing outside checks it, and the one whose absence costs most, since the knowledge then stays in a few heads.
Explicit knowledge is already written and can be passed on as it stands. Tacit knowledge is built from experience and hard to put into words. Implicit knowledge could be written down but nobody has taken the time. Procedural knowledge is the know-how of a task, the sequence of steps. A knowledge base captures the first one easily. The work is in the other three, which we described in 3 types of knowledge to capture.
Where to start
Open the knowledge base you have now, pick one article at random, and look for its owner and its review date. How long that takes tells you where you stand. If you want to see what it looks like when the tool carries both, book a demo.