Content Health begins with the content structure. A well-defined structure is a fundamental element of capturing knowledge value. With KCS, the support organization's experience, or knowledge, is captured in the form of KCS articles. KCS articles are transferable units of content that integrate the situation with information, analysis, and a resolution to form a standardized structure. KCS is a modular approach to knowledge. Ideally, KCS articles are a page or less in length. A given customer situation may use multiple KCS articles to reach resolution. KCS articles often contain links to other more formal or comprehensive information.
The right structure ensures that KCS articles in the knowledge base are findable and usable by the intended audience. Identifying the intended audience is important because the audience defines the context for the KCS article. Ideally, the target audience should be involved in creating and giving feedback on the KCS articles.
One of the key goals of KCS is to capture the context of the issue: the description of the needs and experiences of the customer in his or her own terms. To achieve both broad reuse and relevance, the reusable context for a given situation is contained within the KCS article and does not require an outside reference. (The complete context is also available via links to the cases that have reused the content.)
KCS recommends that KCS articles be presented in an easily skimmed way so that readers can quickly gauge relevance. These are the basic elements:
An example of the KCS article structure:
404 Error when accessing a website
Failed to connect to server
Internet Explorer 11
Microsoft Windows 7
Microsoft Windows 8
A forward slash was added to the end of the web address - that is specified as an exception in the proxy server.
Author: John Smith
Create Date: 14:15: 09-09-13
Modified Date:14:15: 09-09-13
This format and these content elements can work for procedures as well, not just product issues (questions and problems).
Typical case or incident records might also contain information that is customer-specific, such as entitlement and customer contact details. This information is necessary for the support process and is typically retained in the incident management system; it should not be included in the KCS article. The KCS article contains the reusable parts of the experience, not customer-specific or proprietary information.
Managers should note that structuring KCS article content requires explicit work to be performed that has not traditionally been part of the problem-solving process. There is an initial learning curve and start-up investment as content is created and the processes are mastered. Coaching is crucial at this stage. However, once reuse becomes possible and Solve Loop practices become second nature, this extra work disappears. The time invested to get "over the hump" will be more than compensated for by the time saved in the improved problem-solving process and increased reuse.
The resolution normally contains the answer to the question, a workaround, or a fix to the problem. If the resolution contains a multi-step procedure, a common practice is to number the steps.
Sometimes the resolution requires special tools, access, or skills that a customer reading a Published article may not have. Even if the customer does not have the resources to complete the resolution, it is best to inform the customer that the issue is known so they can pursue proper assisted service. Including guidance for obtaining service in the resolution field of the Published article can help the customer contact the support center and provide relevant information to the Analyst to minimize diagnosis.
Adding an "Internal Resolution" field in the knowledge article provides a place to capture a resolution that requires Agent assistance. The "Internal Resolution" field is not visible to customers even on Published articles.
The Cause field is optional as not all issues have a cause (or the cause may not be known). For example, "how-to" articles never have a cause, unless you'd like to blame the customer for not knowing the answer.
If the cause of an issue is known, it should be added to the knowledge article. This can be used to distinguish between two knowledge articles with the same issue description which are actually two different problems. For example an issue of "I can't print" may be due to the printer being out of paper, out of ink, paper jam, or a number of other potential causes, each requiring a different resolution. When searching the knowledge base and multiple articles are found with similar issues, the cause within each article can be used to verify which problem exists for this reported issue.
An additional strategy of value to consider is to add an additional field related to the Cause field, called "Cause Test." In the "Cause Test" field will be the procedure or description of how to validate the cause. The customer or Analyst can then use this test to confirm that the issue they have matches the knowledge article and will then have confidence that the resolution will address the issue. For example, a cause of "Out of paper" may include a cause test describing how to check the paper level in the printer.
A simple, high-level categorization of content can really help with findability, maintenance, reporting and other processes. Generally, categorizing content with a high-level area or product group does not take any extra time during capture and does not cut important results out of searches. KCS recommends some specific metadata to enhance a KCS article's structure and support reuse. Some examples are author, owner, date created, date last modified, number of times used, last modified, and life cycle state (discussed in the next technique). In addition, there are some specialty pieces of information that enable reuse by other engineers and customers, and even management metrics.
Organizations should feel free to add custom or optional fields to suit their industries or regulatory requirements.
A word of caution—sometimes people go too far, over-structuring knowledge with metadata. They try to put knowledge into buckets, especially to facilitate reporting. Unfortunately, this approach sometimes camouflages the knowledge because of the labels or categories chosen. These manually classified labels have proven to have poor search-ability—they do not correspond to the way customers describe their problems.
Predefined buckets also may limit a team's ability to detect patterns of use and linkages, an ability that becomes more important as a knowledge base grows. The good news is that tools have improved tremendously. Over the last five years, automated classification and search tools have made it much easier to organize content based on what that content is, rather than forcing it into predefined buckets.
Throughout this document, we have talked mostly about KCS articles presented as text. However, for an audience that is less technical, for how-to content, or for a product that has a complex user interface, we have found it more effective to include a picture or screen shot of the product or instruction. Visual images can bridge language gaps and overcome translation issues. Voice and audio clips are also increasingly common, both for ease of comprehension and for compliance with increasing regulatory requirements for accessibility. As more customers pursue web-based support, these multimedia formats are increasingly critical and beneficial in speeding resolution.
The KCS methodology and processes remain the same, but the knowledge base and support delivery tools should be adjusted to include multimedia content. Multimedia content creation is, ideally, captured during the Solve Loop, and refined after the incident is closed. This area continues to evolve, so refer to www.serviceinnovation.org for potential additional guidance.
Many companies are missing an important source of knowledge, customer knowledge. Customer knowledge can be captured in two ways. The first is to simply allow customers to contribute directly to the knowledge base in the same way the company employees make contributions. When the article is created, it is visible internally. As the article is reused and therefore reviewed, it is moved closer to the customer.
The second way that customer knowledge can be captured is to capture the search statements being used by customers as they search the company knowledge base. Self-service users can ask questions and submit an incident online. The search history and articles viewed are stored with the incident. The Analyst launches the knowledge base to find answers; the field for search question can be passed to the knowledge base from the incident and used to populate a section of a new article each time they search. The advantage of recording the customer's search words or phases is that we are capturing the customer context directly from the customer. We can further analyze the search words and phrases for commonalities such as "burn to cd," "burn onto cd," "burn cds," "burning cds."
Another source of knowledge for Analysts and customers to use is knowledge from other vendors made available in the knowledge base search. Many knowledge applications allow indexing and searching other web-based knowledge, but care should be taken with those other sources. The same criteria applies to another company's content as was discussed in linking to non-KCS content internally: