Managed IT Services Pricing in 2026: Per-User, Per-Device, or Per-Outcome?

Key takeaways

• Most managed IT services are priced on inputs: devices, users, hours or a fixed bundle. Each model suits a different kind of organisation, and each has a blind spot. 

• Input-based pricing is usually sized to peak demand, so you pay for capacity that sits idle most weeks, and any efficiency the provider gains from automation rarely reaches your invoice. 

• Outcome-based pricing ties what you pay to what gets delivered. Allied’s Flexible Resource Architecture (FRA™) does this with a shared resource pool, digital workers and an automatic Reliability Rebate when service levels slip. 

Ask five providers what managed IT services cost and you’ll get five different units of measurement. One quotes per device. Another quotes per user. A third offers gold, silver and bronze packages, and a fourth wants to sell you a block of engineer hours. Comparing them side by side is harder than it should be, because they aren’t really pricing the same thing. 

This guide explains the pricing models you’ll come across, what each one is good for, what pushes the cost up, and why a growing number of organisations are moving away from paying for inputs altogether and towards paying for outcomes. 

How are managed IT services priced?

Managed IT services are usually priced in one of six ways: monitoring-only, per device, per user, tiered packages, an all-inclusive flat fee, or time and materials. All six charge for inputs (equipment, people or hours). A seventh model, outcome-based pricing, charges for results instead, such as resolution rates, response times and uptime, and adjusts the invoice when those results are missed. 

The right model depends less on which is cheapest on paper and more on how predictable your demand is, how much of your support work is routine, and how much risk you want your provider to carry. 

The common managed IT pricing models, compared 

Pricing model	What you pay for	Works best when	Watch out for
Monitoring-only	Alerts on servers, networks and endpoints	You have an internal team to act on every alert	Fixes billed separately, so the real cost only shows up after an incident
Per-device	A monthly fee per laptop, server, network device	Your estate is stable and device-heavy	Cost grows with hardware, not with how much support you actually need
Per-user	A monthly fee per person, covering all their devices	Staff use several devices each	You pay the same for light and heavy users; idle seats still cost money
Tiered packages	Bronze / silver / gold bundles of services	You want a simple choice and a fixed budget line	Paying for services in a tier you never use, or upgrading to get one feature
All-inclusive flat fee	One fixed monthly price for an agreed scope	Budget certainty matters more than flexibility	Price sized to peak demand; scope disputes at the edges
Time and materials / block hours	Engineer hours, drawn down as used	Work is project-based or very irregular	No incentive for the provider to fix things fast or permanently
Outcome-based (FRA™)	Delivered results: resolution rates, response times, uptime	You want cost to follow demand and service quality to carry a consequence	Only works if the provider’s resourcing can genuinely flex; check how outcomes are measured

1. Monitoring-only

The provider watches your infrastructure and alerts you when something goes wrong. Fixing it is either your team’s job or billed as extra work. It looks inexpensive, but it only makes sense if you already have people with the time and skills to act on every alert. 

2. Per-device pricing

You pay a set monthly amount for each device under management, often with different rates for servers, workstations and network equipment. It’s easy to understand and scales cleanly with your estate. The catch: the number of devices you own says very little about how much support you actually need. 

3. Per-user pricing

One monthly fee per person covers every device they use. This suits organisations where staff work across a laptop, a phone and cloud apps, and it makes budgeting simple as headcount changes. The trade-off is that a light user and a heavy user cost exactly the same. 

4. Tiered packages

Services are bundled into levels: basic support in the entry tier, security and backup in the middle, strategic advice at the top. Tiers simplify the buying decision but rarely match your needs exactly, so you either pay for services you don’t use or upgrade a whole tier to get one feature. 

5. All-inclusive flat fee

A single monthly price covers an agreed scope. Budget certainty is the main appeal. But to protect their margin, providers size that fee against your busiest months, so in a quiet month you’re still paying for peak capacity. 

6. Time and materials (block hours)

You buy engineer time and draw it down as you go. It works well for project work and irregular needs. As an ongoing support model, it quietly rewards the provider for every hour spent, which is the opposite of what you want from a service desk. 

What actually drives the cost of managed IT services?

Whichever model a provider uses, the same handful of factors sit underneath the quote: 

• Scope. Monitoring only, full day-to-day management, or management plus strategy, security and projects. 

• Environment complexity. The mix of on-premise, cloud and legacy systems, and how many applications need specialist knowledge. 

• Coverage hours. Business hours only, extended hours, or 24/7 support across time zones. 

• Compliance and security requirements. Regulated sectors need tighter controls, evidence and reporting. 

• Ticket volume and mix. Not just how many tickets you raise, but how many are routine and repeatable versus genuinely complex. 

• Level of automation. How much routine work is resolved by digital workers instead of a person, which is the factor most quotes never mention. 

That last point matters more every year. In a traditional delivery model, cost tracks headcount: more tickets means more engineers. When routine tickets are resolved automatically, the link between ticket volume and people breaks, and the pricing model ought to reflect that. 

The problem with paying for inputs

Per-user, per-device and flat-fee models all share one assumption: the provider builds a fixed team big enough for your busiest weeks, and you pay for that team whether it’s busy or not. That creates three predictable problems. 

• You pay for idle capacity. A team sized to peak demand is underused most of the time, and the cost of that slack is built into your price. 

• Efficiency gains stay with the provider. If a provider automates half its routine tickets but still bills per user, the saving becomes its margin, not your discount. 

• Accountability is weak. Traditional service credits are usually capped, rarely claimed and often require you to prove the provider missed a target. Most contracts never trigger them. 

None of this means input-based pricing is wrong. It means you should know what you’re paying for, and whether it still matches how modern IT support is actually delivered. 

How outcome-based pricing works 

Outcome-based pricing flips the question from “how many people or devices?” to “what did we get?” You agree measurable service levels up front: first-touch resolution rate, response time by priority, uptime. The commercial model is then built around delivering them. At Allied, that model is our Flexible Resource Architecture (FRA™), and it rests on three layers working together: 

• A shared specialist pool. Human specialists are resourced across clients with similar demand patterns, rather than as a dedicated team sized to your peak. 

• A digital worker layer. Through FusionWork™, digital workers resolve routine, pattern-based tickets end to end. Allied’s stated auto-resolution rate is 84%+, which is why the human team doesn’t need to be sized to raw ticket volume. 

• Dynamic reallocation. Capacity moves to whichever account needs it on a given day, based on live demand rather than a fixed rota. 

Accountability is built in through the Reliability Rebate. Agreed service levels are tracked continuously, and a shortfall reduces that month’s invoice automatically, with no dispute or renegotiation needed. It’s our way of putting our fees where our outcomes are. 

Because the cost base follows actual demand instead of peak capacity, clients running FRA™ alongside FusionWork™ typically see a 30–40% cost reduction against a comparable fixed-headcount contract (Allied’s stated figure). The saving comes from removing idle capacity, not from cutting service. 

And because Allied operates under DHRA™ (Digital Human Resource Architecture), that efficiency doesn’t come from layoffs. Digital workers take on the routine load; people move to the judgement-heavy work that needs them. 

Which pricing model is right for you? 

• Small, stable estate with an in-house team: per-device or monitoring-only can be enough. 

• Mobile, cloud-first workforce: per-user pricing keeps budgeting simple as headcount changes. 

• Fixed budget line, predictable workload: a flat fee buys certainty, as long as you accept you’re paying for peak. 

• Project work or irregular demand: block hours, ring-fenced from day-to-day support. 

• High ticket volume, variable demand, and a need for proof that service is improving: outcome-based pricing, where cost follows demand and missed service levels carry a consequence. 

Questions to ask before you sign

1. What exactly is the unit of pricing (device, user, hour, outcome), and how does it change if our demand rises or falls mid-contract? 
2. Is the support team sized to our peak, and are we paying for that capacity in quiet months? 
3. What percentage of our tickets will be resolved automatically, and is that a measured, current figure or a projection? 
4. When automation makes the service cheaper to deliver, how does that show up on our invoice? 
5. What happens when a service level is missed? Is a rebate applied automatically, or do we have to raise and prove a claim? 
6. What’s excluded from the price, and how are out-of-scope requests charged? 

If a provider can’t answer questions three and four with specifics, the “AI” in its offer is probably doing more work in the sales deck than on your invoice. 

Conclusion

Per-user, per-device and flat-fee pricing all answer the same question: how big a team do you need to rent? Outcome-based pricing answers a different one: what do you need delivered, and what happens if it isn’t? As more routine IT work is resolved by digital workers, the second question is becoming the more useful one to ask. 

Want to see what outcome-based pricing would look like against your current ticket volumes and contract? Talk to our team and we’ll model it with you. 

Click here to connect with us!