How to create an internal knowledge base

You probably already have an internal knowledge base, you just don't know it yet. That's because it's spread across your docs, your Slack channels, and whatever your team reaches for when neither of those has the answer.

So building an internal knowledge base is mostly a consolidation job, not a writing job. Here's the order to do it in.

What is an internal knowledge base?

An internal knowledge base is a private, searchable library of the information your employees need to do their jobs: standard operating procedures, HR and IT policies, onboarding material, product documentation, and the troubleshooting steps your support team reaches for on a call. Unlike a customer-facing help center, access is limited to employees and approved stakeholders. Its purpose is to let someone find an accurate answer without interrupting a colleague.

Step 1: List the documents you already have

Ask each team lead for the ten documents their team opens most often. Going for the top ten rather than everything they have ever written keeps the list small enough to actually finish, and the documents nobody opens are the ones you were going to archive anyway.

Put those documents in a spreadsheet with four columns: document name, author, last updated, and duplicate. Fill in the duplicate column carefully, because two versions of the same process are exactly what you are here to fix. Migrate both and your new knowledge base launches already contradicting itself, except now the contradiction is the official one.

Sort every row into one of three piles:

• Still correct. Move the document into the knowledge base unchanged.

• Correct once, wrong now. Rewrite the document before it moves, or you have shipped a wrong answer into a system people are about to start trusting.

• Never written down. Somebody will have to write this article from scratch.

Start with the pile that was never written down, because it's the only one that leaves when the person does. Sit with whoever does the task and watch them do it. If you ask them to document their own version instead, you'll likely get an article that is crisp but full of jargon, because people skip the steps they stopped noticing years ago. It's your job to own that and fill in the blanks.

Stop when you have covered the fifteen to twenty questions your team asks most often. You can add more later, and you will.

Step 2: Decide where your internal knowledge base lives

Internal content can either sit inside the help center you already run for customers, with permissions deciding who sees what, or live in a system of its own.

If your readers are mostly support and success staff, put internal content in the help center you already run and control access with permissions. Your agents get one search box, and you maintain one system. A single help center also stays cheaper to keep accurate as you add tooling, since Pageloop and most tools like it connect to one help center at a time.

If the content is HR, legal, or finance material with access rules attached, use a separate system and accept that you now maintain two.

Step 3: Pick one way to organize your categories

There are three ways to organize an internal knowledge base.

• By department. HR, IT, Legal, Support, Design. Fastest to set up. Breaks when a topic belongs to two teams, or when the org chart changes.

• By role. New hires, engineers, managers, support agents. Good for onboarding, since someone in week one gets a path instead of a directory. Gets messy as roles blur.

• By question. Expenses, laptop and access requests, time off, escalations. Closest to how people actually search.

Organize by question unless you have a reason not to. Question-based categories survive reorgs, and they match what people type into the search bar.

Name each category the way someone would ask for it. A category called "Getting access to a tool" finds its reader. A category called "IT Service Administration" does not.

Keep the top level to six categories or fewer and put everything else one level down.

When an article belongs in two categories, file it in one and link to it from the other. Pasting the same article into both categories creates a maintenance problem, and you will hear about that problem from whoever followed the stale copy.

Step 4: Set up permissions and owners

Set permissions before anyone writes an article. Adding permissions to a knowledge base people already use means re-checking every article by hand.

Decide three things:

1. Who can publish without review. Usually two or three people per category.

2. Who can draft and suggest edits but not publish. Usually everyone else.

3. Who can read which categories. Set read access per category rather than per article, or you will be adjusting permissions forever.

Then check the four groups that catch people out: contractors, new hires before their start date, anyone in a region with different data rules, and people who changed teams but kept their old access.

Then give every category a named owner, rather than a team or an alias. An article owned by an alias is owned by nobody, and it will sit wrong for a year before anyone notices. If your tool has a review date field, fill it in while you're there. There's more on ownership models if you're splitting ownership across a growing team.

Step 5: Decide what to leave out of your knowledge base

• Anything already published to customers. Link to the external article instead of copying it. Two copies means one of them goes wrong and you won't know which.

• Meeting notes. Notes record a discussion rather than answering a question, so someone searching for the decision has to read the argument that led to it.

• Vendor documentation. Link to the vendor's own page, which stays current without you.

• Drafts and proposals. Anything that isn't how you do things today is noise in the search results.

• Screenshots of screens you control, unless the interface is hard to describe in words. Screenshots go stale faster than the sentences around them.

Step 6: Check your knowledge base after 90 days

Pull three numbers. Most help center and wiki tools report the first two under search or content analytics, and the third you get by asking your team.

Searches that returned nothing. Failed searches are your content backlog, written by the people who needed the answer. Work down that list by frequency.

Articles nobody opened. Archive them. Unopened articles make your search results worse for everything else.

Questions still going to Slack. When someone asks a question your knowledge base already answers, either they couldn't find the article or they didn't trust it. A findability problem is fixed by renaming the article and its category. A trust problem usually means the article was wrong once and somebody remembers.

Chase the trust problem down first. Self-service runs on trust, and trust goes quickly. Someone who follows an outdated article into a mistake goes back to asking a colleague for months afterwards, and tells their team to do the same.

Once the knowledge base is live, knowledge management stops being a project and becomes a standing job (yup sorry it doesn't end here). Check out our Knowledge base maintenance guide which covers how to maintain your knowledge base.

FAQ

What are some examples of internal knowledge bases? An IT help desk with troubleshooting guides and access request steps. An HR hub with policies and onboarding checklists. A support agent knowledge base with escalation paths and product detail. An engineering wiki with runbooks and architecture notes. Companies usually run several of these at once, which is what makes the structure decision in step 3 harder than it looks.

How can I create my own knowledge base? List the documents that already exist, decide whether the knowledge base sits inside your help center or in a separate system, pick one way to organize the categories, set permissions and named owners, then publish the fifteen to twenty articles that answer your most repeated questions. Expand once people are using it.

What is an internal knowledge base? A private, searchable library of company information for employees: SOPs, policies, onboarding material, and internal product documentation. Access is restricted to staff and approved stakeholders, unlike a customer-facing help center.

How do you get people to actually use an internal knowledge base? Answer questions with a link instead of a paragraph. When someone asks in Slack, reply with the article rather than retyping the answer, and write the article first if it doesn't exist yet. Two or three weeks of that trains people to search before they ask, which no launch announcement will do. If a question comes up that the knowledge base answers badly, fix the article in front of them and send it again.

Photo by Birmingham Museums Trust on Unsplash
Snowdon From Pernsarn, 1872 By Charles Thomas Burt