As the pace of product releases accelerates and customer expectations continue to rise, service and support organizations are challenged to keep up with an ever-expanding pool of knowledge in order to do their job effectively. No amount of training seems to prepare service and support techs for the variety of questions and failure scenarios they will meet in the real world.
One common solution is to build a knowledge base – a repository of documentation that describes common scenarios and how to diagnose/resolve them. It sounds like a great idea. Build it and results will follow. But, the reality is not that simple.
The project begins by purchasing and configuring the necessary technology. I.e., a system to store and present the knowledge. It then involves hiring one or more people to write and curate the knowledge. Some organizations try to make knowledge development a part of the job of the support team, but this inevitably gets squeezed out by the pressure of responding to one trouble call after another. Even so, there is cost in having someone(s) to write, edit, and curate the articles. And then there is the need to make changes as corrections are found, better methods, product changes. It’s never ending.
Let’s say you establish a working system and have filled it with 30 or 100 articles. Now what? You hope the support and service techs will refer to the documents when they need them. How do they know what is in there? Did you expect them to read and remember all the different articles? Are they expected to find articles using search? Even if they find an article, it might be about a similar (but not the same) machine or have lots of extra information that causes more confusion than help.
Given these headwinds, how do you measure success of the knowledge base? You know the monthly spend on technology and staff. Where is the improvement in call resolution times, trip avoidance, first-time fix rate, etc.? Even if you know how often articles are accessed, how do you know if they are helping? If you can’t match costs with return, you can’t determine an ROI…
Knowledge bases aren’t bad, but they may not be the best way to help your support team accomplish their mission of helping customers. RevTwo approaches this problem in a different way that makes it easier to capture, share, and measure the impact of knowledge within a support or service organization.
With RevTwo Navigator, the users are the ones submitting knowledge as they do their job. When they see an issue, they enter the diagnosis and repair steps by speaking into their mobile device. This knowledge is immediately available to other users who can modify the procedures or add helpful comments. When users are working through an issue, Navigator uses machine learning and analysis of previous incidents to present the steps in the optimum order to reach a resolution.
Enabling users to submit their own knowledge and comments makes them more invested in the solution as they see the virtuous cycle of social knowledge sharing.
Navigator is a living system that is always learning and can be instantly updated. No more waiting for service bulletins or new knowledge base articles to make their way out into the world. Because the knowledge is shared in bite-size nuggets in the right sequence and context, it’s ideal for outside service organizations or even for customers to do self-service.
Back to ROI. Navigator includes analytics that let you track how many issues have been solved and what procedures (called steps) that users followed to get there. You can see where people got stuck. Or where a few extra questions might have made the process faster or used a less expensive part. You can also input cost information so the system will lean toward recommending lower-cost procedures first. This integration of knowledge, doing, and resolution provides everything you need to monitor and realize the ROI of your knowledge management investment.