The Process Pillar – How to Build an MSP That Runs Without You

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 continue our special three part series exploring the pillars that shape every successful MSP.

Part two is all about Process.

Without solid, trusted and simple processes, an MSP cannot truly scale. Owners remain caught in daily operations, technicians are left guessing, and every new team member or offshore resource creates more pressure rather than more capacity.

Nick and Jeni share honest lessons from their own MSP journey, including what happens when you outsource a mess, rely on knowledge that only lives in someone’s head, or overload your team with documentation that no one actually uses.

Here is what we covered together:

• Process Creates Freedom: Why clear core processes are the pathway to consistent results, greater capacity and an MSP that does not rely on the owner for every decision.
• Do Not Outsource Your Mess: Why offshore support fails when your processes, client information and internal workflows are not documented clearly first.
• The Three Layers of Great Documentation: How to build a simple structure using high level process flowcharts, practical checklists and detailed SOPs or technical documentation.
• Documentation Needs an Update Process: Why documentation becomes useless the moment your team stops trusting it, and why every person in the business needs to take responsibility for keeping it current.
• Your PSA Should Be the Source of Truth: Why your PSA, RMM and documentation systems need to work together, rather than creating confusion through disconnected tools and duplicate information.
• Triage Sets Technicians Up for Success: Why a ticket should be correctly categorised, checked and linked to the right information before it reaches a technician.
• Stop Making Technicians Guess: How poor ticket triage, unclear workflows and missing documentation waste technical time and create a frustrating experience for both the team and the client.
• The 20 Per Cent That Matters Most: Why you do not need to document every rare task in the business. Instead, focus first on the core 20 per cent of processes that cover 80 per cent of your daily work.
• Tool Consolidation and Simplicity: Why adding more tools does not always improve your MSP, and how getting more value from the systems you already use can reduce complexity and save time.
• Guardrails Create Ownership: How delegated authority, clear limits and defined decision making parameters help team members act confidently without constantly seeking permission.
• Building an MSP Manual: Why documentation is not about turning people into robots. It is about giving people the clarity, confidence and guardrails to deliver consistent work while still bringing their own personality and problem solving skills.

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: https://mspmastery.blog
👉 Listen on YouTube: https://youtube.com/@MSPMastery
🎧 Listen on Spotify:
https://open.spotify.com/show/4gftErFYrR8F80kthgvFbs
🎧 Listen on Apple Podcasts:
https://podcasts.apple.com/us/podcast/msp-mastery-ctrl-alt-deliver/id18281057
📸 Follow on Instagram:
https://instagram.com/mspmastery

Transcript

SPEAKER_00 0:00

If you don't have a process on how to update the process in the documentation, then you're going to get random stuff and people are going to look at it and go, That's wrong. My view is documentation should be fed from the PSA. The RMM should update the PSA and vice versa. 80% of the work is covered by 20% of the processes in your business. Make sure that 20% is down pat. It's absolutely stuff you do every day, day in, day out, day in, day out.

SPEAKER_02 0:32

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 60 plus 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 toward recurring revenue and 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. Here's Nick, myself, and today, no special guest. We are running with part two of our special three-part MSP Mastery series, where Nick and I are delving into the three pillars that shape every successful MSP. Part one was people. Part two, today's episode is process, and part three is mindset of a leader. Across this series, we're sharing lessons from decades in the industry, challenge some common assumptions, and explore what really drives sustainable growth and success for MSP owners and leadership teams. Today, Nink, we're digging deep into process. Now, we know that without solid processes, an MSP can never truly scale, and the owner can never truly step away from the daily operations. I'm not saying that we're both good at following processes, but we know the importance of process.

SPEAKER_00 2:27

Yes, I was gonna say I have a bit of a love-hate relationship with processes. I like the concept of them and I like following them, but I'm not very good at writing them. Well, I don't really like following them either. It is true to get consistent results and be able to free yourself up, you need to be having the core processes. Not every single thing, but the core stuff, definitely documented in a simple, reliable fashion.

SPEAKER_02 2:50

Yeah, and the AD20 rule. The process consistent and clear, but still leaving some room for people's personality and the humanity to shine through. We're not creating robots.

SPEAKER_00 3:02

Ah, definitely not. And I have my theory on what good documentation looks like. Happy to share that.

SPEAKER_02 3:08

Nice. So today we're going to unpack how to move from chaos, which we were pretty damn good at creating chaos in our day, to consistency. Just the two of us digging into why process is often the missing link between a job and a business. And as we do like to say, process will set you free. So let's start with Alan Mitchelmore, CAD32, and James Vickery, episode number 10, around offshore failures and was it process or was it person? And what they both said is that offshoring doesn't fail because of the location. It fails because the MSP really outsources their mess.

SPEAKER_00 3:57

Yeah, 100%. We did that a couple of times. Back in our first attempt was uh a couple of Indian offshore places, and it wasn't a dedicated team for us. It was a basic we outsource tickets. And because those internally for us, even our own process and had to deal with the particular clients was not fully documented, it was really difficult to get that process to work. So we would tee up 10, 15 tickets to be done overnight. And in the morning we'd come back with 10 or 15 tickets with a little tiny bit done and with a question, what do I do next? Where do I find this information? How do I do this? So it became very clear that to do that successfully, we need to have properly documented processes. Absolutely.

SPEAKER_02 4:40

And it was hard enough for our own team onshore to follow what little bit of process and procedures we had in place, and then trying to offshore that in those cases we didn't even have dedicated resources, as you said. So each time a ticket was allocated, it was a different person. So they didn't know us, they didn't know our systems. It was just a nightmare for them, probably as much as us. Because if the process is in the owner's head or maybe a senior tech's head, and then pushing that to any resource, but particularly one offshore that lacks the local cultural context, it just doesn't work. And we tried it twice. And after the first time it didn't, we tried it a second time just to make sure that it didn't. And we were right.

SPEAKER_00 5:24

Yeah, even today in our new modern MSP world where we've got advanced tools, etc., they don't work unless you know how to utilize them consistently. And with every tool and platform, there's an infinite number of different configurations and processes. And just saying, I go watch the vendor videos and then you'll be on board and you'll know everything about how we operate here. That is so not true. Even just the basic setup of the PSA and how you onboard your own staff, your own team members, to use the tool. It's particular to your business and the way you operate. MSP A and B are completely different to C and D. Process to me is the three-tiered system. Like we learned through our journey through EOS and our multiple businesses that you have a high-level process flow chart that explains a process, whether it's onboarding a new team member, onboarding a client, project management, the ticket workflow. At the very high level, it's a flow chart of the journey along the way. Then each section in there has a checklist on what needs to happen at that part of the process. And then underneath that, you've got your detailed SOPs or standard operating procedures, technical documentation, vendor reference material. So when you first start, you're looking at everything, right? You're looking at the flow chart. How do I do this from end to end? I'm looking at all the checklists of points I need to do along the way. And then I'm also looking at all the documentation underneath that because I don't know how to do this before. I need to learn how to do it. As you get better, you just need to use the checklists. And when you're creating a sales quote, for example, once you've done the first 50, you don't even need to look at the checklist anymore. You just follow the flow through. And then it's just a reminder to make sure have I done all the right steps and on our way through. So that is a challenge. At Otto, we ended up getting our documentation into that format. And we had the documentation was a website with a flow chart. You click on each part of the flow chart, it dropped down the checklist, then it linked off to the documentation. I think it was in AT Glue or Confluence or something that detailed SOPs. But the tools change bits and pieces, change vary between MSPs, but the fundamental of what's this process trying to achieve? What's the start? Where's the end? What are all the various steps along the way? Then how do we measure success in those steps? Then how do we actually do the work? The three main parts. So just do that and it'll be easy.

SPEAKER_02 7:50

Just do that and it'll be easy. It sounds so simple. You said about bringing somebody in from another MSP. It's so true that just we did this, I don't know how many times, you know, we've employed this person, they're highly skilled tech, they've got years of experience, they should know. And they didn't. And I'm sure we burned good people in that process of not actually teaching them, as we used to say, the DWM way. You have to onboard them properly, set them up for success. I remember when I was in that sort of finance role and all of our team had credit cards because they're on the road and they used to have to buy fuel or pay for accommodation. I would go through every single one every month because we hadn't introduced them to the tools that we use for certain things. So they'd gone subscribe to their favorite. So now we've got a whole different something else. And that was on us. It wasn't on them. If you don't teach them how you want things done, then that's on you.

SPEAKER_00 8:46

Yeah, definitely. And going back to one of the core EOS principles, which is keep it simple, simplifying things down to the core main topics that you need to document. We need to have an accepted level of base knowledge. You're not going to work in an MSP if you don't know what a ticket is, for example. So you don't necessarily need to send an engineer or a technician or a project engineer to go and watch 40 hours of vendor onboarding videos, that is a an insult to their intelligence, pretty much a waste of time, because it's all very generic and it's nothing to do with how you do things here. And depending on the level, if they have never worked in the MSP industry before, sure, there's some background stuff that you can look at that, but don't just point them to the vendor thing and say, go do all this stuff. You need to have one of your team members, coordinator, manager, to actually work through that with the individual person to see where their knowledge levels are at and customize it specifically to them. But I was having a conversation yesterday with one of the senior project engineers and MSP, and we talked about documentation, and he had the same frustration as me. Our system is complex, there's standards, but they're not enforceable. They use particularly use confluence, which is great and it's super flexible. But the flexibility means there's variation and it's hard to audit what's is there and isn't there. So once they get the documentation in and those screenshots stuff and they do this now, well and true. That's all well and good. Then there's a product update. Pick an example. It's a backup solution, right? So the backup vendor changes something in their portal, the process is now out of date. So who's accountable to keep the documentation up to date? And the trick question is everybody is. If you don't have a process on how to update the process in the documentation, then you're going to get random stuff and people are going to look at it and go, well, that's wrong. That's not how we do it, or that's irrelevant. That's out of date. So having that conversation with people, it's a shared journey, right? Everybody has to own documentation. It's not the project, it's not the sales guy who sold its job, it's not the project engineer's job, it's not the technician's job, it's not the manager's job, it's everybody's job to make sure that we keep our documentation as a valuable resource that is trusted and relied upon by the whole team. And when you get that right, then you can supercharge your business because you can know you can bring somebody in and you got those processes down pat. You've got documentation, you've got a culture of documenting things properly and moving forward. And if you don't have that, it's a random challenge all the time.

SPEAKER_02 11:26

Whether they're offshore resources or onshore resources makes no difference because they're all members of the team. And if people don't trust the documentation, you are pushing shit uphill.

SPEAKER_00 11:37

100%. And even simple things like you have a ticket comes in from a client, it gets allocated into the PSA, and that ticket goes to the technician. In an ideal world, my view of a service test ticket is that we know what's wrong, we know how to fix it, we're just scheduling the time to do the work. So if you have a random ticket come in and it goes to a random person, if you don't have the triage process to attach checklists to that ticket or the ticket issue subtype automatically picks the right checklist inside your PSA that has links off to relevant documentation. If you're relying on someone to manually remember every time they get a random ticket to go search some other system with all their knowledge in it.

SPEAKER_02 12:21

Or one of three systems.

SPEAKER_00 12:23

Yeah, and and pick some random document that they're going to follow, then you're setting them up to fail. That's a failure of no triage process. And then basically the configuration of your PSA is not correct. Like the PSA. When a ticket lands with the tech, your job as business owners and leaders is to make sure they have every resource they need to successfully complete that ticket in the shortest amount of time. And I see it time and time again. We set these techs up to fail, and they just get assigned a random ticket for a client they've never worked on before, for a technology they don't know about, and a ticket says XYZ's broken. How are they supposed to effectively and efficiently solve that problem for the client? It's a tragedy, and I say it every day because it's not easy to stand back and think of the workflow, and it's it's a tough one.

SPEAKER_02 13:17

So let's dig into one of my little soapbox moments: strategic tool consolidation. So James Vickery talked about this in episode 10, Jake Weber Cadby in episode 39, both talking about the high cost of tool sprawl. My view was always use each of the tools that we do have to their absolute maximum. So I'll use AutoTask, for example, and the good old project module. That was very clunky. None of us loved it. At one point, we went off and tried a different project management tool, came back to AutoTask. But my view was the lesser amount of systems, but the more that we use those, the better saved on cost. Trying to keep it all within a system or a couple of systems, my view was better. What's your feeling on that?

SPEAKER_00 14:12

I love the shiny new object that solves a specific problem for a specific thing. And there are some super cool tools out there. But the average MSP, I think, has between 15 and 30 different tools they're using now, and probably using 10 to 15% of half of them and even less of the other ones. So it is a tragedy, really, because we're just in the search to simplify and make things easier and more efficient. We're overcomplicating things. And those tools don't share nicely. A classic example is when you have a documentation system, a PSA, an RMM, which the listeners will know what they mean. And which one is the record of truth? You'll talk to a centralized services or a network engineer, and they'll say, Oh, it's the RMM. It's the agents alive all the time. You talk to a accounts person, it's going to say, well, it's the PSA because that's where the billing happens from. You talk to the engineer who does the ticket and they say, I don't know, both one or the other. I don't know. You have to figure out what your record of truth is and have one place. And to me, it's the PSA. That's where the contracts are, that's where the tickets go, that's where the history is, that's where the billing is. So all the other tools need to feed into that or feed off that. And there are so many tools that can go multiple different directions because all these tool vendors want you to use their product. And documentation is a classic. You can connect it to the RMM and have it updated live from the RMM. You can connect to the PSA and have it feed both ways to the PSA. So my view is documentation should be fed from the PSA. The RMM should update the PSA, and vice versa. That's don't have two different things updating your truth record of truth. And I still see MSPs today that don't have sync between PSA and RMM because of that exact reason. So the RMM updates the documentation system. The documentation system might update the PSA to some degree, but it's not live in the ticket. So when an engineer goes to do a ticket and they need to access the RMM, they've got to get out of the ticket, they've got to go across to the RMM, jump in there, click on that. Whereas every modern system can be fully integrated now. So you've just got to be careful with that. So it's not really process here. I'm talking, it's more about the tools. You maximize and utilize the tools you've got. The RMM has tickets, the RMM has knowledge base, the PSA has tickets, the PSA has knowledge base. Pick one, don't pick two. Which one's which?

SPEAKER_02 16:41

And I think it is process because each MSP will have a process of how they do things and making sure that when we have new people come into that business, they know what that process is. How do they take a ticket that they've received and see it through to completion? What does that look like? How do they use the tools? How do they interact? Where is that source of truth? So to me it is process and every MSP is different.

SPEAKER_00 17:08

Yeah, I remember at the towards the end of our use of AutoTast, a couple of years after they were acquired by DATO, they did this uniform UI where AutoTask was the PSA, and on the left hand side you had all the billing information for the client. In the middle was the ticket details, and on the right hand side you had the RMM feeding directly into that. And we could control who saw what. So you got a ticket for Bill Smith's company, you know, ABC Corp. Bill Smith. When you opened that up, you saw all the other tickets opened for that company, the history of that user from the RMM saying that device, how many tickets it's had on that device, and everything was there. Like it was so easy to work on that problem. Where we never got to the point was having the completion history, the knowledge base of suggesting which way to solve this problem, which I think we can do that in in PSAs today. But even just getting that right, it saved count the mouse clicks, count the mouse clicks you've got to do to complete the ticket. And I see it today, like we have these pop-up alerts, and people just click off them. Like there's a reason you've set the PSA up to have an alert pop up in front of a tech when a ticket is logged for that client. If you're not using it, turn it off. It's just another mouse click to waste time to get another distraction. Like mouse clicks cost time. And every time you've got a click a mouse button, you've got an option of clicking the wrong part. So you're just making it more and more complex. So really, really try to focus on keeping it simple.

SPEAKER_02 18:35

And the other thing James talked about in his episode was that there's so much of what techs are doing that's really admin, not technical work. So I wanted to talk briefly about the resistance of techs in adopting maybe it's not techs, maybe it's the business owners, the leaders. They're resistant to adopting a single tool workflow to automate that admin rather than jumping between screens. And is does that go back to the tech and and the way that their mind works, do you think? Of I've got to go here and I've got to go there, rather than just having a workflow that takes you through that process.

SPEAKER_00 19:13

Yeah, I'm a good example of a free flow.

SPEAKER_02 19:16

Serial clicker.

SPEAKER_00 19:17

Well, I'd rather do a free flow, right? If you make me have to answer 20 tick boxes to close the ticket, I'm gonna be less likely to want to jump in and do that ticket. And I was having this discussion with someone yesterday, I think. Yeah, triage process. We were talking about triage process. What we discovered is because we put a whole lot of mandatory fields in the tickets to help get that issue, subissue type, the right contract, the right work type. So when basically when the ticket landed with the tech, they didn't have to think about any of that. They just had to fix the problem and record their time. And maybe they'd update one of the issue subissues because we had a logging categorization. Then when the ticket was completed, if it was an incorrect, if it was triaged incorrectly, like if they put it in as a backup problem and it was actually an email phishing attempt, you had to change the code so that the data coming at the back end. So right. So that's all they really had to do. But to do that, you've got to set mandatory fields in the ticket, which means if you edit the ticket to update something, you have to fill all those fields out before you can save the ticket. And what I discovered is that our triage people in dispatch, they figure that out too. And they didn't want to have to fill all those fields in because they didn't know all the answers to all those questions. So they would not edit the ticket, they would ford the ticket on and assign it to somebody, leaving shit in the title, incorrect contract, incorrect work type. Because if an if a client emails the ticket in, the PSA is going to accept it, right? None of the rules apply to a ticket that's been emailed in. So my point about this is the triage process is super critical. And it's not a receptionist's job to triage tickets. It's not a level one's job to triage the ticket. It needs to be a team leader or service coordinator that knows the correct way to triage the ticket to maximize the output and the efficiency of the tech on the output side. But not a lot of people do that. I don't know whether it's a size issue or we just think, oh, well. So what that means if you don't have a really good triage process, you effectively can't have level one people in your business. It even makes it difficult to use offshore people because offshore teams that I've worked with in the Philippines, in Indonesia, and in Sri Lanka and India, they work on workflow. They are not going to make decisions about which workflow to follow, which contract with the ticket to be on, what code to put here and there. They are just going to follow what they've been told. If you don't have an effective triage at the front end, it's very unlikely you're going to get a beautiful result.

SPEAKER_02 21:50

Quality output. Yeah.

SPEAKER_00 21:51

You've got to invest somewhere. Somewhere, someone with some smarts and skills has got to be work on the ticket. They're either cleaning up the mess afterwards, after the limit. one person's had a go and rooted up, or they're spending five minutes at the start and actually triaging the ticket properly, then when it gets assigned to the service desk to get done, then it literally is just scheduling time with the end user and scheduling time with the tech. And they can we proved it at Ida, we can smash out 14, 16 tickets each because we're not having to guess. So you can get efficiencies in your system, but you've got to invest the time to get the processes right, the tools configured to implement those processes as automated as possible. And then the triage with some intelligence so you assign the work to the right person the first time.

SPEAKER_02 22:39

Yeah. And I I've been in a situation myself. I am not technical and I've had many conversations with you and others in our business over the years about who we should have in that role. And I always used myself as an example. If you put me into the role of triage, I have no idea I see a ticket come in and I read it and it means absolutely nothing to me. So putting somebody into that situation where they are reading something that they don't understand and expecting them to make quality decisions about what to do with that ticket, you are just screwing not just that person, but the whole team it just to me, you've got to have somebody, you've got to have the right person in that seat to set up the whole team for success.

SPEAKER_00 23:27

Let's be clear here we're not talking that triage is different from dispatch and that's different from concierge or answering the phones or the very front end, right? So you can have someone answering the phone and logging a ticket, but they need to be that needs to then get passed to a triage queue or triage board for ConnectWires, queue for the other ones. And then someone's going to triage that ticket. If you're just generally capturing a little bit of information from the client to help them get them off the phone and it just goes and hits a text straight away, that's a lost opportunity to improve that efficiency. It's a real tough thing because for some reason we have this expectation that level one should be the first person to touch a ticket level two should be the second and level three should be the final backstop. I see service desk as needs to have all skill levels needs to have level one, two and three. If you have enough volume of tickets and you've got enough clients you would have with our team we I think we had one level three two level twos and two level two or three level ones in each pod. But the level ones they had their work scheduled 16 tickets a day half hour blocks because we had enough volume of routine work that we knew what to do we knew how to do it was just a matter of getting the work done so that level threes didn't have to do that but the level two and three guys probably level two were doing triage and fixing the more difficult ones and then the level three was for escalation and that worked really well for us. We had enough volume of tickets and enough work to keep that busy it takes a different personality we had guys roll through that role like level three escalation engineers and they're different personalities like some people like the variety of I don't know what's happening but this is exciting. Like I'm like that give me a problem I'll figure it out I'll figure out what the when I figured out what the problem is how to fix it. Fixing it doesn't I don't get the buzz of the fix. I'd rather hand it off to someone who can fix it.

SPEAKER_02 25:24

But if it's documented and you've attached the documentation of the ticket push it back to somebody else. Yep 100% just wanted to say there that triage it takes a special person to do the triage because the expectation is not oh I can do this quickly I can do this quickly because then now they've done 87 tickets today and nobody else has done anything because nothing goes through them. Triage is literally figuring out what needs to be done if possible attach the documentation and allocate it to somebody with the skill to do that ticket not to do them.

SPEAKER_00 25:54

Yeah I was looking at some stats yesterday on tickets on a service desk board over the last four weeks the service coordinator manager did 86 tickets.

SPEAKER_01 26:04

In how long?

SPEAKER_00 26:05

In four weeks 20 a week yeah yeah well that doesn't matter about that I'm not looking at efficiency. The primary level two service desk tech did about maybe it was a week 60 or something 60 it was yeah seven days it was a seven day period. So that the manager did 86 tickets the level three tech did I think 90 tickets and the level two tech did 60 tickets.

SPEAKER_02 26:25

Is that not backwards?

SPEAKER_00 26:26

It's completely backwards. So what was happening is the triage was not happening. So these tickets were being allocated by a dispatcher to the person they felt would be best or like that client or they liked them or they'd worked on that client before or I don't know what to do so I'll just give it to that person.

SPEAKER_02 26:46

Oh I'm having a nervous twitch.

SPEAKER_00 26:48

And what the mistake was the service coordinator slash manager was doing the tickets rather than deciding what needed to happen and allocating it back. And this team has three level two guys in their service desk and two of them got allocated no tickets that week. So maybe they're away I don't know they were Filipino based so there could have been some public holidays. But these numbers are all backwards all backwards. Like the most senior guys should be doing a maximum of three or four tickets a day and their job is to coach and help and get the efficiency at the other level. So we'll be having a DM about that next week.

SPEAKER_02 27:27

I'm sure I'd like to be a fly on the wall for that one.

SPEAKER_00 27:30

Yeah it was just an example of looking so these numbers are all completely backwards. Yeah and interesting with the stats of that 90 odd tickets only 45 of those worked on tickets so the other 45 were just closed because they were superfluous bullshit from dodgy alerts or something. I don't know how you can work how you can close the ticket and not work on it but obviously you can do that. You can just edit the ticket and say complete without a time entry which in my PSA that would never happen. I would ban that from happening.

SPEAKER_01 28:04

Yeah.

SPEAKER_00 28:04

But my point of bringing that up is the importance of deciding on what your process is, documenting it and then implementing the tool to match that process you've got to do all three and educate and it the third is educate the people on what they should do. So document what you want to have happen. Set the tool up so it does happen that way then educate the people to use that to get the desired outcome and this is an example of half of a documentary process a PSA that's wildly misconfigured like it's literally just out of the box you log a ticket in there and everything else is random what happens there's not a lot of workflow rules not a lot of rules and regulations because once you put those rules and regulations in the PSA it's harder to log tickets. It's harder to edit a ticket but the reason we make it hard is because we want to collect good data and like I say you put shit in, you get shit out. And in this day and age right now there are people building MCP servers there are people trying to extract data out of their PSA to help them with the triage process. Now that can never work unless the data is collected correctly in the ticket which means you have to have it allocated to all the right settings in your PSA and the guys doing the work can't just say fixed problem.

SPEAKER_02 29:23

Or I can't remember because it was a week ago and I haven't done my timesheet so I've just put it all to admin.

SPEAKER_00 29:28

And we've all got away with that in the past even though the PSA vendors will tell you there's this magical knowledge base that can automatically pick up the symptom the time it never ever worked. But now we're getting to the point where we can actually analyze that and I know a couple of guys that are working on live prompting for the tech. So it's not writing their ticket entries for them but it's reading the tickets in parallel with the tech doing the work in the PSA and prompting and saying hey this client this user's had this problem four times before here's how we fixed it last time. Try this first and this is exciting because this is then you're getting that triage automation happening but it only works if you're putting quality data on your ticket notes and the tickets are being categorized correctly on the way in. So I'm seeing a massive update in people actually getting their shit together in their PSAs because they can't use AI to help them if it's bullshit.

SPEAKER_02 30:24

If there's nothing in there in the PSA.

SPEAKER_00 30:26

Yeah like ticket says computer slow answer was checked logs it's okay.

SPEAKER_02 30:33

What does AI do with that?

SPEAKER_00 30:35

It's not going to do anything with that.

SPEAKER_02 30:37

Yeah check the logs and say it's okay yeah and there's some really good AI tools out there now for documenting. Scribe is one that we've looked at the days of having to screenshot and type out word documents and that sort of thing are gone. Use the AI tools to help you and because for me I'd much rather have two screens one with the video run it stop it go and do that bit than try and follow screenshot and text on a word document. Just stab me in the eye with a pencil. It'd be much more pleasurable for everybody involved.

SPEAKER_00 31:12

And I think one of the points you brought up earlier Jenny was the tool sprawl and tools and cybersecurity is a fickle little thing. So I was very much of the pick a vendor you trust are they going to be the best at everything? Probably not but if I can get all my eggs in one basket and I've got one throat to choke as they say that's why a client picks you as an MSP. They don't come to you and say oh I want you to do my ticket triage but I want the other MSP to actually do the work and I want this other MSP to sell me stuff and I want this other MSP over here to actually deliver the project work. But that's what we do with our tools. It's like insane to me. If you don't like the vendor get a different vendor but once you've picked someone to get the maximum value for your business and to set you free and what this whole topic's about process is embrace the vendor like we used AutoTask harder than autotask used autotask. You know I was on the advisory board and some of the stuff we got we're dealing with the senior developers said you guys are really pushing that. I said well I want to use everything that I've got I'm going to work really hard to make our business process fit the tool that you provide before I go out and put another third party tool in place. Because that to me is just admitting defeat. Either your product's so bad that I'm going to dump the whole thing or our business process is so complicated we need to simplify it. And yeah getting back to that purpose of process is you don't spend 20 hours documenting a process you do once a quarter or once a year, right? That's not what we're talking about here. We're talking about 80% of the work is covered by 20% of the processes in your business. Make sure that 20% is down pat. It's absolutely the stuff you do every day day in day out day in day out weekly and your PSA should be able to tell you that what are the 20% of the most common tickets are coming. Yeah and if it's quarterly and annual stuff literally you refer to the vendor documentation because I don't know for me I used to do basses in the early days. I had no idea how to do a bass it was QuickBooks. So I'd kind of every quarter I'd have to reinvent myself I don't know how to do this I'd go and watch the video or get the documentation out I'd go click click click and it took me an extra 15 minutes to do it but I did it once a quarter I didn't need to screenshot the entire process of a bass for one person me to do it once a quarter. So be realistic about this. Don't get pedantic and like some people do and go, oh well you know if we're going to do this we're going to have to do it for everything and you know yeah we had people in our team at one point like that and we got way overcomplicated with over process and over documentation then paralyzed by this process and control and it was weird.

SPEAKER_02 33:56

But anyway find the balance embrace it okay I wanted to have a quick chat about the franchise mindset. So still in the same vein but I guess building the MSP manual Alan Mitchelmore in his episode talked about some of his clients going to the point level of having an SOP for putting the bins out. Ryan Spillane in his episode said that great documentation makes a due diligent process for a sale move 60% faster because you can actually show how work gets done. So thinking of the McDonald's work how McDonald's work is because you can pull a 16 year old in and give them a process and they've got the guardrails so how do we do that so that we can bring in well junior techs but also AI without having to ask somebody every 10 minutes or ask for permission constantly?

SPEAKER_00 34:55

Yeah I think because we've all started our businesses or most of us have started our businesses as the kind of entrepreneurial engineer we came from a technical background we knew how to fix stuff for whatever reason we've started a business and everything in our head is in our head we just knew it. And then as we got to it big we start to document a few things. Once you get above about seven or bigger than a pizza yeah once you get eight people eight slices it's too complicated. You can't have things in your head you have to document stuff and I think we need to go back to that mindset and think hang on if my five year old kid had to follow this process is it clear enough? Is it simple enough? Is it relevant? Am I ever going to have a five year old kid do this process? Or Jenny or Jenny or for those listening if I had to follow it could I do it there's a couple of YouTube checkout I think one's called burnt toast and the other one is the peanut butter sandwich process and just really slaps you in the face and says my God sometimes we overcomplicate things and we we say it the way we want to hear the information not how somebody else needs to hear the information so if you want to have those guardrails and keep it simple and you've got to be able to put your head in the other person's seat. And not all people can do documentation. I can't write documentation I can talk it. I've taught myself an AI agent that interviews me now give it a topic and it digs deep and ask me all the right questions and then finally we work together and we put the document together. That works for me. Other people are visual and they're very detailed they can go and make it all happen. I'm a kind of an audible type of person. So yeah I think it's just got to put yourself in the other person's seat and test the documentation. Get someone else to read it to you. I think that's the key to that.

SPEAKER_02 36:48

I think those two videos you're talking about YouTube videos one is how to make toast and I can't remember the name of the other one but it's around peanut butter is it peanut butter and jelly sandwich how to make yeah yep yep and he's literally got his five and probably seven year olds working with him on that. But I think that a big part of this is selling it to your team. Like if your techs know what they're doing and have that expectation that everybody in their team should know what they're doing, they won't be even remotely interested in doing documentation. Like we all know we're smart people, we know what we're doing. But if you can sell it to them that this is so that we can scale and you talked earlier in one of our episodes Nick about having to I think it was today about having to do something a thousand times. If I don't document this every time this ticket comes in I'm going to have to do it. If you can do it and document it and then you never have to do it again that then allows you to go and solve more problems and figure things out rather than just doing the same old shit day in, day out. And because I think a lot of techs they do. They just do the same old, same old and probably get frustrated but not even really sure why they're frustrated.

SPEAKER_00 38:05

And some of them there are techs out there and God bless them we all need people that are just great at doing work and love talking to customers and solving problems but they'll get five tickets for the same thing and it won't dawn on them that there's a bigger issue going on here. And so that's not the person you want to have do documentation by the way. You want to get the person who hates doing routine stuff to do the documentation because they will document the nth degree out of it and make sure that every base is covered and all the options so they don't have to get harassed again down the track. So yeah it's always the way if you've got a really difficult process give it to not the smartest person but give it to the person who you know is going to get frustrated and fix this once and all so it never happens. Yeah like I've seen people get really proud oh yeah I've seen that problem before I know exactly how to fix that. Great. Oh yeah that one hang on you've seen the problem before you know exactly how to fix it. Who have you escalated this to to make it so that problem doesn't happen again for everybody else. And see that's the superpower we have in an MSP is we have multiple clients with hopefully somewhat similar environments. So if you fix a problem over here then there's a fair chance that problem's going to happen on the other customer sites as well. We had hospitals and councils which were like 90% exactly the same like each hospital literally had the same applications. Everything was pretty much the same and the councils were very similar. They may have a different ERP but everything else is pretty much the same. So we knew if we had this problem over here on this vendor's bit of software on that client then we were going to see the same problem somewhere else. And we got really good at documenting that and say and flagging it straight away oh I can that's a man add problem. Known issue with man add and we would tag our team say there's a known issue watch out for it. And that mindset yeah not everyone has that because your customers are not you don't have enough customers in each vertical so you've kind of a bit all over the shop and you don't have that leverage of standardization that we all utopian dream that all MSP wants is you know the reason they can get their price down to 70 bucks a month is because everything is exactly the same and there's no tickets being logged they don't know how to fix. So you get through it really quickly whereas you have take on clients that have a complicated non-standard environment there's going to be a lot more work involved in that and you need to charge them a lot more money. So yeah and both can be successful 100%.

SPEAKER_02 40:29

Absolutely and just one last thing before we close around the guardrails just something I wanted to share was to me a guardrail is at what capacity do people have to operate within without asking permission. And one thing that we had this conversation with somebody over the last few days we had all of our techs were on the road they all had credit cards. We were regional based with DWM. They had a limit of $250 where they could go and purchase something from the local PC store or whatever they needed to get a customer out of trouble up to the value $250 without making a phone call and getting permission. So if they needed to go and buy I don't know a modem or whatever it may be.

SPEAKER_00 41:17

Yeah cable.

SPEAKER_02 41:18

Cable whatever it is just go and buy it, get it sorted. We then had a process that sat behind that to make sure that that came through to our accounts team to make sure it was then invoiced back to the client. But putting those guardrails in place so that people know where their authority extends to and then if they hit that limit say that $250, who do they talk to? How do they get permission? What does that look like? So having guardrails in the business speeds things up. It gives people some authority it gives them a process to follow if they hit that limit and once we did that we weren't getting phone calls of oh you know or somebody drives four hours back did you fix it? Oh no we need to order a cable what we need to order a four dollar cable and now you've got to drive back four hours when the cable comes in and then four hours back again. Why did you not just go to the local PC shop and buy one?

SPEAKER_00 42:16

Because we didn't have a process around that so no one knew how to do it.

SPEAKER_02 42:20

Correct. Yeah. So having those guardrails I think speeds it up but it also gives people a bit of ownership of I know where I can operate and where my decision making ends and what to do outside of that.

SPEAKER_00 42:35

Yeah and I think that's a at a higher level that's a delegated authority matrix where you've it could be financial it could be decision making you know and I I was talking to someone about this the other day and I might have been Sally but yeah like if it's a critical client thing you need to ring me. If it's an update an FYI then an email and two days later response time's fine. Or if it's just a an idea then it it's a different priority level. So and this helps people manage their own time too because um you've really got to set your team up for success and people like to be able to make their own decisions. It gives them the authority level we all complain that we get too many people coming to us and asking questions all the time. That's because we haven't set those parameters it's like I said the guardrails and parameters of what you can and can't do. And the success of those systems are based around you being clearly articulating what you can and can't do and the reasons behind it.

SPEAKER_02 43:32

Okay let's wrap this episode thanks Nick and as always thanks to all of you for listening. If this conversation hit home for you or got you thinking 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 any episodes but particularly the final episode of this series, part three, where we'll be discussing the mindset of a leader. Until next time, this is MSP Mastery