Corporate Wiki Best Practices - 10 Actionable Tips

We recommend four habits over any feature: one page per question, an owner on every page, chat answers that link to the page, and a regular read of the searches that found nothing. A company wiki rarely fails because people cannot write. It fails when pages go stale and people learn that search will not find the answer, so they ask a colleague instead. The ten practices below build those habits.

Do you need a dedicated wiki yet?

A team of five can often manage with pinned docs in Slack and a shared drive. Headcount and page count are poor signals for moving. Watch for people asking a colleague a question they could have searched, because they have learned that search will not find the answer. That is the point to move: a wiki gives people one place to search instead of tracking down whoever remembers. To check, ask three teammates to find one policy answer, such as the time-off rules, and see who gives up and asks.

1. Pick an editor your least technical teammate can use alone

During the trial, ask the person least comfortable with software to fix a typo, add a table and paste a screenshot without help. If they cannot, only the technical people will write, and the wiki will hold only what they know.

2. Open your most-used pages on a phone

Some readers have only a phone: people on shifts, in the field or travelling. Open your three most-used pages on one before you roll the wiki out, and check that tables and screenshots stay readable. A page that is hard to read on a phone gets skipped by exactly the people who cannot walk over and ask someone.

3. Organize by what people are trying to do

We recommend grouping pages by task, such as “Start a new job”, “Spend company money” or “Get a customer refunded”, and recording the owning department on each page instead of building the structure around departments. Nielsen Norman Group’s intranet research found that task-based structures often withstood organizational change better than structures organized by department. A department-first wiki is easy to maintain because each team gets a section, but its navigation has to change whenever the company reorganizes, and it asks the reader to know which team owns the answer before they can look.

4. Title each page as the question people ask

Call a page “How to request time off”, not “HR policy v3”. Then add the words people use that the title leaves out, such as vacation, PTO or leave, as tags or in the first line, because people search with their own words, not yours.

5. Write templates for recurring pages only

Write a template for a page type once you have written it a few times: how-to guide, meeting notes, project brief, decision record, onboarding checklist. Start each with the same short head (what this page answers, who owns it, when it was last checked, where to go next) so a reader can judge in seconds whether to trust it. Skip templates for one-off pages.

6. Answer questions in chat with a link, not a paste

When someone asks a question in chat, reply with the page’s link. If there is no page yet, write it first and then send the link. Text pasted into chat cannot be corrected, so the old answer keeps circulating after the page changes, while a link opens the current one. Managers should go first, since the rest of the team answers the way they do. A wiki that integrates with your chat tool makes this a few seconds’ work.

7. Give every page an owner and a review date

Name the owner as a role, such as “Head of Support”, not a person, so the page survives promotions and departures. Put a review date on the page, and if the date passes with no response, reassign the page or archive it. Pages with no owner go stale unnoticed, and a few wrong pages are enough for readers to distrust the rest.

8. Start open and restrict by exception

A wiki is built for everyone to edit, so let everyone read and edit by default and restrict only the pages where a wrong edit or a leak costs real money or breaks a rule. Ask three questions about each area:

• What should every employee see, and what should stay private?
• Who can edit, and who can only view?
• Which pages hold sensitive information, such as performance reviews or invoices, that only some people may see?

Too loose and sensitive pages leak, which causes tension and can mean a data breach. Too tight and few people will write in the wiki at all.

9. Read the searches that found nothing

Wiki analytics usually list the most-viewed pages. If yours also shows searches that returned no results, read those first: each is a question someone needed answered and the wiki could not. Write pages for the most frequent ones, then check the owners and review dates of the most-viewed pages. Kipwise allows users to view performance analytics, pinpointing areas of improvement and the helpfulness of content.

10. Archive replaced pages instead of deleting them

When a page is replaced, mark the old one archived and link to the new one. Old links sit in chat threads, emails and onboarding documents for years, and a deleted page leaves a dead end in every one of them, while an archived page with a pointer sends the reader to the current answer.

Want to build up your company's knowledge hub easily and efficiently? Kipwise is a modern business tool for organizations to take their knowledge management to the next level. With integration of tools, an intuitive interface and more useful features, teams can now collaborate in real-time and share information anytime and anywhere. Find out more about our solutions today.

‍