ERP114 - Service Management and Automation

Yeah, and there's consistency issues too, right? When when you think about what a dispatch person or a tech person or a service manager may decide as the types of type and item for a particular ticket. There's a lot of noise in that. Just like there's a lot of noise in every process we have, right? So you can have 10 great techs, but they'll perform an action to resolution completely differently. Even though the documentation says do these 10 steps, they often times don't look at it because they're they're working from memory and looking at the documentation slows them down in their day. So, I think there's a lot that we can do with technology to remove some of those nuances. Welcome to Evolved Radio where we explore the evolution of business and technology. I'm your host Todd Kane. This episode is brought to you by Evolved Management training courses. A whole series of courses built specifically for your MSP training needs. There's a project management for MSP's course, an MSP service manager boot camp, MSP security fundamentals and an IT documentation done right course. Check out the full suite of courses at training.evolvedmt.com. Or look for a link in the show notes. Welcome to the Evolved Radio podcast. In today's episode, I'm joined by industry expert Gerway Todd. CEO of Time Zest and Pia. We delve into the transformative role of AI technology in ticket management, highlighting its ability to automate and streamline service desk operations. We chat about the role of the dispatcher and how it could be done differently in different ways in MSPs. We also discuss how AI and RPA tools are not only enhancing efficiency, but also creating new career opportunities within MSPs. Join us for an insightful discussion that explores how automation and AI are revolutionizing service management, boosting productivity and reshaping the future of MSPs. Gerway, welcome to the Evolved Radio podcast. Great to be here. Thanks, Todd. If you could start, just give us a bit of a background. You got a bit of a story history in the MSP market. Uh if you want to give us a bit of that rundown and where you've been and where you are now. Okay, yeah, sure. Happy to do it. Well, I started in technology prior to YTK. Were you around for YTK? Absolutely. Yeah. That was a joy, wasn't it? It was a wild time, yeah. Yeah, it was a wild time. But a little bit after that, I got involved with Connectwise back when it was about 50 of us uh in Tampa, Florida. Little tiny office here in Carolwood, small part of town. Uh that was 2008. I joined as director of sales. I ran sales for a couple years and then moved on to help out with all the M&A work we were doing and the decisions we had made around acquiring Labtech and Chartech and uh along the way. So, that was great. Ran through that journey until 2019 when Tomo Bravo joined and took over the business. And uh decided to go on and and pursue some of my own entrepreneurial initiatives and and goals. So, the first thing that I did is at that point, I was I was looking to try to solve challenges in the industry and one of the first things that I kind of came across was the advent of AI. You know, back then, we had Alexa working, we had home automation things kind of going. And um we also had what I'd refer to as NLU applications. So Twilio and dialogue flow and and what Google had acquired from dialogue flow, it still exists today. Twilio still has their application too and back in 2019, it was pretty early days, you know, this is before Chat GPT and and the world kind of seen what's possible. But a few of us in technology had seen its capabilities. And I was working on a solution to help solve the triage challenge. And in around triage, you know, we all face the challenge of you've got a this inflow of tickets and someone's got to categorize them and we've got all these types of types and items and you know, what's the consistency of figuring out what that should be and there's a lot of repetition in what's done there and there's also a lot of repetition in what we've got to collect to be begin working on problems. So if you imagine, you know, a printing problem, we've got four or five things that we need to know before we can really start solving that issue. And so I saw AI as a capability to try to solve some of those challenges. And unfortunately, COVID hit. And then I had to kind of pivot, make a decision on what I was going to do. I wasn't in a position to continue to invest in the business at the degree that it needed. And um so I pivoted to Time Zest. And a couple co-founders in Time Zest. We built that business and that business is currently running today. And then I just kind of never let go of my interest around AI. And I found myself kind of always wondering what was capable and seeing some new technologies emerge like Pia and so forth. And um I decided to partner up with the the Pia team. I I really got excited about what they had built. And I also took what we had built at Trify, which is the solution around triage and took that technology and embedded it and brought it into the team with Pia. Okay, great. We're right today. Yeah. So, I maybe a point on that. I am curious. Uh so you have a a dual CEO role with Time Zest and Pia. Is that right? Yep, I do. So you're a busy guy. Like what what's the the flex between those? Like does Time Zest fairly mature? I imagine maybe requires a little less effort than it did in the early days. Like how do you how are you splitting your time between the two companies, I suppose? Well, I think, you know, number one, it starts with great teams. And I do have great teams on both sides of the businesses. I on the time to side still does require quite a bit of time. You know, I'm still relatively full-time effectively in that business. But what helps a lot is I have a lot of team members in Pia over in Australia. And so what happens is I have teams showing up at different parts of the day. In our evening here in the US, they're the Australian team starts to come online. And so what I find really kind of late afternoon actually on the East Coast. And so what I find is I just have to work longer days and that's that's doable. Yeah. Okay, fantastic. Leading up to this, we kind of chatted about some things, um differences on tips and tricks on service management. because, you know, your your early days of time zest mean a lot of that was based on improvements around service management. and being able to connect techs with the people that need support in timely fashion rather than playing telephone tag and constantly missing each other as everyone is familiar with. Yeah, I'm curious just in general like through either through the practice of building time zest or sort of other things that you've seen in your time in the industry, what would you say are some of the top tips that you would provide to people in service management? an MSP looking to either sort of skill up on from where they're at or maybe they're mature and kind of missing a few of the marks. What are some of the things that you would suggest that people take a peek at? Good question. I think there's a lots of solutions in the world to kind of adopt and go about thinking about ways to reinvent your service desk. And so I won't focus on just the technologies that that I'm associated with. What I try to think of is the philosophy of of management, of leadership, of how we go about getting to operational maturity and always moving the ball forward. And so what I would say is that for anyone that has not made change in their service operation and their delivery, there's a real issue with that, right? I think we have to be always thinking about in in my businesses, in in your business, and in all businesses, we've got to be thinking about how we're improving how we deliver service, how we do it at a higher level and how we grow our maturity in that regard. And so what I think about, what matters to me most is that we're doing something to innovate that delivery. That we're doing something to change it, to improve it, and we're always thinking about what that can be. And so what it is doesn't really matter to me. What matters to me is that we're making forward progress. What I look to is is if someone hasn't changed something, hasn't improved something in their service delivery in the last three months, six months, that's the fundamental problem. And that's where I would want people to spend their time. It's just, you know, if you think about what we have to do as an industry, we have to be thinking about how we differentiate, right? Differentiate from the cable company. We have to remain differentiated from them by adopting new processes, improving our maturity and pushing forward. So, that's what I like to focus on in that. Yeah. I often suggest uh, you know, in the MSP industry, we're we're a service company that just happens to focus on technology. And we sometimes think of it the opposite way of we're here about technology and we provide that through service. But I I think it's more important to focus on service first and technology is simply the area of focus, right? Absolutely. Absolutely. Yeah. Yeah, it's it's also interesting because like uh we're in a fast-paced industry, you know, kind of everything I suggest has like a six-month shelf life. So, you know, things go fast. And you know, if you're not evolving and adapting your your service delivery and at least sort of focusing on like where's the friction? Where can we kind of create a better experience for the customers or even to create a better work experience for our techs. I think that's something that kind of requires that constant iteration and attention because the other thing I I sort of suggest is like everything is subject to entropy and it just sort of spins apart after a while. And if you're even if you set something in place and think it's pretty good, it probably will start to fall down in, you know, six to eight months and require kind of packing it back together and figuring out, well, like what's not working? How can we fix this going forward? So personally, I find that that's a really fun part about operations and service operations is there's always more to do, right? People sometimes view that as too much of a challenge, but I think it's an important aspect of of just viewing that as sort of a bit of a fun aspect of like, huh, okay, what's gone wrong here? How can we improve that, right? Yeah, you know, Arnie used to say this really well. He'd he would talk about our processes, right? at Connectwise. and say, the moment you're done touching it, it has started rusting. Yep. Right? So now we got to knock off the rust. We once we have to circle back to our old processes and knock off the rust because the last time you looked at it, it's rusted since that time. So it was it was really a really good way to think about it, like you're saying with atrophy and and what not. Same same kind of concept there. Yeah, yeah. One of the other things like I kind of run counter in the industry and I'm curious to kind of get your perspective on this. is dispatcher or no dispatch? because a lot of the industry advocates for dispatch and my feeling is is dispatch is largely an administrative band-aid for organizations that can't get their text to manage their ticket queue and enter their time. I understand sort of the the necessity of it, like certainly from a triage perspective. I'm less set on the idea of having a sort of a person that is a dispatcher. And I recognize like this is not like my view on this uh is a fairly strong opinion loosely held as most of my opinions are. I'm happy to be wrong about this and I think there are certain aspects where in certain circumstances where I am wrong. But you've had to look at triage and think that you were saying at the top like that was one of the things that you were sort of uniquely focused on and how AI could enable that. Uh so what are your thoughts on sort of the best practices as we call them in the industry of utilizing a dispatcher for service support. All right, well, let's start with the disclaimer here. We definitely aren't trying to displace dispatchers in their jobs, right? You and I are not trying to in any way. I really, really deeply respect the work that they do, but the key thing that I think about a lot in what they do is there's a lot of administrative work. And quite frankly, the best dispatchers that I've ever worked with or ever seen operate are chess masters, is the way I think of it. They are five moves ahead in the day. They are thinking about all the things that need to get done and making helping make sure that those things are coordinated to an outcome so that customers are happy at the end of the day and techs haven't just melted, right? and burnt in their seats because they've just been overwhelmed. So, what I think about is we have a lot of administrative work on their desk. They're doing scheduling, they're managing triage, they're often times picking up the phone, they're often times logging tickets, in addition to that, they're trying to sometimes assign work and balance the work load amongst the team and make sure that people are working on the things that they should be working on. There's some debate around what's right or wrong in that model. And I think let's start at the beginning, right? The beginning is, I think the role was defined, in my personal opinion, the role was defined to fill a gap. There was a gap, the service manager needed to be off working on certain things and couldn't do the role. And so they needed someone to be able to be full-time. once you get to five or six techs, you really do have a little bit of balancing you have to do in that team to make sure that that people are kind of where they need to be and everything's assigned out and and things are going the way they should be going. And I think that to quite a degree, you know, some of what we've done historically is quite old process. I mean, very, very old process. Let me give you another example of what from my connect wise days and what I saw from Arnie and what I learned from him. If you think about the dispatch portal these days, whether it be any PSA, right? They're effectively what used to be there before technology. So, back in the day, before we had technology and applications that could do this for us and provided a dispatch portal, there was a whiteboard in the office, right? Yep. And on that whiteboard, it was the same grid. It was resources on the top and time during during the day and it was just magic erasing, you know, who's worked in what and wiping things off and putting things on and who's rolling the truck to this location and who's going there and what are the hours and and so forth. So, all we really did was take that whiteboard and move it to an application. It's true. And so now we see it on our screens, right? on our PCs. I don't know what what are your thoughts about that? Would you agree? Yeah, 100%. I yeah, in my in my office, I had a whiteboard that had, you know, service up top and projects below. Um and and it was sort of a two-week window that I would sort of constantly sort of manage things. This was more in a var setting. But I totally relate to this. I've never thought of it in this description, but you're totally right. Yeah. So it's been right for reinvention, I guess is the point, right? There's there's it's been right for an opportunity to just kind of think differently about how to do the job of dispatch. And at what point do you really need to have someone doing dispatch and can you empower those that are doing dispatch today to be working on higher value things. And that's kind of the mission in my opinion at this point in the MSP. You can potentially, to your point, you can potentially give a service manager enough tools to where they are able to guide the tech team and not have to have a dispatcher, maybe they can wait to hire a dispatcher or they don't have to have one as soon or they can repurpose a dispatcher to go work on project coordination. Or we you know, we had plenty of dispatchers that also want to become techs potentially. And so there's just there's career progression that you can have for these these dispatchers and but you have to give them a way to get out of the of that job, right? In addition, you can empower them. You can empower them to do more, you can empower them so that you don't have to hire a second and third dispatcher as you grow and scale and you can manage with just one. And so I think there's some interesting ways to kind of look at the problem. But I do think it starts with technology, number one, and number two, I do think it starts with reinventing the way we go about it. So use just use one example. AI and just use Pia in this case, Pia is capable of categorizing every single ticket that comes in. And let me be very, very clear about that. We can categorize comfortably 93 to 95% of tickets. So not every single, not 100%, but pretty good percentage based upon what this technology can do. What we're using is we're using some AI tech to basically read through the ticket and to assess what the issue is. And from there, we take it and we assign the type sub type and item. So right there, one task that is just been a really monotonous, administrative task for someone, right? Whether it be a dispatcher or an assigned tech for the day or whatever the case may be. Whoever's doing the dispatch function, I call it wearing the hat for the day. Yep. They're having to do this really monotonous process of figuring that out. Now, the 5% or even, you know, call it some sort of error rate in the 95% that we do, wow, think about the cognitive load of that. All you're doing is reviewing, did we get it right? All right? Okay, we we maybe had a little nuance in one and you want to change it. Well, that sure is a lot easier than manage 5% or 10% of the workload to a change versus having to do the whole pile of tickets that come in in a day. And so that's just one great example of taking some of that cognitive load off of the team and also reinventing the way we go about it. Like we don't have to have team members clicking through there, reading through the whole thing quite frankly, spending all the time to try to assess and and diagnose what the problem is and then, you know, triage that particular ticket. Yeah, so two points. Um I'll get off my my dispatch bandwagon uh here shortly. But I think like it's funny because the more I talk about this with people and it feels it it seems like I'm coming from a point of opposition. I think there is actually a lot of agreement. So, I never suggest that dispatch is not required. I think to my point and I think you kind of called this out is like, I don't think dispatch should be a particular person. Like the way that I view it is dispatch is a function that gets embedded into the triage team and you kind of rotate that around whoever's primary for triaging and answering phone and you know, setting the tickets appropriately. Less so on the putting it into someone's calendar. That's the part that I don't really feel that strongly about, but I do feel like there's a lot of opportunity for service coordinators, right? Where they're a tech is sort of crunched, they're two tickets behind, they reach out to the coordinator, hey, can you contact these clients and let them know we'll reschedule this. They play more of a support role. And I think you're right, like there are a lot of opportunities for those types of people that are sort of strong administratively to move into higher function roles like project coordinators. This is the other thing I've been talking about a lot this year is projects are are sorely undermanaged in MSPs. I think that's a great career opportunity for people. Some of the best project coordinators and eventually project managers that I've seen are office managers or dispatchers. because like they're just more administratively minded, they follow a process, they're quite comfortable with that. That is the sort of the shift around this that I think is is really important to understand is don't just have a dispatcher take tickets and try to put them on someone's schedule because then there's a learned helplessness that creeps into the tech team and a lot of sort of friction that ends up between that dispatcher who is not their boss and the tech team. The other point I love about sort of processing tickets and setting type sub type automatically, is this is really important data that doesn't get the light of day in most MSPs that are sort of mid to lower maturity and don't tend to focus on these things. I use a ton of data in the work that I do consulting with MSPs and 25%, 30% or more of the tickets often the sub type is must change, right? Yeah. Yeah. Well, obviously that didn't happen. Um and there's a ton of useful data that can be in there. Like where is the volume of the noise coming from? What are what is the majority of the work that we're doing with the team?. And without that type sub type being set, it's kind of subjective. It's, you know, what do you guys think takes a lot of time? And that may or may not be true. So I think the advantage of this of leveraging some smart technology to offset this so that you like you say, people are not kind of clicking eight different boxes before a ticket actually gets queued up is really advantageous for everybody. Yeah, and there's consistency issues too, right? When when you think about what a dispatch person or a tech person or a service manager may decide as the types of type and item for a particular ticket. Yep. There's a lot of noise in that. Just like there's a lot of noise in every process we have, right? So you can have 10 great techs, but they'll perform an action to resolution completely differently. Even though the documentation says do these 10 steps, they often times don't look at it because they're they're working from memory and looking at the documentation slows them down in their day. So, I think there's a lot that we can do with technology to remove some of those nuances. Yep. At least we'll get it consistently wrong. Right. Well, then at least you'd notice some some problems in the data and be able to correct against it, hopefully, right? That's right. It it's all a process for sure. Yeah. So, like to dip a bit into into Pia. I I want to sort of pause a few things with you and and for the audience, I I did sort of clarify this with you that I would come at this from a bit of a skeptical view. Yeah. And I have some opinions on automation, especially RPA. which Pia certainly leans into. It's also got an AI element, which I think is really cool. Like I want to understand maybe from your perspective, like Pia is part chat engine, part AI, part RPA, like how would you sort of define what are the technologies that are sort of predominant in the tool? Yeah, I I would actually like kind of remove chat from anyone's line of thinking. Like we use kind of this it appears as a chat is happening back and forth with the application and it is in that in that form a chat, but what we're really doing is just interactively trying to gather the proper information. But if I take it back to the highest level, our mission is quite simple. What we are trying to do and what we're working on, what we have solved is automating the issues that hit the service desk. And the reason why we're doing that is because we've seen what RMM can do for the endpoint, right? We've seen what we can do with RMM technology and the automation we can have with the scripting that can be done there. And so we looked around and said, and this came out of our MSP in Australia, VITG was the source of this, much like Connectwise, the MSP was the source of Connectwise PSA. It emerged out of there because they were trying to solve the challenge of, okay, RMM's done something great, but it's not going far enough. It's not taking us to the next level of where we need to automate. And where you need to automate next after you've automated at the endpoint and the servers is you need to be able to automate on the service desk. You need to be able to find a way to make techs more efficient. They shouldn't have to be processing 10 tickets a day. You can process up to 20 tickets a day with automation. And so we're proving that. We have customers doing it every single day and we have VITG doing it every single day. And so the way that happens though is that when we have a service ticket, what we'll do is we'll categorize it as we mentioned before, we'll triage it. When a tech gets to that ticket and is ready to work that ticket, we will pop up as a pod in the PSA. And it's like a chat pop, you know, you kind of you you see a chat pop up there and you can activate it. And effectively what we do is we we try to determine if we can automate the resolution of this ticket. So use a like a new user added needing to be added to Microsoft 365 as an example. If we see it as a new user ad, we will prompt the tech to let them know we think we can automate this, would you like us to attempt to do that? And they click the button, they authorize it. We then start our process of running scripts, of checking for licenses, of going out to pack 8 and other services to determine if there's a license available, determine if we've got to procure a license. We basically go through all the steps that are in IT glue and that kind of documentation platforms and we've moved it into a system within the ticket. And so what we're finding and so what you what that that kind of chat experience you're referring to is we need some inputs along the way, right? We need to make sure that we've got the name right for this individual. We've got to make sure that we've got the naming convention right for the email address and so forth. And there's just other little bits of input that can be prompted along the way. And then along the way we are making all of the changes to all the services that we need to change to effectuate that new user ad. And so effectively, what we're trying to do, our our mission here is to reduce some of that cognitive load on a tech, right? Also complete work in a much quicker fashion. Sometimes it can take up to 45 minutes to do a new user ad, we can do it in under 10 minutes with our technology. and a tech team member supervising our technology. And what we're also finding is that there are some functions or some automations in the business that are often times reserved for level two techs, we have democratized that and brought it down to the level one tech, right? So if we can put it into a system, we can have the system know what parts need to be changed. So as an example, if you're 100% cloud, you have a client that's 100% cloud, that's all they've got, and you've got another client, client B that is hybrid. They've got an exchange server on prem that needs to be synced with the cloud services. Right? That's a different set of steps that need to be taken. Our system can be configured to understand that and then we can effectuate those changes appropriately. On its face, like uh it it feels like it's at least an interactive bot that can execute scripts. is sort of a very simplified way to to understand that, but maybe like the part that I'm I'm sort of cluing into here is it is more flexible than that. Like just to, you know, one of the things that that people have asked me about Pia is, you know, what does it add outside of the existing tools? Like if we have an RMM, we have this information, we have a library of scripts that that we have in the background here, we can just execute those. I suppose there's a level of interactivity and error checking that kind of goes into the Pia tool as an advantage over that, I suppose. Is that am I sort of reading that right? Yeah, and what we have found too is that the RMM scripting that is done is not specific to these particular use cases. That's what we have found. And number two, what we've also found in our experience is that, like I mentioned with level two techs, often times a level two tech is the one that has access to the RMM, right? You're not granting that access to a level one tech. What we're trying to do is give the level one techs the automation they need to do more work. To be able to take on more types of tickets in a safe environment where all they're doing is executing a safe script to run that they're capable of executing and we're guiding them through that process. Right, so like an industry term for this type of activity is usually RPA or robotic process automation. You do like do you align kind of internally with that as feeling that you guys are an RPA tool or do you see it as something different? Yeah, I I think of RPA as the hands and the legs of a body, right? Like it's got all that it needs to do to pull the levers and change things. And it's kind of brains as you you might want to call it are pretty limited, right? It's triggers, it's triggering off of a variable, like a data value or something of that nature. When you add AI on top of that RPA, when you take AI and you add automation to it effectively, you're going a whole, you're you're really changing the game in a lot of ways. Because as I mentioned, what we're doing at the very beginning is we're saying, oh, we found a ticket that we believe we can work. Right? That's a whole different set of events than here's a trigger on a data value and I'm going to run this set of actions based upon that. And what I've also found is that you need that AI technology to solve the complexity of the volume of information that you can receive in a ticket. You're not going to get that out of an RPA tool. They just don't exist that way. You you need an AI technology, you need to use an NLU engine or an NLP engine to be able to accomplish that goal. Okay. I guess the other piece that sort of worries me, like um one of the things with automation that sort of drives me a little crazy in the industry is how much vendors and things sort of tout automation as the savior for the work in the help desk. of, you know, we'll increase your technician's productivity by 80% and you can automate 50% of your work. And it's sort of like this utopia state that gets sold to a lot of MSPs that I don't think is entirely practical. There's a lot of different reasons as to why. One of them that I find is particularly prevalent around the limitations of automation is that there's a sort of a technical and time budget requirement to make these things really work for for an MSP. So, automation, I feel is pretty valuable, but doesn't really apply to some of sort of the middle or lower maturity MSPs, which quite frankly is is a vast majority of the market. And it it sort of worries me when I hear owners talking about things that they could do to improve their business and they're not focusing on things that I think are really important like culture, standards, having some processes, like good management practices, good leadership, those sorts of things that I think have a real material impact. And what because they're technical people, they want to focus on, if I could just automate this work, life would be so much simpler. And I don't know that that's entirely true around automation and I feel like all the conversations around RPA are an extension of that of like, well, now it's even more powerful. And we can do all these other things. And we're sort of selling these promises that don't really come to fruition for the majority of the market. And maybe these tools are better marketed to sort of mid-size and and larger organizations that have the cycles and sort of the technical know-how of how to actually spin these things up and automate. I would say like what you guys are doing at Pia is maybe slightly different than that. I'll give you some grace on this of not falling into the same bucket because like you said, you you're kind of creating these actions that have a bit of error correction, there's QA that happens through the interactive nature of it. So it's a little more flexible. One of the things that does worry me though is like the edge cases where like um I guess how much of this gets handled by the interactivity because not all of the client environments are standardized. And you know, if you have a certain recipe to do a certain process like a client onboarding, you mentioned like maybe it's cloud, maybe it's on prem, requires sinking, how does it handle that? But like there are lots and lots of variables across the client set that potentially create a lot of complications where it's like, well, this works for these three clients, but it doesn't work for like these six other clients because like their environment is different. So how does it adapt around non-standardized environments? Well, that takes our team. It really at the end of the day, it takes our technology team to sort through these different instances and scenarios that we run into and fortunately, I I think we have attacked it the right way. The team even before I got here was attacking it the right way and their approach was, we have these various environments that we face. But there are there are some consistency, right? There's like four top configurations that we face. And what we have to do is we have to support all four of those configurations to make it a plug and play kind of solution. Now, to your point, nothing is really generally plug and play, but what we have really worked to approach this with is to solve that lower maturity team member or company that that is out there dealing with a little bit of a hodgepodge of circumstances. And what we've done is we've worked on solving that with our implementation team and solving that with all the various use cases we can support on our platform. So, if you look at a lot of what we've spent time on, it has been dealing with a lot of that, a lot of that inconsistency, helping people be consistent, sharing with them, here are the four scenarios that we do support, you know, if you aren't configured in that way, then maybe we can't support them and and they aren't a customer of ours at that point. But we're really working on is solving for those cases. Now, you highlighted one other really key thing and that is is as technology people, we look at every problem as a technology problem, right? And we don't think so much about the business side of what we're doing and the people side of what we're doing and the management side of what we're doing. I think you're right about that. I mean, I think in a lot of ways, and hopefully no one's offended by this, but a lot of MSP business owners are accidental entrepreneurs, right? They're the best tech in town. They start their phone started ringing before you know it, they're filled up, their schedule is busy, and they're hiring another tech or two to help them in the day. And a lot of MSPs have started that way. I I know plenty that started in that fashion. And, you know, they didn't go to school for MBAs and they started with technology and that's fine. But I think at the end of the day, there does need to be more of a focus on things like implementing EOS and traction and and taking a leader approach to the business versus a technology approach to the business. And how do you build the culture that you want to build in the business to ensure that you've created a space where everyone is is working as teammates and and as peers. So, I'm with you. And I think there are some great organizations that help with this. You know, peer groups are a tremendous way to get this kind of insight and how to run your business better and how to not think about it as everything is a technology problem, but as a business challenge and how to go about maturing your business operations. There's plenty of content out there in peer groups to help with that. Yeah, I often say uh tools don't solve people problems. All right? And that that's not to say that tools aren't useful. They are 100% are. But I I think start with the people problems and then there's a lot more material that the tools will be effective to support you with, I suppose, right? Yeah, and I think so to your point, you know, the our mission is not to to remove the people from the equation, but what it is intended to do though is that if you've got a team of 10, what if you could wait an extra six to 10 months before you have to hire another person at through your growth, right? So the the issue we have found is that commonly, a relatively middle of the road maturity MSP will be able to support about 200 to 250 end points per tech, right? Our mission is to get them to 400 end points per tech. That's the goal at the end of the day. So we see it in our customer base, we see them being able to say, well, okay, it took us six months, right? We implemented your technology, it took us six months. But now we are actually seeing it because we've got the volume of ticket automation happening, we are now starting to move from 250 end points per tech to 300. We don't have to hire that next tech as quickly as we had to before. We can be a little bit more thoughtful about how we go about that. And it's not this constant game of for every 200 end points that we add on that we've got to hire another tech. We can delay that process a little longer. So we're seeing some tremendous value out of that. Yeah, I think uh maybe I'd love to get your thoughts on also sort of the future impacts of AI. because the way I've sort of laid this out can maybe feel a little scary for some people, um that you know, AI I think will eventually start to really eat up the service desk. And I I sort of position that not as a scary idea, but it actually helps us to go back to the roots of consulting and be more engaged with the client, providing more business level consulting rather than just sort of the break fix commodity of the environment. recognizing that like we're not trying to build stuff that displaces people from their job, but I think inevitably down the line, there's a lot of work that will be sort of chewed up by machine-based systems and and utilizing AI in a service desk. What's your feeling about sort of like you you think about AI a lot. What do you do you feel like that's true or like what is your future view of the AI future for MSPs? How many days do you have to chat about this one? I think about it a lot. I I I started this as a post like two and a half years ago, so I'm I'm watching to see how my my timeline is bearing out in the in the industry. Yeah. Yeah, this is one of those big debates, right? Like Elon and everyone wants to talk about where where AI is going. It is obviously very hard to predict. And I think that there does need to be controls in place around AI and what the technology can do. But what I would share with you right now is that AI is in such an infant uh stage at this point, I don't think you and I need to really worry too much about what it's going to do with the world. There are other people to probably address that problem. And obviously, I'd be happy to chat with it, but it is just one of those really challenging subjects of where that will all go. What I believe though with regards to where we're at today and where we're kind of going as it relates to the MSP business model is the following. Look, I think the reality is MSPs are always transforming. And you had mentioned of R in the past, right? Like the origination, if you were a business in technology back in 2000, 2005, you were likely a R. And maybe just beginning to dabble in some sort of MSP related contractual engagements with certain clients, but you were doing networking, you were selling PCs and installing servers and doing data center work and stuff like that. So that's transformed. You know, it moved to break fix and then it is moved to MSP and and we now have CSP in front of us, right? So are we on the same page with CSP? Those that are just pure cloud service providers, really doing very little IT infrastructure work, very little kind of IT plumbing work and really almost focused 100% on being business analysts around maybe some key line of business applications and bringing a solution set of services to bear to help, you know, particular verticals in this industry do better and and really architect a technology solution for an outcome as VOs would do, right? Is that something that you've seen a little bit more in your client base? Yep, that's I you know, CSP, TSP, just sort of the the future of going back to consulting around the business and just leveraging the technology. Like I you know, a lot of people suggest the cloud stuff makes it so simple, then what would be the purpose for us? Like can people self-serve this? And there's still a lot of confusion and mystery around like the varied solutions in the cloud and how they all integrate. So I think there's still a lot of work to be done. I think your point is maybe is this is just an evolution, right? Yep. Similarly when, you know, I was around in the the early days of Bpos, right? The original iteration of Office 365 and I would have these conversations with varcentric people and they're like, this is crazy. Do you know how much money I make on exchange upgrades and maintenance and support? They can't do this. The margins are so thin. Like who argues for that now? Like you don't have to deal with the back end of exchange. Stuff just works and sure, like you've moved on to make a lot more money in other areas. Like that's not necessarily a center of your business anymore. So things do change, will change and we'll have to evolve with it, right? Exactly. And and I think that's the the point here is that that that evolution, if you're aware of it, if you're watching it, if you're prepared for it, will dictate how you need to architect your business and how you've got to make that transformation. So, I actually have a business partner, Jameson West, he was um out of Seattle. Do you know Jameson? I know Jameson, yep. Yeah. So, um he was out of Seattle and that Bpos transition happened and then when Microsoft 365 and Skykick came out and they were doing, you know, the transitions from exchange up into the cloud. He saw what was happening. And and he started to transform his business then back then. What his philosophy was, I think it was exactly right is the following. The people that we need to help service the CSP environment of the future is entirely different than the people that we have today. And it's an unfortunate thing. And some people have gone about saying, let's just build an entire CSP business and we we won't have that the same help desk. It's not going to be managing the same stuff, right? We're going to be moving into a world where we have to do more business analyst work and less helping with, you know, making sure servers are running kind of work. Now, I'm not trying to proclaim that that's happening overnight. I'm not trying to proclaim that that's happening right now in the sense that you've got to be there today. But I do think we have to understand where things are moving to. And to your point, you know, as more and more technologies move into the cloud, and it's going to happen with line of business applications too. You know, I was I was in banking software in 2008 and I was working on Cobalt code on mainframe systems, right? I knew it was dinosaur technology. I knew it was dinosaur environment. I needed to get out, right? And so we're we're kind of seeing that with line of business applications too. Any line of business application that isn't cloud-based today is just a dying legacy product that will one day die. I promise you that. I and I've seen it. I've seen where new technology will come out and will eventually catch the feature set of that legacy solution and it will be gone because it's not as usable as cloud technology is. And that's the real problem, especially with how remote we all are these days. So I think the remote nature of things, that the world is going cloud, is going to continue to go cloud. Software providers like me are going to be all building in the cloud from day one. No one builds legacy technology anymore. So the only reason why that legacy technology is around is because it's got deep functionality, it's got deep business logic, people are familiar with it, but it will eventually change and there there will be a day where that will change. So my my point though at the end of this is we have to be thoughtful about business analyst work because that is the future. Future is more business analyst work, less IT plumbing work. Will there be a need for that? Absolutely. Like you're always going to have to service, I think a full spectrum of support. But to your point with the migration to Microsoft 365, the localized work of rolling a truck to install an exchange server, the localized work of of going out and um, you know, having to to help someone with that server in any form or fashion has gone away. And also the backing up and the support of that. Now, you may want to have offsite backups of your cloud instance. I I can appreciate that, but the the degree of work that we have to do in that environment is significantly reduced. Yeah, yeah. Awesome. Well, it's a it's a bright future. We got all sorts of fun stuff to keep pace with and watch as it evolves and changes. So, I'm sure you're going to be around for all of it, Gerway and checking it all out, leading a lot of the crowd in in some of these technologies and appreciate your work. Yeah, I appreciate it, Todd. It's been great chatting with you. Take care. All right. Part of the MSP Radio Network.