With KCS, we seek to understand the customer's experience before solving. This understanding requires information about both the perceived issue (in the customer's words) and the environment in which the problem is occurring. By capturing the customer's perception of the situation in the first interaction, we dramatically improve the findability and relevance of the KCS article to other customers who might have the same or similar perception of this issues in the future (context is as important as content).
The objective of capturing KCS article elements is to "frame" the customer's situation—to capture their need, perception, experience, and relevant aspects of their environment as input to the problem-solving process. The objective is to use this input to improve the KCS article set. We use the framing information to either create a new KCS article if one doesn't already exist or to improve an existing article by reflecting another customer's experience.
Even if the customer's perception of the situation proves to be wrong, preserving it will improve the findability of this article for other customers. The Support Analyst'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 customer's description of the problem. However, Analysts may capture additional technical details to more precisely characterize the problem. Technical accuracy in the problem statements is not required. Of course, technical accuracy is critical in the environment, resolution and cause statements.
Some of today's knowledge tools enable the capture of the customer's online search activity before they contact us for help. Having the words and phrases the customer used to search is very useful - this is their context. The customer's search terms can be used to create the problem statements in a new KCS article, if one doesn't already exist, or can be used to modify an existing article and improve its findability.
In the case of incidents submitted via a self-service model, good things can happen if we capture the customer 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 Support Analyst helps the customer feel like the effort spent pursuing a resolution through self-service was not a waste of time (no dead ends). This information can help expedite the problem-solving process as we can review what the customer has already done.
Customer submission of issues via self-service also helps us create new or modify existing articles. If we need to create a new article for this issue, the search words and phrases the customer used to look for a resolution are valuable content for the new article. If, as the KCS practices suggest, we have captured the information the customer used to search the web in a Work-in-Progress (WIP) 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 customer search activity they are in the customer's context.
If, in working on the issue, we eventually find an article in the knowledge base, we should improve that article so customers can find it. We have already captured the information in the Work-in-Progress (WIP) article, which we can use to update and improve the findability of the existing article. If the existing article was available to the customer but not findable, we use the customer experience (and their context) to improve the findability of that article. If the existing article was not available to the customer, can we publish it? Are we licensed to publish, are we confident in the resolution, and is the article compliant with the content standard? See the Content Health section for more on article states and transitions.