Understanding our metrics

Last week, I defined the three KPIs I believe are what you need to understand how well your support department is operating. Defining them, however, is just part of the job; if you don’t understand what they are telling you, you might as well not bother measuring at all. Let’s look at each in turn:

Resolution rate

Resolution rate tells you about the capabilities of each tier. As I said last week, a fairly common target number is for tier one to solve seventy percent of incoming tickets, and tier two to solve seventy percent of the remaining tickets, resulting in an aggregated ninety-one percent resolution rate. While it would be great if these targets were met, it is more important to understand why they are not. A few factors to consider:

• Staffing situation
• Qualifications and understanding of the field
• Access to perform tasks
• System documentation
• Work load

Any talk about a lower than targeted resolution rate should take historical data into account. While the above list is certainly not exhaustive list, it is, at least, a good place to start. I would also posit that, if you are constantly having to work longer hours because your backlog keeps growing, the issue is likely to be one of being understaffed, that youR staff isn’t performing as they should or (and I believe this to be the most likely explanation) a combination of these two.

Quality

Quality, expressed as the percentage of closed tickets whose resolution was correct and approved, This can be a bit tricky to measure, and we generally need to depend on other metrics to give us an idea of the quality delivered. As I indicated last week, making it an active measure can often be counterproductive, which is why I tend towards passive measurement instead.

Like resolution rate, the result of the quality measurement should be read with historical data in mind. While it is objectively true that having 40% of tickets fail this measurement, it that is an improvement from 45%, you know that you are at least on the right path, and that the treatment you are applying to a problem is having an effect.

Time

Time, expressed as the average time a ticket spends in our system (from registration to closure), both in aggregate and per section or tier, tells you something about the spare capacity at each tier. You should look at both the aggregate and at subsets of this data. You may find, for example, that the mean time is two days, but that the median time is four hours. You may find that you have a very small number of tickets taking a disproportionately long time to resolve, and so on.

You may find that some consultants are spending far more time than others. If and when you do, you must ask why this is so. While one explanation might be that they are underperforming, another plausible explanation is that they are assigned particularly complex cases, which needs more time to resolve. This is the support world equivalent of the very best surgeons typically having higher than average mortality numbers.