This post is part of a four-part series by Adam Krob and Bill Stockton. See also Part 1 and Part 2.
When we left Alice in the last blog post, she was trying to use the same categories she used in the human world to understand Wonderland. She was struggling with her journey, as well, and the Cheshire Cat didn’t seem to be helping...
Alice: Would you tell me, please, which way I ought to go from here?
Cat: That depends a good deal on where you want to get to.
Alice: I don't much care where…
Cat: Then it doesn't matter which way you go.
It might not matter for Alice where she was going, but for our customers, it does. They use our products and services to a specific end. For B2B (business-to-business) companies, that end is better serving their customers. For B2C (business-to-consumer) companies, the end is their own benefit. For those of us in internal IT, it is enabling our company to deliver our own goods and services.
In support, we often lose track of that end goal, the reason we are delivering support in the first place. The way we work has something to do with it. No matter how hard we try, there will always be more cases to answer (a phenomenon my daughter discovered at three years old when she tried to bail water out of a hole near the ocean). Our tools also reinforce this sense of support as an un-ending cycle. We gather data for a particular issue/incident, resolve it, and go on to the next one.
We often lose track of that end goal, the reason we are delivering support in the first place.
Problem management is intended to help us see above the issue/incident cycle to the patterns and trends that connect our customers’ (end users’) issues. This is the true promise of problem management—it isn’t just reactive root cause analysis. There are two ways that we can get on the path leading our organizations beyond reactive.
Micro-Trend Analysis
If you are in an industry with a distinct cycle (yearly, quarterly, monthly), everyone in the support organization can point to specific needs that come up at the same time, over and over. For one financial firm, their clients used the same reports every year for accounting close. Since most of their clients were on the same fiscal year schedule, two weeks before the year end, most customers contacted them to get help with those reports. Support organizations do a relatively good job addressing these high-impact, frequent types of questions/incidents.
There is more information hidden in these cycles, though. Another client saw a jump in the number of searches and cases for their online learning system two weeks before the traditional demand peak. The second time we saw the same jump, we dug deeper. It turned out that the same placement test was administered each year and there was a non-technical problem with the test. It was a less-frequently occurring type of issue, but the impact was very high for a short period of time each year.
The challenge with identifying these micro-trends is filtering out the noise that our most frequently occurring issues/incidents create. Looking at the trends in small date ranges allowed us to find a pattern, one that we would not have seen if we had been looking at reports monthly.
Cross-Product Analysis
Another way to go beyond root cause analysis is to look at the product/service lifecycle across multiple products/services. Some organizations support products/services that are highly customized for each of their customer. For these products/services, it can take a long time to start to see the trends for each individual product or service.
There is still value, however, to start looking for trends across products/services. You might find trends in the top issues reported by customers according to the lifecycle of every product.
Even though each individual product or service has unique technical issues/problems, common issue types/categories can help us target messages to our customers based on where they are in the product/service lifecycle; you could do the same analysis based on how long a customer has used a particular product or service.
Why Should I Use the Knowledge Repository for this Analysis?
There are two reasons why the knowledge repository is uniquely suited for these analyses:
- The knowledge in your repository is about forests, not trees. Knowledge articles distill the core question or customer/end-user need from the conversation in the case/incident record. You are left with the knowledge that applies to more than one situation. Because of their structure, knowledge articles make you think about relationships between cases, products, and services.
- Knowledge articles are categorized specifically to enhance reporting (as Bill Stockton pointed out in part 2 of this series). This categorization doesn’t have to account for how you escalate incidents/cases or the structure of your organization. The categories can focus on common types of issues/incidents across products/services.
Using these two analysis techniques, combined with the rich and relevant data from your knowledge repository, can help problem management start to fulfill its promise—to show us what path our customers/end users need to take and how we can help them along the path.
For more than two decades, Dr. Adam Krob has studied and evaluated IT and customer support structures. While his career spans numerous areas, his core focus has always been the optimal alignment of support with the company's goals and the use of knowledge management strategies, such as KCS, as a tool to achieve these goals. Adam is a pioneer in enhancing overall perceptions of service, and in the transformation of support from a reactive to a proactive enterprise. He is the cofounder of
Klever
, a company dedicated to bringing common sense to knowledge-sharing practices. Follow Adam on Twitter at
@adamkrob
.