If you’re charged with the stewardship of your customers from an engagement perspective you’ve likely come across Knowledge-Centered Support (KCS). The practices KCS espouse aren’t necessarily revolutionary even if they can drive outcomes with as large an impact. 

The assertion of the Consortium for Service Innovation is that KCS isn’t an outcome, but how you solve problems. KCS is more than a methodology to solve problems efficiently it provides as much if not more in terms of value when you explore how you can use this knowledge. Whether it’s driving a living, relevant knowledge base for your subscribers or where we are taking it here at CloudBees to enable automation and proactively notifying our customers of issues they may not even be aware of. 

“Knowledge as Code” is an evolutionary leap and practical solution for leveraging artifacts from the KCS methodology as fuel for both adding value to your customers and enabling your own operational efficiency. Treating your knowledge as code and not something simply published for the purpose of perusal creates an infinite amount of ways in which we can use this information. 

In the following series of posts we’ll talk about the hurdles, decision-making, and outcome driven requirements that led to the birth of Knowledge as Code. We’ll also talk about how this initiative enables our Customer Success and Support Delivery business functions along the way.