Metrics_ How to Improve Key Business Results - Martin Klubeck [83]
How will it be used. You might think this answer would be simple and obvious; it would be used to answer the questions. In this particular case, it would be used to communicate the health of the Service Desk, from the customer's point of view.
How it won't be used. Most people want this to be obvious also, expecting not to have to answer the question. Of course I had to answer it.
It would not be used to differentiate between analysts
It would not be used for performance reviews
It would not be used to push the team of analysts to reach different levels of performance—in other words, the measures wouldn't become targets to be achieved.
Customers of the metrics. The customers of this metric (Health of the Service Desk) was first and foremost the service desk itself. The manager and the analysts were the owners of the data, and they were the “rightful” owners of the information derived. Another customer was the director of our support services (who the manager answered to), the CIO, and finally the executive. All of these were customers. Each customer needed different levels of information.
The data owners (analysts and manager) could benefit from even the lowest levels of the data. The director would need to see the anomalies. She would want to know what the causes of those anomalies were. The CIO would want to know about anomalies that required his level of involvement. If the Service Desk determined that it needed an upgrade to their phone system, a new automated call system, or an expert system, the funding would have to be approved by the CIO. The data would help support these requests.
The CIO would also want to know about any trends (positive or negative), or anomalies that might reflect customer dissatisfaction. Basically, the CIO would want to know about anomalies that his boss (the executive) might ask about. Most of the time the executive would ask because a key customer or group of customers complained about a problem area. The CIO shouldn't hear about the anomaly from his boss.
The same can be said of the executive. If the service's health was below expectations, and it ended up reflecting back on the parent organization, the executive would rightly want to know why and what was being done to make things better (either repeat the positive experiences or eliminate the negative).
Analysis. Besides the planned analysis, the results of the information would have to be analyzed for trending and/or meaning. Now that we had the ground work laid out, it was time to dive a little deeper. We had to collect the data and analyze it to ensure our initial guesses of what we'd use were on target.
Availability
We started with the abandoned call rate for the service. When we looked at the data shown in Figure 9-1, I asked the manager (and the staff) to perform a simple litmus test. I asked the manager if she thought the department was unresponsive to the customer. Was the abandoned rate too high? If it was higher than expected, was it accurate? If it was, why was it so high?
Figure 9-1. Abandoned call rate
The manager had heard many times before that abandoned rates were standard measures of performance for call centers. When she looked at the data she said it “didn't feel right.” Not because it cast the department in an unfavorable light, but because she had confidence that her unit was more responsive to the needs of the customer than the rate showed (the data showed that the department was “dropping” more than two out of every ten calls).
This prompted the proper response to the measures: we investigated. We looked at two facets—the processes and procedures used to answer calls and the raw data the system produced. The process showed that calls that were not answered within two rings were sent to an automated queue. This queue started with a recording, informing the caller that all analysts were busy and one would be with the caller shortly. It was telling that the recording provided information about any known issues with the IT Services like, “the current network