MSP Operational Maturity: Tackling Growing Pains at Different MSP Sizes

Thank you for everyone for joining us today. This is our first session for MSPs in Conversation. We are joined by Aaron, Jim and James. I'll let them introduce themselves in a second, but today is about operational maturity. We have over 150 partners and we hear lots of different things from our community. We've implemented a lot of those in our own business, so today is about a very casual conversation, tips and tricks from some of our partners. So Jim, James and Aaron, feel free to jump in. Very casual today.

Let me just move to the next slide. So Merrill, we've got an Uber Eats voucher. For those who've registered, you would have already received your Uber Eats voucher in your emails if you're a qualified MSP attendee. If we weren't able to reach you, because we did try to call and then we sent you an email, so if you haven't yet received that, just shoot me a message here on the Zoom and we can send that off to you.

All right, so a very quick overview of Hosted Network. Most of you will know who we are already, but if you don't, Hosted Network started as an MSP, which is kind of why we like doing these sort of pieces of content, because we remember what it's like. We've lived a lot of the pain points ourselves, and we love the community that we have. So a quick overview of the services that we've got there. I won't deep dive into them or anything like that, but in summary we are an Australian-only wholesale cloud and telco provider for MSPs.

So without further ado, I will introduce the guys. Aaron from Rodin, Jim from atomicBIT, James from Teamwork Technology. There you go James, I got it right for you for once. So starting with Aaron, if we can just do a very quick introduction of your businesses.

Yeah sure. Rodin Business Solutions, we're based in Wollongong. We're across most of the country, primarily New South Wales. We have 26 full-time staff and about 4,000 managed endpoints. I've been with the company 19 years, and that's probably about it.

Cool, thanks. Jim?

Yep, so atomicBIT is a small MSP and our target market is small to medium business. So we have a very varied client base of a couple of hundred clients, and we probably manage about 600 endpoints, 700 endpoints. Our clients can range from one person to 200, so we cross many different verticals.

Cool, thank you. And James?

Yeah, well we're a 12-man MSP. We have a couple hundred clients, managing around 12 to 1,300 endpoints. We specialize in dental, that's our forte. However, we've slowly learned to realize that whilst we've got a big chunk of dental, we've got a lot of small to medium other businesses that are varied across many industries.

Great. All right, well, a bit of an overview of today's topic. So, operational maturity. Now many of you may have actually heard of this already, but we use this within our business and it's been pivotal. I first heard of this from a channel consultant and he drew it out on the back of a paper napkin in a coffee shop for me many years ago, and it's been a pivotal piece of our business. We sort of drive this a little bit different to what we've got on the screen.

So what we've got here is treated like gamification. You know, if you're into your MMOs or your RPGs, leveling up, right? And it's about the things that you need to do to level up your business, whether it be an MSP or any other business, right? Now this is a very high level, one to five approach. We do this a little bit more in depth internally at Hosted Network. This is really just to give you a very high level overview. We do this at a per department level and we do it out of 10, so it's a little bit more fine-grained.

But the overall approach of operational maturity is that, let's just say sales, right? Sales sell the dream. If you're a one-man band, if you're a very small MSP, then you can control all of the moving parts. You can sell the dream, you can deliver the quality, the project goes to time, all those bits and pieces, you can invoice, you can control all the different facets of your business. As you grow, there's different things that you need to do to level up.

So we look at that. I use the sales example: if sales sells the dream but let's say your help desk drops the ball, if you've sold to the client an absolutely amazing support offering but all of a sudden your support team is dropping it, so sales might be say 10 out of 10 but your support team might only be a two out of ten, right? It's about looking at your business and leveling it up consistently across the board, because it doesn't even matter if it's, let's say, HR down there as a bigger MSP or a bigger business. If your HR or your finance is a two out of ten, it's dropping the ball, it's pulling everyone down.

So today is really about two key things that help drive, in my opinion, that we at Hosted Network believe drive operational maturity, and that is systems and people. So that's what we're going to be covering today. So what I'm going to do is ditch the slide deck, because everyone gets bored by death by PowerPoint, and just stick with the panelists.

So first of all, Jim, I'm going to start with you. Tell us a little bit about how your business started.

So my business started as a side business. I used to work for a large corporate IT firm, a global IT firm, where I learned a lot of lessons on how to grow and how to become more efficient. I started on the side, like we were talking about before, with a spreadsheet as my only tool. Then as the business grew and we started to bring new clients, we had lots of referrals from our word of mouth and our current client base, and I started to find you definitely needed tools to continue to grow and not to drop the ball, like you were saying.

Cool. And James, do you mind just running through how you and Teamwork Technology started?

Yeah, well, we originally started off as a cloud backup company, and very quickly I realized that my day job was paying the bills and then I had a little bit of money left over at the end of every month that I could spend on fun stuff. As this grew, I realized very quickly that the only way I could make it grow faster was by coming up with a way to shovel customers into it, and that was to become an MSP, right?

At the time I was working for a car dealership chain in their IT department. I'd worked in managed services before and up came an opportunity to actually work with somebody who sold dental software. Very quickly we got into bed and started a business together, right? I'm talking like within days, as all good business decisions are done, in bed and very quickly it's going to be the best idea ever, right?

Now after two years we've grown this. He was a great resource for bringing in customers, and I'll never deny that, but our relationship was nothing short of a toxic wasteland, right? There was a big ego in the room and it was from both of us. I wanted to go in an innovative direction, he wanted to stick on the safe direction of selling what he knew. However, as we've seen in the industry, things have changed, and the products that we sold 10 years ago you can't sell today with an active conscience because they're no longer best in class, right? Sure, you could sell Windows NT or Windows XP. It works well, that'd work, less problems, that's it.

But we went from literally overnight having one customer to 30, 30 to 100, right, over a short two year period. So in that period we had to work fast and work hard and innovate and change, and it was quite scary.

Cool. And Aaron, I mean you've been with Rodin for 19 years, which seems like a lifetime.

Which doesn't feel like a lot of time. Started when I was 19, been there for 19.

So do the maths. Very good. Give us the rundown there.

Yeah, so we started, yes, so I've obviously been there for a long time. It did start a few years before I got there, but we actually focused back then, so 2001 when I started, we were very much in the retail space. So think of your retail computer chain stores with a very small fraction of a little bit of corporate business stuff on the side. We picked up some things like HP printer contracts and HP repair agencies over the years. Just naturally over the next six or seven years things started to shift away from retail into more of the business side of things. So it got to a point where we just dropped the retail side and then just focused on the business. That was probably done 2007-ish, if I remember correctly, something like that, around that era.

So I guess you could call it, we were doing MSP stuff before it was really called MSP. I mean, that was early MSP days then, but yeah, it kind of really just scaled up from there. So I've gone from, you know, ultimately one, two-man band stuff managing the business. I'm technical myself, so I was involved in that. I ran that department and absolutely scaled up from there. So I've kind of been through, I don't know, I'm not going to say everyone's growth problems, but I've definitely seen them and I've been through those phases of when you try and stop doing things on the cheap, try to bring in tools, try to bring in this and that, and yeah, absolutely felt all those growing pains and went to introduce management layers and all those types of things.

Cool. Okay, I think, kind of like what all three of you said, that's, you know, everyone's got different pain points within their business that they're trying to tackle, right? And that's kind of what today's about: how do you move your business forward, level up, like I said. I don't know, played World of Warcraft, how do you, whatever it was. A bit of a nerd analogy there, no idea, I was expecting someone maybe.

I was a big World War, sorry, you're on your own there.

Hand on heart mate, handle it.

Why MSP Peer Communities Matter

Okay, so the first question is, and Aaron, I'll continue with you, when you guys were, you know, early days, did you leverage any community groups?

Early days, no, and I would regret that now, absolutely. So, like I'm sure like many of you on the call probably think, you know how to do it best, everything's unique that you do, you don't want to tell your secrets to people, things like that. So yeah, early days, definitely did not leverage community groups. That was something that we probably did more so in the last six to seven years, six years, probably something of that nature.

Okay. And Jim, how about yourself? Today, are you leveraging community groups?

So I'm pretty much the same as Aaron, to be honest. I do regret I didn't when I was starting the business, and I now see the value, you know, even with partners like you guys. I learn so much all the time, and I learn this from all these different partners and colleagues that I work with. So yeah, regretfully, I wish I'd done it from the start. It wasn't really because I thought I knew better, it was I just didn't know.

Yeah, and I can relate to that myself, that up until, I don't know, five years ago, the community groups, I didn't even know they sort of existed. You're dealing with your day-to-day mindset, right, all the problems that you've got day to day, and you're focusing on the next one, the next one. And James, look at yourself, did you and do you?

Well, only in the last couple of years have we really started to do the peer groups. We joined SMBiT years and years and years ago, and we didn't get much benefit out of it, especially in the Sydney chapter. It felt very alien to me, the group. There are a couple of really good guys in there, and what a great community, but it just wasn't for me.

Okay, so because we've got some of the chat at the moment, there's the different community groups like BNI, your local chamber of commerce and things like that. So when I say community groups, I'm talking MSP-focused community groups, right? So these days there's The Tech Tribe, Nigel Moore's group, but even the group on Reddit, right? Those of you that are into social media and whatnot, the MSP community on Reddit is huge. The MSP groups even on Facebook, those sort of things. What about those guys? So James, do you leverage those, play around a little bit with Reddit, reading a lot of the stuff that happens in there? But maybe you're a lurker, that's okay.

I'm a lurker, yeah. But mainly I find the most benefit comes from Nigel Moore's deck, right? That is literally, hands down for us, the best community that we've ever seen or done. I'm not trying to spruik it for the sake of spruiking, I'm definitely not wearing a Tech Tribe t-shirt under this, but it's people with the same problems that we're having at any given time, because the MSPs that are in there are ranging from one-man bands all the way up to 50-60 plus people. And I just, hands down, it's been the best. Before that, I always found that talking to other people in the industry direct was best, people like yourself Ben. One person who comes to mind is Travis Small from Gem Computers. I always liked talking to people that were larger than us, because they've gone through these problems that we've had.

And we've got a great community in that sense, right? And that's one of the things that I personally love about the MSP community, is that we hold events, and obviously we can't do these in person at the moment, hence why we're doing it via Zoom, but so many ideas get passed around the room and whatnot. So yeah, it's interesting in that sense.

So you mentioned that Travis is a bit of, I'm going to use the word, and knowing that they're a partner as well, but a mentor, right? So if he's a bit of a mentor for you, what about Jim, Aaron? Do you guys have, whether in your lives or within your organization, people that have been mentors to help you understand and know what to focus on next? Yeah, do you want to go, Jim?

Yeah, not really, to be honest with you. Like I said, I haven't had much exposure, and I wish I had more. I really have only seen it through you guys, to be honest with you. I'm still learning all the time, so I'd say I love the way you guys, I always try to attend things that you guys do, because I always learn a lot, but nobody else specifically. And if I look at that operational maturity scale, our business is sort of towards the bottom there, and when you're towards the bottom there, you just don't have time to even look at Reddit. I'm often browsing Facebook at the most, the time that you have free on your phone, let's just put it that way.

A big one I'll add, Ben, because I think it's really valuable. I'll go face to face first. So for me, attending conferences and things like that, I try to stay very much up to date on things that are going around, and through my own research and reading. For me, attending vendor conferences and things like that, I don't personally get a lot out of the conference themselves, but it's the networking. The networking is where I get the biggest, and that's very much like, Ben, when you run get-togethers, you guys are less focused on the topic or the tech at the time, well there always has to be generally a topic, but the networking itself is much better.

We're a ConnectWise partner and have been for about five, six years now, and they used to do those quarterly events which were good. I didn't get anything out of the ConnectWise event itself, and I'll be blatantly honest about that, but what I did get was talking to other partners, which is exactly what everyone's talking about.

In terms of an online resource though, MSP Geek, formerly LabTech Geek, has hands down been the best single resource for me. It depends on how you want to obtain your knowledge and be involved in that. Facebook, for me, I don't really enjoy Facebook groups. MSP Reddit, yes, there is some good stuff in there, but there's also a lot of flaming that goes on in there. So while there is some good stuff in there, I actually don't really enjoy Reddit, and that's all the flaming that goes on.

Tech Tribe I personally haven't used. I really want to get into it because I hear some amazing things about it, I've never heard a bad word about it. But MSP Geek, both the forums and basically the Slack environment that they have, it's amazing. It originally started off for ConnectWise Automate, which was LabTech back in the day, but it's now expanded over the last few years. So whether you're a Datto RMM or any of them actually, they've got channels for everything in there, and there's some really clever people in there. It's a really open community, sharing scripts, sharing knowledge, and the security-focused channels, there's an everything-focused channel to be honest.

And when these big incidents hit, Kaseya, that's the most active spot. You have all of the vendors have their own channels in there, you've got the Huntress guys, so fast, everyone has their own channel in there, and everyone's really, really active and really positive. So that's probably my biggest input there. And I don't have someone internally that I've learned from, that's unfortunately been me, in my position, to do that to others. But yeah, if you are watching this and you're not sure where to go, definitely check Tech Tribe, by here it's amazing as a local one, but then MSP Geek would be my number one after that.

Yeah, cool, that's fantastic. Thank you guys.

Pricing, Rate Rises and Selling Your Value

All right, so maybe let's shift gears a little bit. So when you're a smaller MSP, and I'm going to speak from personal experience, so maybe not everyone can relate to this, but I certainly undervalued the value of what we were doing, and I see that far too often in our industry, in the sense that the smaller MSPs, they're trying to grow, but they're charging way too low, right? And I'm going to say how much I charged when I first started. I used to charge $40 an hour when I was a one-man band back in the day, right? And now I kind of cringe at that. But there's a lot of fear behind trying to grow, trying to actually do rate rises, introducing new services and things like that.

So how have you guys in the past tackled things like rate rises, you know, where it might have upset a client, things like that? James, can you give me an example of how you've mitigated that potential risk?

I am the worst person to ask this question. Okay, well, shifty, dude. Because we set out rates, and like I said, when we first started, somebody had a lot of experience with us, right, and basically he set the rates and they were industry standard. I looked at them back then, I'm going, they're too high, $160 exclusive of GST an hour for non-managed, and I'm going, wow, all right. But it's been lucky on the hourly rate part that we set that at what was fair, because that's allowed us to actually grow, right? We're not having to have those awful conversations of all the hourly rate's increased.

The one drama that we have had is we've never actually increased our managed services rates to existing customers. Yes, we've increased them, so we've got customers that pay $25 a computer a month plus $10 a month for antivirus, but then we've got the other flip side of the coin where they pay $50 a month that includes the antivirus per computer. Now I know that there are MSPs out there that are charging $90, right, but I also know that in the direct industry that we operate in as well, which is dental, we've got people down there doing $35 all day every day, which we now know as an MSP of our size is impossible to give quality, because by the time you include your license for your RMM, your antivirus, even things like rent, staff, all these people, yeah, it's all magical. My point is that we're shoeboxed at the moment, because if we increase, we lose opportunities, and I'm not prepared to go down. So it comes down to how do we sell our value at that $50-a-computer-a-month mark, right?

Okay, so can I shift keys to Aaron there? So Aaron, you guys are a bit bigger, right? So how in the past have you, I'm going to say bluntly, kind of like weeded out the crap, the customer may not have wanted?

Yeah, definitely. Look, I was going to say to you, James, then. So there's a couple of things there. Look, it's all about demonstrating value. If you're demonstrating that value, our experience is you can increase rates and people aren't necessarily going to walk. If you are that worried about them going to walk, they're probably not the right customer for you anyway. You need to get comfortable with customer churn.

Something we do, you mentioned you've got some managed agreements out there that have never changed. We have, and we've done this for 10 years, we've written an automatic five percent increase every year into our agreements, and that just rolls on up, and that's a five percent on the overall value. Now I know you were talking about per-computer pricing and things like that. We actually don't operate like that. We do for our calculations and stuff, but we work on a fixed price for the customer, and then there are some triggers that will trigger a re-quote, if you will: new locations, expansions, big user change counts, and then we do reviews on that every year.

But a big one for me that just stood out to me when you were speaking was, you said you've got some customers that are quite low in the payment side and you've got other ones that are on different scales. For me, and this is something we've been working on pretty heavily over the last two years, and this, I think it would have been the second last of your slides, I think it was the second one where you're tuning or optimizing, looking at what your hourly rate is to your clients if you're on your agreements. Now you need some good data from your PSAs and things like that to identify that, but trying to understand the hourly rate that you're working at and those non-profitable versus profitable customers, and then pick your hourly rate and target towards it. Look at all your margins on clients that are below that and try and figure out why those clients are in that space. Are they noisy? Is it that you need training, as in for them, not necessarily you? Maybe there's ongoing problems that your help desk are just ticking over and you're just fixing these things month after month, but realistically all it's doing is wearing you guys down. These are all the little things that you kind of need to do, especially when you get into that higher optimizing level, to try and fit your hourly rate.

And to be honest, one of the things that we are doing at the moment is, we were going to go back and start increasing prices at the halfway through next year, we made the decision at the financial year, send out an email, unfortunately the backflu came through and we've all said, I haven't heard of it, it's the reason why we have to wear a mask every time we want to go buy a Big Mac, all right? That sort of affected that rate increase for us. But in the meantime we've also signed up for a program called C-Level Operations, which the head of Australia here is James, who used to work at a company called CloudJumper, really nice fellow. As a part of this program, the first thing he does is crack open your PSA and go, have you got it configured, how are you running this? And we've literally just spent the last six months coming up with ticket types, all sorts of weird and wonderful things, so that we can actually dive down and get the data out of our PSA so we can look at effective hourly rates.

James, I'm going to pause you there, sorry Aaron. It's a good point that you raise, and that ties back to the topic today, right? About ticket types and things like that, because you're doing that reactively, right? You've hit a pain point. However, ideally in the perfect world you want to be proactive about it, and that's the topic of today, in the sense of what are some of these things that you can do, fast-tracking that so you're ahead of that curve, rather than being, oh, I've got a pain point now because I've got a fire, how do I tackle that ahead of time, knowing that I'm going to have that fire? Obviously easier said than done, right?

Yeah. Well, when you implement your PSA, I guarantee you, James, when you put your PSA in, you probably had all these options to set up your ticket types and subtypes and item level stuff and you went, we'll do that later, right?

Yeah, it's not just that, it's like we drew the short straw, the glass had, the guy who implemented it with us from ConnectWise was the worst implementer ever.

Yeah, I was going to say, we need like the beeper that every time when someone says that, the people goes off. So, but look, absolutely. I guess to touch on what you were saying there, Ben, everyone's going to want to cut corners and things like that. We took nine months to put our Manage implementation in and go live with it. That was two of us, we actually didn't use an implementer at all, we did it all internally, which I think would cost 30 or 40 grand or whatever they quote you. And I guess my advice would be to really take on board the PSA of your choice and really use all the options. Because while at the start you would choose and you think, I'm not going to need that, that pain point you're in now about not having types and things like that, you'll realize that later on, and it's really, really important to get that data.

Because, you've mentioned someone's coming in to look at it now, for anyone that's using ConnectWise Manage online, I can give a plug to Ignition 360 in terms of data analytics and reporting.

Yeah, for sure.

So they'll do the same thing, James, for you. They'll take a look at your data and say, right, and I'll look at maturity and how it's not really focusing on how it's configured, because I'll just suck their reports out and say, right, apparently you got three percent optimization, and why do we have that? Start looking and realize you don't have half the platform filled out. So I guess on ConnectWise, yeah, garbage in, garbage out is important, important. The only way we realized was, we started sucking reports out of ConnectWise and we're like, this is freaking useless.

Yeah, well, their reports are useless.

But it really is important. You need, as you guys grow, and maybe for yourself, Jim, I don't know what PSA and things you're using, but look, I think ConnectWise have a saying, I'm kind of remembering this from my university days, for anyone that knows what I'm talking about, like they say, on time, all time, every time, in terms of your time entry. I think that is critical, and we were very strict on that from the start and always have been, that's been hugely beneficial to us. That comes back onto your people, because if they're not doing it and then you try to force your techs to start doing something down the track, you've got a shift then, you've got to pry everyone out of their ways, and then you've got other problems to deal with.

So yeah, I mean, James, you'll go through and put types and subtypes and things in, but then you've got to actually get your staff using them and enforcing them and actually picking the right ones. I mean, we just did a review of this myself from operations manager just last week, and we realized that one of our types, which we went on a very strict ITIL approach, but one of our types has become a bit of a dumping ground, and that's because of 365 and new services, so a lot of Power BI, a lot of this SharePoint, whatever. So you need to evolve those over time as well and definitely review them. But types and subtypes are a great thing. I was able to pull reports two weeks after COVID hit last March and say, this is how many hours we spent on configuring remote access, and we actually blasted that out to our client base and showed value. We showed that we spent three full-time techs for two and a half weeks or whatever it was, just doing remote access tickets for them, and trying to show the value, and this is where you really need a managed service provider and how much value everyone's getting out of their fixed price agreements at that point.

So there's nothing worse than just getting an invoice once a month, right?

No, you've got to show value. It's good in a way that they're not hearing from you, you're looking after everything, then yeah, sure, but if you're not showing that value, you're going to get into trouble. They're going to start questioning things.

Choosing and Configuring Your PSA

I'm going to follow the train of thought that you've just started there, Aaron. So a question to Jim. Jim, I mean, you come from the enterprise world, right? I think, was it IBM?

Yeah, yep, yep.

So ITIL, right? So ITIL is often, and I see some MSPs require it on their CVs, others don't care. How do you feel about ITIL in your organization?

I think it's definitely the greatest and very beneficial. At IBM it was the first piece of training that I had every new staff member joining our team complete, which was a server engineering team. And to be honest with you, I've built atomicBIT all along that ITIL base framework. And even to this day, new staff that we have at atomicBIT, we also take them through that training. And all our PSAs and all the tools we're starting to implement, so we're sort of at the stage, just going back one step as well, we're starting to implement a lot of these things and tools. And it's hard because our clients are smaller on the small to medium scale, so you can't just go out there and deploy Autotask, it's just not worth it. We've done it in the past and we've gone off it.

Were you one of those ones that swallowed the red pill and you paid the $40,000 setup fee?

Yeah, there is a company, I just can't quite remember, I thought it was Ignition 360, but I do hear that quite often, that getting the actual PSA companies to set them up is a waste of time and money.

Total, total waste of time. There are a few organizations, and I can't remember, Sierra Pacific is one, and I felt like there's something to do with Ninja or something else, but basically all they do, they don't sell the PSA, they just set it up, right, and they are dramatically cheaper. There's a few I've seen in a few of the communities, but for people that are looking at, if you're not quite at the PSA, don't necessarily any of these big vendors, they put their tax on it, right, and they're going to charge you through, you know, through the ask for it. And I've seen it time and time again, even when I, we had Autotask and N-able we used back when we were running our MSP, and we paid for it as well, and we were a small MSP and we financed it at the time, right. There was, I think we spent about 50 grand on getting their professional services to do the deployment, and it was IBM finance at the time, and it just sort of sat there for years and years and years, and in the end we actually got rid of N-able while we were still paying for it. So that's why I raise it, in the sense of those bits and pieces.

Yeah, 100 percent on that. Just to add that consultants, I mentioned MSP Geek earlier, there's plenty of consultants, generally from America, but there's some around that hang in there. Michael Priest, which you guys may know from SMBiT, he hangs around in there, he can do some stuff for Automate, I think he's consulting for Automate. I probably shouldn't plug his name without knowing that for sure, but even if anyone wants to reach out to me, I've been there, I've done it. But a hundred percent, don't pay the vendors when the vendors tell you there's a minimum 20 hours that you have to pay for to buy the product. Tell them to go themselves.

I can tell you from experience, look, I've got something to add there. So I've got a second business up in Queensland, and we just, after using Autotask for the first year of business while we got the thing off the ground, we've just cut over to ConnectWise, and we actually had a really good ConnectWise implementer, Jason, he's based in Australia I think, and we pumped it out in about a month and a half, and he was fantastic.

Yeah, that's good.

I think 90 percent of what made it so easy was number one, I had Kirsty, so for those of you who don't know, Kirsty is like Teamwork's operations manager, she runs the joint, I just show up and do what she says. But she really drove that implementation home, and we were using a lot of the principles that we took from Teamwork and my business partner's company down in Melbourne to come up with a really nice, swish ConnectWise implementation. So as long as you know what the hell you're doing, the 20 hours that ConnectWise gives you can be beneficial, but if you've just signed a ConnectWise contract, it's useless, right? You've already signed it, it's too late, it's useless.

Food for thought, if you're thinking about it, make sure that you understand you've got room to negotiate with those PSA vendors.

Documentation: The Bane of Every MSP

Let's move on from PSA a little bit. Let's talk, you know, I said before, in terms of big things that move operational maturity, for systems and people. Let's stay on the systems topic, but let's talk documentation. Bane of a lot of MSPs. You know, the amount of times we've reinvented our own approach to documentation, I'm ashamed of. We've used all sorts of things, we've used Word documents, we've used, I mean, for a long time we used Confluence, and I think even within Confluence we've reinvented that about four times. All sorts of things. It's a nightmare.

When you're a one-man band, it really doesn't matter as much, right? You keep everything up here.

Yeah, no, that's wrong, it does matter, of course it does.

Of course, well that's it, yes, of course, but the more you, the further you go along, the more and more it becomes important. So I guess, Jim, you're a younger MSP, what are some of the early lessons that you've tackled in terms of documentation to move your internal approach forward?

Yeah, so look, I've definitely started to feel the pain as we started to get new staff members joining, because they're constantly taking your time: how do I do this, where's the password for this?

Correct, that's right.

And I probably reinvented it from Word documents to OneNote, and then made SharePoint things and blah blah blah, and now we have just deployed and implemented IT Glue. And everyone's going to have a different opinion, that's okay, I love Aaron's facial expression as well.

So you know, trust me, I pay for IT Glue as well, I use it, and that's what I just did, and you know why? I'm the guy running the petition against Nadir, the CTO and general manager of IT Glue right now, that has over 200 signatures for people to take their feature requests seriously, plus they're owned by Kaseya, so anyway, just saying.

Who's doing those in? And we have historically used IT Glue as well. But I mean, even for us, that moved that operational maturity component forward dramatically. So there's a lot of MSPs, and that's what this is about, right? And within that concept of operational maturity, let's say you're a five out of ten for a particular piece. It doesn't mean that that system is going to stay forever, right? In order to go to, I don't know, a seven or eight, it might be something else, right? Your requirements are going to change over time, and you need to accept that, it's just part of business. It's a pain in the ass, but you just deal with it.

So, okay, so we've got, yeah, there's a few other, oh, there you go, Aaron. Okay, cool, we'll share that afterwards. I'm reading the chat, and it's Aaron, I'm better against it, but I'm still paying them. And that's where I'm going, in the sense of, okay, for someone that doesn't have something like, whether it's, let's focus not on brands, why is a system like that better than, say, Word documents?

Can I take that, please? Okay. You need to make documentation simple. It has to be simple, it has to be fast for your techs, so they won't do it. That's pretty much the summary I can give you. If it's in your head, get it out of your head. Leave the example of IT Glue and Hudu and those types of platforms. Don't use IT Boost I think, from ConnectWise, but those platforms, they gear it up for an MSP, whereas you've got those other ones, Ben, you mentioned your Confluence and SharePoint, Word, whatever. We're not an MSP anymore, so yeah.

That's right, that's right, they're scaled and targeted differently.

You need something aimed at an MSP. And look, as much as I hate it, I'll probably renew my subscription, because I couldn't be bothered moving away from it, because it's such a job, right? I think it's actually probably easier to move PSA and RMM than it is to move your documentation, unless they have a seamless migration tool, but they don't, and there's still a few spanners with that, even though I just posted a script to do it.

So it's really critical that you have it, it needs to be nice and easy. You definitely need to lead the way if you're in charge of this at your own MSP, or you're a smaller one or two man person, you need to be the one demonstrating how to do it. So lead by example, not a do what I say, not as I do type approach with documentation. Do it, build it out, because when they see it working well, and these platforms link things up well and make it very easy to visualize and search, if your technicians come on board and see a good working documentation platform, they're going to want to join in and do that. If it's a mess when they get there, they're just going to get frustrated. You walk into a nice tidy room and you don't want to mess it up, if it's just a mess then you don't care, right? Same kind of approach. So I would absolutely focus on that. We did it probably seven, eight years ago, and it's been critical to everything we do.

Okay, so we've got a question here. Does anyone have any recommendations on a good IT Glue implementation consultant?

I would argue you don't need one.

I'd agree, that's the point of those platforms, they're built ready to go.

Okay. And James, when you were smaller, what was your transition path? You know, you're using IT Glue now, yeah? So what did you use before that?

So we used OneNote, right? And I always worried about having my passwords for all my clients up in the cloud, it's the perfect example for an Aladdin's cave attack, it's like a spreadsheet labeled "passwords," right?

Oh, that's 100 percent right.

But shortly after we implemented IT Glue, we came in one day and we're trying to access our passwords, and you click it and it just comes up with a hash. For about half a day we operated our business without knowing what our clients' passwords were, while IT Glue went out and figured out what was actually wrong in the back end so that they could recover our passwords.

And that's a risk of any outsourcing, any system, right? I mean, you could run everything off spreadsheets and Word docs, but I guess the risk versus the reward of having a system like that. At home I feel that there needs to be some sort of, I don't think, I know they have an export function, but do you need to build it into your business where you download a copy of all your customers' passwords once a month?

We actually do that, James.

Yeah, just in case.

Yeah, well, I know that some MSPs actually sort of, they have to, in their agreements they have to actually provide those sort of details on a regular basis, right? So depending on the agreement. And I'll just post in the chat for anyone, CyberDrain, Kelvin, he's an MVP, he built an unofficial IT Glue backup script, which I've just posted. Aaron, you need to post that to the audience.

You're posting that to us?

All that stuff I'm posting, there we go. I don't like Zoom.

Everyone, there you go. So all this stuff I've just been rambling on has just been to you, Luke, so there we go.

All right, cool, okay. So if there's a quick one tip from each of you, and it might be the same one, to improve documentation, what would it be?

If you don't do it, you're fired. Extreme, but sure.

Okay, one tip. Yeah, look, other than do it, yeah, you need to get it together so you can quickly respond.

You can't scale without it. If it's in your head, it's not okay. I've seen it time and time again. Even, so the MSP that we used to run, I didn't start it, and my business partner at the time, it took a while to get it all out of his head into the actual techs' hands, and that's quite common. You're wasting your own money, right? If it's in your head, your techs aren't doing their job, they're going to ask you, it's costing more and more.

And I think, actually, sorry, I was going to say, in your projects, when you guys are doing projects for clients, bake time into your project to do documentation. Build a client, it's in their best interest that it's documented, because even if you walk, I mean, IT Glue, it's very simple to do an offboarding with IT Glue, just export it, hand it over, or migrate it to their IT Glue. But yeah, we charge, depending on the size of the project, two, four, six hours to do documentation, and that involves building the network diagrams, documenting it, making sure it's all done. So that would be my advice, charge the customer to do it, and do it well.

I think you hit it right on the head before, Aaron, when you said lead by example, because nine times out of ten, if the help desk manager or the owner normally isn't documenting, it doesn't encourage others to. And I've always seen that as a success, the second that the owner gets into it, it just flows, it's a top-down.

Absolutely, that definitely is a top-down one.

People and Process: Time Entry and Ticket Notes

Well, let's shift into that in terms of the people approach, and we'll shift between documentation and, Aaron, you and I have talked about this before, timesheets and internal ticket notes, right? In my experience, back in the day I had an absolute nightmare of getting people to consistently, for a long time, but at the same time, occasionally, well, occasionally far too often, we weren't reviewing the timesheets. We're too busy as a smaller MSP fighting fires, right? And so we'd come back, and unfortunately we had one tech that didn't log time for basically a month, several times. Learn from your prior mistakes, right? Hence the reason for these sort of webinars.

What are some of the ways that you encourage your techs to log their time, if you require them to log time, because not all MSPs do, but at the very least do internal ticket notes? Because internal ticket notes in my mind are fundamental, right? Someone's off sick, there's no notes, we get f'ed, you know, you have to start again. James, what are some of the things that Teamwork Technology do to encourage that?

So basically, we had to become really tough with it, and we hired a really capable SDM. Not as an SDM, he actually was a team leader at Queensland University somewhere, and then he came to us as a tech, and the SDM left, he took over that role. But with that, we implemented several processes where our techs can't close tickets, right? We don't want them to close tickets. And as a part of the SDM's role, it's his role to go through and go, okay, yep, you did this, and then include quality control. But it also, you know, you might have Andrew looked at this ticket on a Monday, a printing issue for this client, and Alex might have looked at it on Tuesday, Sam might have looked at it on a Wednesday, and they all think it's the first time that the issue's been fixed, and they're fixing it for good, but it's happened three days in a row. By having one central closing point, it makes sure that there's quality control on the ticket closure, what's being done, has actually closed it, if it's still a recurring issue, then the SDM can go, wait, you've all done the same thing, it's come back, escalate back to a senior, and it gets resolved, we go back and fix it properly.

It's important, but it also means that it's keeping our guys honest, because at the same time he's looking, have they done their eight hours, have they done a substantial amount of work for that eight hours, and it's happening every day.

All right, so that's a good example if you can afford to hire a dedicated service desk manager, right? But some MSPs just aren't there yet. So Jim, do you have a service desk manager at the moment, or is it yourself?

No, it's myself.

Yep, so perfect.

So I can tell you exactly what we do. So firstly, we use Freshdesk, which we've recently implemented as well. We came from Zoho, and I'm loving Freshdesk, I'll just tell you that, it's beautiful. From our employees' perspective and all our techs, straight off the bat, they have to log information in tickets, and they must put time spent in the tickets, and I pull that out each month. I see every ticket that's closed, so if I don't see the right amount of hours, I correct them, and I'll go back to the employee, and I review it every month for billing, and make adjustments as required and re-educate the employees that have done it wrong if need be. And I'm loving IT Glue checklists, so I'm now making our employees, when I'm seeing new user onboards for different companies, I need it linked to the IT Glue checklist with each thing ticked off, so no missing pieces.

Okay. Yeah. So Aaron, what about you? Aaron's actually given me advice for that particular staff member that I previously spoke about.

Yeah, oh yeah, we take a bit of a different approach. And I mean, we've been doing time so long, I almost forget how I implemented it initially, and I'm sure I had issues then at the time, but we've taken an approach, sure, we have an operations manager and SDM, but they don't sit there and close every ticket. So we take a different approach, that responsibility goes onto the people, and we almost sort of crowdsource it, so to speak. We have reports, we have everything, full visibility, so we're not hiding that away in a report for a manager to see, we have TVs, we have reports that go out, everyone has their own dashboards. We use BrightGauge for this, and everyone sees their time. They have to enter a certain amount of time every day, literally each team has everyone on a little scorecard, and it shows nice green, yellow, red. If they haven't entered their time, they get warnings in an email every day, so it's all the way down to the daily. Then there's a weekly report that goes to the team leader and manager, and if straight away it's very clear, bang, it sits in your email, this person hasn't logged enough time that week, but equally everyone sees that daily as well. So we've got a good culture where if there's someone not entering time, that means they're not working, and that'll be highlighted very, very quickly and dealt with properly as a coaching type thing.

In terms of ticket notes, Ben, yeah, look, that one's definitely a cultural problem. You have to bring it up. Ticket escalations, we did have a little lull recently where for some reason a certain team just decided to escalate tickets to a different department and not bother writing anything, and I don't know why it happened, but we just had to coach it through, and it just becomes part of the environment. So yeah, ticket notes are really, really important, but then just visibility, just getting it out there, making it, like you mentioned, gamifying things, Ben, just making it like that, making it a game, making scorecards and leaderboards and things like that. So if someone's slipping, straight away that's picked up. We measure things like phone call reports per week and things like that, and straight away, like I had a particular technician this week where we noticed he only took four calls last week and the other team around him were all taking 20 or 30. Looked at the amount of times that his phone was polled and it was six, so he's clearly just left his phone on do not disturb while working from home, and he's worked on tickets, he's still working, he's just not doing his part on the phone. So yeah, it's all about reporting and data, always comes back to it.

So it sounds like you and James, and to a degree Jim, you've all taken a slightly different approach. James's approach is kind of similar to Jim's, I mean he's sort of handed it over to someone else as a dedicated role, but Aaron, you've actually automated it.

Yeah, I'm trying to make scheduling systems. I don't think one single person closing 500 tickets a week is scalable, so we've tried to get off that. We've also given technicians and team leaders little buttons inside Manage, custom fields that say this ticket needs a review, so they call each other out, if they see terrible notes, they can click the button as ticks of review, and then the operations manager at the end of the week gets those tickets and then can call people out on it. So we've absolutely peered it around, and yes, automated reporting.

Okay, interesting. I actually saw that question on one of the Facebook groups the other day, and my piece of it was, you lead by example, you train, you pick it up, and you call it out publicly if that's the case, in team meetings and things like that, not to shame them, but hey, if you see it, bring it up, like what your buttons are for, right?

Yeah, communication is important.

On people, we had this discussion, we had our annual planning meeting the other day and we reviewed the odd issues that we've had over the past year, and they always come down to communication and escalation, and that's communication internally amongst the team or to the customer. If your communication's good, it kind of doesn't really matter what's going wrong. If you're using Teams or Slack or whatever, if you've got a big problem and you communicate it to your company, everyone's going to jump in and help, that's how you drive culture. But if someone sits there and tries and buries 17 hours into a help desk ticket and doesn't communicate that to anyone, that's when you're going to have problems.

Well, yeah, you see time entry of, you know, they just spent an entire day on something with like four bullet points of what they did, that's not right.

Well, and then if you're billing your customer with those notes, your customer sees it and goes, WTF, right? Or worse, if you're not billing them, that's actually worse.

If you're not billing them, well, yeah.

No time entry is even worse, right.

Well, or just they do do time entry, but that's on you because it's a fixed agreement, right, that's worse, that's a negative view. At least if you're billing the customer you can argue and try and build some of it. So yep, fair, fair.

So one of my next pieces is to actually talk about communication and culture of that sort of approach. So over the years at Hosted Network, we are really big on culture in general, I call us a little bit crazy. But not culture in the sense that we've got pinball machines or whatever, those are the things we try and drive a culture of going above and beyond, pushing each other but also helping each other out. But that's difficult to do if you don't have the right people on the bus in the right seats, I love that saying, right? Because what happens if you have brought someone on, at what point do you go, okay, enough's enough, right? Who wants to take that one?

Silence. It's a bit of a tough step, right? I'll take it, but I probably should let someone else take it. I'll let Jim take it.

Oh wow, James just got nothing to say.

It's a tough topic. And that's what, guys, I reckon that's what James does when he has a staff problem.

But actually, you know what, that's exactly what I do. Like, one of my strengths is not firing people and pulling them into line, so I hire really hard people to do that. I took that one off a friend, Travis Wall from Gem Computers, he's got this assassin, his name is Matthew Smart, he's probably watching at the moment. If you end up in an office with Matthew.

So basically from day one, as a smaller MSP and a small business that I've grown myself, every customer in my client base, we have a very close relationship, and our employees are reflecting atomicBIT, and if they're not doing it right, they get spoken to very quickly.

And yeah, is there a point though, and I'm actually going to ask Merrill to unmute herself. Merrill gave this piece of feedback to me, she came back from a partner meeting, like I said, we've driven a lot of change. Merrill, do you remember what you said to me, came back from a partner meeting?

Oh, you always like to bring this up, but I think we were just talking about cutting out the cancer.

Cutting out the cancer, yes. Cutting out the cancer, that's really it, the bad seeds. And that's kind of when I say culture, right? And hand on heart, these are some of the lessons that we've learned. I remember I had a partner once actually call up and say, I hang up every time I get this guy, right, but he only told us after, we realized it was still, right? And I know that's a hand on heart, we had to learn hard lessons there. That's not something I want to hear. And it hurts to hear that, you put a lot of effort in, but this particular guy I believed in, no, he can do that, he was a university grad, he scored really well and he could do a great job. But there came a time, how long do you wait, how far do you take it?

Not too far is the answer, but look, you've got, there's different ways to tackle this, there's different methodologies. If you are in that management leadership role, I would say go and get training around it. We implemented something called EOS, Entrepreneurial Operating System, two and a bit years ago, it's by far the best thing we've ever done. It's not for this particular topic, but we actually have an upcoming session on it, and I think you've got an EOS implementer, Dan, who's going to be attending that.

Oh, you've got Dan, okay, cool. Yeah, so we don't use Dan, we use someone else, but it's an amazing system. And something that they do on this very topic is they GWC your employees, and that means do they Get it, do they Want it, and do they have Capacity to do it. So it's a bit like a two out of three means you've got to fire them, or have a conversation with them and try and turn it around if you want, that's your call. But Get it means do they fully get the seat that they're in, do they understand the role. The secondary W, do they Want it, is pretty obvious, do they actually want to do that job, or are they just there and they want to do something else. And Capacity means a couple of things: are you giving them capacity in time, are you creating the space for them to do that role, or are you overworking them, but equally do they have the technical and mental capacity to do that role. If it's two out of three of those, or a no, then it's not automatic, just go and walk up and tell them to leave, but it's a sign that you have a major issue. If it's one cross, it's still a problem that you've got to bring up.

So yeah, I think we've likened it internally to going in the same direction, looking at all the different stuff, and if they're all kind of going in different directions, there's no way that you can grow or move forward.

Probably correct, yeah. And I've seen that before ourselves, right? We had a team member who was quite toxic in our organization a couple of years ago, and for that one person, he was in quite a senior role within the business, and he wanted a pay rise, he wanted a Mercedes, and I'm just like, no, why would I buy somebody a Mercedes, there's no need for you to have a company car. And as a result, they went around and they convinced half the team to quit because we're going broke apparently.

See, that's a bad seed. I've had one of them, you lasted six days.

And then, yeah.

Well, you're smart, that was my record.

Look, what was our guy's name? I think it was Tim. I didn't, everyone's got a story, and look, you really need to do it, but absolutely don't leave a bad seed there, it will spread. And equally, you might be able to find them a different role if you're big enough and you have those opportunities. But the other thing we've found, I guess on performance management, and Ben, that's really what you asked, like how long do you leave it, we've sort of come up with a process for that now. And before it gets to a formal sort of performance management, if you give the employee who's struggling some time in your week, so once a week maybe you give them 15 minutes, or if it's really bad you give them 15 minutes a day, and that's just to check in how they're going, what are they working on, okay, I've seen these things come up that you've done wrong in the last 24 hours. If you leave it for a month, it's too long. If you leave it for a week in certain scenarios, it's too long, because they just get frustrated when you bring these examples up.

Since we've kind of taken this performance managed approach and really refined it, it's amazing how many people we've pulled out of what we thought were gone and brought them back to really good employees. And again, it comes back to that thing I say, communication. If you are very open and honest and not a dick about how you're telling them they're not doing the right way, it's amazing how quickly you see it. If they just nod into it, okay, well then they shouldn't be with you, but if they are open and say, I'm sorry, I didn't even realize I was doing that, and they're genuine, you can bring these people back. And then we have it on a strict week thing now, and after that 12 weeks there's meetings all the way through, there's meetings every week, but then there's like monthly reviews across that three months, and you kind of know by month one or two what you're going to do at the end of that.

So I think when they go, yeah, yeah, yeah, it just means that they've given up.

Yeah, they have, they've given up, just give them up, that's fine, it's not worth wasting time on those people. But sometimes it's just worthwhile having a direct conversation with them, do you want to be here, do you want to?

And it's pretty honest to yourself too, though, Ben, you've got to be honest to yourself and check if you're doing the right thing. Sometimes it's easy to realize that the issue's yourself.

Well, sorry to miss that, the issue's yourself or your team, or maybe the person responsible for this, if you've got layers of management, maybe that person, maybe it's your manager that's telling you.

Yeah, I've done that, I've done that, and it turns out managing people is a fine art.

Yeah, absolutely. There's a great blog series, they do a podcast, and it's actually an HR app that we use internally called Fellow, I highly recommend that you check it out, it sends out a whole bunch of HR things about management and leadership, fantastic. Our leadership internally have to read a whole bunch of it, and it's fantastic. One-on-ones is probably one of the things that I'd throw out there. We do one-on-ones weekly or fortnightly, depending on the role, with every single team member in our company, and that is to identify issues, coach, and it's not about, oh, how you're working on this, it's about career problems, what's happening in their life, did they have, have they been up all week because they've just got a new baby and they just haven't told anyone, different things like that. So you can open up that communication.

Like Aaron said.

Hiring and Retaining Good Technicians

Well, look, we're at two o'clock right now, so I want to sort of, we're going to have to wrap up a little bit, but I want to end on one more positive question rather than firing people. More of a, how do you find good technicians? I'm not worried about sales or marketing or anything like that, let's just focus on the tech, right, because that's usually one of the first roles that people hire, and it's one of the repeating roles that we're always hiring for, right? You grow, you need more technical people. How do you find them?

Well, first thing I do is I ring up the Rodin help desk and I start offering jobs.

Great technicians, right?

They were great, because now they're here, so that's where he went, got it.

Honestly, this is it, it's always word of mouth, right, and all the good ones are usually employed somewhere where they're either unhappy, not growing, whatever. One of our customers, they sell seafood, right, and how they find their really good staff, their really good ones, is they drive through Macca's drive-throughs, and they find the really friendly ones. We've done that before.

Maybe I'm driving, no, I don't, but yeah, that is the perfect example. On Sundays, Kirsty even often does, she offered a HP repair tech a job when he was here once because she thought he had a great personality. So sometimes you've got to take a leap of faith.

Well, that's it, people fall into your life, and when you see them you just gotta grab it. And if it happens, it happens, if not, it wasn't meant to be. You know, we tried to get somebody that we've worked with years ago to join us, and they agreed to join us, but then they went back to resign from where they were and they got counter-offered back to stay, right. And it just goes to show that when they're probably more money-driven in that sense.

That's right, that means you're always going to be playing that game.

It's also, do you go with what's comfortable sometimes, and when you've got a family, right, are you better off staying where you are, you know, a bird in the hand is better than two in the bush, right?

I would say, Ben, promote from within if you can, that's a big thing I try to do, always trying to bring people up through the ranks. I find that builds loyalty. I've seen that work very well for Rodin over the years, and it's dealing with your junior guys and now they're your senior guys. It builds loyalty and I feel like they just get it, they understand your business better than trying to bring someone in. I've had, over the years I've definitely had some bad scenarios where, and they're all on me, I know, I brought this person in, oh, they talked it up, this is going to be awesome, and it turns out they were just really good at talking, like James.

But no, I wanted to say that. But look, always, for me in terms of when going external, Seek, believe it or not, is where I get techs from, and it's where we get good techs from. I don't find them on LinkedIn, I don't find them, probably my best hire was a guy I met out on the piss, because I think that's where you find people's true colours, and I bonded with this guy and then ultimately gave him a job. But yeah, look, for me, salespeople are different, I don't find good salespeople.

Oh, let's avoid it, that's a darker, people in sales, hey.

So, Luke, interesting, Luke actually, do you have any sort of tips about finding, because you've been going on a bit of a recruitment drive recently, right? So how have you been finding techs? And you don't have to go if you're not comfortable giving up your top secret recipe, that's fine.

Who was that, me, Jim?

Oh sorry mate, I didn't know who you were.

Yeah, I missed it as well.

Yeah, so, humbling again, as a small MSP, we don't have budgets and money to go and get really good techs, I'd love to, but unfortunately we don't have the money. So Ben, I spoke to you a long time ago, and you said what you guys have been successful with has been getting guys in that have fundamental IT skills and building them up and training them, and so far it's proven to be right, mate, to be honest. They've been loyal, they've learnt a lot, they work really hard for the business, so it's worked really well. And then when we need specialized skills, I talk to colleagues and find good skill that I can contract.

Okay. And that's sort of, for us internally at Hosted, like Aaron said, a lot of our techs, we started off planting at Seek and whatnot as well, and Whirlpool was actually, not so much these days, but I got some great techs back in the background, in the jobs section on there. But I mean, James, you mentioned McDonald's, and many of you will know Dylan Franke, who's our partner support manager. Dylan was a night shift worker straight out of TAFE, took him in as a level one, took him under my wing, and now he knows well and truly more than I know. But it takes time, all right. And what's that saying, Luke, hire slow, fire fast, that's it, yep.

But yeah, so any final words in terms of that?

Oh look, you know what, it's just secret sauce, secret sauce, basically. It's just a shaken up or left in your sun for a couple of hours.

No secret sauce, it's just hard work. Look at the helicopter view in business, right, don't get too drowned working in the business, work on the business.

Incident Management and Response Times

All right, fair. We've got a question here, and Ray, you were in our webinar the other day and I got told off afterwards for not reading the question out and only answering it, so firstly I'd like to apologize to you for that. But the question is, how do you manage response time and target resolution times as well, e.g. when a major event hits such as the Kaseya ransomware, how do you prioritize that versus day to day? Jim, I hope that's what you're actually asking for.

Oh right, sorry, too many names going on guys. Who wants to take that one?

So I know how we do it, but we've got probably more resources than others, but it's all about incident management. So security is a little bit different, but if there's a major outage, we assign one person to own that, so it doesn't impact the rest of the help desk. That person owns that incident, all of the tickets, all of the noise gets flooded through to that person, and they deal with the response and the updating of the status pages or emails or however you're managing your incident. Kaseya or that type of thing, we've had PrintNightmare, HiveNightmare, Kaseya, you name it lately, from a security standpoint, it's the same thing. Someone else owns a security hat, they're responsible for updating any communication. I've mentioned communication a lot, it's important, so we use Teams, we have an incidents channel, bang, it goes in there, that thread is continually updated on what's going on, that person is responsible for the internal testing and everything that needs to be done. If it's the type of thing where we need to emergency put out a patch or registry keys or whatever, we then, that person still owns it, but they might, we've got an automation person internally and that's their role, so they'll build out that stuff and push it out. So I know our processes, but we probably do have a little bit more.

Look, I'm actually going to throw, I'm going to ask you this one as well, because I've told you you should write a book about this a few times. What's the approach, and for those of you that don't know Luke, who's our operations manager, so he's all about our internal processes and things like that. So how did you tackle that within Hosted Network?

So what we implemented across several departments was what we call run sheets, or a runbook, playbook. It's generally been taken from other industries, but I was surprised when I communicated this in a couple of MSP groups, how much people in the industry just don't use them. And what they basically are is, look at what you're doing day to day from a sense of not necessarily projects and things, but the actual nitty-gritty, the stuff that you need to get done in order to move your position or the job forward a little bit, right. So for a help desk engineer that might be that they're having to check backups or tickets or whatever else it might be, and ticking them off, making sure that they're done before the end of the day, or before it kind of falls back, and prioritizing, like you know, they've got a P1 before a P2 and so on.

For that, that's right, yeah. Cool, all right.

And Jim, and this will be the last question guys, because we are 15 minutes over.

As I've come from a corporate type background and ITIL, we use our PSA ticket priorities as our main and automated escalation that we've designed into the PSA to escalate to myself if something's not dealt with in a timely manner. And response times are all catered for in the Freshdesk product and the PSA tool.

Yeah, okay. And James?

So 90 percent of what we find when we have an issue is it's usually a wider platform issue. So it might be, for example, it might have an issue with a VoIP provider, one of Australia's major wait providers had an issue yesterday, got us.

I'm trying to convince James to bring his voice over to us for a reason too, I'm good at sales, Ben.

You might be able to convert me, no extra account manager.

Okay, well I don't have one. Basically what I find is when we have a platform-wide issue, we literally have the guys as calls are coming in logging the tickets, but what we'll do is also, we've got a status page, and we'll keep that up to date, and we'll even write when we're going to put our next update up. So we'll say investigating, starting at midday, next update 12:15, and at 12:15, even if we've got nothing to write, we'll do nothing to report, still investigating, right. Regular updates even if it's nothing to report is what makes life easier and clear, and it stops you first from receiving 1,000 phone calls, because you know there's an email problem, it comes back to communication, right.

Correct, so many things, communication is the best, less is more, but just even just people knowing that you're working on an issue is 90 percent of it.

And you know, like, let's say phones go down, first thing that happens is my mobile phone will personally blow up from customers saying, oh, our phones are down, right, and all I can do is say check the status, check the status. One big thing is Status Hub is what we use, and we make sure that as we sign people up to products, we actively put them on that Status Hub page so that they're going to get the update SMS to their mobile phone, similar to what Hosted Network does as well.

So yeah, I think, to answer, are those ideal world times realistic, from that link?

Yeah, I think they are, I think they are, right. Maybe I didn't click the link, so that's all right. The target resolution time, look, that can be a target resolute, you can never give resolution, guaranteed resolution times, right, you can never give them, especially if you use that word, right.

Yeah, absolutely, don't use it, because you can't, a Microsoft outage, you can't, so no one uses guaranteed. But yeah, look, I think that's fine for a target resolution time, especially if it's critical, like hey, the phones are down, it absolutely should be an immediate response. So yeah, cool.

Well guys, we're 15 minutes over time, so I want to say a big thank you. Today has been absolutely amazing, it's been our first one, and an absolute pleasure to have you guys on our first one. So a huge, huge thank you. I believe Merrill has organised a little thank you to each of you, so stay tuned for that. Merrill, I'm just going to call on you, hopefully my screen is sharing, if you want to talk very quickly about our upcoming MSPs in Conversation sessions.

Yeah, absolutely. So we've got a couple that are coming up for the MSPs in Conversation series. The next one is actually going to be with Nigel Moore, so earlier in this particular session we spoke about The Tech Tribe, and Nigel will be joining us as well as a couple of our other MSPs, talking on smarter pricing, packaging and systems to increase your MSP's profitability. That'll be in a few weeks time, on the 18th of August. And we also spoke about hiring IT talent, that'll be for the next MSPs in Conversation later in September. There'll be a wrap-up email anyways from this session today with the links for the upcoming events. And hopefully we can see you online then. I really appreciate your time guys, and hopefully you enjoyed lunch and we were able to get that in time for this session today.

Well, again, I think that's meant to say thank you, but yeah, James has gone to the bathroom. Thank you so much for joining us today, as I said it's been an absolute pleasure having you guys, always a good chat. So yeah, until we get to catch up in person, thank you so much. All right, thanks guys, appreciate you guys. See you, Merrill, and see Luke, bye now.