Knowledge Management best practices in Support: Evolution from Ticket-Centric to Knowledge-Centric Support

I've been running a Support organization in a software company for a few years now. I joined one 20 years ago as a junior support agent and worked my way up to the executive position. Together with the company, I've been through a series of mergers, acquisitions, and rebrandings, being a witness and, sometimes, a driver for significant changes across the support organization.

During all these years, we've worked a lot with support tools that had to evolve to enable the evolution of our processes and the transformation we were going through. And I probably could tell one or two things that might help your company cut corners short.

Anyway, here is our story.

In the very beginning, when the whole support org barely reached ten agents, we worked in the self-hosted opensource helpdesk system Request tracker. Back in 2003, we took it as a cheap and better-organized alternative to supporting our customers via a shared email box. We got a pretty decent ticketing system that helped us standardize the growing volume of support requests and work as a team.

The major benefit of having an open-source system was its flexibility. Whenever we needed to add a new product or change the workflow or pull up some integration, we could easily do it with a few dozens (or hundreds, honestly) lines of code in Perl and Javascript. It was never a problem because we had a dedicated internal development team within our support organization.

Shortly after the launch of the helpdesk system, we launched the Knowledge Base based on open source code as well.

The initial approach towards knowledge management was very primitive. We thought it would be enough to create a FAQ and — maybe — describe our customers' most popular issues. Although the FAQ part didn't produce any problems, "the most popular issues" part of the plan got stuck at the step of identifying the topics we'd want to cover in our articles. At times, we were quite a geeky support team, so the best approach we could invent was to designate the most experienced and nerdy engineer to write articles that our customers must find useful.

Well, maybe it was a good first step but only as the first step. It was not sufficient at all. The problems started emerging from the very beginning when "the most experienced engineer" wrote few articles barely understandable even by our junior members, let alone less technical customers.

Indeed, few geeks liked those articles, but the vast majority either didn't get how to apply the resolution provided or even could not recognize that the article was related to the problem they had. The reason was that support folks (including "the most experienced agent") interpret issues differently than customers. They had the knowledge and skills which our customers did not have, that's why they tended to describe the symptoms of the problem from their point of view, totally unavailable for most of the customers. That could work as an internal Knowledge Base, but it was too inefficient for a client-facing help center.

Okay, once we figured that out, we decided to hire some external copywriter to translate that geeky language into our customers' language. That helped just a little bit, as the copywriter didn't know how our customers perceived the symptoms of a problem and just tried to apply more friendly language to the whole article. Articles become easier to read, but still, the relevancy and efficiency in the search were very low.

Plus, one more problem appeared — despite "the most experienced agent" worked hard, the problem coverage of articles didn't seem to grow well enough.

That's how we thought too. So we added one more "experienced person" to the process. We took our two best agents out from ticket processing, working full time now only writing knowledge base articles. The rationale behind the idea was the following: "Yeah, we'd decrease our capacity on ticket processing, but eventually, we must be able to create a decent number of good articles, so our customers would use those to resolve their issues and stop creating more tickets. And we'd go play PS finally."

However, the time passed by, the number of articles published skyrocketed, but customers kept creating more tickets. Yikes.

Why doesn't KB work? We had to figure that out.

To differentiate that role from that of "key" modeling when a modeling source moves behind the object, it is typically called a "rim" or "accent" light. In portrait lighting, it also called a "hair" light because it is used to create the appearance of physical separation between the subject's head and background.

Before we tell why Knowledge Base doesn't work well, we have to formulate what "well" means. And there is an excellent industry-standard metric widely used to measure the efficiency of the customer self-service toolkit: ticket deflection.

Deflection = Tickets Avoided / (Tickets Avoided + Tickets Created)

Let's say you have 100 customers who have an issue, and they come looking for support. Fourteen of them got to Knowledge Base, found the solution, and haven't filed a ticket. The remaining customers either haven't found the answer or haven't even try to search — they have just reported 86 tickets to your team. Using the formula, we can calculate the deflection in this very case: 14%.

But wait, there is more. The deflection could be direct and indirect. Direct deflection is the deflection that is possible to measure. Imagine, 100 customers came to support web form, and 14 of them transitioned to Knowledge Base following links automatically suggested by the web form. And they ended up not creating a ticket. So it is possible to track these transitions from web-form pages to KB articles and measure the deflection.

Indirect deflection is the deflection that is not possible to measure. Let's take the same 100 customers who want to receive support, but 14 of them either go directly to an article or find it through google. They never filed a ticket, and we couldn't possibly know whether they wanted it or not. As a result, it is not possible to measure the thing that hasn't happened. But some clever math algorithms allowed us to estimate it by comparing the difference between the real volume of tickets and the projected volume. Rocket science, not less!

So, what was our deflection, and why we thought it was not good enough?

You got me here — at that time, we knew nothing about deflection. The only thing we did to evaluate the efficiency of the Knowledge Base was observing the trend of the ticket volume and be happy when it declined and be sad when it grew. It didn't take into account the growing number of customers, the increasing complexity of the product, and many more factors.

We realized that, but we thought the plethora of articles we had published would help us to reduce the number of tickets we had. And still, we were sad more frequently than happy — the volume of tickets was growing.

There had to be an explanation, so after digging into the analysis deeper, we've found few factors to that:

1. Irrelevant content. Our dedicated knowledge base writers created articles they believed to be helpful. In reality, these KB articles were either too basic or, vice versa, too complex. No one wanted to read "How to retrieve my password? Click the Retrieve my password button" or a multi-step technical guide that described how to troubleshoot sophisticated edge cases that occurred only a few times. Neither could help solve problems that customers actually had.
2. Outdated information. In addition to the previous point, articles became outdated quite soon after the release of a new version of the product or after any related technology update. We almost never reviewed the content of the article after it got published.
3. Writers lose competence. After approximately six months of being dedicated writers, "the most experienced" folks suddenly started to realize they were not "the most experienced" anymore. The reason was simple — they didn't participate in resolving customers' issues and, therefore, started losing their product expertise.

Together, these factors made our efforts futile. Even more so, we've gotten to the situation where we took our most efficient and experienced engineers out of ticket processing (where they generated the biggest value for the company), and other engineers had to handle more tickets. And the company had to recruit, hire and train new employees to cover the gap.

But wait, there had to be the right way to do the Knowledge Base business, right?

It was early 2012 when we found the methodology named Knowledge-Centered Service (KCS®). It appeared that major IT companies had already gone through the same challenges and developed a framework that helps keep the knowledge base relevant and effective.

KCS® introduced the significant difference to our approach and helped to resolve the problems above. The considerable shift was that all agents became knowledge contributors and those "the most experienced" people who also were doing tickets.

It was not easy for us to start new processes and workflows.

How do we train all the agents to work the new way? How would tools support these new workflows?

The consortium created different guides and docs on how to implement new workflows, and it's even possible to purchase training from one of their affiliates and certify agents for compliance with KCS® guidelines. So the training part was covered, although it was quite a task to study those numerous guides.

And the fundamental question we had before launching the Knowledge-Centered approach was: "ok, we are ready to go, but what tool should we choose?"

All the tools presented and approved by the consortium had the only integration with "Big Blue CRM" and were very expensive. Honestly, that's pretty much the same nowadays, almost a decade later.

Yes — we decided to go with our own KCS® tool with KPIs and a flexible feature set :-)

Remember that we had a custom-written helpdesk and the knowledge base software. And even the code itself was old and not optimal, the biggest advantage was that we could add as many new features as we wanted to.

We started with KCS® guides and then passed KCS® practice exams to get the framework deep. I learned and got certified myself, then senior managers, line managers, and team leaders did the same. After that, we built up our internal course for support agents and trained them as well.

The development of the KCS® module with tools for Content Health Check took another six months, and we launched the new framework in 2013 year. Yes, overall, it took approximately a year which I still think was a good result considering that we had zero budget and did all the development by the team of two programmers.

Why? We are almost there, read on!

We got the tool that allowed us to involve all agents in the process of content authoring. We started to link articles to tickets and publish relevant knowledge to our customer-facing portal. It did resolve most of the problems we had initially, but something still was off.

Support agents didn't quite "buy" the new processes.

Agents tended to think that it's somewhat unnecessary and "not their" job to create & publish articles because they were too busy handling tickets. They perceived themselves to be the best technical experts performing a hands-on job, while the knowledge maintainer role didn't attract them so much.

The second thing related to the first one — agents, especially senior experts, were afraid that if they'd shared the knowledge they had with others, they wouldn't be so unique and appreciated as they used to be.

And the third thing, all the agents, from juniors to seniors, thought that if they created a lot of articles and customers would stop coming to support, and, as a result, agents would lose their job.

That turned me to think that our performance review and appraisal system had to be changed. We needed to transform a classical model when agents were awarded for their contribution into ticket handling, quality, and customer satisfaction to something else, which would also consider their contribution into the Collective Knowledge.

Here are some of the benefits we've got:

1. Relevant content. The knowledge base was always up-to-date, with real live coverage of the issues that were important for customers at every moment in time. As a result, customers found solutions in articles and created fewer tickets. That's what we wanted to achieve from the very beginning!
2. Low attrition. Agents were less likely to leave because now they had more interesting tasks to do.
3. Quick onboarding. Yet if attrition happened, we could replace agents quickly as our rich and up-to-date Knowledge base allowed us to hire juniors and get them up to speed in weeks, not months. We've got an effect of Intelligent Swarming.
4. Faster response time. That also drove better First Response Time results and helped to resolve tickets faster. In conjunction with volume deflection, it decreased demand in new support headcount in the long term.
5. Better P&L. Finally, as support organization's costs are mostly about the number of employees, we got our costs reduced, as we needed fewer people to handle bigger demand from our customers.

Was that a happy end? Why does it still read in the past tense? Well, there was a second big part of the story, but it will be another article.