How to build a team wiki people actually use

Most teams have started a wiki at least once, and it often goes the same way. Someone spends a weekend building a beautiful structure with twelve sections and a colour-coded index. Three people add pages in the first month. By month six the onboarding page lists a tool you stopped using, the holiday policy is two versions old, and people ask in chat again because "the wiki is probably out of date anyway".

The tool is rarely the problem. Confluence, Notion, a folder of Google Docs or Prompt Notebook will all die the same death if the habits around them are missing. What follows is the set of habits that keeps one alive.

Start from the questions people already ask

The weekend-structure approach fails because it starts from how the team is organised. People don't look things up by department. They look things up by question: "How do I get access to the analytics account?", "Who approves a refund over €500?", "What does 'P1' mean here?"

So before you create a single page, collect the questions. Scroll back through two weeks of team chat and write down every question that got answered more than once. Ask the newest person on the team what confused them in their first month. You will end up with twenty or thirty questions, and they are your first wiki.

Group them loosely. You'll usually find four or five piles, something like:

• How we work: hours, where to ask what, how decisions get made
• Tools and accounts: what you use and who gives you access
• Meetings: which ones exist and what each is for
• Processes: refunds, releases, expenses, whatever your team repeats
• Glossary: the words and abbreviations that only make sense inside the team

That is the whole top level. Five pages, not twelve. Our team wiki template starts with almost exactly this shape, and you can rename every part of it.

Give every page an owner, in the first line

A page without an owner is a page nobody feels allowed to change. It also goes stale without anyone noticing, because nobody is responsible for noticing.

Put the owner's name in the first line of each page: "Owner: Henrik". Not in a hidden property, not in a metadata panel, in the text where everyone sees it. That small line does two jobs. Readers know who to ask when something looks wrong, and the owner sees their name every time they open the page.

Ownership is not authorship. Anyone should still fix a typo or add a missing step. The owner is the person who reviews the page and decides when something has to change.

Write titles as people search

Search is how most people use a wiki after the first week. Write titles the way someone would type the question. "Expense policy" is fine. "Finance > Policies > Reimbursement guidelines v2" is not.

Inside the page, put the answer first. If the page is about refunds, the first paragraph should say who approves what amount. The history of how the refund policy came about can go further down, or into the decision log.

A few habits help a lot:

• Use the words your team uses in chat. If everyone says "the staging box", the page should say "staging box" too, not "pre-production environment".
• Keep one topic per page. A page called "Misc notes" is where answers go to be lost.
• Link instead of repeating. If the onboarding page needs the VPN setup, link to the VPN page rather than copying the steps, so there is one place to fix.

In Prompt Notebook you link a page by typing @ and its name. The page you linked to then lists yours under "Linked from", which is a quick way to see where a page is used before you change it.

Keep decisions separate from documentation

Documentation says how things are. Decisions say why they became that way. Mixing the two makes pages long and hard to scan, and it hides the reasoning when someone wants to change something later.

Keep a decision log: one entry per decision, with the date, who decided, what the options were and why this one won. The wiki pages then state the current rule and link to the decision behind it. When someone asks "why do we deploy on Tuesdays?", the answer is one click away and it isn't someone's memory.

Use onboarding as the test

The best test of a wiki is a new person. Give them the wiki on day one and ask them to keep a list of every question the wiki didn't answer. At the end of their first two weeks, go through the list together and add or fix a page for each one.

This does two things. The wiki gets better with every hire, and the new person learns that the wiki is the place answers live, which is the habit you want everyone to have. An onboarding checklist that links into the wiki for each step makes this easy to run.

Review on a schedule, not when it hurts

Pages decay quietly. Set a review rhythm and stick to it. Once a quarter works for most small teams.

The review doesn't need a meeting. Each owner opens their pages, checks that every statement is still true, and either fixes it or deletes it. Deleting is underrated. An outdated page is worse than a missing one, because people trust it. If a process no longer exists, move the page to the trash.

A simple trick: put a "Last reviewed" date next to the owner in the first line. When you search and land on a page reviewed two years ago, you know to double-check it.

Make the wiki the answer in chat

The biggest shift is cultural. When someone asks a question in chat that the wiki answers, reply with the link, not the answer. When the wiki doesn't answer it, answer in chat and then add it to the wiki, and reply with that link too.

It feels slow for a few weeks. After that, people start checking the wiki first, because they've learned the answer is usually there.

One rule from our template sums it up: if you explain something twice, put it in the wiki.

Where AI helps, and where it doesn't

An AI that can read your wiki changes the search problem. Instead of guessing the right title, someone asks "who approves refunds over €500?" and gets an answer with a link to the page it came from. In Prompt Notebook that is Ask your workspace. It searches the pages you can read and cites each claim with a numbered link, so you can check the source.

It does not fix a stale wiki. If the refund page is two years old, the AI will repeat the old rule with confidence and cite the old page. Owners and reviews still matter. The AI makes a well-kept wiki faster to use. It can't keep the wiki for you. We wrote more about how answers with sources work and where they fail.

A one-afternoon plan

If you want to start this week:

1. Collect twenty questions from chat and from your newest teammate.
2. Create five top-level pages and put each question under one of them.
3. Write the answers, answer first, one topic per page.
4. Put an owner and a review date in the first line of each page.
5. Share the top page with the team. Sub-pages inherit access, so everything new is visible straight away.
6. Next time someone asks in chat, reply with a link.

You can start from the team wiki template or the team handbook and change everything in them. The structure matters less than the owners and the review dates.