The Impact of New vs. Known Issues in KCS

As you walk through the service desk, you overhear a support analyst say, “That was a new issue.” If you are like most problem solvers, you must learn more. You want to know what the issue was and how the analyst resolved it. You might want to know out of curiosity and also to be informed just in case it happens again.

This is the core concept of capturing new knowledge. Someone has just resolved a new issue and others want to learn about it. While they do not need to learn about it just-in-case, the analyst needs to capture the new knowledge so that others can learn from it just-in-time. By capturing the new issue and resolution as a new knowledge article, the analyst is converting it from a new issue to a known issue. When another analyst receives the same issue, they first search the knowledge base to see if this is a known issue. When they find the new knowledge article, they read it and learn about it just in time to help their customer.

When an incident is resolved, and the ticket is closed, it should be linked to the knowledge article that documents the issue and the resolution. All tickets can automatically be assigned to one of three categories when they are closed based on the knowledge article linkage.

1. Known Issue
2. New Issue 
3. Unknown

Let’s explore the meaning and value of this categorization.

Known Issue

Before a support analyst attempts to solve an issue, the incident management process dictates that they must first seek to understand what is known by the organization. That is, they are to search the knowledge base to see if the issue is known and has been previously resolved. Reusing the knowledge article will save the analyst time, reduce the mean time to closure, increase first contact resolution rates, reduce the cost per ticket, and increase customer satisfaction. The customer will receive a consistent answer to their question, independent of which support analyst is helping them because the answer is known to the organization and available to all support analysts.

Reusing the knowledge article will save the analyst time, reduce the mean time to closure, increase first contact resolution rates, reduce the cost per ticket, and increase customer satisfaction.

In a mature Knowledge-Centered Service (KCS®) environment, the percent of tickets classified as known should be between 65%–85%. If the process of seeking to understand what is known before seeking to solve (i.e., searching the knowledge base) is consistently followed by all members of the support team, then the first contact resolution (FCR) rate should directly correlate with the percent of tickets that are classified as known. And the more the organization knows, then the higher the FCR.

As additional tickets are linked to the knowledge article of the known issue, the reuse counter is increased. This linkage can be used to document the frequency of the known issue and indicate the need for a problem record to be created and investigated.

New Issue

Tickets are classified as a new issue when a new knowledge article is linked to the ticket. Since an existing knowledge article could not be found to address the issue, the support analyst is responsible for investigating, diagnosing, and resolving the issue. To the organization, the customer is the first to experience and report this issue and the support analyst is the first to resolve it. It is also the responsibility of the analyst to capture the knowledge they just created as a new knowledge article. The knowledge article was created as a byproduct of resolving an issue for the customer.

For an issue to be known, it must have been captured as a knowledge article. If individual analysts have personal knowledge that is not shared in the knowledge base, then the issue is not known to the organization. The loss of knowledgeable staff can result in the loss of knowledge by the organization. Thus, the best practice is to capture new knowledge within the incident management process before the ticket is closed.

Unknown

When the issue is resolved and the ticket is closed without linking to a knowledge article, the ticket is classified as unknown. While the issue and resolution may have been captured in the ticket, the knowledge is not available in the knowledge base to benefit the organization.

Unknown implies knowledge loss. While knowledge was created to resolve the issue, it was lost to the organization. If the same issue is reported in the future, costly rework will be required for the next support analyst to investigate, diagnose, and resolve the issue.

Unknown also implies that the desired incident management process was not followed. At least the portion of the process that adds new knowledge articles to the knowledge base was not followed. Sometimes, the support analyst may claim that creating new knowledge is outside of the support analyst’s control. This is usually when the ticket is escalated to level 2 or even level 3 support staff. In this case, the resolution process may not have been provided to the service desk by the support partner. While the improvement process is to persuade support partners to participate in the KCS practices, the support analyst can still minimize knowledge loss by creating a new knowledge article. The new knowledge article will document the issue, and the resolution documents the appropriate escalation process. This issue becomes known to the organization and requires escalation to resolve it.

To learn more about the KCS methodology, HDI offers two KCS certification courses.

New vs. Known Analysis

The KCS methodology promotes a continuous improvement process known as the new vs. known analysis. The percent of new vs. known vs. unknown can be trended and monitored to evaluate the maturity of the KCS practice adoption. The following chart displays a 12-month trend.

There will be a higher rate of new vs known early in the adoption because the knowledge base is initially empty. When the journey begins, only a portion of the team is following the process of searching and using knowledge for every ticket. As a result, there is a high rate of unknown. The percent of unknown will drop as more are trained and coached to follow the process. The percent of new issues tends to stabilize as the processes mature. This ultimately represents the true rate of new versus known issues reported to the service desk each month. When the known issues become the majority of the tickets, significant value is being realized. In addition to the improvements in incident management, problems will be identified to problem management.

The analysis of the ticket volume leads to continuous improvement.

• As the organization matures, the unknown percentage should become minimal. Evaluating the unknown can identify where coaching is needed or the expansion of the KCS practices to additional support partners is justified.
• Evaluating the new issues can help to identify common sources of new incidents and failures in new products or services released.
• Evaluating the known issues can identify the need for problem management to investigate the cause and develop a permanent fix that will eliminate future incidents.
• As self-service knowledge is introduced and becomes increasingly used, the percent of tickets for known issues will decrease and the new issues will increase. This is due to the shift of resolving known issues from assisted service to self-service.
• Workforce management can more accurately forecast resources and staff schedules based on the knowledge from the new versus known analysis. New issues tend to take longer to investigate, diagnose, and resolve. The skillset requirements for support staff will be higher for staff handling new issues.

The analysis of known vs. new can be done at the individual level as well as the team level. This chart looks at four different members of the service desk, all with the same role and responsibilities, over several months.

• Rachel appears to be following the desired process. It took her a few months to learn and adapt to the new integrated knowledge and incident management process. Her total ticket volume has increased, and she is receiving about 20% new issues. Her coach should praise her participation.
• Rose has learned to use the knowledge base to resolve tickets most of the time. As a result, her ticket volume has also increased. She is rarely contributing new knowledge. Her coach should review how to contribute knowledge and why contributing is important. You would expect all analysts with the same roles and responsibilities to have a similar new issue percentage.
• Robert contributes a lot of new knowledge and rarely finds existing knowledge. It appears that Robert may not be searching for knowledge and the knowledge he is using is likely his own. Robert is doing more harm to the organization than good. It is likely that his contributions are duplicates. His coach needs to address this urgently.
• Ralph is not following the process. He may need to be retrained and the organization’s expectations restated.

The new vs. known analysis, when trended, shows you if your organization is maturing in its process adoption. At the individual level, you can quickly see which individuals are following the process and which need coaching. When every member of the team is following the process, then the unknown will be minimized, tickets with known issues will be responded to consistently and efficiently, and tickets related to new issues will result in the capture of new knowledge. 

KCS is a registered service mark of the Consortium for Service Innovation.