KCS is a demand-driven system; this means we should not add content in the absence of demand. Just as we should not try to anticipate the future value of an issue (if it is worth resolving, it's worth capturing), we should not create articles in anticipation of demand. This often causes concern and raises the question... What if we know a situation will occur with the release of a new application or process? If we know something will happen it is probably based on past experience, as in, the last time we did this, that happened. Or, we know from the alpha and beta testing that users will experience these issues. That is demand-driven.
The general rule of "don't add articles until someone asks" raises a problem when introducing new products or processes. How do we prime the knowledge base for them?
Perhaps the worst thing we can do is have development or engineering write articles about the new product or process: those articles will be in the context of how the product was designed and built, not how customers will use it, and not how it will break. We can, in fact, capture information about new products in a useful context. As a new product or process is going through alpha and beta testing or user acceptance testing, we should capture those experiences in the context of use. Creating articles that address the issues users are likely to encounter because of what we learned in the pre-release testing is the best way to seed the knowledge base.
During product beta cycles, we pay special attention to creating content in context of the beta testers experience. Generally these pre-release articles should be in a Draft or Not Validated state (not visible to customers) until they have been reused to solve a customer issue, and, as a result, updated with the customer context and then made available externally for direct customer access through self-service.
KCS articles can also be pre-populated in the new knowledge base during the KCS training and pilot phase. Students bring their top ten current issues to training and use these issues to practice creating KCS articles. We structure and enter the knowledge according to the KCS content standard. As these KCS articles are reused in the request-resolution process, they should be modified to include the requestor's context.