Building an Internal Wiki That Actually Gets Used

Why so many company wikis go stale

The pattern is often the same. An owner or a committed employee sets up a wiki, creates a structure, and asks everyone to enter their knowledge. In the first weeks, pages appear on processes, customers, and tools. After a few months, the pages are outdated, hardly any new ones are added, and questions are again answered by calling across the room. The wiki still exists, but nobody relies on it anymore.

This leads to the guiding question of this article: how does a small company build an internal wiki that is still used and maintained after a year? To answer it, we first clarify what a wiki is and what it is suited for, then present the knowledge-sharing dilemma as a thinking model, look at findings from case studies, weigh two ways of building a wiki, and finally describe a setup in six steps.

A wiki does not die from a lack of technology, but because writing costs the individual more than it brings them.

What is a wiki, and what is it suited for?

A wiki is a collection of pages that any authorized person can create and edit directly in the browser. Every change is recorded in a version history, and pages can be linked to one another. The name goes back to the Hawaiian word for quick. The best-known wiki is Wikipedia. In companies it is often called an internal wiki, knowledge base, or team handbook.

A wiki is suited for knowledge that changes and is needed by many people: processes, contacts, answers to recurring questions, settings of machines and programs, rules for working together. It is less suited for files that no longer change once created, such as contracts or invoices. These belong in the filing system described in the article on digital filing. And it does not replace passing on experience through joining in and watching, which the article on securing knowledge before experienced employees leave describes using the model of Nonaka and Takeuchi.

The thinking model: the knowledge-sharing dilemma

Ángel Cabrera and Elizabeth Cabrera (2002) offered an explanation for why knowledge systems often stay empty even though everyone finds them useful. They describe knowledge sharing as a social dilemma, similar to a public good. For the individual, writing things down takes time, and sometimes it means giving away an advantage. The benefit goes to everyone, including those who contribute nothing themselves. If everyone acts on their short-term advantage, almost nobody writes, and everyone ends up worse off than if each had contributed something.

An everyday analogy is the shared office kitchen. Everyone benefits from a clean kitchen, but washing up costs the person who does it. Without a rule, without visibility, and without the sense that one's own contribution makes a difference, the dishes pile up. A wiki is an office kitchen for knowledge.

From research on such dilemmas, the authors derive three kinds of countermeasures. They are the core of the setup described further below.

What case studies show about wikis in companies

Lin and Ehrlich (2012) examined the internal wiki of a German IT service provider that had been introduced in 2008 and gradually developed into the company's global intranet. It comprised around 56,000 pages. The authors assigned the pages to four application scenarios: presentation and communication, encyclopedia, project organization, and collaborative design. In interviews, employees almost always named their own goals as the main reason for using it, such as organizing their own work or avoiding inquiries. Altruistic motives such as helping others were rarely named as the main reason. The authors conclude that a wiki grows mainly through the application scenarios that benefit the writer.

Stocker, Richter, Hoefler, and Tochtermann (2012) described three wiki introductions in companies. The wikis were used very differently: as a knowledge base, as an encyclopedia, and as support in customer service. In each case, use adapted to the specific work. As lessons, the authors name that those involved need to know the potential benefit, that management must additionally support the introduction, and that there needs to be clear communication about what the wiki is for.

For small and medium-sized companies there is a more recent case study. Schober, Stampfl, and Geyer (2025) followed a medium-sized swimming pool manufacturer in Austria as it introduced a wiki-based knowledge database, and interviewed employees at different levels. Satisfaction increased, mainly because information was easier to find and processes ran more smoothly. How satisfied someone was depended on whether the system covered their specific knowledge needs. Middle management and specialists benefited more than top management and administrative staff. The study is qualitative and concerns a single company.

A bibliometric analysis by Budić, Klopotan, and Hegeduš (2025) of 352 publications also shows that research on wikis declined after the peak of the Web 2.0 era. Today wikis tend to be seen as a background for other tools, for example as a knowledge base for generative AI. For a company this means: the wiki today is often part of a work platform rather than a separate system.

Reference work or work tool? Two ways to build a wiki

There are two readings of how a wiki should be built. The first is modeled on Wikipedia: a reference work with a well-thought-out structure into which everyone enters their knowledge. Order speaks for this. Anyone looking for something finds it in an expected place. The knowledge-sharing dilemma speaks against it. Maintaining a reference work is extra work, and extra work is the first thing to be dropped in day-to-day business.

The second reading sees the wiki as a work tool: pages arise because someone needs them for their own work, such as a checklist for their own process or an answer they would otherwise have to give three times a week. The findings of Lin and Ehrlich speak for this: what gets used is what benefits the writer.

I consider the second reading the more sustainable one, with one concession to the first. A lean basic structure with four to six areas is needed so that pages remain findable. Everything below that should grow out of the work. A wiki planned as a reference work looks complete on day one and is outdated after a year. A wiki that grows as a tool looks thin on day one and after a year is what everyone uses.

Building a wiki in six steps

The following setup applies the three levers of the knowledge-sharing dilemma. It is intended for a company with five to fifty employees and requires about one hour per week from the responsible person during the first four weeks.

1. Choose a place

   Use the tool the team already opens every day. A wiki in an additional system that nobody else uses loses against the inbox.

2. Create a lean basic structure

   Four to six areas, such as processes, customers and orders, tools, contacts, rules. No deeper structure in advance.

3. Start with the most frequent questions

   For two weeks, collect every question that is asked more than once in the team. The ten most frequent become the first pages.

4. Provide page templates

   One template for process pages, one for answers, one for contacts. This reduces the effort for every new page.

5. Answer with links

   Whoever answers a question whose answer is in the wiki sends the link instead of the answer. If the page is missing, they write it and then send the link.

6. Set owner and review date

   Each page has an owner and shows the date of the last review. Pages older than twelve months are reviewed or archived.

The fifth step is the most important. It makes the wiki the place of answers, not a place where answers are additionally filed. The rules from the sixth step correspond to those the article on sales knowledge management describes for sales knowledge. How a single process page is structured is shown by the one-page method.

One example of a work platform that combines tasks and knowledge pages in one place is quik OS, a tool from a business partner of Owners Council. Whether this or another tool fits, you check with the same questions: does the team open it every day? Can a new colleague find an answer in under a minute? Can an owner and review date be recorded for each page?

Where a wiki reaches its limits

A wiki stores what can be written down. Experience that only shows itself in doing, such as a feel for a difficult customer or setting up a machine by ear, can only partially be captured in pages. That requires guidance and joining in. For onboarding new colleagues the wiki is therefore a help, but no substitute for a mentor, as provided for in the article on onboarding new employees.

The evidence also has limits. The studies cited are case studies of individual companies, partly from the IT industry and from the time when wikis were new. They show patterns, not proven effects.

Conclusion: how does an internal wiki get used?

We began by asking
a small company builds a wiki that is still used after a year. The answer lies less in the software than in the knowledge-sharing dilemma. Writing costs the individual, the benefit goes to everyone. A wiki therefore stays alive when contributing costs less and brings more: pages arise from people's own work, templates reduce the effort, answers are given with links, and each page has an owner and a review date.

As shown, the case studies point in the same direction. What gets used is what benefits the writer, and management must visibly support the introduction. In the end, a wiki is not an archive of knowledge, but a habit of the team.

How to get started

1. Decide which tool the wiki should live in, one the team already uses every day.
2. Create four to six areas and no more.
3. Ask the team to note every repeated question on a list for two weeks.
4. Write the first page yourself on a question you often answer, and from now on answer with the link.
5. In the next weekly meeting, agree on the rule: whoever gives an answer for the second time writes a page.