Knowledge base software: what to buy, and what to write first

Knowledge base software gets bought at a predictable moment: the third time the same question arrives, or the week after somebody left with a process in their head. The purchase is the easy part. Six months later most knowledge bases are half-true, and people have gone back to asking in chat — which is faster than reading something they no longer trust.

So the useful question is not which tool. It is what makes a knowledge base stay accurate, and which features actually support that.

Internal or customer-facing — decide first

These are different products with different requirements, and trying to serve both from one space is where many knowledge bases become unusable.

• An internal knowledge base carries how things are done here: processes, decisions, runbooks, the reasoning behind choices. It needs permissions, search that works on internal jargon, and an owner per area.
• A customer-facing help centre carries how to use the product: tasks, troubleshooting, answers. It needs public hosting, clean URLs, search that matches the words customers use, and structured markup so search engines and assistants can quote it.
• The overlap is smaller than it looks. Internal notes written for colleagues read as evasive when published; help articles written for customers omit the reasoning colleagues need.

The feature that decides whether a knowledge base survives is not search or design. It is a visible owner and a review date on every article. Without those, nobody knows whether a page is current, and an article people do not trust is worse than no article at all.

What to compare in knowledge base software

• Search quality on your content, tested with the words your people actually type — not the demo dataset.
• Structure: categories that hold, plus the ability to link between articles without hunting for URLs.
• Version history, so you can see what a process said before it changed, and restore it.
• Permissions per space or article, if any of it is confidential.
• Review workflow: an owner field, a review date, and a way to list everything overdue.
• Export in a portable format. Knowledge outlives tools, and a knowledge base you cannot export is a hostage.
• For public help centres: custom domain, sitemap, meta control and structured data — otherwise your best answers are invisible to search.

What to write first

1. Log the questions actually asked over two weeks — in support, in chat, at handover. That list is your table of contents, and it beats any content plan invented in advance.
2. Write the five most repeated answers, each as a task with steps, not as an essay.
3. Add the three processes that only one person knows. These are the expensive ones, and they are usually undocumented precisely because they live in somebody's head.
4. Give every article an owner and a review date before publishing it. An unowned article decays silently.
5. Link from where the question arises — the support macro, the onboarding checklist — rather than hoping people browse.
6. Review monthly against the new question log: what got asked that the base did not answer, and what answers changed.

In Ettex, the internal half of this runs on Write and Storage: rich documents with headings, tables and images, reusable styles, an outline view for navigating long processes, comments and @mentions for review, version history that shows what a process said before it changed and restores any state, and export to DOCX, PDF, ODT or Markdown so the content is never trapped. Storage indexes everything in one searchable list regardless of which app made it, documents start private and are shared deliberately at Editor, Commenter or Viewer level. For a public help centre, Ettex Sites publishes to your own domain with SEO fields and an auto-generated sitemap.

Why knowledge bases rot

• No owner, so nobody is responsible when a process changes.
• Articles written as narrative history rather than as instructions for the next person.
• Duplicates: the same process documented twice, diverging quietly.
• Publishing everything at once — a hundred stale articles teaches people the base is unreliable.
• Search that fails on the first attempt. People give up after one bad search and go back to asking.

Choose knowledge base software on search, versioning and export — then spend the real effort on the question log, the owners and the review dates. That is what keeps people reading it in month six.