_(1).svg?revision=1)
Technique 3.2: Capture the Requestor's Context
With KCS, we seek to understand the requestor's experience before resolving. This understanding requires information about both the perceived issue (in the requestor's words) and the environment in which the issue is occurring. By capturing the requestor's perception of the situation in the first interaction, we dramatically improve the findability and relevance of the experience for other requestors who might have the same or similar perception of this issues in the future (context is as important as content).
The KCS Principle of Demand Driven says it's important that we capture what's happening now, not spend time guessing about other situations in which it might be relevant. Knowledge will evolve as it gets reused and updated by others.
Capturing the requestor's context - their words and phrases - improves findability for other requestors.
The objective of capturing in a structured way is to "frame" the situation—to capture need, perception, experience, and relevant aspects of the requestor's environment as input to the resolution process. We use this information to either improve an existing article by reflecting another requestor's experience, or to create a new KCS article if one doesn't already exist.
Even if the requestor's perception of the situation proves to be wrong, capturing it will improve the findability for others. The issue field belongs to the requestor. The responder's job is to capture with precision and accuracy the relevant environment factors, the resolution, and the cause, not to correct the requestor's description of the problem. However, responders may capture additional details to more precisely characterize the issue. Technical accuracy when describing the issue or symptoms is not required. Of course, technical accuracy is critical in the environment, resolution, and cause statements.
Capture Relevant Content
While we want the requestor's context in the article, we don't want redundant, long, non-relevant information about the issue. The goal is to capture the information that will make the article findable and usable by others. Relevance of information is one of the many areas of KCS that requires judgment on the part of the responder.
The following are some guidelines for content relevance:
- Words and phrases the requestor uses to describe the issue (even if technically inaccurate)
- Environment statements relevant or unique to the issue, which are true before and after the issue is solved
- Information that distinguishes this article from other articles with similar symptoms but a different resolution (distinguishing characteristics are most often environment statements)
- Diagnostic process used in resolving the issue (details or how to do complex, reusable diagnostic processes are often articles themselves and should be referenced or linked)
- Resolution statements which completely resolve the issue described by the requestor
Capturing and refining content as we work the issue is critical. We start by being very literal and seek to understand before we seek to solve. This may lead to capturing information in the article that, once we have solved the issue, we find is not relevant to the situation. This is typically true of the environment statements (functions, products, version and platforms). Prior to changing the article state from Work in Progress (WIP) to Not Validated or Validated, we should do a quick check for content relevance.
In the process of finishing a KCS article (once the resolution is known), we apply our best judgment about what information to include in the article. We will often capture information that has no relevance to the issue based on understanding the resolution, and we should be sure to remove information (particularly in the environment statements) that ends up being irrelevant, misleading, inaccurate, or inappropriate to the audience. We want to capture relevant, accurate statements using our preferred vocabulary in the environment field. We want as much consistency in how we describe the environment as possible. And, we want as much diversity in the issue statements as requestors use to describe the issue.