Using the Mean Time to Resolve (MTTR) KPI to Improve Your MSPs Bottom Line
Cutting 78% of the wasted Service Delivery time would help most any MSP.
Advanced Global are experts in the workings of Autotask and the Key Performance Indicators (KPI) that are so essential to a profitable MSP, and this statement was never truer than when it comes to the Mean Time to Resolve (MTTR) KPI. Yes, MSPs are somewhat aware of the MTTR KPI, but awareness and the realization of importance are two separate things.
In this article we hope to impart some of our expert knowledge about this elusive KPI that can impact the bottom-line to the tune of cutting waste by 78%.
Want a free copy of our most requested reports? Enter your info below!
Why MTTR is Overlooked
One reason this KPI is overlooked is because Autotask doesn’t have a standard report or widget available. However, the reason we think this KPI is significant is that, based on L.E.A.N. standards, MTTR equates to throughput. Most MSPs overlook throughput because tickets are most likely sitting in a neglected queue or Waiting Customer and therefore there is no apparent negative impact.
We’d like to challenge this belief on two levels:
1) The number of times someone picks up the ticket just to “kick the can down the street” which is a total waste of time
2) Customers most important concern is when are you going to fix my “S…” (Stuff). Most care very little about SLA performance.
MSPs can hide behind SLA performance all day, but the MTTR KPI tells the truth of how well the Service Delivery team is performing.
You Need a Live Report to Retrieve the Data
Finding the data requires a Live Report because Autotask doesn’t provide a standard MTTR report. Our favorite MTTR report is to group the data by Sub-Issue, that way not only does the MSP see how long it is taking to resolve Customer requests, but they can also see which devices in the technology stack are taking the longest to resolve issues. This gives the Service Manager a running start on where to improve the team’s performance.
Keep in mind the key word in this KPI is “Resolve”, which means we’re talking about incidents only. Service Requests aren’t “Resolved”, they are implemented. So, how long should one expect an Incident (Break/Fix, Reactive) request should take to resolve? Jeff Rumburg, a leading KPI expert from MetricNet, (Metric of the Month: Incident Mean Time to Resolve (thinkhdi.com) )says on average two business days. This makes sense when you think that 35% of all tickets are Medium priority with an SLA expectation of 8 business hours to tech engagement and 24 business hours to resolve; with Critical and High having shorter time frames and Standard having longer time frames – two business days on average feels right.
How do your peers compare?
So, how are your peers doing? Without a Service Delivery Foundational Improvement (SDFI), 9-16 business days is the norm. With Advanced Global’s Service Delivery Performance Improvement (SDPI), two Business days is easily obtainable.
One other note about the MTTR report, is that a 6-month trend report serves better than one of shorter duration. Every Sub-Issue can have one bad month. Most of the time, Service Managers need to take their limited bandwidth and focus on Sub-Issues that are historically more than the average, with significant tickets to merit attention, and especially if they’re trending up.
What to do when you spot a Sub-Issue that’s Trending Upwards
So, what to do when you spot a Sub-Issue that’s historically more than the average Business Days to Resolve, have a significant number of tickets, and even worse trending up?
Run a MTTR Detail Report and:
1) If the MTTR average is @ or below 2 Business Days, relax. Something will always be above the Company average!
2) Verify they are indeed Incident Tickets and not a poor Triage process miscoding a Project as a Medium Workflow/Priority request.
3) Look for something common for this type of Sub-Issue
a. Assigned to an unmanaged queue
b. High percentage of escalations
c. Slow vendor response
d. Lots of wait times (Customer, Parts, Vendor, On-hold)
4) Report the findings to the techs, requesting their input
5) Take corrective action to bring the number down
a. Improved Intake/Triage process
b. Improved Tech training
c. Journey Map the Sub-Issue workflow from New to Complete looking for where in the process the tickets are getting stuck – and then fix the bottleneck
The results of the MTTR effort are:
1) Cutting out waste mostly in non-billable time checking in on or managing a stuck ticket. The problem is even more impactful if a Billable resource is doing the Non-Billable work
2) Happier customers reduce the churn down to the national average of 4% of an MSP’s Managed Service customers
3) Less stress on techs, who whether they admit it or not, do worry about stuck tickets
A side benefit of the MTTR is the Average Technician Effort for Incidents, as well as each Sub-Issue. This information is very helpful in building the Automated Estimated Time for each Customer Request that comes in, based on Sub-Issue.
This helps with:
1) Informing the techs when they are in over their head and should escalate to a more skilled technician
2) Which techs are taking longer than others to either steer these types of tickets away from them, or provide additional training – which incidentally is one way to bring down the overall MTTR
