An internal knowledge base is a private, searchable collection of articles where a company writes down how it works, for its own staff: processes, policies, product details and the answers colleagues keep asking each other for. Customers never see it.
It goes by other names: a team wiki, a company handbook, internal docs, a playbook. The name matters less than the job. When someone asks “how do we handle a refund after 30 days?”, the answer should be one search away, written once, and the same for everyone.
What goes in an internal knowledge base
Anything a colleague might need to know to do their job without asking someone. Here’s what it typically holds, by team.
Support
- How to handle requests the public articles don’t cover: refunds outside the policy, account transfers, legal requests.
- When and how to escalate, and to whom.
- Known issues and their workarounds, while a fix is on the way.
- Tone and wording guidance, and the replies the team uses most.
Product and engineering
- How features actually behave, including limits and edge cases support needs to explain.
- Release notes written for the team, before customers see them.
- Runbooks for incidents, and who is on call.
Sales and success
- What each plan includes, discount rules and who can approve them.
- Answers to security questionnaires and common objections.
- Onboarding checklists for new customers.
Everyone
- Onboarding for new starters: tools, accounts, who does what.
- Policies: holidays, expenses, equipment, security.
- How the company makes decisions, and where past decisions are written down.
Internal and external knowledge bases
An external knowledge base, usually called a help centre, is public and written for customers. An internal one is private and written for staff. They often cover the same subjects at different depths.
| Internal knowledge base | External (help centre) | |
|---|---|---|
| Readers | Your team | Customers and prospects |
| Access | Signed-in staff only | Public, indexed by search engines |
| Content | Processes, policies, exceptions, how things work underneath | How to use the product, plans and billing, troubleshooting |
| Writing | Can assume context and use internal terms | Plain, careful, no jargon |
| If it’s wrong | A colleague is misled, usually caught | A customer acts on it, and may complain |
The two drift apart when they live in separate tools. The public article says refunds are available for 30 days; the internal note about exceptions was written two policy changes ago. Keeping both in one place, with each article marked as public or internal, means the person updating one sees the other.
AI adds a third kind: guidance you want an AI assistant to follow when it answers customers, but don’t want published word for word. For example, “if someone asks about refunds after 30 days, explain the policy and offer to pass them to the team”. If you use an AI assistant, decide where that guidance lives before it ends up in a public article by mistake. Our guide to what an AI knowledge base is covers how these assistants read your content.
Signs you need one
- The same questions come up in team chat every week, and get slightly different answers each time.
- New starters take weeks to get useful because the knowledge is in people’s heads.
- One person is the only one who knows how something works, and their holiday is a risk.
- Support replies contradict each other, or contradict the help centre.
- Answers exist, but in five places: old documents, chat threads, email, a wiki nobody updates.
How to start one
Most internal knowledge bases fail the same way: someone sets up a wiki, writes a structure of empty pages, and it’s out of date within months. Start small and from real questions instead.
- 1
Collect the questions people actually ask
Go through a month of team chat, support escalations and new-starter questions. List every question that came up more than once. That list is your first table of contents.
- 2
Write the top twenty answers
One short article per question, titled the way people ask it (“How do I issue a partial refund?”), with the answer in the first paragraph and the details after. Twenty good articles beat two hundred empty headings.
- 3
Give every article an owner
A named person, not a team. Show a “last reviewed” date on each article so readers know whether to trust it.
- 4
Answer with links
When a question has an article, reply with the link, not the answer. When it doesn’t, the person who answers writes the article. This one habit does more than any tool.
- 5
Review on a schedule
The most-read articles monthly, the rest at least twice a year. Delete or merge what’s no longer true: a smaller knowledge base people trust is worth more than a large one they don’t. Our guide to keeping a knowledge base up to date has a routine for this.
What makes people use it
Search that finds the answer
People search with their own words, not your titles. Search should match the article body as well as the title, and cope with “cancel” when the article says “end your plan”.
Being where the work happens
A support agent replying to an email won’t open a separate tool to look something up. The closer the knowledge base is to where people answer questions, the more it gets used.
Trust
One wrong answer and people go back to asking colleagues. Owners, review dates and a history of changes are what make an article trustworthy.
Short, focused articles
One question per article, answer first. Long pages that cover everything about a topic are hard to search and harder to keep current.
Tools for an internal knowledge base
There’s no single right tool. The main kinds are:
- Team wikis such as Confluence and Notion, organised as spaces and pages. Flexible and familiar. Notion can mark pages as verified, with an owner and an expiry date.
- Knowledge tools built around verification, such as Guru, where each card has someone responsible for re-verifying it on an interval.
- Dedicated knowledge base and wiki tools such as Slab, focused on writing and finding internal docs.
- Help centre tools with internal articles, which keep internal and public knowledge in one place. A good fit for support teams, since the internal notes mostly explain the public ones.
Shared drives and documents work at the very start, but search is weak and nobody knows which version is current. If your internal knowledge base is mostly for the support team, look for one that sits next to your help centre and inbox.