A knowledge base nobody opens is a folder. What is genuinely worth writing, how to organise it so people find things, and who maintains it - with no project and no expensive tool.
Key takeaways
- Write only what has been asked more than once.
- The document's name matters more than its content, because it is what makes it findable.
- A long document will not be read; two short ones will.
- With nobody maintaining it, a knowledge base becomes a source of wrong information within a year.
An internal knowledge base nearly always fails for the same two reasons: too much gets written, and nothing can be found. In a small team what works is twenty to forty short documents with good names - not a system attempting to hold all the knowledge in the business.
What is worth writing
| Content type | Write it? | Why |
|---|---|---|
| A question asked twice | Yes | It will be asked again |
| A procedure for a recurring task | Yes | Saves training |
| A decision and its reason | Yes, briefly | Prevents re-debating |
| Knowledge held by one person | Yes, as a priority | A genuine risk |
| Information that changes monthly | No | It will be wrong quickly |
| What is in the vendor's own documentation | No | Link, do not copy |
The last row saves a lot of work: instead of copying a vendor's explanation, write one line about what you do and link to the original. When the vendor changes something, the link is still correct.
Organising so people find things
Not through deep folders but through names. A good document name starts with the action or the question as it is actually asked: "how to refund a customer" rather than "credit policy". The difference sounds small and is decisive - people search using the words they would use in conversation.
Beyond that, three rules: no more than two folder levels; one tag or keyword per document; and one page at the top listing the ten most-used documents. That page replaces search for most day-to-day use.
Length: why short wins
A three-page document is read once, during training. A half-page document is opened during work - and that is the whole difference. When a topic needs more, split it into two or three short documents that link to each other.
The practical rule: a document that does not fit one screen without long scrolling probably contains more than one topic. The format itself - what belongs in an operational document - is covered in writing SOPs for a small team.
Where to keep it
Wherever the team already opens every day. If they work in a particular tool, put it there - not in a separate system requiring another login. A knowledge base in a tool nobody opens is an expensive folder.
More important than the tool: that there is only one. The common problem is not the absence of written knowledge but its dispersal - some in documents, some in pinned messages, some in a group chat. Consolidating into one place is most of the work, and in most businesses it takes a day.
Who maintains it
A knowledge base with no maintainer turns from an asset into a liability: documents go stale, somebody acts on wrong information, and from then on nobody trusts the list. Three rules suffice:
- Every document carries a date and the author's name.
- Whoever finds an error fixes it on the spot, without approval.
- Every six months review the list and delete what is no longer relevant.
The second rule makes the difference. When a correction requires approval, corrections do not happen - and a wrong document does more damage than a missing one, because it looks authoritative. The risk of somebody making a document worse is far smaller than the risk of the whole base going stale.
What happens when a new employee joins
That is the best test of a knowledge base. A new employee given ten documents who keeps asking about things written in them - the problem is the names or the organisation. One asking about things that are not written - you have found exactly the gaps worth filling.
So ask them to record every question they asked in their first fortnight. That list is the best work plan a knowledge base can have, and it is produced free - unlike trying to guess in advance what is missing.
How do you start from nothing?
Not by planning a structure. The fast route is the reverse: for two weeks, every time somebody asks a question that has been asked before - write the answer in a short document and send the link instead of explaining again. After two weeks you have five to ten documents, all on topics proven to be needed.
What matters is not trying to write "everything" up front. A list of forty topics assembled in a meeting will stay mostly empty, while ten documents born from real questions are already in use. After a month you can look at what exists and organise it - and then the structure follows the content rather than preceding it.
What turns a knowledge base into a source of wrong information
The danger is not that documents will be missing but that they will be old. A document describing a process that changed six months ago is more dangerous than no document, because a new employee will follow it with complete confidence.
Three checks prevent that: a visible date at the top of every document, so a reader knows when it was written; deleting documents not opened in a year; and a quick review of the most-used documents after any change to a system or process. The third is the only one requiring somebody to remember - so attach it to an existing routine, such as the same quarterly procedure review.
What does not belong in the knowledge base
Three kinds of content are better kept out. Personal information about employees - that belongs somewhere with separate permissions. Passwords and access details - a password manager, not a shared document. And contested decisions still under discussion - a document written mid-debate becomes fact before anything was agreed.
The second matters especially: a knowledge document containing access details is one you cannot share freely, and the moment that is true it stops being used. Better to write "access is in the password manager under X" and keep the knowledge open to everyone.
Sources
Frequently asked questions
Do we need a dedicated tool?
Not in a small team. A shared folder with well-named documents does the job. A dedicated tool starts paying off with many documents, a need for differing permissions, or when search becomes a real problem.
How many documents is too many?
When you can no longer scan the list by eye and find things. In practice, in a team of up to ten, forty documents is already a lot - and if there are more, check how many were opened in the past year. The answer is usually a surprise.
Who should write them?
Whoever performs the task, and briefly. The fastest way to build a knowledge base is not to set aside writing time but to write as you go: every time somebody explains something to a colleague, they write it in five lines and save it.
What about knowledge that is hard to write down?
Record it. A three-minute voice explanation or a short screen recording is sometimes worth more than a document, especially for anything visual. What matters is that it has a good name and lives in the same place as everything else.
Keep reading
Related service
MVP Development
Turn an idea into a validated product in weeks, not months.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.