Internal Wiki · Knowledge Base
Internal Wiki and Knowledge Base
What is an internal wiki?
- Success depends on keeping documents accurate, not on the tool
- Owner role, verified date, and next review date on every page
- Launch with 20–30 recurring questions and mark outdated pages as deprecated
Talk of building an internal wiki usually starts with choosing a tool, but a wiki succeeds or fails on whether its documents stay accurate, not on the tool. If you have 500 documents but can’t tell which are still valid, people won’t search; they’ll ask the person at the next desk. The problem a wiki solves is not storage but the same questions going to the same people again and again. If one person answers how to register for training thirty times a month, that answer is your first document candidate.
The basic unit of operation is three labels attached to each document: owner, last verified date, and next review date. Name the owner by role or team rather than by individual so ownership survives reassignments. For structure, organizing around the questions people actually ask, such as 'First week', 'Travel expenses', and 'Training registration', works better for search than folders by department. Keep each topic in one document only and link to it from elsewhere so the content doesn't diverge.
Trying to move everything at once means you never get started. A realistic approach is to pick out questions repeated three or more times in messenger and email over the past three months and launch with 20–30 pages. One rule grows the wiki: when a question comes in, don't write the answer in chat; turn it into a page and send the link. Reviewing view counts and searches that returned no results each month shows what to write next.
The weak point in practice is outdated documents. When a policy changes but the page doesn't, the wiki becomes a place that gives wrong answers with confidence. Anyone who followed a wrong page and had their request rejected won't open the wiki again. The problem gets worse when internal AI search is connected to the wiki, because the AI builds plausible answers from retired documents. Make deleting outdated pages or marking them as 'deprecated' a regular task, as important as writing new ones, and check access permissions separately for restricted pages such as payroll and performance reviews.
Seolyeong ParkGenerative AI and AX training expert with 17 years of hands-on experience and 200+ lectures, who gets non-specialists using AI right away
John KimJohn Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”"Wiki" comes from a collaborative documentation approach in which anyone can edit pages in a web browser, while "knowledge base" comes from the customer support and IT support practice of collecting answers to frequently asked questions. The two have merged, and today both terms refer to a space that gathers internal work knowledge.
Consider a hypothetical case. At Company A, a software company with 280 employees, the four-person HR and General Affairs team spent an average of two hours a day answering questions that came in through chat. The wiki they had built three years earlier held 640 documents, yet fewer than 30 people viewed it in a month.
- When the HR and General Affairs manager sorted 410 chat questions from the past three months, the top 25 questions made up 68% of the total. The most common was how to register for training.
- Opening the 640 existing pages showed that 220 belonged to people who had left the company. The team lead concluded: "Let's not try to fix them yet. Mark them all as 'unverified' first."
- They wrote the top 25 questions up as new documents and put the owning role, last verified date, and next review date at the top of each one. The writing took four people two weeks.
- When an inquiry came in, the team stopped writing answers directly and set a rule to send a link to a page. If no page existed for the question, they wrote one that day and answered with its link.
- They set aside 30 minutes on the last Friday of each month for review, fixing or retiring documents past their review date, and added the top 10 searches that returned no results to the following month’s writing list.
- Six months later, messenger inquiries fell from 137 to 48 a month, and monthly wiki readers rose from 30 to 210.