Building a Knowledge Base for Employees That People Actually Open

TL;DR

• A knowledge base for employees fails on adoption far more often than on content, and adoption is mostly about friction rather than quality.
• Write the twenty questions people actually ask before writing anything else. Most teams guess, and the guesses are wrong in predictable ways.
• Lead every article with the answer. Purpose and scope sections are why people stop reading.
• Title documents with the words employees use, not the formal policy name.
• Measure questions to HR, not page views. Page views spike at launch and tell you nothing.
• If people find the page and still ask, the problem is interpretation rather than location, and no restructure fixes it.

The Launch That Looked Like Success

Page views on the first day were excellent. Nearly two thirds of the company opened the new knowledge base, which seemed like strong validation for eleven weeks of work.

Week two was about a fifth of that. Week four was a handful of people, mostly the ones who had built it. By week eight the traffic was almost entirely new joiners, who had been told about it during onboarding and were the only people with a reason to look.

Questions to HR had not moved at all.

Recommended Tools

Best tools for HR Operations

B BambooHR HR management system R Rippling HR & IT automation W Workday Enterprise HRIS

View all recommended tools

The content was good. People had genuinely opened it. They had simply not found a reason to come back, because the first visit had not answered anything they urgently needed, and the second time they had a question it was quicker to ask.

The real issue is not that nobody opened it. It is that a launch spike is the easiest number to get and the least informative one, and most knowledge base projects are judged on it.

Start With the Questions, Not the Documents

The single highest-return decision, and almost nobody makes it.

Ask whoever answers employee questions for a month of them. Not categories. The actual questions, in the words people used.

Count the repeats. Twenty questions usually account for a very large share of the volume, and they are rarely the twenty somebody would have guessed.

Write those twenty first. Before the handbook, before the structure, before anything that feels like a proper project.

And write them as answers to those questions. Not as policies that happen to contain the answer. The title should be the question and the first line should be the answer.

What to do: spend the first week collecting rather than writing. Teams that skip this step build a well-organised library of the things they thought mattered, which is the opening story.

There is a reason the guesses go wrong in a consistent direction. The people planning a knowledge base are the people who already know the answers, so the questions that feel important are the structurally interesting ones: how the performance cycle works, what the values are, how progression is decided. The questions that actually arrive are smaller and more immediate, about this week's payslip or next month's leave, and they feel too trivial to build a project around. That mismatch is predictable enough to plan for, and collecting a month of real questions is the only reliable correction for it.

Why People Do Not Come Back

Four reasons, and only one is about content quality.

The first visit did not answer anything. If somebody arrives with a question and leaves without an answer, they have learned that the tool does not work, and that belief is durable.

Asking a person is faster. One step against four. People optimise for this consistently and no amount of encouragement changes it.

They do not trust it to be current. If a page has no date, readers assume it might be stale, and the assumption is usually correct.

They cannot find the right page. Searching requires knowing what the document is called, which requires knowing how somebody else decided to name it.

What to do: fix the fourth by titling with the search term rather than the formal name. It is the cheapest of the four and it has an immediate effect.

The first reason is worth dwelling on, because it is the one that compounds. A person who searches, fails, and asks a colleague has not simply had one bad experience; they have formed a working belief that this tool does not answer questions. That belief is cheap to create and expensive to reverse, and it transfers to any replacement you buy later, because from the reader's side a new knowledge base looks exactly like the old one. Protecting the first visit therefore matters more than almost anything else in the project, which is the argument for publishing the twenty most-asked questions before anything else rather than launching with a complete but less useful library.

Write the Answer First

The structural change that matters most in a knowledge base for employees, and the one most policy writing gets backwards.

Most policies open with purpose and scope. By the time the entitlement appears the reader has skimmed past it or left.

Put the specific answer in the first line. How many days, what the limit is, who approves it. Then the conditions, then the background for anybody who needs it.

Write the number rather than the principle. "Reasonable" produces a question. A stated figure does not. Every vague threshold is a question somebody will ask a human.

Name the approver for exceptions. Most questions are about edge cases, and a policy that says who decides them deflects more volume than one that only states the rule.

What to do: take your five most-asked-about documents and rewrite only their opening paragraphs. It takes an afternoon and it measurably reduces repeat questions without touching anything else.

Title It the Way People Search

A small thing with a disproportionate effect on whether anything gets found.

Use the words employees use. "Working from home" rather than "Flexible Working Arrangements Framework". The formal name can be a subtitle.

One document per question. A single page covering leave, sickness, parental leave and sabbaticals answers four questions badly and is findable by none of them.

Avoid internal jargon in titles. Scheme names, system names and acronyms are invisible to anybody who does not already know them, which is precisely the person searching.

And include the synonyms in the body. If people say holiday and the policy says annual leave, both words need to appear somewhere on the page.

What to do: search your own knowledge base using the exact phrases from your list of twenty questions. Anything that does not surface the right document on the first result is a titling problem, not a content problem, and retitling is an hour of work where restructuring is a week of it.

What to Write, in Order

A sequence that produces something usable in weeks rather than months.

The twenty most-asked questions. Each as its own short document, titled as the question.

Then the things new joiners need in week one. Equipment, access, who to ask, how to book leave, where things are.

Then the policies that carry obligations. Code of conduct, expenses, disciplinary and grievance. These matter and they are not what people search for daily.

Then everything else, slowly. Most libraries never need to be complete, and the pursuit of completeness is what makes these projects take eleven weeks before anybody can use them.

What to do: publish after the first twenty rather than waiting for the full set. A partial library that answers the common questions beats a complete one that arrives three months later, and publishing early gives you something the complete version never will, which is real feedback about what is missing rather than a theory about it.

Structure It Shallowly

Deep hierarchies feel organised and work against the reader.

Most people search rather than browse. Structure is mostly for maintainers, and optimising it is one of the most common forms of visible non-progress.

Two levels is usually enough. A category and a document. Three levels means somebody has to guess twice.

Group by question type, not by department. "Time off", "Pay and expenses", "Working here" reflect how people think. "People Operations" and "Reward" reflect your org chart, which readers neither know nor care about.

And put the twenty most-asked somewhere obvious. A front page listing them answers most visits without anybody searching at all.

What to do: resist the urge to rebuild the category tree when things feel disorganised. It is satisfying, visible and almost never the reason people cannot find things. If the library genuinely feels chaotic, the usual cause is duplicates rather than structure, and searching your ten most important document names to confirm exactly one live page comes back for each will tell you that in twenty minutes.

Make It Obviously Current

The thing that decides whether people keep trusting it after month three.

Put a last-reviewed date on every page, visible to readers rather than in a revision history. It lets people judge for themselves, which is what stops the slow collapse of confidence.

Put an owner's name beside it. A reader who spots an error and knows who to tell turns the whole workforce into a detection mechanism.

Stamp pages even when nothing changed. "Reviewed October 2026, no changes" is useful information and it is what makes a library trustworthy over time.

And review on a cadence. The things people ask about most, quarterly. Everything else, annually. We covered the mechanics in HR knowledge management.

What to do: add dates and owners before you add more content. A smaller library people trust is worth more than a larger one they do not.

The Twenty Questions, in Practice

What the list usually looks like, since teams ask what to expect before collecting their own.

Time off dominates. How much leave is left, carry-over rules, how to book it, what happens to unused days, sickness during leave. This cluster is reliably the largest single category.

Pay and expenses is second. When payday falls, how to claim something, what the limits are, who approves, what happens when a claim is late.

Working arrangements is third. Hours, remote working, where the policy actually permits working from, what notice is needed to change a pattern.

Then a long tail that is specific to you. Equipment, parental leave, probation, references, the particular quirk of your benefits provider. This part is unpredictable and it is why collecting your own list matters.

What surprises most teams is how few questions are about the things they spent longest writing. Codes of conduct and grievance procedures are important and rarely asked about, while carry-over leave is asked about constantly and is usually one paragraph buried in a longer document.

What to do: expect the top five to account for a large share of volume and write those properly before anything else. Depth on the common questions beats breadth across the library, at least until the common ones are genuinely handled.

Where It Should Live

The housing question, which matters less than most evaluations assume.

Wherever the company already works. Confluence if you run on Atlassian, Notion if you run on Notion. Habit beats quality for adoption, reliably.

Somewhere readable without a seat if you have deskless staff. If a third of your people have no account, the library is unreachable for them regardless of how good it is.

Not in two places. The most damaging arrangement is the same policy in two homes with different dates, which happens whenever one function migrates alone.

And where answers can reach people. A library that only exists as a destination competes with asking a colleague, and loses.

What to do: pick the tool the company already pays for unless a specific requirement forces otherwise. The effort saved belongs in the content, which is the part that determines whether any of this works and the part that nobody has budget enthusiasm for.

What the Tools Cost

Published figures, read from each vendor's own page in October 2026, because several in this category no longer publish.

Helpjuice prices by included users: 249 per month including 30 users, 449 including 100, 799 for unlimited. Its page shows no currency symbol anywhere.

Slab is free to 10 users, then $6.67 Startup and $12.50 Business per user per month, both billed annually.

Tettra is $8 per user per month on Scaling with a ten user minimum, billed yearly.

Notion is free, then $10 Plus and $20 Business per member per month.

Confluence is a configurator: $7.15 Standard per user per month at 25 seats, falling to $5.78 at 300. Free to 10 users permanently.

Guru and Document360 publish nothing as of October 2026, and both stopped this year.

What to do: price at your twelve-month headcount, counting readers. A knowledge base for employees is read by everybody and written by a few, so per-seat pricing multiplies against your whole company.

A Knowledge Base for Employees, Week by Week

A sequence that produces something usable quickly, rather than a project that surfaces after three months.

Note what is not in there. No category restructure, no migration, no tool evaluation. None of those is on the critical path to something people will use.

And note that it publishes in week four. A partial library in use beats a complete one in draft, because the first produces feedback and the second produces assumptions.

What to do: commit to publishing at week four regardless of how incomplete it feels. The instinct to wait until it is finished is the single most reliable way for these projects to take a quarter.

Where a Knowledge Base for Employees Differs From Documentation

Worth separating, because most published advice in this area is written for software documentation and does not transfer cleanly.

The audience has no expertise and no patience. Engineering documentation is read by people who expect to work for the answer. A handbook is read by somebody with a question and thirty seconds.

Nobody reads it twice. Documentation is a reference people return to. Most employees open a given policy once, if ever, which means the first encounter has to work.

It changes because of decisions elsewhere. A travel policy changes in a leadership meeting rather than through a documentation workflow, so nothing in the tool triggers an update.

And the cost of being wrong is personal. A wrong runbook causes an outage. A wrong leave policy causes somebody to take the wrong amount of leave, which becomes a conversation about trust.

What to do: apply the structure advice from documentation sparingly. Shallow hierarchies, answer-first writing and visible dates matter far more here than the taxonomy and cross-referencing that documentation practice emphasises.

The published guidance from tool vendors is worth reading with that difference in mind. Slab's own writing on internal documentation is typical of the genre: good advice, written largely for teams documenting how software works rather than for a People team answering the same five questions every week.

The Measure That Matters

One number, and it is not the one most projects report.

Count questions to HR that the library already answers. Before you launch, at three months, and at twelve.

Page views are not a substitute. They spike on announcement and settle, and the spike is routinely mistaken for adoption.

Tag the repeats. If the same question keeps arriving after launch, that specific document is failing, which is far more actionable than an overall engagement figure.

And watch the trend rather than the level. Volume varies with hiring and with the calendar. The direction over months is the signal.

What to do: get the before-number this month, whatever else you do. A project with no baseline cannot be shown to have worked, which is how these quietly become things nobody mentions.

Handling the Awkward Content

Four categories that sit badly in a general knowledge base for employees and need a decision rather than a default.

Pay bands and compensation structure. Frequently needs to be visible to managers and not to everybody, which is a permissions question that lighter tools express awkwardly. Decide before you publish rather than after somebody sees something they should not have.

Anything with legal weight. Disciplinary and grievance procedures need to be current, provable and version-controlled in a way that general tools handle loosely. If you cannot produce the version live on a given date, treat that as a gap.

Local variations. Multi-entity or multi-country companies end up with a core policy and local differences. Writing one page that quietly describes one country's practice is actively misleading everywhere else, so say which parts are universal.

Things that are practice rather than policy. How expenses actually get approved in practice may differ from what the policy says. Documenting the real process is usually right and occasionally creates a problem, which is a conversation to have deliberately.

What to do: list these four before publishing and decide each one explicitly. They are where knowledge base projects create exposure rather than reduce it, and the decisions are cheap in advance and expensive afterwards.

When the Problem Is Not the Library

The most common finding once the content is good, and the one that surprises teams.

People find the page and still ask. The document contains the answer, it is current, and the reader still messages a colleague. That is interpretation rather than location.

Because a document is not an answer. A leave policy with conditions and exceptions requires reading and deciding. Asking a person gets a sentence that applies to you specifically.

An answering layer addresses it without a migration. It reads the documents where they already are and returns a sentence with a link to the source.

Matram is one of these, and it is owned by the same people who publish this site, which you should weigh against this section. It publishes flat pricing at $29, $69 and $199 per month with unlimited seats, which matters here because the reader population is the whole company.

Its limits are specific. There is no free tier, only a 30 day trial without a card. It answers rather than actioning tickets, so it states the policy and does not process the request. And it is not an ITSM or HR workflow platform, with no case management or approvals.

It does not fix bad content. An answering layer over a stale library delivers wrong answers faster and more confidently, which is worse than a library nobody opens.

What to do: only consider this once the twenty questions are written and current. Order matters more than choice here.

The Decision Table

Keeping It Alive After Month Three

Every knowledge base for employees is good on launch day. The question is what it looks like after a year, and that is decided by four habits.

One named owner per document, visible to readers. Not a team. A document owned by a team is owned by nobody, and the failure is silent because staleness produces no alert.

A review cadence split by volatility. The things people ask about most, leave, expenses, benefits, hours and notice, get a quarterly look. Everything else is fine annually.

A trigger habit for decisions. Anything that changes a rule gets written down the same week it was decided. This is the hardest of the four because it depends on HR hearing about decisions made elsewhere.

And permission to delete. A library that only grows becomes unusable. Archiving superseded versions is the most useful maintenance task and the one people are most reluctant to do.

What to do: put the quarterly review in a recurring calendar entry with the owner's name on it. An intention to review is not a mechanism; an interruption is, and the difference is the entire gap between a library people trust and one they do not.

Two Things That Feel Like Progress

Both visible, both satisfying, and neither moves the number that matters.

Reorganising the structure. Rebuilding the category tree is highly visible work that does almost nothing for somebody who searches rather than browses, which is nearly everybody. If search is how people arrive, structure serves the maintainer.

Adding more content. A library nobody trusts does not become trustworthy by growing. Writing twelve new policies while the existing forty have no owner makes the problem larger, and it is tempting precisely because writing feels like the job.

What both have in common is that HR can do them alone. The things that actually help, naming owners outside HR and getting told when decisions change rules, require other people to agree to something, which is why they get deferred indefinitely.

What to do: before starting either, say which number you expect it to move. If the answer is not questions to HR about documented things, it is tidying rather than progress, and tidying is fine as long as nobody mistakes it for the project.

Six Mistakes Worth Avoiding

All common, all avoidable, and the first two account for most failures.

Writing the handbook before the questions. Produces a complete library of what somebody assumed mattered.

Judging it on launch traffic. The easiest number to get and the least informative.

Formal titles. Invisible to anybody searching in ordinary words.

Deep hierarchies. Satisfying to build, irrelevant to people who search.

No dates. Readers assume stale, usually correctly, and stop checking.

Announcing once. A single message in a channel produces a spike and a reversion. Three times over three weeks, in the places people already look, works considerably better.

What to do: check your plan against these six before starting. Each takes minutes to avoid at the beginning and months to correct afterwards.

Getting New Joiners to Use It

The one group who will reliably adopt a knowledge base for employees, and the opportunity most teams waste.

They have no habit yet. Existing staff have two years of asking a colleague behind them. A new joiner has nothing, which makes week one the only moment when a new habit is cheap to form.

So make it the answer to everything in onboarding. Not a tour of the library. Every question a new joiner asks in week one gets answered with a link, even when telling them directly would be faster.

Build the new-joiner page deliberately. The ten things everybody needs in week one, on one page, linked from the offer letter and the first-day message.

And ask them what was missing. New joiners are the only people who will tell you honestly, because they have no investment in the existing content and they encountered the gaps yesterday.

What to do: add one question to every thirty-day check-in: what did you have to ask somebody that you could not find. Six months of that is the best content backlog you will ever have, and it costs nothing to collect.

Writing for People Who Will Not Read

Practical techniques, since the realistic assumption is skimming rather than reading.

Front-load specifics. The number, the limit, the deadline. If somebody reads one line, that line should be the one they needed.

Use headings as answers, not labels. "How much carry-over leave can I take" works. "Carry-over" does not, because it only makes sense to somebody who already knows the rule exists.

Keep paragraphs short and concrete. A policy is not an essay. Three sentences per idea is plenty.

Put edge cases in their own section. Most readers need the normal case. The people with an edge case will look for it, and mixing the two makes the common path harder to see.

And link rather than repeat. If the expenses policy and the travel policy both touch per-night limits, one of them owns it and the other links. Repeating guarantees they will diverge.

What to do: have somebody outside HR read your five most-asked documents and tell you what the answer is. If they cannot say in ten seconds, the writing is the problem rather than the tool.

What Getting This Wrong Costs

The visible cost is eleven weeks of work that changes nothing, which is the opening story.

The larger cost is the belief that forms afterwards. Once people have tried a knowledge base twice and got nothing useful, they stop trying, and that belief outlives any amount of subsequent improvement. You can fix every document and still have a workforce that asks a colleague first, because nothing announces that the library has become reliable. Rebuilding trust takes considerably longer than building the library did.

The second cost is organisational. A knowledge project that visibly failed makes the next one harder to fund, regardless of whether the second diagnosis is better. The conclusion drawn is usually that this sort of thing does not work here rather than that the approach was wrong, and the next person to raise it inherits that.

And the third is the HR team's own time, which is the largest and least counted. Being the search index for a company is low-value work that fills a day and displaces the work people joined to do. Four hours a week of a People Partner answering documented questions is roughly a tenth of a role, and the effect is not only the hours. An inbox of small urgent questions crowds out everything slower that has no deadline attached.

There is a fourth cost that is specific to doing this badly rather than not doing it. A library that exists and is wrong is more damaging than no library, because people act on it. Somebody reads an old notice period and plans around it. A manager quotes a superseded expenses limit to their team. These do not arrive as incidents; they arrive as small inconsistencies that quietly erode confidence in HR rather than in the document, and nobody traces them back to a page that was published once and never reviewed. The decision to build one is therefore also a decision to maintain one, and a team that cannot commit to the second should think carefully about the first.

So the question is not what to put in a knowledge base for employees. It is which twenty questions arrive most often, whether the answers are the first thing on the page, and whether anybody will still trust it in a year.

When You're Ready to Build It

Collect a month of real questions before writing anything. The list will not match what you expected, and that gap is the whole value of the exercise.

Write the top twenty as individual documents, titled as the question, with the answer in the first line. Publish those rather than waiting for a complete library, because a partial one that answers common questions beats a complete one three months later.

And record the before-number on questions to HR this month. Without it you will be judging the project on launch traffic, which is the one number guaranteed to look good and mean nothing.

A final note on sequence, because it determines how much of the effort survives. Questions first, so you know what to write. Writing second, answer-first and titled the way people search. Dates and owners third, so the library stays trustworthy. Publishing fourth, before it feels finished. Tooling last and smallest, because every option in this category hosts a well-written, well-owned library adequately and none of them rescues a neglected one. Most teams run this in reverse, starting with a tool evaluation, and the reason these projects so often disappoint is that the tool was never the part that was broken.

Frequently Asked Questions