Nearly every company under 50 people has its own Peter. Peter knows why client X gets an 8% discount instead of 5%. Peter knows the printer on the shop floor needs a manual reset after every toner change. Peter knows which Excel file holds the latest price list for retailer Y. When Peter takes a two-week holiday, the numbers wobble. When Peter leaves, some processes just go dark.
A knowledge base is not about the tool. It's not about Notion, Confluence or SharePoint. It's about the fact that the knowledge your operation depends on has stopped living inside one head. It's mostly human work and mostly boring — which is why most companies don't do it until it hurts.
At one of our clients — an 18-person metalworking shop — one of two salespeople resigned with a week's notice. For 3 weeks, orders from roughly 40% of clients were stuck, because individual discounts and "commercial arrangements" existed only in his inbox and his head, not in the ERP. Four months later we rolled out a modest knowledge base in Notion — 62 pages describing clients, terms and exceptions. When the second salesperson left the following year, onboarding a replacement took 3 working days instead of 3 weeks. That's the whole economics of a knowledge base in one number.
Start with what stalls the company, not with structure
Don't start by building "the company wiki" as a project. That's the road to a catalogue of empty templates. Start with a question: what happens if this specific person doesn't come to work tomorrow?
Make the list on paper. Peter — chain-retail customers. Anna — POs to the Asian supplier. Mark — everything Comarch Optima and accounting. Chris — router config across two branches. Each entry is a potential hole. Sort them along two axes: how often is it needed and how expensive is the missing knowledge when it is.
You tackle the top-right corner first — frequent and expensive. The rest waits. A knowledge base built "most important first" has a chance of staying alive. A knowledge base built "A to Z" dies at letter D.
- List people and what only runs because of them.
- Mark the ones where replaceability is near zero.
- Pick the 10 most painful items and write only about those in the first month.
- Don't try to describe the entire company. That's the trap.
Pick the tool last, not first
Companies love to start by comparing Notion, Confluence, SharePoint, Guru and BookStack. It's procrastination dressed up as a project. Picking a tool will eventually take you a week. Gathering content will take months. Start with content, even in a folder of Word files on the shared drive if you must.
Once you have 20–30 pages of content, the tool choice becomes obvious. Then you'll actually see what you need: full-text search, version history, per-department permissions, Microsoft 365 integration, comments. Without content, those are abstractions.
The practical choice for a 10–50-person company usually boils down to three: SharePoint / OneNote if you already run Microsoft 365 and want zero extra spend; Notion if you value editing simplicity and can accept permission limits; Confluence if IT or engineering already lives there. All three work. None is magic.
Who writes and when — without this, nothing gets written
The biggest mistake is announcing "starting today, everyone documents". They won't. Documentation loses to every urgent email.
Three rules that work in practice:
Rule 1: write during, not after. When Peter resolves an unusual customer problem, he writes a note right after — not "when he has time". He won't. 15 minutes right after the event produces a page that will save his replacement six months from now.
Rule 2: writing is done by the person who knows, not by someone delegated to document. "The assistant will take notes from Peter" doesn't work. Peter knows nuances he can't hand over in an interview. Instead — Peter writes 20 minutes of raw text, someone else edits and gives it structure. Split the work: knowledge from the person, form from someone with the time.
Rule 3: documentation is part of the job, not an add-on. Add "create a knowledge base note" as a step in the client onboarding procedure. Add "describe the resolution" to the incident checklist. If it isn't in the process, it won't happen in practice.
Maintenance — without it, the base becomes a museum
A knowledge base nobody updates becomes more harmful than no knowledge base within a year. People find an outdated instruction, follow it, lose an hour on something that's been done differently for six months.
Three simple maintenance mechanisms:
- Date and author on every page. Anyone reading sees "last updated: March 2024" and decides for themselves whether to trust it.
- Quarterly review of the 10 most-read pages. Not the whole base. Only the top. 30 minutes of work, a specific person, a specific day on the calendar.
- "Report outdated" in one click. A button, a form, whatever. Anyone who reads and spots a mismatch flags it with one gesture.
You can't keep the whole knowledge base 100% current. But you can keep the most important 15% at 90%. That's enough to stop the company from freezing when the next Peter leaves.
What next
The rule that always holds: if your company's operation breaks down when one specific person goes on holiday, that isn't a company — it's that person with attachments. A knowledge base is cheap insurance against that. It doesn't need a budget or a new system. It needs the decision that for the next three months, someone in the company will spend two hours a week writing down what today lives only inside heads.
If you'd like to talk through which person and which procedure to start with in your company — the first call is free and takes half an hour.
If your company's operation breaks down when one person goes on holiday, that isn't a company — it's that person with attachments.