Community Fireside Chat | The Great Stack Audit: Rationalizing Your Tools

Don't focus on best in class. There's a real delicate balance. If you always put the client experience at the forefront, you will make good decisions. When chaos hits, you need to have a playbook. And welcome to January twenty twenty six, the first of the year fireside chat. We're so excited that you have joined us today. I don't know about your temperatures, but I just turned the heat on in my house. We've lived in Florida for five years. It's the first time we've turned the heat on. So it is getting cold in Florida. Please send your thoughts, and let's go ahead and get this started. So it's a pretty common scenario with MSPs. You look at line items at the end of the quarter, and you realize you've been paying for multiple backup solutions, a dozen zombie tools or shelfware, some folks call it. You've been haven't logged into those for months. So today, we're gonna move past a bit of the latest and greatest and focus instead more on the business side of building out your stack. Now we're gonna look at how you audit your chaos, how to build a decision matrix, and, how to stop auto renewing things that are killing your monthly, your monthly margins. So we're gonna meet our panel here in just a minute. But first, we're gonna start today with a poll. I'd like to do a bit of a level set on where we're sitting as an audience so we can customize this a little bit. So poll number one, this one shocked me when I asked the panelists. How many solutions are you currently using? Full disclosure, when I first built the poll and I showed it to the panelists, they kinda laughed at me because I think I had the top number at, like, fifty plus, and they were like, yeah. Nobody's gonna use that. So, we adjusted the numbers to be a bit more reasonable and, go ahead and get that answered, and we're gonna do some introductions. I'll start with me. For those of you who don't know me, I'm Becky Teal. I head up a lot of our community efforts here at Huntress, and I also host this monthly series where we bring on MSPs to talk about the things they're doing in their businesses. So, Nas, you're next on my screen today looking at one view. I know I'm gonna throw you on the on the spot here. Would you introduce yourself, please? Yeah. Nassello, Dallas, Texas. Our company name is IT for Scrubs. We do IT for health care. We're a smaller shop. We're around, nine employees currently, manage around nine hundred users ish. Perfect. I love the I mean, you work with a pretty unique audience, though, with health care. They they definitely look at tools a little bit differently than some. It's a lot of fun. And Mike. I'm Mike Johnson, VP of product management for Courser. Courser is a national, MSP. We've had about over twenty, partner MSPs joined together now to to form our organization. Perfect. And David. Hello, Becky. I'm David Steinwike. I'm the president and owner of Macatello Technologies. We're an MSP in Holland, Michigan, and we have nineteen employees right now. Perfect. So it gives us a bit of a level set. We've got a varying size here of MSPs on the call with us today to kinda answer a few questions and talk about this. Now, if we can see those poll results really quick, let's see where everybody else sits. And then, guys, if you're willing to share, I would love to hear the number of solutions in your in your monthly bills. Do we have So I'll go first. I actually had to look this up, Becky, because I didn't even know when we talked about this last week. And I was surprised at how many it is. So I would say, we have, close to two hundred vendors that we work with on a monthly basis, and I think close to maybe seventy. I had to double check. You put me on the spot, but we are in that, third one in the sixty to ninety, I think, total technical solutions. We're between thirty and sixty. They're actually a sales stack, technical stack. On the technical stack, we're slightly above thirty. We're thirty. There's some in under evaluation. We've been working our way down from over two hundred at this point. Yes. So very number of answers there as well. Looks like we're having some technical difficulties with the poll, so we will, we'll come back to that later. So when we talk about too many tools and auditing that that stack, how did you identify tool fatigue in your organization? I'll I'll start. I think for me, Becky, the joke or the thing that I would always say is it seemed as as we grew because we started with myself and my friend, my business partner, so it was just two of us when we started. And it seems like as we grew, the answer to almost every problem in our business was either we needed to get a new tool or hire another person. And I I see Mike nodding his head, and I feel like that's still, the case here. But as we've grown, you know, our service manager jokes now is because he used to push for more tools, and now he's kinda in the seat that I was of pushing back and utilizing what you have. So, yeah, it's been something we've dealt with for a long time. Yeah. I think for us, the challenge was just overall, nobody was speaking the same language. Since we had different tools that might have different things that you could implement a little differently than another one, each of our teams couldn't really function as one group. They had to function as a bunch of different groups individually with our organization, but we're focusing on offering a unified experience to our our clients. And so having that that disparate set of tools didn't allow for us to really present ourselves in the market the way that we wanted to be seen. Yep. Same, but just, tool fatigue is a big, big thing. And, as a smaller MSP, we always try to kind of, like, shape, our stack to be efficient and compliance in the same time without without having any overlapping, which is I think we're gonna talk about it in a little bit. So, you know, we talked a bit on our we do a prep call for these guys. So some of the stuff we've talked about already. On the prep call, we talked a little bit about how too many tools can start to affect your staff's productivity and sometimes their morale. If there's just too many things, they're expected to know too many tools, the experts what is it? Be the masters of everything, experts of none. What, was that something that you took into consideration as you started to try and maybe consolidate that a little bit? Absolutely. For us, I mean, every vendor brings a certain level of risk because they will they will be affected by discoveries all the time of different vulnerabilities or or issues that they have. And so the more that we had of those things, the more squirrel chases we had out there. Right? We had to go after each of those and individually monitor for those in each of our solutions, make sure we were on top of those, addressing them, patching them. And so that really is fatiguing to the teams, but it also meant that because one team might use something that other teams didn't, they're kind of isolated it on their own. So we can't really help each other if we're not using the same stack to get there. Yeah. It's really cool to add a tool that do, like, one thing or multiple things. And and we're tech people like, hey. It's shiny. It's beautiful. Let's just do it. But when you have a team around you and you wanna train everybody to use that tool to the best of their knowledge, to the best of the actual tool capabilities, it's kinda like really fatiguing these employees. It's like, hey. Take this. Next day, you come. You go to an event and you come with ten tools. It was like, okay. Let's have fun, guys. That doesn't work anymore. So, you have to think strategically on what's actually achieved, what you're trying to do. We're staying compliance and secure, of course. It's a big thing when our employees oh, I see the results. Oh, that's actually we're we're really bad, I guess. I I see that a big issue for the employees, especially also onboarding new employees. Just you wanna think about the time to get the employee to actually start being productive and working tickets. And more tools you add is just more time for, training. And, you know, another, GUI update out there, and it's just like everybody is shocked that next day and it's just, like, working around it. It's just bad. So we're trying to consolidate our stack all the time. So how did you start auditing, though? So, I mean, you had to start somewhere. It wasn't most MSPs start pretty technical. They get in that habit of bringing home ten tools, the shiny object. And at some point, you really do kind of hit a point where it's like, alright. We've gotta do this better business wise. How did you kinda make that decision, and then what steps did you take first? David, you had some good examples of your audit process that you started. Yeah. So we started, you know, frankly, we just relied on people. We had good people and, you know, whoever, I guess I don't even remember how we sort of identified who who audited the tools or who was in charge of them. But when we were, you know, smaller than we are now, was just, oh, Kevin does this or Tony does that or whatever. And when COVID hit, it was the first time we had really experienced some turnover, of our staff. And my memory is pretty good, but it's not perfect. And we started running into, like, okay. Wait. Who is the primary for this or that? I mean, the big tools, obviously, you know, but, our business coach used to say, faded ink is better than the best memory. And so we went old school. We created, an Excel document in on our SharePoint site and just came up with our tool list, and our vendors. Then we had who's the tool, what does it do, and then we had a list for the primary and secondary for who's in charge of that. And, so that was great. The other thing that we did and I don't remember. I think this actually came before that, what we call our tool and vendor task matrix. But, we implemented a text steering committee because what would happen is, you know, maybe you go to IT nation or whatever event, and you'd see the shiny thing. And I'd come back all excited about something, and I'd have to feel like I had to sell it to our team. And so we actually implemented a text steering committee, and we meet once a month. And we evaluate, what are the tools that we have, what are the sort of the business functions or outcomes that we're looking for from those tools. And it's been great. We've done that for many years. It's actually a little sad, Becky, because I just got off of that committee. Now we have it. It's run by our service manager. We have an account manager, a couple other people, and we're gonna do sort of a twelve month rotation so everybody kinda gets their their thoughts and ideas, and we can have the clients represented through account managers. Anyway, so that's how we do it. And the last thing I would say on that is, you know, we're we've been a part of the Evolve peer groups for a long time. And, Paul Dippel would always talk about, you know, the owners or the c level people that you talk to. They wanna know, will your solution make them more money? Will it save them money? Or will it reduce their risk? And so or as a part of our text steering committee, we're always looking at that is, okay. For our clients or our company here, will this solution do one of those things? So that's how we've handled it. And it's not perfect, but in our side, think it's it's working pretty well. I I love the concept of the tech steering committee where it's not just you. You know, as a vendor, we support not only owners peer groups, but we do support service manager peer groups for that very reason. That if if the owner comes home with shiny tools all the time and this the folks who implement those decide they don't actually wanna implement them at renewal time, it's a pretty hard case to make that renewal if it hasn't been utilized. And so making sure that you give other folks a voice, I think, becomes a really important element. The tools also feel kinda like a tax. Taxes are generally not repealed, and tools, it seems like they're hard to get out of the stack once they're in there. Yes. That sticky factor. Nash, you talked a little bit about your annual reevaluation process. Will you share a bit about that? Yeah. I believe in October, is what we try to do is we have on a calendar that we sit down and just kinda, like, reevaluate the tools that we have. Of course, like, throughout the year, if something comes up, like actually, yesterday, we had a we had a request from two different clients that we've been putting pause on that for a little bit, and now we feel like we really need to look for that tool. But in general, if there is not necessary to add something, We actually keep it till the reevaluation meeting, and we sit down and just go over it. Well, I love the fact doing it every month, but it's just impossible for our size. And not just that, it just if if a new, software or new tool that we're gonna add, that we really have to train everybody on, like, every month, because we're really optimistic. Right? And the cost as well. So it's not just necessarily, that we have a seat cost. Right? And we in a a small margin business here now that MSP is very competitive business. So we also consider that as well on top of what David said. Like, it has to either save us time or make us money. We wanna make sure if we're adding something that's an add on, it's justified, somewhere. And then Mike shared an amazing diagram that he had built. Mike, should we pull that up and you can walk folks through a little bit of that? Oh, I didn't I didn't bring that to the No. My team did. Here you go. Perfect. Excellent. So this was the kind of our methodology. So going back to how did we actually audit this thing as a whole? I I went to every one of the MSPs that we partnered with and brought up every category of solution that I could possibly think of and then had them tell me what are all the solutions you're using? Because we found that a lot weren't just using one. They were using three, four, five solutions for any given kind of category, whether, you know, that was security awareness training or endpoint detection. Like, they might have had multiple solutions even within their own team for the same purpose. And so that sprawl was a big challenge, but it also means I'm looking for different ways that we can get to a decision quickly. What will we standardize on and and how will we get there? So obviously, everyone here cares about cost. If you're an owner, you you do care about what your margins are. So the cost is gonna be a big factor in that, but it can't be the only thing because cheap can only get you so far. And so ultimately, the vendor support is gonna be one of the biggest criteria there. Are we getting good support from the vendors? Are they helping us recognize the challenges that we have and directing our attention to the things that need to be addressed and ignoring the things that we really don't have to worry about, you know, that that alert fatigue. Are they helping us overcome that? The next piece and there were three buckets there as well on implementation of management. We wanna know what is our overhead to actually maintain this thing in production. If we're going to roll this out to clients, how hard is it to implement? Is it a, you know, is this a two month endeavor? Another solution might be, you know, two weeks, two hours in order to to push it out. How how bad is our effort to support it? It might be easy to deploy, but if it's terrible to manage, that's another problem. And then ultimately sorry. When you see cross geo here, we we refer to our MSP partners as geos within our organization. But how do we share the opportunity between them if we need help in one location and they need to address a high urgency issue? Can we quickly and easily mobilize them in order to address that need in that other other team so that way we can we can share and help each other? But the biggest thing and this is where this all comes together is what does this do to our tool set? The goal of this is tool set reduction. We wanna standardize around one, maybe two solutions at most. But in doing so, I also need to look at what did we collect from everybody and understand maybe sixty five percent of our adoption already was on a tool. That that may influence our direction because that way we can reduce that way, we can get rid of a lot of extra ones. But sometimes that one location out actually had the right the right solution. It was doing something a little bit better than that, but at the same time, it's very hard for me to say, hey, over twenty teams need to make a direction toward what one was using just because it is a better tool, but at the same time, confidence comes through demonstrated success. If I could show you that we were able to be successful here, that we're reducing down the overall amount of work that we have to take on for our utilization, then that demonstration of success is what breeds the confidence in the teams who are having to make that change, and they don't really love that fact. It's a lot of information. I know. I'm sorry. No. No. It's perfect. So let let's talk a little bit just because you do have so many locations. I know, ultimately, a lot of the vendor relationship part of it falls to you. But do you have SMEs inside of Courser for each of the different tools? Does each location have an SME? Kinda how do you treat who owns I mean, there's the relationship over but but then there's the who who's in charge of being knowledgeable about what the tool does and how to use it? Yep. And we've been actually transitioning that. So we started with kind of a a geo specific SME. Everyone had one. And then over time, we started to realize it's very difficult to get those teams who have no experience with this spun up quickly and to feel confident that I am really the expert in this thing and that I know enough that if my team members come to me, that I can confidently speak to what they need to do or resolve in order to address that issue. And so that's when we started centralizing our teams around a centralized knock and working on bringing those resources together so we can say there's kind of one person for the company. They are dedicated to that, focused on that thing, and that this is the person or or people because we don't want to just kind of leave one person in that role. But these are the the the few people who are going to dedicate to truly deep diving and understanding that tool, getting the advice from our our vendor partner, our solution partner on that to identify what are the best practices around deployment, how should we be setting this up, ensuring that everybody is on the same page for that and that they they can be the resource to respond to questions as they come along. So we started with everybody having one, and we've been moving towards a more centralized model in order to make sure that that's a scalable thing. So I I talked to MSPs who do it a number of ways. You know? Some have one SME inside of their organization that's responsible for everything. Some have an SME per tool with a backup just in case that person happens to be out of the office and something changes. As a vendor who communicates a lot of updates, we're always curious. What are you doing, David Doss? Like, how are you managing that inside your company? Is it everybody's job? Is it just the service manager? What what's the ideal scenario there? I would say for me, it's a work in process, Becky. You know, we have you know, through our task matrix or vendor matrix, we do have the primary and the secondary identified. You know? And as new features or training comes along, it is up to that subject matter expert or their backup to kind of help train our team on that. You know, we have, but, again, with we have you know, if you think of the eighty twenty rule, twenty percent of our tools are eighty percent of the impact. So we really try to make sure everybody's up to speed on and trained on all, you know, that the twenty percent that are having the eighty percent of the results for us. But yeah. I mean, to be fair, when it's some of the smaller tools, I mean, even if we have a primary or secondary, you know, a lot of times those things will just get dropped. You know, we have a weekly service meeting. You know, I was in there this morning, and and this was kind of a part of the conversation, But it it's tricky. So I'd also be curious of what other people have that works better. Yeah. We it's for us, it's the the basically, I don't do any service. So it really depends on your department and your tools. So in our case, it's not a service manager. It's actually the lead tech, the senior tech, that do the evaluation and basically deciding. And I'm switching a relationship to be, his. In this case, I don't wanna manage technical vendors. I'm doing the admin in the sales side now, for, the stack. Basically, I manage those. So we're trying to delegate for the technicians, and they have their all the tech all the service department have their own, Alta meeting where they might throw an issue for a specific vendor, and that relation is between them. It doesn't come to the admin side. I I like that. Like, there's a good mix. Jared has a really good point in the chat that having a single tool person for managing and understanding the tools is kinda scary. It's a really solid point. The cross training is really critical. Vendor certifications, though. Like, there are so many available when it comes to certification. Do you require I'm guessing it depends on the tool. But do you require all techs be certified on all tools? Do you pick folks internally to be certified on certain tools? What's your approach there? This one, we did not discuss, so I'm throwing curveballs, guys. I'm sorry. I I can I can I can start with this? We do not push for certification unless it's, like, specific thing like Microsoft certification and stuff like that. It's always there is always a bonus if you get an extra certification. So we we just added a tool not too long ago, and two of the techs actually did the certification on it and wasn't required. It was pretty easy tool anyways. But we see the need, and it just really depends on the tool and what that tool does. I I generally look at certification as a pathway for that SME to really deeply dive that solution that they now own. And so for us, we we we focus on the Microsoft ones like like Nas was saying. That one's probably the biggest one. And typically because especially with hardware vendors and Microsoft, you kinda have to in order to qualify for their different partnership programs that they have. But beyond the ones that have that baked in requirement, the ones that we really focus on are the ones where I have a SME, I want them to deeply know that that solution. And so I ask them, go do the vendor training so that way you can you can know the most about it because generally speaking, that vendor will make sure that the the content of their training has has everything that that person needs to know in order to be successful. Yeah. Becky, and for us, I think, one of the the talks that was the most influential for me in all the years I've been in business was when, Peter Kajawa filled in for Paul Dippel. I don't remember where we were, but, the the subject of his talk was about how to attract and retain talent during the great resignation. It was, like, the our first or second in person meeting with Evolve. And he talked about trying to go for a twenty percent, EBITDA. And I thought, well, that's great, but that doesn't really have anything to do with, you know, retaining your talent. And then he went on to make the case where if you could standardize and simplify and get your people trained on everything And so we've really taken that to heart, and we've we really work hard on simplifying even though it is a little maddening to look at our long list of tools. Everyone has a purpose, but we really try to simplify the number of tools we have. And so while we may have a primary and secondary who are the owners of that tool, you know, people all need to be trained on it. Now we don't have a single person here, even our service manager, for instance. I mean, it's funny we're on a Huntress call here. He, at our service meeting this morning, he asked. He goes, does this seem like we're getting more of these alerts from Huntress? And everybody's like, no. No. No. No. And literally, like, thirty seconds later, his watch dings with an emergency alert. He's like, see, I think we're getting more. But then he made a joke. He said, but that's okay. He goes, I'm not the primary for this tool. And as long as I remember who our primary is for hunters of of that particular tool. But, anyway, to answer your question, yes, everybody needs a certain basic level of training, but standardizing and simple buying the number of tools we have is is really been helpful for us. That's helpful. Just I mean, as a vendor, I talked to other vendors, and we we always kinda joke, like, do we need a certification program? Are we missing the boat by not having something like that? And then we in the early days of Hunters, it was, like, certified on what? The dashboard has gotten more complicated, and there's more things to set up. But in some of the early days, it was like, what what are we training? Like, two. And so there's some conversation around, you know, what type of certification would be valuable. The Microsoft part makes sense, and that's a transferable certification that makes sense in the greater place. But if you went around telling all of your customers all the certifications your staff had, most of it would be alphabet soup to to your customers who that doesn't really impact. If you're not following the chat out in the audience, Cory Booker just shared an amazing list of categories with particular products, but some categories of tools where you might have unique vendors. Definitely recommend going in and taking a screenshot of that. It is a very large list, and I'm not going to read them all. But, it it's a good one. So you talked a bit about your matrix, Mike, on your decision matrix. Does that also apply when you're looking at renewing a tool, or is that really just for bringing something new on? Typically, it's it's which one we're trying to standardize on. And so overall, you know, I'm I'm trying to bet on solutions and and solution partners that are gonna grow with us over time. And so, you know, the more time I spend kind of reevaluating a tool and then remaking the same decision, the less time I can spend on getting to the next one. Because, you know, in terms of category, there were well over fifty categories that we were able to identify and wish to classify a solution. And we're finding more as we go along and we realize, oh, we didn't track that one. We weren't tracking that one. And so that list keeps growing. And then and so the the the worst thing I can do is to keep making the same one over again just because it's the one that we're most familiar with or it's the one that somebody who's been responsible for that in the past really focuses there. And so they keep drawing it back to that. But the goal is to be able to really decide what do we standardize on across the board and then also try to look ahead and say, hey. Some of these we've already we we've kind of made a decision in terms of what just who all brought their adoption to us. Do we wanna actually just go ahead and standardize on this one? But I also try to make it something where we we get the voice back. I've seen times where, you know, the most adopted solution that we had, people hate it. And they're actually like, no. We don't want that on the on the consideration docket. Please get rid of this one. Help us find something better. Or no. We really want this one into contention. Let's make sure that it makes it there. So we kind of start with that point. Everybody, you know, tell me whether or not what you brought to the table is something you want us to consider, and then we can start to whittle it down from there in terms of how easy is it to manage for us at scale and across teams and all those other things. That that makes sense that you you look at a number of factors. I love that there's the one of, oh, we all use it, but we hate it. So the importance of asking your teams what they think about a tool. Now are there certain nonnegotiables as you're looking at a new tool? Do you kind of have a list on your steering committee, David, of what are nonnegotiables? Yeah. So everything starts at that high level. I mean, on the recurring ticket that we have in Halo, I think that's the very first line item is the purpose of this committee is to ask the question, will it help us or our clients make money, save money, or reduce risk? So those are kinda nonnegotiables. I think it's hard a lot of times to evaluate that in the process. You know, one of the things that, you know, we have we have a some tools obviously have bigger impact than others, but, you know, try to interview other MSPs or hear some success stories. But, yeah, as far as nonnegotiables, I think one of the things that, has come up a little bit is who owns this tool, that we've had to kinda look at is we've seen some acquisitions in our industry, and we've gotten burned quite a bit. Another one, is around the renewals. We've also been getting burned on renewal verbiage that sort of snuck in, you know, on as you had licenses and suddenly the terms have changed because you agreed to it and, you know, the tech who so, anyway, that's becoming more of a nonnegotiable as far as who owns it, and the renewal period as well. I think one of the non negotiables for us is we we always pursue our SOC two type two certification and so or attestation. And so as a result, any any solution partner that we're going to partner with cannot jeopardize that. And so we we have an internal review around any kind of compliance requirements. And so our internal team are always invoked early on in the decision phase to collect that correctly from each of the vendors and make sure that they are not going to jeopardize that and or bring any additional risk. So we do have conversations about where's data stored, how is it transferred, and things like that. And so vetting out the compliance side of of a new solution partner, I think, is just as important as vetting out the cost of the other things of that model. And it it's probably the thing that comes down to whether or not it's even in contention. The other gotcha that I think we kind of ignored at first until our finance team continually reminded us is the finance team exists. They have to pay that bill and they also don't want a terrible experience in doing so. Because at the end of the month, when they're clearing all of these, every new vendor introduces one more. And so involving your finance team early on in the process, making sure whatever automation that they're hoping for and that is available by API is extremely important to their workload. And the the more you address that while you're making decision on a new partner, the happier they're going to be because they also sign your paychecks as a reminder. So Keep the finance people happy. I think that might be the best takeaway of of the session. Billing people matter too. Yep. And now, Noss, because you work in such a high compliance group of customers, is there different nonnegotiables for you? Yeah. It has to be compliance for sure. That's that's that's the first thing. The there are actually other things also just considering the different specialties that we service. So some requirements might change from one to the other. The non big nonnegotiable for us is just basically the the vent so what we do let me let us track it back to the prep call that we did. We actually evaluate vendors, and we have to have three vendors for each solution that we're trying to achieve. So if a vendor so you will see, like, certain tools that can do same features, but, like, one off feature because they're trying to get a market share in in a certain we're not gonna talk talk vendors, but we actually flag those. And we just wanna make sure that everybody we do in our stack is just achieve exactly what we're looking for. The extra cherry on the top, we love that, but we're achieving one thing, and that's what our target. And it does not have to be cheap. Cheap is very expensive, is what we say. We had that I had that conversation with my husband the other day that you can have cheap or you can have good. And very rarely do those two things hit the same mark. Like, you have to pay Always. Even when we are hiring now, it's it's a lesson. It could be, two, five, ten percent above the budget. And for our size, we got a the superhero, that's the person that's gonna work, whatever the cost is. That's so speaking of then, total cost of ownership of a tool. That ties in here too. Like, there's the price tag at the beginning, but there is definite total cost of ownership. David, you talked a bit about the labor split on our prep call. What is your ideal labor split when it comes to a tool? I don't know if we have an ideal, but I could tell you what we're doing currently. So being part of the evolved peer groups, we index to the service leadership. And when we do that, we do pull this out and put it into cloud revenue. But currently, for the way we run our financials, we're spending about twenty four percent of our well, technically, it would be twelve percent because we're looking for a fifty percent margin, in services. So but of our total cost, we're looking at about twenty four percent around tools and seventy six percent on labor. I think that's averaged out through all of twenty twenty five. I don't know that it's ideal, but it's what we're doing. I think few years ago, it was eight percent. Now it's up to twelve percent just concerning the amount of work that tools and AI can and integration needed. So we try to keep it at twelve percent. Mike, that might be a really difficult one for you to answer just because there's Yeah. I think it's branches. Yeah. Instead of breaking it down at a percentage because we're we're not really tracking it at an individual tool level because there are so many, we're making that decision around what what resources are available through that solution provider. So, you know, not to to throw the name here, but, know, Huntress is amazing at that for us because the backing of that SOC, the types of alerts that we get, the the effort that we see regularly from our account management team really have proven to us that we are getting excellent support as a whole. And so being able to do that, even if I can't qualify the exact percentage of of offset for that, I I can recognize it very simply because of of how many things I can recognize against what the tool our team was responding to before in a in a previous tool versus what we we now are having teams respond to. So we we can see that more through ticket volume than than through two per true percentages, but I think that's kinda how we we tend to look at that a little bit more. So sorry. I'm trying to communicate in the background too, and I get very easily distracted on this. There's a reason there's a production team behind me, guys, because I can't pull up polls and continue talking. So there you go. A little behind the curtain. Poll question number two. We're gonna move a bit into renewing tools. And so because of I've as every time happens, we have nine minutes left. So we've got quite a bit to get through still. How far in advance do you begin typically begin reviewing a tool before its renewal date? So, Nas, on our call, you talked quite a bit about how you're managing your renewals process, and you had built out a really cool process. Would you share that? Yeah. In our documentation system, we have an integration with our PSA, and what it does is just, I believe, sixty days before the renewal, it just opens a ticket in a billing board. I'm sorry. We changed boards. That's why I can't remember the name. In a billing board, and, basically, it's assigned to the somebody from the admin, or sometimes the service manager can even see that and just kinda go over it for now. And is we don't have all the vendors, but, like, the most critical was are in there, and we're slowly rolling these in. What we noticed also, David, I think, touched on that, is just the cost. It's been like, a lot of vendors kinda, like, really the renewals is higher. And if it's not within our reevaluation time, because we're trying to kill the noise during the year and just keep it to that month. We just kinda, like, schedule sometimes on it, just kinda go over it feature wise. Yeah. That's how we do that you built out some automation boards. That's so, David, how are you tracking all of those renewal dates? Because it doesn't all renew in the same month. Yeah. So a few different ways. We have, so we've also migrated our PSA. We're on Halo now, and so they're I think it's Lists, I think, is what you're looking for there. Used to be boards and where with, ConnectWise. But, so we have it set up in there. There's it's a little over my, area of of expertise, but I believe there's some integration with our documentation platform, and it creates tickets as well. But like I said earlier, the one thing that has tricked us, and we really haven't come up with a good answer, but, we've had a few tools in the last year, a couple of vendors where, you know, when you renew some of these or add licenses, it's changing the master service agreement behind the scenes and and the what you've agreed to, and it used to be thirty days, now it's ninety. And so we're sort of trying to meander through that as well. So, you know, the yeah. We'll just leave it at that. Yeah. And I think for us, like, we've had a a mix of of different experiences because everybody's bringing their renewal date to the table when they come in. So for us, we try to just look at the ones that we've standardized on because those are the ones I can say we should try to move towards those when the renewal period makes sense. We've done a good job in many cases in being able to catch those in advance and make plans far enough out. I can also say I've had some two weeks scrambles and a couple of cases where it was like we lost track of that, but we're addressing it because at least we know what the migration move looks like. And so I do prefer the former than the latter, but we we are equipped and ready to handle that as it comes. This year, we're taking a whole different motion. This month, we are heavily focused on all of any of the outliers that liars that are still there and any new teams coming on board. We will have already done that calibration upfront, so we know exactly at what point in the year they can move for every one of the solutions. Because this year is a big motion year for us, and so we will have done that calibration early on in the year and it'll be fully planned prior to our partnerships as well. Again, I'm my I'm mind boggled every time we talk, Mike, about the number of moving pieces. And I even feel that way about MSPs managing one location. Just you think of all those subscription services, and as they renew, who's staying on top of that. And, David, to your point, changes in terms make that an even bigger situation. So we talked a little bit about tools getting acquired. What is your feeling on that? When somebody gets acquired, do you give it some time? Do you start looking for a new solution? Does it depend? I know that's Yeah. I'll go out first. I think for us, Becky, you know, we've had a negative experience with a couple, you know, vendors, especially one large one in our industry. And so, there was a period of time there where it was, like, every few months, you know, as they're requiring tools, it's like, oh, man. Here we go. We gotta replace that tool now. So, it it depends. You know, when we, you know, I whether it's private equity or going public or whatever, ultimately, you know, we're just looking for the results of it and a good partnership too. That's another thing I would say is through this whole thing. We're not looking for vendors that we can just beat up over price or get the cheapest thing to Nas's point. You know, we're smaller than almost all of our vendors, and so, you know, we need them to succeed. So, you know, the ownership of their company doesn't really matter, and but there are a few out there that we do shy away from. Yeah. Same here. We have one, that we don't work with. And, luckily, none of our tools actually sold to that company, and that's that's pretty much it. We we again, it just goes in a evaluation. And if we can go month to month until we kinda reevaluate, it's just the way to go. Also, in the reevaluation thing and I'm sorry. I thought that question was gonna come up. It's just we look at the category of the tickets, and we wanna make sure. Is it is this tool actually saving money? It's just like there's AI tools that reset passwords or Microsoft three sixty five for our niche. We don't have we don't have two hours of actual employee work on resetting passwords. We don't have that many tickets. I think one or two per month. So that tool doesn't do me any good if my expense on it is less than hundred bucks per se, and I can just get another tool for that price, that achieves something that I'm spending on categories. So looking at the categories and your PSA and your expenses, before you decide who buys what ownerships are gonna change, you might sell your company to a PE firm. You don't want your partners, your customers to leave your company too. Like, the think about it this way. If you're still working with Becky in a huntress, Becky is amazing. Keep that relationship. Yeah. That's that's our approach on it. K. I'm blushing. You're picking on a really valid point, though, of making data driven decisions that it can't just be David, to your point, it feels like we're getting a lot more alerts for that. It's looking at it over an amount of time. And is this a tool that's actually being used? Is it something that needs to do we even need this thing anymore? It might have been important at a point in time, but certain tools don't age as well or the need for it changes. That's a really valid point. Mike, anything different? No. I think David nailed it. I mean, there are some vendors in our space that are known for buying amazing tools and making them mediocre. And so we we have a tendency when we see those kinds of acquisitions, we we stray away from them. And then we have others like and once again, I'll call out hunters for this one. They buy great solutions. They make them greater. And so that does tend to gravitate us a little bit more towards a solution that's being announced there because we've seen that that success track in the past and we can bet on that in the future we feel like. So I think, you know, generally there is a sentiment around who's doing the acquiring that gets weighed into that overall and the trust that gets built up through the evidence that they produced. But to us, I I know that we're we're open minded because ultimately at the end of the day, our goal is to provide the most phenomenal experiences to all of our clients that we have. And so we're going to meet that goal regardless of of how we have to get there. And as it always happens, we are at time, you guys. It there's always the first fifteen minutes that I'm like, are we gonna have enough? And then we hit this point, and I'm like, we didn't even get through everything. So, Cody, I believe we have a few slides to share really quick just to talk through a few. So next month, February, we're gonna be talking about Beyond the Tech Mastering the Business First QBR. We did a survey at the end of twenty five and, got a lot of great results. You do have an opportunity to fill that out if you haven't yet on topics you'd like to see, and QBRs was in the top three of topics people wanted to learn about. So, we're gonna talk about that in February. And, please, again, you haven't filled out that survey, it helps me continue to bring content that you want to hear about. And, gentlemen, thank you so much. Mike, Noss, David, you guys were amazing. Thank you for sharing, for being open with your input, and appreciate it. And we will see you all again next month. Thanks, Becky. Thank you so Becky. You, and stay warm out there, everybody.