What Managed IT Support Actually Costs, and Why Nobody Will Give You a Straight Number
Key Takeaways
Introduction
Ask five managed service providers what support costs, and you’ll get five answers, three pricing models, and a lot of hedging. That’s not always evasion. Managed IT pricing is genuinely complex, but the complexity is knowable, and buyers who understand it stop overpaying.
Here’s how the models work, what moves your number, and where the surprises hide.
What goes into a managed IT support price?
Before you compare models, understand what a provider is estimating on their side. Every quote, regardless of how it’s packaged, is built from software costs, personnel costs, time costs, and how much automation the provider brings to the work.
There’s a fifth input that buyers rarely think about: the current state of your environment. If your environment is in poor shape, part of what you’re buying is the work of getting it into a state where it can be managed efficiently at all. That work doesn’t disappear because nobody priced it. It just shows up later.
What are the main managed IT pricing models?
Per user
The most common approach, and it works at almost any size. You scale with headcount, and there are economies of scale: once you cross certain thresholds, the per-unit cost drops. In practice, per-user pricing is often banded into tiers: 0 to 100 users, 100 to 500, 500 to 2,000, and so on. At some point the curve flattens, and you’ve extracted all the efficiency available. The only real question between providers is where the cutoffs sit and where the curve levels off.
Per device
This is how manufacturers have always priced support, especially at enterprise scale. Per-device pricing exists because some things simply can’t be priced by user. You can’t sensibly charge for switch support based on headcount: how many users does that switch serve? You could count ports, but ports don’t map cleanly to people either.
Hybrid
This is why most real arrangements mix the two. Endpoints price per user; infrastructure prices per device. Depending on what’s in scope, the models either blend or stay deliberately separate.
Flat rate, all-inclusive
Built from how many resources need to be embedded in the engagement, how many software tools are required to do the job, and the expected number of incidents. Buyers like it because it’s predictable, and they’ll often reverse-engineer a per-user comparison to sanity-check it.
But flat-rate carries real risk for both sides. If a provider walks into an organization without knowing the state of the environment, quoting flat-rate all-inclusive is guesswork. Competitive pressure pushes providers into it anyway, which is exactly how engagements go sideways. The honest version is often a hybrid: flat rate guaranteed for the well-understood scope, per-incident for the piece nobody can responsibly fix a price on yet.
À la carte
This one doesn’t really belong on the list, but it is worth mentioning. Per-incident charges can be one component of a deal, but à la carte as a whole doesn’t fit what managed support is. Managed support is an ongoing operational relationship, not a menu.
Who is managed IT support actually for?
Not everyone. Very large organizations (10,000, 20,000, 30,000 people) generally don’t buy managed IT support outside of specific pockets. They build internal support depth, buy manufacturer support directly, and if they outsource at all, it’s full outsourcing, which is a different animal.
The scale gap is worth sitting with. The largest banks employ more IT people than the top three managed support providers in this country outside of IBM. That work was never coming to a mid-market MSP.
Where enterprises do buy managed support is narrow and specialized, a provider with genuine depth in one platform supporting one part of the environment globally.
Managed support does its real work in mid-market and smaller organizations, up through roughly 10,000 users. Not because they’re less sophisticated, but because they don’t have the scale to staff every specialization they need.
One caveat: industry matters. Organizations where IT is the product (finance and banking in particular) tend to keep more in-house, because the technology is the intellectual property.
What drives your number up or down?
Number of users. Number of servers. Number of sites. Security requirements. Technical debt. None of these gets left out of the tiering conversation.
Users are the easy one, because endpoints correlate to headcount. Infrastructure doesn’t work that way. We’ve seen 100-user organizations running enormous server and network footprints, and 500-user organizations running less infrastructure than the 100-user shop. Headcount tells you about clients. It tells you very little about everything behind them.
Technical debt deserves its own line. Lack of standardization, aging gear, unsupported platforms: these translate directly into support volume, and support volume is what you’re paying for.
Where do pricing surprises come from?
Almost every unpleasant surprise traces back to one thing: the provider didn’t understand the environment they agreed to manage.
Less sophisticated providers skip discovery, lead with an attractive per-user number, and then start lobbing in exceptions:
- “We didn’t know your security appliances were from 2015.”
- “We didn’t know you were still on Windows 10.”
- “We didn’t know those systems were in the cloud.”
Lack of discovery is the root cause. The headaches are downstream.
Why do three quotes come back so different?
When bids are far apart, the most common explanation is that providers interpreted the requirements differently, sometimes honestly, sometimes not. A provider can notice a gap in your RFP, stay quiet, and save the conversation for after winning the project. Sales tactics can get deceptive, and “that’s the information I had at the time” is an easy thing to say later.
The other explanation is real capability differences. Providers with better tooling and more automation can deliver the same outcome for less. Providers without them price high, because their operation is less efficient.
What to ask every provider before you compare numbers
- What discovery have you done, and what did you find?
- What assumptions about my environment is this price built on?
- Which parts of the scope are guaranteed, and which are per-incident?
- Where are your tier cutoffs, and what happens to my price when I cross one?
- What’s explicitly excluded?
The Takeaway for IT Buyers
Frequently Asked Questions
How is managed IT services pricing usually structured?
Most providers price per user, per device, a hybrid of the two, or as a flat all-inclusive rate. Per-user pricing is almost always tiered, and most real arrangements blend per-user pricing for endpoints with per-device pricing for infrastructure.
Why won’t managed service providers give a straight number?
Because the price depends on users, servers, sites, security requirements, and technical debt, and none of those can be priced responsibly without discovery. A quote given in thirty seconds is either a guess or leaves something out.
Is flat-rate managed IT support a good deal?
It is predictable, but risky for both sides if the provider has not examined the environment. The honest version is often a hybrid: flat rate for the well-understood scope, per-incident for what nobody can responsibly price yet.
What should I ask before comparing managed IT quotes?
Ask what discovery the provider has done, what assumptions the price is built on, what is guaranteed versus per-incident, where the tier cutoffs sit, and what is explicitly excluded.
The Takeaway for IT Buyers
There is no clean answer to managed IT pricing, no rule that says at 100 users you go from $8 per user to $7. Anyone giving you that answer in thirty seconds is either guessing or leaving something out.
What you can do is buy like an informed party: understand which model you’re being sold, know what’s driving the number, and insist on discovery before anyone commits to a price. Providers who do the work up front have less reason to surprise you later.
Talking to providers about managed support? Derive Technologies has spent decades on both sides of these conversations. Start a conversation with our team.