I posted a shorter version of this on LinkedIn and promised a longer breakdown. Here it is.
The problem with the term "managed IT" is that it has no floor. There is no licensing board, no minimum standard, no certification you have to hold before you can print it on a business card. I have personally seen it used to describe a sole proprietor who answers his cell phone at 9pm if he feels like it, and I have seen it used to describe a 200-person operation running a 24/7 security operations center. Same two words. Wildly different products. Often, surprisingly similar pricing.
That gap is where businesses get hurt. Not because the small guy is a crook or the big shop is a saint. They get hurt because they signed a contract believing they bought one thing and actually bought another, and they don't find out until something breaks at the worst possible time.
So let's talk about what the tiers actually look like in practice, and then I'll walk through the three questions from the post in more detail.
The tiers nobody labels honestly
Break/fix wearing a managed costume. This is the most common version at the small end of the market. You pay a flat monthly fee, which feels like managed services, but what you're really buying is a retainer for reactive work. Something breaks, you call, someone eventually fixes it. There is no real monitoring, no patching cadence, no documentation of your environment beyond what lives in one person's head. The flat fee is doing a lot of marketing work here. The service underneath it is the same hourly break/fix model that existed twenty years ago, just billed differently.
This isn't automatically bad. For a five-person office with simple needs, it might be fine. But you should know that's what you're buying, and you should price it like a retainer, not like managed services.
Tools-based monitoring and helpdesk. This is the middle of the market and where most legitimate MSPs live. The provider deploys a remote monitoring and management agent on your machines, runs a patching schedule, manages your antivirus or EDR, and staffs a helpdesk you can call or email. Alerts come in, tickets get created, technicians work the queue.
The quality range inside this tier is enormous, and it comes down to two things: what happens when an alert fires, and how loaded the helpdesk is. An RMM tool generating alerts that nobody triages is just expensive noise. A helpdesk where each tech is juggling 80 open tickets is a helpdesk where your problem waits. The tooling is table stakes. The process and staffing behind the tooling is the product.
Genuinely proactive managed services. Here the provider is doing things before you ask. Documented runbooks for common alerts, some of them automated. Quarterly reviews where someone who knows your business looks at your environment and tells you what's aging out, what's at risk, and what next year's budget should look like. Defined SLAs with actual response and resolution targets, not vague language about "best effort." Asset lifecycle tracking. A named point of contact who isn't also the salesperson.
This tier costs more because it should. You're paying for engineering time spent on your environment when nothing is on fire, which is precisely the time that prevents fires.
Co-managed and enterprise-grade. At the top end you get 24/7 coverage with real humans on shift, a SOC or a partnership with one, incident response capability, compliance support for frameworks like HIPAA or CMMC or SOC 2, and the ability to plug into your internal IT team rather than replace it. Most small and mid-sized businesses don't need all of this. Some absolutely do and don't know it, usually because of who their customers or regulators are. If you handle health data, take card payments at scale, or sell into government supply chains, the question isn't whether you can afford this tier. It's whether you can afford to explain to an auditor why you didn't have it.
The three questions, expanded
Question one: what's actually monitored, and what happens when an alert fires?
Everyone monitors. The word is meaningless on its own. The useful version of this question is a chain: which systems are covered, what conditions generate alerts, who or what sees the alert, and what action follows. "We watch your systems" and "we have automated remediation runbooks for our top 40 alert types, and anything outside those gets a human within 15 minutes" are different planets. A provider who can't describe their alert-to-action pipeline in concrete terms doesn't have one. They have a dashboard somebody glances at.
A good follow-up: ask them what their most common alert was last month and what the average time to resolution was. If they can pull that number, they're running a real operation. If they get vague, you've learned something.
Question two: who answers the phone at 2pm on a Tuesday?
Not who answers during the sales process. Sales calls get returned fast everywhere. I mean the actual human who picks up when your bookkeeper can't print on a random Tuesday afternoon. Are they local or offshore? Are they certified on the systems you run? How many tickets are they carrying at once? Is there an escalation path when the front line is stuck, and how long until your problem reaches someone senior?
You're allowed to ask to meet the service desk lead before you sign. Any provider who hesitates at that request is telling you the desk doesn't look like the brochure.
Question three: what's NOT included?
This is the one that matters most and the one nobody asks. Every managed services agreement has a project boundary, and the expensive surprises all live on the far side of it. Cloud migrations. Hardware refreshes. Office moves. New employee onboarding beyond a certain volume. Security incident response, which many people are stunned to learn is frequently excluded from agreements that advertise "security." Compliance audit support. Anything labeled "project work" at the provider's discretion.
None of these exclusions are inherently wrong. A provider can't flat-rate a cloud migration any more than a mechanic can flat-rate "whatever happens to your car this year." The problem is when the exclusions are buried and the client believes they bought all-you-can-eat. Read the SOW exclusions before you read the inclusions. The inclusions are marketing. The exclusions are the contract.
Where the lines should be drawn
If I were writing the rules for the industry, here's where I'd put the boundaries. Monitoring, patching, endpoint security management, helpdesk, backup management, and vendor coordination belong inside a managed agreement. That's the recurring operational work that benefits from consistency and process. Projects with a defined start and end, like migrations and refreshes, belong outside it, scoped and quoted individually, because flat-rating them forces the provider to either pad the monthly fee or cut corners on the project.
The gray zone is security incident response, and my position is that the first hours of triage and containment should be included in any agreement that uses the word "security," with full-scale response scoped separately. A provider who profits from your breach by billing the entire response hourly has an incentive problem you should think hard about.
The point
If you have an MSP today and you can't answer those three questions about your own agreement, that's not a knock on you. It's a knock on them, because a good provider makes sure you know exactly what you bought. Pull out the SOW this week. Read the exclusions first. If what you find doesn't match what you thought you were paying for, you're due for a conversation, with them or with someone else.
And if you want a second set of eyes on that agreement, that's a conversation we have with prospective clients all the time. No charge for reading a contract and telling you what it actually says.