Life-Cycle Analysis

Tracking the amount of time it takes from when a ticket is opened to when it is closed — often referred to as “time to close” (TTC) or “mean time to repair” (MTTR) — is one of the most commonly measured service-desk metrics. Many organizations tie this metric to an SLA and guarantee customers certain performance based on it (for example, all Priority 2 tickets will be closed no later than 6 hours after they’re opened). While knowing what this metric is serves as a good starting point, the real value is understanding the underlying reason why this number is what it is — and more importantly, what improvements you can make in order to reduce it.

With that in mind, consider your current reporting capabilities and whether or not you can answer the following questions:

  • Which customer contributes the most delays to your TTC?
  • How does your TTC vary by analyst? By assignment group?
  • Does your TTC vary by day or week of the month? By year?
  • Are there certain assets or categories that skew your TTC metric?

By being able to quickly view your standard TTC metric through a variety of different life-cycle lenses such as these, you can pinpoint which segments of tickets in your service desk are the biggest influencers of your overall TTC.

Subsequently, you can target those specific segments for improvement, and once you’ve done that, just imagine … All those pesky penalties you pay when you miss your SLA targets? Gone.

Those unhappy customers waiting and waiting — and complaining and complaining — to be back up and running? Gone. Your boss hearing about how satisfied clients are with the service you’re providing instead? Check. Saving the company money because the help desk is performing better? Check. Suddenly getting more funding for your department? Checkmate.

Case Study

A large service provider established a “bring your own device” (BYOD) policy for smartphones that enabled Blackberrys, Androids and iPhones to be supported by the corporate help desk. Having a workforce that depended on these phones while away from the office, a strict goal of 2-hour ticket resolution was set for all non hardware-related smartphone issues.

After the first month, the average time to close smartphone issues was 3.8 hours, which clearly did not meet the target. Instead of simply accepting the baseline and changing the goal to 4 hours, however, management was able to explore the data on all the smartphone issues that occurred in that first month of service and come to understand what factor was contributing most to the 3.8-hour TTC.

After segmenting the tickets into those that closed quickly and those that took longer, a key insight appeared: A small group of analysts consistently took longer to close smartphone issues than others. After delving further into this insight, it was discovered that analysts who had a personal Android phone didn’t do very well resolving iPhone issues, and those with iPhones performed even worse at resolving Android issues.

A quick policy was established to identify experts on the team for each device type supported and properly assign smartphone issues to those best equipped to handle them. The impact was felt immediately, and the result was also apparent in the monthly TTC metric — a number that was a dramatic 20 percent lower than the original 2-hour resolution target.

In the next chapter, we will talk about the ticket category tsunami warning as a possible data blind spot in service management.

Questions? Let’s talk about your use case and see if DashboardFox is a fit.