A corporate knowledge base: getting what's in people's heads onto the page

Every company has a layer of unwritten knowledge: why a process works the way it does, the peculiarity of one customer, the known quirk of a system. That knowledge lives in people's heads, and when someone leaves it goes with them. That is the reason a corporate wiki exists — not to store documents, but to write down institutional memory.

How it differs from the document centre

The two are assumed to be the same thing but they solve different problems.

The document centre holds official, approved content: policies, procedures, forms. The author is known, versions are approved, changes are controlled.

The wiki holds living knowledge: how-to guides, team notes, common pitfalls. Anyone can contribute, it changes often, and it needs no formal approval.

A company needs both. Managing the wiki like a document centre — approval for every change — kills it; managing the document centre like a wiki — anyone can edit — creates compliance risk. We cover the document side in a separate article.

Hierarchy: wide, not deep

Structure is where wikis most often die. Nobody can navigate a tree five levels deep, and nobody knows where to write.

What works: two levels at most. Team or topic headings at the top, pages beneath. When more depth seems necessary, the problem is usually not the structure but a page that has grown too large — splitting it is the right answer.

And accept this: people don't navigate trees, they search. Structure is a fallback for when search fails.

Revision history and rollback

The biggest reservation about a system anyone can edit is: what if someone writes something wrong, what if someone deletes an important section?

The answer is an immutable revision history. Every edit is recorded with who made it and when, and any earlier version can be restored in one click. Without that guarantee, granting write access is hard; with it, keeping access wide becomes safe.

In practice the fear of deletion is overstated: the real risk is not malicious deletion but nobody writing anything at all.

Without ownership a wiki goes stale

The wiki's biggest enemy is the same as the document centre's: content that has lost its currency. The risk is higher here, because wiki content is less formal and nobody treats reviewing it as their job.

Two practices work: every page has a named owner, and the last-updated date is visible on the page. When the date is shown, the reader can make their own judgement — they approach a page updated two years ago with caution.

Regular freshness reviews are needed too; reminding owners about pages untouched for a defined period is part of the rhythm described in our operations article.

What should and shouldn't be written

The three most valuable kinds of wiki content:

1. How-to — the steps of recurring work. "How to onboard a new supplier", "how to dispute an invoice".
2. Why it's like this — the reasoning behind a decision. This is the most frequently lost knowledge and the only thing that prevents re-litigating the same debate.
3. Known pitfalls — the quirks of systems and processes.

What shouldn't be written is equally clear: personal data, performance information, salaries and confidential contract details. A wiki is an area open to the whole organisation; that content belongs somewhere with permissions.

Make writing easy

The biggest barrier to contribution is making writing feel heavy. Approval flows, mandatory templates and complex formatting kill it. The right default: edit, save, done. Quality control comes afterwards, through review.

There is also a starting threshold: nobody wants to write the first page in an empty wiki. Filling ten to fifteen pages during setup clears it.

The wiki and AI

A knowledge base is the most productive source for a corporate assistant: written, current and open to the organisation. The best answer to "how does this process work" is usually a wiki page.

That has a positive side effect: the questions the assistant can't answer point directly at the missing pages. Reviewing unanswered questions regularly is the most efficient way to grow the knowledge base — nobody has to wonder what to write. We cover the assistant's scope in a separate article.

Measurement

• Breadth of contribution — how many different people edited? A wiki written by one person is a personal notebook, not a wiki.
• Unsuccessful searches — topics searched for but not found are your page backlog.
• Stale page ratio — the share of pages untouched for six months.

We recommend leaving the wiki to the second wave of rollout; the reasoning is in the 90-day plan.