Knowledge Base Software: How to Choose One That People Actually Use

Knowledge base software is a system for writing, organizing, searching and publishing articles that answer questions people ask repeatedly. It replaces the pattern where the same explanation gets typed out again in a ticket, a Slack thread or an onboarding call. Two distinct products share the name: an external knowledge base (a public help center your customers search before they open a ticket) and an internal knowledge base (a private wiki where employees look up policies, runbooks and how things work). Decide which one you need before you look at a single vendor, because the good tools in each category are almost entirely different.

If you want the short version: for a customer-facing help center attached to a support inbox, use the knowledge base built into your helpdesk (Zendesk Guide, Intercom Articles, Help Scout Docs, Freshdesk). For an internal company wiki, use Confluence, Notion or a purpose-built one like Guru or Slab. For developer or API documentation, use a docs-as-code tool where content lives in Git (Docusaurus, GitBook, Mintlify, ReadMe). Buying outside your category is the most common expensive mistake, and the second is assuming the tool is the hard part. It is not. Maintenance is.

The short answer by situation

External and internal knowledge bases are not the same product

An external knowledge base is a publishing system. It needs SEO-friendly URLs, a custom domain, article versioning, a review workflow so nothing wrong goes public, localisation if you sell internationally, and analytics that tie searches to outcomes. Its job is deflection: someone finds the answer and never files a ticket.

An internal knowledge base is a retrieval system. Nobody browses it. People arrive with a specific question at a specific moment, usually while doing something else. The features that matter are search quality, permissions, freshness signals and the ability to surface content inside the tools where work happens rather than making people open another tab. Guru's whole design premise is that a wiki nobody visits is worth nothing, so cards get pushed into the browser and chat instead.

Tools built for one job do the other badly. A helpdesk KB gives you weak internal permissions. A general wiki gives you a public site with no deflection analytics and usually no clean way to stop an internal page leaking into a public space. If you need both, run both, and accept that a small amount of content will be maintained twice.

What the categories genuinely differ on

Once you are inside the right category, the feature lists converge fast. Every tool has a WYSIWYG editor, categories, tags, search and some form of AI answer layer. The differences that actually change your experience two years in are narrower:

Search quality. Most knowledge base search is keyword matching with basic stemming. That fails on the exact case where a knowledge base earns its keep: the user types their problem in their own words ("card declined again") and the article is titled "Payment authorisation failures". Tools with semantic search or an AI answer layer handle that; tools without it need you to write titles the way customers speak and stuff synonyms into keyword fields.

Authoring friction. If publishing an article takes ten minutes and three approvals, your knowledge base will be permanently out of date. If it takes zero review, it will be full of contradictions. The right setting is one reviewer, a short SLA, and templates so writers do not start from a blank page.

Where content is stored. Markdown in Git can be diffed, reviewed, migrated and grepped. Content in a proprietary block editor is pleasant to write and unpleasant to leave. Check the export format before you commit, not after.

Permissions granularity. Ask specifically whether permissions are per space, per page, or inherited, and what happens when a page moves. This is where wiki migrations go wrong.

Pricing: what the sticker hides

Pricing models matter more than headline numbers, because the model decides what happens when you grow.

• Per agent or per editor. Common in helpdesk-attached knowledge bases. Cheap, because only the support team writes. Readers are free.
• Per member. Standard for internal wikis. Every employee is a seat, so cost scales with headcount, not with knowledge base usage.
• Flat plan with limits. Common in documentation tools: a base plan with caps on projects, versions or languages, and jumps at the boundaries.
• Self-hosted and open source. BookStack, Outline, Wiki.js, Docusaurus. Licence cost is zero, and your cost moves to hosting, upgrades, backups and the person who owns them.

Prices change often enough that any figure written here would be stale within a quarter, so check the vendor's current page. The three line items people forget to budget for: localisation (usually a separate tier), a custom domain with SSL on the lower plans, and the AI answer feature, which is increasingly metered separately from seats.

Why knowledge bases fail, and it is rarely the software

Every failed knowledge base I have seen shares the same three symptoms.

No named owner. "The team" owns it, which means nobody does. Fix: one person owns the structure and the review queue. Contributions come from everyone, accountability does not.

Decay is invisible. An article written in March that became wrong in July looks exactly like a correct article. There is no error message. Fix: give every article a review date and an owner, and treat an overdue review as a real task, not a badge. Tools like Guru enforce this with verification expiry; in Confluence or Notion you build it with a database property and a recurring reminder.

It is written from the inside out. Articles get organised by how the company is structured (by product module, by team) instead of by what the user was trying to do. Fix: name articles after the user's goal and their words. "Why did my invoice change this month" beats "Proration logic".

A useful discipline: export the top 100 search queries every month, and specifically the ones that returned nothing. That list is your writing backlog, and it is better than any brainstorm.

A worked example

A 45-person B2B SaaS company with six support agents. They already run Intercom. The pragmatic build:

1. External: Intercom Articles. Six agents write, customers read free, article suggestions appear inside the messenger. Start with the 25 questions that account for the most tickets, pulled from tags, not memory.
2. Internal: Notion, one space, three top-level areas: how we work, how the product works, how we handle edge cases. Every page has an owner and a review date.
3. Developer docs: Docusaurus in the same repo as the API, so a change to an endpoint and the docs change ship in one pull request.
4. Ownership: the support lead owns external content, an ops person owns internal, engineering owns developer docs.
5. Measurement: monthly review of zero-result searches and ticket volume by tag.

Three systems sounds like too many. It is less work than forcing one tool to do all three, because each stays simple.

What to measure

Be sceptical of vendor "deflection rate" numbers. Most are modelled from sessions that viewed an article and did not open a ticket, which counts people who gave up alongside people you helped.

The answers that never make it into any knowledge base

Even a well-run knowledge base only holds what somebody sat down and wrote. The rest of what a company knows is scattered across the places where the work actually happened: the Slack thread where an edge case was resolved, the support ticket with the real reproduction steps, the CRM note explaining why a customer got a custom rate, the pull request comment that documented a decision nobody formalised. A knowledge base search cannot see any of it, and no amount of tidying the wiki will change that, because the evidence is a sentence in a conversation, not an article.

That gap is a different job from documentation, and it is worth naming so you stop trying to solve it with a wiki. It is a search problem across connected systems: asking a question in plain language and getting an answer assembled from Slack, the helpdesk, email, the CRM and your database, with citations back to the source message or ticket. Skopx connects to nearly 1,000 tools plus direct databases to do exactly that, so the knowledge base can stay what it is good at, the durable written answers, while the situational ones stay findable where they were created. If that is the half of the problem you are actually trying to solve, the platform overview explains how it works.