To preserve company knowledge, write down rules, instructions and recurring answers as soon as they appear, place them in a knowledge base with a clear section structure, give each section an owner and review it on a schedule. Knowledge then belongs to the company. It no longer leaves when one experienced employee goes on holiday or changes jobs.
Why does company knowledge stay with individual employees?
Every company has a person everyone asks. They know how to set up a new client, which supplier to call, why the invoice template has that odd extra line. Nobody wrote it down. It is simply in their head.
This is often called tribal knowledge: know-how that lives in people’s memory and passes on by word of mouth. It builds up for natural reasons.
- Rules and methods are explained out loud. A senior colleague shows a newcomer how something works. The explanation is good. It is also gone the moment the conversation ends.
- Useful solutions sit in personal notes and chats. Someone fixed a tricky problem last spring. The fix is in a private document or a long message thread that nobody else will find.
- New employees keep asking experienced ones. Each question is short, but together they take a noticeable share of the most experienced people’s time.
- Part of the expertise leaves with people. When a long-serving employee moves on, the company discovers what they knew only when something breaks.
None of this is anyone’s fault. Writing things down feels slower than answering a question. Until the person who knew the answer is no longer there.
What knowledge is worth keeping?
Not every thought needs a page. The aim is to capture what the company uses again and again. Seven types of material pay off first:
- Rules and policies: how holidays are requested, who approves expenses, what the working hours are.
- Instructions: step-by-step guides for tasks people do regularly but not daily, such as closing a month or onboarding a client.
- Work standards: how a deliverable should look, what a good handover includes, naming rules for files.
- Answers to frequent questions: anything asked more than twice.
- Descriptions of internal processes: who does what, in which order, with which tools.
- Onboarding materials: what a new employee needs in the first week, by role.
- Specialists’ practical experience: lessons from past work, typical mistakes, tricks that save time.
A useful test: if the answer would be the same next month, it belongs in the knowledge base. If it changes every week, it probably belongs in a task or a project.
How do you turn personal experience into company knowledge?
The hard part is not the tool. It is the habit. Knowledge gets captured when writing it down is part of the work, not an extra job for Friday afternoon.
A simple cycle helps:
- Notice the moment. A decision was made, a problem was solved, the same question came up again. That is the moment to write.
- Turn it into an instruction. Use the real case as the example. “How we fixed the import error” is easier to follow than an abstract rule.
- Collect repeated questions. Keep a running list. Once a question appears three times, its answer gets a page.
- Name an owner. Each section has one person responsible for keeping it accurate. Not for writing everything, but for noticing what is out of date.
- Review on a schedule. Once a quarter, the owner opens the section and checks what has changed.
The fourth step is the one most often skipped. A page without an owner starts going stale on the day it is published.
A short example
A small consulting firm hires two analysts in the same month. In the first weeks, both ask a senior consultant the same questions: where the client templates live, how to log time on internal work, who signs off on reports.
The consultant writes the answers into an onboarding section, one page per question, with links to the templates. The office manager becomes the section owner. When the third analyst joins in spring, they read the section on day one. The senior consultant now gets occasional questions instead of the same ones every week.
How do you organise a knowledge base?
A knowledge base is a structured collection of a company’s shared rules, instructions and experience, organised so people can find answers without asking a colleague. Five decisions shape whether it gets used.
- Split information by area. Sections for HR, finance, sales, delivery and general company rules are a good start. People look for answers by department first.
- Build a clear section structure. Two or three levels are usually enough. Deep nesting helps large companies, but each extra level is one more click.
- Make answers easy to find. Page titles should match the words people search for. "How to request leave" beats "Absence policy, version 3".
- Restrict access where needed. Most of the knowledge base can be open to everyone. Salary rules or management guidelines may need a smaller audience.
- Keep content current. Old pages do more harm than missing ones, because people trust them. Owners and review dates solve this.
The company knowledge base page shows how teams put this structure into practice.
Knowledge base vs project documentation: what is the difference?
The two are easy to mix up. Both are written, structured and shared. They serve different purposes.
| Knowledge base | Project documentation | |
|---|---|---|
| What it holds | Rules, instructions, standards, experience | Goals, requirements, decisions, agreements of one project |
| Who uses it | The whole company or a department | The project team and stakeholders |
| How long it lives | As long as the rule is valid | As long as the project runs, then archived |
| Example | “How we onboard a new client” | “Client X: agreed scope and change requests” |
Keeping them apart stops the knowledge base from turning into an archive of every document the company ever produced. Lessons from a project can move into the knowledge base once they apply more widely. How to keep project information in one trusted place is covered in our article on a single source of truth for projects.
How does Weenvo keep company knowledge?
In Weenvo, the knowledge base lives in the Wiki app, part of the Collaboration group of apps. The Wiki is built from sections, and sections can be nested inside each other to any depth. Each section holds tabs with content: formatted text with images and tables, or an embedded external page.
Several features support the habits described above:
- Templates speed up new sections and keep pages consistent.
- Section access can be given to users or whole teams at View, Edit or Full Access level. If a section is restricted, people without access do not see it at all.
- Publishing control: a new section stays hidden until someone publishes it, so drafts do not appear half-finished.
- Content history keeps every saved version. Any two versions can be compared, and an earlier one can be restored.
- Attachments and discussions can be switched on per section, so files and questions stay next to the page they concern.
The Content Administrator system role gives one person or team full control over the Wiki’s structure and content. The Weenvo wiki guide to the Wiki app walks through each feature. Project-level documents sit separately in documentation management, next to the project they belong to.
For HR teams, the Wiki often becomes the home of onboarding: the Weenvo page for HR teams shows how it connects to the rest of the employee’s first weeks.
The Wiki search field looks up section titles, so clear, specific titles make pages easier to find.
Start free and create the first sections of the company knowledge base.
FAQ
What is tribal knowledge?
Tribal knowledge is know-how that exists only in employees’ heads and passes on by word of mouth. It covers methods, workarounds and context that nobody has written down. When the people who hold it leave, the company loses it.
How do you keep knowledge when an employee leaves?
Start before the notice period. Ask the employee to list what only they know, then turn each item into an instruction in the knowledge base, with a named owner. A habit of writing things down as part of daily work makes the last weeks far less of a scramble.
What should go into a knowledge base first?
Begin with answers to the questions asked most often, then onboarding materials and instructions for regular tasks. These save time from the first week. Policies and standards can follow once the habit of using the knowledge base is in place.
How do you keep a knowledge base up to date?
Give every section one owner and a review date, for example once a quarter. Fix or remove outdated pages as soon as someone reports them. Version history makes it safe to edit, because any earlier version can be restored.