What is knowledge-centered service (KCS) and why does it matter?
Knowledge lies at the heart of every service desk. It’s how agents respond to problems and learn about the systems they administer. It’s what we pass along to customers when we walk them through a fix. And, before embracing knowledge-centered service (KCS), it was something that lived entirely in the minds of the agents and customer service reps on the front lines of those fixes.
In 1992, that all changed—when experts started making an argument for building knowledge-base creation and maintenance into the customer service process. And today, knowledge-centered service (KCS) is common, and many big, successful companies have been testing, developing, and improving on it for years.
What is knowledge-centered service (KCS)?
Knowledge-centered service—also known as knowledge-centered support or KCS—is when support teams not only provide real-time customer, system, or employee support, but also create and maintain documentation as part of the same process.
What does this look like day-to-day? It differs a little depending on which ITSM practice you’re applying it to.
In service request management, each time an agent handles an issue, they consult the knowledge base first to see if a fix is already documented. If so, they follow the steps outlined in the article, updating it if any of the steps have changed or if the current documentation is confusing. If no such documentation exists, the agent uses the proper process to troubleshoot and resolve an issue while also documenting the issue and the fix in a new knowledge base article.
KCS looks similar in problem management. When a team recognizes a problem, they document related incidents and the process they use to resolve the underlying problem.
Simply put, KCS is about getting the in-depth knowledge of IT teams out of their heads and onto the page, creating detailed documentation that employees, system users, and new or less experienced engineers can use without constantly bombarding the service desk with the same requests. It’s about treating knowledge as a business asset and not relying entirely on memory and experience to resolve problems quickly.
Knowledge-centered service--or knowledge-centered support?
Until recently, the most common term for this approach was knowledge-centered support. The word support was the focus because that’s where the process started. Knowledge was captured, updated, and maintained through customer support.
Today, the more common term is knowledge-centered service. The word service is embraced because it expands the focus of KCS from simply being a support practice to being a process that can improve every aspect of ITSM.
Service requests are still the most obvious place KCS comes into play. But KCS also has a place in other ITSM processes including change management, where change plans can benefit from collaborative, detail-oriented record keeping processes. In incident management, KCS can improve the ability to quickly address an outage. And in problem management, it’s used to document known issues and make sure they aren’t repeated in future.
Benefits of KCS
So, why should career-minded, cost-conscious IT professionals add knowledge management to their already long list of priorities? Because the benefits greatly outweigh the costs.
At Atlassian Summit, ITSM expert John Custy shared some pretty powerful numbers to support the case for adopting KCS. In fact, the average team that adopts KCS sees…
- A 30 – 50% increase in first-contact resolution
- 70% faster time-to-proficiency for new analysts
- 20 – 35% improvement in employee retention
- 20 – 40% improvement in employee satisfaction
- 10% fewer reported issues/support requests
50 – 60% of KCS adopters also improved time to resolution. And in an IT climate where we’re always looking to shave fractions of seconds off key performance stats, it’s hard to overlook gains like these.
Why are those gains so massive? In our experience, there are quite a few reasons…
Less problem-solving from scratch frees up time
The more well-documented and up to date your solutions are, the simpler and quicker they are for anyone—service desk agent or end user—to implement. This means quicker solutions to common problems and quicker responses to complex issues (since the service team won’t be bogged down with small, redundant fixes).
Adopting KCS takes some up-front time commitment, since agents now have to document each fix. But the time it takes to write that article is nothing compared to the time future agents and end users will save by having a quick step-by-step guide to the fix. This is particularly true when you onboard or train team members, increase workloads, and encounter issues that aren’t fresh in anyone’s mind and whose solutions may have been forgotten along the way.
More consistent customer experiences mean happier stakeholders
Centralizing answers and fixes also creates more consistency in your customer experience. If every agent is using the same playbook and the same processes, customers--whether internal or external--will have a more consistent experience no matter which customer service channel they choose and which IT professional they end up with.
Why does consistency matter so much? Well, it’s no secret that customers love fast fixes, predictably positive experiences, and confident, knowledgeable employees who can put them at ease. And happy customers mean a better bottom line for the overall business.
KCS creates continuous improvement
Another benefit of consistency across the IT service ecosystem is that it makes it easier to identify recurring issues and key areas for improvement in both support processes and the systems themselves. Tracking which documentation gets the most review, which fixes have the most steps, and which fixes have more or less satisfied customers can help the organization identify opportunities for not only simpler fixes but also product upgrades or better solutions to common issues.
Good documentation enables true self-service
Many customers prefer self-service and the ability to use a knowledge base over other service channels. Put simply, great self-service is what customers want.
Self-service can reduce service desk cost significantly. This kind of money-saving self-service is only possible with an approach like KCS that builds good, up-to-date documentation into your service practice.
Challenges of KCS
Most people acknowledge the value of knowledge-centered service. When it works, the benefits in time, profits, and happier teams are pretty compelling.
So, the challenge of KCS is seldom an objection to the practice itself. Instead, teams often experience cultural challenges that make it hard to shift out of what expert David Kay calls “an obsession with the urgent and tactical.”
His point is that IT managers get too busy fighting fires using current processes (ineffective as they may be) to focus on doing something more strategic. After all, creating content sounds difficult and time-consuming—particularly for teams already bogged down with requests and struggling to meet or beat a slew of SLA promises and SLO targets. Not to mention that compensation is often directly tied to performance goals, which are directly tied to that firefighting mindset.
The truth is that content creation and adopting the new processes of KCS aren’t actually that time consuming. Both can be done gradually from day one. In fact, with a system like Jira Service Desk you can create an article directly within a support ticket.
The biggest obstacle here is the cultural shift—which needs to happen not only at the team level, but also at the organizational level where things like performance goals and compensation are decided.
How does KCS work?
Knowledge-centered service follows a continuous loop of capturing, structuring, and reusing knowledge. While engineers are actively supporting stakeholders, KCS asks IT teams to:
- Create content to document how they solve problems
- Update and evolve that content based on demand and use
- Publish that content in a knowledge base to make it easily available (reducing incoming tickets and saving the service desk time and money)
- Reward each other for learning, collaborating, sharing, and improving
This is done through a five-step process built into the team’s existing support process.
Step one: capture knowledge
When requests come in, articles are created and then updated as a by-product of the problem-solving process. This means agents write articles not based on internal lists or priorities, but based on actual customer context, making information inherently relevant and easily searchable.
Step two: structure knowledge
The best way to write an article that’s usable by the customer or end user is to work from a template or form. This simplifies the process and creates consistency in the customer experience with the business’ knowledge base.
Step three: reuse knowledge
When a new issue pops up, agents should always search the knowledge base first. They can link incidents to relevant articles, making sure the team is working from their collective knowledge.
Step four: improve knowledge
As the knowledge base gets built up, agents become responsible for less content creation from scratch and more updates to existing articles—keeping the knowledge base up-to-date and always useful.
This approach not only keeps content fresh, but it shares ownership across the whole team rather than treating knowledge base updates as the responsibility of a single person and as a separate task on that person’s to-do list.
Step five: use knowledge to see the big picture
As the knowledge base grows, the team will have more data on how effective each article is at solving problems and can start to hone processes and put more resources toward high-demand, cost-reducing knowledge. The process and the knowledge base itself are useful tools for identifying what’s working and what’s not, where there may be gaps in knowledge across the team, and what tweaks might need to be made for future articles to be more effective.
Knowledge-centered service, in other words, in a process that builds on itself, bringing more value to the company over time.