How Agile Metrics Can Turbocharge Service Delivery and Customer Satisfaction

What metrics are your team chasing this week in hopes that they will meet or exceed the organizations’ desired performance and customer satisfaction goals? Number of touches to a ticket? Time to first call back? Percent resolution on first contact?

What if I told you there are only three true primary metrics for all of service delivery, no matter what the business? Everything else is secondary and, although important for gauging and tuning performance, do not lead to the turbocharged results that these three prime metrics can.

To find the answer, we look to this thing known as Agile. At its simplest, Agile simply means continuous incremental improvement of a thing through frequent iterations or releases (new versions). We hear the term most often used in software development and we see it most prominently in our phones.

With phones, you open your favorite app and try to do something, but a bug prevents you from doing it. You can see the Help icon and you type a simple message about the bug to the developers and click send. The next morning when you open your phone, it says there’s an update for your favorite app – you click to allow it to update – and voila! Your app works! Your app was incrementally improved by a frequent release of a new version. This is Agile. And Agile methodologies work in many other processes beyond software development.

The Three Metrics

To describe the three metrics you need, I want to place them in a real-world context. Let’s use these metrics in regards to moving from one apartment to another:

Lead Time

Lead time is simply the total time it took to get a single box unpacked, broken down and thrown into the garage. Lead Time starts the moment the box is unloaded from the truck and set on the floor inside the house. It can be minutes, hours, or days. If you can tell me the average lead time for unpacking your boxes and how many boxes you have, I can tell you how long it will take to be done with the entire moving process.

Cycle Time

Cycle time is the time it takes to actually unpack any given box. It starts when you open the box and start unpacking it in earnest. Cycle Time matters because if you can tell me the average Cycle Time and the number of boxes in the kitchen, I can tell you how long it will take to unpack the kitchen.

Work in Progress (WiP)

Work in Progress simply means the percentage of all the work in front of you (the queue) that is in some stage or status of actually getting worked on. Technically, it is the percentage boxes that the Cycle Time clock has started ticking for. Let’s say you have 10 boxes on the pile (queue) in the kitchen, and you’ve opened and pulled something from 5 of them. Your WiP is 5/10 = 50%. If you continue to open boxes, at some point you’ve got too many open, and it begins to bog you down. You can’t move around, one box is in the way of another, more boxes are showing up, and so on.

A Deeper Dive

Mathematically we can understand why Work in Progress matters because of a formula known as Little’s Law. It simply states that the more WiP you have the longer the Lead Time, and also the queue of boxes piled in front of you. If you recall from the definition of Lead Time, it is directly related to how long it will take to get the entire move-in completed. If Lead Time goes up, we’re going to be unpacking for a lot longer than we want to be.

I’m certain you noticed the mention of the queue getting longer when WiP goes up, so I’ll address that with one more quick example. You’ve already got 5 boxes on your pile, you’re working on 5 (WiP), and the movers are putting another box onto the pile every thirty minutes. If you’re still unboxing the first 5 and several hours have gone by, your pile has now grown by 4 to be 9. Your queue is getting longer because you keep opening another box instead of finishing boxes. Oh, and your floor space is shrinking, too.

Now although Queue Length is not a primary metric, it can’t be ignored in this discussion because it is the most visible sign a customer has of their expected customer experience. Think about how you perceive your customer experience will be the minute you walk into the coffee shop and the queue is to the door. (Coffee runs are the best form of procrastination when it comes to unpacking, so allow me to mix my metaphors.)

Finally, I want to tie this all into your Service Delivery process to have it all come clearly into focus. Before I do, let’s talk about Customer Satisfaction or CSat. It’s all about doing everything we can to provide the very best customer service we can, and hopefully living up to the customers’ expectations for their experience. It’s dealt with much differently if you are the in-house IT support for a corporation than if you are a Managed Services Provider taking care of the IT for other businesses.

Customer satisfaction is a financial obligation, whether you know it or not, and whether you believe it or not. High-level stelar customer service comes at a direct cost to the efficiency of your system and directly affects your bottom line. Most companies try to balance the three out – providing highest possible customer satisfaction without becoming unnecessarily inefficient and while maintaining reasonable profits.

With that said, these three turbocharging metrics force a balance between the three opposing pulls of CSat, Efficiency, and Profit. To see how, let’s correlate them to your customer service process. I will also inject some of what I believe to be best-in-class specific numbers for the metrics.

Lead Time is how long a ticket stays in your system – from the time it was entered by the end user/customer to the time it’s completed. Track it as Average Lead Time, and the target should be 3 business days. With this, if you keep the average Lead Time down, your customer sees that you consistently resolve an issue in a very reasonable timeframe, and you should have good CSat.

Conversely, when any tickets get too long in the tooth and they tend to get touched too many times, the narrative gets unclear, the customer gets frustrated, and too many hours are logged on any one problem. Long lead times for a single issue are often due to failure to escalate, or a missing skill set among the team. Long lead times as an average are due to short staffing or too much WiP. This will affect long term CSat more than anything.

Cycle Time is how many actual hours of work a tech (or the team as a whole) logs in the process of resolving the issue. Aside from finding out where they are in the queue, it is the most visible indication to the end user/customer of what their customer experience might be. Track it as Average Cycle Time and the target should be 45 minutes. This is where the metrics of Percent Resolution on First Contact and Close Rate stem from.

This is very inefficient, and inefficiencies like this directly impact the bottom line. It should be considered that it may be cheaper to just buy the customer a new laptop versus having a tech spend another five hours on it.

Work in Progress is simply how many tickets the team has started working on something in relation to the total number of tickets in the queue. Track it as a percentage and keep it under 50%. We’ve seen that when WiP goes up, Lead Time and queue length go up, resulting in CSat going down. An old WiP saying is: Stop starting and start stopping, or close tickets out before opening more if you can.

My recommendation is to track these three metrics alongside CSat. Bring Lead Time, Cycle Time, and WiP down, and you will see a direct correlation. Oh, and from now on, when you look at a metric – see if you can trace it back to one of these three Agile turbocharging metrics.