You would think I could find something more interesting to talk about than resolution time, but… I drone on.
To be fair, what could be more important than resolution time for the support & operations center? Well, cost is obviously an important factor in this topic as well, because you can certainly reduce resolution time across all of IT by hiring 5 technical subject matter experts for every specialized technical function in your IT organization if you would only pay $175,000/year + benefits to the top individuals in each specialty. That’s what hospitals have to do!
No, today we would like to propose cost-effective, real-world solutions. So first, let’s define resolution time with it’s nuances and exceptions considered.
Resolution Time (TTR for Time-to-Resolution)
Resolution time (or TTR for time-to-resolution) helps organizations track the average amount of time spent resolving customer (even if the customer is an employee) issues.
The greatest interest in TTR tends to be in the domain of technical support, where organizations and their customers share the common goal of resolving customer issues as quickly as possible. For customers, this means returning to “operational status” as quickly as possible; for employers this meanscontrolling support costs while maintaining customer satisfaction.
TTR is typically measured in hours or days depending on the nature of the product or system being supported, and is measured from the time a support request is logged until the time the case is closed. source:http://www.impactlearning.com/resources/metrics/resolution-time-ttr-for-time-to-resolution/
So, Lee, How do you propose to keep costs stable while maintaining user/employee/customer satisfaction?
Answer — The Key Performance Indicator (KPI). Because, the KPI will help you establish department-specific goals rather than a broad brush view of overall performance which leads to wildly inaccurate information.
But, we’re already have KPIs!
No, you don’t. How am I so sure? First, let’s talk about what a KPI is versus a measure, because there is still a major misconception in the market that needs to be addressed:
You will notice in the figure above that the Key Performance Indicator also includes a goal, status and trend. The goal allows you to create departmental specific measures that are pertinent for each group. For example, you would absolutely want a different Key Performance Indicator for Network Engineering than you would for Desktop Support.
We’ve found that Average Resolution Time for all desktop support Incidents is in the neighborhood of 20 hours vs. 250 for network engineering Incidents (total duration, not in business hours). This is due to the complexity of the technology. So the same thing goes for enterprise applications, storage engineering and many of the deep tier 2 and tier 3 departments that you would expect.
What will these KPIs help you to do? Prioritize performance by criticality of departmental need… so that you don’t need to hire 5 SMEs for every technical discipline, but prioritize organizationally which resolution time goal is most important by department.
So, can you create these KPIs manually in each report? Sure you can, but the effort is so daunting, that we would recommend you consider pre-built solutions that allow for configurable goals rather than pursuing a multi-month project to build them out in each report and dashboard.
Due to length, we don’t get into the other components of the KPI today in this blog, but look for additional considerations in upcoming posts! And, to see how we have implemented Key Performance Indicators contact us today., or visit our YouTube Channel.