Building a knowledge base: start from the questions, not the documents

The short version

• A knowledge base should start from the questions people repeatedly ask, not from a migration of existing documents.
• Every knowledge base page needs a named owner and a review date, because a stale page looks exactly like a correct one.
• Failed searches are the best guide to what a knowledge base should cover next.
• Tool choice matters less than ownership: a well-kept wiki serves people better than a neglected platform.
• Adding AI to a knowledge base does not fix wrong content. It repeats it in confident sentences.

What are the steps to build a knowledge base?

1. Decide who it serves: staff, customers or both. If both, plan two separate knowledge bases.
2. Collect the questions people already ask, from support tickets, team chat and new starter onboarding.
3. Rank those questions by how often they repeat and what a wrong answer would cost.
4. Name one owner for each topic area before anyone writes a page.
5. Write one page per question, with the answer in the first two lines.
6. Publish in the simplest tool that has search, permissions and page history.
7. Read the failed searches every week and write only the pages they call for.
8. Give every page a review date, and archive any page that misses it.

What is the first step in building a knowledge base?

The first step in building a knowledge base is listing the questions people actually ask. Do not start with an audit of existing documents. Documents record what somebody once needed to write down. Questions record what somebody needs to know today, and the two lists overlap less than you would expect.

The list is quick to gather. Read the last few months of support tickets. Search team chat for phrases like 'does anyone know' and 'where do I find'. Ask recent starters what they had to ask in their first month. Then ask the person everybody interrupts, because that person is the knowledge base you currently have.

Rank the list by two things: how often a question repeats, and what a wrong answer costs. A refund rule asked twice a month may matter more than a printer question asked daily. Start with about twenty questions. That number is a workable starting size, not a research finding. The aim is to finish something small and accurate before building the knowledge base any further.

Should staff and customers share one knowledge base?

In most cases, no. Staff and customers should have separate knowledge bases, because they differ in audience, tone and exposure. Internal pages hold workarounds, pricing exceptions and the names of people to call. Customer pages hold instructions, and search engines are meant to find them.

A shared system depends on one visibility setting being right on every page, every time. One wrong setting publishes an internal note. Keeping the two apart removes that failure instead of managing it. Where both need the same fact, such as a returns period, keep it in one place and link to it from the other. Two copies of a fact will eventually disagree.

How should you write a knowledge base article?

Write one page per question, title it in the words people use, and put the answer in the first two lines. Readers arrive with a specific question and leave once they have the answer. Anything that delays it gives them a reason to go back to asking a colleague.

Keep background below the answer, not above it. Split a page when it starts answering a second question. Link to the system of record instead of copying from it, so a policy lives in one place. Short, single-question pages are also easier for search to match, and easier for an AI assistant to retrieve cleanly later.

What should every knowledge base page record?

Which tool should you use to build a knowledge base?

Use the simplest tool your people already open, provided it has search, permissions and page history. Choose it after you have the question list, not before. A tool chosen first shapes the project around its features. A well-kept wiki serves people better than a neglected platform.

Internal teams often start with a wiki such as Confluence or Notion. Customer-facing knowledge bases often sit inside support software such as Help Scout. Atlassian publishes a free Confluence sign-up, which is a low-risk way to test the habit before paying for anything. Its pricing page returned no readable prices when we read it in November 2026, so paid tiers are not covered here.

Read vendor prices carefully, because the billing period is not always clear. Notion's pricing page offers 'Save up to 20% with yearly' and does not say which billing period its listed price reflects, so paying monthly may cost more. Help Scout's plan prices carry no billing label, and its add-on pricing suggests the default view may show annual rates. Confirm the monthly price per seat before you compare. We hold no partner badges with any of these vendors.

What should you add to a knowledge base after launch?

After launch, add only what failed searches and repeat questions ask for. Anything else is a guess about what people need, and guesses are how a knowledge base fills up with pages nobody reads.

Keep the routine small. Once a week, one person reads the failed search log and the repeat questions, then sorts each one. If the answer exists but the words did not match, change the title or add the term people used. If the answer does not exist, add the question to the list and give it to the topic owner. If a question keeps coming back despite a good page, look at the process that causes it, because a page will not fix that.

How do you keep a knowledge base from going stale?

Keep a knowledge base from going stale by giving every page a named owner and a review date, then archiving the pages that miss it. Staleness is the normal failure because nothing breaks when it happens. An out-of-date page looks exactly like a correct one and keeps appearing in search.

The damage spreads beyond the one wrong page. Someone who acts on a bad answer stops trusting the rest and goes back to asking in chat. Once that habit returns, the pages stop being read, owners stop updating them, and the decline feeds itself.

Two rules help. First, tie updates to changes: a price, policy or process change is not finished until the page is updated. Second, make the review date do something: a page past its date shows readers a warning, then gets archived if nobody acts. A smaller set of trusted pages is worth more than a larger set nobody believes.

How do you measure whether a knowledge base is working?

A knowledge base is working when the same questions stop being asked. Count repeat questions in chat and tickets for two weeks before launch, then compare afterwards. Without that baseline, nobody can say whether the work helped.

Three other signals are worth a weekly look: searches that return nothing, searches where the reader opens nothing, and the share of pages past their review date. Page views are a weak signal. A busy page may be useful, or it may be so unclear that people keep coming back to it.

Do not lean on someone else's survey to justify the project. APQC published a 2021 survey of 982 full-time knowledge workers under the headline 'KM Makes Knowledge Workers More Productive and Less Stressed Out', where KM means knowledge management. It was not specific to small firms. We could not open the full report, so the sample size and date come from search results for APQC's own pages, and the blog post carrying that headline states no method. Treat it as direction, not proof. Your own before and after count will tell you more.

When should you add AI to a knowledge base?

Add AI to a knowledge base after the content is owned and current, and only if people still cannot find answers through search. An assistant retrieves passages and writes an answer from them. It does not know which page is out of date, so it can state an old policy in a complete, confident sentence.

Three things need to be in place first. Contradictions between pages need resolving, because retrieval may surface either version. Permissions must be enforced before retrieval, because copying content into a search index creates a second access surface that does not inherit the original rules. And every answer must link to the page it came from, so a reader can check it.

The question list from step one has a second use: it becomes the test set. Run those questions through the assistant and check the answers against the pages. Then check that a user without access cannot reach restricted content. If the assistant fails on questions you already know the answers to, it is not ready for the ones you do not.

What does it cost to build a knowledge base?

The main cost of a knowledge base is staff time, and much of it comes after launch. Licences are often the smaller line. Nobody can give an honest number without knowing your page count and how fast your content changes, and we do not have a measured figure to offer.

Work it out from your own numbers. Multiply the page count by the hours to write and check each page. Add the weekly time for reading failed searches and the time owners spend on reviews. Price those hours at your own salaries. If developers are involved, the US Bureau of Labor Statistics publishes a median wage you can use as a rough benchmark, but it is a salary figure, not a measured cost of building a knowledge base.

When is building a knowledge base not worth doing?

Building a knowledge base is not worth doing when the team is small enough to ask each other, or when nobody will own it. A handful of people in one room already share knowledge faster than any page can. Writing everything down early produces pages that go stale before anyone needs them.

It is also the wrong fix when the question has a better home. If customers keep asking how to complete a form, change the form. If staff keep asking for a number that lives in another system, give them access to that system. And if a topic changes faster than anyone will update the page, name the person to ask instead of writing a page that will mislead.