You’re probably familiar with the feeling. Maybe it was on your very first day at work, or the last time you were promoted. You find yourself facing a completely new scenario which no amount of training has prepared you for. Your colleagues aren’t there, and you can’t find information on what to do anywhere. You feel the impostor’s syndrome setting in, the floor suddenly swaying beneath your feet. Are you in over your head?
Of course, this feeling is usually temporary. Eventually, you will find yourself mastering the tools — everyone does. But if you’re leading a team, this can be hard to manage. Everyone adapts to a new role or process at a different pace, and in the meantime, a lot can go wrong. This is where a good knowledge management system can make a difference.
Why should you do it?
It enables everyone in your team to excel in record time
When you first arrive at a certain position you will be faced with two sorts of knowledge: the canonical and the informal. The first refers to adapting to all the procedures — it’s important that all processes, playbooks, and instructions are set in place, and it’s the first thing you should do. A lot of information can easily slip through the cracks, particularly when you work in a fast-paced, multi-disciplinary environment such as a start-up or a fast growing company, where a big share of your time goes towards solving unforeseen obstacles that have an unpleasant tendency to just pop up. What’s more, if you’re growing your team, whether in number or coverage, or seeing people moving on to other roles, you will quickly need to onboard new recruits and have a reliable source of truth for excellent performance, always available and up-to-date.
A good combination of knowledge bases, guides and FAQs will equip all team members with the appropriate tools to be fast and precise at all times to delight your customers, by avoiding wrong solutions, providing a great level of detail in their support, and finding the best ways to address the most common situations in the shortest amount of time.
It doesn’t just exist in someone’s head
Structuring all this basic knowledge frees your team from wasting time chasing down information they need, time they can focus on building an actual relationship with your customers.
And while it’s important to have this first step in place, it���s often the informal know-how, the undocumented rules, the practices that come from experience and “common sense” that are a big part of daily activities that can distinguish your team and boost your support.
The problem with informal knowledge, those unreplaceable bits of know-how, such as experience in historical cases, informal conversations or simple things such as best practices, is that it’s always at risk of getting lost, when a member of your team is on holidays or has moved on. It’s important to avoid this by turning informal knowledge into structure one — if you catch some presentation on a tool or feature, if you hear advice on best practices that aren’t in the reading material or on the helpcenter for the tool provider, carefully gather this information in the knowledge repository, and use screenshots whenever necessary.
It shines light on any blind spots
The best part about building robust knowledge repositories is figuring out how much it’s missing. Questions raise answers that raise questions that… you see where I’m going with this. The more processes, playbooks and walkthroughs are known and documented, the more apparent any gaps or spots with room for improvement will become. In our case, as I started putting together our knowledge repository, I realized that, across our product suite, there were some common features in products where the information was very rich, but in others it was virtually non existent.
Ensure that knowledge is structured thoroughly and that you keep everyone engaged by constantly updating contents and sharing news and changes, and they will soon be your best allies in guaranteeing that all knowledge is up to date. The more your colleagues see the results and how it makes their lives easier, the more engaged they feel.
It benefits everyone
It’s not just the support team that reaps the benefits of an organized knowledge base. The entire company can benefit as a whole. If you are working in customer support, you will find yourself with a lot of dependencies at hand. If all the processes are well described, there will be a significatively smaller number of escalations, reducing the workload in other areas and leaving room for priorities.
The escalations will also increase in quality — they’ll inevitably be more detailed, including information that all the different teams involved will appreciate. Instead of escalating issues to the engineering team only to have them pointing out the missing information in the report, or engaging in pointless back and forth with the customer, setting up the right troubleshooting questions will make the whole process a lot more efficient and greatly reducing resolution time. This will make communication a lot easier, and make everyone’s experience in the workplace a lot more positive.
How you can implement it
Once you decide to implement a knowledge managing process in your support team, you need to figure out how to compile and structure all the scattered information and create a detailed plan from the very start.
You’ll likely find that several tools will already be in use by all these teams, whether as knowledge repositories, or simply containing important historical information on processes and use-cases. Before you start, ask your team members how they work and explore and get to know the tools they use so you can understand what has been done before, and what the system currently is.
When I started the process, I created a spreadsheet where I gathered information about the key questions and topics (in our case, the expected behaviour of a certain integration setting), and then I read everything I could get my hands on about that specific integration. I found answers to those, and once I had a comprehensive list of questions and topics, I’d crosscheck the information, eliminate duplicates and complement with extra information whenever possible.
These are some of the questions you should be asking:
- Are the same processes described in multiple sources, and is the information complementary or contradictory?
- What are the most frequently asked questions, the issues that keep coming up? What kind of bugs are identified more often?
- Do you find that, once you establish those key questions, there is no consistency? Are some instructions missing in a feature but not the other?
It might seem like an exhaustive and time-consuming task, but if you skip this step you might be risking building knowledge repositories that will be incomplete, imprecise, or, in the worst-case scenario, irrelevant.
Our Customer Happiness Knowledge Base follows a very simple but effective structure. When it comes to products, we have a small description of the product and what it’s purpose is, we list how-to-use articles that gather most of the frequent questions and how it works articles where we add information that is a bit more descriptive, and then we describe a few key processes — troubleshooting, quality reporting, etc.
For example, one of the topics we added was when we found that one of our customers was using a third-party app to add a specific type of content to their email translations. This required a lot of back and forth between our team and the developers’ to provide the customer with very specific instructions. Although this was a custom-made solution, a different customer can always come up with the same idea, so if this is documented, the support team doesn’t need to start the whole troubleshooting process from scratch.
There’s no one-size-fits-all system, so rather than sticking to any ideas of what a knowledge system should look like, let this new information you’ve gathered determine the direction you’re going to take.
Always be on the lookout
One thing about being a knowledge manager is that if you’re carefully listening for it, you’re bound to pick up on those informal bits of information that are weaved in your company’s M.O. Pay attention and ask your colleagues what they do in specific situations.
Managing knowledge repositories is a never ending job, especially when it comes to updates — processes keep changing and products are always evolving. Even though feature releases or version updates are documented, when you’re providing technical support, new scenarios always arise, no matter how small the changes are.
Be ready to anticipate and investigate any new issues and questions that come up by paying close and continuous attention to all the communication channels you have access to. Maybe the feature that’s being released holds the key to solving a situation flagged in the past, so if you have a detailed register of all feature requests and issues, you’ll easily connect the dots.
This is not a one-person job
Even though you might be assigning a single person to the task, such as I was, doing a good job out of managing knowledge requires constant contributions from the people around you. There is only so much bandwidth a single person can provide. Include the people on your team in the process as best you can by engaging with them regularly, either through training or refreshing sessions, or just by communicating to the team how their input influences the process.
Make it crystal clear that their constant feedback is extremely welcome, and when they reach out to you, just accept and acknowledge their expertise, and give them credit for it. If your colleagues believe their contribution has an actual impact, they’re likely to start doing it more often, and their inputs will be invaluable in keeping your content and tools up to date.
Creating a knowledge managing system involves a lot more than just creating an easily accessible and reliable source for excellence in customer support. It is an opportunity to nurture your team into higher levels of performance, build stronger interpersonal ties and help set your team’s tone of voice. And at the very least, it’ll make it easier for all those overwhelmed newcomers trying to find solid ground to stand on.
The post Here’s why your support team should have a knowledge manager appeared first on Unbabel.
