Full Operational Optimization: What are we talking about?

Recently, I was talking with the owner of an MSP using the Autotask software.  I made the statement that I know what most MSPs need but am clueless as to what they want.  His response was that what he wanted was to maximize efficiency.  My comment was, “Isn’t that the same as Full Operational Optimization?” He responded, “Maybe, but when he hears someone promising ‘Full Operational Optimization’, he prepares for disappointment.  They usually deliver some part of the Operation, but the person does not meet his all of his expectations. 

 

We proceeded to define what Full Operational Optimization means, based on LEAN Process KPIs: 

Based on LEAN Processes, Service Delivery optimization is based on: 

  • Inventory => Billable Hours or Resource Utilizations 

    • 80-85% company average 

  • Throughput => SLA or Mean Time To Resolve (SLA w/o wait states) Performance 

    • SLA: 95% company average 

    • MTTR: 2 business days Company Average 

  • Efficiency => Reactive Hours per Endpoint per Month 

    • 1 hour of Break/Fix work per 5 Endpoints per Month 

 

Many MSPs are running with 10, 20, or 30% wasted billable hours.  Others are struggling with a ticket-created noise level 2 to 4 times higher than other MSPs.   Technician effort averages 1.25 hours while other MSPs burn valuable time hunting for that elusive animal we call Workload balancing.   What these MSPs have in common is that they have no idea which numbers are important, how to find the data, or how the numbers compare to other MSPs when they actually do have them!  

 

This article discusses finding the data in an Autotask database and benchmarking the information against what Advanced Global MSP Coaching sees across the Autotask MSP community.  The result is information that lets an MSP know if the service delivery operation is optimized or not.  And if not, where they’re operating out of tolerance.  For example, three years ago, the average technician effort – the average total hours worked per ticket – ran about 1.75 hours, but today it’s less than 1 hour. 

 

 

Over the years, most MSPs have wrestled with solving one of the Universe's great mysteries:  is My MSP's service delivery team running efficiently?  To answer this is a complicated equation that considers available billable hours, Workload, technician effort, and noise per client.   

 

You can send us an email here to learn more about our MSP Service Delivery Efficiency Evaluation priced at $997 

 

Available Billable Hours: “If it’s not documented, it doesn’t exist” 

Many MSPs often utter the phrase, “If it’s not documented, it doesn’t exist.”  This is a great mantra and one we should leverage more often. The reason is if technician time isn’t entered in the timesheet, then there’s no way to accurately measure available billable hours.  If a client request isn’t captured in a ticket or project, it was never requested.  If the executed work isn’t captured in the time entry summary notes, it was never done (nor billed).  We’d lobby for a world where techs that don’t put in time entries don’t get paid for that work - wouldn’t that forever change the way we do things!? 

 

This lack of proper time documentation happens often and all-too-perfectly illustrates the crux of the problem.  Many times, while working with MSPs in a Service Delivery Performance Improvement program, when we get to resource utilization and grill the Service Manager on what the techs are working on, 9 times out of 10, the first thing they say is “the techs are very busy, and that report doesn’t show all the work they’ve done.” This, in turn, lights up the owner, and […beat…] magically, all time appears reported in the timesheets. 

 

Looking at one week’s worth of timesheets just doesn’t give an accurate picture of available billable hours.  On any given week, a single tech, a team, or the entire MSP could be having a good week or a bad week. It could be a holiday or heavy PTO week. It’s better to have a bigger sample size of the period.  Instead, take a look across the last three months’ resource utilization to determine the actual available billable hours. 

 

Workload:  T3 - Tasks, Tickets, & Time  

Workload consists of the time entries captured in completed tasks and tickets, of course, but for many MSPs, there’s also a lot of time that’s not being tracked and accounted. 

 

RMM Alerts: 

Very few MSPs account for all the time it takes to address the RMM alerts for their full Managed Service clients. The RMM, and other monitoring utilities, can create thousands of tickets each day, and it takes time to determine whether they’re just noise or real issues. It also takes a billable resource to make that proper determination. But then, how do you capture the time?  Do you create a time entry for each of them?  Um, that would take longer to capture the time than to do the review itself. What about just saying “we’ll just get it done” and skip the whole ‘documenting what we actually did’ dance?  Or the capturing the time it takes to review alerts thing?  Is that good business and providing superior service to the client?  How ‘bout capturing a block of time in the Zero account and applying the time well spent across all your Managed Service clients; now that is the best of both worlds! 

 

Preventative maintenance: 

So, what is preventative maintenance, and who does it?  The more mature MSPs have a regular network checkup, keeping an eye on all the good stuff like endpoint O/S patching, current AV definitions, properly-licensed applications, and good data backups. The best-in-class MSPs also take the time to track and analyze whether any production equipment is approaching or already at EoL, triggering the opportunities to reinforce the value of your offering. These gladiators may even look over recent ticket history for any recurring incidents in dire need of RCA. And how’s all this time captured?  In a recurring ticket, as documentation, or not bothered with at all?  (After all, this kind of important activity is likely covered by the overarching Managed Service offering, so the client is not being invoiced for this work anyway, right?) 

 

New client onboarding: 

Wait, wouldn’t this billable work be captured in a task or ticket?  Not when it’s part of pre-positioned scheduling! When it’s pre-positioned scheduling, it needs to be considered as part of the future, committed workload, in addition to everything else. There are no worries here that this allocated time will go unused. If it’s not sold to a new client for onboarding purposes, it can be repurposed to, say, work through ticket backlog (you do have a ticket backlog list, right?). We just need to determine how much time we’re reserving for new clients and define the window of when to release it if a sale doesn’t come through. Of course, we add this to the unaccounted time for any service delivery optimization calculations. 

 

Non-billable work: 

Non-billable work is not typically a factor considered in a service delivery optimization calculation unless the MSP has the techs doing non-billable work. If this is the case, then shame on them. They should hire a service coordinator!  A service coordinator will make the techs at least 10% more efficient, yielding at least 10% more available billable hours. If you consider that a single billable hour is worth about $150 in top-line revenue, then 4 more hours each week per tech is worth about $600. 3 Techs is $1,800/week. Most service coordinators would love to make $1,800 per week with burden, or about $900 without burden ($46,800 per year).  And one service coordinator can manage the non-billable workload of about 10 techs. So, it makes a lot of sense to hire a service coordinator rather than hiring a 4th or even an 11th Tech, all outside your Right-Staffing calculation.  

 

The constraint of available hours: 

And then there’s the hardest component of all:   How much time would be in the task and tickets if there was an infinite amount of available billable hours?  Parkinson’s Law says the existing workload would just spread out to fill the time. Our experience is the total hours worked are understated due to the limited availability of existing techs. The total hours worked can be adjusted by multiplying it by the ratio of created to completed tickets.  The reason the adjustment is needed is because the backlog ticket list is either increasing or decreasing. 

 

Determining MSP service delivery efficiency: 

This is the hardest of the quadrangle calculation to determine due to a triangulation within this one component. To determine efficiency, you need to run this triangulation independently, and then apply the various outcomes to the larger calculation, which provides multiple outcomes. So, the best right-staffing answer comes with an “it depends” answer (not to be confused with the adult diaper, but for those who have gone on before us, they might have liked the comfort and support!)  

 

The 3 interacting components of the efficiency calculation are:  

  1. Technician Effort: The average Total Hours Worked per Client Request (Ticket or Project) 

  2. Noise per Client:  The average # of Requests per Client 

  3. Automation: Things the PSA software could do for us to free us up to do billable work 

 

Technician effort: 

It used to be that the average total worked hours per request was around 1.75 hours. Today, with everything moving to the cloud and the amount of a single pane of glass between our tools, not to mention better tools in themselves, the average total worked hours are <1 hour per request.  

 

Noise per client: 

This one should be easy, but not all clients are equal!  We had one Advanced Global client who was certain their newest, largest client was taking up most of their service delivery support resources. When we looked at the data, we saw that they did create the largest number of tickets, but when we divided the number of tickets by seats, they were actually one of the quietest clients, even though they paid the most for services on a client-by-client basis. So, noise per client is not the best metric; noise per seat is far better. If you can verify the number of employees across all clients, including the fringe T&M clients, then you know exactly how many employees you’re supporting. But for many MSPs, this is asking too much.  So maybe focusing on endpoints is the answer? 

 

Endpoints for our full Managed Service clients are known. That’s why, when it comes to efficiency, so many MSP advisors quickly look to the noise per endpoint metric and extrapolate it across the rest of the client base. This makes sense, but only to a point. The argument could be made that we are more efficient at providing services to our fully-managed clients than to our T&M clients because we know them better and have better documentation on them.  I mean, IT Glue is up to date, right?!  But as we all know, garbage in is garbage out. While we may be more efficient at providing services to fully-managed clients, it’s the same systems and the same team providing the services, so it’s better to extrapolate it to all clients than to make strategic decisions on bad data in the first place. 

 

Automation: 

How much time is saved with automation, and what kind of time is saved? The very definition of automation (having the PSA software do non-billable work for us) implies there is no direct impact on your right-staffing calculation. In fact, it is an indirect impact in that it provides more available billable hours, therefore impacting the calculation not in efficiency but in utilization. 

 

Summary: 

To determine service delivery optimization, an MSP needs to determine the workload, divided by available billable hours for each efficiency scenario. 

 

The different efficiency scenarios to be considered are: 

  1. Efficiency stays the same 

  2. Efficiency is improved by reducing technician effort 

  3. Efficiency is improved by reducing the noise per endpoint 

  4. Efficiency is improved by doing both 2 & 3 

 

Email us today to learn more about our MSP Service Delivery Efficiency Evaluation for $997 

 

 

Steve