We have discussed the capture process and the reuse process. Now we will look at how day-to-day use of the knowledge base is review, and how we constantly improve the quality of the KCS articles that have value. The goal is to create a culture of collective ownership: this is our knowledge base; it represents the best we know to date. And, in the moment of use, we are responsible for the quality of the articles with which we interact.
In most organizations, we know that up to 80% of KCS articles will rarely or never be reused. Of the remaining 20%, some will be reused a lot. The first question that comes to mind is: why create them all, if most are not going to be used? The problem is we don't have good predictive capabilities. We cannot predict the future value of a support experience. Here is the logic for this position:
Support organizations in high tech see less than 3% of the customer demand for support (see the Consortium's paper "A Demand Based View of Support" on the web site). 97% of support demand is served through self-service or on-line communities, forums and social media. So, while we in support may have the best intentions, we don't have the context to make a future value judgment.
Reuse patterns of articles on the web are different than they are internally. There are those issues for which customers will use self-service and are happy to find an answer but they would not bother to open an incident to get the answer. It appears from the self-service data that this is a very large set of issues.
So, we capture all the experiences. If the question is worth answering or the problem is worth solving, it is worth having in the knowledge base. Capture it and let the other KCS processes improve the quality of the articles that turn out to have value.
In the early phases of adoption (Phases 2 and 3), we let reuse draw our attention to the articles that have value. By embracing the "reuse is review" practice, we are constantly improving the articles that are being used. For those articles that are never referenced, we have wasted no time reviewing them. This is an example of the fundamental KCS principle of a demand-driven system, and one of the reasons KCS is scalable and efficient. This demand-driven technique optimizes resource allocation and helps companies avoid investment in dedicated quality assurance and editorial staff. Review during reuse also helps encourage timely availability of information and avoid costly post-incident knowledge engineering.
In Phase 4, Leverage, we have enough KCS Publishers in the organization to publish, in the moment, the articles we have confidence in. In the leverage phase we must have a fast, closed loop mechanism for customer feedback; the customers participate in the "reuse is review" process. Customers are pretty quick to point out articles that they don't understand or that don't work. We have to be able to respond with corrective actions just as quickly.
Reviewing every KCS article that is created is a huge waste of time and money. Articles should be written in a way that is sufficient to resolve the customer issue. In the Solve Loop, this means as Support Analysts we are responsible for the quality of the KCS articles we interact with. We modify and improve KCS articles as we reuse them to increase the KCS article quality with each interaction. In this way, we focus only on those articles that are being used.
Another fundamental premise of KCS states that the best people to create and review knowledge are the people who use it everyday. Reuse is review reinforces this concept.