Knowledge Management and Self-Service have been and continue to be key success factors and differentiators for any customer support organization. Having a solid knowledge management and self-service strategy will help the organization to:
1. Increase client satisfaction
2. Reduce service delivery costs
3. Shorten employee and customer on-boarding/training cycles
4. Reduce incoming service call volume
5. Improve first call resolution
6. Improve channel efficiency (if you have a channel of VARs or partners that deliver services)
7. Differentiation from competition
Many organizations have adopted various systems and methodologies and have invested significant amount time, resources and energy without reaping much benefits while others have succeeded. Why?
Every support organization that I have worked with has-in one way or another-a working knowledge repository filled with articles, how-to documents, FAQs, etc., but what I hear repeatedly from both customers and support agents is:
“… the database is too big and it is almost impossible to find answers in it. Some data is outdated or incorrect, and search results are so overwhelming and answer-sets so large that render it useless…”
So, what are the secrets to the development and implementation of a successful knowledge management and delivery machine?
1. Knowledge creation has to be a part of your culture!
It takes a very special breed of people to successfully work in service and support organizations. We like challenges, we thrive on the unpredictable nature of what we have to solve next, and above all, we like being the heroes and knights in shining armor who save the day!
The latter characteristic, which I call the “hero” effect, is the number one challenge to a successful knowledge-driven service organization.
“If everyone knows what I know, then I won’t be the hero anymore!”
Customer service organizations cannot just value and reward problem solving, quick resolution, and high first call resolution; rather, they must preach “problem elimination” and “no known problems” religiously.
Reward and recognition, both monetary and non-monetary also must be tied directly to knowledge creation.
2. Knowledge creation cannot be seen as a secondary unit of work
All support organizations use a ticketing or Incident Management system to document, report and track client issues and service requests. All Customer Support Representatives perform a significant majority of their work using these systems. The goals, as briefly stated earlier, are to solve problems and to close these tickets/incidents as quickly as possible and to move on to the next service request.
As such, knowledge creation (in terms of knowledge articles, how-to documents, etc.) is not seen as an integral part of the incident management process. Rather, it is seen as a secondary unit of work-something that we will do if we have time!
3. It is not the system/tool you use?
There are many systems/tools that are designed to house knowledge content and to expose it to clients/users in a self-service fashion. Unfortunately, many organizations focus all of their resources on developing or implementing a fancy system with impressive bells and whistles and yet still fail because the system in itself is not the primary success factor. Important and integral success factors are:
• How the knowledge is created
• How the knowledge is maintained
• The quality of the knowledge content
So, unless you have these three factors under control do not waste your money on a fancy system.
4. Your knowledgebase cannot be a static repository
Knowledge management is not a fire-and-forget process. I have seen a lot of organizations set up contests on who can create the most knowledge articles, hoping to create a sizable knowledgebase or to significantly increase the size of an existing one. End result is a sizable database of inaccurate, duplicate, unsanctioned, unstructured content.
A knowledgebase is a living entity that needs to be fed, maintained, and cleansed. Strict processes have to be in place to determine:
• What content is needed
• How content is created and validated
• How content is maintained and reviewed periodically and regularly
• How the content is accessed and used
• Does the content solve problems and achieve the 7 objectives I outlined at the beginning of this article?
5. Knowledge creation must be built around your workflow!
We discussed earlier how “knowledge creation” is often seen as a secondary unit of work. We also talked bout the fact that the organization must be able to measure and understand what content is needed, the quality of the content, and how successful it is in solving “repeated” problems.
The biggest secret in overcoming the challenges and in achieving the objectives I have outlined is to BUILD KNOWLEDGE CREATION DIRECTLY INTO YOUR INCIDENT MANAGEMENT WORKFLOW!
• If a ticket/incident is opened to track an issue, do not consider it CLOSED until your workflow has either identified an existing knowledge article that solved the problem or the need to create a new one. Note: those who are worried about their call closure statistics to be skewed by this suggestion can simply introduce a new status within the Incident Management system called RESOLVED.
• Design your system to track problem symptoms, root causes, workarounds, and solutions CLEARLY and in a repeatable and predictable format in every case/ticket/incident.
• Direct your customers seeking self-service to your knowledgebase first. Gather information on what they search for and capture it in the ticket if they are unable to solve the problem themselves. If the client is successful in solving the problem through self-service capture what the problem was and which article helped them solve it.
• Design your Incident Management system to support one-to-many linkages between support tickets and knowledge article.
• Configure your Incident Management system to automatically search the knowledgebase for related articles when a support agent is in the process of creating and documenting a new ticket. Have the system automatically document the recommended articles in the case.
No comments:
Post a Comment