Home > KCS v6 Practices Guide > Section 2 The KCS Practices > The Solve Loop > Practice 2: Structure > Technique 2.1: Use A Simple Template

Technique 2.1: Use A Simple Template

Table of contents
No headers

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.  

Viewing 4 of 4 comments: view all
Comment from Russ Brooks:
Agreed - keep structure simple. It should support and enable the "capture as you go" or "create as you go" or "modify as you go" process, not hinder it. It gives readers an expectation of what to find in other articles and lets them more quickly scan for what they are interested in when each article they read has the same structure
Posted 23:53, 14 Apr 2016
I find it's often useful to have multiple templates or structures available for different types of knowledge:
- Issue Resolution (Solutions, or Break/Fix)
- How To (or Best Practices)
- Q&A
I'm looking forward to the more information in Content Health, but I'd like to suggest that we replace the prescriptive language at the top with language that is more supportive of different templates for different purposes.
Posted 23:31, 26 May 2016
While there are benefits to capturing knowledge in a WIP article, there are also benefits to capturing it in a system of record--traditionally a CRM case record or an ITSM incident, but really anywhere where the work is happening. While we lose some ability to search for WIP in most cases, we gain transparency and visibility of the requestor to what the responder is saying. And, the details of how many of the tools out there work make this a more practicable approach.

As we've discussed repeatedly, as long as we're capturing and structuring in the workflow, we're gaining the benefits of the Solve Loop...no matter where the knowledge lives temporarily during the capture process. Edited 23:38, 26 May 2016
Posted 23:37, 26 May 2016
The opening statement about Environment, "what function, process, products, platforms, geography, categories, or topics does the requestor have an issue with?" would be be better phrased as "in what function, process, products, platforms, geography, categories, or topics does the requestor's issue arise?"

In a complex IT environment, requestors often have no idea what aspects of that environment give rise to their issue - they simply know what their issue is. It is the resolver's role to ask appropriate questions to determine what aspects of the environment might be involved, to establish the version numbers, etc., that are in use.

I also have concerns about the statement "The environment statements will be true before and after the issue is resolved." They tend to start as best guess and need to be revised as diagnosis and ultimately resolution confirms the initial perception.
Posted 03:08, 31 Jul 2017
Viewing 4 of 4 comments: view all
You must to post a comment.
Last modified


This page has no custom tags.


This page has no classifications.