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
Environment statements should be 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 in the article 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.
Environments where the requestors use self-service as the entry point for assistance offer a great opportunity to capture the requestor's context. Capturing the words and phrases they used to search or their click stream as they browse as well as articles they opened can be very helpful in the event the requestor moves from self-service the assisted path. If the requestor does a "click to chat" or "click to submit" the history of their session is passed to the responder. This kind of mechanism ensures that we capture the requestors context. It also makes for a positive experience for the requestor as they move from the self-service path to the assisted path.
See Appendix E for a sample of a quick reference guide for article content and structure.
The words and phrases we use to search are candidate content for improving existing KCS articles or creating new KCS articles. They are especially valuable because they capture the requestor's context. Content used for searching should be saved, updated based on search results, and should become the beginning of a new KCS article in the event a KCS article does not already exist.
Content like the issue and environment statements frame the KCS article. This Work-in-Progress (WIP) KCS article should be saved in the knowledge base even if we don't yet have a resolution. We may continue to work on the issue or submit to the appropriate people for resolution (this process varies based on role and KCS license). A WIP article in the knowledge base lets others know that the issue has been reported. When the resolution is determined, we add it to the WIP article: we finish the article. We consider this KCS article complete and mark it with the appropriate state based on our KCS license (rights and privileges) and our confidence in the resolution. In the event that other open cases have been linked to this WIP article while we were working on it, they can be quickly resolved.
The process of framing and finishing KCS articles draws people into using the knowledge base as the basis for resolving issues. This, in turn, ensures that the collective experience is being captured in the process of resolving issues.