Technique 4.1: Use a Simple Template

KCS prescribes a specific article structure, 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? Issue statements can often be vague because they are the customer's perception of what is happening. 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? Environment statements should be precise, and will be true before and after the issue is resolved; these are the necessary environmental factors for experiencing the issue. Environment statements are one of the key enablers in article findability. 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.  
• Resolution (sometimes 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 audience, confidence, governance, date created, reuse count, modification history, and the date last modified.
• Title —the main issue + the main environment. The article title should clearly relate to the article's content and indicate to the requestor that this article is relevant to their issue. 

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.

Structure helps readablity for both humans and machines.

Ideally, as we work on the issue, we are capturing information in the correct area of the KCS template. 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 (or in structured, searchable case notes) 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 for humans and machines. For more details on KCS article structure and KCS article quality, see the Practice of Content Health.