Transcript
price out your program, just a couple of cautionary notes that I wanted to bring up as you are working through your own pricing exercise. The first being don't price based on what the competition is charging and don't aim to be the cheapest in your marketplace. I think MSPs have done themselves a great disservice by always focusing on the price and what their competitors are charging for their programs. It's the reason why we have a lot of this pricing commoditization that's still rampant in the market today because we have done a good job of really forcing the business owners to flip immediately to the last page where the price is located. We haven't done as good of a job of educating and communicating how your MSP is different and how your approach is different and therefore the value that you provide and the experience that you provide is different and that is what goes into our price. By specializing in security and kind of bringing that security angle into the program development embarking activities, this is a way that we can differentiate our MSP from our competitors and we can focus then on the benefits and the outcomes that our security centric programs provide instead of just the price. Back in part one of the bootcamp, we spoke about program development. We went through the different feature sets that included in each case and if you take what you've done and then a customer is trying to compare it to somebody else, it'll be very difficult to kind of get a true apples to apples comparison and so again, education is really important when you're working with a prospect around what you deliver your program in this manner, you support your customers in this way and that just naturally means we are going to be more expensive because we have the security centric focus of our programs which maybe another MSP that they're trying to compare you against doesn't have. And next week's bootcamp is really going to bring in that kind of that whole sales aspect of it. So once you've known your programs, you've figured out your pricing, you're going to have to start selling them, naturally, you're going to get pushback naturally, you're going to have customers say, well, you are priced too high, or why are you more expensive than X? Or I think I'm just going to stay with who I'm using. Or I don't understand why you're different. All of those types of objections and more, they're going to be addressed in next week's bootcamp. I think I've outlined 12 different objections you possibly could hear and I'm providing kind of strategies and tips with some scripting on what you can use to say to almost weaponize an MSP's lower price and use it to really help differentiate your MSP. So not really touching on it today, but that's what's coming in next week's bootcamp, the whole selling and objection handling technique. And don't price your programs based on what you think your customer can afford. I have had a lot of conversations with MSPs over the years on this. A lot of MSPs are still very much scared to kind of have that security and risk conversation with their customers because they know that by implementing a layered approach to security, like we talked about last week, it's just going to end up costing their customer more each month. And you'll see that momentarily when we start going through the costing exercise. And so they will often pre-object on behalf of their customer. And as a result, they end up underpricing their offerings or they end up kind of stripping out services and reducing the number of services in their offerings to try and meet a preconceived price point or a budget instead of just kind of standing firm and being confident, you know, in the way that you've designed your security program and, you know, kind of building that education piece again around why you are different, why your program is different. And therefore, this is why it's priced the way it is. Also we're not, I know there's people that said they price per device. I really do advocate pricing per user as per device, because when you, from a positioning and kind of messaging standpoint, we want to focus on the users with our programs. You know, we want to educate our users about our programs. We want the focus of our marketing, all of our sales messaging to really be on the user and not necessarily the technical tidbit that you're going to be managing. Because when you think about it from a security breach perspective, still many of the breaches that are occurring are caused by the end users. You know, they're generally the ones that are behind causing the breach to occur. So we want to really focus on the users and do everything that we can to kind of bubble wrap them from clicking on something that they shouldn't have clicked on or acting in an unsecure way that kind of allowed the attack to take place. You know, people are the most expensive asset of any organization. So the goal with your programs is that, you know, you want to keep them safe, protected, productive and you want to keep them working. So that's why we tend to focus more on a per user price and positioning a per user price as opposed to a per device price. Also make sure you understand what goes into your fully burdened labor rate. When you look at your fully burdened labor rate, this is the full cost of an hour's worth of work. And it includes things like your hourly wage, of course, all the payroll taxes, the vacation pay, health insurance, supplies, meals, training, or any other benefits or expenses that are related to an individual's employment. So I'm not going to touch on it more than what I have just done because this question came up in this morning's bootcamp. Because I've always assumed that your bookkeeper, your accounting person can give you your fully burdened labor rate if you don't happen to know it yourself. And there's a lot of material on Google on how to get that number. But you will see when we get into the costing calculator, you do need to know what your fully burdened labor rate is on average so that we can get the right labor costs associated from that. And lastly, be honest when it comes to the amount of direct labor and the human resource time that is needed to actually deliver your program. I've had many conversations with MSPs over the years where they've tried to skimp on these estimates to try and reduce the monthly price. So it fits more into a customer's preconceived budget. But if you're skimping on how much time it actually is going to take you to deliver the program, that's just going to hurt your profitability and your revenue levels. So if you're going through the exercise and you're finding that your preventative maintenance time is too much, or maybe the consulting time is too much, then this is where you really need to kind of look at what are you doing internally? Like are you not leveraging automation where you should? Are you not doing what you can from an operational efficiency standpoint, from a tool set standardization standpoint? So you may need to kind of look internally to see, okay, if I really want to reduce this honestly, then I do need to pay more attention and implement some more automation strategies and operational efficiency strategies so I can better optimize my labor. And I think the biggest pricing mistake that I still see, now it's not as much as it used to be. I think we're all getting better with this, but there's still MSPs out there that have told me they don't do price increases, or they haven't gone back to implementing price increases post COVID. And that really needs to stop. We need to set a cadence, set a precedent when it comes to our price increases, because your costs go up every year, right? Like whether it's your business costs or whether you've had to deal with general increases in inflation. And so to maintain your own profitability levels, you have to build in price increases, interior annual contract renewals, because you need those increases to offset your increases in cost. Because by not implementing regular price increases, your profitability is just going to naturally erode year over year. And that's just going to end up eventually having a negative impact on your overall business valuation levels over time. So I've just added some points there, some tips on how to handle price increases if you've never done this before, or maybe it's been a little bit since you've done it. I think you can just tear off the Band-Aid, bring it up at their next executive business review meeting. Just tell them that you have to start implementing an annual price increase, and just let them know when that's going to take effect. Whether it's at the renewal, whether it's in 60, 90 days, 120 days time. But the idea is that you need to start doing this because your costs are growing and you need to offset your costs. Or better yet, price increases generally go over better if the customer can see that they're getting increased value in exchange for the monthly price increase. And that is why we kind of went through last week's boot camp, focusing on a new pricing structure. Because if you do that, along with a price increase, then it really isn't so much a price increase for the sake of a price increase, but rather you've kind of redesigned your whole entire managed security practice. And you're now introducing a new set of security programs that are aimed at providing better threat detection, better threat prevention, remediation services for your customers. And so that's why the monthly price is changing, because you're working to standardize your customers across the board on these new security program offerings. And another way to introduce price increases is kind of along the same lines. This came from a partner of mine that attended office hours a year ago, maybe a year and a half ago. And if you've attended my boot camps or office hours in the past, you have heard me tell this story. I think this is probably the 100th time I've told this story. But he was kind enough to share it. He is kind enough to allow me to keep talking about it. But the way that they handle their price increases and to note, this is a small MSP. There's only four guys that work in the MSP. But when they built their MSP, they were very intentional on this. And so what they do is they build a security suite and they bundle that security suite and they version it like cars. So they have like the 2023 security suite, the 2024 security suite. So every year they look at their security suite and they make changes to it. And then every one of their clients gets moved on to that latest security bundle or that latest security suite. And this is a fantastic approach. When he was kind of talking about in the office hours, like even though I've been in this industry for 20 years, like it was just it was mind blowing for me. Because it makes absolute perfect sense and it solves so many problems and so many challenges that a lot of MSPs have when it comes to pricing and raising their pricing and setting their pricing. Because first, by implementing this security bundle, it promotes naturally product standardization and it keeps every customer basically on the same program with the same feature sets, with the same tech stack. And through this product standardization approach, it then makes it easier for you to onboard, service, support those customers because the tech stack is the same across the board for everyone. And so it makes it a lot easier for their techs then to kind of stay current because everybody there's only one only one set of products that they have to learn. There's only one backup. There's only one EDR that they have to learn. They don't have to waste cycles trying to stay up to date and knowledgeable about four or five different backups or four or five different EDR products. So it really helps from a technician efficiency and training perspective. What it also does is it positions their MSP as the experts. And it affords them the flexibility and the luxury to change out products whenever they feel it's necessary or to amend the product mix if they find that there's better versions of products that have come out with or it even gives them the flexibility to introduce new products, new security technologies, if they feel that the threat landscape has changed and now warrants it. And by doing this, it removes this notion where they have to go and get their customers permission first before they can make changes to their programs and their tech stack. And I used to hear that all the time when I was in sales. You know what, Steph, I can't I can't buy EDR right now because I have to go and talk to my customers to see if they'll pay for it. With their approach, they really do take kind of the tell don't sell type of approach with their customers. You know, if they feel because they're the security experts that the threat landscape has changed, that some products that they had aren't as effective anymore or there's a new version or there's a new service that or a new service that we need to include like MDR as an example, then they go and make their changes. They build a new security bundle and then that gets automatically applied with the new pricing to it. And one of the things that they do make sure is they give their customers ample warning about the new pricing. They're very good at doing their executive business reviews. So generally, because they do have quarterly reviews, you know, the quarter before the price comes into effect, that's when they kind of send out their reminders or make them known about that, which also, I think, removes the element of surprise because their customers have just naturally come to accept this arrangement because they don't know anything else. They they just accept that this is just part of their MSP supporting them. And John has told me he gets very little pushback because it's just something they've always done. So even through their sales process, they make sure they educate their customers before they even sign on and say, look, this is the program. We change it every year. The prices will go up accordingly. So if you're OK with that, this is the way we support our customers. And they're good customers. They they recognize that and they're OK with that. Now, in saying all this, I'm not saying that every year John throws the baby out with the bathwater. You know, it's not as if he blows up his security bundle and implements a whole new security bundle every year. But what this does, it just gives them the flexibility that if they do see changes need to be made, their customers understand that. And it means that they don't have to go and get permission first before their customers. They're able to kind of amend their tech stack based on their expertise, their knowledge, their skill sets, and then they just apply it to to the rest of their customers. So basically, the moral of the story with all of this is don't be afraid to implement price increases, especially if you've never done a price increase before your customers. Little secret. They're waiting for you to come to them and say we have to raise your prices. They've had their prices raised by everybody else. The fact that you haven't raised their prices yet, they're waiting for it now. They're not going to come to you and say, hey, you know, you should raise our prices. But if you start talking to them about having to implement a price increase in regular price increases moving forward, you're good customers. They're going to understand. They may have some questions around it, naturally, but if they're implemented properly, they should be OK. But if you are getting pushback, if you have customers that are adamant that they won't accept this new bundle of services or they won't do your they won't accept your price increase and they're giving you a really difficult time, then maybe you let them walk. To me, churn is not a bad word if it means that it's going to allow you to build a better book of business. And that's why I have next week's boot camp happening. So if you have a customer that says, yeah, I'm not taking that or I'm not paying for that, I have strategies that I've built out scripting for as well for that particular pushback.
