When conversing with heads of support or other company representatives during various conferences, webinars, or private discussions, I sometimes come across the following statement: "We already engage in knowledge management. We maintain a knowledge base that is diligently filled by dedicated content writers or support agents." In certain instances, some companies even follow a quasi-KCS process, where support agents are required to document their solutions within the knowledge base.

This question invariably follows. These individuals are often confident that their knowledge base practices are solid, adhering to the best standards, leaving no room for improvement. They employ documentation best practices to craft exceptional articles, and that much is true.

However, the real challenge lies in assessing the effectiveness of the knowledge base itself. Only a handful of managers have genuinely contemplated this. Or if they have, it's been approached in a somewhat empirical manner – for instance, when confronted with an ongoing issue that triggers a deluge of tickets (usually tied to a malfunctioning service or feature). In such cases, an article is created to address the matter, and yes, it does indeed reduce that specific ticket influx, which is clearly visible.

And in the initial stage, there might be a certain number of articles created to address frequently asked questions and provide how-to guidance. And... that might be the extent of it.
However, when there's a dedicated team responsible for content creation, they can eventually find themselves facing a crisis. Content managers are perpetually haunted by the question, "What topic should I cover in an article?" This query becomes increasingly challenging to answer over time. The situation is even more challenging when support agents are tasked with article creation. Their focus tends to gravitate toward best practices in handling tickets, rather than thorough documentation of issues, due to their inherent mindset.

So, what's the outcome? Yes, the knowledge base exists, and it's partially populated. Yet, nobody truly knows whether it's worth sustaining these efforts or not.

Interestingly, if we were to ask customers, we might be taken aback by their response – they don't use the knowledge base because it primarily contains generic solutions. They always seem to encounter something "specific," which leads them to prefer reaching out to support. This ultimately generates increased support volume and costs for your organization.

However, what about those who claim that their support agents are already engaged in content creation?

As is often the case, the devil resides in the details. Mere inclusion of a rule in the agents' workflow, urging them to document each and every issue, doesn't suffice. Even if they do not resist (which is quite common) and agree to contribute to the knowledge base, you'd be astonished if you started measuring the documentation of every single issue. The figure you might encounter could fall within the range of 10% to 20%. This figure directly reflects your knowledge base's coverage – in other words, the likelihood of customers finding a solution should they encounter an issue.

Why does this discrepancy exist? Indeed, the answer comprises several factors:

• Nature of Support Agents' Mindsets and Approaches: They often hold the belief that not every case requires documentation. They tend to assume that customers possess the necessary insights and might provide answers to seemingly obvious issues, deeming them unworthy of documentation.

• Perception of Job Role: Many do not perceive content creation as part of their responsibilities. They feel valued, incentivized, and acknowledged primarily for their ticket handling prowess, not for content generation.

• Time-Consuming Process: Creating and publishing precise content might be perceived as time-consuming, adding to their workload.
  

Herein lies the second difference – the process of content creation demands control and meticulous measurement. Achieving this entails two crucial steps:

1. Efficiency Control and Measurement: The process itself must be closely monitored and assessed for its effectiveness.
2. Motivation and Incentive: Agents must be equipped with the appropriate motivation and incentives to produce high-quality content.
   

Let's suppose you've initiated the process control. However, it's not long before you begin to receive complaints from agents, citing excessive time consumption in article creation and publishing. This, in itself, distinguishes traditional "waterfall" knowledge management from the KCS approach.

Unlike the traditional method, KCS doesn't necessarily mandate the publication of every drafted article. Instead, it suggests creating drafts as is, employing a simple copy and paste approach:

• Symptoms: Detailing how customers describe the problem in a ticket.
  
• Cause: Optionally, providing a description if the reason is identified.
  
• Resolution: Copying the response sent to the customer within a ticket.
  

Typically, creating such drafts takes only a few minutes or even seconds.

The pivotal rule to remember: Whether crafting your draft or utilizing someone else's, it must be linked to the corresponding ticket to initiate the re-use collection process.

Only after accumulating several re-uses for a draft should you contemplate refining and publishing it to your customer base.

Usually, a mere 20% of drafts end up being published.

Another crucial aspect involves measuring the outcomes of your content creation efforts and assessing how effectively your content contributes to the achievement of your ultimate goals. These goals can vary depending on the role. For example:

Support agents or supervisors may seek to minimize the effort required for routine tasks, aiming to avoid boredom or overwhelm. In their case, a reduction in volume serves as a meaningful metric.

The Head of Support might also focus on demonstrating that their activities are driving the volume reduction. Here, well-measured deflection can establish a clear link to volume reduction, resulting in reduced team workload, diminished extra tasks, improved employee Net Promoter Scores (NPS), and ultimately enhanced Customer Satisfaction.

COOs, CXOs, or VPs may additionally be concerned with automation and cost optimization, especially in the face of budget constraints. For them, metrics like improved team capacity, reduced volume, and ticket deflection leading to cost savings take precedence as key performance indicators (KPIs).

For a more in-depth exploration of this topic, refer to this article.

If you happen to work in a software company, you might have heard something from your R&D colleagues like: "Give us the top 10 issues, and we'll address them in the product." Sounds simple, right? Well, when it's the top 10 bugs, maybe it is – although even then, prioritization remains a question. Critical bugs are usually visible and impactful, and they tend to get fixed relatively swiftly. If the engineering team is requesting the top 10, it implies that all critical and visible issues have already been resolved, and now they are seeking other challenges.

This inquiry might arise due to the CEO's concern over support costs and a desire to enhance the product to prevent them. Or, the engineering team could be grappling with the dilemma of selecting features for the next iteration, lacking a clear roadmap. In any case, this intent is commendable, and Support organizations employ diverse strategies to address it. Some invest significant man-hours in reading through tickets, eventually compiling a list that might result in one fix being implemented within half a year. Others attempt automation by labeling each ticket with predefined tags.

Can you guess which tag ends up being the most popular over time, regardless of the company's focus or product type?

This occurs because predicting the future is an elusive task. Regardless of your expertise and the tags you devise, there's no way to cover every potential case.

However, how can KCS make a difference here?

Remember our agreement to link an article to every ticket we handle? This is not only for re-use collection but also to build an automated taxonomy of the top 10, 20, or 30 cases – essentially, whatever cases Product Management and R&D require for analysis, whether they are bugs or not.

Articles with the highest number of linked tickets convey a clear message:

• These are the precise pain points customers are grappling with, whether it's malfunctioning features, poor user experience, usability challenges, or product intricacies.
  
• Such issues drive customers to seek support, indicating dissatisfaction with a product they struggle to use. In the worst-case scenario, this dissatisfaction can lead to churn.
  
• Each re-use signifies a support ticket, translating to a cost for the company. Improving the product would lead to fewer incoming tickets and reduced expenditure.
  

The beauty of this approach lies in its efficiency. There's no need to spend endless hours re-reading tickets or brainstorming and validating tags.

In conclusion, the Knowledge-Centered Service (KCS) approach shines as a superior alternative to traditional knowledge management. Its dynamic and collaborative content creation, efficient resource allocation based on re-use, systematic measurement of impact, alignment with product improvement, and engagement of all stakeholders set it apart. By fostering a culture of continuous learning and improvement, KCS not only enhances customer support but also propels organizations toward optimized efficiency, innovation, and ultimately, greater customer satisfaction.