Why company wikis fail and what works instead

Confluence, SharePoint, MediaWiki, Notion: the tools are mature. Yet the pattern repeats in companies of every size, no matter which software is in place. When the same failure occurs everywhere, the cause lies elsewhere.

A wiki asks an employee to document knowledge at precisely the moment they want to move on to something else. They have just solved a problem, and their head is already in the next job. To them, documentation is extra work for an audience they do not know, at a time they did not choose.

Anyone who is supposed to document after the work is done first has to get through a chain of decisions:

• Is this knowledge important enough?
• Where does it belong?
• How do I phrase it?
• Which existing page needs updating?
• Which tags fit?
• Is what is already there still accurate?

Each question on its own is small. Together they are a good reason to put the whole thing off. Most of the time, “I'll do it later” wins. And later rarely comes.

So knowledge bases do not go stale because nobody has knowledge. They go stale because maintaining them is an additional task that offers hardly any immediate benefit to the person doing it. The effort is due today. The benefit arrives at some point, usually for someone else.

You probably know the usual remedies: a wiki owner, an editorial plan, a documentation duty written into the work instructions. Some companies even offer bonuses. All of this treats symptoms, because the incentive structure stays the same: the effort sits with the individual, the benefit sits somewhere else.

Editorial plans have a second weakness. They decide what should be documented before anyone has asked for it. They reflect what an editorial team considers important, not what is actually missing in daily work.

And even well-kept pages are no proof of quality. Documented does not mean correct: a tidy-looking guide can have been wrong for years. The first person to rely on it finds out.

Many mid-sized industrial companies are certified to ISO 9001:2015. In clause 7.1.6, the standard addresses “organizational knowledge”: companies must determine, maintain, and make available the knowledge necessary for their processes. Knowledge gained from experience is explicitly included, not just what is already documented.

Nowhere does the standard prescribe a wiki. A visibly outdated wiki can even become awkward in an audit: whoever presents it as evidence of how knowledge is handled mainly proves that this handling does not work.

It is worth a look at DIN ISO 30401:2022, the dedicated standard for knowledge management systems. Among other things, it calls for dealing with outdated knowledge, and it explicitly names knowledge activities embedded in business processes as a driver. Embedded, not set up alongside. What this means for your operation in concrete terms is something to clarify with your auditor; this article is not standards consultancy.

This is why I believe modern knowledge management has to reverse direction. Not: employees maintain a knowledge base. But: knowledge is created during normal work, and the system helps to recognize it, organize it, and make it findable again.

The idea is not new. Klaus North's knowledge ladder shows that information only turns into knowledge, skill, and competence across several steps. A wiki works on the lowest of these steps: it stores information. Everything above that comes from application, in other words from work.

A note, a document, an answer to a concrete question, or a sentence like “The customer is still waiting for the approval” should not have to pass through five forms before it becomes company knowledge. The threshold has to be so low that nobody perceives it as a hurdle.

Even more important is the opposite direction: a good system recognizes which knowledge is actually missing. When different employees keep asking the same question, that is a stronger signal of a knowledge gap than any editorial plan. This signal comes from everyday work, not from a meeting.

Whatever you introduce or keep: five criteria separate tools that survive daily use from tools that become the next data graveyard.

• Capturing happens in the flow of work and needs no separate maintenance step.
• Search works with a question in plain language instead of folder logic and tags.
• Every answer names its source, so what it is based on remains verifiable.
• Contradictions and gaps become visible on their own, without anyone having to look for them.
• Whether content is still current is questioned where it is actually used, not by calendar entry.

A classic wiki keeps its place alongside this: for stable content such as templates, responsibilities, or policies that rarely change. For experience-based knowledge from day-to-day operations, it is not enough.

We built hAiner on this principle. hAiner reads the sources your company already has: documents, file shares, your own website. Employees ask their question the way they would ask a colleague and get an answer with a source reference. Where sources contradict each other or answers are missing, exactly that becomes visible, and that is where targeted documentation pays off.

This approach has a limit too: it can only organize what comes into existence somewhere. If nothing is ever written down, no note, no email, no document, there is nothing to find. The difference lies in the threshold: material that accumulates anyway becomes findable knowledge, without anyone maintaining a database.

If you want to find out where your operation depends on the knowledge of individual people today, take the knowledge-loss check. And how to preserve experience-based knowledge before it leaves the company is covered on our topic page Preserving experience-based knowledge.