One of the major operating questions for MSPs is whether they should, or should not, standardize their stack. Standardizing the stack is something that often comes as part of either the sales or the onboarding process, where you sell the client on working with your tech. But standardization represents a trade-off between margins and churn, so it’s fair to ask how far down the road you should go.
From the perspective of the MSP, a standardized stack is good. Getting all your clients on the same tech allows you to be much more efficient. MSPs with a standardized stack policy can expect to experience the following:
- Lower operating costs
- Shorter training times for new techs
- More reliable SLAs
- More competitive pricing and SLAs
If you’re talking about firewalls, it’s a lot easier to train your techs on one firewall than on six. You can take the efficiency gains to put those into margins, into more competitive pricing, into more attractive SLAs to help you increase sales.
One of the interesting findings from IT Glue’s 2018 MSP Benchmark Survey is that MSPs that insisted on a standardized stack were significantly more likely to experience a net margin over 30%. MSPs that do not insist on a standardized stack, but merely prefer one, performed the same as MSPs with no policy on stack at all, in terms of margins.
The downside of standardization is that the end user will often have its own ideas about what tech it needs. Some potential clients may bristle at the idea of changing their tech. Some might have organizational cultures that are not especially conducive to changing technology – certain verticals are notorious for this. Thus, there are instances where insisting on a standardized stack increases the risk of churn. 17% of MSPs that insisted on a standardized stack experienced churn of 10% or more last year, compared with 7% of MSPs that do not insist on standardization.
How to Get your Clients to Standardize their Stack
Knowing that there’s a higher risk of churn is great, because it allows you to anticipate how you’ll solve this problem. Nearly two-thirds of MSPs that insist on a standardized stack are able to achieve churn of 5% or less, so it’s definitely a solvable issue. This means that while the risk of high churn is greater, most MSPs are able to manage this risk effectively.
There are a few ways to do this. The cleanest is simply to set expectations up front, preferably with all of the client/prospect’s different stakeholders. One recent article highlighted one MSP’s approach to bringing about the proper culture fit with clients – and what to do if there were issues getting that trust and culture fit.
You would also be correct to point out that you are the expert in the field, and as such the clients should trust you on this matter. If they are unwilling to trust you, they might not be the right client for you.
If possible, build out use cases. Say you’re including the MyGlue password vault in your offering, to reduce your password reset burden. You know that if your clients are storing passwords in Excel, Post-Its, and goodness knows where else, that this is a problem. But if you build a story around why they should use MyGlue, that makes it a much easier sell than simply saying “Hey, trust me.” In other words, don’t be afraid to make a case for your recommendations, and keep the focus on the customer’s needs.
So Should I Standardize?
In a word, yes. You just have to do it right. Most MSPs are able to insist on a standardized stack and succeed because they tie the strategy into the trusted relationship they are building. They are prepared to walk away from a prospect or a client that is unwilling to take their advice, and are able to effectively communicate the benefits of this strategy both before the sale and after. It’s not perfect – it can take a couple of years to achieve standardization, and in some cases 100% standardization across your customer base might not be possible at all. But it’s a noble goal, and the closer you get the greater the efficiency gains you’ll see.
To find out more about IT Glue, click here: