712 Onboarding & Offboarding Professionally

Hello friends, Uncle Marv here with another episode of the IT Business Podcast, the show for IT professionals, where we try to help you run your business better, smarter, and faster. So this is the regular Wednesday live show, and I am here by myself. It was one of these weeks where, short week, we had the Monday off, and I wasn't sure if I was going to have one, but I decided I needed to go ahead and do that.

I do want to say thank you to Brad Gross, who recorded an episode with me yesterday, and we talked about the growth of our managed service community and the cybersecurity managed services that come with it, along with the possibility of more lawsuits. So if you've not had a chance to listen to that, go back. Episode 711 with Bradley Gross.

So tonight, one of the reasons that I wanted to get on here and do this is I had something that's been on my mind. It's been bugging me for, oh, a couple of weeks now, maybe three, and the situation technically is over, so now I can talk about it publicly, and I'm going to do that. And I'm going to try to keep it sane and not really throw anybody under the bus or anything like that, but I do have a bone to pick with some people about what happened.

But before we do that, let me make sure that I do not forget to talk about TechCon Unplugged that is coming up. It's next week, folks, September 12th through the 14th. If you have not yet signed up and you are near the Washington, D.C. area, please do that.

There are a few seats left, but this is a type of conference that you don't want to miss. Parco and Rick are working their butts off to put together a good group of speakers for us, some good breakout sessions where we as peers will be able to talk and share at a conference and not be preached at or anything like that. It's going to be a good time.

So that is next week. I had a chat with Parco and Rick this morning, mainly for them to put me on notice to do a good job as the emcee. I will be there kind of leading some of the sessions in terms of moving things along and stuff like that.

It's a little different format. So I actually forgot to ask them if I'm leading a session. I was signed up for a session, but it may have been bumped.

So I need to check in with that before I head out next week to see if I'm doing that session or not. But it's going to be a good time. People have already started putting in their musical requests.

I will say go ahead and send them if you have a song request that you'd like for me to play during our in-between times, our morning breakfast and stuff like that. Go ahead and send that request in and I will be DJ Marv for the weekend, as long as it's appropriate. Can't have no super-duper booty-shaking song or something like that X-rated.

This is a family-style conference, folks. So let's think about that music as you're deciding on your choice for me. That will go for not just the in-between music, but also the walk-up music for the speakers.

All right, so techconunplugged.com. There is a coupon code that you'll find on the website. If you use my link to go to it, get $75 off the ticket price. I think it's still valid.

Something else I didn't ask them, but hopefully it is. And you can get a little bit of a discount there. So two things that I really want to address tonight, and they both are an answer as to why.

So I had a nice long chat with someone last week before the break, and it really boiled down to, Marv, why are you doing this podcast? What is the motivation behind it? And it was a question that I answer from time to time. And it usually comes down to one thing, but I'm going to add a second thing. And the first thing is, this is my opportunity, in a sense, to give back.

I found the podcast community at a time when I was looking for some help, and I was kind of running solo. I had just gotten rid of my techs. For those of you that do know me and my story, yes, there was a time that I had technicians in my business.

In fact, there was actually four of us in my business at one time. I had an admin person and two full-time techs along with myself. And yeah, we were doing our thing.

And between 2008 and 2012, some things started to shift, and I found that I could do a bunch of stuff remote. I came across RMM software, remote access stuff, and automation, and found this community that it was something that was weird. I had a couple of customers that were growing at the time, so I wasn't actively growing, looking for more business.

And my goal at that time was just to support the clients I had. I wasn't looking to get big. I had a little frustration with managing techs at that time, techs who didn't want to get certification, didn't want to pass testing, didn't want to learn anything.

They just wanted to play. If they weren't out on a job or if they didn't have a task in hand, they'd be playing games. They'd be doing stuff that I'm not going to talk about.

But I was at the point where I'm like, you know what? I don't need you guys. I'll do it myself. So that's how I ended up being the solo person that I was.

So in 2014, I came across this community, and it really helped me to support my customers. I still expanded, helping my customers grow. I did take on more customers, but I was able to do it by myself with subcontractors.

I didn't hire techs full time. I still had some subcontractors. One buddy of mine who ran his business, and he and I partnered from time to time.

I had another buddy that had several techs work for him that I could lean on from time to time. Had another consultant friend, and then I found consultants in the branch office areas of my clients throughout the state, Orlando, Tampa, Jacksonville, Vero Beach. So I was able to support those.

And that was the main thing that I did. They were looking to bring back a podcast, and the talent portion of that podcast didn't want to do the logistics. I said, I'll do the logistics and got the podcast back.

And then he ended up giving me the podcast because he was done. He needed to do family stuff, and that's how I got the podcast. And so it was my way of giving back.

The second thing that I have found that is popping up more and more, first really came up in 2019, but really has been something else that has been, is to defend the solo tech and the small MSP or the small emerging IT solution provider, whatever you want to call the small business. There seems to be this, I don't even know what to say about it, but there's this thing that's permeating our industry that there's one way to run a business. And we know from looking at other industries, that's just not true.

I mean, there are small businesses, there are large businesses, there are tons of businesses in between our customers. Some of them like to be handled by big business. Some of them don't want to be handled by a big business.

They want to support the small and local community business. So I find myself from time to time supporting that and just getting to the point where if you're in this industry and you are poo-pooing the small business, even if they have two, three, four people or techs and they're not growing, that's no reason to tell them that they're not a real business. That's no reason to tell them they're not a real MSP.

And there are a lot of people in this industry that are solo and solo for a reason. And listen, I'll be honest. Technically, I'm solo.

I've got the subcontractors. I've gone back and forth over the years. Do I need a tech? Do I want to grow? And the bottom line is every time I've gotten to that brink, I've come to the realization that I'm happy where I'm at.

And one of the things that I have realized over the years is that the biggest thing that should be important is happiness. Happiness with ourselves, happiness with our family, spouse, relationships, all that stuff. I don't need to get big and be grumpy.

If I can get big and be happy, I'll do that. But I'm not going to get big just for the sake of getting big, just for the sake of somebody telling me that's what I have to do. You build your business to sell it, whatever.

You do you. And that's not to say that I'm against a lot of what happens out there. I just don't like the fact that people are attacking the smaller businesses because they're not like you.

So part of why I'm here is to defend those people out there because somebody has to. And there's no reason to run people off, whether it's a solo tech, whether it's a female, whether it's minority, a person of color, there's no reason to do that. So stop it.

The topic that I had tonight, so it's weird. It's onboarding and offboarding professionally is the full title. If you saw the show cover on the YouTube or LinkedIn, whatever, just had onboarding because that was the only picture that I could find for the podcast cover, I did find a way to onboarding and offboarding professionally.

And oddly enough, this did not come up because of Bradley Gross's last podcast that he did just a couple of weeks ago where it was titled Offboarding, You're Doing It Wrong, which good podcast, by the way. And in that, he talked about realistic expectations, workload considerations, payment, removing software, that sort of stuff. All the things that we need to take care of if we're offboarding a client.

But one of the things that maybe was an underlying thing that he talked about, but it wasn't out in your face, is the professionalism that goes along with onboarding or offboarding a client. And the reason that this is dear to me right now is I've just spent the last month offboarding a client, and I'll say that they weren't a full managed client. So that's probably a good place to start.

This was a client where they had a full-time tech at one time. They had an MSP that supported them by selling them 365 licenses, and that was about it. They did help with special network projects that this tech in-house could not do.

The tech was self-taught, not Microsoft certified, didn't really have any formal training, just Googled as much as they could. And without getting into the details, they wanted to make a change and brought me in as somebody that could give them a little bit more support, maybe a little bit more proactive support. I got along with the tech, and it was good.

I fixed a couple of problems for them, and that made things go really well. Well, the tech went away. I won't get into how that happened.

And we needed a stopgap for the client. And so one of my subcontractors and I, we supported them for about a month before they brought somebody else in. And at that time, they only brought this person in part-time, and then they still relied on us for help desk support, in a sense.

So whatever that person could not do while they were on site, in terms of managing the network, onboarding, offboarding, end users, that sort of stuff. And that's what we did. There was no MSA agreement.

There was no, we're managing everything. In fact, I did give them a proposal that at one point in time, they said they were going to sign, but they never did. So things never changed.

Now, I also know that in tandem with them considering me, there was also another MSP in the mix. And I don't know how many years they were in the mix, but I know that they were there. And listen, first, I'm going to say no hard feelings, because this other MSP is who actually they ended up signing a formal agreement with just recently.

And business is business. I get it. And I'm always on the side of the client when it comes to doing what's right for your business.

And if that's not using us, that's fine. But in this process, what really got my attention was I kind of got ambushed with a meeting where I never really got formal notification from the client that this decision had been made. I knew there were some things out there.

They were looking for some invoices and contracts. So I kind of figured, OK, something's probably happening. I got a request for a meeting to understand the 365, because we were actually selling that direct through our CSP license.

We weren't referring it through App River or anything like that. So I thought, well, maybe they just want to fund that. Well, of course, I get ambushed with, I don't know, four or five people from the new MSP.

And they immediately started asking questions about the network and servers and desktops and switches and stuff. And I'm like, hold up, hold up. Does this mean you guys are taking over? Because I wasn't told.

Oh, yeah, yeah, yeah, yeah. OK. And I asked, when are you taking over? Oh, we don't know.

And from my perspective, I'm like, OK, well, if you don't know and I don't know, we really don't need to have this conversation. Now, I did give them some information. I knew it was going to happen.

I'm not trying to be a jerk or anything about it. But I had not received formal notification from the client. And so I reached out to my contact there, who happened to be on vacation, oddly enough, and said, oh, I didn't know I had somebody else taking care of this.

Why don't you reach out to them? Reached out to that person. They didn't know. So, I mean, listen, yeah, it sounded like a mess.

I knew it was going to be a mess. That's the way it was. So I was actually the one that came up with the off-boarding date.

I put together a 30-day window of what I would do, when I would hand stuff over. And this was going to be the last date of management and handed that over to the client. And that was that.

And then I get an email because the new MSP started asking for stuff. And some stuff I gave, some stuff I didn't. But it really, in my mind, wasn't a situation where I still, to be honest, I still did not get formal recognition of the off-boarding date.

I never got from the client that's like, yep, that's it, that's good. I did get a call and saying, can you explain this email? And I said, well, as I understand it, you're making a decision. So I'm putting together a timeline that I think works for all of us.

Oh, okay. And that was it. But the client started asking for stuff.

And one of the things was all of their credentials and passwords for the network. And when I had talked to them in that meeting, my response at the time was I would give them about a week before the final date. And they were kind of taken aback as to, you know, why, why would you do that? We can't onboard in 30 days without that.

I'm like, what are you talking about? Now, let me just put a couple of things in perspective. This company, along with us, had known about this possible takeover, let's call it that, for a while. It didn't like sneak up on us.

It didn't sneak up on them. They've known about this customer for at least a couple of years, maybe longer. This is a fairly large MSP.

And when I say fairly large, I'm talking huge. I mean, if we're saying 175, 200 employees, maybe more, I don't know. But they're big.

And to tell me that you can't onboard in 30 days without passwords, okay, that's not my problem. But it just felt weird that they were pushing that hard and that fast. Now, granted, I don't know all the official documentations of what's adopted in the entire channel.

But I know in terms of a typical process for onboarding and offboarding, in most cases, and when I say most, I'm going to say 80% or more, when passwords are handed off, so is the responsibility. My thought to them was, if I start handing that stuff over, I'm done. And the stance was, if you put on your agents, I'm taking mine off.

And their response was, well, you're still providing support for them. I'm like, well, this isn't a co-managed situation in my mind. I didn't say that to them, so let me not put words where they're not.

I didn't say that to them. But in my mind, this wasn't a co-managed thing. There was no agreement for us to share responsibility during this 30-day window.

I was going to offboard, hand over stuff. I provided one week's time for the transition, and then I would wipe my hands and be gone. But that's not how they understood it, because I got an email mid-month, and basically, they were upset that I had not yet given them the credentials.

I should probably have gone back and let you know that the ambush meeting was probably about 40 days or so before the date that I had put on the offboarding. So let's say we're probably 10 days into that 30-day period, and I get the email where they basically accused me of intentionally withholding network credentials, and that not only was such behavior unprofessional, but also detrimental to the client. And I was like, first of all, I didn't agree to that.

They asked me how long it would take to put together a runbook for them. I said 24 hours. But that wasn't the fact that I agreed to give it to them.

I said I would give it to them early, which means that I wasn't going to give it to them on the last day of my obligation. I was going to give it to them a week in advance. And actually, I might have given it to them sooner had we all just gotten along.

And both my wife and several people that I talked to were like, what are you doing? I said, listen, I have no ill will towards the client. Why am I going to put them in a bad situation? And I'm not intentionally trying to be a jerk to the new MSPs. In fact, I know this MSP.

I've known about them for a while. I even tried to get somebody from their company on this podcast. So it's not like I'm the jerk here.

But apparently, it was perceived that way. And so I did have to send an email where I told them that, listen, that's not what I agreed to. Here is my process.

And in a sense, I took the stance at that point where my responsibility was to the client. Not to the new MSP. So all of the agreements that I had in place were with the client.

And that's where I did it. And I did still make some overtures of offering up. I gave them some other documentation early.

I even offered to meet somebody from their office at the client's base, walk them around. Because this type of building is a cluster. Let's just say that.

It's basically multiple warehouse bays that have been added time over time. Wiring is horrible. I mean, if you talk about a bird's nest, a spaghetti nest, it's horrible.

The wiring is horrible. The server, it's old. It's a 2016.

Some of the workstations are old and slow. Most of the switches had been replaced. There is a ruckus wireless network in place.

Mismatched access points. But they work. There was a bunch of other stuff that I could have showed them as well.

I offered that crickets. And I don't know if they ever went by. I did not ever see a device pop up on the network.

But I offered, and they did not take me up on that offer. So, OK, that's fine. One of the other things that really struck me in that ambush meeting was they had asked if I would put their agent on the network, on the server, on all the computers.

No. And this is just simply something where, over the years, the typical process is that the offboarding MSP's main responsibility is to exit the client's environment, not to assist the new MSP with onboarding or setup. So, again, big MSP, probably charging a lot of money for onboarding.

Why would you need for me to help you with your onboarding? So, that was a no. I did offer to put it on the server and let them do their deployment. So, that was that.

So, let me go back to some of the, I'm going to talk about the key points when it comes to the MSP's responsibilities for offboarding. Because their big contention was that I was withholding information. And, you know, withholding passwords or credentials, I've always taken the stance that these are the client's information.

So, it wasn't that I was going to withhold them and hold anybody hostage. But it's something where it's for everyone's protection that during that transition period, if something were to happen, whose fault is it? I don't want to be pointing fingers back and forth of saying, well, I don't know who's in the environment. You're in there installing stuff.

We're in there installing stuff. Who knows what happened? I don't want there to be any pointing fingers. Again, it's not a co-managed situation.

So, I will support them up until this date. You support them going forward. And I think the overwhelming stance that most people take in this industry is while you may try to work together.

And even have an overlap period. The bottom line is that once passwords and credentials are handed over, so is the responsibility. So, if you want me to support them to a certain date, that's when I will support them.

I had not talked with the client about providing support after the final day of responsibility. Which is something that everybody that I've spoken with and heard from in the vendor chats about, you know, checklists and stuff. You know, you have that final handoff date.

And any support after that is billable. Which is something that, you know, everybody wants to do. See, the best practice is to coordinate the transition with the new MSP to minimize downtime.

But the offboarding MSP is not responsible for the new MSP's onboarding process. I think I said that a little earlier. The offboarding MSP should clearly define and communicate the last day of managed service responsibility.

Quotations when passwords are handed over. The date that they will be completely out of the client system. So, in a sense, two things.

So, I had, you know, agreed to give them the passwords and stuff a week early. That final week as they put their stuff on, I will be taking my stuff on. Off, I mean.

And then the last day, I would remove all of my agents. And then the day after that, I removed my final access. Removed VPN access.

Removed the final agent from the server. All my credentials from the switches, the firewalls, all of that stuff. Kind of interesting there.

So, it's something where I try to maintain professionalism. Now, we may have different ideas of what that is. But my process is usually what is typical, what is standard in this industry.

I have strived to do that. The email that I was sent that, you know, the person was, you know, kind of offended that after 24 years, this is what was happening. And listen, I never met the person before that.

I don't know. Good guy, bad guy, nice guy. I don't know.

All I know is that I've been in this industry more than 30 years. I've had this business for 27 years. Never been called unprofessional in this setting.

I've been called a lot of things. I've been wrong a lot of times. So, in a sense, I think I was more upset with being called unprofessional just because our timelines did not match up.

So, that was that. Okay, I think I've ranted a little bit here. This probably is unprofessional in terms of how I've handled this.

But it was something that I felt like I needed to do. So, what I'm going to do is take a quick break. And I'm going to go back.

And I spent a lot of time in the offboarding side. I want to go and talk about the typical onboarding side. And this is from the perspective of MSP to MSP.

This isn't really based on whether you're firing a client or losing a client. It's just common courtesy in our industry, at least from my perspective, what I've gathered over the years in talking to other MSPs, in reviewing the checklist. I mean, there are vendor checklists all over the place on typical ways to onboard and offboard clients.

And that's what I'm going by here. So, let me do this. I did not, at the top of the hour, say that the IT Business Podcast was brought to you by NetAlly, your trusted ally in fast, reliable network testing.

I will say this. I did play the clip for the new CyberScope Air. My CyberScope is one of the devices, excuse me, that is in my everyday go bag.

I used it today as I was adding an access point to a client's office. So, I used it after I attached the access point, went back to the server room, traced route the path through the switches to that access point so that I could assign VLANs to those specific ports on each switch. One of the things that I don't do is I don't assign every VLAN to every port on every switch.

So, in certain situations, it is very vital that security-wise, you only pass through VLANs on the ports that need it. So, I did a trace route on all those ports, on all those switches to that access point. That way, I could just push out those VLANs.

There was a guest VLAN, a cafe VLAN that were separate Wi-Fi for those. And I did that using the CyberScope because it's got not only the quick network test to see if everything's working, but you can do a path ping to the device and get the path through each switch to do that. And then, of course, I took it back to where the access point was, did a wireless connection test on that access point specifically on all the Wi-Fis.

And it's one of those things, one tool can do all of that. Not only could I test connection, I could test the VLANs, I could test the SSIDs. This client was actually set up as a profile on the CyberScope.

So, I just switched to the profile, had all the access points in there, hit test, ping, ping, ping, tells me everything, gets out, sends me an email. Once it's all done, I can show the client, there you go, wireless access point installed and tested. So, that's it for the NetAlly.

I will be searching for more information on the CyberScope Air as I get it. I know it's been out there for about a month or so, but I don't want to push my partners. You saw a different MUD earlier, but of course, SuperOps is the secondary sponsor for the podcast.

They're also the MUD sponsor and the Florida Man sponsor. As I take a sip of my beverage there, you're all-in-one RMM PSA solution. Empower your IT management using SuperOps unified solutions for modern MSPs.

And also on the intro, you saw TruGrid, one of the products that I use for secure remote access. Secure your remote access with TruGrid, simplified, fast, and firewall free. And I think we've got an episode coming up with them in a few weeks where we will be diving into a lot of the stuff that has changed with TruGrid in the past, I don't know, 18 months or so. 

It's actually a fantastic product specifically for remote access. Now, it's not the full sassy solution that everybody's using now, but if you need people to get to their desktops or to RDS servers with multi-factor authentication, TruGrid, very easy and simple to set up there. So there we go.

You saw maybe before I started the show, the new mug that I was drinking out of. So this has my hot, angry tea in it. And this is a mug created for TechCon Unplugged this year.

And it's got a picture of all the DC stuff for 2024. I'll be playing the TechCon video as my outro today, not the regular music. So you'll see all of that. 

All right. So there is, I got all the sponsors done. All right. 

So typical onboarding, let me pull that up. And again, I did this from the standpoint of onboarding when the customer is in an agreement with another MSP. So if you're listening to the show and you've already cursed at your car or your phone or whatever, because you're like, Mark, have you left out this or that? I understand. 

Fine. I'm not trying to do a full debrief on onboarding and offboarding. Send me those comments and suggestions and let me know what I left out or what I said wrong or if I handled the situation.

So some notes that I took down. And again, I've got multiple sheets and stuff that I do because I do a different process every time I onboard. I don't do the exact same thing every single time.

But one of the things that I have noted here is that when onboarding a new client that is currently with another managed service provider, it's important to handle the transition carefully. And this is what I think is key. To avoid interfering with any existing contracts.

So the goal that I have is to work with an outgoing MSP or an outgoing tech. And I try most of the time not to badmouth them. And whenever a client said, oh, they didn't do this. 

Listen, there's just different ways of doing things. It's not necessarily that an MSP is wrong. Now, if they screwed something up, they lost data, then that's wrong. 

Now, it still may not be the MSP's fault. May have been out of their control. It may have been something that they recommended that the client didn't do. 

But the whole idea is when you're doing an onboarding and there's an existing MSP, try to do it respectfully and, you know, understand that there is an agreement in place that you want to try to honor because you want that done to you on the other end. So this is one of the things that I usually, I have done and I have not done. But one of the things is to obtain and review the client's current contracts to understand termination clauses and notice periods. 

And that is so that you can understand that if an MSP has an agreement to support a client through a certain date, well, that's the date that you look to take over and you don't try to push your way in or anything like that. You use all that time ahead of that as your onboarding process. You do your needs assessment. 

You hopefully visit the client's site and understand the infrastructure. You develop the transition plan. Those are all things that are done at the very onset of when you get the client.

Usually somewhere in that two to three weeks, you know, before the handoff, you know, you establish communications with the stakeholders. You begin gathering documentation. Um, sometimes this can be provided by the outgoing MSP. 

A lot of us, again, most of us, if things are done well, if things are done right, if the client is agreeable, we know that it's time to hand stuff over and we're going to do it in a nice manner. Hopefully it's done smooth enough that you can give some documentation early. So that gives the new MSP time to understand the network, understand the nuances of things that you've done.

It gives you time to prepare your teams, if you've got teams, for that upcoming transition. One of the things I have in here is a shadow period. And to be honest, I've only done this twice. 

With the client's permission, begin shadowing the current MSP's activities to gain insight into day-to-day operations. And this is why I offered the other MSP a chance to come on site. Come see what I've done. 

And you can critique it, you can tear it apart, but at least understand, here's what's in place. Maybe I can try to explain to you why it's in place. You know, maybe the budget didn't allow for it at the time. 

Maybe the client said, no, we'll get to it later. Maybe they just said, no, we're not doing it. Or maybe you can come in and realize that, okay, yeah, I don't know what I'm talking about. 

I didn't know what to do, so I just left it. All those things can be explained ahead of time, and then you can stop the finger pointing later. Work with the outgoing MSP to transfer knowledge, access, and control of systems.

Begin providing basic support services alongside the outgoing MSP. So this is something that I actually did in 2017 when I parted ways with a very large client. Without going into detail, I was leaving, another company was coming in, and one of the things that I said to them is that I'm not going to leave you in a bad situation. 

We had a couple of things that needed to be done to transfer some services, one of which was the Datto backup. The new company was not a Datto partner, so I knew that I could not just abandon their Datto. I would maintain the Datto until the new provider got their partnership in order, and it actually ended up taking two months. 

I don't know why. I don't know what the deal was, but I ended up supporting that customer in their Datto for two months after I stopped supporting them with other managed services. That was a situation where I had actually told them, my stuff will stay on until the new person's stuff comes in. 

So this was a situation where there was multiple offices. I think at the time it was five. No, it may have been more.

At least five offices. This was a large client. I'm not going to lie.

So I knew that they weren't going to be able to just simply deploy everything within a single day. So as they went to each office to deploy their stuff, I took mine off, and that was my way of working with the client and the new MSP so that there was no gap when it came to, at the time it was just basic antivirus protection. I did have web protection, so DNS filtering for the websites.

I did have some solo workstations that were being backed up of key people in the business that kept stuff locally on their desktop as opposed to a server drive. At the time, each of those offices had a server in place. So there were not only backups on the servers, there were processes, there was a bunch of stuff. 

So it was something that I worked out with the client that I said, look, I'll keep my stuff on even after the date until the new MSP puts their stuff on. And that one wasn't as long. I think that was maybe a couple of weeks that it took them to get to all five offices and do that. 

So these are things that, you know, if you're working with another MSP, you're the one onboarding, you know, work with them. See if there's anything else that's truly important here. So I have here, this is something that when I did have a tech support me in doing an onboarding, one of the things that I wrote specifically with them is that we need to respect the client's existing contract and avoid any actions that could be seen as interfering with their current MSP relationship. 

Number two, maintain open communication with the client and when appropriate with the outgoing MSP to ensure a smooth transition. So that was, we had a situation where, let me just say that there were times that we did have to reach out to the outgoing MSP, but we did it with the customer's permission. We didn't just contact them outright. 

We got permission to say, look, we need this from them. Do you want to contact them or do you want us to do it? And that was something that I thought was pretty important to keep as a note going forward. Anytime this happens, this is how I would be. 

Be flexible with timelines. Things don't always go as planned and focus on building trust and demonstrating value to the client during the transition period. And that's both onboarding and offboarding. 

I did not want the customer to hate us on the way out the door. They might have. I don't know. 

And it happens. I'm not going to say that it doesn't. I'm not going to say that I haven't had bad situations. 

I have. But again, one of the things going back to why I wanted to chat about this was that I was never at any time called unprofessional by the other MSP on either side. And I just thought it would be something that I should address, especially because I think that in this particular case, now I do not know that this is true. 

I cannot prove that it is true. But if I'm wrong, maybe they'll reach out and let me know because they're probably listening. The new MSP knows I have a podcast. 

They might be listening. The client knows I have a podcast. They might be listening, too. 

So if they hear this and I'm saying something wrong, just reach out to me and let me know. I'm not doing this in a way to slam anybody. But I think what happened is this MSP, as big as they are and as long as they've been in this industry, they probably get used to doing things a certain way. 

And the smaller another company is, they probably believe that we're the big boy in town, do it our way or else. And I think that getting pushback from me wasn't what they expected. And could that come across as unprofessional? I don't think so. 

But at the same time, I don't want solo techs, small MSPs, small solution providers, whatever you want to call us, I don't want us to be pushed around or relegated to... I don't want the clients to think that because we're small, we don't know what we're doing. There may be some that don't, but I'll be honest with you, most of us do. And most of us do it just as good and in some cases better than the larger MSPs.

We... I'm going to be careful how I say this. We are probably more in tune with our customers than you think. I'll leave it at that.

Eric Anthony, I want to say thank you, man. You hung out for a while here tonight. Eric Anthony runs the All Things MSP show, YouTube channel, Facebook group. 

He usually is on an hour before me, 7 p.m. Eastern. And good show. We've been on each other's shows many times. 

We might be sharing podcast space again at some upcoming conferences, notably IT Nation in November. So Eric, good to see you out there. Thank you for hanging out. 

He made a comment earlier, VLANs for the win. In my honest opinion, there will always be a need for small local MSPs. Yes, there will.

Robert, thank you for the comments there. Nice sentiments. Oh, Giles in the house, probably ironing on a Wednesday. 

Thanks for tuning in there. All right. That's going to do it. 

I've got more stuff here, but I... Man, I've talked a while here. I do want to, even though we don't have a guest, I have a Florida Man video for you. Last week, I put, I believe, three Florida Man links in the show notes. 

I don't know how I'm going to put in this time, but people always wonder if my stories are actually timely in a sense. And so I'm just going to let you know. So if I go into my news system, because I've got a news system for Florida Man. 

So these are all topics that have come in. They're definitely today, but most of them are within the last hour or two. Man dies after catching fire in Florida Mall parking lot. 

Florida Man tries to pass off DUI by swapping seats with passenger after crash. Let's see here. That’s shouldn't talk about that. 

Florida Man continues to adjust to life after losing an arm in an alligator attack. That was from about a month ago. Let's see here.

Oh, the nursing home story. I'm sure you've all heard about that. Sad story there.

Man tries to kidnap woman in Walmart parking lot. U.S. Man died because doctor removed wrong organ and procedure. I saw that story earlier today. 

This was in a North Florida hospital, and the U.S. Man was actually from the state of Alabama. So somebody came to, so from Alabama, came to Florida to get a surgery, and we removed the wrong organ. That doctor is going to be sued.

But I have a video Florida Man story for you tonight. And here it is. So what I would like to do, if you're comfortable with it, is put you through some filter body exercises to make sure that you're not. 

No, I'm not. I'd be happy to do that. Okay. 

But I will tell you, I have done nothing wrong except for two people who caught me off. Breaking news. You are watching new dash cam video of Naples police arresting the city's mayor for DUI. 

Thank you for watching NBC2. I'm Peter Bush. Witnesses told police that Mayor Teresa Heitman was driving drunk behind them last night on 3rd Street, followed them home all the way to 16th Avenue South, and even did some damage to their front lawn. 

NBC2's Sarah Mankiewicz is in Naples tonight walking us through this brand new video. She was literally almost running into my Jeep and followed me home. You're listening to the moments a Naples family calls 911, saying the mayor was driving drunk Wednesday night. 

Why did you follow us home? Why did you pull into our grass? No, we didn't. We're driving down 3rd Street and we saw you slam on the brakes and give yourself a headache because you almost ran us over. You can hear Mayor Teresa Heitman in the background, denying she did anything wrong. 

Are you guys outside? Then why did you come here? Well, the mayor stopped here at this house along 16th Avenue South, but the homeowners say she actually hit their mailbox and then told them that it wouldn't matter if they called 911 since she's the mayor. I don't know if she's claiming to be the mayor. I don't know who she is. 

She just drove. She's drunk and she just drove on our lawn. But once Naples police officers showed up, she wanted to be a regular person. 

Don't call me mayor. I am Teresa Heitman right now. Okay.

I'm not the mayor. Police say they smelled alcohol on Heitman's breath. Have you had anything to drink tonight? One glass of wine. 

Just the way you're speaking to us and I can smell it. So I was just making sure that. Smell what? They performed a sobriety test. 

Use your eyes only to follow the fence. All right. Okay. 

You ready? I'm sorry. It's okay. I've never been to this before. 

Okay. Okay. Go ahead. 

I'm going to follow the pattern. Then another sobriety test. One.

Okay. Which she failed. All right, ma'am. 

We're going to be done for tonight. Okay. Unfortunately, right now you are going to be placed under arrest for driving under the influence of alcohol. 

Her blood alcohol level was 0.0169, more than twice the legal driving limit. The for a comment, but she hasn't responded. I'm local along 16th Avenue South in Naples, Sarah Megowitz, NBC2. 

And there you have it. One of Florida's finest. And I will have a link to the video for those of you that are listening by audio only. 

You can go to the show notes and find the video of our fine Naples mayor right across Alligator Alley, folks. It's about an hour and 15 minutes. Used to go there all the time, hang out in Naples. 

I'm going to go see the mayor, see how that goes. That is going to do it for tonight. I again want to thank everybody for hanging out and putting up with my editorial comments for tonight. 

And we'll find out soon if there's any backlash and I'll let you know. I will be doing a show next week, even though TechCon is happening, I will be flying out Thursday morning to get there early and I will be doing a show Wednesday evening. And I believe that is at the regular time with a new guest to the show. 

And actually, I didn't even think about this. I think he's a large MSP. So I wonder how much offense he may have taken to what I said tonight. 

Brian Weiss is going to join me next week. So that's going to do it, folks. Head over to the IT Business Podcast page, support the partners on the show, NetAlly, SuperOps, TruGrid, even some of the others that I don't mention all the time, but they've been a supporter in the past. 

Thread is out there. Synchro is still on there. Instant Housecall call may still be on there. 

I don't know. But head over to the website, check that out. Check out any other shows that you might have missed. 

I know some of you are way, way, way behind. So I'll give you some time to catch up soon. That's going to do it, folks. 

We'll see you next time. And until then, Holla!