The Ultimate Guide to Better Company Documentation Using Notion
December 6, 2022
Having a clear and organized internal knowledge base is crucial for any company, and at Prezly, we've been using Notion as our internal knowledge base since early 2018. After spending many hours refining our structure, we believe we've found the perfect solution. In this post, we'll share our structure with you and provide a template that you can easily duplicate for your own use.
Why is this important? Your internal company documentation is essentially the collective brain of your team. Without a clear and organized system, decision-making can become sluggish and confused. By having a great way to share and organize your knowledge, you'll be able to make quicker and sharper decisions.
- Onboarding: Running a software company involves many moving parts, and providing a way for new team members to understand these different parts on their own can be a huge competitive advantage. With a well-structured internal knowledge base, new team members can quickly get up to speed on the most important aspects of the company, allowing you to focus your conversations on answering their specific questions. The better your internal documentation, the easier your onboarding process will be.
- Redundancy: As your team grows, it's natural to divide responsibilities among different teams and individuals. However, this can also create the danger of having only one person who understands a specific aspect of the business. In some cases, it may not be economically feasible to hire redundant staff for these roles, which is why it's so important to have clear and comprehensive internal documentation.
- Cross-company collaboration: At Prezly, we've found that our best progress comes from having people from different skill sets work together on projects. While we have a typical team structure (sales, customer service, marketing, product, etc.), we believe that teams should never operate in isolation. Processes and decisions that impact one team often have implications for the rest of the company, which is why it's important to avoid storing knowledge in silos. This will prevent problems down the road.
- Start from the customers: When creating your internal documentation, it's important to remember that its ultimate goal is to serve your customers better. Processes and guides that don't have any impact on this goal will only add unnecessary complexity. On the other hand, guides and processes that are closely tied to the stages or segments of your customer journey will provide valuable context and clarity, making it easier to understand why a particular process or guide is needed (or what's missing).
With that in mind, let's take a look at how we've structured our Notion. We'd be happy to share our template with you, so please reach out if you're interested.
The general team space contains all of the cross-company knowledge that's relevant to everyone at the company. In addition to the handbook, we've added several other entities to create and share knowledge in a structured way. These entities are all Notion databases, which means they have a defined content structure and can be linked to each other (more on that later).
This is where we document the most important aspects of how we run the company, including our vision and mission, company values, onboarding information, HR guides, and more. Although we update these items periodically for clarity, they don't change often since they describe our core identity and beliefs.
Each year, we identify 2-3 main objectives for the entire company based on the biggest challenges we face. These objectives guide our focus and efforts for a longer period of time.
This is where we track the projects we're working on, using the Shape-up methodology for shaping and selecting projects. My co-founder has written extensively on how we've been using the Shape-up approach, important to note is that we do this also for marketing, sales and CS projects, not just for product.
This is an overview of the most important tools we use at Prezly. Guilty as charged, we probably have too many tools. It's one thing all new team members mentioned. But our tools are also essential for us to do our work, so we do see them as a crucial part of the business. This is why it's important to outline them all, and explain what they do and how we use them.
Guides & Processes
The internal guides and processes database is a structured way to create and share knowledge within the company. This database contains most of our company knowledge, as it is where we document guides and processes in detail.
Each guide or process includes a body of text that explains the steps involved, but we also use structured attributes to provide additional information. Some of the most important attributes include:
- Type (options: Guide, Process): We could have created separate entities for Guides and Processes, but we decided against it because they are very similar and a Guide may evolve into a Process. The main difference is that a Guide is an optional help article that teaches a colleague how to do a specific task. A Process, on the other hand, is a required and recurring set of tasks that are linked to a specific stage of the customer journey.
- Team(s): The team(s) responsible for owning this process or guide.
- Priority: The importance of the guide, with options such as "Need to know," "Best to know," and "Optional to know."
- Tags: Relevant tags for the guide, such as "Onboarding" for guides that are especially useful for new team members.
Overall, the internal guides and processes database provides a structured and easy-to-use way to share knowledge within the company. By using this system, we can ensure that our team has access to the information they need to do their jobs effectively.
Customer Lifecycle Stages
This is where it gets interesting since this is a structured database of all the defined stages a customer goes through when discovering, using, and paying for Prezly. It gives us a shared vocabulary to use within tools and documentation. All tools are aware of and use these Customer Lifecycle Stages in naming campaigns, processes, automations, etc.
Once you start digging in, you'll find there are so many different Lifecycle Stages, so start with the ones you want to focus on and expand from there.
A customer segment is a specific group of customers within a certain Lifecycle Stage. We create segments when we want to approach a group of customers differently or separately. Segments can be based on a customer's profile (Key Accounts), behavior (Unhealthy), or request (I want to speak with Sales). Every company uses customer segments, but documenting them for the entire team to see is often overlooked. This can lead to different teams using similar segments with different names. By documenting customer segments, we can create a shared vocabulary that's used across the company.
Highly efficient businesses often have many automations running in the background, such as tool integrations, email sequences for welcoming new users, billing automations, surveys for collecting NPS, playbooks, and reminders. Because these automations are spread across different tools, Lifecycle Stages, and teams, it can be difficult to get a clear view of what's happening with a specific customer or within a specific team. By documenting our automations, we can see exactly what's happening and where it's configured, as well as identify gaps in our process.
The Automations database includes the following information:
- Name and description of the automation
- Type (options: Sequence, Email campaign, Glue Code, Playbook, Survey)
- The tool used
- Status (options: Running, Broken, Idea, etc.)
- Configuration URL (link to the campaign builder, sequence, etc. within the tool)
- Owner team
By organizing our automations in this way, we can easily see what's happening and identify areas where we need to improve.
Relationships creating more context
If you've been reading the above, you'll think, Wow that's complex and seems like tons of work. And I don't disagree, but let me show you why it's actually worth it. The whole idea of having these different entities is that they can and should be linked to each other. That way, you can find what you're looking for more easily and through more different ways. Let me give you some examples:
- We have a guide that explains to everyone how to file a bug, which you can simply find by searching the notion or the Guides & Processes DB, but since it's linked to its related tools, you can also see it in the Linear tools page.
- We have a process on how to handle Renewing Key Account, which you can find through the "Guides and Processes" but are also discoverable through the Lifecycle Stage "Renewing Customer" and/or the Segment "Key Accounts".
- I can get an overview of all automations in place for messaging New Trials
This structure works since it gives you different ways of finding the guide or process you need. But at the same time gives you a higher-level overview of processes, guides, or automations you don't have yet.
The magic comes from the fact that your internal documentation evolves from a collection of guides into something of strategic value for your company. And once you see and can use it like that, you make everyone at the company smarter and better informed.
Keeping content up-to-date
The biggest issue we had, was keeping our internal docs up to date. The moment you write something, it is in danger of getting outdated. And the larger your content base the easier it is for stuff to get outdated. But how do you flag that something is out-of-date, unused, or broken?
We've solved this by giving all the above-described entities a "Status" attribute, which takes everyone 2 clicks to mark something as outdated, or not working. And since every entity has a team assigned to it, it's easy to ping those people in the comments to take a look and update.
As mentioned earlier, we believe that teams should never operate in isolation, so we avoid creating silos of knowledge. However, we do have dedicated spaces for each team where they can share information and collaborate on specific projects. This allows teams to focus on their specific tasks and responsibilities while still being connected to the rest of the company.
Although your teamspace can be yours with its own documents and databases, it is helpful to build out an overview that filters out all the company-wide content filtering on your own team. Which makes it easy to see what content, project, and stages are really relevant for you as a team. This is easily possible, since all entities have a "Team" attribute, allowing you to define the relevancy of a tool, lifecycle stage, guide, or process for a team.
Drafting in place
Lots of ideas you have, and processes you'd like to implement, can be added directly into this structure. This can become incredibly valuable because the structure creates context. Context can be helpful to see what is in place and which gap your new process, guide, automation, stage, or segment needs to fill.
This is really where Notion shines since it's a hybrid between a place where you do work and a place where you store work. And if you're smart you use this to your advantage. It's essential to evolve from a static documentation hub to a place where you share and work on new ideas for processes, guides, segments, and lifecycle stages.
There are 2 powerful ways how to do this:
- Keep your draft hidden for everyone except yourself. This allows you to work on it in pieces without it getting in the way of others.
- Share it with the status field "Idea" and use the comments to ask for feedback (similar to how we do this in Projects).
A growing company can get complex quickly, so you need a logical structure that handles this and can still work for you as you grow (not against you). Having a clear and logical collective brain is where it starts, so think carefully about this, since how you structure your internal docs does matter.
I've built this into a Notion Template, reach out if you'd like me to send it your way.