Automate To Elevate Your MSP

Thank you for joining us today for our first MSPs in Conversation of the year. Today our topic is "Automate to Elevate Your MSP," so we'll be covering the topic of automation — you know, what it is, the mindset behind it, what you can automate. Feel free to drop questions into the chat as always, and I'll introduce our panelists in a second. But if you haven't already received your Uber Eats voucher, our team is standing by. So if you're an Australian MSP, whether you're a Hosted Network partner or not, you are eligible. Just drop that in the chat if you haven't received it and one of our team will organize that for you. So hopefully you enjoy your lunch while you listen to us carry on.

A little bit about Hosted Network, if you don't know about us or what we do. Well, we're clearly not doing our job properly, but we are a wholesale cloud intelligence provider for MSPs. We only deal with Aussie MSPs. We were an MSP ourselves, and our goal in life is to solve your problems through cloud and telco solutions. But enough about us — let's talk about our panelists.

Today we are joined by James Davis, the Managing Director for APAC for Sea-Level Operations. Some of you may have seen in the press that we have partnered with Sea-Level. James, would you mind giving us a brief introduction to yourself and Sea-Level?

Yeah, sure. So I have a background working in the MSP industry for about 10 years. I come from a sales background, so I'm a bit different to the typical technical owner. I managed an MSP down in Canberra. I've owned and operated businesses outside of the MSP space as well. For the past four years I've been coaching MSPs and their leaders, and joined up with Sea-Level to bring down their operational program July 2020 and start to help a lot more MSPs improve their operational maturity, and more importantly develop the next-level leaders inside the business so we can grow and get unstuck and go on our different journeys. So I've been fortunate to see many, many different MSPs of different shapes and sizes. I'm here to share my wisdom.

Cool. Well, operational maturity is a word that I absolutely love. I think we've previously done a topic on it, in fact. So everything that we're talking about today is about driving and increasing that operational maturity within your businesses.

Aaron Jacobs, you've joined us for a few before, so you've probably got a good spiel already. Aaron is from Rodin. Give us your spiel.

I'd have a spiel? Put me on the spot. No, I'm from Rodin, GM. We're an Australian-based MSP based out of Wollongong. Finally back in the office, which is nice. We are about 25 to 27 staff depending on what day it is, and we manage about four thousand endpoints across Australia. So that's my pitch, that's my spiel.

Cool, awesome. And myself, I am the CEO of Hosted Network. Like I mentioned before, we started as a managed service provider ourselves, and basically the short of it is every second person that was coming to us was an MSP asking for the solutions that we were offering, and we eventually went 100% channel. That's all we do — work with MSPs across Australia. So I love the topic of automation. It is my absolute baby. In fact, my DevOps team often joke about getting t-shirts that their job is automating Ben's world. But we're going to be covering a little bit more than just technical automation today, and with that I will stop sharing so that everyone can see our beautiful faces a little bit bigger.

What automation really means for an MSP

So automation is more than just how to automate a process of something technical, whether it be RMM or something like that. It can really relate to all areas of your business. As an example, it could be HR, you know, leave management. It could be something to do with payroll. It could even be improving and automating the process, or parts of the process, that your customers submit tickets through, to reduce the overhead of staff working on the phones and things like that. Whatever it is, it is always about streamlining your business — improving that scalability, taking the human error out of it, decreasing the risk.

But when I think, for our business, of how we started our automation journey, it really did come with a mindset shift for me as the business owner way back when. It started with trust — actually letting other people take on things that we could then start building out processes for. So I'm going to start there, way back at the beginning of how we all started our automation journeys.

So James, it's a mindset change, right? You and I talk about mindset a fair bit. What is the right mindset that an MSP needs to be in to start their automation journey?

I think more than any of it, it comes down to being able to think ahead, even if it's thinking to tomorrow rather than looking at what I've got to do today, or more importantly what's all the stuff that I've got to clean up from yesterday. But that's where we start, right? We're always cleaning up behind ourselves, not being able to look forward. So being able to take a breath and actually step back and go, "Well, what am I doing right now, is it even the right things?" and then starting to look and break that down. For a lot of people initially that's super daunting, because we're super busy, we're all busy now in our day-to-day roles. And until we change our mindset and start to prioritize different things and start to say what we're doing now isn't necessarily the best and right way, and prioritize time to actually sit down and think about it and basically nut it out — irrelevant of high-level strategy or how low tactically it really is — we need to take time to actually work on the business, not in the business. That's a throwaway term we all use, but what does it actually mean? It actually just means setting aside some time to work on this stuff. And until we actually just make it a priority and say yes to this and no to other things, it just won't change.

Sometimes you need to let something burn, right? There's always a fire, something's going to have to burn. And there's so much power in no. Whatever we're doing, there's always a parent saying no, saying no to the clients that's not as important, saying no to our internal staff to say, "No, that's actually not that important right now to do." We need to start with no and build it back up, because we're so used to working day to day flat out — we're just doing what we've always done and not questioning it. And the longer that we do that, the harder that we work at doing that, that behavioral trait just keeps getting reinforced over and over again. You get to that point where it's like, "If I have to do everything, or it's going to fall apart," because you don't actually know all the components that are driving your role or driving your business or driving client success. You've got no concept of it because it's all just intertwined, and we can't articulate what we do either. And that's usually the hardest part for people when they have that awareness of things that need to change — they don't actually know what needs to change, because they don't have the ability to articulate what they do. I've been there myself. I've been a small business owner, sole trader. You just get super busy just doing it, the same thing over and over, until I took that time, whether it was time in the car to think about it.

Time in the shower.

Yeah, it could be anything, definitely. It's very much just taking time to actually think about it. That is the first step to moving forward and changing that mindset, I think, more than anything.

Yeah, it's a shift. I actually remember distinctly when my mindset changed, because I used to hold on to a lot of things. And this was — we still had 15, 20 staff at the time, but I was still holding on to a lot of things. And I actually got a phone call from Luke and Dylan, our infrastructure manager, and they actually said thank you to me. And I was like, "What do you guys mean?" They're like, "Thank you for giving us permission to go and do, you know, for trusting us." And I was like, "What do you mean? You've always had that." But I hadn't — I hadn't had that mindset change of just letting go. And so I still remember that to this day, of going, "Hey, if I've got a team, trusting them to let them do those bits and pieces."

Turning automation into a dedicated role

Okay, so Aaron, I asked you to be on today's panel because you guys are unique in the sense that not a lot of our MSPs have dedicated automation staff. You made it a role. What was that mindset piece of it for you that kind of went, "All right, enough's enough, we're going to really commit to this"?

Yeah, so look, it was part of what you were just talking about there. When realizing it — and I reckon a lot of people on the phone, you guys would be juggling automation. And for me at the start, like I'm sure a lot of you, it was all very technical focused. How can we automatically detect things are wrong on customers' machines and then ultimately fix them, right? And for me, that big part — that's where my journey's always been, with the technical background — was trying to minimize help desk requests. And that's the obvious one in MSPs. So I juggled that, but I could imagine many people would have different people trying to juggle that and also trying to do support at the same time. So you know, trying to manage the RMM is probably the right thing I'm trying to say there.

But it got to a point — and I guess this is part of my mantra always, in my role as a leadership and running the business — I'm always trying to do myself out of a job. Now that sounds like a funny thing to say, but I think it's the best approach, and I coach it to my managers and everyone around me. I'm like, "You've got to make this so automated, or if not automated, a process, that you can hand it off to someone" — like what you guys were just talking about, letting go. You've got to be able to get rid of it. And then people often say, "Well then, what am I going to do? I'm not going to have anything to do." And I go, "Great, we'll find you something else to do. You're not going to not have a job."

So there's a fear element to it. A hundred percent there's a fear element. They think they won't have a job if they're going to hand this off to someone or automate it. And even some of my techs make jokes when we do another great automation, and they'll just like, "Oh, there goes our job." But I'm like, no, not at all. And it's always a continual improvement process — it's never done.

Absolutely. The robots aren't going to take over.

They're not going to take over, they're absolutely not going to take over. I wish they would, but they're not.

But yeah, look, for me, turning it into a role really was just getting that extra buy-in and wanting to do more. So taking it from technical — which, I mean, we do a huge amount of technical automation, and that's allowed us to grow our client base and manage machines without putting on additional headcount. And I track those numbers about how many machines-to-tech ratios and things like that. And I have a target that to this day I still haven't reached — that's probably going on five, six years, but we're always edging closer to it. So taking that next step was really pushing automation across the business in all avenues, and then really wanting to do more and more and more.

And I guess the good thing about MSPs nowadays is there's a lot of new platforms out there to do automation, especially in the last few years.

Definitely, yeah.

I've got a couple of names that I'll drop later, but they're really good. The problem is they still need time. So depending on where you get, you're either trying to juggle automation, which is second-hand to your primary role, or you really just can't commit to the time. And the good thing about automation is, I feel that you need to have a bit of freedom to think. Some of you guys were talking earlier, and what I was thinking about was a couple of things that just recently have happened in my sales and admin departments. We didn't realize, because you leave these departments to go on and do their own thing, and it was only when we sat down and reviewed their processes and were like, "Wait, hey, what are you doing here?" And it's like, "I do this, this and this." "How long does that take your day?" "Oh, about an hour." And I'm just looking at going, "That could be done in 35 seconds with automation. This is ridiculous."

So it's amazing. You need the time, going back to what you said James, to work on the business, to really just sit and watch, take notes and go, "Okay, we're going to fix that now," and then turn to automation. So that's what led me to hiring someone. And it's even gone past that now. My full-time automation engineer is now subcontracting to other people because of the amount of stuff we're doing, both for clients and internally. So he's now, I guess, managing even more automation, if that makes sense.

Starting with the low-hanging fruit: internal processes

Right, okay. So you started with technical automation, and let's call that the low-hanging fruit — that was the easiest apple to pick from the tree. What was sort of next in line for you guys?

So next in line, I would probably start to say internal processes is where I went to next. What I mean by that is repeatable things that happen inside your business. Now, there's a lot of different ways to automate these things, there's plenty of platforms out there. If we take something like license ordering through Office 365, there's lots of ways to automate that process — so you buy it, the license appears, and the billing side of that happens. But even more things: you all have things inside your business where you have to ask someone to do something, and often it's admin. Admin swivel chair is what we call it.

Swivel chair, yeah.

Yeah, so like, there's things like shipping requests — you've got to ship something to a client or to a vendor or whatever. Change management is a big one, as in your techs need to change something in your customers' environment. Now if you're a smaller MSP, you're probably just YOLO-ing it and just doing it — we shouldn't say that, but you probably are — you know, test and production and all those kind of fun things. Everyone's got a test environment. But the reality is you shouldn't be doing that. So change management is important.

So I'm really big on forms and using — you know, that could be Microsoft Forms, you all have access to that — and something like Power Automate, just to simply prompt the tech or whoever this is for the right information. Because if you've got tickets going forward and back, or emailing someone, everyone's going to ask for it slightly different, even if you write a process or a procedure.

Standardization.

So to be honest, half the time if you put a form in front of people and say, "You have to fill this form out," if you ask the questions the right way, that just triggers them — they go, "Oh, I haven't done that yet," then go and fix it. And you never know, they might not even need to do what they're doing. So standardization. But then taking all that information and then just automating the next steps, even if that is just creating a ticket and handing it off to someone, or maybe it's passing to someone for approval for a yes/no, that can then go on to the next step. That's where I went next, into internal processes. And again, that's an ongoing thing, but that's where we follow the bouncing ball — where's the next bottleneck, where's the next.

Definitely, yeah. We've just got to start the journey.

Yeah, and once you get over those first couple, then it just opens up your eyes to a whole bunch more. And simple little things that we've just been able to make standard, like, "Ask admin to do something, fill out the form, that makes a ticket for admin, admin do it, I click a button that then notifies the person who made the request that it's done and gives them all the reference numbers and things like that." Just small stuff. So yeah, internal process I would say would be next. And then, I mean, you can take it from there — there's lots of different avenues to go into, sales and marketing and all those other areas as well.

So I think that's an interesting comment, in the sense that automation doesn't necessarily need to be a process end to end. It can be a part of a process, right? It could be the first step of that, like just a form. Having a form is a very good example of a simple automation.

Where most MSPs should start: payments and social problems

Okay, so James, you obviously work with a bunch of MSPs, and you say, like us, that working with multiple MSPs you sort of see different things — the good, the bad, the ugly. Where do you see that most MSPs — you're very operationally driven with what you do with Sea-Level, it's in the name in fact — where do you find is the low-hanging fruit?

Yeah, I'd say what Aaron said just before around the automation and the types of automation that you can do was a really good insight. Because I think we've been sold the dream from like, I don't know, 12, 13, 14 years ago now, of "you could just automate your whole service delivery through a platform." Well, ConnectWise call their product that, right?

So exactly, isn't that ironic.

Now get me started. You mentioned the C word. So we think of automation in the wrong way, if it's like taking a whole process and the machines and robots doing 100% of it the whole way through. And what Aaron just said there is like, there's different components that we can use our systems better for that make a whole lot of difference. Forms, fantastic way of making it repeatable, and they can go across all your areas of the business. Just by creating a standardized way of dealing with something, you've already automated most of your problems away with communication — with the amount of effort going backwards and forwards, people not remembering everything. Even something as simple as that is a really good perspective. And I think starting from there is really important, like where I started our conversation from. You have to step back and have a think.

Because where we typically start with automation is always — it's not even technical, honestly. Most people that start with automation, it's actually inside the PSA and ticket handling. So the most common one that I see over and over again is automation of ticket closure. User status, let the tech select the status, and then the system will email the clients. My perspective of that is actually that's a really bad way of automating. We're trying to solve social problems with technology. It's what we all default to, the majority of MSP owners — fantastic techs, built the business back on the back of that expertise, so we focus on things that we can solve symptoms of. So that ticket closure process is a symptom of a wider issue, which is actually our communication with our clients. We don't close it because there's no closure process, there's no communication standards with clients, et cetera. So we dive straight into automation because it's easier to solve.

So I like to say, don't solve your social problems with technology first. Take a step back. And where I would normally start with an MSP to start with any type of automation is actually taking payments from clients. It's the most neglected part of all MSPs. Just think about all the time and effort it takes for you to chase up cash from clients, managing cash flow, et cetera. If you've got all your clients — I'll say the utopian dream of Kaseya automating all your problems away — if you just flipped it on its head and you're taking all your payments up front and automatically every month, how much of a burden would that release on you? Not just admin-wise, but also stress, the emotional side, and having to have awkward conversations with your client. Just the energy of talking to the client on that, rather than talking about proactive stuff like, "What are we doing with you, where you're heading." It flips the conversation around. So I usually challenge people with that one, and it's usually the one that most MSPs avoid and don't want to do anything about.

It's interesting, in the sense that, I mean, let's be blunt, business is about making money, right? You've got to pay bills and all of that. But having that conversation is always hard. And like Aaron, I started off as a tech in that sense, and I jumped straight to the technical bits and pieces when we started our automation journey — ticket automation, those sort of things. But I definitely, we did get there, and you're right, you're 100% right, that it made a huge difference in the sense of, okay, standardizing the way we accept payments. And sometimes it's like, I know a few MSPs, well quite a few, that only have a direct debit arrangement, right? So there's no chasing. It's like, "Okay, cool, you sign up with us," so that way there's no need. Or, "We need a credit card on file," simply. Versus, "Oh yeah, you can pay us when you want, send us a cheque," god forbid. But yeah, interesting.

Okay, we've got an example in the chat that Daniel Burroughs put in there, and I kind of like this as well. You know, finding the things that you hate doing, which is always a good — you know, not always the perfect way, but if you're a one-man band and whatnot, and you're more of a lifestyle business. You know, you may not be a one-man band, you might be a bit bigger. And looking at those areas of your business that you kind of don't want to get out of bed for, starting to make a list of those, prioritizing them within your business and whatnot as well.

Yeah, cool. Okay, so moving on a little bit about how we automate, and then we might kind of jump into the "what" a little bit. Aaron, you mentioned you've got some tools — you know, Power BI, etc. — within your business. Where do you, how do you automate? And let's talk outside of your RMM and your PC pieces, the true business pieces of it, not the things that certain vendors are chopping down our throats.

Yeah, of course. Well look, I think what Daniel put in the chat is important, and I was just going to quickly touch there and say there's an exercise that comes out of EOS, and it's about four quadrants. It's about what you love doing and you're good at it, what you love doing and you're not so good at it, what you don't like doing but you're good at it, and what you don't like doing and you're not very good at it. And the whole idea is, when you break up everything you do in your day into those four quadrants, the bottom ones you either automate them or you get rid of them to someone else. And that's kind of what you said there, Daniel. So I just wanted to touch on that — it's really good to do that exercise and sit down and break it apart, because it at least gives you a target list of what to do.

The second thing I'll say there, Ben, is we always work on the 80/20 rule. There's just so many ways where you can fall into it and go, "I want to automate that, but what about when blah blah happens, and this happens, and Bob, that pain in the ass customer, does this, that won't work." Don't think about the outskirts. Don't always think about the what-ifs. Don't let your entire automation break down for an edge case. Always try and think, if you can at least automate 80% of it, and then or delegate 80% of it. And then yeah, the other 20%, those edge cases, that's fine, just make sure there's an escalation process or something in there to hand off and address those edge cases. Because automation can also mean outsourcing it. It's not always thought like that, but if you can outsource it to someone to make that problem go away, because you can't actually automate it, it's still off your plate. And in my case, you still got rid of it and dealt with it.

And just expanding on that, you mentioned make sure there's a path for escalation. One of the other things we've seen work really well is also making a secondary process or automation to then go back and check. So something that's going to run continuously, or run kind of with you blind, going back and being able to check that on a regular basis to make sure that it's not just kind of falling by the wayside.

Yeah, I've got quite a few automations written into my RMM — I'm not going to name drop — but I've got quite a few where I actually can't automate something because of reasons. So exactly what you said, Luke, I've actually written a check or a report to catch the edge cases and then just deliver it to me monthly. And that way, off my phone, I look, I do, and then I just pass on. So it's taken what could be quite a problem if it dragged on for months — then I just get it once a month, I quickly look at it, "Oh yeah, that's a two-second click of a mouse button that can't be automated because it's so stupid," or I just forward it on to someone to deal with it. So, good things like that as well.

Sometimes there are customers that you can't automate, right? You mentioned they won't follow a process. I don't know, maybe they're a legacy customer, and touching on what James mentioned, the social issues of having to retrain them. You know, starting with that 80/20 rule as well. And I think, like, the topic of this is starting on your automation journey, right? So the sooner you start, any new clients that understand those processes and all those automations, they're trained from the word go.

Yeah, definitely. But also, that's a social thing which James touched on earlier. We've had a good two or three attempts at trying to make a beautiful portal for clients to log tickets in and actually automate based on their answers and do stuff, and then no one ever uses it. Despite us running surveys that people say they'll use it, they never use it. Now whether that's our problem of delivering it properly, possibly, but we just find everyone just seems to default back to shooting an email off to log a ticket. So again, you just deal with things like that. And phone — we still have, I think it's 40-something percent of our tickets still coming through phone, which I think is crazy, but people seem to love it no matter how much we try and change their minds. So we're just going to deal with that and carry it, because I'm sick of trying to force it down their throat and make a social problem.

I think a good point, Aaron. I'd go back to a lot of this is taking a step back and understanding the purpose. The portal is a really good example of people trying to do automation in MSP to not only reduce the cost of delivering service, but also to provide a better client experience through transparency. There's a lot of benefits there. Often we don't think through the strategy and what we're trying to achieve from it enough to make it, like, fully back it. So when I hear people, like exactly what you just said, like people still default to email, my first reply to that is often, "Well, did we turn the email off?" They've still got a choice, like, they're going to default to old behavior, aren't they?

That's right, what they know best.

Yeah. So in this process of automation — I think this is where most people get confused when we talk about automation. It's a component of delegating away processes and tasks, and automation is delegating to a system and technology to do it for us. But like you said, outsourcing is a form of this automation and delegation. And I think what we need to do is step back. So this example, the cloud portal — why are we doing it? What do our clients like? What do we need to actually stop them using their old methods? Everyone, I always say, "We need to get rid of phone calls," and my first question is always, "What clients do you look after? What verticals are you working with?" There's plenty of verticals that don't sit in front of a computer but have technology problems that they might be out on the floor with clients. Like, I used to work with hospitality — you couldn't expect them to email in, they needed to be able to do it from their phones. But it's how we handle it from there. Most of the problems with answering the phones, as an example, of automating a process — it's because it's an issue, because we spend so much resource on actually trying to resolve this issue on the phone, rather than having a clear triage process that sets expectations, lets it go into the system. So we end up having to throw a lot more resources at the phones than what we would have if we looked at what are our processes and how do we automate some of that, using our systems to reduce that, so it's a quicker phone call.

It's a log-and-flog type thing.

That's right, yeah. Often just on the back of what you said there is just saying, "Why?" Someone says to you, "We've got to get rid of phones." Why? If customers like it, challenge it, right?

Content challenges, yeah, absolutely.

The correct return on the other side. Because if the return is, "Oh great, I don't need to have people answering phones, but I've just pissed off 750 of my clients," then it's not a good automation. It might look good on paper — "Oh, we'd reduce phone calls by so many percent, great" — but you'll slowly burn off those clients. It might take a year and then they don't like you anymore. So I would never get rid of phones like that.

Well, I think that you mentioned 40% of your tickets coming by phone. Your goal is — and that's the thing you need to think about — what's the actual outcome, the goal that you're trying to achieve with that? Because it's not to reduce it to zero.

No, it's potentially — so, you know, if you could reduce that by 10% as an example, what would that have within your business? And you might identify certain clients that, like James said, that don't have that criteria, that you could potentially go, "All right, well let's encourage these guys," let's group them and sort of say, "Okay, let's see if we can get these guys to retrain." But it might also just be a retraining thing, not how they're submitting their tickets.

Correct. But it's also what phone calls are coming in. Most people's phone calls are coming, "I've lost my password," or "Holy, everything's on fire." And so you don't want those — those ones kind of need to come in that way. I mean, there's the password one, there's other options, but there's reasons as well. So yeah, it's definitely more than just — I guess the big thing we're trying to say is make sure you measure it accurately and you do the automation for the right reasons. And internal business processes are a really good one, because they're actually not necessarily trying to change a social aspect for clients or anything like that. You're really just trying to — for me it's actually consistency, it's trying to make it consistent, and then you speed up things as well. So, you know, human error, it's always going to be around.

Yeah, and you've got to be able to account for that, like you mentioned earlier. Someone is always going to hit the wrong button, they're going to, you know, whatever the case. So there's a reason we have backups and things, right? Because people accidentally delete an entire folder, and well, what are the cases.

RMM, patching, and software deployment tools

Okay, so let's talk a little bit about systems. We talked about — again, I'm going to use this sort of phrase, low-hanging fruit — because how do we help people that are on the call get started? We've talked about a few different things that we can automate — we talked about tickets, we've talked about payments, etc. But what are the tools available as part of that journey, rather than actually, I don't know, learning PHP or Python and becoming a full-blown coder? What are the tools out there that can actually help you on that journey that aren't going to cost an absolute bomb, ideally?

Yeah, of course. I mean, it depends on your goal and your issue, right? So if you're trying to reduce the amount of tickets, or if you're like something stupid like Windows patching. I've been dealing with Microsoft patching for 15 years, it seems to be my baby, and whatever, I still seem to be responsible for it.

I know, right.

And you've got different tools. Just look at what Daniel Burroughs put in the chat a few minutes ago about delegating the processes that you hate. Well, ironically, I've spent so long getting it done well that I feel like I'm a bloody industry expert on the matter. Because every RMM you have, or patching tool, does it — everything does patching. But the Microsoft patching can break down in so many different ways, and the RMM tools don't factor that in. So again, you need to then look at the reasons for it. I'm not going to sit here and pretend like I've seen every patching issue ever, but I've seen lots of them, and I've then automated the fixes to those issues. So everyone patches, but it's about detecting that it's broken, detecting why it's broken, and seeing if you could script or do whatever to avoid it from happening again, and then ultimately if you can't, automatically dropping a ticket to the right person to actually do the manual work. And so now I just can sit back, I don't actually have to handle patching at all. I've got a very simple report that tells me where things are at with numbers, and I just look at it once a month and go, "It's good, it's good, it's good." I get the occasional outlier, and maybe something's broken down in the automation, but it's very rare.

But in terms of what you can automate, or how, or the tools — again, it depends on what you're tackling. Software deployment has been something we've been on a journey for a good 12 months now, about really improving our software deployment, about the methods our technical people deploy software, whether that's ad hoc random ones, or in a scenario where you've got to deploy something to an entire client. There's lots of different ways to tackle this problem. Even Intune and things like that have options now for you, but again, I always come at this from a cross-tenant MSP vision, not where Intune is very much one sort of environment. But if you look at things like — there's a software out there called Immy, which is relatively new, they've been around for a few years, but it's really, really good when it comes to the software deployment side of things.

One that people should look into, which is brand new — I don't even actually think technically it's released yet — is Rewst, R-E-W-S-T. It's new and it's targeted at MSPs, and if you have a look at that and what they're doing, it's going to be pretty game-changing once they — I think it's a waitlist scenario at the moment. You can get a demo if you just fill out their forms and stuff, you can see what they're doing, and it's pretty awesome, and the integrations they're doing. I would encourage every MSP to have a look at that one, because that's very exciting.

But that's all very much technical focused as well. You've got your RMMs, of course, you've got your various platforms, there's a million other things out there, and it depends what issue you're tackling. But I guess on the sales side of things as well, everyone should — you know, everyone's got sales, that's the reason we're here, and it's all a part of it. But looking at quote creation and proposals and things like that, that's something that can be the sales automation, just creating quotes.

It's an interesting one, because I would say we've done it pretty manually for many, many years, using Excel spreadsheets and Word documents, etc.

Yeah, just Word templates has been a big thing at Rodin for a lot of years and years, for proposals and quotes and whatever. And sure, they've made it really fast with lots of Word templates, but it's still — and that's something I'm changing at the moment. But there's plenty of tools out there on the sales front that you can look at. I mean, if you're in the ConnectWise ecosystem, ConnectWise Sell, but you know, it's ConnectWise products, so don't say Aaron told you to use that product. But there's different platforms out there, there's lots of them. There's Quoter, there's Zomentum, which is like tomatoes, momentum, I always get the wrong one.

Yeah, the IT Quoter. There's quite a lot of them.

You've got, previously, IT Glue, who was an Australian company that Datto bought. That's now IT Glue, so I think it's just going through its rebrand at the moment. And they all do slightly different things.

Liongard — I just saw someone put into the thing, that's around documentation automation, which is a really good one as well, that's often missed. Liongard does that component where it goes and talks to all the environment and automatically feeds that documentation into Liongard, or things like IT Glue, and all those platforms. So there's lots of different technical tools out there. You could go on forever, probably, on the various platforms that are available.

So maybe I'll throw it back to James then. So, non-technical, in the sense of, what do you see out in the wild that MSPs use just to start their automation?

So I'll say what people are doing wrong, and Aaron sort of touched on it. The problem is, these days there's too many options. Pretty much in all the operational facets of our business, there's tools and platforms that we can automate, present things better to our clients. The list goes on. There's a lot of benefits, there's a lot of great tools, a lot of great things out in the ecosystem these days. We're too quick to just go and buy a tool to solve our problems. And the reason why I bring that up again is we often half-implement these things, so we don't actually get the benefits of what we're doing, and we don't take the time to review our systems because we do it in a rushed manner. It's like, we've got an issue with, let's just say dispatching as an example. We're using ConnectWise, we've got some issues, we rush out, get one of the tools like Nelly or Thread to solve our problems or magically make it all disappear, but we're not making the time to actually sit down and make sure our processes are mapped out first, and that we actually understand what we're doing, so that then we can reshape and cut out stuff that we don't need, streamline it. Maybe we don't even need a tool at that point of doing that — maybe we do, but then we know what we're going in for, and we know what the features that we need and why we're doing it and the purpose, and ideally have an owner to actually implement it. Because half the time it's an owner saying, "I've got a problem, I keep getting sucked into this, I'll just buy this tool, that'll make it go away." It doesn't, but we get dragged into the next bushfire that we have to deal with, and all we're doing is adding cost and cost and cost.

Yeah, cost of subscriptions can blow out so quickly with these things.

Oh, 100%. For your average, let's say, one-to-three-million-dollar revenue MSP, every time I go and look at a prospect or a client or help somebody, there's at least four grand on average that I could rip out in savings of all the stuff that they're not using, haven't implemented, don't use the features, and can reduce their subscription costs. The biggest one I've done so far, it was like a five-million MSP, we saved about 25 grand a month in subscription costs for all the stuff they weren't using. So it's a real problem, and it goes back to not understanding our figures and what are we measuring.

I'll use the ticket example of the phones. As we were talking through, what was going through my head is, when you said, Ben, "We want to reduce our ticket count by 10% that's coming in from the phones," is that actually the right metric that we would look at? I would say no. What's more important is reducing the time on the phones. It doesn't matter how many are coming in, it's how we're handling it, how much time are we spending on the phones. A ticket coming in that takes three minutes to deal with, compared to a ticket coming in that takes 30 minutes, is a big difference. And that goes to everything that we do.

And I know I'm making this whole automation and delegation sound like even more complex, "Why would I even bother?" It's actually worthwhile. And what's important is just, like, picking one thing off at a time. Like what Aaron was saying, it's continual improvement. You can do this across your whole business, but we just do it one step at a time. What's our big burning issue that's affecting our profitability is where I'd always start, because there's an actual easy way to measure that — you're going to increase profit or you're not. Whereas a lot of the other ones, if we don't have our system set up for any type of measurement, it's all just gut feeling, and you can do some changes and it feels good, but it doesn't mean it improves your bottom line or actually changes any of the hard metrics. You just don't know.

Automating triage: process first, then platforms

Okay, so we've got a question here from Don, which, James, maybe for you or Aaron: any ideas on automating triage?

I've seen a few. So firstly, we need to know what we're doing. Everyone's going to get sick of me hammering back on this — purpose and why, and what are we trying to achieve?

You're right, root cause and return on investment is very, very important. But it's also very easy to forget. It is, as someone has mentioned in the chat — Daniel, you know, shiny object syndrome. And I know, I've done it many, many times, it's very easy to get distracted by something.

So all right, let's assume we know what we're doing, we've got a good purpose to it. First place is creating a process, like, what are we actually doing and achieving through triage, and what are the steps that need to be ticked off? Then we know we can work from there. The first problem is most of us don't know what's involved in that.

You've also got a fallback process if it doesn't.

Yeah, correct. And again, like I said before, maybe that's enough in the first place. Especially if you're a smaller MSP, having a simple process that can set out expectations, and we get some data inputted, give a good client experience — we're already going to be better than what we were before. Operational maturity, you don't have to be a 10 out of 10. Going from a one to a two is enough.

Yeah, exactly, baby steps. It's a journey, you can't skip levels.

It's a journey, it's a process to go through. Once you've got that, then it's using — you know, making sure the PSA's set up to make it easier, so we can go through it faster. Then there's, like, what we touched on next, like Aaron mentioned, the cloud, having a portal like CloudRadial, getting clients to self-lodge their things. It can also be using one of the ones I see most often, like alerts being generated, and we're not using the email parsing rules inside ConnectWise. The amount of people I come across that don't know that exists, that can reduce a whole lot of labor burden without adding any cost or any extra work, that's quite simple. And then you can take it to the level of, like, Thread, starting to try and build out automation through machine learning that's going to get the sentiment out, and get the wording, and what's inside the body of the email or the portal, so it can set priority and settle the categorization of the tickets.

So you can see how there's a journey there. If you jump straight to the end game of just getting a system to try and fully automate it, you don't know what tickets you're dealing with, you don't know what sort of expectations you're trying to set with the clients, you don't know what the data is that you're trying to gather so you can make other data-driven decisions. And all you're doing is speeding up something that you don't truly understand. So you will reduce some labor, but what benefits are you getting out of it? You don't actually gain any other insights at that point, because you haven't learned the process and you've just shoved it in the back corner using a system to do it. So again, I just challenge, like, there's a process of doing this right, and Aaron's touched on it quite a lot as well with how he's gone about it.

I think unfortunately a lot of us YOLO things in these situations where, you know, we've got a fire and we try and put it out. But you're 100% right. And I think if I look back at where we've come, we've YOLO'd it so many times, so many times. And it wasn't until we actually turned around and we actually periodically review these things now throughout the year. Luke and I call them operational maturity days, and we try and go through that, and that's for a number of things. It's to avoid sprawl of subscriptions because people have just signed up for things and they've forgotten about it. And there's a lot of cases that existing tools can do the same thing, but also making sure that the conclusion that we originally came to is still valid. Which, in a lot of cases, we make a decision based on something and then down the line the requirements actually change, but we don't go back and look at it.

To quote what Daniel was adding — lots of good tidbits in today, Daniel, I'm going to pull you into one of these.

Can I just take Don's question for a sec, man?

Yeah, yeah.

I mean, Don just said, "Any ideas for automating triage," and I said, "Do you have triage now, or techs triaging?" And Don, you said, "I'm triaging." So I don't know your position, where you are. I don't know, Ben, if you know Don and know what he's at. But look, I'll tell you how we've done it, and a little bit of what James just said. Process is a big one. I don't know your structure, how your teams are laid out, but let's assume that you have tickets coming in and you need to throw them at certain people or teams. We don't run in a model where every ticket gets allocated to a tech and then stuck with that tech, we do things a little bit different. But yeah, let's just assume.

There's only me.

Okay, so it's only you, so you're triaging and teching, which comes back to my question, are techs triaging, and that means it's yes, yeah, okay, cool. All right, so auto-triage like that, all right, that's a little bit harder. But I'll tell you — I mean, we've got obviously a larger team — we've gone down the process route. We've measured all the types of tickets coming in, various SLAs and response times. Where I've landed at the moment, and maybe this will help you, is I've outsourced that to Manila. So phone calls and emails go to the same spot, we have a person that answers those calls and they triage. So they pass them to — we use boards in ConnectWise Manage, I said it, ConnectWise. But we use boards and obviously all the types and things like that, priorities and stuff like that. So she's taking about 150 phone calls a week, and all the tickets start there and triage out. We're about to expand that process shortly with something else as well. But that's been working for us, and that gets my techs off the phones and off the triaging, and that measurement has been based on time.

A lot of people would say, "Do you get complaints about someone from Manila answering the phone and things like that?" We've only ever had it twice, and they were racists, so I don't care. That's how I answered that question — I don't tell you to take their feedback. Because they're awesome, they've actually been really, really good at it. They take great phone calls, they triage things, Teams channels. I know it's only you, but they're able to sort of alert the whole team immediately if there is something urgent. Even though all the statuses are there in ConnectWise, we have TVs dinging, we have an automation where we're sucking into the API of ConnectWise whenever there's a high-priority ticket or an SLA about to breach, it starts yelling at everyone in Teams, things like that. We've done a lot around that to get that SLA and triage stuff down. But did I employ direct? No, I didn't go direct, I use an outsourcing company for that. But yeah, it's been very successful in that regard. And you know, that might cost me 30-something grand a year, or whatever the number is, but that gets my techs off the phone and it frees up their time, and they're the more expensive part of that equation. So that works for us, and we measure it, and yeah, it works really, really well.

You could also look at — I mean, this is less than ideal, but at a lower price point if it's just you, Don — using a messaging service or a virtual assistant, those sort of things. And sometimes, if you're working on something, letting it go to a messaging service, so at least someone is still answering it, could be a step in the right direction. And if they then fill out a form — you know, Don, if your messaging service were able to fill out a form, you could have the categories in there, and that could potentially then feed into — I don't know if you're using a ticket system or not, but if it's coming to you, then that could at least higher-priority things for you.

So lots of different ways to tackle that problem. There's two ways to approach it with labor, like what you said. We've put someone offshored over to the Philippines, cost-effective resources, there's a return on investment there. As soon as you elevate techs — even if you're a one-man band, if you have someone taking on those calls — even if you go to just spending more time billable, you're going to generate that money back pretty quick each month if you've got the right hourly rates. But also there's other ways to look at that labor effort down here as well. It's a perfect opportunity for people to bring trainees on. Put them in that position and start to learn them and teach them and mould them. They're useful, they're getting used to the clients, they're getting used to what tickets are coming in, and you start to transition them into doing some quick-fix work — again, taking more work off the more experienced techs to focus on the more experienced work. It's sort of a self-fulfilling prophecy, but it all starts with having a process written out correctly. Always the process, and make sure you're measuring it as well. It's not just hiring them and getting them answering the phones is not the end of that equation.

But whether it's a junior or outsourced — yeah, we took that avenue for many, many years of hiring, I guess to call them level-one techs, and they were the ones that answered the phones, and the others were further up the chain, so to speak. But then it got to a point where we moved into that model, and it's been very successful for us. But yeah, I wouldn't necessarily dive into that straight away. But at least there's some ideas for you there, Don.

Awesome, thanks guys. We've got a five-minute warning, so time flies when you're having fun. So if there's any other questions, feel free to drop them in the chat, we're always happy to answer any of those.

We've also got another little piece from Daniel. Daniel, I'm going to drag you into the next one, mate, I'll tell you what. Lots of ideas. You can use your recording to remind people if you've got it on your IVR. I quite like that, in the sense of going, "Hey" — and I hear that with a lot of MSPs, in the sense of saying, "Hey, if it's not urgent, please submit a ticket." Those sort of things.

Just, you know, in some cases, if clients are calling your personal mobile — I know that when we were an MSP, my business partner used to get a lot of phone calls to his personal mobile, and I actually made him a challenge once. I was like, "How about we just change your mobile number?" And in the end he didn't, he actually managed to go through it. But it is hard if you're taking all the calls. If you can get them into a proper process rather than calling you directly, it will allow you to scale, so think about that as well. And it also means that — yes, you're always going to get your clients that might be your P1s that need to call you, that's one thing, but if they're telling their staff that and so on, that can really cause some issues for you personally when you're trying to, I don't know, spend time with your family.

Yeah, do your phone IVR for anything really — statuses, large outages. We have a process, we get a message on there when there's large outages, like Microsoft, AWS, whatever it is, because you're going to get an influx of calls. So if you can sort of filter them all out and get them to hang up before they waste your human time, that's great.

Adam just asked a question around scripting automation with regards to auto-creating Office 365 tenants. You triggered my memory there, Adam — there was another platform that I was going to give a shout out for. So this is CIPP, C-I-P-P. That's Kelvin — if any of you know Kelvin from CyberDrain, he's an MVP — and Gavin. They've been working on this. That platform is amazing. It's new, as in it's only a couple of months old, it's free, it's totally free. You have to put it into your own Azure environment, so it might cost you eight bucks a month.

Yep, that's the one, thanks Luke.

That is really great. So for all of you doing — you'd all be doing 365 user creation, users onboarding, offboarding, tenant administration, groups, you name it — that is CIPP, stands for the CyberDrain Improved Partner Portal, and it is awesome for all of us that are dealing with multi-tenant 365 stuff.

Coming back to your question, Adam, I think it creates Office 365 tenants, but if not, I've pretty much seen that on the roadmap, but you can absolutely go on their GitHub and request stuff. It's amazing, it's really, really good, it's really worthwhile. From a technical aspect, that has saved us so much time. We actually had a competition internally over the last couple of months of how long it takes from "we need a new user set up" — ignoring the 365 license for a second, but just the actual creation. We had a competition, and I won't say where the time started off, because that was a human problem that we got rid of, that human. But that's where that competition started, and where it ended, I think the record is two minutes or three minutes or something at the moment with this platform to be able to create a new user.

But even offboarding users — you need to get rid of them, and I'm sure a lot of you do the same kind of process we would, which is disable user, initiate sign-out, convert it to a shared mailbox, give that permission to someone else, blah blah, the list goes on. They've written a nice wizard where you literally just go click, click, click, done, and it does it all for you. So definitely look at that one. And it can also do some rules on your 365 tenants as well. So if you're interested in setting standards — they call them standards — enforcing modern authentication, disabling legacy, all those types of things, that platform will just run around and do it to all of your tenants, and every three hours keep it enforced in that way as well. So yeah, great platform.

Is this going to — add to that, Aaron, you do have to be a little bit careful in the sense of just reacting. So if your 365 tenancy creation — is your current pain point that you're dealing with now the real — basically track how many of those. So if you've got ticket metrics, look at your ticket metrics and then try and prioritize based off data versus gut feeling.

Yeah, I mean, I don't know how many 365 tenants you're creating. If it's that many, that's awesome, yeah. But I would have probably argued there's something else that would come before that one, but yeah.

Well, that's how we do it internally, is we kind of look and go, "Okay, what are we actually facing?" Whether it be service delivery, whatever the case, and we just do it a numbers game. And then we set a goal — even those goals, what we're trying to get it to, sometimes we call them stretch goals, like stretch sales targets, and it's kind of like, "This is really a bit further out, others might be nice to have." But that does help for us to make decisions.

Yeah, you've got to measure. You've got to do decisions. Once a quarter I sit with the operations manager and rip through our ticket data and figure out what types of tickets are the next thing to go to. And it's not just ticket numbers, it's hours — but both, you need to look at both, because a huge amount of tickets at one minute is still an issue. So you look at all those things. Use things like BrightGauge, which is great for ripping the numbers apart. If you're ConnectWise, Cognition360 is actually a really, really good platform from a performance and metric — well, for profitability as well. But you can do a lot there to measure and improve your profitability. But yeah, you've got to pull the numbers apart. Obviously it goes back to what we said, return on investment, and just working out where the automation is right.

And we fixed a major problem in October just by simply changing a process and creating a Teams channel called Escalations, and giving all of our techs a voice to, instead of pass the ticket up the escalation chain — which just ends up in this ticket tennis process around the company — to just simply tag everyone in the channel. And normally it's me answering them, because I'm sitting around, you know, GMs don't do anything, remember, they sit around, don't do any work. And I'm the first one and just say, "Have you tried this?" They're like, "Oh no, that was it, thanks." And I'm like, "Yep, high five, another ticket closed for Aaron." But stuff like that, it's just simple little things that you can empower your techs with to just ask questions, and they feel better about it. So it's amazing, again, all back to that measuring the data properly.

But that's a really good example of a simple automation, right? In the sense it's not even automatically, really.

Well, it isn't, but it's working towards the same goal, right? It's a process.

It's a process, yeah, that's it.

And I'd wrap up with thinking, like what you were just saying there, using the data to decide on what's next. ROI is one of the most important parts. We get sucked into — we can try and automate everything. If it's going to take us a hundred hours to automate something that we only do once every quarter, like touching on what Aaron was saying around the tenancy creation, maybe that's not our highest priority at the moment. There's a lot we get sucked into, those annoyances, "Ah, we don't really like doing it," and then we ignore the really important parts in our business, like take payments, and actual admin labor. Some of the simplest things that make changes I've ever seen, like simple PSA setup — people spending so much time on billing issues at the end of the month because they haven't got the PSA set up correctly. I've saved someone like 20 hours a month from one setting, because of one setting against one client in their PSA. Start with — they might not appear as the low-hanging fruit, but what are the ones that are going to have the biggest impact? Focus on one, make that change, learn from that process, and then keep doing that continual improvement.

Don't forget time — sales time, the time it takes you to create proposals, get pricing, admin time. It's so easy to forget, "Oh, it's just an admin process, well, let admin do it." And then suddenly you need a second admin person.

Oh, I've had that happen.

And they'll never question it too, either, will they? It's like, "I need help." Well, I've had my sales manager come to me and say, "I need a second person for this," and I go, "Cool, why?" "Just because there's so much on." And then I look and find out they're just doing this manual process. "Why do you need that person?" And just dig into it, and it turns out, once I get involved and we automate something, it turns out they have more time than they did before without the person. So yeah, it's funny. You've just got to measure it, you've got to measure everything.

And don't try to — we've been speaking a lot about today around thinking forward in the future — don't try and solve the problems if you're a one-million-dollar business. Don't try and solve the problems and assume you know what it's going to look like at a 10-million-dollar business. You don't know. Exactly what you said earlier in the piece, Aaron — it changes and evolves as you grow, and as you mature, things are different. So you need a review, and that's okay. It's not only okay, it's actually the best way to do it. It doesn't have to be a 10 out of 10. Just get from one to two.

Leveling up operational maturity across the business

Yeah, I often look at — we talk about operational maturity, and we're a little bit over, so we will wrap up, guys — but I always look at this as operational maturity in the sense of, look at every single department, at a very, very basic level, and just give it a score out of 10. If you've got multiple, it's a bit harder as a one-man band. But if you've got those different departments, or you've got different functions, give it a score out of 10, try and back that up with data. And then, rather than make one area a 10 out of 10, try and just do that across the business. Level it up, but consistently. Get everything to a two, then get everything to a three. Because there's no point in having a sales of 10 out of 10, or an absolutely amazing triage process, if you can't actually get the issue resolved, or if you can't bill it, or whatever the case may be. So just try and level that up across the board. Because that way, you know, sometimes crawl before you walk is that with those sort of things.

If the first thing that came to your mind when Ben said that was, "I have no time to do that," that's where you start. Figure out what's taking up your time, automate, delegate, and then go work on the other departments.

But guys, with that I will wrap that up. I'd like to say a huge thank you for today. As always, hopefully everyone got to learn a few bits and pieces. If you've got any follow-on questions, don't hesitate to reach out. I think we've got a few assets that we will be sending out after this.

We also have our upcoming series. You know, marketing — if you haven't seen our marketing automation, definitely have a look at that. We actually touch on tying sales and marketing together a bit as well, around automations, etc. We've got a number of different marketing workshops coming out. We've got — speaking of automations — our Rewst system, if you're not already using it, feel free to check that out. We have a technical session coming up for that. And the next two MSPs in Conversation — we don't have the dates there, but they will be on our events page on our website, so feel free to check that out: "How to Build the Perfect Team," who are you going to delegate to guys, and "Finding the Perfect Prospects." So there's a couple of different topics. If you've got ideas for topics, or you want to cover off something, if you want to join us as a panelist, feel free to reach out.

But with that, I'd like to thank everyone. If you missed a few bits and pieces, it's recorded, we'll send out the link afterwards. But again guys, James, Aaron, thank you so much for joining us today, it's always a pleasure. And thank you to everyone for listening to us ramble on for an hour. Thanks everyone.