ERP031 - vCIO Process w/ Alex Markov — Evolved Radio podcast cover art
Episode 31 May 28, 2018

ERP031 - vCIO Process w/ Alex Markov

31:52

Listen in your player
I think MSPs eventually will be something more of like managed strategy providers, really can help guide the strategy for for clients.
Share this quote X LinkedIn

Show Notes

On the podcast today, I'm chatting with Alex Markov, President of Red Key Solutions and CEO of Strategy Overview.

Red Key is a mature and successful MSP in the New York area. Alex and his team work hard to deliver business value to their clients. One of the best way for MSPs to do that is implementing a QBR/TBR. Alex recognized the value in the system they had built and has created a SaaS product called Strategy Overview to help others deliver effective technology planning to their clients.

Read Transcript
Welcome to Evolve Radio where we explore the evolution of business and technology. On the podcast today, I'm chatting with Alex Markov, President of Red Key Solutions and CEO of Strategy Overview. Red Key is a mature and successful MSP in the New York area. Alex and his team work hard to deliver business value to their clients. One of the best ways for an MSP to do that is implementing a great quarterly business review or technology business review process. Alex recognized the value in the system they had built and has created a software as a service product to help others deliver effective technology planning to their clients. If you aren't in the IT service delivery, this episode may not be of interest. But if you're an MSP, you're going to love it, so get ready. If you enjoyed the show, be sure to subscribe on iTunes, Stitcher, or wherever you get your podcast from. Also, be sure to check out the web page evolvedmt.com/podcast for show notes, links to my guests and to check out previous episodes. Now, let's get started. Joining me on the podcast today is Alex Markov, President of Red Key Solutions and CEO of Strategy Overview. Welcome, Alex. Hey, Todd, good to be with you. Today, we're going to be talking a bit about more MSP process and specifically, we're going to be talking a lot about the position of the VCIO or the virtual CIO and the role that that plays in an MSP as well as general IT service providers. Alex, you're a particular pro at this area of the business and know that this will be an interesting discussion. This is an area that is developing pretty rapidly for a lot of MSPs as they look to provide more business value, rather than just the straight-up technical value. And maybe just to get us started, if you could tell us a bit about your MSP and your background and how strategy overview came to be. Yeah, sure. So, I started my career or my kind of journey as an IT person back in 1992, my dad got me a computer and I got on Compuserve and then got on AOL after that and have done nothing else except consult and work with businesses and people on setting up technology. So, I really go back to the beginning of the functional internet. Um, in 2002, I started a company in college, um, and actually did a real entity. And started consulting for businesses and then eventually we switched to manage services. I merged with a partner here, the local in the area and we started Red Key Solutions. And today we support over 50 different companies, we support the New York City Tristate market. And we use Connectwise, Labtech, IT Glue, Brightgage. You know, the full MSP stack and have really invested a lot of time in perfecting our VCIO piece of the business and how to do QBRs. Excellent. And you launched into starting a product to actually help you out with that VCIO product process. Do you want to touch on that briefly? Yeah, so. We we used to have a great process that we use spreadsheets for. Um, because it had to be really easy to use and we were never able to find anything in the market that was. It was as easy to use as our spreadsheets. So, we had an opportunity where my brother is an enterprise quality developer and he said that he can absolutely do this. And we started a different company called Strategy Overview. Um, which basically took our process on how to do risk analysis for clients and um, and converted it into an app. That's now used by over 260 MSPs today on every continent. Awesome. So, let's step back a little bit here for the people that maybe are not this deep into the the IT space. Uh, let's help define what is a VCIO. And uh specifically, let's talk about VCIO and the overlap between what other roles. This could be defined in or maybe how they differentiate. There's the VCIO, there's the technical account manager and there's also the traditional account manager or salesperson. Uh for yourself, how would you define what is the VCIO role that uh have you found success with in in your organization? Yeah, so, we really started the journey many, many years ago where we are trying to figure out a way. How do we communicate with clients in a structured strategic way? So, when we when we all started as MSPs, we as owners as the main kind of the principles in the companies are the main people that communicate with clients, explain to them, you know, what they need to get. You know, what the risks that we see and then as it evolves, we need to make it a formal position. Right, so we tried a number of models, we tried having an account manager. Um, we tried even calling maybe a technical account manager, it never really worked for us. Um, because they the person that really communicates to clients really needs to be almost like a CIO. It's the same way as we as principles when we started MSPs. We communicate to clients as a CIO would. Um, so we we heard the term in the in the industry, it's a common term virtual CIO. And it really is a a great term to define what um a a role does. That has that type of communication with clients and that's what we call it. Um, again, we've tried other ways and I'm sure there are other MSPs. Which get the account manager model to work and um, for whatever reason in our MSP, our market, the way that we do it, um, we never were able to get that to stick. Yeah, I find it's it's almost a confluence of a few different issues where it's the type of person that you have available for the role. It's the needs of the client base that you have in particular and also what maturity level you're at in your uh your your journey as an MSP. Uh I find the there's a lot of components you have to get right beforehand, there's a maturity level that you has to be in place before this really becomes a viable option for your business. Is that something that you see as a hindrance to people getting started on the VCIO process as well? Yeah, definitely. I mean, there's definitely prerequisites like you need a PSA. Where it's Connectwise, Autotask or any of those. Um, you need tools like an RMM. Um, you need to get your service down right. Um, you need to just have ideas and and quoting and that stuff organized. So those are definitely prerequisites. Um, and then you definitely need to find the right person and the right team that could do that. Um, it can't be a salesperson, we've learned that. It's it's not a sales role, um, even though they're involved in sales, um, but the sales just fall out of the role. It it has to be somebody that really can have a a coherent, logical conversation. Um, and in our MSP as well, we still keep principles involved in the process as well. So, it's you know, I may not go to every single meeting with clients, but especially with the big clients, I'm there and I'm helping guide them in the overall strategy. So, clients get both the VCIO and then a principle that's on the VCIO team. And what would you say are the the particulars, like if someone is looking for that person either outside of their company or preferably inside their company, what are the qualities that you would look for in someone that you feel would be successful in that VCIO role? So, they definitely need to be personable, but not salesy personable. Just like a relatable person, they have to be sharp, um, and be able to learn and understand, um, technology. They have to be technically minded, um, because a CIO needs to really understand technology. If they don't understand, you know, even like basics of like DNS and domains and active directory and all these other things, they it'll be difficult for them to make, you know, strategic decisions. So, they definitely have to be technically minded. In our company, we um our people came from the project services world. So, they ran projects. Um, so that gave them the ability to understand budgets, um, understand financials, understand, you know, different companies have different needs and different budgets. Um, and so there's definitely it's it's not like a scientific black and white thing. Um, they definitely need to be um flexible and be able to communicate that with clients. Yeah, it's an interesting mix of um, like you said, they they have to be technical to have that authority and understand the sort of the the issues at work. And and what a successful uh technology implementation looks like, um, they need a bit of sales to be able to impart the value to the organization and to the the client that they're speaking with. But, you know, any one of these that is out of concert or or too much on one end of the spectrum. I think that's why it's so difficult to to replicate this outside of the principle. The principle of the organization will usually know enough about the business, has had to do sales in order to build their business, um, and has that that relationship and that authority with the client. Um, uh, do you feel that that the VCIO role should stick with the principle before it's replicated uh outside of that office, is that maybe the best approach to to take there? Yeah, you know what I think now that thinking about it. I think, you know, the way that we were able to succeed in it so much is we took project people that were also comfortable speaking to C-level executives and speaking financials and budgets. Um, and then they basically shadowed me for about two years. Um, and then over time, smaller clients, they were able to run themselves. Um, but they I had to invest a lot in business logic and overarching, you know, just really explain a lot about how businesses work. What's important to a business. Explain concepts of what a balance sheet is, you know, CAPEX versus OPEX, explain things, you know, how a P&L, what a business would look at. Um, financially, burden rates, just like business fundamentals. Um, where a project manager may understand technology, but then you infuse this business knowledge into them. And that's how a true VCIO was created, I think. Yeah, yeah, it's it's really fascinating to to understand, you know, who is the right person and what is the process that makes this successful. Um, and every time I've I've sort of gone through this process and worked with folks to develop their VCIO practice or to help develop a VCIO in their skill set. There's always one component that that is that aha moment where they really start to get this and you hit on a couple there. Um, the first place I usually start, um, I I'd be interested in kind of your feedback on this as well. As uh asking the person, the client if they actually have an IT budget or if it's just reactionary spending. And it's surprising the number of times a client that, you know, is doing multi-million dollar business and develop doing very well, but they have no predictive spending on their IT. They've never even thought about it. And that first step to sit down with them and say, okay, here's a draft budget, here's all the things that I have I have visibility to and and I've wrote this down on our spreadsheet. This is kind of what I predict is your annual spend and you just see their eyes light up. And they're like, oh my God, this is amazing, like we've never even thought to do this. It's as simple as that and then it gets way more complex down the line. What are some of the other components of the VCIO process that you feel are really important? Um, so first and foremost, consistency. It can't just be something that you do once in a while and again reactionary. You have to build a process around it. So, in our MSP, we've standardized scheduling with Calendly, but there's a number of solutions you can use. Um, and we use Connectwise to automatically send the ticket to every client every quarter to give them an opportunity to schedule a a meeting. We call it a technology strategy meeting. And then essentially, they can schedule that meeting, they can pick to either for us to go to their office, them to come to our office or do a go-to meeting. And that consistency behind it creates rhythm. And we live in this in the MSP world, we constantly, you know, we know EOS and all these other type of systems. We just have to bring that same logic to um this process. Um, and just keep consistency with it. Um, and then have a platform and a process. So, you know, it doesn't matter what platform you choose, you know, we use our platform because we really like it. Um, strategy overview and but it doesn't matter what platform or process or whether you're still using spreadsheets, just some kind of process that's consistent across all your clients. Now. You must have run into some resistance as well, uh certain clients that maybe don't see the value in this meeting and they're resistant to either um starting the meeting to begin with. Or keeping the pace or the that consistency with the meeting. Um, any any input from you on that client that says, I I don't know I don't understand what we're trying to do here, I don't think this is valuable, so I'd I'd prefer not to do it. Is that something that you you try to change their mind on or is it you just adapt to what the client says that they need, what's what's your feeling on that? Yeah, so. I I believe there's definitely a lot of thought leadership in the industry about you need to have all your clients consistent and have them all respect strategy and want to focus on growth and everything like that. But what we found in in our market and just in our where we are as an MSP. Um, that there's still some clients that don't really care about growth. And we ask them that question like, do you are you focusing on growth? And a lot of times they'll say no. They just enjoy their current spot where they are. They know that growing pains is is are difficult and painful, right, and it's difficult to grow, sometimes you have to spend a lot of money to grow and some clients are just comfortable maintaining their operation. So, and we still I would say 20% of our business is clients like that. Um, we still have clients if they're local, if they're friends, um, strategic for a number of reasons, referral partners, we'll stay still take them. And for those clients, we'll at least tell them about all the different strategy elements they should pay attention to, elements of their stack. Even if they don't meet with us, we'll send them a report from our software and just basically outline all the different things that they need to pay attention to. And if it's like a legitimate risk, we'll mark it as a risk. And then that's a risk for them and for us. So, that gives us a little bit of extra um kind of liability protection. Because then we've identified the risk for them and then they don't they don't have to wonder. And then if something does crash, we can just reference the email that we sent saying, look, this was the risk we identified. So, at the very least, even if they don't care about strategy, we can at least limit our own liability by identifying risks for them. Right. So, you're still doing the process. Their involvement is is is to some degree up to them. Uh especially dependent on the risk. Yeah. I I like that approach. Um, you know, I do a lot of work in Brightgage and and I I like the idea of setting up the monthly reporting, which I would say is one of the the first uh early stepping stones to a VCIO process. Is at least monthly reporting on service and the approach that I take in this. I think is similar in that um you want to at least train the person how to read a report. So that you can send it to them in an automated fashion later. So if you get them um on a web session or you go to their office and visit with them and on the first couple of times that they see this report and review it with them. So they understand what they're looking at, then down the road, if they want to self-serve and it just comes to them automatically. That's a less of a risk than automatically just sending them this report that they don't see any value in. So I think training them in in the value of what they're seeing through these the tools and the reporting, I think is really critical as well. Uh like I said, just that first stepping stone to getting started. Yeah, and the way we handle that actually is. So, in the onboarding with every client, we add them to our app and then to close the onboarding, we generate their first report. And we'll bring it to them as kind of a regroup post onboarding. And most clients, they'll they'll want to meet with us at least once after that to find out, even if they don't care about, you know, growth and strategy and all that stuff. They still care for their quick books to work, they still care for their computers to work and their internet to work. So, that's our opportunity to sit down with them and say, look, if you did want to grow, if you did want to look at all these different elements, here's what, you know, you should pay attention to. But at the structural foundational level, let's make sure that your base is covered, right? Because if their wireless is not um set up properly, if their network is not set up properly, all of that creates issues. And and that's issues for us and issues for them, no one wants issues. It's a waste of everyone's time. So in your process in the the VCIO process, how much do you feel kind of a percentage split of this um a lot of the industry talks about them being technology business reviews. Rather than the quarterly business reviews and there's some discussion about uh how technical they should be versus business-minded. Uh and I think there's there's a need for both, what do you see within the clients um as far as their attachment or their need for these meetings to be technical versus business focused? So, from a business focus perspective, we just have an open conversation with the client. Find out where they want to go, right, find out are they looking to grow, are they looking to expand and understand what they're currently doing in their business. Um, from a sales perspective, um, distribution, um, if they're servicing their accounts, how they're doing it. Just having an open conversation about that. But then we do look at all the technology behind it that affects that. So, as we understand how they're running their business, we'll explain to them. For example, if we know that a construction company is doing $10 million a year in revenue and they they say they want to go to 50, right? But they're still on QuickBooks Enterprise. That's not going to work. We know they're going to start hitting growing pains. So, at that point we start talking about the technical piece of it that they should be looking at a larger ERP and they should be looking to streamline their bidding, their takeoff process, all these different things. Same thing for, you know, a healthcare provider. Um, we we look at all those elements. So, definitely understanding where they're going in the business, but then definitely relating to actual technology and things that we do, um, and and then marrying it all together. Yeah, so I guess uh the technical components are the prerequisites to leveraging more business solutions. I I view this sort of similar to the MSP business model, uh before you're doing a VCIO process. As you mentioned, you want to make service uh really rock solid. Because if service sucks, then your client is not going to listen to you about the other needs. You know, you're you're standing here trying trying to sell me something and the uh in the meantime, you can't get this problem fixed that's been an open ticket for two weeks. So, I feel like the those those uh stepping stones are important to get right. Work on your service, make sure that's stable, then you can move into more advanced measures, same thing with how you're managing that VCIO process is uh standardize the stack, eliminate sort of the technical noise within uh the business. And then start to look for other solutions or other issues to solve within the business further up the stack, right? Yeah, definitely. And I think service could actually be broken down into two categories. Service is the managed services piece, which is everything, you know, our help desk and proactive monitoring and um, you know, all the different antivirus, all that other stuff, right? And then there's the project piece. And the project piece is just as critical as a service piece. Because you need to be able to quote the projects, either if you're doing fixed fee, they have to be relatively accurate. Right, if you're doing block hours or anything like that, they have to again be relatively accurate. And it has to be timely. Um, that's another thing we found. That if you get into a process where you're quoting things and you don't have a good structure behind it, a good scope of work process, um, a good, you know, template in your quoting system. Then it creates an issue where if it takes two weeks to get people a quote, then they lose interest. Right, and then the actual project delivery itself, if that goes rocky, then it kind of destabilizes the whole process. So, definitely MSPs as part of the making the VCIO process successful. Should focus on their service piece and making that consistent and then making sure their project coding piece is consistent. And you lay the VCIO on top of that and then it's just value generation for everyone involved. The client, the MSP, it's just a beautiful thing. Yeah, that's really good advice. I often view the VCIO uh process um from a uh a revenue generation standpoint. Uh as a a project accelerator. Because how where better can you get a a funnel of projects. Then meeting with your clients on a quarterly basis to find out what their their next need is and that's helps you figure out um uh how that can actually lay out in sequence. So, in the next three months we want to do this, in the next six months we want to do that. And a year from now we're going to maybe focus on these things if nothing else changes. Then you can kind of work on that on an annual basis. And from a sales perspective, it always blew my mind when people would come back from a client and say, oh, they're cheap, they don't want to buy this. And, you know, you would you would fall have follow-up conversations and what you would tend to find out is that. They're not really saying no, they're more saying not now. Uh and I think if you don't have sort of a business-minded focus on this and understand how the business works, if you're not catching them at the right time where they're in budgeting cycles and doing planning proactively with them. Then they can't make room for those OPEX uh or for this CAPEX expenses. If you're not planning with them on a progressive basis. So, rather than do you want to buy this right now, it's when can we fit this into the budgeting cycle to make sure that this works for the business? That opens up huge channels on developing your your project funnel. Oh, definitely. So, in in our app, what we do is we used to do this in Excel is basically do a three-year roadmap and a three-year budget. And pick the quarters and where things are going to move. And we're flexible with clients, right, as long as they're okay with the risk of something being, you know, potential risk. And having some glitches. We're still flexible with the clients. But we look at everything on a three-year cycle, so our clients know roughly what the budget upcoming is for next year. That's the other really important thing about being consistent with the process. Because if you fall behind and it's really easy to fall behind, you know, everyone's busy, everyone's focusing on their businesses. If you fall behind, then you may not be kind of telling clients about what's coming up. And a year will pass and then the server that should be, you know, server 2008 needs to be upgraded and you surprise them with the bill. No one wants a surprise. Right. But if you tell them ahead of time, nowadays what we do is we never really even quote anything unless the client virtually says that this price is okay off of our roadmap. Um, which saves a tremendous amount of time on sales engineering. Um, because sales engineering is also very, very expensive time. And if you can do the VCIO process right, that dramatically reduces the amount of investment that MSPs make towards sales engineers. Yeah, that's a huge point. I couldn't agree more. That um, one of the areas of major inefficiency in project quoting is uh people are using statements of work to go fishing. And a sales engineer sitting down for four hours to architect a solution when, you know, they've maybe got a 30% likelihood of buy-in from the client. But, you know, hey, can I get you a quote so we can talk about this? It's not a piece of sales material, it's a definition of work that is essentially already been verbally agreed to. So, that that's great to be able to to split that process and be able to have that person have visibility on. Okay, yeah, let's go ahead with this, okay, now we can actually start architecting and develop a sale for it. Correct, that's a huge hidden cost that a lot of MSPs don't pay attention to. Is the amount of time they spend on sales engineering. And then where do you put that cost? You know, we um classify the cost of sales engineering under service. There's a a weird way that that um, you know, motivates the team and drives the team efficiency. And then you really can look at the burden rates on that and make better decisions. Um, but whatever you put it, whatever bucket you put it, even if you put it under sales, then that really inflates your sales cost. Um, so again, now we very rarely will quote something and do a scope of work. Unless the client pre-approves it off of the roadmap document that our app generates. And the the pre-approval like that, the the numbers there are probably just pro like um approximate numbers. So, you know, variations of up to 20, 30% once we have. Correct. And we explain that, we tell them that this is, you know, this is not set in stone. This is just a like a roadmap, you know. And especially if we don't understand if we're just signing on with the client, you know. Yeah, we'll do a a full-blown assessment sometimes before we sign up with the client, but sometimes we don't still. Right. And we explain to them that we can't, you know, we can't predict the prices exactly. And then it's also we have to have a more serious conversation with the client about where they want to go, you know, if they want to do multi-location. If they if they want to expand, if they, you know, or if they're more interested in CAPEX versus OPEX, you know, um, all these different elements. Uh those are conversations that we need to have. But putting sales engineers to architect something without a, you know, understanding that the client's actually going to commit to it and buy it. Is is a huge waste of time. And just a huge money hole of time. Yeah. Couldn't agree more. Um, so let's uh maybe we'll chat a bit about the solution that you guys have have developed with strategy overview. Do you want to give us uh kind of your uh short pitch on how this solves problems for the MSP owner? Yeah, definitely. I mean, it's basically like a souped-up spreadsheet where there's a template behind the spreadsheet, which um creates standardized dropdowns, um, and has a budgeting roadmap component. So, it allows us to analyze the client risks. Um, we give all people that sign up our template that we use at our MSP. It's over 115 points of items, um, that we look at for every business and then we also have vertical specific items. So, we look at healthcare, financial services, construction, we have different elements that we pay attention to with all those clients. Um, once we run through this process with them. And again, it's template-based, so people can use our template, build their own template. We have people using it that are not even MSPs. Um, I know you guys have been using it and then kind of playing around with it. Um, just it's a way to standardize a consistent approach to doing things. Um, and then it has a three-year budget and a roadmap page that's generated off of all those items. And there's an executive summary section. It kicks out a beautiful PDF report. Um, it's just a really easy to use software. And then on top of that, we have a dashboard that forecasts the pipeline pre-opportunity and then gives you a total view of health into your entire stack and like a visual format. Um, we we're doing it a little differently, um, where we're an MSP and we know what people. You know, what MSPs like and you know, we're trying to treat ourselves like we want to be treated. Um, so anyone can get a free account. Um, they can run it on one client and play with it. Just stay involved in the project, pay attention to it and, you know, whenever they're ready, they can upgrade. We did the pricing where it's very um affordable for any MSP to any size. And it really allows people to standardize their whole stack, um, really elevate themselves to a a larger trusted advisor perspective. Standardize the whole QBR process, um, it limits their liability as an MSP. It's super fast, super simple to use. So, that that's what we did, we built it for ourselves and, you know, we're sharing with the MSP community. And we have over 260 MSPs using it and a number of top 100 guys. Um, and then a ton of MSPs in every community, HTG, Robin Robbins. Uh TPG group. So, you know, we're spreading through word of mouth right now. And everyone should check it out, strategy overview.com. Yeah, as you mentioned, I've been using it um uh for the onboarding process. So, I've taken the template and dumped all of the well, some of the MSP best practices. That I like to see in in in the client that I'm onboarding and then use it to stack rank the the uh initiatives that could be undertaken to improve the the development of of the company. Processes or uh approach or metrics that they should be viewing for their business. So, it's pretty flexible that way, I do like the the template base. And it helps eliminate, I think, one of the pushbacks to doing a QBR process to begin with. Is writing these reports is really time consuming. And I think that's a big piece that limits people from doing it on a wider basis to more clients. And I think having a tool like this to make it a a bit more repeatable and just, you know, pull up that template, run through a bunch of clicks. Once you you've got the first one done, the iterations after the fact are a ton simpler. So, it really helps facilitate those meetings and eliminate a lot of the manual labor of of having to create these reports and get something to review with the clients once you actually show up. Yeah, and besides the fact that we're saving a vast amount of time on sales engineering resources. Not being wasted. Just the time to prepare the reports, um, that's another really important thing. That, you know, these reports are not prepared by your level one engineers. Right, they're prepared by either your VCIOs or your your project engineers. Your level threes. So, we've cut our preparation time down from two to three hours down to about 15 minutes per client per quarter. From some of our most expensive resources. And that's tremendous savings. Right. Each VCIO and each critical resource can support a lot more. Um, because with the software, it allows you to pre-populate every answer through a template. You could always overwrite anything at any moment. But it allows you to pick from a a standard list of common questions and we just keep refining and adding to that. So, most of it is clicks. And it just makes it so much faster. So. And it's structured like Excel, so it's really easy to use as well. Yeah. Awesome. Uh, well, uh, we'll look towards uh closing up here. And um if uh people want to follow you uh personally or reach out to you to find out more. Can you tell them where they should reach out to you and and to to look at strategy overview if that's their interest? Yeah, strategy overview.com. You can uh connect with me on LinkedIn. My name is Alex Markov. Um, on the strategy overview site, there's a little chat widget in the bottom right corner. You can just go on there and chat and say hi. Um, go get a free account. Test it out, play with it. And um, you know, we're going to keep building it for the community and keep adding features that, you know, our MSP runs into. We just launched a partner advisory council. So, we have like 10 um bigger MSPs that have been using the platform for like six months on there. I know you're going to be taking part of that as well with us. And we're just going to keep building it for what the MSP community needs and, you know, find ways to make our life easier. And bring more value to our clients. Yeah, excellent. Well, the as we've talked about the VCIO and the technology advisor is definitely the way that the industry is headed. So, this will be a great addition as as people start to head down that road or uh continue to refine their their process once they're on it. Yeah, I think that's really the future of the MSP world. Um. I think MSPs eventually will be something more of like managed strategy providers, really can help guide the strategy for for clients. As services become easier. Um, the strategy is something that I don't believe will become a commodity. It's something that there's, you know, every MSP can have their slight flavor on it. Um, but every MSP is qualified to do this, they're doing it for their own businesses today. So, we just have to bring that same mentality that we bring to our own businesses to all of our clients. Yeah. Excellent. Well, we'll close it up there, thanks for your time today, Alex, I'm sure we'll be chatting more about the this process and the evolution of the MSP industry. Awesome, Todd, thank you so much for your time and yeah, stay well.

The Ops Brief

Weekly MSP ops insights, in your inbox

Frameworks and field-tested tactics for service-delivery leaders. One email a week.

Like what you hear?

Weekly group coaching, battle-tested frameworks, and a peer community of MSP ops leaders.