The FT Word
The FT Word is a free monthly newsletter with support management tips. To subscribe, click here. The subscription list is absolutely confidential; we never sell, rent, or give information about our subscribers. Here’s a sample.
Welcome to the August 2011 edition of the FT Word. Feel free to forward it to your colleagues. (They can get their own subscription.)
Topics for this month:
- August’s number of the month – 12%
- Hands-on metrics – fighting stale cases
- Our first open-registration training event ever! Register for the Tech Support Skills workshop in Santa Clara, CA on September 12-13.
The Number of the Month: 12%
As reported in the July 2011 issue of Customer Relationship Management, a survey recently conducted by Accenture found that 12% of executives deem their intuition to be “very important” when making decisions about what their customers want. Another 15% like to consult with colleagues (pooling intuitions, perhaps?) and 23% trust their personal experience (is that educated intuition, perhaps?). Simple facts and data and more complex data analysis do garner similar scores, 22% and 17% respectively.
What are you relying on when making decisions? We all like to think that our intuition and experience are well-honed (and that we are gorgeous, and modest to boot) but surely numbers and facts should be trusted and used more. This survey scared me a little, so I thought we would talk about metrics this month.
Fighting Stale Cases
Many thanks to Eeshan Rairkar for suggesting this topic.
Resolving cases expeditiously is a basic component of quality support. Your intuition tells you so, your personal experience bears it out, and your colleagues will back you up, but do run the numbers. Calculate the correlation between case age and customer satisfaction and you will get your proof! Therefore, backlog management is a critical component of well-run support organizations and indeed has been the topic of several newsletters. This time, we turn our focus towards metrics that help measure the backlog.
Idea #1: average resolution time
The beauty of this approach is it simplicity. Simply add up the average age of cases being closed, divide by the number of closed cases, and voila: average resolution time. If this magic number goes up, it means that cases are taking longer to close. If it goes down, cases are closed more swiftly. Simple, effective?
Well, not exactly. As is well known to aficionados of “case blitzes”, the average resolution time metric goes up sharply if you conduct a case blitz or “closathon”, seeming to indicate a problem, but in fact clearing out the stale cases is a good exercise. And even outside case blitzes averages suffer from distortion by a few outliers. Finally, the average resolution time tells you about closed cases, but nothing about stale cases that lurk in the backlog, still open.
Idea #2: backlog ratio
If you want to focus on the backlog, you need to look at open cases rather than the cases that were (finally? mercifully?) closed. So you could simply look at the number of open cases, but that is not a smart choice since it does not scale well. For instance, I have a client with 70,000 open cases, give or take, which would be a crushing burden to most support organizations. But since this particular client opens about 12,000 cases per week, it’s “only” a six-week backlog, a lackluster performance, to be sure, but nowhere near a disaster. Using the ratio of open cases to average volume opened in a week allows easy comparisons as your case volume fluctuates, as you acquire new companies or new products, and over time as the customer base grows.
For highly complex operations such as enterprise software, I find that an ambitious goal is to limit the backlog to two weeks’ worth of cases. So in the example above with a 12k monthly incoming volume the goal would be to keep the open cases to 24,000. With less complex products the backlog should be much smaller, perhaps a couple of days for a customer care (non-technical) team.
I like the backlog ratio very much because it’s simple, yet powerful. (And by the way, resist bastardizing it by eliminating cases from it. Include all cases in the numerator, whether opened for a minute or a year, whether waiting for the customer or an engineering fix. Keep it pure!) But the backlog ratio keeps the contents of the backlog opaque. In particular, it does not say anything about really stale cases versus the normal, just opened, actively researched cases.
Idea #3: average age of the backlog
Reprising idea #1, you can use the same approach to compute the average age of the backlog instead of the age of the cases that were closed. This is an interesting idea since it targets the backlog itself, but it still suffers from outlier effects. And since customers are most concerned about very old cases you really want to find a way to zero in on the old cases..
Idea #4: stale case index
The idea behind a stale case index is to stratify the backlog, recognizing that there is an essential difference between a new case and one that has lingered for weeks, months, or worse. The best approach to a stale case index is custom, matching your particular reality and case mix but the idea is simply to look at cases that are old, not just cases that are open. So if we stay with the idea of a highly-complex support organization, a case that’s two weeks old could be a relatively normal occurrence, but a case that’s (for instance) over a month old would be more problematic. So you could use a ratio of “old-old” cases by dividing the number of cases older than a month by the total number of open cases – and set a danger target, perhaps 30% (for instance, rooted in your current reality), meaning that you don’t want more than 30% of open cases to be over a month old.
The stale case index is useful because it models the age of the “undesirable” backlog. But its weakness is that it allows more old-old cases as the backlog grows, so a better approach would be to construct a stale backlog ratio, learning from idea #2: divide the volume of old-old cases by the average incoming volume.
To reprise the example above, let’s say I have 12,000 incoming weekly cases, 70,000 open cases, of which 20,000 are old-old cases (older than a month). My backlog ration is just shy of 6 weeks, my stale case index is 20/70 = 28%, so not bad, and my stale backlog ratio (old-old compared to backlog) is 1.67, which is very high. Since the overall backlog is old, even though its age may not be horrible per se, the stale backlog highlights the weight of the old-old cases compared to the average incoming volume.
So what should you measure? I would suggest staying away from the simple but misleading average resolution time metric. Use a backlog ration instead and you will get just as much information without the potentially misleading outliers. But if you want to know a little more about your backlog, and you should be curious about it, using one (or more!) stale backlog indices in addition to the backlog ratio would be very helpful. For instance, you could look at: the overall backlog (as a ratio compared to incoming), the old backlog (say cases over 2 weeks old), and the old-old backlog (cases over a month old). Happy measuring!
For more musings about metrics, see Best Practices for Support Metrics.
FT Works in the News
Finally – The Tech Support Skills workshop with open registration
Over the years I have received many requests for an open-registration version of the popular Tech Support Skills workshop – and yes, it’s coming to Santa Clara, CA on September 12th and 13th. The workshop is for support engineers and support analysts and covers all aspects of working with customers, from picking up the phone or the electronic case all the way through resolution. With an open registration you can easily sample the workshop to decide whether to bring it in-house, or train just a handful of support engineers.
You can find a full description of the workshop and register here. Book now to ensure you get a seat. Attendance is strictly limited to ensure a highly interactive experience. (And if you want to attend both the Tech Support Skills workshop and learn about KCS you can register for a full week of fun and learning here.)
Third Tuesday Forum Breakfast – not? – on September 13th
Breaking with tradition and messing with your mind and the calendar, The Third Tuesday Forum will meet on the second Tuesday of the month in September to avoid a conflict with a CSI meeting scheduled for the following week. How daring! If you are based in the San Francisco area (or will you be there on Tuesday September 13th), join David Kay and me as we host Riz Dhanani of OSIsoft, who will speak about recruiting and training high-performing support engineers for a fast-growing, demanding support environment. If you are planning to hire in the next months, or wonder how to train effectively, join us for a PowerPoint-free, spirited discussion. You can register here. The full calendar is here. You can also sign up for the mailing list. You will be the first to know about new events. You can also join the Third Tuesday Forum groups on LinkedIn and Facebook.
Curious about something? Send me your suggestions for topics and your name will appear in future newsletters. I’m thinking of doing a compilation of “tips and tricks about support metrics” in the coming months so if you have favorites, horror stories, or questions about metrics, please don’t be shy.
650 559 9826