Hey, Channel Insiders. Before we dive into today's episode, I've got exciting news. Channelinsider.com has a brand new look. We've completely redesigned the site to make it your ultimate hub for channel news, insights, and stories. With a sleek new layout, smarter navigation, and faster access to the content you care about most, you'll never miss a beat. Go explore the allnew Channel Insider today. Hey channel insiders, welcome back to channel insider partner POV.
I'm your host Katie Bavoso and my guest today is Brad Gross, founder and president of the law office of Bradley Gross PA. If the liability of unchecked AI tools running rampant in your customers environment keeps you up at night, or you think you can just write your master service agreement with Chat GPT, you'll first want to hear some valuable free legal advice from the man known as the attorney of the channel. Welcome, Brad. >> Thank you. Good to be here.
Thanks for having me. >> Great to have you. So, I know that technically you are like a few miles from me in Massachusetts right now. We could have done this in person. So, I appreciate you doing this virtually still and it's great to see you and know that you're here experiencing uh the area as a as a New Jersey, New York transplant myself. I can appreciate that you're up here in New England. >> That's right. Everyone's out here complaining about the heat like, "Oh, it's so hot." Thinking, you know, I'm originally from New York and now I'm in Florida.
I said, "You're dealing basically with a flidian. I don't I don't think you should be talking to me about heat. You don't know from heat. >> You don't know heat. >> You don't know from heat." Well, thank you so much for being here today. And I want to give a little introduction to who you are because as I told you, and I'm not blowing smoke here, I I just had a couple of my co-workers come back from GTIA Channel Con, and they were like, "You got to talk to this guy, Brad Gross.
He is the channel lawyer. He is the lawyer for MSPs." And that was that was funny. I have it in my notes with the capitalized. And I was like, how does one become the lawyer of the channel, let alone know what the heck is going on inside of this very niche industry, inside of another niche industry? So Brad, why don't you give me a little breakdown? I first want to know how you got to where you are. And as I understand it, you're a bit of a hacker turn prosecutor.
Is that a correct statement? >> Well, that's my past. Are you are you a cop? I'm just making sure. Oh, okay. Just um so starting from the very beginning, you're right. I I started off as a teenage hacker breaking into the municipality computers at the age of 11 and 12 and hacking through software, you know, with my 300 baud modem. So those of you who go way back with computers will know what that is. Uh and eventually ended up as a prosecutor putting hackers in jail.
So that was sort of a a turnaround there. I helped found the internet and computer crime division of the uh Nassau County District Attorney's Office, the Miami Dade State Attorney's Office, and then when I went into private practice about now, wow, 26 years ago or so, uh since I had that technology background, it was sort of a a natural evolution into where we are today. How did you discover the channel itself and become so familiar with what managed service providers face in their day-to-day legal business activities? >> So, it's interesting that you brought that question up right after you mentioned GTIA because it was actually the predecessor company to GTIA, which was um CompTIA that started me in that path.
I saw this industry consortium back we're talking like 2001 or so called and it seemed interesting to me. I was I had this technology bent. So I got involved in that organization. Uh I started out with uh security the subcommittee for for basically internet and and computer network security. And I started representing because through through contacts I made there technology companies that were back then called ASPs, application service providers.
Those were the predecessor companies to MSPs that you have today. So I started representing one and then another and then another. And then, you know, it's just through a lot of writing and a lot of speaking and a lot of just being there that people got to know me and it sort of built onto itself over the years. >> So, I did mention obviously MSPs a few times, but I'd like to get to know your client base a little bit more. I know it's primarily MSPs, especially ones that serve the SMB sector.
That's typically their bread and butter, but who who are your clients? Are do you have any others outside of that MSP realm? Sure. So we represent technology companies of all sorts. Okay. Any company that has technology that it wants to monetize or a company that requires technology uh to leverage it to then commercialize it or or make their operations better. And that sounds like a lot. I mean theoretically includes nowadays almost any company. But usually these companies are very very technologyoriented and centered.
So, it's not necessarily a company that uses a point of sales system because, you know, hey, that's technology. No, we represent the companies that make the point of sales system. It's not just having a credit card reader. We will represent the company that makes the credit card reader that has that technology. So, it sounds very broad, but as you really look into it, it sort of narrows down into a sort of a technology niche uh niche. But I would say that the bulk of our practice is managed service providers, right? the companies that provide professional information technology services to others.
That would be the bulk of the practice. But we certainly have um people in the um in the gaming industry, uh all kinds of e-commerce, hardware and software vendors and so forth. We represent many of those as well. In addition to years of experience and obviously years of knowing companies uh like CompTIA and now GTIA and going to events like that, what would you say makes you so specialized to operate in this space compared to if I just went to another attorney down the block?
I would say that the real value that we bring to the table is uh our ability to take these complex topics and these complex technology uh uh solutions and make them meaningful in a plain way so that people who require these technologies can understand what they're getting. We are sort of the Rosetta Stone, if you will, of technology. You'll have a solution provider that will come to us and they'll say, "Listen, we do this, this, and this." And it's very sophisticated.
It's very fancy and complex and so forth. And they said, and they would say, "We need an agreement to uh offer to our consumers who are dentists, who are accountants, who are, you know, manufacturers. How do we get an agreement that protects us but isn't so complex that somebody who's not a technology person would understand it? Since we are not only attorneys, we're also programmers. We know how to take the the solution and sort of like I said, translate it, be the Rosetta Stone, such that at the end of the day, the deal will go through because not only is everyone protected, but they all understand each other. they are all on the same page.
Nobody is turning around going, "Well, I don't exactly know what this is, but hey, I'm I'm going to buy it and see how it goes." That's a road to disaster. Everyone has to understand what they're selling and what they're getting. Those are the best kind of deals and that's what we structure all the time. >> Well, let me like really put my money where my mouth is here asking a very distinct question. Obviously, I've been to your website. I've explored it.
So, let me deep dive into an example. On that website, you emphasize that many MSPs operate with patched together or even copied over master service agreements, MSAs. What are some of the most critical traps that you see MSPs fall into with their MSAs? And how should they proactively address those to ensure enforcability and clarity? I'm thinking about the MSPs that are listening right now. How can they avoid some of the most common mistakes that you could see?
A lot of MSPs believe a few um candidly, entirely incorrect uh uh foundational uh uh things. What do I mean? Well, first of all, they believe that if their MSA, their master services agreement, if it has big capital letters, right, in bold print, they think, "Oh, I'm protected because it has capital letters." Or they'll see something that says, "Well, my liability has been limited." Right? those big long paragraphs that you see attorneys write about.
We wave incidental and special and consequential and you read all that, you think, "Wow, I guess I, you know, this looks very official, so we're protected." They are usually poorly written, they don't mean what you think they mean. And what people think is that because a lawyer wrote it that they're going to be all set and protected. and we candidly built a law firm on on companies that believed that and then ended up with problems. So, the first thing that I would suggest an MSP do is if you're going to engage an attorney, whether it's us or anyone else, make sure that the attorney understands the industry.
Okay? You shouldn't have an attorney that writes a contract for you but also does your bankruptcy and your will tra and estate. If an attorney, you know, if on their website they say we do bankruptcy, real estate, and technology law, I would tend to worry about which one of them they do the best, you know, and and how much experience they have in it. Because the thing that is interesting about this industry is that there are so many what I call realities. realities that exist in other industries but in this one they all converge right like for example every industry every service industry has uh situations in which the customer doesn't listen to the professional patients don't listen to their doctors clients don't listen to their lawyers and in the IT industry customers don't always listen to their managed service providers okay that's common in every industry you will often find that you are working alongside another professional.
So a doctor might find out that he's the second opinion for someone else. A lawyer, right? The second opinion. MSP might come in and say, "Oh, there's another vendor doing something. So we're going to be involved too. And I'll give you just one more." A lot of industries will find themselves with transition. I'm leaving you to go to somebody else, right? Or I'm coming to you after leaving another professional. Okay, that happens everywhere. But only in this industry does it always happen all at the same time.
This industry has all these different realities coming in that you'd say, "Well, doctors have that, lawyers have it, accountants, manufacturers." Yeah, but in this industry, they all come together. We always have clients that don't listen to us. We always have customers that are transitioning from one to the other. We always have uh co-managed situations. And there are so many of these realities that any attorney who tries to tackle an agreement in this space has to understand not just the individual realities but the fact that they converge >> and how they will impact the relationship overall.
That is the number one thing that an MSP should be thinking about, should be looking for in an attorney before they hire that person to put finger to keyboard and start typing. >> Some very good advice there. And I want to go a little bit more deeply into some of the things that MSP should be considering because we obviously live in an age now where AI is the buzzword of the moment. It's the technology of the moment. It's also meaning that we're all kind of downloading our own tools and applications and LLMs of choice onto our work laptops.
And I'm just thinking what a risk nightmare that is for a lot of managed service providers that have these applications on their clients, employees computers that they don't know about and that that could be inviting in uh a door uh for a threat could be opening the door that is for a threat. So how do you help MSPs one protect themselves from their client's bad behavior and then how do you help them be able to avoid liability when the worst inevitably happens in some cases?
So the topic that you're touching on is called shadow IT, right? This is when uh or at least in part this is when a customer will start doing things on the network that the MSP is totally unaware of and the MSP may find out about it when something bad goes on. So the concept is that MSPs not only have to be aware that that's going on, but they have to take precautions in their agreements such that if they discover it, they have a remedy. they have a way to resolve this before it all blows up.
So, for example, one provision should be that the customer, the MSP's customer has to take the MSP's advice and if they don't take the MSP's advice and something bad happens, that is on the customer, not on the MSP. So if they discover now if you have that type of provision and the MSP discovers shadow IT a lot of things going on in the network that shouldn't be there and they say listen I'm advising you not to do that anymore I'm advising you to take that off the system let us do our job and it either continues or the MSP doesn't yield to the advice MSP doesn't have liability anymore because it's in the contract the other thing the the other question that is touched on by your by your question is to what extent should an MSP require exclusivity over a network >> because if the MSP has exclusivity, it can lock down that network.
So AI and all these different things can't be downloaded. But then of course you have the customer saying well I have an internal IT department. I have others that have to do things to this network. I can't give you exclusive access. So I think that the customer has to understand the paradigm in which it's working with this customer and sometimes require exclusivity and if it doesn't um if that doesn't work then have a provision in there that says listen we're not going to take exclusive control but understand okay you should not install things without telling us you should not move hardware in you know install uh new devices without telling us and if you do that's on you customer anything that happens.
So once you have those types of provisions, the MSP is now starting to become more flexible, right? We'll allow you to make changes. You can you want to download AI, we're telling you not to, but if you do, that's on you. See, you there's flexibility there. You just have to think of those realities. And if you don't think of them in advance, then when it happens, what do you do? The answer is you have to hire a lawyer. We don't want to have to hire lawyers. >> You got to go to Brad. this podcast by the way if you're listening uh we are billing you by the hour as you are listening to this so just keep that in mind >> yes everyone just send me their billing address of course >> let's go on to my next question with that in mind let's say that the the customer and the MSP are just butting heads constantly you actually cover a topic that I think is is really overlooked quite often in your podcast the broadcast which is just chef's kiss the coolest name that you could possibly give a podcast so thank you very much >> thank You spoke about the risk of improper offboarding specifically of clients themselves.
What essential legal missteps do MSPs make when decommissioning clients and what best practice steps could save them from costly pain? And I'm specifically talking cost as in financial cash money. I'll tell you the number one misstep that MSPs don't think about and here's a reality. Okay, think about this. Everything ends and in this industry usually not well. I've heard about situations in which a customer will say to an MSP, "Listen, you've done a great job.
Your service is unbelievable. Your price point, I can't match it. I mean, I don't even know how you make money on me." Okay? You're you're a beautiful person. I'm leaving. I've heard about that in Legend, but that's like Loch Ness or UFO, right? People have seen it, but I've never seen it. People say it exists. What usually happens at the end is that people are fighting or they're close to fighting, right? The customer doesn't think it's getting the services it's supposed to.
The MSP thinks that the customer doesn't value the services it's it's offering. That's how things end. And what we have found is that more often than not, what an outgoing customer will do is they will simply bring in another vendor. that vendor will then cut off all kinds of things in the network, especially they will decommission these software agents. And so for those of you I know if you're an MSP, you know exactly what that is, but if you don't, software agents are the little bits of code that are on the customer's network that allow the MSP to remotely log in, monitor, manage, and so forth.
And what an incoming vendor will do is they'll say all these agents we're disabling them. So they'll disable them. So now the existing vendor can't monitor and manage. The problem with that is that the MSP who installed those agents, they are being built for them by the upstream provider. It might be Microsoft. It might be whomever it is. And if you disable those agents, the the MSP can't access them, can't remove them, but it's still getting build. it's still getting build.
So the MSP will say to the customer, you have to enable, you have to reenable those so I can get rid of them. We're not enabling them because then you're going to have access to our network and we don't want you to have access. And here we go. One party is being build. You have an incoming vendor that says, "Oh, don't worry about." And this is how the most vicious feuds start. So what I would recommend to MSPs as a best practice is to make sure this is a reality that you know reality check that your contract talks about these software agents and how if there's going to be a transition to an incoming vendor it has to be a staged process.
You should even recommend an overlap and in all cases nobody is to disable those software agents. they have to be disabled in an orderly way, in a predetermined way. MSPs forget about that. It costs them thousands of dollars. So, that's a reality that they should be thinking about. >> I hadn't even thought about that. So, I think that that's incredibly valuable advice and I appreciate you bringing that up. You mentioned the vendors. Obviously, that equipment, that hardware, even software in many cases is coming from an upstream vendor.
MSPs are often acting as resellers to an extent. So, with that in mind, are there any red flags or things that they should look out for in those contracts and a vendor's routine before they sign their life away to a partnership with a vendor? >> Yeah. So, I think that what MSPs face is that these vendors have these boilerplate contracts that they can't really negotiate. I mean, you could try to negotiate with Microsoft or Amazon Web Services. Good luck.
They're basically non-negotiable. So instead of an MSP trying to figure out how to negotiate these things and how it should approach these these uh these solutions before they take them on. Instead I would suggest that MSP simply learn what these contracts mean. actually understand what you are receiving because as you correctly pointed out ultimately most most of the services that an MSP offers to its customer it does not provide directly it facilitates it resells.
So, it behooves the MSP to actually read the upstream provers agreement, understand what it says, understand the restrictions. That way, it can then pass through and explain those restrictions to its customer because the MSP should not be offering its customer more than it's receiving from the upstream provider. My advice is read those agreements, understand the restrictions. Some of them actually have restrictions that say you MSP, you have to tell your customer the following.
Boom, boom, boom, boom, boom. Whatever it is, you have to read the agreement. Don't just assume that, well, it's Microsoft and it's not negotiable. And I just use Microsoft as example. Uh, you know, it's this vendor, it's not negotiable, so I'll just sign it and I'll have an MSA with my vendor with my uh customer. that agreement has provisions, restrictions that you really have to understand because if you don't and something goes wrong on this end with your customer, it's going to work its way right up to that contract and what it says.
You have to know what it says. Don't just sign these things because they're boilerplate. You don't read them. You have to read them. >> Excellent advice. And what have you been most advising your clients on lately? Is there a subject that they've been consistently bringing to you that you've kind of threaded together as an emerging trend or a new trend that you're seeing? What's been that experience like for you? >> So, the thing that that I have been talking to MSPs the most about, let's say, over the past few years >> and continuing through today and probably into the near future, >> is managing your customers expectations.
Let me tell you what I mean by that. The odds of an MSP failing to provide or facilitate a service, just absolutely failing to do it are very low. It is very rare. Okay. Now, I've been doing this 25 years, longer than any attorney that I've heard of in this industry. I've handled more cases than all these lawyers. Have thousands and thousands of MSPs. So, I have a good sample set to look at. And I can tell you that in that period of time, the most vicious, the most belligerent, the most expensive battles between MSPs and their customers always relate to a mismanaged expectation.
That's what it is. It is not that the MSP failed to do something. That's not it. Instead, it is that the parties will sign some sort of quote, statement of work, whatever it is, that says A, B, and C. And everyone walks away happy. But what the MSP doesn't realize, and what it could never realize is that the customer, while it's signed A, B, and C, customer thinks AB, and C includes D, E, F, GH. Why? Because the customer doesn't understand what AB and C is to begin with.
So now something wrong occurs, something bad happens and the MSP says, "Listen, we gave you A, B, and C." And the customer says, "Yeah, but where's D, E, FGH?" What do you mean? Right? And the example I like to give, here's a real world example happens more frequently than than MSPs would care to admit. So you pick a time. Let's say MSP's customer calls the MSP at 11:00 a.m. and they say, "Hey MSP, our biggest customer will be here in 30 minutes." Okay, 30 minutes and uh his files are gone.
But where'd they go? I don't know where the files went, but I need them back. So, please get them to us in the next half hour. Thank you. And now the game begins. Can the MSP do it? And the answer is no. Why? Because I didn't give you all the facts and the customers won't give you the facts either. What the MSP will find when they look into it is it's almost a terabyte of information. They might be cryptolocked. They've unmapped drives, whatever it might be.
So, they call up the customer and they say, "Listen, we can't do it by 11:30 today. We looked into it. We can't. But here's what we'll do. 9:00 a.m. tomorrow, you're up and running. We're going to have everything up and running for you. 9:00 a.m. It's a problem." Because the customer is not going to say, "Well, tomorrow 9:00 a.m. that sounds great. Thank you so much." Right? No, that's not what the Right. What's the customer gonna say? This is ridiculous.
Right? What have I been paying you for? I'm looking at our contract which says backup and disaster recovery. Right? This is my disaster. I paid you to recover. So, I need recovery. Where does it say that I have to wait 24 hours? Where does it even say I have to wait a half hour? This is urgent. This is critical. And now we're going back and forth. Did the MSP do something wrong? No. It It didn't want to overpromise and underdel. But did the customer do something wrong?
No. It just wants its stuff back. But we have a problem, don't we? A mismanaged expectation. And that causes friction. And friction causes lawsuits. And those are the most vicious kind. And it's because the MSP and the customer didn't understand each other when they signed that quote for backup services. And if we're going to point the finger at anyone, I pointed at the MSP in that case. Why? Because the MSP should have told its customer when they entered into that agreement, listen, you want to get your stuff back, we get it.
Here's how you'll be able to request your stuff. Here's what we do when we receive your request. This is what we look into and understand that recovery is not just pushing a button. It depends on file size, types of files, internet connection, right? A whole bunch of variables. And then once we've confirmed that there are certain objectives we'll aim to meet. Of course we can't promise them and this is what you should expect. All that sounds wonderful but no one includes that in their agreement.
So as a result you have this friction. In my view and this is what I preach to these MSPs all the time. You need to explain these things all of these services. I suggest doing it through a services guide through a separate document like a user manual >> that explains what your services do, what they don't do, what the customer should expect from you, the MSP, and what you should expect from the customer. In order for these things to to go uh forward properly, you need to have a user manual.
We've been working on these things for years and this is the solution that I came up with about four years ago and it works. A user manual. MSPs are always scared to put in writing what they do and what they don't do. They think that with the absence of language, the absence of information, they'll be better off. They're not better off because if you don't provide information, you know who makes up the rules? The customer. And trust me, the customer's rules aren't the rules that you're going to want.
They're not. So yeah, that is what I've been preaching for the past few years. It's the number one issue I think affecting MSPs these days. >> I really like the sound of that. It's funny because you mentioned, oh, if I don't bring it up or if I don't set the rules, then that'll reduce friction between myself and the customer in that relationship. It reminds me of people who think if I don't go to the doctor, I won't be sick. And that's not how that works.
You're going to run into problems. No, it's not. >> Call my doctor. Okay. Now I thank you. Wait a minute. That's not how that goes. >> Oh, I should have remembered that. Yeah. No, but you're right. It's they think that the absence of information, the absence of knowledge is either a good thing or is probably at least will allow you to coast and it it doesn't. What ends up happening is at some point something goes wrong. The customer is going to look at this in the light most favorable to it, not to the MSP.
And that light is then that light's going to shift back and forth between the customer and the MSP because they didn't actually at any point get together and explain what the service involves, what it doesn't include, right? Expectations. But if you have that, then the parties can sit down and cooler heads can prevail. You can say, "Well, we have a services guide. We gave that to you at the outset. This is how we're going to handle things." Well, I really need it now.
I understand and we're going to try to get it to you now. We're going to try, but understand like we said here, there are certain variables that we're going to have to look into and explain it. Explain it. All but the most difficult customers will if you present it in the way we're I'm suggesting. All but the most difficult will actually understand. They will they'll say, "Okay, I get it. You got Could you speed it up though?" Yes, we'll try to speed it up.
That's how things should go. >> What were some of the uh some of the folks who were attending Channel Con asking you about the most? Did you notice any patterns there with people coming up and asking, "Hey, Brad, you're here. Can I get some free advice?" >> There are a couple of things. So, you know, at Channel Con, there were lots of questions being asked, but a lot of them involved AI and not just in the way you'd think. Um, it wasn't just AI as a service, you know, and how do we uh accommodate that in an agreement and so on.
What we actually saw a lot of was our thoughts about using AI to create agreements. And as shocking as it was to me because I actually wrote a book about 2 three years ago that one of the chapters the name of the chapter is I want you to use chat GBT for your next agreement because I have kids in college and I need the money. That was the chapter bec and I actually in the book Oh, that's true. And in the book, I actually show an agreement that Chat GBT created and how it's god awful.
And you know, people were coming up to me saying, "Listen, why wouldn't I, you know, if I get into trouble? I understand we're going to call you, but why not use AI to create these types of agreements?" And my first, you know, in law school, they teach you it's a Socratic method. You answer questions with questions or you address issues rather with questions. So I said go into your agreement and let me know whether your chat GBT agreement mentions the word co-managed.
Let me know whether it mentions transition. Let me know whether it mentions regulatory. Just those three words which are all very important. Of course it doesn't because these are realities and in truth AI hasn't caught up with the realities because there are too many of them right now in the industry. So what we were asked about is a lot about, you know, what we think about the advent of AI and contract creation. It is not ready for prime time. And I don't just say that out of self-interest.
It really isn't. The other question that we were asked involved, of course, integration of AI into solutions and how does that affect the MSP's agreements with its customers? And the answer is, well, it doesn't necessarily affect the agreement directly. It affects privacy. It's more of a privacy issue right now, a privacy and data security issue. It's not so much of a service issue because if your MSA is written correctly, your master service agreement, if it's written correctly, it will be service agnostic.
It doesn't matter whether you're using something with AI or not, but AI involves privacy and data security. So I think that MSPs and we had these discussions at GTIA would be well advised that if they're using AI in any significant way that they set up policies and convey those policies to their customers so their customers understand where their data is going, how it's being used, whether it's being saved, whether it's being used in a training model elsewhere.
It's a security and privacy issue. It's more of a policy issue than a than an agreement issue. Very good advice. And I I cannot get over how funny the chapter name is. Please use chat GBT. I need the money. >> Yeah, I read that because I have kids in college. I need the money. No, it's true. >> Please make mistakes. It's what runs my business. >> I encourage it. Yeah. Brad, when you think about a success story that you love to tell to really represent the value of your office, the value of your services, your experience, a culmination of these 25 years of learning and really knowing what this industry needs, what is a success story that you can legally tell me without mentioning names that you really like to think about and say this is an example that really shows that why we're such a cut above the rest when it comes to serving the channel.
So I think that especially this is the case in this uh SMB small to medium business area. It's not just one story. It is a lot of stories collectively that have the same issue, the same story line and the same result. By that I mean you have these small companies, they're just starting out. They have limited budgets. They have limited time, limited revenue and they know they need an agreement. They don't know where to go. They don't know where to start.
They'll see templates online. They'll see, you know, they'll get uh different templates from different areas and and they'll say, "I really don't have the money for this right now, so this is what I'm going to go with." And to the extent that they're open to listening, someone like me, what I will tell them is a good agreement is like an insurance policy that if it's written correctly, you only have to make that investment once every 3 to 5 years. if it's written correctly, once every 3 to 5 years.
And by making that investment upfront, you're going to not only save yourself from litigation, though candidly, most MSPs don't end up in litigation, okay? But here's what you're going to save yourself. You're going to save yourself time. Time in having to explain your services to your customers. Time in having to resolve disputes involving realities of the industry. That time is precious. You need that time to research more solutions, to develop your company, to right, to get out there and do the things you do best.
A good contract gives you that time back. And my point to these emerging MSPs especially is invest in a good contract paradigm upfront and you will immediately recover all that time that you would have otherwise spent in the future. And I can tell you without hesitation that all of these MSPs that take that advice, they say, "Okay, you know, if I have to have a budget, okay, I'm going to carve out a couple of thousand bucks, but I'm going to get a good set of agreements.
I'm going to set myself up, right?" Years later, when we talk to them, and we're talking three, four, five years later, they'll say, "Hey, maybe it's time for an update." And I'll say to them, "How you doing? Like, how has it worked out, Brad? You have no idea how many times your agreement has saved us. Really, you have no idea. we had this and then they'll tell me their stories. We had this crazy client that wouldn't do this this this but we pointed to the agreement that says this and then they you know capitulated they Right.
Right. So the success story is not just a single MSP but is the collective MSPs that are starting out that are contemplating whether they want to spend on a good set of documents 100% of the time. I have yet to have an MSP that called me up and said I spent this money didn't really need to. didn't need to. Nah, I've never heard that in 25 years, 26 years of doing this. I've never heard it. So, that's a success story. Businesses that understand the importance and of of not only having a good set of agreements, but understanding that you're paying for time.
You're paying to recover that time. That's where the most success happens. >> Brad, where can we find you on the road through the rest of the quarter so we can ask you more questions like these? Well, first of all, anyone can always hit me up on LinkedIn, Bradley Gross on LinkedIn. We're going to be I'm going to be in Phoenix in another month. Uh, you know, these these I'm going to be speaking at IT Nation in Orlando in November. So, these events pop up all the time.
But if they email me at brad bradleygross.com or like I said, hit me up on LinkedIn. Be happy to tell you where I'm going to be. If you want to chat with me, I'm always available. >> What about your your website? Would you mind saying that for us so we can go visit that for our listeners to visit? >> Sure. So it's bradleygross.com www.bradleygross.com. The podcast that you were talking about earlier is uh technologybrad.com not technology podcast but broadcast cuz I'm very clever like that.
So I encourage everyone to tune in and listen. It's free. It is devoted just to MSP's issues and yeah I enjoy doing it. >> Brad, thank you so much for your time today. I've learned a lot. I know our listeners have learned a lot and I just really appreciate you taking the time to sit down with me this morning. >> It's good to be here. Thank you for having me. >> Thanks so much to Brad for joining me and thank you for watching or listening. You can check out every episode of Channel Insider Partner POV on channelinsider.com or watch us on YouTube at youtube.com/ channelinssider_news and trends.
You can also listen to us as a podcast wherever you get your podcasts from. Don't forget to like, subscribe, and follow wherever possible so you never miss an episode. Come connect with Channel Insider on LinkedIn and X, or come connect with me, Katie Baboso. Once again, I'm your host, Katie Baboso, and I'll see you next time.
This transcript was generated automatically from the
video's captions and may contain errors.
