What happens when a veteran employee moves on?
Besides their skills and experience, they take with them valuable technical knowledge about systems and technology—losses no sensible business should accept. This is why many organisations are increasingly looking to build simplified knowledge bases to serve as internal repositories of best practices, resources, or ‘how-to’ guides on the many IT-based processes, business logic, and issues employees—or remote teams—face daily.
Knowledge bases are touted as the cornerstone of ITSM, the catalyst to IT self-servicing that would unburden today’s helpdesk teams. Ironic, since building and maintaining a knowledge base project itself can be time-consuming for IT teams, unless done right the first time! Here are three rules I consider essential to building knowledge bases that will generate greater value—and usability—down the line.
Rule 1: Make it simple and intuitive for the average user
The first step to building a knowledge base is deciding the right format for your intended audience: the average user. IT pros might be tempted to replicate the information flow and documentation formats of their Git repositories. The layered complexity of this format, however, may overwhelm the average user, who would sooner give up than learn how to navigate it. As non-developers, it’s simply not worth their time and effort.
Instead, take inspiration from popular formats of knowledge bases already used by today’s online communities. Think Wikipedia, for instance, or the intuitive support pages of user-friendly websites. Collaborate with your UI/UX designers to work out an intuitive and sensible information flow, prototype it, then test and iterate where necessary. And when the real build goes online, continue testing every assumption or page workflow, during onboarding or deployments of new software solutions, for instance.
Rule 2: Establish maintenance protocols beforehand
Building was the easy part. Management and maintenance of the project, however, is a long-term commitment that often blindsides the unprepared. IT teams should plan forward and establish these measures below, that would significantly lower the effort and resources required to maintain and update the knowledge base later:
Create a familiar back-end interface: The front end may need to be simplified for the average user, but the back end of your knowledge base can be the same GitHub interface IT pros feel at home with. Alternatively, employ a vendor service desk solution with an intuitive interface designed for IT pros. This hybrid approach allows technicians to commit changes, deploy new features, and maintain the knowledge base without having to waste precious time learning new workflows or processes.
Employ a dedicated team resource: Make no mistake, maintaining a help desk knowledge base is a full-time job by itself. Most IT teams today employ technical writers with specific skill sets that allow them to efficiently manage, curate, and update the knowledge base. Specifically, these writers know the entire knowledge base content library like the back of their hand, and are familiar with a majority of IT terminologies and concepts—allowing them to create ‘how-to’ articles to complex processes and technologies both IT and non-IT folks can easily understand.
Establish timely update plans: Things move quickly in the business world, and every month sees new processes, workflows, and software being introduced to support expansion and growth. Information can quickly become outdated and pose a security or stability risk to business operations. Ensure you create a structured process to update your knowledge base, which considers the frequency of updates, plus any questions or concerns raised during UAT or group tests of any newly introduced solutions.
Rule 3: Make it scalable, configurable and experimental
Knowledge bases could just be ordinary repositories of information and self-service portals, but they can be much more. I like to think of knowledge bases as places where you can trial new technologies or processes. Some things IT pros could try to include:
- Basic machine learning algorithms that can predict the context of a question with great accuracy. For instance, when someone searches “Can’t save my doc onto the network” and “Error saving Word to OneDrive” on the knowledge base, these are two different searches with the same problem.
- Enabling comments and annotation on knowledge base articles, so employees can highlight inconsistencies or suggest ideas to improve. This creates a DevOps-like feedback loop that gives busy IT teams enough information to plan and refine the knowledge base to perfection with every updated version.
- Multi-language capabilities, which are ideal if you’re a multinational organisation. Sure, you could manually translate the entire knowledge base, if it’s deemed an appropriate use of resources. Or you could use solutions with multi-language APIs to automatically do it for you.
However you chose to approach it, these threes rules will lead you closer towards a self-service knowledge base employees can turn to when they need answers. Management gets a solution that ensures valuable business information doesn’t vanish with every resignation, while the IT team faces less burden when it comes to technical support. Now that’s a win-win situation for everyone.