Commercial

MSP pricing models: per-device, per-user or flat fee?

Every conversation about MSP pricing models eventually collapses into the same three options: charge per device, charge per user, or charge one flat fee for the whole estate. All three are defensible, all three are in daily use, and all three fail in specific, predictable ways. This is a comparison of how each one actually behaves over a contract's lifetime, and, because a comparison that ends in "it depends" is useless, an actual recommendation at the end.

What a pricing model is really for

Before comparing the options, it is worth being precise about the job. A pricing model is not just a way of calculating an invoice. It does three things at once:

• It allocates risk. Somebody absorbs the difference between the fee and the real cost of service in any given month. The model decides whether that is you or the client.
• It shapes client behaviour. Whatever you charge for, clients will try to have less of. Charge per ticket and they stop reporting problems. Charge per device and old machines never get retired from the count, just hidden.
• It sets the tone of every future conversation. A model the client cannot predict produces a billing argument every month. A model they can predict produces a renewal.

The reason MSPs argue about pricing models so much is that no model does all three jobs well. Each one trades precision for simplicity somewhere, and the right question is not "which model is correct" but "which trade-offs can my operation and my clients actually live with".

Per-device pricing: precise, and precisely wrong

Per-device is the oldest model, and its logic is honest: your tooling costs scale per endpoint, your patching and monitoring effort scales per endpoint, so your price should too. A workstation costs one rate, a server a higher one, network kit something in between. The invoice is a stock count.

Its strengths are real. It maps almost perfectly onto your cost base, so margin per client is easy to see. It is trivially auditable: the client can count their own machines. And for estates with unusual shapes, a warehouse with forty shared terminals and nine staff, a clinic with more diagnostic machines than people, it is the only model that prices the actual work.

But per-device taxes exactly the wrong behaviour. The industry has spent a decade telling businesses that security means every laptop enrolled, every mobile managed, every server monitored. Under per-device pricing, each of those good decisions raises the client's bill, so clients quietly resist them. The unmanaged personal laptop that never made it onto the invoice is also the one that never got patched, and it is still your incident when it goes wrong. A model that gives your clients a financial reason to hide endpoints from you is working against your own security posture.

It also ages badly. Modern users average two to three devices each, and that number only rises. A model that meters the thing that is multiplying makes every renewal conversation a price rise conversation, which is partly why industry surveys now put per-device somewhere under one MSP in five, and falling.

Per-user pricing: the default, for good reasons and one bad one

Per-user charges a single monthly rate for each person supported, covering whatever devices that person reasonably uses. It has become the industry default, and mostly on merit:

• It matches how clients think. A managing director knows their headcount to the person. They could not tell you their device count within twenty percent. An invoice denominated in people is one they can sanity-check in their head, which is worth more goodwill than any discount.
• It rewards the right behaviour. Enrolling a second or third device per user costs the client nothing extra, so nothing pushes back against full coverage. Your security posture and your pricing model finally point the same way.
• It tracks the licensing world. Microsoft 365, most security tooling and most SaaS is already per-user. Your cost of goods and your revenue rise and fall together with headcount.

The bad reason it became the default is that it is easy to copy without doing the sums underneath. Per-user is an averaging model: it works when the average user's device load and support demand match what you priced. Sign a client whose "users" each carry a laptop, a desktop, two mobiles and a tablet, or a client with heavy shared infrastructure and few people, and the average breaks in your direction. Per-user also hides servers entirely. A server is not a user, and folding a demanding hypervisor estate into a per-head rate is how MSPs end up doing their hardest work for free.

Flat-fee pricing: the best sales pitch and the worst discipline

The third model drops the metering entirely: one fixed monthly fee for the whole environment, everything included. It is the easiest model to sell, because it is the one clients actually want. No counting, no surprises, one line on the budget. It is also the purest expression of what managed services are supposed to be: you are buying an outcome, a working estate, not a basket of units.

For the MSP, flat-fee done well is the most profitable model on this list, because it decouples revenue from effort. Every hour of toil you automate away widens the margin instead of shrinking the invoice. It gives you the strongest possible incentive to prevent problems rather than bill for them.

Done badly, it is the fastest way to go broke slowly. A flat fee is an underwriting exercise: you are insuring the client against their own IT demand, and if you set the premium without data, the client with the flaky server room and the growth spurt will consume your margin invisibly, month after month, with no mechanism in the contract to correct it. Flat-fee also invites silent scope creep. When nothing is metered, nothing is out of scope by default, and two years in you are supporting an acquired subsidiary, a second office and a fleet of tablets that were never priced at all.

Flat-fee is not really a different model so much as a bet that you know the client's demand curve better than they do. Sometimes that bet is right. It should never be the opening offer to a client whose estate you have not yet measured.

The comparison that matters: how each model fails

Feature lists make the three models look interchangeable. Their failure modes do not:

• Per-device fails at the edges of the count. Its characteristic failure is the unmanaged endpoint: the machine kept off the invoice that becomes your breach anyway. Secondary failure: renewal friction, because the metered unit is the one multiplying.
• Per-user fails in the averages. Its characteristic failure is the client whose per-head demand quietly exceeds the rate, invisible until you measure effort per client. Secondary failure: unpriced servers and infrastructure.
• Flat-fee fails in the drift. Its characteristic failure is scope creep with no meter to catch it, discovered only when a profitable contract has become an unprofitable one with the same signature on it.

Notice what the three failures have in common: none of them show up on the invoice. Every pricing model fails silently, which is why the model matters less than the measurement underneath it. An MSP that tracks devices, users and effort per client can run any of these models and correct course at review time. An MSP that tracks none of them is guessing under all three, just with different notation. If you price per user, you still need the device count; if you price flat, you need both, plus effort. This is also why pricing belongs on the agenda of your quarterly business reviews: the QBR is where the drift gets caught while it is still a conversation rather than a dispute.

Our honest recommendation

If you want a straight answer: run per-user as your base, price servers and infrastructure per device on top, and treat flat-fee as something a client graduates to, not something they start on.

Per-user as the base because its incentives are the least destructive. The failure modes of per-device pricing damage the client's security and your relationship; the failure modes of per-user pricing damage only your margin, and margin failures are fixable with measurement and a rate review. Add a per-device line for servers, hypervisors and network infrastructure because those genuinely are units of work with no user attached, and folding them into a per-head rate is the single most common way good per-user pricing goes bad.

Reserve pure flat-fee for clients where you have at least a year of real data on devices, tickets and effort, and where the relationship justifies underwriting their demand. At that point it is a genuinely better model for both sides. Before that point it is a guess, and the discovery work in a proper client onboarding is exactly what turns the guess into a quote.

Two caveats, honestly held. If your client base is dominated by device-heavy, people-light estates, per-device is not legacy thinking, it is the correct model for you; run it and ignore the surveys. And whichever model you choose, write the assumptions into the contract: devices per user, server counts, what triggers a re-price. The model is the headline; the assumptions are the contract.

Where this fits with Helios

Every recommendation above leans on the same prerequisite: knowing, per client, how many users and devices you actually support and where the effort goes. Helios keeps that inventory live across every client tenant, devices, users, servers and their state, so a rate review starts from real counts rather than a walk-around, and the client whose demand has outgrown their rate shows up in the data before they show up in your margin. And because Helio's auto-triage and auto-healing take repeat toil off the desk, the gap between a fixed fee and your real cost to serve moves in your favour, which is the whole economic point of fixed pricing done well.