My examples in this Metric of the Month will focus on desktop support, but the MTTR metric is equally applicable to the service desk. Please note that I make a distinction between incidents and service requests. A desktop incident is typically unplanned work that requires the assistance of an on-site technician to resolve. Common examples include break/fix requests for a laptop computer, a printer or server failure, connectivity problems, or other issues that cannot be resolved remotely by the level 1 service desk. By contrast, most desktop service requests represent planned work. Among the most common desktop service requests are move/add/changes, hardware refresh/replacement, and device upgrades. MTTR as discussed in this article refers specifically to incidents, not service requests.
Why It’s Important
As you know from prior Metric of the Month articles, service levels at level 1, including average speed of answer and call abandonment rate, are relatively unimportant. They have little influence on customer satisfaction. The same, however, cannot be said of service levels for desktop support. In fact, MTTR is one of the key drivers of customer satisfaction for desktop support. This makes sense, as a user may be completely down or forced to use workarounds until their incident has been resolved. This, in turn, has a significant impact on their overall satisfaction with desktop support.
The figure below shows the relationship between customer satisfaction and incident MTTR for a representative cross-section of global desktop support groups. The strong correlation between MTTR and customer satisfaction is readily apparent.
Inasmuch as customer satisfaction is driven by MTTR, many desktop support organizations take steps to actively manage this metric. Although the user population density and hence the travel time per incident cannot be controlled, other factors affecting MTTR can be managed. These include maximizing the first visit resolution rate (comparable to first contact resolution rate at level 1) and routing desktop technicians in real time. This latter technique allows an organization to effectively manage the incident queue by dispatching and assigning technicians based on the proximity, urgency, and geographic clustering of incidents rather than on a first-in-first-out (FIFO) basis, as is common in the industry. This has been shown to significantly reduce the MTTR for desktop support incidents.
Benchmark Data for Incident MTTR
Industry data from MetricNet’s global benchmarking database shows that the average incident MTTR is 8.40 MTTRbusiness hours, but ranges widely, from a high of 33.67 hours to a low of 0.67 hours (shown in the figures). This wide variation is driven by several factors including the ticket backlog, user population density, which impacts travel time per ticket, and the complexity of tickets handled, which impacts the work time per ticket.
In a high-density user environment such as a high-rise office building with lots of cubicles, the technician travel time to and from the site of an incident is generally short (e.g., less than 10 minutes). This results in shorter MTTRs. By contrast, technician travel time for users who are spread out over a broader geographical area (think desktop support for a retail bank with many branches in a given region) is often significantly greater and will increase the MTTR accordingly. Likewise, more complex tickets result in longer work times and correspondingly higher MTTRs.
As with level 1 service levels, performance targets are generally established for desktop support MTTR. Due to variations in desktop environments from one organization to another, there is no standard performance target for MTTR. Nevertheless, some of the more common performance targets include 80 percent of incidents resolved same day/next day, and 80 percent of incidents resolved in 8 business hours or 24 clock hours.
Join me for my next Metric of the Month article, where I will explore the cause-and-effect relationships for desktop support KPIs.