Unicorn or Narwhal? How does your Client Experience measure up?
If you ask most MSPs, they’ll tell you they believe their Service to Clients grade is an A+.
However, in taking a deeper look, reality paints a very different picture. One where:
1) Chaos reigns
2) Client Churn is higher than perceived
3) Billable Hours are being wasted
When Owners talk about how their Service Delivery Team is performing, they focus on the symptoms without a deeper understanding of the root problem. Symptoms like:
1) Techs not knowing what to work on next
2) Not fully using the PSAutomation software, they are paying so much for
3) Noisy, Complaining, Disruptive Clients
Some Owners believe that their Service Delivery Operation is doing exceptionally well (Unicorn).
But how can you tell if it is not performing as well as you think it is (Narwhal)? For that, we turn to LEAN Process KPIs:
1) Inventory => Resource Utilization above 80%
2) Throughput => SLA Performance
a. Intake above 97%
b. Tech Engagement above 95%
c. Completion above 90%
3) Efficiency => Reactive Hours per Endpoint per Month below 1 hour for every 4 endpoints
The problem is that these numbers are very hard to get to: therefore, most Owners have no quantified data to back up their perception.
Inventory => Resource Utilization:
While there is profit on hardware (even if you are a high-volume VAR and rely on Vendor Kickbacks) and licensing/subscriptions, most of what we sell is Labor or, in our vernacular, Billable Hours.
Side note: on Billable Hours: According to Adam V from System Engineering, “If we are entitled to be paid for the work we did, it is Billable Hours. How the Client gets invoiced is not a concern of the Techs. They do not need to know if it is Covered by an MSA or Not Covered. The Cascading Contract Automation determines that. Their responsibility is to focus on the Clients and not worry about Invoicing. There are only two types of Non-Billable work:
1) Non-Billable does not show on Invoice (ex: warranty work where we are fixing our mistake)
2) Non-Chargeable does show on Invoice (ex: Business Development work where we want credit from the Client for the work we have done)
When we do our FREE No-Obligation Autotask PSA Configuration Evaluations, 9 times out of 10 Resource Utilization is below 50%. This includes MSPs who believe their Clients are being served well. What we often hear is that not all the hours are being tracked. As a matter of fact, we have met several MSPs who do not require time entries at all.
How to Know if You’re Delivering Superior Service
I would challenge you on two fronts that Superior Service to the Client is not being delivered (Narwhal, not Unicorn) without Resource Utilization above 80%:
1) If hours are not being tracked or reported, then neither are the documentation or updates to the Clients
2) If you do not know what the Techs did with the hours you are paying them for, then neither does your Client know what they are paying you for
How do you improve Resource Utilization? Resource Utilization for MSPs eBook
Throughput => SLA Performance:
Of all the automation in the PSAutomation software (six), as well as automated mechanisms (dozens), the SLA Automation is the most powerful. With SLA Automation fully configured:
1) Techs will always know what to work on next
2) Stuck Tickets needing Intervention will stand out
3) Superior Service to the Client will be delivered and documented
When I first arrived at System Engineering back in 2010, the SLA performance was 63%. This number represented Tech engagement for the Managed Service Clients only, and the way it was configured was a bogus number.
Bogus numbers are what we see 99% of the time when doing those popular FREE No-Obligation Autotask PSA Configuration Evaluations. When I left System Engineering in 2019, the SLA performance was best in class, all non-project tickets were under SLA management, and churn was 2% (mostly due to Clients going out of business or not being a good fit).
It took five years to figure out how to properly configure the PSAutomation software to bring all non-project tickets under SLA Automation, and another few years to improve the performance not only for Tech Engagement, but also for Triage/Intake and Completion.
Configuring the PSAutomation Software: The path from there to here
Here’s what it looks like:
1) Dividing types of Client requests into 11 different workflows, each with its own procedure and SLA
2) Fully configuring the SLA
3) Designing and building Dynamic, Proactive Dashboards leveraging the SLA Automation
The end results:
1) Throughput => SLA Performance
a. Intake above 98%
b. Tech Engagement above 97%
c. Completion above 95%
For information on how to fully configure the SLA Automation, check out the 2nd tab at the bottom in this document from the Service Delivery Gladiators Community Documentation Library: Recommended Advanced SLA Configurations
This allowed us to not only engage and disengage within expectations but also allowed us to manage the stuck tickets. A Unicorn Service to the Client communicates within 20 minutes of submitting a request, not only who will be engaging but by when. If there was a business case (Payroll printer on Payroll day) that they needed expedited (not escalated) service, we had an opportunity to deliver a Superior Service to the Client.
Efficiency => Reactive Hours per Endpoint per Month: (RHEM)
RHEM is the most elusive yet most critical metric/KPI for an MSP. It is even more elusive than Labor Profitability by Client. The reason it is the most critical is because even if a Tech spends 85% of their time on one ticket that is triaged, engaged, and completed within SLA expectations, the question remains: Is that one Client or all the other Clients needing engagements being properly served?
We usually think of efficiency as improving profitability, but in reality, it is also speaking to moving the Client experience from Narwhal to Unicorn.
Determine whether the Client is efficiently served by asking these 3 key questions:
1) Was the End-User back to productivity as quickly as possible?
2) Were other Client requests waiting engagement engaged on as quickly as possible?
3) Were resources ($$) freed up to improve the operation so future Clients could receive a Superior Service to the Client experience?
I would be surprised if no one agrees that for Service Delivery to be operating as a Unicorn, it must also be operating efficiently. However, there is still the problem of getting to the RHEM number.
The Trouble with Endpoints
The number of tickets and hours spent serving Managed Service Clients are easy numbers to find. But the number of Endpoints is a difficult number to find. And the problem with the number of Endpoints starts with the definition of just what is an Endpoint.
Most MSPs think of how they are billing the Client, but does that cover all Endpoints being served? It may be close enough to track and find efficiency within one MSP, but we need a universal definition to compare one MSP to another or apply the 1 hour of work per 4 Endpoints objective.
Palo Alto Networks:
An endpoint is a remote computing device that communicates back and forth with a network to which it is connected. Examples of endpoints include:
Desktops
Laptops
Smartphones
Tablets
Servers
Workstations
Internet-of-things (IoT) devices
Source: What is an Endpoint? - Palo Alto Networks
This is great, clear, decisive, and a number that the RMM can easily push through to the PSAutomation software.
However, what about Firewalls, Switches, Phones, etc.? I realize some of these are not technically an Endpoint, or in the case of Phones, may not need Endpoint protection, but all of them are devices that we support.
And when it gets down to it, the majority of what we support are people, not devices. I’m okay with figuring that in supporting people, we are actually fixing either the device or the application residing on the device.
Why should we be okay with this? Because we are paid to support and help grow someone’s business - and people are the largest manageable units of that business. By supporting the success of the people through handling Service Requests and Incidents, you are naturally managing the technology that surrounds each of those Client Users. Besides, it takes a Psychologist to fix people, and they are saddled with a lot more education debt than I would like to think about.
I guess for a bottom-line answer on what is an Endpoint; I should call Gary P.
Improving the RHEM number is a two-prong approach:
1) Reduce the average time per engagement
2) Reduce the number of engagements
Reduce the average time per engagement:
Reducing the average time per engagement takes three things:
1) Improving the Techs' skill level with
a. Vendor provided Training
b. Tech led Lunch ‘n Learns
c. Repetition which includes:
i. The Team communicating through a Knowledge Database
ii. Moving more Clients to the MSPs Technology Stack
2) Move more Clients to the Cloud (has reduced our average time of engagement by an hour)
3) Reviewing and Assigning all requests to a Tech with the right skillset
Reduce the Number of engagements:
Reducing the number of engagements per Endpoint includes:
1) Root Cause Analysis (RCA) with mitigation remediation
2) Preventative Maintenance program
3) Replacing poor partners with ones that are more willing to upgrade their networks
Note: while we determine the RHEM number based on devices under management, the efficiency factor can be extrapolated to non-managed Clients. It could be argued that if the Client and Clients devices are not under management, it will take longer to engage.
While this is true, we are still who we are and engage and disengage using the same processes. What takes longer for non-managed Clients is access to their environment and lack of familiarity with their equipment. Besides, who cares anyway? We are compensated by T&M billing, and if it takes longer to support non-managed Clients, that is on them, not us; we still give them our best effort.
Once the # of tickets, # of hours, and # of Endpoints are known, the calculation is straightforward:
# of Hours worked / # of Tickets = Average Technician Effort per Engagement
# of Endpoints / # of Tickets = Average Noise per Device
Average Technician Effort per Engagement * Average Noise per Device = Efficiency Factor (RHEM)
RHEM of 1 = 1 hour of work per Endpoint per Month
RHEM of .5 = 1 hour of work per TWO Endpoints per Month
RHEM of .25 = 1 hour of work per FOUR Endpoints per Month
o Advanced Global’s guaranteed results
RHEM of .20 = 1 hour of work per FIVE Endpoints per Month
o TruMethods claim to fame
After going through this process, you now have an MSP that has reduced Chaos, minimized Client churn, and gets the most out of each and every Billable Hour. And, perhaps most importantly, you can hold your head high because you can confidently know that your MSP delivers a Unicorn A+ Client Experience.
Of course, not everyone can jump on the information above and somehow manage to digest and implement it while performing the million other tasks of an Owner or Operations Manager.
In fact, most can’t. So, if your head is spinning and you could use some help sorting it all out, we are here to help with a FREE No-Obligation Autotask PSA Configuration Evaluation. Email Info@AGMSPCoaching.com for more information on how we can evaluate you.
The elephant in the room:
Who is Advanced Global, and why should we listen to them?
Recently someone we’ve been in communication with since DattoCon 2018, who was faithfully reading our articles, commented that up until a few months ago, “I really did not know what Advanced Global does.” So here are a few bullet points to let anyone interested know who we are and what we do:
1) We Are – the Autotask Global Service Delivery Authority
2) We Help – MSPs thrive
3) We Solve – Service Delivery issues, inefficiencies, and challenges by making sure:
a. Techs know what to work on next
b. Someone is managing all open tickets and driving them to completion
c. The staffing levels are correct, and the workload is balanced
d. Real-Time Time Entry is a cultural habit
e. The Client has a great client experience
f. Profit is maximized
g. Autotask is being fully leveraged
h. The historical data that is in the Autotask software is accessible to benchmark, track & USE effectively
i. The Service Delivery operations can scale
j. Projects are completed On-Time and On-Budget
k. The company can grow
l. MSPs know what they don’t know
4) Our Tools:
a. Autotask “Best in Class” standard build
b. Our MSP robust Service Delivery SOP library
c. Advanced Live Reports
d. Expertise in providing a transformational experience
Note: We are not philosophers; we are doers with 31+ years of Service Delivery experience, bringing real Service Delivery Improvement change, profitability, and Best in Class performance.
We start by offering a FREE No-Obligation PSA Configuration Evaluation.
