Choosing and Building an Internal Wiki for Your Company

Employees spend 9.3 hours every week looking for information to do their jobs, according to research conducted by McKinsey.

And that was in 2012.

Employees have always had to scour archived email threads and disconnected documents to find critical company knowledge. These days, they also have to search for knowledge in chat tools like Slack and project management tools like Trello.

This makes finding shared knowledge incredibly time-consuming. It also makes it challenging to maintain company knowledge. As a result, work gets duplicated, employees repeatedly ask the same questions, and onboarding new employees is far more resource-intensive than it should be.

A dedicated internal wiki can streamline your team’s knowledge sharing and collaboration.

What is an internal wiki, and why does your company need one?

An internal company wiki is a dedicated space where teams store, find, and share critical knowledge. Think of it as your company’s long-term memory or internal knowledge base. Companies use wikis to document information critical to their business operations, including:

• Company policies
• Processes and procedures
• Common workflows
• Technical notes
• Training and onboarding materials

A company wiki minimizes repetitive questions and empowers your team to work autonomously. It also protects your company from attrition — wikis document knowledge that might otherwise be lost when employees leave.

Wikis also have a positive impact on company culture. Documentation forces employees to hone their writing — to convey their message clearly and concisely. Through clearer writing, you have clearer thinking, which improves collaboration and productivity.

Below we break down what to look for (and what to avoid) in your company wiki.

The core features your wiki software must have

Your company will customize your wiki experience to your needs. However, the features below are integral to your wiki experience. When choosing an internal wiki for your company, be sure that they contain these features.

Editor’s note: Throughout this article we provide examples specific to our platform, Slab. However, the information should be easily applicable regardless of the internal wiki tool you choose.

Your wiki should work with the tools your team already uses

Your team already collaborates and shares knowledge in chat tools like Slack, project management tools like Trello and Asana, and document editors like Google Sheets. As a result, your shared knowledge is scattered across a handful of apps. Your team has to constantly switch tools just to access important company knowledge.

While an internal wiki can help, the reality is that some of your team’s critical information will continue to live only within the confines of tools that aren’t your wiki.

For example, your design team might use InVision, which allows them to comment on designs. Those comments likely won’t make their way into your team wiki — despite possibly being of value to other teams. By choosing the right tool, your design team can embed that InVision file into your wiki. That way it’s easily accessible by other teams and becomes a part of your team’s history.

Choosing a wiki that integrates with your existing tools makes it easy to consolidate your company knowledge.

The search function should be powerful and robust

A powerful search function makes it easy to find content without searching through folders (or topics, which is what we use at Slab).

At the bare minimum, your wiki’s search function should be as fast and intuitive as it is with Google.

Take the search function in Slab, for example. Teams use Slab to store, organize, and share critical knowledge in one dedicated space. They rely on our platform to help them find exactly what they’re looking for — fast. That’s why when you click on the search bar in Slab, we reveal your most recently viewed posts — because chances are the post you’re searching for is one you’ve recently visited.

We also have Faceted Search, which allows you to narrow your search. For example, here’s how you’d find references for the term ‘writing’ in your Product topic only:

Plus, when you search in Slab, we also show you results from your connected accounts, including Slack, Google Workspace, Confluence, and Dropbox.

A fast and powerful search function isn’t just a way to minimize the hunt for knowledge. It’s also a positive user experience for your team – meaning they’ll be more likely to use and contribute to your wiki.

The ability to create dedicated team spaces

Internal wikis knock down information silos that naturally occur within any company that has multiple teams. But teams should still have their own dedicated space within your wiki.

With Slab, teams use Topics for this (other wikis use folders). Engineering teams have their own dedicated topic, as does Marketing, and so on. Each team can create nested subtopics, too. For example, your Brand team and Growth team could each have their own dedicated subtopic inside the Marketing topic.

Regardless of what it’s called, these dedicated spaces should make it easy to get the right knowledge in front of the right people, at the right time.

A way to keep content accurate and updated

Some wikis make it difficult to determine if your content is updated and accurate.

Look for a wiki that clearly shows key information like when a post was last updated and who is responsible for it.

Your wiki should also allow real-time collaboration editing, meaning multiple people can simultaneously add and edit content without overriding or causing duplication.

Can you use Google Docs or Dropbox Paper for your company wiki?

Google Docs and Dropbox Paper are among the most widely used tools for companies of all sizes. Teams create and collaborate inside these tools — so it makes sense to attempt to use them for your team wiki.

But writing apps like Google Docs make bad internal wiki tools for a number of reasons, including:

Poor organization

Document editors use a standard folder concept to store and organize content. This makes it hard for teammates to know where to find and store information.

While you can add descriptions to a Google folder, that description isn’t always easy to find. Compare that to Slab topics, where descriptions are clearly displayed:

Too many formatting options

Documentation should be simple and straightforward. The more formatting options your team has, the more burdensome the documentation experience becomes. When everyone can format posts however they want, you end up with an inconsistent and confusing wiki experience.

Search is just a second thought

When you have fewer than 10 people in your company, finding documents inside Google Docs isn’t too complicated. But as your team scales, and more people contribute to your internal knowledge base, you’ll discover the limitations of these document editors.

Google Docs and Dropbox Paper aren’t designed to scale alongside your company. Rather than start off with Google Docs and migrate to a dedicated wiki, most teams find it better to adapt to a team wiki from the start.

Which leads us to the next question: self-hosted or cloud-based proprietary wiki?

Self-hosted (or on-prep) vs. cloud-based wiki

Should you host your wiki or subscribe to a cloud-based solution?

Self-hosted wiki. You can host your company wiki on your intranet, server, or online hosting service — if you have the budget and resources. The benefits of a self-hosted wiki include:

• You own all your data.
• You can create a wiki experience that matches your exact needs and specifications.

But a self-hosted wiki eats up engineering resources. It’s typically best-suited for teams with very specific needs.

Cloud-based wiki. Platforms like Slab allow you to build an internal wiki without dedicating massive engineering resources. You can be up and running within one business day.

The trade-offs are:

• You’ll have a recurring subscription cost for the service.
• The wiki you choose may not perfectly suit your needs.

Building your internal wiki

It may sound like an ancient Zen Koan, but a wiki isn’t really a wiki until more than one person contributes to it.

Still, before you onboard teammates, we suggest you create at least a work-in-progress information architecture. This ensures there’s an established method of organizing company information before you and others start adding content.

1. Setting up your information architecture

What your information architecture will look like will depend, in large part, on which wiki solution you choose.

In Slab, information exists in two ways: topics (which are like folders) and posts (which house the content itself). So if your team uses Slab, your information architecture is how you organize your topics.

We recommend creating topics (or folders) for:

• Company. Use this for company-level information, like all-hands meeting notes or quarterly progress reports.
• People/HR. Use this for company policies, benefits information, employee handbooks, etc.
• Teams/departments. You can create a top-level topic or folder to contain individual sub-topics for each team — this will work better if you have a larger number of teams. If you have fewer teams, you can create top-level topics for each team.

As you decide how to organize your team wiki:

• Focus on clarity. Everyone on your team should be able to navigate your wiki easily — not just those who set it up. Get multiple sets of eyes on your architecture to make sure it makes sense broadly, and that everyone will know where to look for information.
• Give teams flexibility. Allow each team to construct their topic or folder in a way that makes the most sense for how they work. A structure that fits one team’s workflow might not fit another’s.

2. Import and add content

Once your architecture is in place, you can add content to your internal wiki. If you have existing documentation (like in Confluence, Notion, or Google Docs), you should import this content into your new wiki before you officially launch. At Slab, we make it easy to import content from a variety of tools, as well as from markdown and HTML files.

You should also add any critical new content into your wiki before your official launch. A few posts that teams frequently launch their company wiki with include their employee handbook and a guide to navigating their new wiki.

3. Set up integrations

As we mentioned earlier, your team likely uses a handful of tools to store important information. Instead of replacing these tools, we’ve found it more helpful to your team to integrate these with your knowledge base.

Consider what information should live in your wiki, and what information should be connected to it. Some content deservedly belongs in a tool other than your wiki. For example, engineering teams that use GitHub can sync markdown files and embed issues and pull requests from GitHub to Slab. That way, they can continue using GitHub for their workflow while easily contributing to their company wiki.

4. Map out your launch

Now you can plan your launch. You’ll need to make a crucial decision: will your initial rollout be to one team or the entire company?

1. Team-specific. If you decide to launch your wiki to one specific team, that team will have the chance to dive into the product and start building out their own information architecture. Then, as you expand to the rest of your company, the original team can provide valuable insight and guidance.
2. Company-wide. If you decide to launch your wiki across your entire company at once, make sure that everyone is familiar with your approved knowledge base management process. Otherwise, it’s best to start with a single team. We recommend appointing team ambassadors for company-wide rollouts. They’ll become product experts and can lead the charge within their individual teams.

Launching your wiki

Once you’ve planned your rollout, designed your information architecture, imported your content, and set up any integrations, it’s time to announce the rollout to your team.

This is an especially important step because it sets the tone for how the rollout will proceed.

Your announcement should introduce your new wiki to your team, explain why you are using it, and clarify the expectations and next steps each team member should take.

If you’re rolling out to a single team first, it may help to organize a training session to demonstrate your wiki’s features.

If you’re rolling out to your entire company, you likely won’t be able to conduct live trainings for everyone. Still, we recommend investing time with your appointed knowledge ambassadors — it’s important to set them up for success so that they can empower others to be successful!

Below are two example emails you can adapt for your announcement, one for a team-specific launch, the second if you’re launching your wiki company-wide.

Team-specific launch

Hi all,

We’re excited to announce the launch of Slab as our new internal wiki! In an effort to improve our documentation practices, we’ll be using Slab as our source of truth for team knowledge. It’ll help us ensure that we keep our content accessible, fresh, and useful.

Your team has been chosen to lead the charge — you’ll be getting set up on Slab first! You’ll soon receive an email with instructions for creating an account. Please do this by DATE

From there, we’ll be holding training sessions to start learning the ropes. You can sign up for a session here.

We’re looking forward to building our team’s long-term memory together! 💪

Best,

Rebecca

Company-wide launch

Hi all,

We’re excited to announce the launch of Slab as our new internal wiki! In an effort to improve our documentation practices, we’ll be using Slab as our source of truth for team knowledge. It’ll help us ensure that we keep our content accessible, fresh, and useful.

We’ve designed our new information architecture and have begun importing existing documentation. We’ll continue to build it out as time goes on — this is where you come in!

You’ll soon receive an email with instructions for creating an account. Please do this by DATE. Look out for another note from your team lead with the next steps for creating content in Slab!

If you have any questions, please reach out to your team lead. We’re looking forward to building our team’s long-term memory together! 💪

Best,

Rebecca

Your shared knowledge is an investment

Your company’s internal wiki isn’t just a place to store vacation policies. Your wiki helps foster a culture of writing and knowledge sharing.

But which wiki you choose matters. Choose a wiki that makes documentation seamless and straightforward. No one should have to jump through hoops to contribute their know-how and expertise.