“Let’s set up a wiki” is usually the first thing a company says when it realises that knowledge lives in people’s heads and in chat threads. A year later the same company complains that nobody can find anything in that wiki, and half of what they find is out of date.
The problem is rarely the tool. “Wiki” and “knowledge base” are two different jobs, and a company picks one while expecting the results of the other. Below I separate the two, show when you need each, and give you structures you can copy.
If you want a quick answer for your own situation, go straight to the free 8-question picker.
The problem is rarely the tool. “Wiki” and “knowledge base” are two different jobs, and a company picks one while expecting the results of the other. Below I separate the two, show when you need each, and give you structures you can copy.
If you want a quick answer for your own situation, go straight to the free 8-question picker.
Wiki vs knowledge base: what is the difference?
Both are places where a company writes down what it knows. The difference is who writes, who reads, and how much the reader can trust what they see.
Confluence, Notion, Microsoft Loop or SharePoint can host either. What you end up with depends on your rules, not on the software.
- A wiki is a shared space where many people create pages and link them to each other. Anyone with access can add or edit. It is built for collaboration: project documentation, meeting results, drafts, team notes. It grows fast and changes fast.
- A knowledge base is a curated collection of answers: policies, procedures, instructions, FAQ. It is organised for finding, not for writing — categories, tags, search, short articles. Every article has someone responsible for it and a date when it was last checked.
Confluence, Notion, Microsoft Loop or SharePoint can host either. What you end up with depends on your rules, not on the software.
Codification or personalization: the strategy behind the choice
In my Knowledge Management course I start with a basic idea: knowledge management is transferring knowledge from those who have it to those who need it. Some of that knowledge is explicit — it is already described. Much of it is tacit — it sits in people’s heads, and they may not even realise they know it. The goal is to make tacit knowledge explicit.
There are two strategies for doing that:
There are two strategies for doing that:
- Codification — knowledge is recorded in company systems where anyone can access it: a wiki, a knowledge base, an intranet.
- Personalization — knowledge stays tied to people, so the goal is to maximise communication between them: workshops, communities, brainstorming, personal meetings, mentoring.
When a company needs a wiki
Choose a wiki for an area of knowledge when most of these are true:
- The people who write it are the same people who read it — one team, one project.
- The content changes every week: decisions, plans, specifications, meeting notes.
- An outdated page costs little, because the reader can ask the author in the next chat message.
- People find things by following links from a page they already know, not by searching.
When a company needs a knowledge base
Choose a knowledge base when most of these are true:
- The readers are not the writers: new hires, other departments, the whole company, support staff answering clients.
- The content is a set of answers: policies, procedures, “how do I…” instructions, onboarding steps.
- An outdated answer is expensive: a wrong process, a security issue, a client getting the wrong information.
- Some sections are confidential and need access levels.
- The same questions keep coming to the same experts.
How to build a knowledge base in 7 steps
This is the workflow from my course. It works whether you start from an existing wiki or from nothing.
- Define the objective. What knowledge exactly, and for what purpose: transferring experience to new employees, solving a specific problem. A SWOT of your current knowledge and interviews with key employees help here.
- Prepare the collection. Choose methods for explicit and tacit knowledge: STAR interviews with experts, surveys with a Likert scale to assess the team’s knowledge level. Create templates for both.
- Collect. Run the interviews (STAR or “5 Whys” for depth), surveys and working groups.
- Structure. Turn unstructured information into organised knowledge: categories and subcategories, tags, FAQ templates.
- Store and give access. Choose the system, build clear categories and assign access rights.
- Protect. Access levels, two-factor authentication, backups, regular checks of who has access, an NDA where needed.
- Review effectiveness. Team feedback, availability and relevance of the content, areas for improvement.
How to structure a knowledge base: examples you can copy
1. The page hierarchy. Main page → categories → subcategories. The main page links to every category with a one-line description. Typical categories:
Policies · Processes · Projects · Training · Frequently Asked Questions
Example subpages under “Guidelines and Instructions”: Training New Employees · Privacy Policy
2. Tags with one naming convention. Tag articles by content (Processes, Training) and by area (HR, IT, Security). Agree on names in advance, otherwise you get “HR”, “People” and “hr-team” for the same thing and search breaks.
3. The index card. For every article, one short card in the catalogue:
3. The index card. For every article, one short card in the catalogue:
Title: Onboarding Process
Brief description: The onboarding stages for new employees, including the first 90 days plan, goals and tasks at each stage.
Link: the document with the full onboarding process.
4. The FAQ entry. Collect the questions people ask most, group them by category (General, Processes, IT), answer briefly and link to the full document:
Question: How do I restore my password?
Answer: Go to the password recovery page, enter your email and follow the instructions.
5. The decision tree. For situations where the answer depends on conditions, write “if… then…” branches instead of a long article:
What training method should we choose for this employee?
If the goal is to learn a new program: basic level — an online course; advanced level — mentoring.
If the goal is better communication skills: immediate need — a training session; can be gradual — coaching sessions.
6. Links into the work itself. A knowledge base that lives apart from daily work gets forgotten. Put links to articles inside your standard operating procedures and inside the tasks where the knowledge is needed. If you are writing procedures from scratch, start with my HR SOP template and guide.
At Wargaming, iDeals and Preply we used Confluence. In essence, Confluence or Notion is a corporate Wikipedia with very advanced features: simultaneous editing, version control, access rights, personal spaces, internal cross-links. For remote employees this matters even more. In an office, when someone leaves, they hand over files; when someone joins, a colleague talks to them. When people work remotely, that handover works much worse, because they do not see each other. So you have to give people the tool and build the habit of recording knowledge in it. At Wargaming that habit started on day one: in the first days, new employees were trained to use Confluence and Jira, because the whole company worked in them. For the rest of the first weeks, see structured onboarding.
Who maintains a knowledge base: owners and roles
A wiki can live without owners for a while. A knowledge base cannot. In my course I assign roles for knowledge with a RACI matrix; here is the core of it:
- Creating materials (instructions, checklists): the subject matter expert is responsible, the process manager approves.
- Verifying relevance: the process manager is responsible, the department head approves, the expert is consulted.
- Adding to the knowledge base and updating it: the knowledge management specialist is responsible.
- Gathering feedback: the knowledge management specialist, with team members consulted and informed.
How to measure whether your knowledge base works
These are the metrics from my course that I would start with:
- Usage rate = active users per month ÷ all employees.
- Relevance percentage = materials whose relevance was confirmed in the last six months ÷ all materials.
- Engagement index = employees who made changes ÷ all employees.
- Time to find information — a survey question with four answers: a few seconds, about a minute, up to five minutes, more than five minutes.
- Recommendation score — “How likely are you to recommend the knowledge base to new employees as a source of useful information?” on a 1–10 scale.
Five mistakes companies make with wikis and knowledge bases
- Calling a wiki a knowledge base. Open editing, no owners, no review dates — and then everyone is surprised that new hires do not trust it.
- Waiting for experts to write. They are busy with current work. Interview them and write the article yourself.
- No visible relevance date. A reader cannot tell whether a page is current. Show when it was last confirmed.
- Everything open to everyone. Confidential sections need access levels and a need-to-know rule; people who left need their access removed.
- Never deleting anything. Outdated pages compete with current ones in search. Remove or archive them during the six-month review.
The quick rule: keep a wiki for the work in progress, publish a knowledge base for the answers people depend on, and give every published answer an owner and a date. The full system — from capturing tacit knowledge to a knowledge strategy — is in my Knowledge Management Course: KM Training for Business.
