Service level metrics are often measured backward. Almost any course, book, or framework on service management suggests that we assign Service Level Agreements (SLAs) that provide a contract between a service provider (either internal or external) and the end user that defines the level and acceptable delivery time of service.

Is Your Service Desk Measuring It Wrong?

Consider this: If you have a problem that needs to be solved, would you want it fixed quickly, or within a pre-determined acceptable time frame? I am betting you would want that solution as fast as you can get it.

In my opinion, SLAs are often an unnecessary safety net for those providing the service, giving them an excuse to deliver slower than necessary. SLAs and First Call Resolution (FCR), especially for internal service deployments, can set the wrong orientation for the service provider.

For instance, I want my organization to measure how fast we can address the problem instead of defining the acceptable turnaround time to provide a service. Instead of setting a time limit that is acceptable, like 2 hours to respond to a failed piece of equipment, or 24 hours to respond to a question, I want my organization to reach for very close to immediate response – the opposite of the SLA.

The SLA can give service providers the luxury of waiting until few minutes before it expires to start the work.  The IT worker’s engine should not suffer from idle time, and it should not be validated by starting just before the SLA expires.

The IT worker’s engine should not suffer from idle time, and it should not be validated by starting just before the SLA expires.

For example, if there is a two-hour SLA for response time for a computer that will not boot up. Two hours probably seem quite responsive for some organizations, and celebrations will occur by meeting this SLA and satisfying this agreement.

But if we take a closer look, that’s two weeks of downtime in a large organization if this occurred 40 times in a year.  The SLA gives the organization permission to wait for two hours to respond and define that response as acceptable.  If this metric was reversed, we could inspire the fastest response possible, and save many hours of lost work time and frustration.

We may have a highly-paid executive unable to work, or a researcher working on a cure that cannot be tested, or a room full of staff waiting on a video conference to start. As long as IT makes the fix within the SLA’s timeframe, we think it is OK.

However, instead of measuring the outer limit, I want to measure the innermost limit – that is, how fast can we respond?  How quickly can we get the executives, the researchers, and the video conference attendees up and running again?

Another of the metrics, FCR, should only be utilized to identify deficits in knowledge and then addressed by proper training. FCR can be useful to management to see where training may be necessary on the front lines, but in my opinion, is not a good performance metric.

FCR can be useful to management to see where training may be necessary on the front lines, but in my opinion, is not a good performance metric.

In my perfect world, the ‘caller’ should receive a solution as fast as possible regardless of the number of calls or contacts it takes. If FCR is a known metric to the service agent, they may feel it’s necessary to keep the contractor on the line too long to try to resolve the matter on their own, instead of escalating to a better source as soon as it is clearly outside their realm of knowledge.

For example, an employee contacted the service desk because his printer was not working.  It sounds simple, but there are many elements to this problem – it could be a disconnected cable, a driver issue, or a network issue, it could be a printer hardware issue, it could be that the printer was simply offline.

In this case, it was a network issue, but the new service desk technician was not yet familiar with the network set-up. But because he is measured on FCR, he did not escalate quickly and the end user had to help work through all of these issues before the problem was resolved.

Has anyone really ever cared if there was more than one call or an escalation if they received a solution very quickly? Rather than counting the number of FCRs, it would be far more optimal to measure how fast a resolution was provided, and reward the fastest overall responses.

To sum up, swapping the metrics provide for a much better end user experience and a more challenging and quality-oriented work environment for the service provider. After all, a faster resolution is what everyone desires.

Explore More

• Converging User and Platform Centric Agendas: A Case Study
• Delivering Smiles Every Time: A Case Study
• Arkansas’ Easier Path to Financial Aid: A Mobility Case Study
• A Journey to a Better Patient Care Lifecycle: A Case Study in Mobility
• Building a Lean IT Organization
• The Lean M&A for Lean Times
• The Lean Data Center: Just Another Bandwagon?
• Applying Lean Manufacturing Concepts to IT
• Enterprise Storage and Compliance: Feeding the Monster!