In a comment to the previous post, titled “The Pain Report”, my long time friend and colleague David King made an excellent point that is worth repeating. The importance of any metric is not in a single value, but in the way it develops over time. This is how improvements or deteriorations are determined and this is how support organizations can preempt potential high visibility situations before they become so.
I have written about metrics and benchmarking in the past, that post and especially the links it contains are well worth visiting.
One of the people I worked with in the past used to produce what he called “Pain Report”. This report attempted to predict the customers (or sales people) that would explode next and give support managers a way to proactively address problems.
The report was basically a weighted sum of the amount of time all cases were open. Here’s how it works:
- Assign a weight for every severity level you have. The more severe the case, the higher the severity. For example, with a four level severity scale a possible a possible scale can be:
- Now multiply the number of days each of the customer’s cases have been open, and what you have is the weighted number of days for every case
- Sum the numbers you received, and you receive the customer’s pain index
The weight numbers in the table above are a way to assign relative urgency to the different severities, play with them and determine the weighting that works for you. Here is a sample of two customers’ pain report that demonstrates the influence of higher severity cases on the pain index:
Both customers have an identical number of cases open, and the total number of days is similar. The only difference between the reports are two higher severity cases that customer “A” has.
Now, this report does not attempt to predict the next angry phone call our CEO will receive. There are more variables at play here, from a pending deal to total lack of good will on the customer’s side. But, it does give us an additional perspective on the caseload and the way it is broken down by customer, and helps us diffuse potential trouble spots before they materialize. It will probably be far more useful in very high complexity environments, where customers have multiple cases open at any given time and support management needs to find a way to make sense of their workload.
Have you implemented such a report? Do you think it will useful in your environment?