There are a few important reasons to use the “Work in Progress” (WIP) status in a KCS implementation.
First is to preserve the customer context across the life of the case.
If the issue takes some time to resolve, as is often the case in moderate to complex support environments, or if we have to escalate the issue to get a resolution (assuming the traditional tiered support model), it is critical that the customer’s context (how they described the issue) be captured at the beginning of the issue resolution process: at the first point of contact with the customer.
The customer context is a key factor in findability, and it is nearly impossible to recreate how the customer described the issue after we know the answer. Additionally, if the case gets escalated to another group for resolution, by passing both the case and the WIP article we preserve the customer’s context. The person who figures out the solution to the issue adds the resolution to the article, reviews the environment statements, and updates the article status as appropriate.
Second is to enable collaboration across space and time.
A WIP article promotes collaboration in environments where the resolution of issues takes some time, and especially when teams are working in multiple locations around the world. If someone working in a different shift or geography gets a case with the same issue (or even a similar issue) and they search the knowledge base, they will find that the issue has already been reported and is being worked on. Visibility to WIP articles prevents duplicate effort and promotes collaboration across different shifts and locations.
As a general rule of thumb, an article should only be in a WIP state while the case is open and being worked. If the case is closed because the issue has been resolved, the article status should be updated to “Not Validated” or “Validated” as appropriate.
For more information on the confidence states for KCS articles, visit the KCS v6 Practices Guide.