When reading the Adoption & Transformation Guide or KCS Practices Guide you may question the benefits these documents offer as payback for implementing the KCS Process.

Okay, – you may say. – I see how it might improve our response time, but the rest… It simply cannot be THAT easy to impact on eNPS and support costs in our company.

And it's absolutely natural to question the very feasibility of these benefits: such a big change in a workflow as the KCS process is, requires a lot of effort and commitment. And these investments must be well-countered by a real and substantial return.

To make the weighing process easier for you, we've collected our own experience with three different companies and the outcomes those businesses got.

See if the company profile matches yours and estimate what results you may be looking for following the successful implementation of the KCS process.

As with any B2C product, it is targeted at a consumer audience that makes purchases and uses the product impulsively.

What do we know about consumer products?

1. They typically have a larger consumer audience. Any, even a tiny issue in the product would spread with the speed of light, resulting in tons of support tickets.
   
   
2. Most of the customers are not technically savvy, and it's challenging for them to troubleshoot and fix a problem.
   
   
3. They prefer to have a quick conversation over chat or the phone and have the issue resolved ASAP. A "just fix it for me now" approach, as we call it.
   
   

Let me show what the reality was for the company when we stepped in to implement the KCS process.

Knowledgebase maturity at that point was moderate. As the product was relatively simple, the Product Team spent hundreds of working hours developing troubleshooting wizards for the support request form to address all possible issues they could foresee for their users.

And naturally, they faced some typical challenges that approach has:

1. Content Managers who created the troubleshooting articles thought they added all possible scenarios to the wizard, and they did not know what to add next.
   
   
2. The product evolved, and some branches of the troubleshooting tree gradually became obsolete. And it was time-consuming to maintain it too!
   
   
3. Customers didn't really use it as they preferred the "fix for me" approach. So as soon as they saw an option to get in touch with a real human being to get help from, they would immediately use it. Plus, those who had still tried to use the wizard later complained about the low coverage and outdated content.
   

Since KCS process helps to overcome those challenges, the buy-in happened blazingly fast and the adoption went smoothly. Agents saw their efforts in writing articles paid back quickly, with customers resolving the issues without even getting to the support request form: they were able to find those articles with the help of an Internet search.

Let's build the comparison table of KCS benefits outlined in general and compare with what we got there:

Here are our comments:

Time to Resolution and FCR had a noticeable improvement. These KPIs did not exceed the declared numbers because the product itself was relatively simple. Experienced agents could have the solution in their minds and did not have to go to the knowledge base for a solution. However, in the long run, it did have a positive effect anyway.

Time to Proficiency improved as well. Although the difference was not that big in its absolute value – remember, the product was rather small – the game changer here was lowering the requirements for hiring new agents. With KCS adoption, we got the ability to hire agents even without any technical knowledge, train them in the basics, and then use the Knowledge Base to learn the rest.

Employee Retention & Satisfaction was the greatest win here! Before the KCS era, agents had to work on the same issues, guiding their customers through the same steps again and again. And they burned out quite soon – there is no joy in monotonous routine work. Also, the product had "seasonality" effects - e.g. Black Friday or a new product version could produce a huge spike that required hiring temporary agents. But with a mature knowledge base the effect vanished: quick & relevant content for Self-Service prevented any such hiring at all.

Self-service success had a moderate impact, as there were still many consumers who preferred things being fixed for them rather than looking into knowledge for self-service solutions.

All-in-all, everything tied together, it contributed to the substantial reduction of Support Center costs.

That was a completely different case from the previous one. The company offered a sophisticated product that was sold to and adopted by huge enterprises with lots of customizations. These enterprises had their own technical support teams and were quite savvy, preferring to resolve cases independently rather than contacting vendor support.

From a Knowledge Management perspective, the company had a knowledge base but the coverage was far from ideal. The team explained: "Our product is way too complicated and customizable. There is no point in creating knowledge base articles as there are no two identical setups anyway. "

And the adoption wasn't well received by agents either. Some even tried to sabotage it. They had two widespread fears:

1. We are here to deal with hands-on troubleshooting rather than writing articles. We don't have time for that.
   
   
2. Why should we share our unique and deep knowledge with others? That's what we get paid for!
   

We had to overcome the pushback, and we did it in two steps.

1. We changed the performance assessment program and added KCS-related KPIs. That was us steering the team to the right motivation.
   
   
2. We ran the adoption in waves. Once the first wave turned out to be successful and others started to see that, now other support agents appreciated the program too.

Here are the results we got:

As it was a complex product that took a lot of time to learn, the main benefit we got was in Time to Proficiency and Time to Resolution. Newcomers got to learn faster, and then they were able to provide resolution quicker. In addition, the documented knowledge allowed them to troubleshoot even new problems faster.

FCR didn't improve that much because the B2B Enterprise software requires extensive troubleshooting in most cases. However, it feeds customers' support teams to resolve issues on their own and results in improving deflection and self-service success.

Attrition and employee satisfaction had a moderate impact, as the agents were already working on resolving complex issues requiring a lot of creativity. That did not change with KCS adoption.

The big win in Costs was the combination of improvements in Time to Proficiency, Resolution, and Deflection.

That company had several moderately complex products serving small & mid-sized companies that may not necessarily have their own technical support folks. Some of these customers yearned for the right solution so they could apply it themselves. Others preferred that the vendor fix issues for them.

The big difference here is that the company already had a knowledge base they considered "mature". I am putting the word "mature" in quotes and here is why.

The knowledge base had a lot of articles, but most articles – and the company admitted it! – were outdated or very difficult to follow.

Once we started digging into that, we found two other typical reasons why we believe KCS was the best approach for knowledge management in this case:

1. The content creators were not part of the support team. Even though they were former agents themselves, and they were competent in the technical aspect, they always struggled to determine the actual knowledge gap. In an effort to find out what to write next, they consulted R&D, read through long "most complex" tickets, etc. Which had nothing to do with the knowledge most customers needed at that time.
   
   
2. They were tech geeks and tended to write articles in their own way. Needless to say, a sizable portion of their articles were barely understandable even by less experienced support agents, let alone customers.
   

However, it was them who became the first promoters of the KCS methodology in the company.

The relevant parts (about 30-40%) of the existing knowledge base content were "re-used" and modified in accordance with a new style guide in the initial stages of implementing KCS. And that was a great starting point!

Eventually, we got the following results:

First Contact Resolution & Time to Resolution were the first metrics that popped up - in this case, we got a combo of medium complexity, customer's database similarity (no customizations) and customers' willingness to apply the solution themselves.

Time to Proficiency also improved significantly. Even though the complexity was moderate, it still required some initial skill and time to learn. We were able to play in both directions - lower the requirements for candidates and decrease the time we needed to get them up to speed.

Retention & Employee satisfaction also had a boost. As the self-service part improved, agents got to handle more complex issues requiring a lot of creativity and knowledge removing the routine from their daily work.

And as I mentioned, as the company's customers were willing to resolve issues on their own, they appreciated the new Knowledge Base coverage. In turn, it resulted in growing volume deflection.

Deflecting the incoming volume, improving the resolution time, and improving the Time to Proficiency all contributed to the overall cost reduction of the Support center.

Now we see that the actual outcome depends on multiple factors: company size, product complexity, initial knowledge management process maturity, size of the user base, etc.

However, at the end of the day, the combination of any improvements that are available for your type of company makes it possible to benefit from KCS adoption anyway.

As they say, "KCS is not the destination, but the journey!"