Docs and knowledge base

What this category covers

Places to write things down so other people can find them: customer-facing help centres, internal handbooks, developer documentation and the search that makes any of it useful.

The distinction that matters is audience. Documentation for customers needs a public address, a review process, and language written for someone who is already stuck. Documentation for staff can be messier and needs permissions instead.

Personal and small-team knowledge belongs in notes and wiki. The ticket queue where unanswered questions arrive is customer support.

Structure decides whether anything gets found

Every documentation project starts organised and ends as a pile. The tooling either slows that down or accelerates it.

Look at how hierarchy works: categories, sub-pages, cross-links and whether a page can sit in two places without being duplicated. Then look at what happens at three hundred pages, which is where navigation designed for thirty collapses.

Search is the honest test. Try a query using the words a customer would use rather than your internal vocabulary. Products that only match titles will fail that test, and readers will end up in your support queue instead.

Tags and related-article suggestions help when they are maintained. Nobody maintains them by hand for long, so prefer products that generate connections from content.

Writing, review and keeping pages true

Documentation rots quietly. A page that was correct in March is a support ticket in September, and nothing about it looks wrong.

Useful products carry ownership, review dates, and a last-checked stamp the reader can see. Draft states and review workflow matter once more than two people write, and version history matters the first time someone asks what a page said before it changed.

Reuse is worth checking too. A limit, a price or a supported-versions list should exist once and be included everywhere it appears, rather than pasted into eleven pages that will disagree by next quarter.

Publishing and the search question

A public help centre is a website, and it should behave like one.

• Clean URLs that survive reorganisation, with redirects when they cannot.
• Editable titles and descriptions per article, not generated from the first line.
• Fast pages without a heavy application loading before the text appears.
• Sitemaps that update when you publish rather than on a schedule nobody remembers.
• A custom domain, so the material builds authority for your own site instead of the vendor’s.

That last point is worth arguing for internally. Documentation is often the best-performing content a software company has, and hosting it on a vendor subdomain gives that traffic away.

Measurement, and the only metric that matters

Page views tell you almost nothing. Two numbers tell you a lot.

The first is searches that returned no useful result, which is a written list of what to create next. The second is whether readers who opened an article still contacted support afterwards, which requires connecting the help centre to your ticket system.

Rewrite from that list rather than from opinion. The five articles that fail most often are worth more attention than fifty that nobody visits.

How these products are priced

Seats for authors, sometimes free reading for everyone, sometimes per registered internal reader. Public help centres usually charge by author and by article volume, internal wikis by user.

Watch three boundaries. Custom domains, versioning, and single sign-on each tend to sit one tier above the entry plan. Analytics depth is a fourth. Vendors that bundle a help centre with a support product often price it as an add-on rather than including it, which is one of the habits collected in what pricing pages hide.

Before committing, export everything and read the output. Markdown or clean markup means you can leave. A proprietary format means the archive is hostage.

Starting a help centre from nothing

The first version should be embarrassingly small.

Take the twenty questions your support queue receives most often and answer them properly. That covers the majority of contacts and takes a week, whereas planning a complete structure first takes a quarter and answers nothing in the meantime.

Write each article for somebody who is already stuck, which means the answer first and the explanation afterwards. Screenshots age badly, so use them where they genuinely help and expect to replace them.

Then let the structure emerge. After thirty articles the categories become obvious, and imposing them at article five means reorganising anyway.

Publish the search terms that returned nothing as your writing queue. It is the only content plan in this category that never runs out and never guesses wrong.