Episode 136: When SaaS Goes Surfing

 

Transcript:

Rich: [00:00:00] Wanna know what the smartest people in the SMB channel are reading? Check out Channel Holic, the industry blog from me, veteran technology journalist and analyst Rich Freeman. Covering managed services, AI, cybersecurity, and M&A, Channel Holic delivers sharp analysis and insider perspectives trusted by MSP executives, technology vendors, and IT investors alike.

If you wanna understand where the channel’s headed next and why, check out Channel Holic at

David: www.channelholic.news.

Rich: And three, two, one, blast off. Ladies and gentlemen, welcome to another episode of the MSP Chat Podcast, your weekly visit with two talking heads talking with you about the services, strategies, and success tips you need to make it big in managed services.

My name is Rich Freeman. I am [00:01:00] Chief Analyst of Channel Master, the organization responsible for this show. I am joined side by side digitally by your other co-host, our CEO and Chief Strategist at Channel Master. His name is Erick Simpson. Erick, how are you?

Erick: I’m doing well, Rich. I’m I’m at home base here as we record this podcast, but you obviously aren’t in your usual home base.

You wanna share with our audience where you are? in San Diego?

Rich: Yes, indeed. And the the folks in our YouTube audience will know just by looking behind me, I am in a hotel room. They won’t know where that is or why I am in a hotel room. I’m actually in a hotel room in Plano, Texas right now because I am attending the 20s Vision Conference which is their annual event.

The 20 for folks who don’t know, is essentially an MSP roll-up. They have they got 49 MSPs now, and they’re gonna hit 50 I’m sure pretty soon. And we’ll probably end up talking about some of what I learn here at the show in next week’s episode. But that is why I’m here in in this [00:02:00] this lovely hotel room.

Erick: And in the extreme heat that’s happening in Texas these days, right? So hopefully you’re maintaining your climate control as much as possible while you’re doing your rounds at the Vision 20.

Rich: They’re good at many things in Texas, and air conditioning is one of them.

So yes, thank you. I I am comfortable in here, as is everybody downstairs at the conference. They’ve definitely got the refrigeration cranked up.

Erick: Awesome.

Rich: So Erick, let’s dive into our story of the week, and it’s an interesting one coming to us from Synchro. Very recently, Synchro announced that they are the as far as I know and as far as they know the first RMM PSA provider out there in the managed services space to have not just a connector for their software that plugs you in via MCP to Claude but basically the first to have a native authorized.

They applied to Anthropic. They said, “We’ve created a [00:03:00] connector that uses MCP to connect the Claude chatbot directly into our backend RMM PSA.” They passed the application process, were approved. And so right now if you are a Claude user, you can go into the connectors directory and you will find Synchro listed there, the first, like I said, RMM PSA vendor to do that.

Now this is not just something that they are doing for the s- at this point in time, relatively modest number of MSPs who are looking to turn Claude or ChatGPT, something like that, into the front end for how their technicians run the business. But it, th- they are also basically placing a big bet on the f- on their belief that this is how all MSP, or most MSPs basically, are going to want to operate down the road.

And they, th- there will always be, I’m sure an interface to the Synchro software. That’s not going away. But this isn’t just something they’re doing for a few MSPs out there. It’s something they’re doing because they really believe [00:04:00] there is a kind of convenience that comes with having this cutting edge LLM interface that you’re using to do lots of different things during the day and to have a natural language conversation with Claude or whoever about your clients and about the issues they’re experiencing and the network conditions, and is the backup current, have we tested, all that kind of stuff.

Now we’ve, I’m sure, spoken about this on this show in the past. I wrote my first story on the possibility that someday MSPs will use tools like Claude to interact with RMM and PSA system about a year ago, and that was based on a conversation I had with someone who joined us on the show back in June, Elliot Hyman of Lyra Technology Group, part of Evergreen.

And he had an MSP within Lyra, whose name is Tim Gwinn, for folks who know him. Tim had been playing around with it. This is over a year ago now, and at the time it struck me as this really interesting possibility. It became a little bit [00:05:00] more concrete as something that actually might catch on a few months later when I was at this event, when I was at Vision 2025 a year ago and I interviewed Rania Sakr, the CEO of Kaseya, and I brought the topic up and she said, “Yeah, this is something that we’re thinking about, we’re working on.”

Relatively recently Kaseya introduced an MCP server to make that kind of interaction with their data possible. So in the year since that first was introduced to me as something that who knows might happen, we’re seeing vendors take that possibility seriously. And then the question is just going to become how much, to what degree do MSPs take that possibility seriously as well?

Now w- a few weeks ago on the show, we were joined by Yaron Bach- he is the CEO of a company called IgniteHQ. They have a a brand new AI

native RMM PSA suite for MSPs. I don’t know if he saw the news from Synchro or read my story, but he got on LinkedIn a few days back and was asking the [00:06:00] question, ’cause he clearly has an opinion on the matter, do you as an MSP really want to be sharing all of that context that you’ve accumulated with a third party LLM kind of tool?

I can imagine another question that some of the folks we’re familiar with some of the vendors we’re familiar with might be asking, which is just is the Claude connected to your RMM PSA? Will it be able to provide answers that are specific enough to you and your customers and your experiences?

Or will the answers potentially be poisoned by the large language model, where what you really maybe need is a small language model that is 100% or close to it unique? So there are objections that I know Synchro competitors out there are raising right now that MSPs will need to consider. But I do think just based on what I’ve seen out there talking to MSP…

And in fact, right here at the show this morning at breakfast I was talking to some MSPs and they were just talking about the interesting things that they’re doing [00:07:00] with Claude and ChatGPT and MCP and Cla- They at least don’t seem to hesitate to do that kind of thing. They’re intrigued by the possibility.

So Synchro has a pronounced point of view on this being the future of how help desks operate and how MSPs operate. They clearly are leaning hard into that in terms of how they build the product now and going forward, and it’ll just be very interesting to see are they the first and only to do this in this particular way, or are we really gonna see some momentum pick up both on the vendor side and the MSP side?

Erick: Rich listening to your intro reminds me of that famous scene in the first Matrix movie where Agent Smith has got Neo in a choke hold, and he says, “You hear that? That is the sound of inevitability.” It’s… I feel that this is the sound of inevitability. I think that, even [00:08:00] from, my own journey with AI as I, continue to vibe code and connect Claude and other AIs to our platforms, and then really training.

I think it’s a, it- it’s a valid question is how do you secure and govern the data? Which I’m very, trying to stay very on top of. I’m not trying to leak any data, anything like that, taking all these precautions. But the more that I connect C- Claude to the different platforms that I use on a day-to-day basis for doing what I need to be doing, and then leveraging the in- the Claude interface myself and just, asking it questions and having it surface patterns and trends that I’m not even aware of and giving me that rich context.

But then I’m pushing back and training it more and creating skills and and, the MD file, MD files that it uses for context and all this other stuff. I’m really, the last I’d [00:09:00] say 90 days have been quite an awakening as I’ve spent more time doing it And then the last piece that I want to try, because I’ve been p- speaking to a lot of people as well, is connecting that now to Intercom, another connector that Claude allows, where I’m just speaking without having to inter- interface with the Claude interface at all.

I can have the phone the app on my phone and just communicate back and forth verbally. So my mental picture as it applies to MSPs, Rich, becomes one where, the service desk and all the staff has got their headsets on and they’re talking with clients and doing their thing, whatever it is.

I see that becoming they’ve got their headset on and they’re talking to the LLM, the, the interface, Claude in this case, or ChatGPT, whatever it is, and having the conversation and the and the LLM executing and giving data [00:10:00] back and things like that. That’s where I’m seeing the evolution. So I just picture instead of talking to users, but…

And I’m not saying we’re not talking to users, but I’m saying for the day-to-day activity that the technicians are doing, when they’re not talking to users, they’re talking to the LLM that is connected to their RMM and PSA and the devices that they’re managing and things like that. But yes, that requires a very strict and high level of governance and security because, for every application we connect to an LLM, that’s just another a threat point, right?

From a security perspective that needs to be locked down and governed. So big conversation but I see us moving more and more in that direction. That’s just my prediction.

Rich: Very interesting. Time will tell where the market goes. Until then, Erick, it’s time for your tip of the week.

And interestingly enough it touches on something that came up on stage at the 20s Conference this morning, where the [00:11:00] CEO of that organization, Tim Conkle, was talking about the importance of trust in the era of AI. Trust is very much at the heart of your tip this week.

Erick: Yeah. Rich, so af- what we’re talking about this week is really- the promise that every client that engages with an MSP expects from the MSP, and that is to start the relationship off at a high level of trust and then build trust along the way.

And of course, that’s what MSPs want as well. They wanna make sure that clients feel that they have the right MSP serving them, that they have a high level of trust and confidence in their ability to help them meet their business growth objectives and along the way. And typically what happens when clients leave MSPs, Rich, is that they’ve lost trust or confidence in that MSP’s ability to meet or exceed their expectations, right?

So [00:12:00] somebody else comes along and drives a wedge in between the that relationship and basically wins the business away from the incumbent in a MSP, and this is where we find churn. And we’ve talked a lot, Rich, on the show about the value of net revenue retention and things like that as it pertains to company valuation, right?

As we’re seeing a lot of M&A activity. So this is our ability to maintain the revenue that we have, not churn it out. And from my seat here on the bus trust is built not by QBRs and by strategic meetings with clients. I think that helps and enhances it, but trust is built based on every interaction that a client or their staff has with the MSP’s organization.

And where does the vast majority of those interactions occur, Rich? Is with the service desk, right? Typically. So every [00:13:00] interaction that we have, closing a ticket, speaking with a client, all of that either bu- does one of two things: it either builds trust or it might erode trust a little bit. So here are three quick tips that I think might help remind MSPs to just, assess their interactions with every client and every end user.

So the first tip is And this is every phone call, every virtual meeting, every email, all of these things are a touch point. So first of all, three things that MSPs can do today. Number one is when we’re responding to a ticket or an email or a voicemail or a text message however, which- whichever way we’re engaging with our clients, we wanna respond with clarity, not just speed.

So here’s a great example, Rich. So we might say, [00:14:00] “Hey, we’ve got your ticket. We’re looking into it,” right? Automated response from a system, right? Better and more valuable response would be something like, “We’ve identified the issue,” or, “We’ve assigned the issue to Erick. He’s looking at it right now, and expect an update momentarily or by 2:00 PM,” or something like that.

I remember when we had RMSP, that’s how our updates always went out. We gave the person that opened the ticket confirmation that we received it, we again then gave them a confirmation when it was assigned to a technician, and then we gave them a a status update in between, like these were triggered timeframes to let the user know we’re on top of it and we’re giving them valuable feedback.

So even when you don’t have a resolution yet, just letting them know. Another great example is we would have… back in those days, we had all kinds of, internet outages all the time, and we would proactively reach out [00:15:00] by phone. And this wasn’t a technician. We had, administrative folks that would call each client letting them know, “Hey, we know there’s an outage in your area.

We’re kinda waiting on an update from the upstream provider. As soon as we have it, we’ll get back to you.” And this was… This would happen every 15 minutes. And I know that may sound extreme, but think about this. The, our highest, our top vertical market we have the most clients in were attorneys, so we were on top of that, as you can imagine, Rich.

Tip number two, follow through. And this is the hard one. If you make a commitment to say you’re gonna have something to a client or an end user, make sure you get that done, especially like if it’s a quote or a proposal. If you say, hey, you’ll have it by Friday, do everything you possibly can to get it to that to that client by Friday, or prospect.

If you ca- if in your mind you’re thinking, “Okay, I’ve got enough time,” but you’re sketchy on it, give yourself an extra day, by Monday. Like, but deliver [00:16:00] on your promise. When you say you’re gonna do something, make sure you give yourself enough time to deliver on it. There’s nothing worse than overpromising and underdelivering, so that also erodes confidence.

Third one Is when you’re having any kind of conversation or an email exchange or a text message or a voicemail, just set the proper expectation at the end of that communication. So if you just say, “Hey, we’ll get back to you ASAP,” yeah, that’s okay, but if you say something more specific about setting the expectation and next steps, “Hey, we’re gonna complete your assessment by Thursday.

We’ll be sending you the results on that day, and then we’re meeting with, we’ll meet with you on Friday to discuss that with you.” So give them a step-by-step what to expect, not, “We’ll get back to you ASAP.” Everyone should leave knowing what’s gonna happen next and have an expectation of when. So the takeaway really, Rich, is [00:17:00] clients don’t judge your MSP simply by how well you manage their technology, right?

You can be the best MSP in the world. They judge you by how consistently you keep your promises and how clearly you communicate with them and set their expectations. Yeah. I love all three of those, Erick, and two of them I love in particular because they line up very closely with things that I have, for literally decades at this point, believed about how you conduct yourself in the business world basic- basically.

Rich: And the second one on the list there was about following through. You told someone you would do something. I have long believed, and it’s like this little maxim that I think about all the time, say what you’ll do and do what you say. Say what you’ll do and do what you’ll say. So set the expectation, here’s what I’m gonna do, and then once you’ve done that, make sure you follow through and actually do what you said you were going to do.

Very important. And then just in terms of the third one and managing expectations, I have long believed, I [00:18:00] have no evidence for this number, for decades I’ve been saying 80% of s- success in business is managing expectations, and I really believe that basically, because if you don’t set expectations with a, a client this will be done in an hour, in two days, in a week, the client will fill that void with their own expectations, which could be totally unrealistic.

And even though you’ve done your best, maybe you’ve resolved the issue for them in heroic time, if they think this is something you should be able to do in the next 15 minutes, they’re gonna be furious with you, right? Set expectations. Let them know w- what to expect, particularly in terms of timelines, and then follow through on that.

And yeah you… That is what builds trust, and failing to do either one of those things is what can crush trust.

Erick: And then one bonus tip. Let’s say that you’ve done everything in your power, but you just can’t make that deadline. You know before the hour before [00:19:00] it’s due to, for an update to your client when you’re not gonna make that deadline.

And so my guidance there, Rich, would be, look, as soon as you have an inkling or a suspicion that you might not make that deadline, reach out to the client, eat crow, let them know, “Hey, you know what? I know I promised you this on Thursday. I’m letting you know I need an extra day.” And just stay in front of it.

Now that hopefully will maintain trust where it will erode trust if you do it all the time. So again, you’ve gotta, you’ve gotta, know your limitations and like you said, Rich, say what you’re gonna do and then do that thing that you said. Your client will give you grace here and there, but if it’s just a habitual thing, they’re just, that’s gonna erode their confidence and trust in you way faster than if you just, said, “I’ll get back to you ASAP,” in my opinion.

If you just keep promising and just missing deadlines over and over again, [00:20:00] that’s gonna tank their trust and confidence in you as well.

Rich: Totally agree. Totally agree. Great. Folks, we’re gonna take a quick break here. When we come back on the other side, it’ll actually be me flying solo for a little bit interviewing David Schwartz.

He’s the CEO of Pia one of the service desk automation tools out there that has actually been in the market the longest. He recently published a blog post that grabbed my eye ’cause he touches on it in in it, on a number of topics that I’ve been writing about a lot lately, including vibe coding and AI pricing and the SaaSpocalypse.

He has truly kind of an insider’s take on those and other topics that I got to explore with him in this interview. It’s coming up after the break. Stick around. We’ll be right back

Welcome back, part two of this episode of the MSP Chat Podcast, our spotlight interview segment, where we are very [00:21:00] pleased to be joined by David Schwartz. He is the CEO of Pia one of the pioneers basically of the service desk automation field that’s become familiar to MSPs everywhere. I believe this is his first time on the show.

David, welcome.

David: Thanks. Excited to be here, Rich. It’s good to see you.

Rich: Yeah, you too. So for folks who don’t know you or don’t know Pia, just to get started a little bit, tell them a little bit about both.

David: Yeah, sure. David Schwartz, I’m the CEO of Pia. I’ve been here a little over a year and a half at this point.

And I came from the MSP side of the, the world for a long time. So I was a co-founder and ran a, I’ll call it a IT services business. We had a blend of managed services and a SaaS element of it as well. And then we were acquired, and I got the experience of being part of a big private equity rollout of MSPs, expanding from being very regional-focused to nationwide, and did that for a while and then, a few years later landed here [00:22:00] at Pia.

Pia is an AI and automation platform, like you said, for the service delivery or service desk specifically. So we embed in the PSAs that MSPs use today. It’s not to displace them, it’s actually to embed it within them and drive AI and automation initiatives across what we call the life cycle of a ticket or the life cycle of a request.

Everything from how you first interact with your customer all the way through to actually how do you resolve the ticket, and how do you still make it feel like it’s, how do you level up h- what an MSP can deliver, but how do you still make it feel like the value that MSPs provide, which is that really hands-on of touch and that white glove treatment, still remains in place?

And so it’s the balance of bringing AI in whilst it, allowing us to elevate humans to do bigger, better, more meaningful work but also still giving that, that really top-notch experience that MSPs that the MSPs, like my favorite part about the MSP community is that’s what they do, right?

Is that [00:23:00] they all have their n- their uniqueness to them, but it all comes down at the end of the day to the quality of service they deliver.

Rich: So you given your background and what you’re doing now, you’re at a, a very interesting position where you have sort of an insider’s view of managed services and AI and the SaaS marketplace.

You recently… the biggest reason I’m excited to have you on the show is you just recently posted a blog post that touched on a bunch of those topics, a bunch of topics that I’ve actually been writing about recently on my blog, Channelholic, that Erick Simpson and I have been talking about on this show.

And so I’m dying to get into your thoughts on those topics with you a little bit, beginning with the SaaSpocalypse. Now there is a- and I know you’ve actually had some meetings with people recently where you’ve discussed this. I wanna get into that in a moment. But first, just to set things up, there is a concern, a belief widely held in the industry right now [00:24:00] that y- all or close to all SaaS solutions are eventually doomed.

And what you wrote in the blog, and by the way, I will include a link to the blog in the show notes. I encourage everybody to read it. It’s a good read. You said, “I don’t buy that SaaS is doomed.” As a blanket statement, you’re not buying it. What you said is, “Some categories are genuinely at risk, and others aren’t going anywhere anytime soon.”

And I know I’ve been spending a lot of time trying to figure out exactly how to f- you know, categorize what’s gonna be okay and what isn’t. From a- Yeah … a broad principle standpoint, what’s your thinking about that?

David: Yeah I think that, these S- SaaS companies that basically are just surfacing information, let’s say in a dashboard or something like that, but maybe aren’t doing anything quite, like when you really, if we’re honest with ourselves, unique I think that those are gonna face a challenge.

Those types of solutions like that could probably be replicated fairly easily. And I think when we say, when I say, they might be doomed, [00:25:00] I don’t necessarily mean that it’s bleak ahead of us for all of us that are on the vendor side of the house. I think what, how we all need to be approaching it is, we’re now entering this phase where we need to be very mindful of historically maybe we were gonna build something into our product.

The question then becomes, is what we’re gonna build easily, easy to build in cloud code or whatever tool you’re using and an MSP may not need to go buy it? Or is it actually complex and unique enough and valuable enough that it’s not something that’s gonna go be built over a weekend or a month through Claude or OpenAI or whatever it may be.

I think what’s interesting is it will be disruptive. We’re already seeing it be disruptive in certain ways. But when you peel back the layers and you look at what’s really involved behind the scenes to maintain support and do all the work that goes into running a software business, most MSPs are not software businesses, and all of a sudden now what’s, what they risk happening is [00:26:00] the mindset shift to having to now become a software business to support the own- the tools that they built in-house.

And that, that’s where we’re seeing, that’s why I don’t believe that SaaS is dead by any means. I think it becomes more of a situation of Finding tools to leveraging your organization that are purpose-built for the industry that you can build on top of to accomplish your goals. So when I think about the SaaSpocalypse specifically and that threat or concern that the market has as a whole, I look at it more as, is it actually sustainable for an MSP to take these initiatives on?

It really is fun and it’s exciting to go build something initially. And in fact, I am very much personally guilty of that, I’ll admit. I spent this whole weekend actually doing something because I wanted to see is it actually doable. And I validated that what I wanted to do is doable, but it was more meant as a proof of concept for [00:27:00] myself to go, “Hey, I’m gonna take this to my real product team to start exploring is this actually doable at scale or is it gonna break quickly?”

And even in the small little proof of concept I spent the weekend doing Guess what? It still broke. It still was a pain, and it’s still something that I very– halfway through the journey, I said to myself, “I don’t know if I wanna be doing this. I’m already frustrated with this.” And I think that if you’re now doing that, but it’s at the at the expense of potentially how you interact with your clients or the service that you deliver to your clients, is that worth it?

And so that’s kinda like the, the mindset of where I’ve landed, and then you start layering in, like token consumption specifically is is absolutely through the roof right now for a lot of these early startups because they aren’t being built by, how a DevOps or a product team would’ve in historically built a product.

They’re now doing it leveraging these AI tools, and everything’s AI, right? [00:28:00] You have to have an AI assistant in your product, and you have to do all these things that are just eating up tokens. And you look at something like this latest article I talked about with Canva basically resetting expectations in the market on what their growth trajectory is for this year.

It’s not that they can’t grow. It’s that they’re saying, “We don’t actually think it’s a good idea to grow if we can’t get this token consumption under control.” And I think that’s a, just a very interesting place to be in terms of the direction that these SaaS companies are going. So if you take that to a, less experienced organization who’s never been in that space before building product and now trying to do that internally or externally, I think that there’s a lot of inherent risks that should be considered.

Rich: So I totally wanna get into those risks the tech debt risk in particular that businesses take on when they vibe code. Token consumption, AI pricing, that’s all really interesting stuff to me. Something else interesting in the blog post. [00:29:00] You wrote that you’ve recently been having conversations with other vendors and with investment groups about the SaaSpocalypse issue, and one of the takeaways for you is the– there’s less fear there about the future of SaaS than there has been before.

It hasn’t disappeared, but there’s, it sounds like more confidence that there is a future for cloud-based software. There is money coming off the sidelines and being deployed. What you said that was inter- particularly interesting to me is that some of the concern about the future of SaaS has been redirected to what you called operational maturity.

So talk a little bit about what you heard, what people were saying to you about that what operational maturity means to you, and how the vendor world, the investing world is kinda thinking about that in relation to SaaS vendors right now.

David: Yeah. So I’ll hit on the operational maturity piece ’cause I think that’s really important.

I what I’ve found in these conversations is that it’s so interesting and easy now, [00:30:00] and if you go on LinkedIn any day of the week, thought leaders are posting stories of, “Check out how this company went from a million dollars or zero dollars in revenue to, unicorn kind of growth numbers,” right?

And it’s everywhere, and they did it with five people or some number that is just hard to fathom. That is– I don’t wanna downplay the significance of that, ’cause that is incredible. Truly incredible that it- we’re in a world where that’s doable. I think what’s happening is some of these products and solutions and companies are growing faster than they are operationally ready for.

And so all of a sudden now they’ve reached this point where they can get a huge fundraising round very large numbers, but it… Or they believe they can. But the, a lot of these investment groups are now looking at it going, “Is this actually– Can this team actually get it?” Can this be a real business or is this, a once off or I don’t wanna say a fluke, but maybe just like they got really lucky, they timed the market, they [00:31:00] did all these things, and they did build something unique.

There is definitely an element of that. But is it sustainable long term? And if they don’t feel like the, these companies can check certain boxes around operational maturity in terms of do they have a vision? Do they have a strategy? Have they priced it, w- like the product with that strategy in mind?

Do they really have a plan on how they can execute sales processes, how do you take care of your clients or in our world partners in, from an account management perspective? And it’s all these pieces are what makes a company either mature or immature, right? And that is being focused on more from an operational perspective in a lot of the conversations I’m having with investment groups.

And yes, there are certain things that they are very focused on, are you growing revenue? Are you keeping the revenue that you’ve grown? And all these obvious things like that. But when you peel the layer back, it’s an understanding of like what’s the structure of the organization and the team, and how do you build vision and the strategy, and how [00:32:00] do you execute that strategy and- If you’re gonna get an injection of capital, what are those use of proceeds really going to?

Or are you just saying, “I need a ton of money to dump into, to sales, and I’m, with a hope and a prayer,” kind of thing. And so I think now what’s interesting is you can see companies that have grown so rapidly, which is, like I said a minute ago, it’s incredible. It’s beautiful. But can they keep that pace in any real way, or are they going to have a problem?

And it’s interesting, I was talking to a, a friend of mine last week who has– not in the MSP world, but has a, an AI startup, and has amazing traction, has some, you know, reputable names from an investor perspective. And he– We were talking about when he first went live, and he’s “Yeah we’re on fire.

We’re crushing it. We had all these new clients that signed up, and our whole system crapped out of the gate.” And they had to go offline for [00:33:00] months, pull back, and figure out, “How do we rebuild?” And so it becomes just this interesting question of, were they operationally mature and ready enough, and had they really tested this enough?

Or had they rushed to get to the market because we feel like there’s this AI race if you have something with AI, how do I do it as fast as possible? And that could be at your detriment sometimes. And so they’ve had to pull back, reset, and now they’re on a good trajectory again. But it was this moment of, “Oh, man, our product’s not ready.

Our token consumption, like it’s just sucking up way too many tokens and so now we have a margin issue.” And so it becomes, again, this conversation around are we operationally mature enough or not? And now the investment groups are going, “It’s fantastic that you’ve grown at this rate, but we still can’t maybe join you for the next journey, the next chapter of this.”

Erick: That make sense? And so

Rich: as the investment companies kinda look at it, it sounds like pulling together some of the threads of what you’re talking about here. [00:34:00] As they try to decide what’s gonna separate the winners from the losers they’re looking for complexity. One of the– It was one of the things if it’s not easy to replicate this through cloud code, that’s a good sign.

Subject matter depth and expertise, that’s something good. And then also this operational maturity, which suggests that maybe from an investment standpoint, we’re moving out of a phase where all you had to do was say AI to the investors and you were gonna get some venture capital. They’re maybe being a little bit more discriminating now in terms of what AI startup plays they put their money into.

David: Yep, exactly. E-exactly. And I think it’s important, I think there’s a lot of AI products that have been built that do something valuable, but they’re like unleashed technology, if you think about it. And when I say that, is they’re doing something that’s very industry-focused, but it’s with the backbone of high dependency on one of these frontier models [00:35:00] or LLMs.

And that is a little bit more vulnerable to disruption in terms of not really having a moat, and can be easily replicated than doing something that has a lot more complexity around it and is more protected. And, your moat is something in terms of your ability to break it, to– or in, in terms of protection against competition, excuse me, that is not just the technology.

It’s, to your point that you just said, it’s like the experience in the industry and the team that’s behind it and it’s a bunch of pieces like that, that, that go a long way with certain industries. Like for Pia, for example, we spend a lot of time hiring folks who have MSP experience.

Not vendor experience, but MSP experience, very specifically. We want our partners who are MSPs to have somebody onboarding them that knows what it’s like to onboard a client as an MSP, right? That’s one area, and we do this across a spectrum of the areas. Because to us, we [00:36:00] feel like that goes a long way in terms of making you feel comfortable.

I’ve just signed on with this vendor, whoever it may be, they know my space intimately, and that goes a really long way in feeling like I’m in the right hands

Rich: I, like you David, am a, a vibe coder. I, I have, I think at this point, five different applications that I’ve created and most of which I use daily or close to it.

And this is great because they’re all totally customized to me and my workflows, and I’m not paying anything essentially for them. I’ve in fact canceled some SaaS subscriptions that I no longer need ’cause I have something better. But to some small degree, I am now in the software business.

I’ve got these applications that I have to maintain, and that’s certainly one of that kind of tech net debt that you can accumulate is one of the risks that comes with vibe coding. You were touching on a few of those before. Talk a little bit, for the folks in the audience here who are [00:37:00] building applications either for themselves to run within their MSP or to sell to their customers- what are some of the risks that they need to consider?

David: Yeah, so I’ll use an example that is actually not business related, because I think it’s very relatable to what we do. So I’m a big surfer, and I have a group of buddies that I’ve grown up with that we all go surf, before the sun rises several days a week, and we have for years.

And- I– there’s all these forecasting apps out there that do all these amazing things, and I said, they’re great, but they don’t really tell me and my friends we really liked this day at this time because the swell and direction and all these things that you have to analyze as a surfer perfectly hit this one spot that is a secret spot or isn’t like a, a, a well-known spot.”

So I said, I’m gonna build a tool that basically lets me and my friends capture this information so only we [00:38:00] know oh, this is… I- if we log these sessions, it’ll make recommendations, ‘Hey, you love days that look like this at this location. You should go, Saturday at 10:00 a.m.'” So I built this whole app with this model that analyzes and does all that stuff, and I was so excited about it, and three weeks later, the biggest company in the industry built the same thing.

And now, I built this for fun. I didn’t build it for f- for business. But what immediately happened is my friends who saw my app said, “This is great, but Surfline, the biggest vendor in the sur- the surf forecasting space has this, and it’s included for free. We’re not gonna use your tool.” And that same thing is relatable to the idea of vibe coding something internally, whether it’s to be used internally or it’s to be used and sold to your– and repackaged to your clients.

Which is, we have to be mindful that internally, if you wanna do something that, [00:39:00] is gonna transform sales if HubSpot or Salesforce or one of these CRM systems could literally have that in three weeks. And so the reason I point that out is these big SaaS, actual SaaS players Focus on a few things that are really important.

They focus on making sure the product works, so they do a ton of QA on it. They focus on making sure it’s secure. They focus on version controlling, giving you release notes and updates and all the things that you need to know about, and actually making themselves available to bring you along for the journey ar-around those release notes and new capabilities.

And they also invest in R&D for you. So your subscription that you pay 30 bucks a month for, or maybe it’s multiple users and it costs you 1,000 bucks a month, they are investing in all of those things for you. The moment you don’t use them is the moment you now have to worry about security governance version [00:40:00] maintaining and controlling, R&D, and all of these other things.

Mind you, most MSPs don’t really have a DevOps team that can truly own that. The, the bigger ones absolutely do, but most do not have a real DevOps team, and it gets parked in the hands of one person. And what if something happens to that person? What if they’re just sick for a week? For-forget something serious, just they’re out for a week, or they go on vacation for a week and something fails, right?

And so that vulnerability is very real. Now, that is ma- multiplied at a number that is unimaginable if you’re gonna extend that to your clients because you are now putting them at risk and your revenue at risk. It’s one thing to do something internally. It’s very different to extend that to the client themselves.

So I look at my personal example with this, the forecasting surf tool as, oh, this is literally what happens when you try to build something cool and you’re really excited about it, but you’re not [00:41:00] aware of what goes into maintaining it. Which, by the way, mine failed and errored out an alarming number of times.

And then a real SaaS player Has invested their R&D and has done a much better job at delivering that same thing. So I think these are conversations we do have to have internally. Now, I’m not against vibe coding. I think it’s incredibly powerful tool, like just– which is why I do it, which is why I spent this weekend doing it, and you do it.

I think it’s, if it’s your business that you want vibe coding, like your MSP, I really think it’s important to find a platform to do it on that is purpose-built for the industry, not starting from scratch every time you do something. And from my standpoint, I believe that vibe coding starting from scratch with Claude or another one of the, the coding tools, that is really starting from scratch.

It’s not purpose-built for the industry, and I think that there are a lot of risks associated with that. So like for us at Pia we actually just last week put out our [00:42:00] AI automation builder, and it’s basically prompt-based build your automations. That’s us encouraging from our perspective, but the beginnings of vibe coding, right?

Vi-vibe code, but do it on Pia. Don’t do it in Claude Code or some other solution that’s not industry specific. So that’s how we’ve approached it because I do think people are always going to want– Like now that these capabilities exist, everybody is gonna wanna build stuff, and everybody should, to a certain degree, be able to build stuff.

It’s just doing it where you know it can be done safely

Rich: Let’s let’s get into the token consumption issue that you brought up before, ’cause it has a number of really important, interesting implications for MSPs. That whole area is in constant flux right now. It’s a very unpredictable field in which as more and more agents come online, token consumption, just the number of tokens being used is going up.

But at the same [00:43:00] time, we’re seeing dollars per token, the cost of the tokens maybe going down as, as pricing pressure from these open source models in Asia begin to make themselves known. And all of this is happening week over week, day over day, very difficult to predict. Now what I am seeing, and you can tell me if you’re seeing something different, but for the most part, what I’m seeing is that the vendors who sell to or through MSPs specifically, for the most part right now, are just taking on the burden of dealing with that complexity themselves.

They’re not building a consumption component, a token consumption component into their pricing. MSPs are continuing to pay for software more or less the way they did before, and the burden, the risk is on the vendor to deal with that. So I guess the, the question is that what you’re seeing as well right now, and do you think that might change at some point in the future?

David: Yeah, good question. I am seeing the exact same thing. I am seeing [00:44:00] a situation of vendors taking on that risk and not necessarily having a path ahead if t- token consumption for a particular partner or a, a cohort of partners goes through the roof, and how to get in front of that. I think they’re one-off conversations probably of, fair usage and things like that.

That’s not sustainable long term. The problem is like, what’s a token? And I think that is a question that not enough people are really talking about in the general sense. We know that a prompt is gonna generate some number of tokens, but is it a small amount? Is it a large amount?

And asking some AI assistant to write you an email is not, it’s not a large usage of tokens, but it’s still, the average person has no idea what that even still means. Which I think is an interesting part of this. It’s a type of commerce that nobody actually, has value assigned to in this very weird way.

So [00:45:00] vendors are definitely taking that on. There’s been a number of s- attempts to go with, a credit token, jobs to be done type of approach. I personally have seen in the MSP world that MSPs just don’t take well to that. It sounds so, so great on paper, but it becomes very fearful for MSPs because the risk of bill shock variable costs month over month, and all these things that come with unpredictability Sometimes what it ends up causing is MSPs to choose to not get the value out of a product at their own detriment because of the fear of these usage costs that come with that.

So vendors have done what makes only make sense. Okay let’s just try to build enough margin in to try to support that effectively. The problem with that is it’s gonna impact vendors in certain ways. I also think that [00:46:00] part of this is a default to everything, the theory that everything just now needs to be AI-based in your product, which means it comes inherently with using tokens.

And I think the reality is that actually is not accurate. I actually think I see things all the time and again, I don’t believe to be an expert, but I see capabilities all the time in products, not just in the MSP space, in, in the world in general, that just simply don’t need to be leveraging an LLM.

But that vendor built it around that because that’s what everybody wants or thinks they want. But I think that there are probably more advanced ways to be– Like, when I say advanced like from a thought process to be solving those types of things, to be mindful of, let’s not just build something that leverages tokens or credits just because.

Let’s do it because it, it’s actually something that requires some really complex work to be done that more deterministic outcomes or built-in [00:47:00] workflows or whatever it is can’t do. So I think there’s some awareness that we all as vendors need to be, like, very mindful around. And, that’s a conversation internally our product team and I have regularly, which is how can we be really mindful of when we look at things that are on our roadmap and our vision and our these things that we’re working on that are innovative, how do we ensure that the model and the pricing model that would go out can actually support it?

Because if I want to charge a price for something Well, the industry is only going, and the market’s only gonna pay a certain amount for it. It doesn’t matter what it is, and it’s based at the value that they believe it is. But they don’t know the costs that come with maintaining and supporting that. And so one of the things that actually in that blog I mentioned was we should actually be really mindful of this credit and tok- or token consumption because it immediately eats into margins for us as vendors.

And that’s important if you’re shopping [00:48:00] and looking at vendors and you’re looking at multiple vendors that could do something similar, like they all play in a similar space. Being aware of, what stage they’re at as a business and the vulnerability they may have around token consumption and could my usage or a company like my mine who’s gonna use that product have such a massive token consumption that it changes their margins in a pretty significant way month over month is worth a consideration.

And look, I think that it’s kinda stinks to say that. As a buyer, I shouldn’t have to worry about that. I acknowledge that candidly. But we’re in this weird world right now where there’s so much green field in front of us, and it’s growing and happening and evolving so fast that I think it’s important that we all do actually challenge ourselves.

I have to really challenge myself and our team internally when we’re looking at vendors of is that vendor gonna be here six months from now, or are they going to char- be able to charge us this price? This seems awfully low [00:49:00] for what they’re presenting to us. Literally right before I got on this call, there’s a vendor, not in, not MSP specific, but for a product that we use internally, that just sent in a renewal for us as our contract comes up in a couple months that’s 35% higher Probably because of this.

That is not an exaggeration, actually 35% higher. That is just crazy to me. Now if we need the product, we end up kinda just taking it on the chin and we proceed. But it immediately pulls into question, do we need that product? So token consumption is a very real thing. If it eats into margins, and I think I gave an example on the blog where it’s one company, would have these fluctuations of 15% to 70% gross margin.

You c- you can’t spend revenue. You can only spend gross margin dollars. And [00:50:00] if they’re at 15% they’re bleeding. At 70% they’re okay, but at 15%, you as the customer absolutely are suffering whether you realize it or not. They’re going to pull back resources from you. They’re not gonna have client support for you or sup- or service desk support for you.

All these things start happening behind the scenes that do directly impact you as a buyer. So while it does stink to say that I think we as buyers have to be really thoughtful in what we’re buying and who it’s from it is just a reality of the time frame.

Rich: Yeah. I this was just a very interesting issue you raised in the blog post as well as just now.

And one of the things that you said there is that this has to be part of the evaluation process for a new vendor. And so two, two kind of related questions there. And one is, okay I need to factor token consumption and its potential implications for pricing into the evaluation process.[00:51:00]

What– How do I do that? What kind of questions am I asking the vendor? But also how much faith can I, should I have in the answers I get? Because I’ve got to believe if you had asked the vendor you just met with a year ago about AI and its impact on their cost, they would not have predicted y- you might be looking at a thirty-five percent price increase a year from now.

And so I, w- what kind of advice can you offer around how an MSP should factor this into the evaluation process, how much confidence they should have in what they hear back from a vendor? Yeah. That’s a great question. I think I think asking the direct questions that are hard to ask is an important part of this, which would be things like, walk me through how this plan works.

David: Do I have a set or allotted number of credits or tokens? How much of your product is really based on leveraging capabilities out of a frontier model like a claw and, [00:52:00] Anthropic or OpenAI or whatever it may be. And in really asking those direct questions, you’ll get some sort of answer. I imagine, if I’m being really honest and candid, that a lot of sellers probably won’t be able to directly answer those questions.

I am acknowledging that I am suggesting Questions to be asked that sales have probably not been prepped for objection handling within that organization. That said, it’s probably a, “You know what? Let me get the answers for you and I’ll come back to you.” And I wouldn’t probably take, as a buyer, “You know what?

Don’t worry about it. Everything’s gonna be okay, Rich.” I probably would take it as a little more serious than that, especially if it’s a smaller vendor. If you’re talking to a Salesforce or somebody like that, I’m referencing somebody out of our industry on purpose, but somebody like that, I think it’s a different conversation.

I think there– you get a [00:53:00] lot of risk for making an investment in a smaller vendor if you can’t get comfortable around some of these questions. And I acknowledge we’re a smaller player when you compare us to some of the really big players out there. But I think that those questions are important to ask.

Now, how do you challenge that is you probably s- ask, “Okay, so what happens if this happens?” types of questions. Because that ends up telling you where the real risks inherently lie for you as a buyer, which is, what happens if we overuse here or we overuse here? How do you know– is, are we limited on how we’re able to use this product?

If so, in what ways? If you run into these issues what parts of how you support us should we expect to see implications around? Now, they’re not gonna tell you, “Hey, we’re gonna have to, change how we support you from a client success perspective or a support perspective.” No-nobody’s gonna do that.

I think you could probably read through the lines, though, as you ask those challenging questions. So this is asking the questions that probably at least myself, we- we’re avoidant in w- in actually [00:54:00] wanting to ask, because you have to be very direct in those questions.

Rich: So one of the reasons I was r- I’m really looking forward to speaking with you on the show this week is it gives me a chance to talk about this blog post. There’s something else as well, though. Back in April, you guys did a webinar that unfortunately I missed, but it was based on an experiment you conducted where you ran 50,000 tickets past ChatGPT to kinda see how it triaged those, how well- or poorly it triaged those, and I’ve been dying to know what you saw and what you learned ever since. And I’ll say right now in the show notes, in addition to a link to David’s blog post, I’ll include a link to this webinar for folks who wanna dive into that deeper. But just give me high level what did you find?

What was this experiment exactly, and what did you learn from it?

David: Yeah. And then, oh, you’ve– Okay, I thought I lost you for a second. So what we did is we, that’s exactly right, we ran a bunch of tickets through, ChatGPT to ultimately find [00:55:00] out how does that compare to a more like what we’ve done internally, which we’ve built a small language model specifically to handle that.

And the reason we wanted to do that is one has a lot of openness, is what I would say, which is the ChatGPT approach. The world is your oyster. You can, it’s, but it’s also, that comes with risks inherently built into that. The other is very industry specific design to have guardrails in place. And so we wanted to kinda do an AB test to go which one ultimately has the highest confidence rating between the two?

And the reality is that ChatGPT didn’t perform as well, in short. And so- But the, what I would say, and I think it’s a really important conversation at the moment, is that’s actually an area I’ve seen a lot of MSPs building their own tools specifically, is around triaging tickets and [00:56:00] triaging them through building their own triage capabilities.

And for clarity, Rich, triage, for the audience, is the ticket comes in from the customer, and triaging, in short, is understanding what that ticket is and then updating the ticket in the ticketing system or the PSA to have the type of ticket listed and maybe some– It’ll do a lot of other things, but in short, it’s so that the next person who picks that ticket up actually knows what the request is.

And so that allows the, the system to be a lot more intelligent around getting it in the right hands as quickly as possible to the right technician. Now, in theory, a triage tool should do all kinds of things, not just update the type and subtype of a ticket. There’s a bunch of other things, but that’s a, it’s very separate, longer conversation.

But at a minimum, it should be able to confidently say, this is this kind of ticket or that type of ticket. And that really shouldn’t [00:57:00] require a ton of, what I’d say is complex reasoning. It should be pretty guardrailed. If this is what it is, it needs– it can only have this answer. However, what we saw with like ChatGPT is it started w- with basically classifying tickets into the wrong categories, in short.

And so I don’t want to call that necessarily hallucinating, but it was making wrong decisions in the same way that a human flipping and ripping through tickets really fast may make the wrong choice. They go, “Oh, I think it’s that,” and they’re just trying to move quickly. And that was similar results to what we saw with testing this theory.

Now that said, there’s totally a world where you want to leverage capabilities out of an LLM to do triage in this particular example, but it’s not without having guardrails in place. And I think that was like the really big indicator is how well can it do and perform, and can it cons- can it consistently deliver or not?[00:58:00]

So that, that was the test, and it was interesting. We found it quite interesting. We shared it with folks, as you saw. I still think it’s something that continue to do more of in other ways because I think that it’s just in this world of vibe coding and SaaS apocalypse, it’s a really great and really easy way to analyze these things candidly.

Yeah. Yeah it’s interesting ’cause it this is reminding me of a conversation I had with the CEO of Lexful a week before last and and she was kinda talking about some experiences she had with AI where it became clear to her that these large language models, because they are so large, they almost know too much.

Rich: They have too much context, and it’s not specific enough to you and your business and your workflows, and so on, and that’s why they make these mistakes. And so the, there’s a contrast potentially for MSPs between tools built on small language models, which I guess is what you guys are doing- Right

versus [00:59:00] just using a large language model to, to do this work. It might actually have too much context in a certain sense, and not specific enough context in another.

David: Yeah. I think it’s interesting and you mentioned in this that you do some file coding yourself. One of the experiences I had just yesterday was a few things I was working through and getting this recommendation from an LLM on here’s the best approach to do it, and here’s how I would do it, build this and configure it, and so on.

And me taking a step back and going, “I f- I really feel like this tool has overthought this scenario, and there has to be an easier, more direct way to accomplish the same thing.” And sure enough, I say, “Hey what about this or what about that as an alternative?” That’s a great idea. That’s actually a much better recommendation than what I suggested, and that, that happened just two or three times yesterday, right?

And so if you’re [01:00:00] doing that against hundreds of thousands of tickets that are coming in a day, in this particular example of triaging, and then you expand using an LLM across so many other spectrums of the business, it’s not necessarily the best tool for certain things, and we just have to, I think, acknowledge that a little bit.

And that’s why I said not everything has to be AI. I think there’s a lot of ways to drive automation and a lot of ways to drive solving problems, but it doesn’t have to be just feeding information into an LLM to get it done

Rich: So I wanna close out by getting your thoughts on something that you raised at the beginning of the conversation here, which is the role of the human in service delivery.

Gaze into the crystal ball for us David. Let’s say two years down the road to 2028, what has disappeared from the service desk in terms of how it’s worked in the past, how it [01:01:00] works today, and what has maybe become more valuable, even more valuable than it is right now?

David: Yeah, I think– so I’ll tell you what we’re seeing, which is and it’s very early days of this.

We’re seeing MSPs start shifting what they’re hiring for in terms of the type of person they’re hiring for the level one, more your junior roles that they’re bringing into the organization. And that’s not just on service desk, it’s applying to some other areas of the business. And they’re shifting the focus to more personal or personable, I should say, skills.

How can you– how do you interact with people? How, what type of quality of service are you gonna be able to provide? And it’s shifted a little bit less away from being just highly technical. Now I think the no- I’ll call the noise, which is the repetitive, highly repetitive work does go away, which is why [01:02:00] that personal touch becomes so much more valuable in terms of what you can provide to your customer.

So we’re seeing the job description change. We are also seeing new roles pop up in MSPs that never existed before. I liken it to, the automation engineer just a few years ago, which was a new role, and now we’re seeing it be more of an AI enablement type of role within an MSP. So I think that those are big changes.

In terms of the service desk specifically, the noise goes away for sure. The balance is going to be MSPs finding products that still make it feel like they’re giving a quality service to their clients with a human touch on it. And if th– but actually leveraging these tools behind the scenes. So I’m a big proponent of I’m already tired of these words, like human in the loop specifically, but like layering the humans on top of these tools.

The tools should make [01:03:00] you better at your job. They should make you feel more empowered. They should make you, put you in a better position to accomplish your goals and initiatives. They shouldn’t re- you know, ideally replace you in the MSP world. I think we’re– There’s obviously fears of that, but I think, when we look at what we’re seeing in MSPs today, if level one tickets can get more automated, then the folks on the level two team that are often coming in to provide extra capacity or save the day for level one can actually work on level two or can actually progress into the next career goal that they have.

So many folks- Have this in, hope of wanting to be, more focused in cybersecurity or more focused in infrastructure. Some path that they see a f- for a career for themselves in the MSP world, but they can never get there because most MSPs have a hard time being able to come up for air because of the noise that’s coming in.

So that’s what I think we’re starting to see shift, for sure. [01:04:00] And then I think what Pax8 branded as the managed intelligence provider, right? We’re seeing resources already in MSPs get shifted to allow for MSPs to start becoming MIPs. That is a very real thing that we are seeing right now, which is amazing.

It means that it’s not AI and all this stuff is not necessarily replacing people, it is leveling them up to focus on new things. But I do think that the entry job, entry level jobs are probably going to be the more challenging thing. And it’s tough because we have to be really mindful of the personal touch that hire can bring to the table, and so we have to be much more mindful that ever before, than ever before as it relates to the tech world or the IT world.

Rich: David, really interesting conversation. Again, I thank you for joining us on the show. And again, as I’ve said before, in the show notes, folks links both to David’s recent blog post about some of the topics we discussed a [01:05:00] link to that webinar about their experiment with ChatGPT.

Check both those out. And David, for folks in the audience who wanna get in touch with you, learn about, more about Pia, where should they go?

David: Yeah. So Pia’s website is Pia, as in P-I-A, .ai. Really easy. And then to get in touch with me specifically, I’m pretty fairly active on LinkedIn. So you can find me there, drop me a direct message tag me in your post, whatever it may be.

So those are the best ways to get with us. And then we tend to be at most of the major flagship events, if not all of them, we try to be at. I know coming up, there’s a couple in Australia that are about to hit with IT Nation, and Kaseya has a big event coming. We’ll be at Pax8 in Copenhagen, IT Nation in Orlando in, what is that?

October, Nove- November. So any of the big events, and I tend to be at a lot of those flagships specifically, and actually, and ac- at the booth specifically. So come by if you wanna find me.

Rich: All right. Thank you very much, David [01:06:00] Schwartz from Pia. Folks, we are gonna take a quick break now. When we come back on the other side, I will be rejoined by Erick.

He and I will share some thoughts about this interesting conversation with David about several of the topics we discussed here. That’s coming your way in just a moment, so stick around. We’ll be right back.

And welcome back to part three of this episode of the MSP Chat Podcast, and welcome back to my hotel room in Plano, Texas, by the way. One final thank you to David Schwartz for that very interesting conversation that I really did enjoy. That, that interview was actually in the works for a while before his blog post appeared, and then the timing was perfect because he’s interested in things I’m interested in.

I really wanted to hear his perspective on that. That, there are a lot of things we could kinda dive into here, Erick. I’ll just call out two. And one was about the, the whole vibe coding conversation that we had there, and, his [01:07:00] very legitimate observation that if you’re building apps for internal use or for your customers, as he is seeing a lot of MSPs do, that, that becomes something

It becomes this whole new workload that you you have to deal with. And what I was thinking about as he was talking along those lines is, you’re using tools like Pia’s tools to free up bandwidth at the help desk to, to, free up the technicians to do other things. Is software maintenance really where you wanna be putting those freed up resources to work as opposed to customer success, project work AI project et cetera?

Maybe not. Maybe that’s not the best use of the resources that service desk automation tool frees up. And then the other thing that he got, kinda got into a little bit, and it’s still a TBD, but so far what I’m seeing Erick and what he’s seeing is vendors out there are not- vendors who sell to and through MSPs at least.

This, and if you look at the IT industry more broadly it’s very different. [01:08:00] But in the managed services space, I’m not seeing a lot of vendors add a, a sort of token consumption, token usage element to their pricing yet. Because I think everybody understands MSPs will hate that if it happens, and no vendor wants to be the first one to do that and kinda suffer the consequences.

The question David raised is, i- will things change down the road? Right now a lot of vendors feel like they’ve got a, a, a firm enough grip on their margins, on their economics that they can do that, that they can kinda manage around the potential margin compression that will happen if their AI costs go up and their prices don’t.

It is not guaranteed at all that it will turn out that they are as good at that as they want to be or think they are. And so there is that real possibility down the road, I think, that you do start seeing some consumption related element to how vendors MSPs do business with price their products.

It’s not out there yet [01:09:00] but for reasons David discussed, could be out there eventually

Erick: Yeah. I think it’s inevitable. I think I think that we’re gonna see different approaches, right? I think we’ll see some vendors that, will want to cater to MSPs by saying here’s our base rate, which remains this way.

But if you want this enhanced capability, then maybe there’s a little bit of, token consumption that goes on there.” I think other vendors may take an approach that says we’re just gonna raise our prices across the board just a little bit to try to overcome that.” So I think different vendors will take different approaches in order to try to be more competitive for, MSPs’ wallet share and mind share.

It’ll be interesting to see what happens. But I… Yeah, the SaaSpocalypse and, tokenization and, what’s happening with these, with these big LLMs and the economics of that. It’s on one side you think, “Oh my goodness there’s a bubble that’s gonna burst.”

On the other [01:10:00] side it’s like no. We’re gonna grow, a 100 miles an hour and keep doing that for the next five years.” It’ll be interesting to see how each one of these different vendors approaches this very real economic reality. Y- you keep increasing the load on the LLM that powers your services and solutions, you’ve got to address that increased cost somehow, and it’s going to impact partners in one way or another at some point, it- I think.

Rich: We shall see. And David obviously shared that story about one of his vendors, one of the vendors Pia does business with. He’s at renewal time, and their prices went up 35% across the board. So th- no usage component but holy cow. And yeah, it’s gonna be an interesting y- next year in particular, I think, to see how the vendors deal with this and the degree to which they feel compelled to do something different than what they’re doing now.

Until then, folks we’ve got time for just one last thing, and we are in fact going to [01:11:00] cheat a little bit and give you two last things because they both come to us from the world of idiocy in billing policies. First we take you to British Columbia, where a a couple suffered the tragedy in a wildfire of having their entire home burned down.

And how do you possibly add insult to that injury? If you’re the cable company, you charge a $660 cancellation fee. They called in and said, we no longer have a home, therefore we don’t so much need the cable service. We’d like to cancel.” And because they were at some point in the contract or whatever, the cable company was like, then, you’re gonna have to pay us $660.”

You’ll be pleased to know that once the media caught onto this and publicized it, that fee was waived. I’m a little skeptical that might have happened under any other circumstances. You know what? Could you top that? Here’s another good one for you, Erick, and this time we’re going to Australia, where a 54-year-old woman parked her car outside of a grocery store.

She was on her way from the car to the grocery [01:12:00] store when she collapsed. Her heart stopped beating. She was technically dead. She would, in fact, be dead now if not for somebody noticing that she had collapsed. This was somebody who knows CPR, kept her alive till the EMT showed up. The paramedics took her to the hospital.

It to- it was five and a half hours, basically, from the time she parked her car until she was able to come back and retrieve her car. And the policy in this parking lot is 90 minutes of parking only, and five and a half hours is clearly more than that. And so she was billed an $80 fee for overstaying her welcome in the, the parking lot.

And when she contacted them to say, the, the problem, the, the reason I overstayed is because I was dead briefly,” they said, “You know what? That’s a pretty good reason. We’ll knock it from $80 down to 30. How about that?”

David: So

Rich: The folks in the billing department and it’s not just New Zealand and Australia.

I’m sure plenty of folks in our audience here right now have stories of their [01:13:00] own along these very lines. Oh

Erick: my goodness, Rich. It reminds me of, the times when I’m, you know the tactic to get your, you know, cable bill down or your, s- satellite radio bill down is to call them and go, “Hey, I’m canceling.

Take me off,” and they immediately reduce your price, by 80%. I’m like you guys are making all that margin all that time anyway, and now, this is what I get.” But yeah to r- to just offer her a reduction of $50 instead of just going, “You know what? We’re so sorry to hear that. We’re glad you’re still with us.

Come back and shop anytime. We’re waiving this fee,” that just another, another confidence eroding tactic for a client of, whatever the store she was shopping in, right?

Rich: Agreed. Agreed. An extra bonus tip of the week for you right there. Don’t, do not follow that example, MSPs.

It is not gonna work out well for you. Folks, that is all the time we’ve got for you this week on the MSP Chat Podcast. We’re gonna be back in a week with another episode for you. Until then, I will just remind you, as I always do at this [01:14:00] point in the show, that this is both a video and an audio podcast, which means that if you are listening to us right now but you’d like to check us out on video, you can go to YouTube, look up MSP Chat.

If you’re watching us on YouTube but you’re into audio podcasts, go to Spotify, Google, Apple, you name it, you’re gonna find us there. And wherever you find us, please subscribe, rate, review. It’s gonna help other people find and enjoy the show just like you do. This show is produced by the great Riley Simpson, part of the team with us here at Channel Mastered, where we help vendors build, grow, and optimize thriving MSP channels.

You can learn more about the many ways we do that on our website, which is located at www.channelmastered.com. Channel Mastered has a sister organization called MSP Mastered. That’s Erick and his team working directly with MSPs to help them grow and optimize their business. You can learn more about that at www.mspmastered.com.

So once again, we thank you for joining us. We’ll see you in a week. Until then, folks, please remember, as we always ask you to, you simply can’t spell channel without [01:15:00] MSP.