Fixing MSP Short-Staffing Part 3: Efficiency
What we’ll cover today:
Intro to Short Staffing Issues
Spotlight on Service Delivery Efficiency
Find the data (yes, it’s really there)
Benchmark!
Analyze: Put it all together
Your no-stress next steps
Over the years, many MSPs have wrestled with what the right staffing level is.
The techs tell us they’re overworked and more techs are needed. But are they really overworked, and is hiring more techs the right answer?
The accountant says they’re underutilized, but are they? If their weekly time sheets are incomplete, how can you tell for sure?
What about efficiency? If the techs worked smarter, not harder, would all the work get done with the existing Service Delivery staff?
These are tough questions and hard ones to answer. If it were easy, you would’ve figured it out years ago!
I’d bet one reason you haven’t answered is because of the time required to do so. We’ve broken down the process into the following 3 components to arrive at the right decision:
Utilization (Supply / Inventory)
Workload (Demand / Sales)
Service Delivery Efficiency
Each of these three components merits a discussion on its own. To that end, we’ll be focusing on Service Delivery Efficiency here.
A Short-Staffing exercise takes a few hours. If you’d like us to walk you through the process to speed things up, email us at Info@AGMSPCoaching.com.
Service Delivery Efficiency:
Service Delivery Efficiency is where the data points - volume of work, the time it takes to do the work, and the number of customers being supported are triangulated.
This triangulation gives us the efficiency of the Service Delivery operation. For an MSP, it’s a difficult number to get to because not all customers are equal.
Noise per Seat would be a better # to level the playing field, but not all of what we support is people. What about the tickets for devices? And how do we account for our customers who aren’t on a managed services agreement?
To resolve this issue, Advanced Global leans on the Reactive Hours per Endpoint per Month calculation (RHEM) to calculate efficiency for our Managed Service customers and extrapolates the efficiency rating across all work.
Finding the Data:
The first challenge is qualifying the data. We know:
How many tickets were created or completed last month
How many hours we worked
But…
Is the volume of tickets higher than it should be?
Did it take longer than it should have?
A third data point is needed here for reference: # of customers, or, in this case, # of Managed Service customers.
We need to limit it to Managed Service customers because not all customers are created equal. To have an apples-to-apples comparison, we need to know a significant quantity of data points about each Customer, i.e.:
·# of employees
# of devices
# of endpoints
While # of employees will technically work, we don’t fix people; we fix things. # of devices would work, but we’d need to be consistent with what types of devices we are counting.
Enter endpoints: Technically, an endpoint is any device at the end of the network. However, firewalls, routers, and switches are significant devices that are part of the network as opposed to being at the end of the network.
That said, because of the amount of work that goes into supporting firewalls, routers, and switches, they’re included in the endpoint list.
Monitors, keyboards, mice, etc., aren’t included because they’re user interfaces to the endpoint and not an endpoint in and of themselves. And lest we forget, printers, scanners, and PoS devices should also be included in the endpoint list.
For the list of tickets, as the word “Reactive” in the RHEM acronym calls out, we’re talking about incident tickets only. While knowing how long it takes to install a WAP or PC is important, it’s not used in a head-to-head comparison to determine MSP best practices.
Benchmarking:
An efficient rating for RHEM of 0.2 is touted as best-in-class. Even a rating of 0.25 is achievable.
But what is this rating? It’s a correlation between how long it takes to fix any one request times the number of tickets per endpoint per month. The less time it takes, the more tickets a tech can engage on. And fewer tickets mean the tech has more time to devote to each one.
It’s a balancing act - tipping in one direction or another can cause quality to go down, either by generating more tickets or by taking more time to remediate…or both.
The target average Total Hours Worked per ticket used to be about 1.75 hours, but since moving most of our work to the cloud, the average has dropped to less than an hour.
While we no longer see an MSP having 1 ticket for every endpoint per month, we still see it as high as 1 for every 1.5 Endpoints. While a RHEM of 0.25 (or 1 ticket per month for every 4 endpoints) is achievable, 1 of 5 tickets per endpoint per month is best-in-class, which is a RHEM of 0.2.
Analyzing:
Putting this together, an efficient rating of 1 would mean that each endpoint would generate a ticket every month, taking about an hour to complete each request.
Achieving a RHEM rating of 0.2 would require either reducing the # of tickets per endpoint per month to 1 in 5 or reducing the monthly average Total Hours Worked per endpoint to 12 minutes.
Most MSPs work on improving in both areas, landing somewhere around 45-50 minutes per ticket per month and 1 in 4 tickets per endpoint per month for a best-in-class RHEM of around 0.2.
Applying:
MSPs improve their efficiency by either reducing the time it takes to complete requests (training, tool improvement, automation, etc.) or by reducing the # of tickets per endpoint via things like RMM scripting, root cause analysis, and preventive maintenance.
Next week, we’ll summarize the discussion and complete the Short-Staffing exercise.
If your actual efficiency is a wake-up call, and you want someone to guide you through the improvement process, email Info@AGMSPCoaching.com to discuss the next steps.
