How should you structure your knowledge base?
Imagine this: you've finally done it! You've created a dedicated knowledge base for your company and you're ready to put an end to the chaos of scattered documentation. You step into your fresh, clean workspace and think, "This is going to be awesome!". But then, a big question hits you: how on earth should you structure your new knowledge base?
Don't worry, you're not alone. This is actually the number one question we hear from new users at Slite. And our answer? A somewhat disappointing "it depends".
But after helping over 200,000 different teams, publishing our ebook in collaboration with renowned knowledge managers, and studying our most successful customers, we do have some ideas about how to go about setting up a solid company knowledge base structure.
Consider the process of constructing your new knowledge base as utilizing a GPS. To identify the most suitable route for you and your company, we must first understand where you are going. Take a moment to envision the future. How do you see knowledge management at your company one year from now? What are the current obstacles you like to eliminate, and what would the ideal situation look like?
Once you know where you're going, you can start gathering the requirements. A good way to start is by identifying the different groups of people who will use the knowledge base and what content they should have access to. Then, you can connect the user groups with the relevant content (or vice versa). Looking at the areas where they overlap will help you choose the right structure.
When it comes to structuring your knowledge base, aka creating the channels in your Slite account, there are two main options to consider. You can either choose the classic departmental approach or opt for a more flexible subject-based approach. Each approach has its own advantages and disadvantages, and we will allow you to decide which one suits your needs best.
To maximize success, we strongly recommend involving stakeholders from various departments within the organization for the setup of your knowledge base. It is important to avoid the common mistake of investing significant time in designing a flawless knowledge base, only to discover later that it fails to meet critical requirements and will not be embraced by your team.
And don't forget, establishing a solid structure for your knowledge base from the beginning is crucial, but it doesn't mean the work stops there. Keep in mind that a knowledge base is a dynamic entity that will evolve with your company. It's an ongoing process that requires continuous iteration; a knowledge base is never truly "finished".
A helpful perspective is to view your knowledge base as a thriving community garden, or exploring how other teams are doing it to understand if you have common needs, for instance Commsor has a structure for their documentation but also for their Q&A .
To address all these challenges we've also built the AI-powered Wiki Generator that just by answering a few questions it gives you a tailor-made structure.
I've been in B2B SaaS for the past 7 years, setting up and leading Customer Success and Support teams. I'm a big advocate for good factual documentation, to allow folks on my team to be their authentic selves while working with customers and approach challenges in a way that fits them.