Dec 27, 2017

KCS Version 6

Moving from Knowledge Centered Support to Knowledge Centered Service

Knowledge Centered Support (KCS) is a particular methodology to create and maintain content in a Knowledge Management System (KMS). It was developed originally in the customer support context roughly two decades ago and was adopted by quite a few major support organizations successfully over the years. Its effectiveness in generating and disseminating knowledge has prompted the supporters of KCS to extend its application to areas beyond support, which is what version 6 has given us with Knowledge Centered Service.

Knowledge Centered Support  -  History and Background

KCS was developed by the Consortium for Service Innovation (CSI) starting around 1997 as a response to the models of content generation prevalent at the time:

• The knowledge specialist model gives the content creation job to a group of authors whose specialty it is to generate documents. They create manuals working with the product group, research specific issues they receive from support agents, and put together articles that addresses knowledge gaps. This is, however, a slow process with multiple intermediate steps: the need for content has to percolate up to this authoring group first before the content can be created and put through various testing and verification steps.


• The product specialist model relies on developers taking their time from product development to put together documentation to help support agents. The type of deep knowledge that only developers can provide is clearly essential to some content, such as manuals and technical specs. There are other kinds of content however, that do not require a developer's point of view, as in troubleshooting documents and solution articles. To engage developers in such an activity is unnecessarily disruptive and it requires them to anticipate problems before they are encountered.

Both model entail an inherently centralized process that separates content creation from the act of problem solving. KCS, on the other hand, starts with the assumption that those who are involved in resolving the issue have the best vantage point to create the content they need. It does this by handing the content authoring responsibility to support agents as a task they perform while they are working on a service request.

• The content benefits from the agent's past experiences with similar issues, and the knowledge they are actively developing as they engage the issue directly.


• Agents are also in the best position to capture all relevant aspects of the issue while the experience is fresh in their minds.


• Content created while servicing a ticket is created because it is needed when it is needed in order to addresses an actual problem, instead of being created in anticipation of an issue that has not been encountered yet.

This is a seemingly simple shift in focus whose implementation may technically pose some challenge that can be resolved by applying correct knowledge management tools. However, it often requires the organization to undergo significant changes in the overall mindset.

How KCS works

The KCA methodology can be summarized as follows (the reader is referred to the numerous articles available on line for a more detailed discussion):

When an agent picks up a call or opens a pending service request on their Customer Relationship Management (CRM) system, and start taking notes, they are in the process of capturing the customer's problem in their own voice. These notes constitute the kernel of the Knowledge Base (KB) article they have already started constructing. As a picture begins to emerge in the agent's head, they are forming enough understanding of the customer's issue to be able to search their KB for answers. Content creation and issue resolution are happening simultaneously during the call.

There are three possible outcomes as the agent conducts their search:

• There may be no prior article in the KB that handles this particular problem, in which case, the agent continues creating the article they had started.


• There may be an existing article that addresses the issue but it may be incomplete, not entirely accurate, or otherwise in need of some revision, in which case the agent abandons the article they had started and goes on to either improve the article they found, or flag the article for someone with the correct permissions to make the necessary modifications.


• There may be an article in the KB that handles the customer's issue, in which case the agent again abandons the article they had started, and links the existing article to the service request.

This is the "use it, flag it, fix it, add it" approach (UFFA) that is the cornerstone of KCS.

To make this process work, the CRM system the agent is working with needs to be integrated with a KMS that has these key functionalities:

• The ability to have support agents create an article while they are handling customers.


• The ability to have an article go through a workflow in an iterated "flag it or fix it" fashion until it is mature enough to be published.


• The ability to conduct effective search against KB articles that were created prior to the incident to minimize content duplication.
• The ability to link articles to cases handled in the CRM system so that the value of articles in the KB can be evaluated through analytics.

Providing agents with this capability is essentially a technology issue; it is a matter of applying the right tools and making the necessary configurational adjustments to enable them.

The cultural challenge facing an organization in transition to KCS, on the other hand, is to relinquish the centralized control over content creation. It requires management to trust that their agents can put together reliable KB articles and that the peer review process will enhance the quality and accuracy of the content. Most of all, it requires that sharing knowledge is at least as much values as possessing it. In most organizations this would suggest a cultural shift, whether in parts or as a whole. This aspect of transition is driven by management, whose task would be to develop the incentives, leadership and values aligned around the culture of sharing within the organization.

What is in KCS version 6?

Version 6 of KCS, released in 2016, does not introduce any departure or divergence from its core ideas, but develops a better articulation of their execution.

These two areas are impacted the most.

1. Inclusion of three types of metadata to help regulate the workflow process.

• Visibility: Who should be able to see the document.


• Quality: How confident we are with content of the document.


• Governance: Who should be able to edit and revise the document.

2. Deeper discussion on the role of management in an organization's transition to the KCS methodology and the values that need to be championed by leadership.

• Developing a vision for the organization and forge a strategy around it.


• Promoting teamwork among knowledge workers, identifying their motivators.


• Focusing on communication, recognition and, accountability.

Version 6 does one more thing. It expands KCS to areas outside of customer support, specifically into service (note the change of label to "Knowledge Centered Service" instead of "Support"). It does not, however, go beyond some nomenclature adjustments to explore this idea further or provide any guidelines as to how the methodology would be applied in non-support contexts.

The job of a support agent is well-defined at a high level: they take something that is not working correctly, and they fix it in ways that makes it work correctly. The endpoint of this process is well understood (whether it is a working product or the resolution of a problem) and the role of knowledge is to guide the agent in the process to get the issue to a resolution.

The situation is considerably less clear in the world of professional services (PS) or product development. In consulting, endpoints are defined by the customer based on their needs, limitations, and business requirements. Specifications help define the guidelines in product development, but what the product will look like at the end and what it will be capable of doing are, again, defined by business requirements and management goals. It is not immediately obvious how KCS can be applied in such contexts without normative end state as opposed to the more familiar support context.

The key is to look at the job of a PS consultant or a product developer at the next level down and focus on their daily tasks where they are engaged in solving a series of smaller problems along the way and how knowledge can be generated in those settings.

Professional Services and Sales Consulting

Consulting work in a PS organization typically implies implementing a solution, whether it is a financial service, tech service, or administrative. The exact form of the solution and its ingredients vary greatly, however consultants often find themselves handling a series of set pieces along the way. In other words, the overall structure they are building may be unique, but the way they keep putting the bricks together to form that structure is often very familiar. It is in this familiarity that we find the opportunity for knowledge generation, for example, knowledge emphasizing ways to work with specific environments in terms of their features to exploit or traps to avoid.

The type of content envisioned here goes beyond the usual "how to" articles. Instead of focusing on step by step instructions to follow, the goal is to build a better understanding of the customer's working environments and the properties of the product in order to achieve the goals of the project as defined by the customer. This process would empower PS consultants to produce content that would help their teammates navigate towards a finished product the same way solution articles guide support agents towards issue resolution.

Incidentally, the same approach can be applied to Sales Consultants and Sales Engineers, who are often in a position to build proofs of concept.

KCS advantages would still apply in these cases: consultants would be producing knowledge at the point where it is needed, they would rely on each other's work to complete their tasks more efficiently, new team members would be on-boarded faster, and product management can receive valuable feedback.

Product Development

Product development also involves solving a sequence of smaller problems on the path towards solving the larger one, or completion of the product. There are known interaction between elements, methods that were tried that caused issues, or a decision made at some point having an impact elsewhere. These are all candidates for the time of knowledge that can be generated during the development process.

Quality Assurance

Quality Assurance (QA) professionals work closely with the development team to ensure that the product meets specifications and works properly. They produce an immense amount of knowledge actively traded during the testing cycle, which needs to be tracked, referenced, and amended as development responds to testing and makes modifications. This knowledge can be captured in real time and after a layer of filtering, its salient parts can be made available to the other groups that operate downstream in the organization.

Creating a Unified Knowledge Environment

As groups outside of customer support become engaged in a KCS-driven knowledge management process, the organization begins to shift towards a unified knowledge environment that we might call "Knowledge Centered Enterprise". The organization now engages in knowledge creation and dissemination end to end: starting from the source in product development, through the QA team, sales consultants, professional services, and ending at customer support. As knowledge is shared within each group and across the departmental boundaries, a more effective and efficient work environment is created and the benefits that support organizations have been drawing from having adopted the KCS methodology can now be spread throughout the enterprise.

Going forward with Knowledge Centered Enterprise

KCS is a mature methodology that has been applied successfully in many customer support groups at the enterprise level. We have seen that it is designed to empower knowledge workers, acknowledge their skills and expertise, and to emphasize success through knowledge sharing. In this sense, this is a social experiment that has worked. As such, we believe it is time for these lessons to be carried over to the entire enterprise by adopting it methodically and stepwise (as prescribed by the KCS). In other words, we would like to see organizations who have started with Knowledge Centered Support not only to transition to Knowledge Centered Service, but to push it even further and transform it to Knowledge Centered Enterprise. The process would require considerable effort by management, but the potential upside promises to be even greater.

.   .   .

.   .   .

This post was written by Murat Kural — Practice Director of the Knowledge Management (KM) practice at SoftClouds. He has executed many successful Global KM Implementations and is a recognized leader in the knowledge industry for his expertise in search, dictionary management, and knowledge management. Prior to SoftClouds, he spent a number of years teaching linguistics at UC Irvine. Murat has KCS certification and holds a PhD degree in Linguistics from UCLA.