The MSP Problem No One Talks About

Walid Elemary: Hey everyone, welcome to the Cloud PSO podcast. I am Usman and I'm the social media manager of Cloud PSO. And today I am joined by Waleed Alimari, the CEO of Cloud PSO. And today we are diving deep into the topic that a lot of founders, a lot of businesses don't realize until it's too late.

It's the MSP. Your MSP is probably over promising you. And today we are going to talk about that. Let me ask something, when was the last time your MSP promised something and actually delivered exactly as expected?

Faster response time, better security, proactive monitoring, strategic guidance, on paper it all sounds perfect, but in the reality, tickets takes more than expected, it takes too much time. ⁓ Issues repeat and the strategy conversation never really happened. So the question is, are MSPs under delivering or? you know, they are like over promising from ⁓ from the start.

So today on the value crops, we are breaking down exactly how to spot ⁓ the difference before it costs you like so much money or ⁓ risk exposure. So let's let's get started here. What do you think? Why do so many MSPs relations start strong and then it slowly falls apart?

That's a good question. Most MSP Osman are more focused on you know, the expectation gaps during a sales call, for example. The sales process is always designed to win trust, not to set reality when it happens. So what is happening?

The client expects a strategic partnership. The MSP delivers operational support. ⁓ When you look at it, the gap only becomes visible, you know, once the contract is signed. the work start the gap really becomes visible you know three to six months within the contract.

⁓ At that point switching is painful for the client. Most companies they just tolerate the issues for example. That's when you know the real problem really starts. So let's start with SLAs because almost every MSP sells guaranteed response times.

What's misleading about that? ⁓ man so SLA sounds impressive on paper. or in a conversation, but they're often meaningless in practice when you think about it. A typical SLA says we respond within 15 minutes.

⁓ That sounds great, wonderful. What does respond actually mean when you think about it? It usually means someone ⁓ is acknowledging your ticket. That's the first step.

⁓ Not that the issue is resolved, not that the right engineer is working on it, ⁓ just as someone said, where we have received your ticket ⁓ and we're reviewing it. mean, AI can do that today and a lot of companies are transitioning to the first response through AI. So companies are measuring responsiveness, not like effectiveness. Exactly, and here's a real world pattern, for example.

Companies has recurrent email outages, just a small example. Every ticket is, I would say, within the SLA. But... The root cause is never fixed.

On paper, SLA meet. In reality, business's impact continues. Exactly, I'll sponsor. Here's a real world ⁓ example.

A company, for example, has recurrent email outages. This happens a lot. Every ticket is ⁓ responded with an SLA. It could be 15 minute, 30 minute, whatever it may be.

But the root cause is never fixed. On paper, SLA meet your... need from a responses perspective in reality, business impact continues. And also there's the fake, you know, there's the fake performance on key line reports.

If your SLA resources response, but not resolution, ⁓ you were, you're measuring activity at best, not the outcome of the actual outage and so forth. You follow me? Yeah, yeah, exactly. 100%.

So, Wali, most, you know, MSPs send like monthly reports, they send long PPTs and everything, charts, graph, you know, metrics. So are those like actually useful? It depends on how you look at it. Most of them are just vanity reports.

You know, they're designed to show tickets closed and response time. ⁓ System uptime is another one, but they don't answer the real question of is your business actually... becoming more stable. How do you measure that?

How do you measure security and efficiency? These reports are not gonna give you that. They're just showing you uptime and response time at best. It's but my question is, it's like, so what exactly is missing from these reports?

Context and impact. That's two things, for example, context and impact. Let me give you an example. Let me give you a perfect example.

A report says you're up 98 % uptime. Great, wonderful. That sounds good, but what if the 2 % downtime do happen and it's during peak hours, or just say peak revenue hours for that matter, the 2 % could represent millions in lost revenue. Without business context, matrix.

it's meaningless at most, right? The key line here is good reporting tells you what happened, great reports tell you what it cost you, for example. You know, because at the end of the day, your business doesn't run on metrics, it runs on outcomes. So let's talk about, you know, internal cultures inside the MSPs.

So what is like ticket closing culture? Well, I would say it was when success is measured by how Yeah, mention performance measurement? Yeah, what did you mention performance measurement? So do you think speed replace quality?

Exactly, Elzman. Let me give you a real world example. A company keeps having VPN issues. Let's just use that for as an example.

Every ticket gets fixed by restarting the service. Restart your computer or restart your router or restart your firewall and so forth. But no one investigate why the issue keeps happening. It could be, you line flapping, internet latency issues, could be many things.

⁓ It could be ⁓ a port issue or a hard issue. Nobody's actually looking at that. So the same problem repeats itself for months and nobody's actually looking at the root cause. ⁓ That's not support, that's maintenance of a dysfunctional ⁓ hardware or a configuration within the software itself.

If the same issue keeps coming back, your MSP isn't solving the problem. They're just patching the symptoms, if you will. There needs to be a proper investigation on why this issue keeps repeating itself. And this is where things get ⁓ more serious ⁓ strategically.

So how do you know if your MSP is actually ⁓ strategic? Well, simple question. Do you have a six to 12 months IT roadmap that aligns with your business goal? That's like the first thing you got to ask yourself.

If the answer is no, you don't have a strategic partner. You have a support vendor at most, right? ⁓ And that's another question. Are you looking for a support vendor or a strategic partner that is going to help you keep your goals moving forward?

You follow me? Yeah, so let's say if if the thing yes, we have, you know, strategic roadmaps. So my question is, what does a real roadmap includes? ⁓ wow.

So let's just say ⁓ risk roadmap, security compliance gaps that needs to be in the roadmap, operational roadmap, efficiency, ⁓ automation, for example, ⁓ gross roadmap, know, scalability. Systems for expansion, for example, that needs to be in the roadmap. Without this, for example, it ⁓ is reacting to whatever happened next. You're going into a reactive mode.

Real order, I'll give you another example. We have seen companies scale from 20 to 100 employees, any identity governance. Results, here's a result. ⁓ Ex-employee, ⁓ still had access to certain confidential data.

Permission were inconsistent, for example. Security risks increased massively because they didn't have that. They grew so fast, they forgot the core foundation of the security and compliance. That is not a technical failure at all.

That's a lack of planning. ⁓ And I would say if your MSP doesn't show you where you're going, they're just helping you stay where you are, not moving forward. Yeah, Waleed, that makes total sense. So let's talk about accountability, Waleed.

When something goes wrong, who owns it? Well, that's when most relationships with MSP breaks because responsibility is shared, but accountability is unclear. The MSP says we manage infrastructure. ⁓ The client says we're expecting ⁓ reliability, for example.

And when something fails, ⁓ nobody, nobody owns the outcome. ⁓ So that, you know, that's very common in IT. ⁓ A real world example, you know, think about ⁓ outages like Let's just say Facebook in 2021. think that's one thing that comes to mind.

Hours of downtime affecting billions. Now scales that down ⁓ to mid-size companies. know, bring that down to mid-size companies. Scale it down to mid-size company.

Even a two-hour outage, just two hours outage can ⁓ stop operation, block revenue. Damage your customer's trust is another one. Yeah, if your MSP can't ⁓ clearly explain ⁓ who owns recovery, what is the time, what is the timeline to recover, for example, what is the communication ⁓ plan is. If they can't explain that to you, then that's a problem.

⁓ You have, ⁓ I would say you have, accountability gaps if you don't have all these ⁓ points covered. ⁓ If ownership for example, if ownership isn't defined before a failure happened, it will be ⁓ debited during failure. If ownership isn't defined from the beginning before failure happened, then this is to be major issue. So let's make it practical, Willy.

Let's say if I'm a CEO listening this right now, so how do I quickly assess whether my MSV is over promising? ⁓ go back to what I said before. Show me, you know, show us. roadmap, Yeah, show us our roadmap.

What percentage of issue are recurring that will tell you exactly if they're fixing it or resolving it or not doing it at all. When was our last backup restore test? Very important. No backups.

You are in a major hurt if outages happen. What are ⁓ our top three current risks? Is it internal security, external security, data? What is it?

Show it to me. ⁓ What happens if ⁓ our system goes down at 2M? Who's gonna respond? How fast?

⁓ Who decide what? Who decide what? So this is very, very important points, you know, when you're working with an MSB, and by the way, I'm not saying all MSBs ⁓ don't get this, a lot of them do, but some don't. And you need to make sure when you're working with an MSB, ⁓ you wanna have a partner, not just a vendor, who's gonna help you grow, who's gonna help you grow as your business grow and have a detailed IT roadmap.

So if someone is realizing their MSBs might be over-promising, What should they actually do? First thing, don't panic. Don't go fire MSP or make a big switch. First, get clarity.

Most MSP's issues ⁓ can be fixed with ⁓ better ⁓ expectations first, better communication and better structure. But if ⁓ those conversations fail, the best MSP isn't the one that promises the most. It is not the one that show you exactly what's real and so forth. It's the one that is really gonna have a structure in place, clarity, accept the expectation and ⁓ make sure that they're growing and your business is growing, you know, and have better expectation, better communication and better structure in place.

Yeah, and I think in situations such like that, people usually, you know, start panicking first. They see something goes wrong and you know, immediately assume everything is like broken. But most of ⁓ the time it's not that deep. ⁓ I feel like it's just a lack of clarity or maybe like communication or the structure.

⁓ The real mistake I believe is like making a rushed decision, you know, is that correct, Malib? Yeah, absolutely. You know, take your time, set clarity from the beginning, know, have a good relationship with your MSP, make sure that, you know, they understand, you know, your vision, your business and so forth. You're building a partnership long time.

Essentially, the MSP becomes an extension of, you know, your technology stack or your IT team. So you got to make sure you're happy and they're happy, but set the expectations from day one. Yeah, 100 % right. ⁓ So this is for everybody you're listening to right now.

If you wanted to run this script, know, to check your check the audit on your MSPs, we have created a free checklist, the five questions to you know, expose MSPs over promising. ⁓ So the link is in the bio link is in the description, it's going to take hardly five minutes and it will be immediately show you where the thing stands. So Willie, thank you so much again for everybody who's listening this right now. If this episode helps you and Please subscribe to Cloud PSO channel and share it with the founder or an operator or a founder or CTO.

And we'll see you in the next episode next week. Thank you. Thank you guys.