• Choose a category
• All
• Classic-Fiction

Depending on the tools you use for capturing speed, you can report the exact time it took to resolve a problem. For example, you could use the automated call system to identify the time the call was initiated (instead of when the analyst opened the case file in the trouble call system). You could use another call system to log the day and time the analyst completed the final call to the customer, closing the case (assuming it took more than one call). You would have to have a means of connecting the case information to the call system. This level of accuracy is unnecessary in most cases—it is enough to log the time the case was opened and closed. But even if you had the accuracy described, the customer may “perceive” the resolution to take longer than it actually did.

I can assure you, showing the customer “proof” that the case actually took less time than he perceived it to take will do nothing to improve the customer's level of satisfaction nor change his opinion of how fast the department works. To the customer, perception is reality. And while it is useful to know the objective reality—you also have to address the customers' perception.

Even if you meet your Service Level Agreements (SLAs), assuming you have them, a case may be perceived as taking longer than expected.

Note: If you can get SLAs for your services, these are great starting points for documenting the customers' expectations for a service or product. If you have them, stay alert. You may find that although the customer agreed to the SLA, it may not reflect their expectations, not as time passes. It may not even reflect their expectations the day they are written.

For our metric, I collected the time the case was opened and time closed. Our trouble call system had the capability of toggling a “stop clock” switch. This function captured the amount of time the switch was toggled in the “stop” position until it was toggled back to “active.”

This was very useful as it allowed the worker to capture the span of time the customer did not expect work to be performed. This was not used to subtract evening hours or weekends when the desk was closed. The customer, while not necessarily expecting work to get done during this time, did consider “down time” as part of the total time to correct their problem. The stop clock was used for specific, well-defined instances, such as

The customer was not available (on vacation, out of town) so the case, while resolved, could not be closed.

The customer requested that the resolution not be implemented until a specific time. Like installing new software because she didn't want the upgrade to mess up her current work.

In the case of a scheduled fix, I used another data point, scheduled resolution time, which was used as the start time in the formula. I rarely found the stop clock being used in this instance although it could also work. If you use the stop clock or scheduled resolution times, you still must capture the start time and close time. You have to keep the source data because you don't know when you'll have a customer argue that the real time should have been from the time of the call, or you may find that you want to show how far in advance you're getting the requests for future resolutions. Are you getting the request a day before? A week? Or a month before it's needed? What are your processes for dealing with these requests? How do you ensure the work gets done on schedule? The source data, including actual start and close times will help in checking your process.

So we started by looking at the Time to Resolve compared to the customers' expectations as shown in Figure 9-3.

Figure 9-3. Time to Resolve: the percentage of cases resolved within expectations

For Speed we also had to make a decision on how to represent the data. We could show the data as the number of calls resolved within expectations. This could also be a percentage. You may notice a trend here. Percentages are an easy way to depict data, especially when combining it with the number of instances used to determine the percentage.