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 KCS article for other requestors who might have the same or similar perception of this issues in the future (context is as important as content).
Capturing the requestor's context - their words and phrases - improves findability for other requestors.
The objective of capturing KCS article elements is to "frame" the situation—to capture need, perception, experience, and relevant aspects of their 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 of this article for others. The responder's job is to capture with precision and accuracy the relevant environment factors, the resolution, and the cause in the article, not to correct the requestor's description of the problem. However, responders may capture additional details to more precisely characterize the issue. Technical accuracy in the problem statements is not required. Of course, technical accuracy is critical in the environment, resolution, and cause statements.
Many of today's knowledge tools enable the capture of the requestor's online search activity before they ask for help. Having the words and phrases the requestor used to search is very useful - this is their context. The requestor's search terms can be used to modify an existing article and improve its findability, or to create the problem statements in a new KCS article, if one doesn't already exist.
In the case of requests submitted via a self-service model, good things can happen if we capture the self-service activities (search strings, articles viewed, and in some situations product and version information). First of all, this guarantees that we are capturing the customer context, and secondly, making this information available to the responder helps the requestor feel like the effort spent pursuing a resolution through self-service was not a waste of time. This information can help expedite the process as we can review what has already been done. We call this "no dead-ends" for the user, and is a critical factor in creating a positive experience with self-service.
Requestor submission of issues via self-service also helps responders improve existing articles or create new ones. If responders need to create a new article for this issue, the search words and phrases the requestor used are valuable content for the new article. If, as the KCS Practices suggest, we have captured the information the requestor used for their self-service search in a Work in Progress article as we were working the issue, we have already created a new article and simply need to review the environment statements and update the resolution field. Because the problem statements came from the requestor's search activity they are sure to be in the requestor's context.
If, in working on the issue, we eventually find an article in the knowledge base, we should improve that article so others can find it. We have already captured the information in the Work in Progress article, which we can use to update and improve the findability of the existing article. If the existing article was available to the requestor but not findable, we use the requestor experience (and their context) to improve the findability of that article. If the existing article was not available to the requestor, we change the confidence and visibility metadata indicators if we are licensed to do so. Reuse drives both improvement of the articles being used as well as increasing the visibility of article being used.