Support Desks handle many of the complaints, issues and problems that your customers experience working with your products. They are on the front line when it comes to customer satisfaction and that all important NPS value. But not every support desk agent can know everything, so this is one reason why knowledge bases are essential. In this article we will think about some of the factors influencing how you get started with a knowledge base and how you grow it efficiently.
Types Of Knowledge Bases
In broad terms, here at Knowldege Tek we consider knowledge bases to fall into one of two camps. Knowledge that is freely available to your customers and knowlege that you intend on keeping internal. There is often a natural reaction to categorise knowledge as being internal, when in fact with careful curation you could release more knowledge to your customers which may be beneficial. Why could it be beneficial? Well, if a customer can self-help themselves then it may deflect them from raising a support ticket with your support desk at all. Every support ticket has costs associated with it, so if you can remove them from being created at all, then you are saving time and money for your agents. It may well also increase the customer satisfaction levels as they have the help they need quickly.
In The Beginning
One of the first indicators of a need to build a knowledge base is the realisation that somebody has built one already. These come in all sorts of formats, but the keeper of them is a support desk agent or supervisor who is typically overworked and a font of all knowledge. They are the people who have created log books, personal notes, diaries, folders on a hard disk with a multitude of files in them or simply have a large bookshelf with piles of books located behind their desk.
Problems With Ad-Hoc Knowledge Bases
The problems with this ad-hoc gathering of knowledge though are that:
- The content often not properly curated or organised. It’s just how the individual threw it together over time.
- It’s often not indexed, so finding information is difficult.
- It’s localised – i.e. not accessible by remote teams of people or customers
- In all likelihood, it’s unaccessible out of business hours or when the star agent goes on holiday.
- It’s not in a format that can be just given to a customer, so needs transposing if it is going to be used (which may introduce errors).
- It cannot be used to deflect the raising of a support ticket in the first case.
- It will be inconsistent when compared to eLearning or classroom training courses that your instructional designers and instructors may be delivering.
- It may not be the advice that a product manager or subject matter expert may want to give, i.e. it hasn’t been checked, reviewed or subjected to any kind of quality process.
So, something needs to be done. But what and how do you go about it? We have come up with seven simple steps to building your internal and external knowledge base and using it to deflect support tickets and increase customer satisfaction.
Seven Steps For Knowledge Bases
Step 1 – Review Your Support Desk Software
There are heaps of tools out there that help drive your support ticketing infrastructure, examples such as ZenDesk, Freshdesk, SalesForce ServiceCloud, LiveAgent, Zoho Desk, etc. In all likelihood you will have one in place already that allows tickets to be raised, tracked and managed. Perform a review to see if they support the creation of a knowledge base and if that knowledge base can be searched by customers and used to deflect support tickets being raised at all. If your software cannot do this, then it’s time to change.
Luckily, many tools are now provided in the cloud and allow you to start trials and switch relatively quickly. If your customer service is going to get better then this is a task that you’re not going to be able to avoid.
Here at Knowledge Tek we can recommend Freshdesk as a good all-rounder that’s worth a look at and that’s well proven in the field.
Step 2 – Review Your Content Authoring Methods
If you are going to populate a knowledge base with information, then you’d better make sure that you can build that content quickly, efficiently and to a high quality. You need an authoring tool that incorporates workflows and automatic version control. If your products are software based, then you need object recognition. Regardless of your products being software or physical, then you will need the content you build to be availble in different formats, e.g. eLearning, training manuals, knowledge base articles, quick reference guides etc all need to be created once, edited once, reviewed once and then output in whatever format you need them to be in, so you can re-use them in your knowledge base, LMS, classrooms, EPSS or wherever. Depending on your business, you may also need to translate this content into local language.
Here at Knowledge Tek we partner with TT-S and can recommend their TT Performance Suite incorporating TT Knowledge Force and Quick Access as a solid content authoring platform that supports multiple output types.
Step 3 – Start To Build The Case For Change
You are not going to be able to do this on your own. As a minimum start talking to support desk supervisors, senior agents, instructors and trainers, training managers, subject matter experts, product managers and anybody else who you deem to be key. Highlight where the improvements can be made and how the establishment of a knowledge base can be beneficial to the business, not just for the support desk but also for other areas. Leverage the content authoring tool as a way of reusing content that is built once in different ways. The workflow driven approach means that no one person becomes overloaded. Quality will increase as reviews become easier. The tool GUI will be adaptive so it’s easy for everybody to use and collaborate together with. Suggest running a proof of concept and see if people are open to that idea. Highlight disgruntled customers and investigate the reasons behind their issues. Could a new method avert disaster in the future?
Here at Knowledge Tek we recommend building the case for change from the bottom, going upwards, rather than trying to force change from the top, going down.
Step 4 – Proof Of Concept
Start demo or trial accounts up with the support desk software and content authoring tools of choice. Make sure that the knowledge you create in the authoring tool can be easily leveraged in the support desk tool. Key tests are:
- Does it import?
- Is it indexed by the knowledge base properly?
- Is it free text searchable?
- Can it suggest content to the customer when a ticket is being raised, based on the content of what is being put into the ticket BEFORE the ticket is submitted?
We recommend sharing the results of the proof of concept with everybody – even if the first trial you run doesn’t work and give the results you expect. Create trial accounts for people to access the tools and hold some meetings/webinars showing them what there is.
If you want an out of the box solution, then let us know and we can do a demonstration of it for you.
Step 5 – Seek Approval To Go Ahead
Get your costs together. Work out a high level project plan for implementing the new tools including training people on how to use them. Involve your purchasing teams and contracts people if needed. Get the management team on board.
This is often the hardest step, but with sufficient ground swell of people behind you already and as you are presenting a way to go forward and solve a problem, not just whinging about it, you might be suprised with yourself. Be confident. Innovation is key in all businesses.
Raise your purchase orders and get the tools in place.
Step 6 – Implement and Pilot
For any software implementation there will need to be a fair bit up-front work to be done. E.g.
- Agents, SME’s, Reviewers, Authors, Editors and other roles need accounts to be created
- Product portals and support channels mapped out and built
- Branding and logos
- Workflows and content templates
- Training on tools and processes
We can do this for you, so get in touch with us.
Take a baseline if you don’t already have any data on how many tickets are currently being processed by the support desk. How long is being spent resolving each ticket? Are there repeating areas of issues?
Use this information to build content in the new authoring tool. Populate your knowledge base with this content and any existing content that is suitable for releasing to customers.
Once the configuration work is done we recommend running a pilot with a subset of customers or products. Based on how this goes some change will no doubt need to be made before a general release. But, this should give you a feel for if ticket counts are being reduced and time spent on a ticket coming down. Agents should be able to use the knowledge base to send solutions to customers without having to create bespoke solutions all the time.
You’re now ready to go live with a general release. Pull the trigger and go-ahead.
Step 7 – Build And Refine Knowledge
Incorporate the enhancement of the knowledge base into your business processes. For example, if you are making a software product, then for each release of the product ensure that you are creating knowledge in the authoring tool and continuing to populate the knowledge base. Review the articles that are best-received and see if they can be improved upon. Take out poor articles that are never used, or enhance them so they become more useful. Reward and congratulate the authors who are the best contributors. Survey your customers and see if there are any holes in the knowledge base that they would like to see filled. Analyse your support tickets to see if this sheds any light on other areas that need enhancing.
These are quite high level steps that we think most people will go through in one way or another when building an efficiently created knowledge base. Of course, there are other ways of doing this, but without efficient content authoring you’ll be slower to create the content and likely to fall behind product updates.
Read our case study on NAVBLUE about this topic.