Earlier we discussed the complementary processes of the Solve Loop and Evolve Loop. Each loop generates important knowledge by considering KCS articles at different levels. To recap, Solve Loop articles are created and improved by knowledge developers (licensed Support Analysts) while they are resolving incidents. At the time Solve Loop content is created, it is difficult to judge how important or valuable it may be, but if a problem is worth answering or solving, it is worth capturing in the knowledge base for others to reuse and to contribute to the patterns or clusters that emerge in the Evolve Loop analysis.
Ideally, Solve Loop articles are developed just-in-time based on customer demand. Solve Loop articles should follow the content standard so that the articles have a common structure and are findable and usable by the intended audience.
In contrast, Evolve Loop articles are high value articles. These articles are usually created by Knowledge Domain Experts based on patterns and trends in the Solve Loop content. Evolve Loop content is considered to be of higher value because it is derived from the patterns of use, the clustering of KCS articles around a common theme or issue, and critical processes and procedures. Evolve Loop content generally represents a very small percentage of the total KCS articles in the knowledge base.
The usage and pattern analysis performed in the Evolve Loop also identifies product quality and serviceability improvements. By analyzing the root causes and aggregating symptom and usage frequency data, the Knowledge Domain Expert can assemble compelling data (especially business justifications) to drive product or documentation changes based on the customer experience.
Some examples of Evolve Loop content include:
Procedural KCS articles or step-level processes (how to do a specific thing)
Resolution paths—a collection of linked procedural KCS articles that defines a complex process (procedural or diagnostic)—created by Knowledge Domain Experts to address generic or high level symptoms, especially ones that are addressed in an unwieldy number of Solve Loop KCS articles
High impact issues (ones that cause outages or pertain to new or strategic products)
KCS articles created to fill gaps in the web-accessible knowledge base—that is, based on web demand rather than support center demand
A primary goal of the Evolve Loop processes is to learn from the collection of activity and content created in the Solve Loop. This promotes continuous improvement of the KCS system on many levels. In order to make sense of the thousands of articles that are typically created in the Solve Loop, it is helpful to consider the content in subsets or collections of related articles. These subsets of the knowledge base are known as knowledge domains.
Knowledge domains are virtual collections of KCS articles about a product family or a technology or group of technologies. Knowledge domains are seldom about one product. They are not precise or absolute in their boundaries; knowledge domains often overlap. A knowledge domain is the collection of content that makes sense to review for pattern and clustering analysis. Therefore, the purpose or intent of the analysis defines the collection of KCS articles that is relevant.
For example, if we perform root cause analysis to identify product improvements, the collection of KCS articles that relate to the product family or technology is the knowledge domain. If we want to provide an account team with a profile of a customer's experience over the past year, the collection of KCS articles for a specific customer's cases is the relevant knowledge domain.
We see some predictable phenomena in looking at knowledge domains for product families or technologies:
The frequency distribution for the reuse of KCS articles is always a power curve—the 80-20 rule applies to KCS article reuse. In many organizations, up to 80% of KCS articles will rarely or never be reused. Of the remaining 20%, some will be reused much more often than others.
Within a knowledge domain, customers most frequently experience failures in a limited number of ways, perhaps five to seven high-level generic symptom categories (for example: can't connect to the internet; PC won't boot; cannot access hard drive)
Generic or common symptoms have diverse causes—each of the five to seven common failure types has multiple possible causes and therefore different resolutions
Some common causes will show up in diverse and seemingly unrelated ways—a single cause and resolution will be experienced by customers through very different symptoms
The challenge for the Knowledge Domain Expert is to look for clusters of KCS articles that have the same or similar causes or resolution. Commercially available data mining tools are very effective because we can point them at structured statements in the KCS articles (a little bit of structure to content provides a lot of value). Another way to identify high value content and the issues to focus on is to have an algorithm that measures the value of the KCS articles to the organization. A calculated value is based on attributes of both the KCS articles and the related cases. Things like frequency of use, severity, type of problem, impact of the problem, type of customer, and importance of the product can all be considered. The algorithms can become quite complex.
Root cause and value analysis are complex and evolving areas where many Consortium members look to experts for assistance. There are great commonalities in content trends when we look across support organizations. This is an area of considerable industry activity. Some technology vendors are delivering rich analytics with their KM tools. Consultants such as OutSights, Inc. and DB Kay & Associates have helped to define these processes (see paper on Normalization at www.outsights.com) and David Kay and Francoise Tourniaire's book, Collective Wisdom: Transforming Support with Knowledge, provide some direction on this topic (see the Reference section).
When we examine KCS article reuse, we often find that a single symptom (or a small set of common symptoms) can emerge from multiple, diverse causes, each of which requires different resolutions. For example, "cannot connect to network" could mean anything from a hardware or software failure to user error. The symptom experienced by the customer is insufficient to identify the correct resolution. Additional information is required, possibly necessitating diagnostic steps to identify the distinguishing characteristics of the failure in order to provide the correct resolution.
A diagnostic step can be captured as an article, and a collection of steps or KCS articles linked together creates a "resolution path." OutSights, Inc., has refined the concept of the "resolution path" in their work with a number of Consortium members. (See References for more information.)
This approach is very powerful, because the resolution paths are made up of KCS articles (diagnostic steps or procedures) that can be reused as appropriate in multiple resolution paths. And, unlike diagnostic trees, where the Support Analyst has to start at the beginning and work through each step independent of what they know about the situation, the article structure allows the Analyst to enter the diagnostic process based on what they know about the problem.
A frequency distribution showing reuse of KCS articles is one way to identify common symptoms. The analysis of the heavily reused KCS articles coupled with the Knowledge Domain Expert's knowledge about the domain brings to light the common or generic failure symptoms. The Knowledge Domain Experts then create the Evolve Loop articles that support the Analysts in determining the distinguishing characteristics that will point them to the correct resolution. While it is the responsibility of the Knowledge Domain Experts to do the analysis and create the Evolve Loop articles, it should not be done in isolation. The Knowledge Domain Experts should validate their observations and resolution paths with a cross-section of the Support Analysts who work in the domain.
First, the Knowledge Domain Expert identifies a cluster of Solve Loop KCS articles that relate to a generic symptom. This identification must be done from the customer perspective; how they experience the issue is what counts. For most domains, there are a limited number (5-7) of generic symptoms. The Knowledge Domain Expert then looks to understand the process by which the distinguishing characteristics of the situation can be identified, en route to the right KCS article. The Evolve Loop content will eventually describe the diagnostic process in the form of a procedural KCS article or a collection of procedural KCS articles that are linked together.
Each step in this diagnostic process is itself a KCS article often created in the Solve Loop. The resolution path (the collection of linked procedural KCS articles) stitches these pieces of knowledge together. Computer programmers might think of this process as a series of "if..., then..." steps and the procedural KCS articles as reusable subroutines.
From a KCS article structure view, the problem and environment information includes the distinguishing characteristics needed to take the next step. Resolution information describes how to do the procedure. Each possible outcome or result of the procedure will point the user to the next step in the process. Eventually this sequence leads to a KCS article that contains the resolution or workaround.
Different users may experience a single problem in very different ways. Despite a common cause, users see diverse symptoms. This situation would be likely in a software environment, where different hardware and software combinations might cause the same application glitch to behave in different ways—poor performance in one case, but system crash in another. Situational variables might disguise the common cause.
When a cluster is identified, the sum of the reuse counts and the value to the business for the collection of KCS articles should be considered in prioritizing the issue. The Knowledge Domain Expert should also decide if the articles should be merged or linked. The key criteria to consider here is findability for the audience that the article serves. While merging the articles has many advantages for the ongoing evolution of the article and aligns with the "one article, one fix" concept, situations can exist where it makes sense to have multiple articles for the same issues, perhaps linked together.
If the symptoms and environment are dramatically different, merging the articles would decrease findability for each respective environment. In this case, the articles should remain for each unique environment, but should be updated to be procedural. They should include ways to validate the situation, and the resolution field for each should point to an article that contains the resolution. As the resolution is used and improved, it is updated in one place.
Another type of Evolve Loop content is articles that fill content gaps in our self-service model. Customers' use of self-service introduces some interesting dynamics:
Customers will use a good web site to solve problems they would not have called the support center about. Demand for support is far greater than the number of incidents that come into the support center.
When customers use the web, there are issues they will not solve, but they will still not submit an incident
Unsolved customer issues represent gaps in the knowledge base (an article does not exist) or findability issues (a KCS article exists but the customer could not find it)
Part of the Knowledge Domain Expert's responsibility is to identify content gaps on the web through web analytics that captures search strings. If possible, they should create articles that resolve customer issues that were pursued on the web and not resolved. They could also refine existing articles based on how the customer was searching for the answer—this improves the findability.
The Evolve Loop content processes are critical for continuous learning, innovation and improvement. They leverage the Solve Loop content, create incremental value for support, and help to integrate the support organization into the overall product development lifecycle.