Internal knowledge bases: how to keep one people actually use

Someone asks where the expenses policy is, three people give three different answers, and two of them are wrong. Sound familiar? That's not a technology problem, it's a habits problem, and it's the main reason internal knowledge bases end up ignored.

Everyone's had this experience. You go looking for how to book leave, or what the actual current IT access process is, and you find four pages, two of which are clearly old, one of which contradicts the other, and none of which say who wrote it or when. So you give up and message a colleague instead. Which, fair enough, is faster. But it also means the knowledge base has quietly failed at the one job it had.

What an internal knowledge base is

An internal knowledge base is where staff go to find out how things work here: policies, processes, how-to guides, who to contact, templates, that sort of thing. It's just the internal record of "this is how we do things," nothing customer facing about it. Shared drive, wiki, intranet, call the platform whatever you like, doesn't matter much. What matters is whether people trust what's on it.

And that's the bit that tends to slip.

Why company wikis go stale

Wikis rot because anyone can add a page but nobody's actually responsible for keeping it right. There's no review date on most pages, so a document written years ago sits there looking exactly as current as one written last week. Nothing distinguishes them. You've probably got two or three versions of the same policy floating around too, with no obvious sign of which one is the real one.

Add to that all the pages written for a single project, once, and then never touched again after the project ended, and you've got a graveyard dressed up as a library.

Here's the thing though: the damage isn't really about one wrong page. It's what happens after. The first time someone follows the wiki and gets a wrong answer, they stop trusting it. Not just that page, the whole system. After that, they ask a colleague instead, every time, forever. Trust doesn't come back easily once it's gone.

Give every page an owner

So the fix starts with ownership. Every page, or every section really, needs a named owner, and I'd make that a role rather than a person, because people leave and roles don't. "Head of Ops" survives a resignation. "Dave" does not.

The owner's job is simple: they're the one who answers "is this still right?" Not everyone. Not "whoever notices." One person, or one role, accountable for that page being accurate. It sounds obvious written down like that. It's rarely how these things actually work in practice.

Review dates and "last reviewed"

Set a review date the moment you publish something, not months later when someone finally notices it's gone stale. Shorter cycles for things that change often, expenses, IT access, rotas, that kind of thing. Longer cycles for stuff that barely moves.

Show the "last reviewed" date and the owner at the top of the page. Always. If a review gets missed, flag it, don't just let it sit there quietly pretending to be current. ACAS spells this out well for policies specifically: "You should regularly review your policy." It suggests deciding when or how often that happens, who is involved, what the review considers, what the outcomes might be and how changes are communicated. That's not complicated advice. It's just advice almost nobody follows properly.

Make it obvious which version counts

One source of truth per topic. That's the rule. If there are older versions floating around, archive them or label them clearly as superseded, don't just leave them sitting next to the current one with no distinction.

And link to the approved document rather than copying its text into five other pages. I know copying feels faster in the moment. But then the original changes and now you've got six versions to update instead of one, and five of them will get forgotten. Drafts should look like drafts too, obviously in progress, not indistinguishable from a finished, approved page.

Who can see what

Not every page is for everyone. Managers-only guidance, one specific team's local process, confidential HR material, these all need proper visibility decisions, not just "it's on the wiki so it's fine." Decide who sees each section before you publish it, not after someone stumbles onto something they shouldn't have.

Turn repeated questions into pages

If the same question lands in someone's inbox three times, that answer belongs in the knowledge base. Not as a favour someone does when they've got a spare hour, but as an actual job the page owner is expected to do. Repeated questions are basically free market research telling you exactly what's missing.

Measure what people could not find

Track the searches that came up empty, and the ones where someone clearly landed on the wrong page. That list is your to-do list, really, it's telling you precisely what to fix next. Worth also keeping an eye on pages nobody ever opens. Either they're not needed, or people don't know they exist, and either way that's useful to know.

Handbook, knowledge base, or an assistant that answers from it

The handbook and the knowledge base aren't the same thing (our guide to employee handbooks and UK law covers what has to be in writing), though people often treat them as interchangeable. The handbook is the curated, approved set of policies and terms, often the thing new starters get before their first day (ACAS lists "a staff handbook, if there is one" among the things to send new workers before they start). It's narrow, formal, and it doesn't change often.

The knowledge base is wider and moves faster: processes, how-tos, local quirks, the stuff that shifts as the business does. The handbook should sit inside it as one clearly marked, authoritative section, not compete against it as a second copy of similar information.

If you've got an assistant answering questions from the knowledge base, that's fine, genuinely useful even, but it can only ever be as good as what's underneath it. It needs the same basics as everything else: approved sources only, proper respect for visibility permissions, answers that point back to the actual document rather than just paraphrasing confidently, and an honest "I don't know" when it doesn't know, logged as a gap rather than papered over with a guess.

What to look for in a tool

Look for ownership fields, review reminders, version history, decent permissions, good search, and visibility into failed searches. That's genuinely most of it. Easy editing matters more than a long feature list, because if updating a page is a pain, people simply won't do it, and you're back to square one with a wiki full of stale pages nobody trusts.

Where to start

Don't try to fix everything at once. Find the pages behind your most-asked questions, give them owners, give them review dates, and get those right first. Then grow outward from there.

It's not glamorous work. But it's the difference between a knowledge base people actually use and one they quietly route around.