Knowledge Base and Wiki
Also known as: wiki, internal documentation, help centre, knowledge management system
A knowledge base (or wiki) is a centralized, searchable repository of documented information (processes, how-to guides, FAQs, policies, onboarding materials, and reference information) intended to be accessed and updated by a team or organization.
Internal knowledge bases serve teams (reducing repeated questions and preserving institutional knowledge); external knowledge bases serve customers (reducing support tickets with self-service answers). Leading team wiki platforms include Confluence, Notion, and Guru. External knowledge bases are often built in Zendesk, Intercom, or Freshdesk.
Knowledge Base and Wiki, explained at three levels
At home
A knowledge base is a shared document library where a team writes down how things work: processes, guides, answers to common questions, and reference information. Instead of asking a colleague 'how do we process a refund?' for the tenth time, the answer lives in the knowledge base where anyone can find it. Good knowledge bases reduce repeated questions and make information accessible to everyone, including new employees on their first day.
At work
When companies rely on individual employees to hold critical process knowledge in their heads, the departure of one person can leave significant knowledge gaps. A knowledge base ensures that documented processes, best practices, and institutional knowledge remain accessible regardless of team changes. Customer-facing knowledge bases (help centres) let customers find answers themselves 24/7, reducing the volume of basic questions that reach support teams.
At home
Under the hood, a knowledge base is a set of articles stored in a database, each with a title, body, owner, tags, and a version history. A search index reads every article and maps words to the pages that contain them, so a query returns ranked matches in a fraction of a second. Categories and links between articles give a second way to browse. Permissions decide who can read or edit each space, and every edit is saved as a new version, so a bad change can be rolled back.
At work
Knowledge base maintenance is the most common failure mode: teams write documentation during onboarding or a specific project, but processes change and articles aren't updated. Ownership models that assign a content owner to each article (responsible for keeping it accurate) perform better than 'everyone is responsible' models where no one feels personal accountability. Article health tracking (last reviewed date, analytics on most-accessed but highly exited articles) identifies stale or inadequate content before it becomes a problem.
At home
AI-powered knowledge bases (Guru with AI assist, Notion AI, Glean) enable semantic search (finding relevant articles even when the search query doesn't match the exact words in the article), automatic article suggestion to support agents based on the current conversation, and AI-generated first drafts of articles from existing documentation. These features reduce the friction of both creating and consuming knowledge base content, the two largest barriers to successful knowledge base adoption.
At work
Enterprise knowledge management involves multiple knowledge repositories that often don't connect: product documentation (Confluence or Notion), customer support articles (Zendesk or Intercom), learning management system (LMS) content, SharePoint intranet, and informal Slack/Teams discussions where undocumented knowledge lives. Enterprise search platforms (Glean, Guru, Notion) attempt to unify search across these disparate knowledge sources. Measuring knowledge base effectiveness requires analytics on search query success rate (did the searcher find an answer?), article view-to-ticket deflection ratio (how many support tickets are prevented by self-service?), and new employee time-to-competency (does onboarding documentation reduce ramp time measurably?).
Real-world examples
At home
Jerome joined a small company with no written documentation. After spending six months asking colleagues the same questions repeatedly, he spent two weekends documenting the 20 most common processes in Notion (software deployment, client billing, vacation requests, expense submission). His team lead was initially skeptical but within a month, new contractors could onboard faster and routine questions to senior staff decreased. The 20-article knowledge base paid for itself in the first month.
At work
Lena managed customer support for a SaaS company receiving 400 support tickets per month. She analyzed ticket categories and found that 35% were about 5 common questions (password resets, billing changes, feature requests that were already in the product). She created a customer-facing knowledge base in Zendesk covering these topics and linked it from the support chat widget. Ticket volume from those 5 topics fell by 70% within three months, allowing the support team to focus on genuinely complex issues.
Common confusions
- Many teams treat a knowledge base and a project management tool as interchangeable places to document things — Project management tools (Jira, Asana, Trello) organize tasks and work in progress. Knowledge bases document stable reference information: how things work, best practices, and guides. Project notes in a task management tool are ephemeral (they become irrelevant when the project ends); knowledge base articles are persistent (they remain relevant and should be updated over time). Mixing the two leads to noise in both: the project tool fills with stale documentation, and the wiki fills with resolved tickets.
- Some organizations believe internal knowledge bases are only necessary for large companies — Knowledge bases are most valuable when organizations are small enough that documentation is still feasible, before processes become too complex to document. A 10-person company that documents its processes as they're created builds institutional memory organically. A 100-person company trying to retroactively document 5 years of undocumented processes faces a much larger, less accurate challenge. Small teams benefit disproportionately from early knowledge base investment.
For analysts
When a client is experiencing high turnover impact or slow onboarding, a knowledge base audit is the diagnostic starting point. Ask how new employees learn how to do their jobs: if the answer is 'they ask other people,' the organizational dependency on individual knowledge holders is a business risk. Quantify the time cost of those repeated knowledge transfers (hours per new hire x number of hires per year x average salary) and compare it to the time investment of building and maintaining a knowledge base.
History & origin
Ward Cunningham created the first wiki software (WikiWikiWeb) in 1995, using the Hawaiian word 'wiki' (meaning quick) to describe the fast editing mechanism. Wikipedia (launched 2001) demonstrated wikis' potential for collaborative knowledge building at scale. Enterprise wikis emerged in the 2000s to address the problem of organizational knowledge trapped in individuals' heads, email threads, and personal files. Confluence (Atlassian, launched 2004) became the dominant enterprise wiki. The rise of modern tools like Notion (2013) and Coda brought more flexible knowledge base options. Customer-facing knowledge bases (often called help centres) became standard alongside customer support platforms, with Zendesk and Intercom building integrated support documentation tools.