Today we are talking about your technical stack. The core of what you offer to your clients. We are going to talk about best practices for managing and selling your stack.
I’m going to start with a quick story. My former MSP had a pretty solid stack, and we were heavily in the camp with one backup product. We had a TON of the devices in the field and something like 90%+ of our clients used the service. One client that was a stick in the mud and refused to swap over to the stack backup product. We timed the effort the NOC had to do to check on backups for the 200 something devices in the field vs the time to check this one device. They were nearly identical. Supporting this one device took longer than any of our stack devices.
We took this to the client and they still wanted to stick with their backup product. To them it was “good enough” and a bit cheaper than our stack product. Because they were making us less efficient we decided to charge them more to support their backups. As it turned out, the amount more was just a little more than it would be for them to switch to our stack. A few weeks later, they were stack compliant…
Why have a technical stack in the first place?
Managing your stack and enforcing stack compliance will make you more efficient with supporting your clients. When you have a solid stack your team can be far more efficient and can support more endpoints without adding extra members to your team.
If you consider endpoints as devices you can see in your RMM your engineers should be supporting between 200 and 400 endpoints. Building a good stack will go a long way to make this a reality.
How to define your stack
The next logical question is how do you define your stack? Most MSPs pick a handful of products and adjust over time. You probably already have a pretty good idea of what your stack is, even if you’re just starting out.
I like to think of your stack as a few strong CORE items that are the truly non-negotiable pieces of your stack. Things like your firewall/edge devices, network gear, backup products for both cloud and local data, the entirety of your security stack, and user identity (think Active Directory local or cloud, or the equivalent over on Google). You could probably argue to add some more things to the core, but this is pretty close. These are the items that you WILL NOT ALLOW CLIENTS TO DEVIATE FROM AT ALL. These are truly the non-negotiable. Each of these items impacts support and security, so don’t deviate. Especially on the security stack.
A quick sidebar on security: I’m of the mind that if your client won’t take your entire security stack they need to find another MSP.
Other things that you’d prefer them to have aligned are things like endpoint makes and models, and other software or services. Those things can be adjusted for over time, but I recommend that you require your clients to have vendor support for line of business applications AND appropriate hardware warranties for all endpoints. Those would be stack components I would require.
How to sell the stack to clients
This one can be a bit tricky, but remember, you’re the IT expert. You know your stack items in and out. You know what issues to look for and how to mitigate risk with your clients. Ultimately, they’ll be happier with your services if they are stack compliant.
The first thing to note is that your stack is YOURS. You picked the vendors and products that go into it. I would not talk about the specific vendors you use and the products that comprise your stack. I would keep it generic to the services that you’re providing as part of the stack. Things like network security, endpoint protection, local and cloud backup, and that sort of thing. The minute you start calling out specific products you make it harder to switch to a different product later on.
Since most of your stack items will require a transition period, you will want to address this during your early conversations with them when they’re a prospect and enforce this when they’re a client.
I would then build a roadmap to get your new client stack compliant as quickly and as reasonably as possible. If the client agrees to the roadmap and is following it I’m inclined to not charge them for being outside of stack compliant.
Here’s the key point. You really aren’t selling your stack. You are selling the services and value you bring to them as the awesome MSP that you are. I would not get too hung up on selling the stack. Sell them how you will solve their problems, mitigate risks to their business, and level up their efficiency with your service. The stack is just a part of that.
How to handle out of stack clients
That said, if the client refuses to become stack compliant you may want to consider charging them more to make you less efficient. Just like we did in my story at the beginning of this ramble. You should build this into your contract verbiage, but it’s important that the client offloads the IT related work to you, and just because they like something else or it’s cheaper doesn’t mean they should continue to use it.
Swapping out products in your stack
Remember when I said earlier that you shouldn’t be talking about the specific vendors and products in your stack? That’s because you will need to swap out a product at some point. Maybe the service declined, maybe their contract became untenable, or maybe they were acquired by a company that you would prefer to not do business with. Whatever the reason, you will need to be flexible enough to swap out a product or two on your stack over time.
When this happens you will need to communicate with your client if their users will be impacted in any way. Even if it won’t impact users it wouldn’t be a bad idea to let the client know that you’re going to be performing some maintenance on their systems. This way it’s not a surprise when the thing that wasn’t supposed to impact users does, in fact, impact users.
With all of that, we talked through a lot during this ramble:
- Why your stack is important: Efficiency
- Defining your stack: build the CORE first
- How to sell to clients: it’s YOUR stack, not a bunch of vendor products; also sell your value and not the stack
- How to handle non-stack compliant clients: Roadmap or charge more
- Swapping products out in your stack: do it when you must and be careful and communicative
Thanks for coming on this ramble with me and I hope to see you on the next one.