Striving for 100 Percent

Link Rate is a metric that is calculated by dividing the total tickets closed where the ticket is linked to a knowledge article, and the article was either used to resolve the issue or was added after the issue was resolved, divided by the total tickets closed for the same time range. Link rate is a knowledge management leading indicator related to maximizing value and improving the efficiency of assisted service within service management.

Because of its importance, some service management leaders make knowledge linking a requirement to close a ticket. Unfortunately, putting such a goal on an activity is likely to have a negative effect. Support staff may link for the sake of linking, thus corrupting the data and the value. Instead, the organization needs to strive for 100 percent and remove the barriers that prevent them from achieving it. The most common barrier is the lack of understanding. When a person does not understand the value of a practice, they are not likely to follow it. Everyone should know why an organization strives for 100 percent.

Striving for 100 Percent Logging

Ask any seasoned service management professional what the best practices recommend for what percent of incidents and requests reported to the service desk should be logged. The most common answer will be 100 percent. When you ask them what percent their organization logs, the answer will usually range from 90 to 100.  percent. While they strive for 100 percent, there are reasons why 100 percent may not be achieved.

One hundred percent was not always a best practice. When ticketing systems were first introduced to early help desks, support analysts would log 30–50 percent. The initial purpose of ticketing systems was to record the outstanding tasks, so they would not be forgotten. If an analyst was able to answer the customer’s question or resolve their issue on first contact, then there was no need to record it. The work was done. Early ticketing systems replaced the memo pads and pieces of paper to manage outstanding work. And when the work was completed, the analysts would simply mark the ticket as done. They did not record what they did to satisfy the need. There was no perceived value in doing that extra work.

As service management practices evolved, striving for 100 percent logging became a best practice. This occurred after the value of logging every incident and request became understood. Ask the same service management professionals, “Why is it important to log every contact?” They are likely to give you a list of reasons. They can tell you why it is important to record every interaction with a customer and capture the answer and resolution. Ticketing evolved into incident management and request fulfillment based on the innovations and experiences of others. As organizations shared their stories, others replicated their results, and best practices evolved.

Just because the practice is to log all incidents, that does not mean quality exists. Ticket monitoring, or incident monitoring, was introduced as a quality assurance process to verify that tickets were captured properly and to provide improvement feedback to analysts. Quality criteria for logging was developed to define quality, communicated to set expectations, and used to monitor the work of the staff. Coaching is then performed to improve the staff skills and ultimately the quality of logging and the customer experience. Recording the ticket as “Done” is no longer acceptable.

Striving for 100 Percent Linking

Knowledge management is on a similar evolutionary path. Initially, knowledge articles were made available to support analysts as an optional resource. The knowledge base was another tool for researching issues. Unfortunately, the usage was low, and the value of the knowledge was questionable. Most organizations struggled with knowledge management or did not formerly have a knowledge management process. And linking tickets to knowledge was non-existent.

The introduction of Knowledge Centered Service (KCS) by the Consortium for Service Innovation redefined knowledge management practices. Linking was promoted as a critical success factor. Technology providers delivered solutions that integrated knowledge searches and usage with their ticketing systems. With this integration, linking tickets to knowledge articles became possible. Linking is performed when using existing knowledge to resolve a ticket or adding new knowledge from a newly resolved ticket where existing knowledge could not be found. Unfortunately, linking is an activity that can be gamed. When measuring the link rate, it is important to update the ticket monitoring process to verify that linking is being done properly. This quality assurance check can identify if an individual is linking for the sake of linking instead of following the process properly.

The KCS v6 Practices Guide promotes “In general, a healthy link rate for an organization is in the range of 60–80 percent.” This indicates that the knowledge practices are being followed enough to sufficiently review and maintain the knowledge articles and that the review is being performed based on demand. So why strive for 100 percent when the guidance says 60–80 percent is good enough?

Why strive for 100% linking of incidents to knowledge articles when the guidance says 60–80% is good enough?

The chart below is an example trend chart that measures the link rate of each staff member in an organization over a six-month period. 
 

Why Strive for 100 Percent Link Rate?

Like 100 percent logging, there are multiple reasons to strive for 100 percent linking. You want your support staff to follow the same process 100 percent of the time, not 60–80 percent of the time. Analysts are expected to:

• Use knowledge if it exists—100 percent
• Flag it or fix it, if warranted—100 percent
• Add knowledge if it does not exist (and therefore develop new knowledge to satisfy the customer)—100 percent

Which of the above responsibilities would you consider acceptable for your team to do 60 percent of the time?

Just telling them that you are striving for 100 percent does not remove the barriers to adoption. You must define the process, enable the process with technology, and educate the team about the process and the expected benefits. There are several benefits realized when the process is consistently followed. Striving for 100 percent benefits the customer, the support staff, and the organization.

• Consistency of service. When every analyst reuses existing knowledge to answer questions and resolve issues, the customer receives the same service. Consistency of service is required to deliver quality.
• Efficiency of service. The knowledge articles contain the best resolution known to the organization at that time.
• Elimination of rework. When analysts don’t use existing knowledge to resolve issues, they must develop new resolutions or custom knowledge. They are expending effort to resolve issues that have already been resolved. Reusing knowledge eliminates rework and saves the organization time and money.
• Just-in-time knowledge sharing. You no longer need to email new procedures and answers to the support team just-in-case they get a call. Instead, update knowledge articles and trust that your team will find the updated procedure when they need it. This requires that everyone follow the same process of using knowledge for every call.
• Increased trust and confidence in knowledge. When knowledge is linked to a ticket, the reuse counter is increased. Views of an article only measures when someone opened the article. It does not imply that the article resolved the issue. Reuse, or linking, is done when the analyst validates that the article resolved the issue. Analysts are more likely to trust an article that has been proven to resolve previous tickets. If the search results list two articles with the same issue, one with a reuse counter of 1000 and another with a reuse counter of 3, which are you more likely to trust?
• Just-in-time knowledge review and improvement. Before a knowledge article can be used to resolve a ticket, it must be read and reviewed by the analyst. If warranted, they are to fix or flag the article for improvement.
• Reduce ticket documentation work. Linking a ticket to an article can automate the task of capturing the answer or resolution in the ticket. The automation can also include information such as ticket type, category, service, and other metadata that can be transferred from the knowledge article to the ticket. This saves time for the analysts.
• Improved ticket documentation quality. Automating the completion of a ticket using information from the knowledge article increases the quality of the ticket documentation. This improves ticket-based reporting and the information shared with customers. Customers who receive automated closed ticket emails or who view ticket status via a customer portal benefit from higher quality documentation.
• Reduced escalations and improved first level resolution rates. Level One Solvable (LOS) tickets should never be reported to level two if the service desk uses existing knowledge articles to resolve known issues. If you measure LOS, any such ticket indicates a failed search of the knowledge base.
• Improved escalations. Some issues require help from level two. Knowledge articles for these issues can define the proper triage steps and escalation process and set proper customer expectations. Analysts at the service desk who need level two assistance should be able to find and use a knowledge article that documents the standard operating procedure in support of every operational level agreement.
• Problem detection. Problem detection based on knowledge reuse replaces the costly and error prone ticket analysis. As tickets are linked to knowledge articles, the frequency and volume of the incidents can indicate the need for problem management to investigate the cause and develop a permanent fix.
• Improved data for root cause analysis. The process of linking tickets to knowledge results in a list of detailed incident tickets related to the knowledge article. By linking the knowledge article to the problem records, problem management has full access to the most current list of incidents related to the problem. As new incidents are reported, the linking of the article to the ticket improves the data for problem management.
• Justification for change. When a change request is submitted to the change advisory board, it can be accompanied with data that defines the historical frequency and volume of related incidents. It is the linking of tickets to knowledge and knowledge to problems that provides the source of this information. This information can be used to analyze the return on investment for implementing a change.
• Monitor changes. Once a change has been implemented, the status of the problem is updated. Any additional linking of new tickets to knowledge articles linked to the problem may indicate a failed change.
• Employee recognition. When support staff share their knowledge directly with their teammates, they receive immediate recognition and appreciation. This is lost when they share their knowledge through the knowledge base. In knowledge management, the employee earns citations when their teammates link an article they wrote to a ticket. Management can use citation reports to acknowledge the value employees generate through shared knowledge. The reuse counter and author’s name on a knowledge article contributes to the employee’s reputation within the team.
• Increased customer satisfaction. Customers are happier when they receive fast access to the right answers. It is faster to reuse knowledge than to re-create it for every incident. Consistency in answer is expected and if escalation is necessary, the ticket needs to be efficiently handled. Ultimately identifying and removing problems reduces the number of incidents the customer experiences.
• Increased employee satisfaction. Support analysts are happier when they can satisfy more customers more quickly and without the need of escalation. Analysts benefit when repeat incidents are eliminated. This enables them to spend their valuable time and talents on more challenging work.
• Reduce the cost of support per incident. Ultimately, eliminating rework, automating tasks, and reducing the time to resolve issues saves the organization money.

Now that you are aware of the potential benefits, what link rate will you strive to achieve?