Knowledge Base

Overview

Creation, writing, and maintenance system creation of a 180+ article knowledge base to help with employee training.

 

Responsibilities: Design, development, maintenance, template creation, article creation, training on it

Target Audience: Agency employees 

Tools Used: HubSpot Knowledge Base

Client: Remotish

Year: 2019-2022

Problem

We started writing down our processes in the first year of business since we all wore so many hats and had so many different tasks and processes to remember, and we needed to standardize everything, We also needed a way to train new people, and more easily improve processes.

Solution

In addition to making task list templates in our project management system to easily repeat multi-step processes, we also started using the Knowledge Base tool in HubSpot to write out the processes with more context. As a HubSpot agency, we wanted to keep our team inside the tools they were using daily, as well as help them better learn part of the tools they might assist clients in using.

We used the knowledge base to write processes for our own tasks, so we didn't have to rely on memory, could more easily test and improve the process once we could see it, and could repeatedly run the process with fewer errors and more consistent, predictable results.

Once our team started growing, we would document our current process to hand off or delegate the work to the new team members, or to train them to run the process consistently as similar team members. Some of the standardization and consistency included a template for writing the process with a table of contents box at the top of the screen, constantly evolving categories as teams and responsibilities changed, a naming convention, and more.

Some of the triggers to create or improve documentation in the knowledge base included if we noticed a recurring issue that needed reminders or clarity, a recurring question people were asked, or a major one-time problem that could have been prevented with guidance on what to do.

We taught new team members about the knowledge base during onboarding, to help build a culture where knowing how to do something did not depend on seniority or tenure. This extensive documentation gave new employees a better sense of security or belonging. They knew they could self-service to find the answers, at any time of day, instead of waiting for someone to be available in real-time to answer the question. The articles were also useful for employees who were not native English speakers, where understanding writing may be easier to comprehend than verbal answers. Information was accessible and transparent across time zones, departments, and job levels. The new employee had a task to read through this knowledge base and become familiar with using it.

All employees were encouraged to contribute to the knowledge base for their particular role.

I completed a major 2021 project to improve our knowledge base, including: 

• • Re-organize/re-categorize as the leadership's roles were split into additional managers and departments by then
  • Standardize formatting 
  • Create an approval process where the team's manager approved the content and I approved the documentation quality/standardization
  • Update all articles, and archive them when appropriate
  • Create missing articles or help teams create them
  • Help teams know when to update wikis, assigning quarterly updates as recurring tasks, and encouraging real-time updates
  • Assign categories of wikis to other people to manage
  • Create the wiki_docs_processes Slack channel to communicate changes (and remind people that documentation exists)
  • Create a section of the weekly team meeting and the weekly internal newsletter to communicate important updates and reminders about documentation

A lot of the content in my current classes and blogs uses examples and learnings from creating a culture of documentation at Remotish.

 

Examples:

• Wiki article on how to create a wiki article - copied into a Google Doc and cleansed
• Wiki article on how to maintain the knowledge base - copied into a Google Doc and cleansed
• Onboarding slides about documentation, during systems training
• Other examples of Remotish wiki articles
  
  

Process 

1. Analysis: Researched the ways other companies did documentation and set up their knowledge base. I didn't find much information, which later inspired my creation of a course on this topic. Since we started writing our processes so early on, there wasn't much research involved beforehand, until the improvement project a few years later. 
2. Design: Decided on the platform and initial template.
3. Development: Created articles and had other team members test them for clairty and improvement.
4. Implementation: Several team members started making articles when needed, and then used the articles to do the work.
5. Evaluation: More and more people contributed to the wiki as more people were hired, and more articles were written as processes were created and repeated. There was no formal evaluation until an improvement project a few years after starting the knowledge base. The platform didn't capture many metrics that would be useful for evaluating the effectiveness of the training documents. We relied on qualitative feedback and also noticed if processes were run efficiently and producing the predicted outputs.
6. Continuous Improvement: Making feasible improvements on a regular basis if we noticed an inefficiency, change in process, or the process was not creating the predicted output. Documenting larger improvement feedback for the future, and continuing to improve and iterate. 

 

Results & Takeaways

We learned that we had to teach that the documents were  "living documentation" to encourage the appropriate people to edit them and to suggest changes and improvements, to ensure we remained flexible and innovative. Sometimes instead of feeling security and the stress relief of not having to remember each step of a process or risking errors, some team members may have viewed the wikis as rigid or intimidating, so we worked to fix that perception through education.

Self-reporting for the wiki improvement project in the Operations 2021 annual review:

Category	Score 0-3	Score Explanation
Use of tooling and processes	3	Wikis are processes! And we are maxing out the use of the wiki as a tool, we tried to do more reporting and assignment of wiki categories inside of HubSpot, but it is not possible.
Increased efficiency	3	Having the info about how to do everything, how everything works, how decisions are made, and more, is more efficient than someone asking someone for the info all the time or just not doing things in the same way over and over since they do not remember. Knowing the info is now correct and will be kept up-to-date will be more efficient so people can trust the info. Splitting responsibilities between team members should be more efficient
Increased data points	1	Hubspot is currently unable to do much reporting on the knowledge base
Impact on revenue	2	The efficiency should have a big impact on revenue, a few examples are making sure the sales process is smooth, making sure client onboarding and offboarding is done well, making sure employee onboarding is easier so our team ramps up faster to start earning or retaining revenue since they can find all the info they need to service or sell to clients in the wiki. Not a 3 since not all needed wikis exist and direct impact is hard to measure
Impact on number of leads	0	We do have a few public wikis but I don’t think they bring in leads
Impact on customer success	2	Consistently delivering a great customer onboarding, offboarding, and servicing in between, across all team members, is the only way we can improve our services and keep customers successful and happy and retain and upsell them. The team now has most of the tools to do this. Not a 3 since not all needed wikis exist and direct impact is hard to measure
TOTAL	12	The highest score possible is 18