Optimal Organizational Structure for MSPs
We left off in the last article talking about:
“The problem is the ratio of Project work, to Field Work, to Preventive Maintenance work, to Break/Fix remediation remains about the same. Whether your Sr. Engineers are on a Professional Services Team or a Collaborative Team across all skill levels, Managed Service Support still disrupts Projects - just like at the 3-Tech shop and above.”
We went on to say that as the MSP staff grows, the Service Delivery Issues remain the same, and fixing them is a lot more difficult the more Techs there are.
This led us to realize that the Optimal Organizational Structure also depends on the Workflow mix. For a shop that does a lot of projects, say 500 or more per year, the Optimal Organizational Structure is very different than for a shop that only does break/fix.
While this is obvious, you should pause to think about your current mix, where you would prefer the mix to be, and then contemplate the growth path from one to the other. Let’s break it down Workflow by Workflow:
Side Note: before we jump in, Segmenting Customer’s requests into different Workflows provides three significant benefits:
1) The Automation software can tell the difference between one ticket and another
2) Staffing Levels for each Workflow can be determined
3) Chaos is driven out of the work environment
Once all Customer requests are segmented, a simple Service Delivery Forecast report will provide data into each Workflow and the staffing levels needed for each one!
Typical Workflows that every MSP encounters:
Break/Fix
In the break/fix world, life is simple. One Workflow, no need to prioritize or triage a ticket. A Customer calls with a Break and the MSP fixes it. If all we did was Break/Fix, life would be hectic, stressful, and boring. We question the competency of a shop that only does Break/Fix as it tends to provide a very poor Customer experience, stunt the growth of the Techs, and introduce a high level of uncertainty for both the shop and Customer.
However, with that said, there are very few MSPs that can get away without some Break/Fix Customers. 20 years ago, the mindset was to get them in the door and upsell them to Managed Services.
10 years later, the rhetoric of Paul D and Gary P changed to a rip and replace mentality. Based on personal experience, you can upsell them, but not with a value statement. What you need is to paint a picture that without a Managed Service Agreement, “Best Effort” means when a Server goes down, expect to wait 3-4 hours before engagement. However, with a Managed Service Agreement, a Tech will engage and stay with it through to completion within an hour.
Note: If you do not know how to organize Service Delivery so you can guarantee 97% of the time when a Server goes down, a Tech will be available to engage within an hour (the average is less than 15 minutes), schedule a call with us, we are happy to coach you through the process.
Managed Service Support
Managed Service Support is not break/fix for many reasons:
1) There is a contractual obligation to the engagement.
2) The relationship and documentation are richer with a Managed Service Customer.
3) There is a commitment to build and maintain the network in such a way that having a Tech at the Customers beck and call is not needed.
4) 24/7 monitoring of the network alerts the MSP before the Customer realizes there is an issue.
5) A strong preventive maintenance program makes the relationship very cost competitive for both the MSP and Customer.
How competitive is a Managed Service Provider over a Break/Fix provider? 3 to 1.
The average MSP needs 3-4 Techs per 1,000 endpoints, B/F needs 7.5. And with a strong preventive maintenance program, the # of Techs needed per 1000 endpoints is 2-2.5.
Does this mean a smaller staff is needed at an MSP over a B/F house? Not hardly, it means there is less B/F work, but there is much more Managed Service work. Think Alerts, Preventative Maintenance, and Projects are all provided to a Managed Service Customer to reduce the downtime and other negative productivity impacts.
Alerts
Alerts are a bugaboo for an MSP. It is nice to have the RMM tool tell you in advance when there is a problem before the Customer calls, but 1000 of the Alerts and more each day is too much for any MSP to deal with. We have seen it be an FTE for every 40 Customers. Even with great scripting, which knocks the noise down by 80%, there is a fair amount of Tech time needed to review the tickets and determine which ones are noise and which ones need to be transferred to Triage for remediation. Needless to say, FTE time is better spent learning to script and reducing the noise than to continually go through the motion of reviewing and deleting/completing tickets – or even worse, ignoring them.
Proactive Preventative Maintenance
The other arm that is very much underutilized in the MSP world is the concept of Preventative Maintenance. However, it is very difficult to have enough staff to run both a Break/Fix/Managed Service Support arm and spin up a Preventative Maintenance program. Not to mention, 30% of every dollar spent in MRR comes back in the form of additional Project work. But the long-term effect of going through the process (which could take a year, 2 or 3, depending on the Customer base) is well worth the effort if the MSP wants to scale the business.
How does a Preventative Maintenance program impact staffing levels? – One FTE per 20 Customers.
Moves/Adds/Changes (M/A/Cs)
M/A/Cs are what’s causing staffing levels to be bloated. The noise, confusion, disruptions – Chaos - that arises when an MSP has only one workflow (put it in the queue and let the Techs figure out what to work on next) goes unnoticed for the first few years of MSP operations.
But at some point, things stop working. Suddenly, the Owner feels hogtied by Service Delivery Issues and is unable to focus on growing the Company. Adding more staff is not making the problem go away; as a matter of fact, it just makes matters worse as there are now more people asking the owner what to work on next.
Moving M/A/Cs into a separate queue is not the solution because the same pool of Techs are working the Incident/Reactive Work/Break/Fix queues as the other queues. To rightly staff the organization, segmenting requests so the software can identify the M/A/Cs, and therefore manage them is needed. Once the segmentation is in place, reporting can be leveraged to validate the # of hours required (demand) and strategic decisions can be made as to the right level of staffing in each area, along with the amount of flexibility needed in the normal course of business.
Projects
Unlike M/A/Cs, it is when Projects come along that the noise gets so loud that everyone realizes Service Delivery is not working. Segmenting requests makes sense, but since the start and end of any one project is negotiable, the PSA software is unable to automate the Service Delivery or Project Execution phase.
Here, a totally different Workflow process is needed, and both non-billable and billable resources need to collaborate to keep the projects on-time and on-budget.
What is different about projects is that the MSP can control when to start or end, and how many to sell. This means staffing levels can be a strategic decision rather than just reacting to Customer demands.
If the MSP chooses to do more project work, there are several techniques that can be used to increase the projects without adding more Customers. However, it is good to have Sales-Sales Engineering-Project Management for MSPs methodology (along with staffing levels to support the type of project work being sold) in place before increasing project sales.
Network Assessments and Sales Engineering Time
If the decision is made to increase Project sales and the methodologies and staffing are in place, then Network Assessments and Sales Engineering Time are two techniques used to sell more project work. These two are lumped together because they require the same Level III tech to support the work.
This type of structure puts pressure on the organization as this highly billable resource is now being pulled into three directions – Managed Service Support, Project Work, and Sales Support. There is an Organizational Structure that gets these three demands to play nicely together, but it depends on having a strong Level II staff and ones that are hungry to grow their career.
We trust that this look at how the # of Techs and Customer Request Workflows impacts Organizational Structure has been enlightening but wait…there is more. The type of Customer mix also impacts how the Service Delivery Organization should be structured. Stay tuned for next week.
How do we know? Because we have 22+ years of MSP Service Delivery Coordinator/Manager experience on staff, and 17+ years Autotask System Administration experience. Which is another way of saying we have been there and done that, and we know how to leverage the Autotask software to Resolve Service Delivery Issues.
