KCS prescribes a specific structure or format, which provides context for the content, improves the readability of the KCS article, and promotes consistency.
Any situation or issue can be broken down into the following categories:
Issue (sometimes called symptom, question, or problem)—the situation in the requestor's words. What are they trying to do or what is not working? Everything in the issue statement is resolved when the resolution is applied.
Environment—what function, process, products, platforms, geography, categories, or topics does the requestor have an issue with? How is it configured? Has anything in the environment changed recently? These are the necessary environmental factors for experiencing the issue. The environment statements will be true before and after the issue is resolved. It is the richness of the environment statements that help us find the specific article we need. It enables us to find the correct resolution when the issues may be very similar but the resolution is different. Issue statements can often be vague because they are the customer's perception of what is happening. Environment statements should be precise. Environment statements are one of the key enablers in findability.
Resolution (sometime called the fix or answer)—the answer to the question or the steps required to resolve the issue.
Cause—the underlying source of the issue. (optional, typically only valuable for complex problems or defects)
Metadata—attributes or information about the article. For example the article's visibility, confidence, governance, date created, reuse count, modification history, and the date last modified.
By capturing the information in this structure at the start of a request, we are creating as we go. This is also the information we should be using to search the knowledge base for known articles. We reduce issue resolution time and ensure that new KCS articles build on and integrate with existing knowledge.
Ideally, as we work on the issue, we are capturing information in the correct area of the KCS article. This should replace the way we take notes today (on paper or electronically). Most of us capture key points while we are talking to the requestor, especially if we have a sense that this is a new issue. We want to take notes in a Work in Progress article for a few reasons. First, if an article about this issue doesn't exist we are creating it as part of the process. Second, we are capturing our notes in a readable, standard structure. And third, if someone else is working on the same or similar issue they are likely to find the Work in Progress (WIP) article; we can avoid redundant work and collaborate on solving the issue.
Once the issue is understood and the resolution is known, we review the content captured and refine the environment statements to be sure they are relevant. Relevant environment statements are critical as this is how we distinguish this article from another with similar symptoms but a different resolution and cause. If appropriate, we update the cause field.
The most important benefit of this simple structure is it improves readability and usability. Also, some search technologies can take advantage of structured content to improve the relevance of their search results.
For self-service, the value of the KCS article may be improved by including links to specific sections of other documentation relevant to the issue or the resolution. Links to supporting information can help us write articles to the expertise level of the general audience. Those who are novices can follow the links for more information, while those who are knowledgeable in the area will be able to use the article without wading through documentation on things they already know.
We discuss KCS article structure and KCS article quality in more detail in the Content Health section.
For this technique, the key point is that consistent, simple structures help with readability and findability, and simplify the process of creating new articles or modifying existing articles. As we start the KCS journey, we want to keep the structure as simple as possible and let our experience drive improvements to the structure. Similarly we do not want to start with lots of different templates for different types of articles. Start with one, keep it simple, and let our experience drive the need for additional templates.