Why MSP Success Is No Longer About the Tech: An Episode Review with Jeni Clift and Nick Clift

Welcome to MSP Mastery: Ctrl Alt Deliver Podcast, the podcast for MSP owners and leaders who want to build a better MSP; one that actually works for them.

I am Jeni Clift, joined by my husband and long time business partner, Nick Clift. Together, we unpack what is really working in thriving MSPs, including insights from the trusted partners who support them.

In this episode, we take a deep dive back into previous conversations to pull out the "gold" from our guest episodes. We revisit the wisdom shared by Guy Newton, Amy Baha, and Kultar Khatra. The theme for today is clear: technical skill is now just the baseline. What separates the best MSPs is how they create human connection, lead meaningful business conversations, and think about impact beyond the ticket.

Here is what we covered together:

✅ Human Experience as the Differentiator: Why how you make clients feel is what they actually remember.
✅ Context over Coverage: Why the "smartest" tech in the room still needs to ask clarifying questions to understand the business impact.
✅ Impact Beyond the Client: Understanding the "client’s client" and protecting the systems that keep their revenue flowing.
✅ The Art of the Ticket Close: How to ensure a client feels heard and satisfied, not just "notified" that a ticket is done.
✅ AI as a Door Opener: How to use AI to start strategic conversations without needing to be a developer.
✅ Culture Under Pressure: Real stories of how transparency and teamwork save the day when major outages happen.

We created this podcast to share the real conversations and lessons we wish we had more of while running our own MSP; practical insights from people who understand the challenges of this industry.

👉 Read more episode notes here: mspmastery.blog
👉 Watch the full video on YouTube: youtube.com/@MSPMastery
🎧 Listen on Spotify: MSP Mastery on Spotify
🎧 Listen on Apple Podcasts: MSP Mastery on Apple Podcast
📸 Follow on Instagram: instagram.com/mspmastery

Transcript

SPEAKER_01 0:00

Take the team leader there to the meeting. If they meet and they create a connection, gonna save you hundreds of hours over the next few years because they've got that connection. Your senior guys, do they know the partners' names? Create a human connection. We were drummed into this years ago because we were in physical contact with these people. You can't help but making a bond. The only dumb question is the one you didn't ask. Because you can be the smartest guy at your specific experience technology, but you know nothing about how this business operates or how that client.

SPEAKER_00 0:35

Welcome to MSP Mastery, the podcast for MSP owners and leaders who want to build a better MSP, one that actually works for them. I'm Jenny Clift, and alongside my longtime business and life partner Nick, we unpack what's really working in thriving MSPs, including insights from the trusted partners who support them. With more than 60 years of combined experience, we've seen it all from the first break fix calls to the sophisticated MSP tools of today. We've been early adopters of the tech and the strategies that shifted our industry towards recurring revenue at long-term success. Our goal with this podcast is to share the real stories and hard-won lessons that inspire and add genuine value to our industry, helping you build a business that is both profitable and fulfilling. This is MSP Mastery. Today's episode is one we love doing. Nick and I are on the mic, delving back into some of our previous episodes and exploring the key nuggets our guests have shared. So today, delving into the wisdom from Guy Newsin, Amy Babinchak, and Kulter Katra. I've given this episode the working title of Why MSP Success is no longer about the tech, because when I go back into these old episodes, I always find there's a theme. Every guest is coming at this from a different angle, but they're all pointing to the same shift, away from tickets, tools, and simply fixing things and towards relationships, outcomes, and real business value. It really breaks down into three key pillars. First, human experience is the true differentiator. Technical skill is expected, but how you make clients feel is what they remember. And second, conversations are what drive value, not just capability, because the real opportunity lies in stepping into strategic business level discussions. And third, impact goes beyond the immediate client with mature MSPs thinking past the ticket and even past the client and starting to focus on the outcomes that their clients are trying to create. And Nick, this is something that you always talk about, isn't it? That MSPs need to be thinking about what the clients need.

SPEAKER_01 2:55

Yeah, absolutely. And it's like it's just expected that everybody can fix the technical problem. That is not differentiator, that is not the issue, and that's not what your customers are paying you for. They're paying you for their team to be feeling empowered to do their work efficiently. And when they have a problem, they get listened to and they get the problem resolved in a prompt fashion without making them feel stupid or disempowered. And yeah, it's just a it's just a common theme that I've seen over the years. And it's the most successful, even if the really, really difficult technical problems that cause business impact, is if they're handled correctly and they're and the technician has empathy for the person who's logged the call and there's communication going between different management levels in that business, there's never been never in my history never been an issue. It's always as long as the communication's happening and we're really showing that we understand the impact and we're working on it and keeping them updated, it's never been an issue, to be honest.

SPEAKER_00 3:58

And I think it's about, you know, human nature is we want to be heard. And if we feel that our MSP is listening to us and understanding, then they are far more tolerant of when technical stuff is is causing an issue.

SPEAKER_01 4:12

Yeah, like if you're if you've picked up a ticket and you're a tech and you picked up a ticket and you're you're ringing the customer, and while you're kind of arse listening to them and blah, blah, blah, and you're logging into the RMM and you're logging into their machine and you're 100% focused on getting into the technical stuff of that problem and not listening to what they're telling you, they can pick that up. Like humans can pick up very quickly when they're not being listened to, even over the phone. That's even easier on a Zoom call or a Teams call, for example. And in real life, like actually physically there in the old on the old days, like in the 80s, when I used to carry a 20 kilo bag of screwdrivers and tools and bits and pieces to go visit the client, you you had to sit down with the client and and talk to them, you know. It was great. Because there was no no misunderstanding of how they were feeling and the impact of that issue on them. And I suppose a good point that the problem is when we we just don't know what's going on in that person's world. When you answer the phone from Mary, Mary says, Oh, I got I can't print this report, you think, Oh, it's just a printer. Like, she's just print it to another one. She's got the CEO standing behind her, waiting to go into a board meeting, and the pressure is enormous for Mary. So you don't know that unless you ask the question. So I've made the same mistake many, many times. Just go straight into fix it mode because that's what us engineers do, and you start fixing a problem. That's actually not the real problem. So it's it's just it's hard to do in the thick of it at the time, but you need to figure out how, in your business or your process or your individual people, how to get them, slow down, listen, ask clarifying questions, and then fix the real issue. Because sometimes we miss the boat. I mean, I remember an old story from when I was at Unicist days. I was the service manager, and there was we used to do on-site support for national bank branches. And yeah, there's two national bank branches in. Well, I didn't know this at the time. There's a bank I sent a one of my texts to, and I get a phone call from the customer saying, Yeah, where's Leo? Like he you said he would be here an hour. I go, Yeah, he's been there, he's fixed the problem. He goes, No, Leo's not been here. I go, what? Turns out he went to the other branch of the bank in that town and fixed the problem that had not been reported because the people were glad to see him. Oh, yeah, there's a problem with this machine over here. And he was da-da-da-da-da. So he didn't really read his ticket notes before he and then back in those days we had pages and it was like NAB Bank Mornington. So, you know, you can just assume that there's one, but there was actually two. So it's just take a little time to clarify what we're trying to fix here, and then fix it and make sure. Like my boss back in the time, Graham Robertson, I remember him, he was a great state manager, and he said, You guys are like cat burglars. You sneak in the back door, you sneak across to the machine, you try and fix the problem and sneak out without talking to anyone. That's not who we are. That's not what we do. And I that sticks with me to today because he was dead right. There's it's like a saying in Bali, like if you didn't have a photo, it didn't happen. Like if you didn't talk to the customer and explain what you did and how it's resolved the problem and confirm with them that the problem's resolved, then you didn't fix the problem. In their mind, they logged a ticket yesterday and I've they've still heard from nobody. Yeah, I I work with a number of MSPs and I log tickets with those clients to just test the system, and you'll be surprised how many. I've to be honest, in the last four years, I've never, ever, ever had a phone call from any of the MSPs that I work with. And I log tickets on purpose, right? So you know who you are. So it's all done through email, it's very distant, and maybe a chat to have a chat functionality, but I've never, ever, ever had a phone call. So it makes me wonder: are we building a society today where people don't want to talk to people?

SPEAKER_00 8:14

Okay, so let's get into Guy Newton. So one of our earlier episodes, and the thing that I really pulled out was exactly what we've just been talking about. He talked about customer experience versus technical outcome. So, like we said, fixing the problem is given. Like all MSPs can do that. But what differentiates, I think, the good MSPs is how the client feels during the journey. And this is what you were just saying as well that you know, we've got MSPs looking after us now, and it's all by stealth. So the problems get fixed, but we never actually speak to a person. So he talked about the tension between being right as a as a tech, you know, have to have wanting to feel that they're right, versus creating a good experience and navigating that balance is where I guess the maturity in an MSP shows. So the question I wanted to ask you is where do you think MSPs get this wrong? Why do so many teams still measure success by ticket closed instead of client satisfied? Because there's a to me, there can be a big difference between those two. Yes, the tickets closed, the issue is completed, the client doesn't know, or the client's feeling pissed off because they didn't feel heard, it took too long because you jumped in before I told you what was actually the problem. And the last part of that is how do you shift that mindset? How does an MSP owner or leader work with their team to shift that from yes, you're right, yes, the person probably doesn't have the skills that you think they should. However, you're the tech. You not only fix the problem, but support the customer through that journey.

SPEAKER_01 10:02

Yeah. What comes to mind for me is once again, it's just slowing down and reaffirming the question. So there's a couple of areas here. So let's talk about ticket closing because that's kind of one of the things. And it's been a you know, I go and work with MSPs and help them get their systems and processes sorted out. And one of the things that always interests me, I straight away I go to oldest ticket on the service desk. And when was the last action on the tickets? And you would be surprised in your own business if you went and did that. You would find a couple of tickets that are probably over a year old. And you're probably thinking, oh bullshit, go have a look. They'll be hidden in your PSA somewhere. They would have someone would have snuck them and put them on a board that nobody looks at because they just don't want to close it off. Because you know, one day I might figure out how to solve that problem that really doesn't matter. No one's complaining about it. And it comes back to in your business, what is your definition of a service test ticket as opposed to a proactive maintenance ticket, as opposed to a technology alignment ticket, as opposed to a project planning thing down the road. So to me, the definition of a service test ticket is it was working yesterday, it stopped working, I need it fixed, it's stopping me doing my work. So if you take that definition, you should not have a ticket on your service desk older than two days, right? Because someone can't do the work. Seriously. And if you actually ask your text, how many of your clients can't do their work because of a ticket we have, they're gonna say none. Because we are really good at solving the immediate problem. What where we're not so good at is making a decision on what to do next. And that's why you have these people called ticket hoarders or as John used to say, fondlers. You know, people will fondle their tickets, oh, but yeah, I fixed the problem, they're happy, there's no issue. But yeah, maybe I could change the color of the icon in the left-hand pixel of the TV in the meeting room that they use once every six months. No, that's not a service desk ticket. And then when the VCIO or the owner has the quarterly meeting and they look at the ticket stats, the customer goes, Why have I got tickets that are over 200 days old? And you don't know the answer to that because you don't think they are either. And but this is this is a whole sorry, I'm rabbiting on a bit here, but that's what I do. It's about your definition and being very, very clear with your team as to what you expect to have happen. And ticket closing is a challenge, right? I met a guy that I worked with a few years ago, and you know, we talk about ticket surveys, right? So there's a way to gauge customer satisfaction. And most of the PSAs, if they don't have the function built in, there'll be a bug on product that you can send a quick little survey to a client when the ticket's closed. And it, you know, in my experience, the simplest thing is sad face, black face, smiley face. Three. You're happy, sad, and realistically, people that survey you are never going to pick the middle option because they just don't survey. So you're either going to get happy faces or sad faces, and and you're probably gonna get five to six percent of ticket close surveys sent out responded to. Now, one very entrepreneurial MSP decided in his uh system to put a workflow in that the ticket never got closed until the survey was done.

SPEAKER_00 13:19

How many thousands of tickets were open?

SPEAKER_01 13:21

Not none too many, because the way the workflow worked is you the ticket went to resolve, and then a survey was sent to the client saying, We believe we've solved your problem. Please confirm, click. And it was it was not worded as a survey, it was worded as a confirmation of ticket closed. Then there's a secondary part of it, which was yeah, we where you're happy sad about the experience. He got his surveys up to 95%. I thought it was super smart. Anyway, but anyway, that was just a little anecdotal story. But there's different ways of using surveys, but how do you close the ticket off? Yeah, there's no right or wrong way. We had lots and lots of different clients that had different expectations, and in the end of the day, we have to have a discussion with the client and decide what works best for their business. A lot of our bigger clients had what we call a point of contact where there was one person that basically kind of monitored the tickets from the client side and that the individuals would log the ticket, but that person would be the kind of ticket coordinator on the site. And if they if the survey went to the ticket coordinator, it would never ever get done because the ticket wasn't for them. So you have to be careful you have the right context and yeah, and figure it out. Like, do do people do you want your does the client want their team members physically spoken to to confirm that the ticket is closed off? Is it just an email? Is it just a closed ticket? So there's no right or wrong answer to this. It's a it's uh working with your client to figure out what works. And you know, like I haven't been actively running an MSP at the service desk level for a few years now, but my impression is that people don't want to talk on the phone anymore. You're gonna get a much more interactive feedback if you have something that pops up and says, hey, your tickets closed, were you happy? Do you have any questions? Can we close it off?

SPEAKER_00 15:20

And I I find that living here in Bali, but you know, we're still Australian citizens, you know, all of our banking and our businesses entities are all still in Australia. So for me, if I can do a chat to get a problem resolved, because you know, we're two to two or three hours behind Australia, the East Coast, depending on daylight saving. So the timing may not work. You know, I'm doing other things, so it's easier to just you know watch and and conduct a chat with somebody than ring, sit on hold, often not get the problem resolved, and then have to ring back or do whatever. So, you know, certainly for me, the chat works better. And I and I think a lot of people feel the same way that, you know, if I ring, am I gonna get on hold? You know, what's the process where if I can just do this by chat, I can continue to do other things and and I guess sort of you know continue on with what I can do while I'm getting a tech problem resolved.

SPEAKER_01 16:15

Yeah, and it's it's it's not it's not black and white. You've got to work with the system and your customers to figure out where you want to be and how you want to do it. The most important thing is just doing a regular physical meeting with the client or ringing a few key contacts in your clients and just ask them, hey, how's it going? How are you finding our service desk? Are we responsive enough? If there are any issues happening, that's more, you're gonna get more gold out of those conversations that you're ever gonna get out of ticket survey. I think the original question is what makes a modern MSP effective at the client communication? It's it's figuring out what works for them. I mean, if they've got a bunch of under 40-year-olds in a high transaction, high pressure environment, they haven't got time to talk on the phone. They haven't got time to respond to an email. They probably don't even have time to click a button. So for that particular client, there may not be any process that you're ever going to be able to circle back and 100% confirm that the problem's solved. Or you can say to that customer is have a chat to them, say, look, this is the process we're gonna put in place. We're gonna auto-close the ticket. We'll send one, two, or three email reminders from the ticket. If we don't get a positive response to those, we're gonna close the ticket off, which is fine. All that all you have to do is tell your staff is if there's a problem reoccurs or they're not happy, just reply to that email. It'll automatically open the ticket up. We'll put it in as a higher high priority ticket back in the queue, and we'll contact them and resolve the issue. There's no point, you know, if I go and look at a service desk board and there's 30% of your tickets on waiting on customer. Okay. So if the customer's not getting back to you, that means the problem's resolved and they don't care. Or you've closed the ticket and they're not going to answer. So you need to figure out in your business what works for you. Yeah. And and for us, we had we had this we had carefully crafted three consecutive messages that went out and were friendly and helpful. And and then we put that in place, and one of the hospitals said, hang on, we have a lot of part-time staff. So three business days is not enough for us. And you change ours to be seven business days. And so we did. But you've got to start somewhere and have the conversation, that's for sure.

SPEAKER_00 18:25

That was then that auto-ticket closing. And we had good feedback on doing that. So it was still, it was working with the the customer to get the experience right, which is where we started was, you know, fixing the tech versus actually, you know, having the customer feel like they are looked after. So let's talk about the next part. And again, this was Guy talking about this and and all of the the four episodes really about thinking beyond your customer to their customer and understanding the impact that tech outages or issues have on your client, but also how that flows on. So, what does it look like in practice to care about your client's customer and how can an MSP genuinely influence that next layer? And I'll start by sharing a story. I'm sure we've said it before, that we got one of our clients in, newish client to the business. We were running a strategy session for our staff, our team. So we got that client to come in and share a bit about his industry and the tools and what were the critical tools. And in this case, it was an insurance broker. And for them, the quoting tool was critical. If that was down, and if you think about it, you bought a new car, you need to get insurance, you ring around to get three quotes. If they can't give a quote immediately, they're not going to get that deal. They've lost that deal. So that for them was number one. Hospitals we looked after, it was their patient, you know, the call button. If that doesn't work, literally somebody could die. So understanding that. So as an MSP, yeah, how how do we influence?

SPEAKER_01 20:10

Yeah, it's interesting because it reminds me, we did a lot of work with hospitals, councils, and commercial stuff. And for a council, the most important system was email, not payroll, not finance. Like when I had these discussions with CEOs and finance directors and said, payroll's not a problem. And we'll just pay the guys the same as we paid them last week. We just go to the bank and do a transfer, yeah, it's not an issue. And all their internal systems, yeah, whatever. But communication, because they're a they were a counsel, the email, and I said, Oh, okay, it's really interesting. Because if you go to the insurance broker, for example, they didn't give a shit about email, really. Like email was a their quoting system sent quotes out directly. So yeah, it's really interesting. So that is what you said, Jen, is that is the key. Understand your client and getting the client, or at least your account manager, VCIO, whoever it is that looks after that client, to give a presentation to your team to explain the impact. Another example I can think of is we have a client that is in the transport industry and a ticket comes in, uh, printer's not working. And we have printer not working all the time in hospitals and councils, and then you just go to another printer, right? There's 20, there's 20 printers in your site. Like, yeah. And the tech that picked it up was used to that. So he didn't give it the priority, right? Because he thought, ah, printer's not working. What's your problem? And I just didn't even answer that ticket because he had other things that were more urgent. That printer was a logistics label printer that stopped the trucks leaving the warehouse. And I got a phone call from the boss of that company and said, What the hell's going on? And said, I'll let me check. Oh, yeah, I see. We've got the ticket. Yeah, I'll I'll make sure one of the senior guys gets on that straight away. Oh, thank you. And went and had a chat to the teams. What happened here? Oh, well, it's just a printer. Like it's just wouldn't they just print to another printer? No. So they made an assumption out. Guys made an assumption based on lack of knowledge for that client, what's important to that client. So, yeah, absolutely. Digging into the client. And hopefully in your MSP, you've got, you know, more than one client in each industry, line of business. So you can group them together and say, hey, these are their professional services clients. What's important to them? And then back the other way to help get them a really good experience for your clients' clients is understanding how they interface with their clients. Is it through a web portal? Is it through email? Is it through an application? And then having a strategy for those products to back them up. So I always use analogy, especially when we're doing a lot of disaster recovery plans back in the day. There's a disaster recovery plan and then there's a business continuity plan. Two different things. So the disaster recovery plan is your building's burnt to the ground, all your IT's gone. We need to get you back up and running, right? Without loss of any data up until the point where it's a disaster happened. That's a recovery plan. But meanwhile, your business is dead for a week, a two weeks, a day, whatever it takes to get it going. That's not business continuity. Business continuity is having an alternative to your systems, critical systems, a plan B, and not just having them, but actually testing them. And in the modern world, everything's cloud related. Everyone thinks, oh, actually, there's no problems. Yeah, well, what happens if the cloud's down? What happens if Microsoft has a Office 365 M361 have a fit? What happens if CloudFit has a DNS fit? Half the websites in the world go offline. You know, they have multiple carriers and multiple different ISPs with you know load balancing, and there's a whole lot, and I'm not going into that today, but understand your client, understand their client, how they interface with their clients, and how can you help mitigate the risk of critical system failure? This is where you're adding super value to your client, you know, because they know you can fix a PC, they know you can fix a printer, they know you can fix a website down or a whatever. It's about preventing the problems. That's the modern provider's job for sure.

SPEAKER_00 23:59

Okay, let's dig into Amy Babanchak's episode. So the first nugget that I pulled out are and Amy's she's this is her her soapbox, I think, are about the conversation, you know, beyond the tech. So most MSPs, like she said over focus on tools, KPIs, tickets, but that long-term retention comes from deep business conversations. And without understanding, and we're just talking about these client goals, you can only ever be reactive. So the question what's the real reason you think MSPs avoid those deeper business conversations? Is it a skills gap, confidence issue, or just maybe bad habits?

SPEAKER_01 24:46

To be honest, I don't think it's any of those. I think it's the pressure to do the next ticket. And if I think about the clients we work with and over the years, and it depends what who who's accountable had to have the conversation. If it's per ticket, it's absolutely the person doing the ticket. But when you're solving a ticket for an individual in a business, you're not having your headspace is not in the solving any bigger problems in that business. So you've got to be really clear who should be talking to you. And I I remember back in the 2000s and up to 2000 and probably 10 or something when I was a frontline accountant, you know, VCO. If I I drove a lot, right, in the in the country areas, I would be constantly, I had a speed doll of all my important customers, probably 15, and I would just go tick, have a chat for five, 10 minutes, chick, next one. And I would be talking to my customers all the time. So I knew what was going on in their world. And due to a whole lot of things, it's just humans have stopped doing that. I don't know really why, but we in this day and age, we haven't really done that. So, how do you replace that conversation? And that's where Amy was coming from, is like the deep conversations make for awesome customers. Like we had customers for 20 years, and it yeah, and in those customer bases, the people we dealt with changed regularly. Like every three to four years, there was new people coming in. But we had enough conversations with enough people that we had the continuity to be the constant that we're in and out. And you can't do that on the service desk. You've either got to have a really strong VCIO strategic business review, do the quarterly, six-monthly review, but even in between that, just having a conversation. Can your senior guys do they know the partners' names of the key people in that business? Do they know their kids' names? Do they know what sport they play? Do they know what their favorite video game is and yeah, whatever their favorite Netflix series is? Like create a human connection that doesn't happen by accident. We we were drummed into this years ago because we were in physical contact with these people. You can't help but making a bond. But now that it's all done behind a screen and sometimes not even behind a camera, it's literally behind a screen and you're on a phone call, it's really tough to build those relationships. So those quarterly in-person meetings with clients are super important. Hey, take the team leader there to the meeting. Like, yeah, it'll cost you half a day or whatever out of production and closing tickets, but if they meet and they create a connection, gonna save you hundreds of hours over the next few years because they've got that connection.

SPEAKER_00 27:16

So And client retention too. It's much much easier to keep a client who has a personal connection. You're effectively friends because you do know their kids' names, their dog's name, you know their favorite video game, as you said. It's much harder to move away when you've formed that connection, that bond, than I don't know, my I've got an MSP, but I don't even know what any of them look like.

SPEAKER_01 27:40

Look, I I remember a customer I had and he he loved me to he was a IT manager and he loved me to come over and do a site visit once a month because I'd buy him lunch. You know, I was allowed to do that. But it's just and it cost me like 20 bucks or 10 bucks or something.

SPEAKER_00 27:53

It's not oh with inflation now it'll be 70, but you know, and $140 in fuel.

SPEAKER_01 27:58

Yeah, but it was during the day, so we would have a Coke or a soda or something like that. We weren't bloody getting smashed on a bottle of wine or anything. That was a dinner, but that didn't happen very often. So and I I get back to your original question. I don't know that it's a skills gap. Because if you're if you know your people and your team, you shouldn't have people in your frontline facing roles that aren't people people. There are roles for those, and we call that in the EOS journey right person, right seat. There are roles for non-people people, super techos that are detailed oriented, but they're not frontline customer service people. So I think I think it's more permission, like the pressure of their role. You know, we were guilty of this. We would put pressure on guys and start monitoring how long they're on the phone and how many minutes they spend on a ticket, and then we quickly drop that because it was about happy customers and total hours spent on the client versus how many hours on an individual ticket, because you could spend an extra half an hour on one ticket that solves five other tickets coming in. But if you're put the guys under so much pressure to get that ticket done in there in the average of the 15 minutes that we all aim for, they may just do the band-aid, move on, and then that same problem pops up. But and then taken at another level, if that problem's happened five times here, who in your organization is looking for that same problem across your other clients? You know, and that's the whole this whole proactive model what we're talking about. And it's just so many people get stuck in just the doing, and there's so much pressure to go to the next ticket, next ticket, next ticket. We don't take the time to stop the next ticket coming in. Yeah, and lead by example. Like you've got to get out there and go see your clients, take your text with you, you know, teach them how to look someone in the eye and shake their hand. They won't, no one would have taught them that.

SPEAKER_00 29:42

Yeah. And we found that with our trainees, a lot of the time they just didn't have those basic professional communication skills.

SPEAKER_01 29:50

I thought anyone born after 2000 would not know how to meet someone new professionally in a business environment. No one would teach them that.

SPEAKER_00 29:57

True, very true. Okay. The other thing that Amy shared that I really liked was around AI, as AI as a door opener for strategic conversations. So clients we know are confused and concerned about AI. Amy's comment was that this is a massive opportunity for MSPs to take the lead, not by being developers. So we don't all need to be have an AI team and be creating all of these tools, but simply by guiding the usage, alerting people to the risks and strategy. So the question is, how can MSPs use AI as a reason to start strategic conversations without feeling like they have to have all of the answers?

SPEAKER_01 30:43

Good question. That's funny because we were in a session yesterday with an MSP, and that exact question came up. And I think it was a good discussion. I think we landed in the right spot. Need to be aware of what the basic level tools are. If let's be honest, anyone using a keyboard has to be engaged in the AI journey. Otherwise, they are going to become irrelevant going forward. It's as simple as that. They may not be replaced, but they'll be just be irrelevant. They'll get forgotten about, they'll get put in the corner. And when the role they're doing disappears, they're never going to be on anyone's radar to promote or to move to the next level. So everybody's got to be using the basic tools. And that means if you're a Microsoft shop, you've got co-pilot and you're kind of, you know, you've got it running and you're transcribing your meetings. And don't just ignore the transcribes. You've got to go back and read them and learn how AI does things. Then you learn how to have better conversations in those meetings to get the transcripts to be useful. And they're the kind of things that I think the basic MFPs can help their clients with. And the going to the next level is packaging up however it works for you is a bit of an education piece. There's yeah, 90% of the traffic on the internet now is about AI and AO, this and that. And there's I'm guilty, I've probably spent a thousand hours watching a bunch of podcasts and YouTube's about trying to come up crack this nut. And I've done a lot of research on it. And I think for the average small to medium business supported by an MSP, their first easy enter step in is about co-pilot. It's understanding just the concepts, what to do with it, how to secure it, how to educate your team. Doesn't mean everyone needs to have the full top-level pro license, but understand that the free licenses are limited in their capability. And then I'd say after that, if you're more advanced, you'd probably go to something like a Claude Teams or something like that, where you can actually start to do some automations. But I wouldn't even think about automation, start the conversation. Because and if you're not talking to your clients about it, somebody else is.

SPEAKER_00 32:44

Somebody else will be, or we'll be trying to get in that door. Yeah. And I think policies is another really easy conversation to have with your clients, making sure, you know, provide them some templates of those policies and procedures around A, what can people do, what can they not do? Because B, you need to help them protect their IP and their business.

SPEAKER_01 33:08

And like even with you know, Jen, you and I, we use AI tools to help us with content, no, no, not narration or something, like just research and that kind of stuff. And the results are quantums apart depending on how you ask the question. And AI has gone past just a chat tool that you ask a question, it gives you an answer back. Because it's basically a pattern matching at that level. It's it's looking for the patterns in your question. So the more detail you give in your question or your state, I'm not going to go into a full lesson here, but basically a context statement, like what am I, where am I at, what am I doing, what am I trying to achieve, then a statement of what the output you want, and then the actual question of what you want the AI to go find out for you. If you can think in those three ways, the output is quantum is better than just, oh, what's a good tool to manage DNS? It has no context of who you are, what you're doing. It doesn't know if you're running an ice cream shop or you're running a multinational telco. You've got to think logically. And they're the basics I think that MSPs can help their clients with. There are lots of tools out there that can help you do that.

SPEAKER_00 34:10

But the other thing we talked about too was you know, potentially getting offer your clients some workshops for your team. And you don't even need to run those if you've got an MSP and you don't have anybody in your team. Find somebody and, you know, package it up as a, you know, we're running a workshop. It could be a virtual one, running a webinar. And and, you know, if they're clients, then it's a free thing. But that's a potential marketing tool as well, because there's lots and lots of people out there who've got that knowledge. Look for the ones who have that, the ability to run a workshop, the ability to connect and run something that people won't go to sleep. But you know, there's some really simple things I think that we can do as MSP owners that add value and will place you as having some knowledge in the AI space.

SPEAKER_01 34:56

And I my last piece on this would be if you're running an MSP and you understand the potential and you want to help your clients, you have to lean in yourself. You have to give your team a paid subscription to a tool and do the work internally to train them and get them to use it and have a weekly, monthly AI conference or whatever you want to call it, committee and get them to come up with ideas and show things that they've done. Because and you need to have someone in there that does wake, literally wake up at three o'clock in the morning going, oh my God, we can do this. Because you need to have that passion. And if you don't, that's completely fine. Outsource it. Go find someone else. There's plenty of just AI-only studio designers out there at the moment, or what do they call them? Agencies. Yeah, agency is the right word. Go find one of those, partner with them and work with them and introduce them to your clients. Under your banner, you can white, you can white label it, or you can just do a straight intro or whatever. But you've got to have a story. You've got to have a strategy. You can't just stick out in that's just like cybersecurity was five or six years ago. AI is the new side, everyone assumes that every MSP now is dealing with cybersecurity. Not really an issue anymore. Now they're worried about AI. So you've got to have a strategy. And it is the perfect opener.

SPEAKER_00 36:10

Oh, absolutely. Yeah. Okay, so Kultar Cartra's episode, he talked about culture and how the team behaves, particularly under pressure. So making sure that as MSP owners, we're embedding that empathy, communication, and internal accountability that ensures when things go wrong, because they do, the team responds with calm confidence, which then builds trust with clients. So my question is tell us about an ex or share an experience with us where you've seen a really strong culture come into play when things are under pressure, when something's gone wrong.

SPEAKER_01 36:52

Yeah, well, there's one example that is really good. One and we had a medical clinic, and we had a the technical people out there, we had a single ESX host, and we had a single dato backup appliance and a single internet connection. We use the word single, single, single. They're going back to earlier in this podcast where we have a disaster recovery plan versus a business continuity plan. And uh I was a and I still am a firm believer in the in the datto B C DR device. And what happened is as the gods and the sun spot activity happens, you always have three hard drives failing a rate array out of six at once. Never ever won. I think we had one fail, and by the time we got a tech on site, the second one had already gone and the whole thing was gone. Say great, no worries. We've got the disaster recovery appliance on site, no problems at all. Fired all the servers back up on that, no problem. Customers in and running. It was a bit slow, like obviously. Then the hard work started because to do the recovery, we had to involve the vendor to get the hard drive fixed in the server. That took a couple of days. Then we had to do the recovery, but what we discovered is the I.O. on the getting way too technical here. I'm apologize. But basically, the bandwidth on the disaster recovery appliance was not great enough to run production and do a recovery at the same time. That was the the real. So we go, well, we're stuck. How do we fix this? So I had my engineers working on it overnight. We said, well, could we can shut production down at night and we can do a recovery? And we did that for a few nights and we were getting one server back online into the and it was like a nightmare. So we were talking with the guys at Data and they said, hey, why don't we spin all the servers up in the cloud DR and let the appliance offload it from the appliance, then you can recover the appliance locally. We tried to do that. The internet wouldn't work. It wasn't having enough bandwidth. So we had to involve a third party, the provider. And say the the moral of the story was everyone pitched in. We got extra bandwidth allocated to that client or a month's period so we could do this recovery. We had some in the cloud, some on the appliance, some on the hardware. And at the end of the day, the customer didn't lose a skerrick of data or a minute of probably had an hour of downtime, but it worked really well. So the site engineer, the guy took the ticket, he put his hand up straight away. Oh, we've got a major problem here. This server's offline. Oh no, this one. Oh, they're all offline. So the senior guys jumped in, worked, they all work together really well. So that's one where a place where I'd say it's an extreme example, complete site down, where it worked really well. And we had multiple partners and our team working with vendors and other providers, really good result. On the flip side, is when the culture's not great.

SPEAKER_00 39:28

So if we dig into that one, it was about teamwork and communication.

SPEAKER_01 39:31

Yeah, 100%. And all constantly through that, I was talking to the customer. All right. So, you know, at that point I was still VCIO for all my clients, and I was constantly out. But I appointed a senior guy as the daily contact. So we had a daily meeting at the end of the day with the client and with our vendors and with myself and our project senior engineer. And it was smooth because we had that culture of transparency, is probably what you really want to have. Yeah. Own the problem, be transparent, and communicate. On the flip side, there was a background issue where there was a problem with backups on the customer site, and they were taken forever and ever and ever. And it wasn't really impacting production. And I didn't know about it. One of the guys was working on this problem and they kind of kept it to themselves. And I think it took two months and they resolved the problem. But the customer had had a problem for two months, and it did actually impact production as well, because it was just slow. Getting data in and out of this database was slow. And yeah, they'd logged a few tickets about it, but the guys had kind of written it off as a Windows update or something like that. So they they kind of there was a complete opposite. Like the tickets were dealt with as an individual issue. No one joined the dots. That the backup was really, really, really slow, and the backup was running into production the next day. So that was impacting the performance. And then those tickets, people would log tickets saying they're the application's slow. And then no one joined the dots. The service desk wasn't talking to the project guys and with the whole thing. And it took months to resolve. In the end, it was a that was a switch problem, network switch bring switching problem. Fix that, everything got fixed. But that was the complete opposite because that was a the teams weren't talking to each other. So I think ultimately to get a the good culture you want is a daily huddle where people are open and they say what's going on and they're not afraid to ask for help. Like I always say the only dumb question is the one you didn't ask, because you can be the smartest guy at your specific experience technology, but you know nothing about how this business operates or how that client. And I I had that example, I've probably shared it before where one of my senior engineers, really smart guy, new to new to us, about three months in said, working on a problem. He goes, Oh, seriously, what idiot set this up? This is like crap. Yeah, well, that idiot would have been me. And at the time when we did that three years ago, that was the right way to do it. And you kind of went, oh, what was it? So I said, mate, you have to be really careful. Lucky it was me and not one of my other project guys, because then you guys would have not had a good relationship for a long time. Said I can wear it because you know I'm the owner, so blah, blah, blah. But and he learned a hard lesson on that one. He said, There's multiple ways to do everything, and nothing is ever perfect. So that culture of not being the perfectionist that done is better than perfect, and being open and sharing. The worst thing you want in your business is what I call knowledge hoarders that kind of think their job security is based around the more they know than the other guy.

SPEAKER_00 42:25

And protecting that knowledge, yeah.

SPEAKER_01 42:27

And yeah, and that hopefully that doesn't happen in the modern world because nobody's got that much knowledge now. Just go ask Ford or ChatGPT or something that's got more knowledge than you. And because they have every single manual from every single piece on IT tech ever known to man. So no one can say they've got more knowledge on a product anymore because everyone has access to all the knowledge on all the products. It's just how you use that knowledge, is where the experience comes in.

SPEAKER_00 42:52

So I guess what what I took from that is the th is three things: transparency and communication. And what was the third one? Teamwork. Everybody working together. Thanks, Nick. Great to have these chats. I really enjoy, I guess, sort of digging a bit deeper into these episodes after uh after they've gone to air.

SPEAKER_01 43:11

Yeah, and it's great for me because I get the questions make me think back to things that we've really done and experienced and learnt from over the years. And that's the purpose of this podcast is to get people on and and share experiences. We're not doing anything hypothetically or theoretically, it's all shared experience, and that's why we really want to broaden the range of guests we have on there. And I'd love to hear from anyone else out there that's got any stories or has got a really cool thing that they've achieved in their business over the years that they think would help the community. And yeah, just reach out on on LinkedIn or nick at tenassia.com, check out the podcast at mspmastery.blog, and yeah, share, share the love. We love it, and it just brings back really good memories of of what we've done in the past and are happy to share.

SPEAKER_00 43:57

And as always, thanks to you, our audience. If this conversation hit home for you or got you thinking, as Nick said, head to mspmastery.blog and keep the conversation going. You'll find all our episodes there and more wisdom from the peers and partners who are shaping the future of our industry. And make sure you subscribe so you don't miss future episodes. We've got plenty more great guests and stories coming your way. Until next time, this is MSP Mastery.