How to choose knowledge base software, and what the shortlists leave out

The short version

• There is no single best knowledge base software: the categories serve different audiences and are not substitutes for each other.
• Knowledge base tools fall into five groups: internal wikis, help centres bundled with a support desk, standalone documentation platforms, docs kept as code, and retrieval layers over systems nobody will migrate.
• Search quality decides whether a knowledge base works, because nothing is read until it is found.
• Almost every published figure about knowledge bases and ticket deflection comes from a vendor measuring its own product.
• A knowledge base with no named owner and no deletion habit becomes a source of confident wrong answers.

Which type of knowledge base tool do you actually need?

Start with the audience, not the feature list. Knowledge base tools split into a handful of categories that look similar in a screenshot and behave nothing alike in year two: internal wikis, help centres bundled with a support desk, standalone documentation platforms, docs kept as code in a repository, and retrieval layers that sit over systems you are not going to migrate.

The first sorting question is who reads it. Staff reading internal process notes want fast editing, loose structure and the ability to paste a screenshot. Customers reading an online knowledge base want one canonical page per problem, written in their words, reachable from search. A tool built for the first audience serves the second badly, and the usual symptom is a public help centre full of internal shorthand.

The second question is whether the content tracks a release. An application knowledge base, meaning documentation for one product rather than for the whole company, has versions, deprecations and a changelog. That is a different job from an internal wiki, and it is the job standalone documentation platforms are built for. Confluence and Notion sit in the wiki group. Zendesk and Intercom bundle a customer help centre with their support desk. Document360 is sold as a standalone documentation platform. Docusaurus and MkDocs keep the docs in the repository next to the code.

A knowledge base software comparison is only useful inside one category. Comparing a team workspace against a docs-as-code pipeline produces a feature grid where both sides lose.

Knowledge base categories, and where each one breaks

How do you compare knowledge base software without being sold to?

Bring your own questions. The fastest honest test is to take the fifty questions your team or your customers actually asked last month, load the same real source documents into each shortlisted tool, and check whether the correct page comes back first. Vendors demo with a clean corpus and queries they chose.

Do the loading yourself, and include the badly written pages. Every knowledge base platform performs well on a tidy sample. What matters is behaviour when two pages contradict each other, when a policy was updated in one place and not the other, and when the searcher uses a word that appears nowhere in the document.

Then check the boring things, because they are the ones that end a contract: export, permissions, and who can publish. Ask for a full export on day one of the trial and look at what you get. A knowledge base solution you cannot leave is a knowledge base solution you will keep renewing on their terms.

What to test in a two-week trial

• •Load fifty real questions and score whether the correct page is the first result.
• •Import your messiest existing content, not a curated sample.
• •Request a full export and inspect the format, including images, hierarchy and page history.
• •Check how permissions are expressed, and whether they are enforced on search as well as on page views.
• •Find out who can publish without review, and whether that can be changed.
• •Ask what the search actually does: keyword, vector, or both, and whether you can see why a result ranked.

Why does search decide whether a knowledge base works?

Because nothing gets read until it is found. Content quality is capped by retrieval: a perfect page that ranks fourth for the question it answers is, from the reader's side, a page that does not exist. This is why the editor, the templates and the theming matter less than buyers expect, and why search is the feature hardest to judge from a demo.

The failure is usually vocabulary, not ranking. Customers describe symptoms, documentation describes features. Someone whose card was refused searches for 'declined', and the page is titled Payment authorisation errors. Keyword search misses it. Semantic search often catches it, then confidently returns a near neighbour that is wrong in a way a keyword miss never is.

So test both directions. Ask the questions where you know the answer exists and check that it comes first. Then ask questions where no answer exists and watch what the tool does. A knowledge base system that returns a confident wrong page for an unanswerable question will do the same thing to your customers all year.

What do the published numbers about knowledge bases actually tell you?

Less than the headlines suggest, because nearly all of them are vendors measuring their own products. That is not a reason to ignore them. It is a reason to read the method before the figure, and to treat every number as a claim about one installed base rather than about your situation.

Zendesk's ticket analysis covers 165 million intent-labelled support tickets from paid Zendesk accounts, which is a large sample, and the page states the period only as a fiscal quarter. Its help centre benchmarks come from a random sample of 500 active help centres, each with at least 300 monthly views, drawn from an index of 45,000 participating customers across 140 countries, with no measurement window stated. Both are useful. Neither is a controlled study, and the second excludes by construction every help centre too small or too neglected to clear 300 views a month.

Resolution rates deserve the same reading. Intercom reports a 76% average resolution rate across an installed base of more than 12,000 Fin customers, and publishes no measurement window, weighting method or definition of resolution. The figure may be accurate for whatever it measures. You cannot tell what it measures, so you cannot forecast your own number from it.

Survey evidence has the same shape. Intercom's 2026 report surveyed 2,470 customer support professionals, half of them from teams of fewer than 50 people. Atlassian surveyed 12,000 knowledge workers and 200 executives, and the page gives no countries or fielding dates. The sample sizes are not the problem. The missing method is.

The practical conclusion for a buyer: measure your own baseline before you buy anything. Count the questions that arrive, how many already have an answer written, and how often that answer was found. Those three numbers are worth more than any published benchmark, because they are yours.

What does an online knowledge base system cost to run?

The licence is the small part. The recurring cost is the time of the people who write, review and retire pages, and that cost does not fall when you change platform. A team that could not maintain forty pages in a wiki will not maintain forty pages in a better product.

Budget for an owner. Not a committee: one named person whose job description includes the knowledge base, with a review date per page and the authority to delete. Deletion is the part teams never plan and the part that keeps the thing trustworthy. An out-of-date page is worse than a missing page, because it gets found, quoted and acted on.

The second cost is migration, paid twice: once on the way in, once on the way out. Ask what the content looks like after export, not whether export exists. Most knowledge base products export something. Whether that something keeps your page hierarchy, your images and your internal links is a different question, and it is answerable in an afternoon during the trial.

When is a knowledge base not worth building?

When nobody owns it, when the answers change faster than anyone can write them, or when the whole thing fits in a dozen pages that already sit where people look. Buying a knowledge base platform for a team of six is often a way of deferring the conversation about who writes things down.

Three cases where the honest answer is 'not yet'. The product is changing weekly, so documentation would be wrong before it was reviewed. Or the real problem is that two teams disagree about the process, which a new tool will record rather than resolve. Or the content exists but is scattered across systems people will not leave, in which case a retrieval layer over those systems is cheaper than a migration.

Saying no here costs nothing. Reversing a migration costs a quarter.

What changes when an AI assistant reads the knowledge base instead of a person?

Structure starts to matter more than style. A person skims a long page and finds the relevant paragraph. A retrieval system splits that page into chunks and may hand the model the chunk that lost the condition the paragraph depended on. One idea per page, with the qualifying sentence next to the claim it qualifies, survives chunking. A sprawling page covering eight scenarios does not.

Freshness changes too. 'we keep everything' is an awkward answer once a retrieval layer is live, because the superseded policy page from three years ago is now a candidate answer with the same standing as the current one. Archiving stops being hygiene and becomes a correctness requirement.

So does access control. The moment content is copied into a search index you have a second surface with its own rules, and it does not inherit the rules of the first. Permissions belong before retrieval, not applied to the results afterwards.

This is why the best knowledge base tools question has changed shape. For years the answer was about editors, templates and theming. If machines are going to read the content, the answer is about structure, freshness, permissions, and whether you can see why a given passage was retrieved.