Do you ever feel bad presenting a budget to your client and find yourself thinking “What are they going to say?” or “It’s too much, they’ll never accept it”? It doesn’t have to be that way. When done right, budget discussions shouldn’t feel like a tense negotiation between you and your client.
If you start a Strategy Meeting (aka a QBR) by presenting a budget, chances are you’re doing it wrong. The budget should be a consequence of what was already discussed and presented up to this point. And not “up to this point” in the current meeting, but “up to this point” with every single Strategy Meeting you’ve had so far with this client.
Clients Hate Surprises
What makes budget discussions tense is the feeling of surprise, the unexpected. Part of your job as vCIO is to minimize the number of surprises for your client. That’s why you should present an up to date 3-to-5-year budget every time you meet for a Strategy Meeting.
This budget should include both asset rotation costs and project costs. Some MSPs also include recurring agreement costs, but many prefer to leave out the Managed Services agreement costs to avoid side-tracking the discussions.
Asset Rotation Costs
Asset replacements can represent a substantial portion of the budget, but asset rotation costs are predictable. They’re the result of policies put in place for each category of asset (e.g. Laptops, Workstations, Virtualization Hosts, SAN, Switches, etc.) the client has. Each should define the:
- End of life policy: how long should be the asset be kept, and what’s its replacement price?
- Warranty coverage policy: how long should the asset be kept under warranty, and what are the approximate warranty renewal costs?
- OS End of life policy: if the OS is no longer supported, should it be upgraded, or should the asset be retired instead?
As an MSP, you must have a “best practice” recommendation for each of those and the very first budget you present should be based on recommendations. But no two clients are alike, so it’s likely your recommendations won’t stand as is. Openly discuss your them with your client and tweak them to better reflect their reality.
Maybe your client will want to keep laptops for 5 years instead of 4, but with a replacement budget of $1300 instead of $1000, or maybe they’ll need to split the “Laptops” category in two, like “High-Performance Laptops” and “Office Laptops”.
Be transparent, discuss the pros and cons of each approach and update the budget accordingly.
When you have come up with policies that your client feels comfortable with, have them “sign off” on it. If not officially, at least conceptually. This will make future budget discussions easier as going forward, you’ll be able to say things like “Remember, we planned to replace the SAN after 7 years, that brings its replacement in 24 months”, then “in 18 months”, “12 months”, and so on. No more surprises!
Project Costs
By nature, project costs are most volatile, but that doesn’t mean you can’t plan ahead. Conduct an audit of your customer’s IT infrastructure to identify:
- Gaps between your recommended tech stack.
- Vulnerability and risks that should be addressed.
These will result in project recommendations that need to be discussed with your client and scheduled. That will undoubtedly affect the budget, but the sooner the better. No one wants to hear “We need to overall your VPN infrastructure… now! That’ll be $20K!” Regular audits are a good way to avoid that… but that’s a topic for another time.
Don’t Pre-Negotiate with Yourself
Lastly, you shouldn’t pre-negotiate with yourself by cutting out some recommendations or changing a solution because you’re afraid of showing the price to your client. Of course, you should make realistic recommendations, but let your client take the risk management decisions based on your recommendations and analyses.
Say a client doesn’t want to have redundant firewalls because of the costs, make sure you explain why you’re proposing it and what the risks are. This way, if a firewall does break down and needs to be replaced, your client will know that he previously accepted this risk and the downtime that now comes from it. If you never propose it, you’ve made this decision for them, and they may very well get upset if downtime is caused by a faulty firewall.
Think of how much one day of downtime costs your client and factor that in your risk analysis before you decide to scale down your solution based on costs. And make sure you tell your client.
That being said, some clients are just cheap and never approve projects. There’s a way to around that, see how to address ticking timebombs.
Dominic is a Computer Engineering graduate and a process analysis expert. In 2018, he co-founded Propel Your MSP to help MSPs improve and structure their vCIO services offering.
