Knowledge-Centered Service (KCS®, also known as Knowledge-Centered Support and Knowledge-Centric Support) is a methodology for creating and maintaining knowledge as a byproduct of the problem solving process.

KCS introduces a new workflow for support agents that brings "tribal" knowledge that is spread across the team to the surface, enabling it to be accessed by the whole organization and by your customers.

As opposed to traditional knowledge management workflows, where designated knowledge managers or technical writers work on maintaining knowledge base, within the KCS workflow all agents create and refine the knowledge as they work on resolving customers' requests.

We've collected 10 core KCS principles that we believe make the whole qualitative difference to the traditional knowledge management process. Let's take a closer look at each of these.

With a traditional knowledge management system there are knowledge managers, technical writers, content creators – designated roles responsible for creating and maintaining the knowledge base.

Knowledge-centered service methodology shifts the culture towards collective ownership of the knowledge base. All support agents are responsible for filling up and refining articles.

Even though benefits of this approach are obvious – more articles get to be improved, and it gets faster too – but you may rightfully object: "Not every agent is equipped with the skills to create customer-facing content."

That's true!

To make sure only qualified agents get to change public articles KCS introduces the licensing model for knowledge workers. Still, if an agent has a KCS role that does not grant permissions to edit public articles, she still can flag an article for rework just in time she sees any inaccuracy or mistake.

Without KCS, technical writers or knowledge managers create articles that they believe will be of the most value to customers.

They change these articles when someone from the team reports inaccurate or outdated information, and the priority for these changes is rarely aligned with customers' needs.

The backside of this approach is the substantial time gap between the change requested and the moment the change is published, and the information may no longer be relevant.

With knowledge-centered service, the knowledge gets documented as soon as the lack of it is spotted. That is, when we try to resolve an issue which is not described in an article yet.

Moreover, only the relevant piece of information gets documented – the problem the customer contacted us with and the resolution we provided.

Just enough for another agent to resolve similar issues in the future.

Using articles in support tickets does not affect priority with the traditional knowledge management approach. It's either titanic work to review all articles to bring them up to date, or a per-request reactive approach that saves the effort, but delays the necessary changes.

KCS prioritizes knowledge requested by customers first.

It's only important to update those articles that are actually used for resolving customers' issues at the moment.

It's okay to leave rarely used articles in draft state, but if the draft regularly gathers new uses in support tickets it's a signal for publishers to make it conform to the content standard checklist and publish as soon as possible.

Review and rework only those articles that you use often and as you use them.

Typically, a technical writer or a knowledge manager picks a structure for an article that looks appropriate to the topic and the body of information that lies within.

Of course, it helps to make a better impression of the author as a writer. Epigraph, suspense, hero arc, etc.

Unfortunately customers read the documentation or knowledge base to resolve their issues as soon as possible, not to evaluate the writing skills of the author. There is probably another William Shakespeare sitting within your technical writer, but customers will not appreciate it enough.

KCS enforces a rigid structure for an article, which helps customers and agents quickly scan through the body, gauge applicability, and easily apply the suggested steps.

The structure reduces agents' efforts on creating articles too!

In traditional knowledge management, writers tend to cover all possible issue variations and all possible approaches to resolving the issue. So that it won't be necessary to update the article in the future.

But that's so exhausting, and requires a lot of their time too!

KCS does not require describing all possible scenarios and ways to resolve every particular problem. When you first create an article draft, you may even copy and paste the reply to the customer into the resolution section of the article.

These steps, however, should be sufficient to resolve the issue.

Later, if more customers come with the same problem and support agents find better ways to resolve the issue, the article will be updated.

The more tickets get resolved with an article, the better shape the article will take.

Reuse is review, remember? So don't try to create a silver bullet right away.

"Good enough" is good enough!

I bet, if your company is seriously invested in proper knowledge management, then you probably must have tried hiring a specialist for editing knowledge base articles. A copywriter or even a linguistics graduate, the whole job of whom is to review and re-write the KB for better grammar.

It makes, however, these articles harder to find and to read for your customers and agents. A majority of them may not even be a native speaker of the language you use in your articles. In such cases they may even auto-translate the text with in-browser plugins, so the talent of linguistics graduates is wasted for nothing.

Knowledge-centered service recommends using short phrases that represent complete thoughts.

My thumb rule is that an article should look more like a numbered list, not an essay.

Traditionally, technical writers would want to describe symptoms in a literary fashion, or maybe in a more general form.

If you have an agent or any other technical expert who writes articles out of the KCS workflow, they would tend to write symptoms in more technical form. Sometimes they might even substitute symptoms for the root cause they may have found during the investigation.

Both approaches make the article harder to find for your customers, who may not think of the problem that way.

The preferred approach that KCS suggests is to write symptoms in customer words, exactly as they see them.

That way customers are more likely to find and apply the article.

The traditional approach to knowledge management focuses on categorizing and structuring knowledge. That is, creating sections and subsections of the help center that better reflect the structure of the product.

However, most customers won't explore the knowledge base from top to bottom, starting with the home page. Most likely, they will use search functions to look for a solution to their issue. And chances are high it would be Google or another popular search engine, not even the one pre-built with your knowledge management system.

That's why the KCS workflow introduces the content health check process to make sure articles conform to the content standard and remain searchable.

The last, but not least, key difference of KCS is its focus on business outcomes rather than activities.

With traditional knowledge management, KPIs for knowledge workers are focused on activities: number of articles created, number of articles edited, time to create an article, and so on. Sometimes these KPIs may include views and customer ratings, but that's all.

KCS offers ways to measure and control business outcomes, directly impacting your company's success.

For more detail check out our article on how KCS suggests measuring your help center efficiency.

Here are results observed by the members of the consortium for service innovation for the past 30+ years:

Solve Cases and Incidents Faster

• 50 - 60% improved time to resolution
• 30 - 50% increase in first contact resolution

Optimize Use of Resources

• 70% improved time to proficiency
• 20 - 35% improved employee retention
• 20 - 40% improvement in employee satisfaction

Enable Web Success

• Improve customer success and use of self-service
• Up to 50% case deflection

Build Organizational Learning

• Provide actionable information to product development about customer issues
• 10% issue reduction due to root cause removal

We also have our own statistics on how various companies benefited from implementing KCS. Read about results of three different businesses launched Knowledge-Centered Service transformation.

Knowledge-Centered Service methodology is openly available to everyone, thanks to Consortium for Service Innovation.

Depending on time and resources that you have for KCS implementation, there are three options: