Managed services pricing comes down to one choice: the unit the fee is attached to. Per user, per device, a percentage of the customer’s spend, a block of hours or a tiered fee per application each reward the provider for something different, and only one of them rewards taking responsibility for something difficult and then making it easier. Price on a proxy for what the customer spends and you earn more when their estate is worse. Price per application, tiered by countable indicators of effort and standardised (standardized) across the estate, and you can write a fee designed to fall into the contract, which is the strongest commercial argument a provider can make.
This guide is written for the provider. Buyers will find it useful for reading a proposal, but the argument is about what you should sell.
Five pricing bases and who each rewards
| Basis | The unit | Who it suits | What it rewards the provider for | Where it breaks |
|---|---|---|---|---|
| Per user | A named person supported | End-user IT, standardised desktops and productivity suites | Headcount growth at the customer | Bespoke systems: a user is not a unit of operational effort |
| Per device | A server, endpoint or network device | Estates with countable, similar equipment | Estate growth; more boxes, more fee | Cloud and containers, where devices are ephemeral and the count is meaningless |
| Per cent of spend | The customer’s bill for the underlying platform | Cloud resellers and platform partners | A bigger customer bill, including waste | Every improvement you make cuts your own fee; incentives point the wrong way |
| Block of hours | Prepaid or metered time | Break-fix and small estates with irregular demand | Incidents; the worse the month, the more you bill | The customer pays most when they are least happy, and you have no reason to reduce incidents |
| Per application, tiered | A system, scored and placed in a tier | Application and platform operations, cloud managed services | Accepting responsibility for difficult things and making them less difficult | Needs a scoring method both sides trust, and honest tier reviews |
Notice the column that matters: what each basis rewards. A pricing model is an instruction to your own delivery team about what to want. Per user tells them to want the customer to hire. Per device tells them to want more devices. Per cent of spend tells them to want a bigger bill. Block hours tell them to want incidents. Only the tiered per-application model tells them to want the estate to get better, because that is the only model where getting better is what the contract pays for, and where the fee can honestly fall.
The argument against pricing on a proxy for the customer’s spend
At the business that became DevOpsGroup, a services company helping other businesses build and run software, the services company my co-founder Steve and I started in 2013 to help other businesses build and run their software, we developed a service for operating customers’ applications. Much of the industry priced that kind of service as a percentage of the customer’s cloud bill, because cloud spend is easy to measure and the number tends to go up.
We chose not to anchor the base fee to it. The reason was simple: that model pays the supplier more the more waste there is. A customer running an inefficient estate is a better customer, in fee terms, than one running a lean one, and we did not want to sit on that side of the table. The contracts still carried exceptions, an uplift tied to cloud spend on some tiers and separate terms for VM hours, so the honest version of this argument is about what the fee is anchored to and what direction it points, not a claim that spend never appeared in a price.
The deeper problem with a spend proxy is that it does not describe operational difficulty. A system can be expensive to run and comparatively straightforward to support: a large, well-automated data platform that rarely wakes anyone up. Another can spend very little and consume a disproportionate share of attention: a small, fragile application with no monitoring, three third parties involved in every incident and nobody left who understands it. Price on spend and you charge the first customer too much and the second too little, and you have no vocabulary for explaining why.
The same objection applies, more mildly, to per user and per device. Both count something real, and both are fine for standardised environments where the count does track the work. Neither says anything about how hard the things are to operate, which for application and platform services is where the effort actually goes.
Application tiering: Core, Remediation and Kaizen
The alternative is to price on a unit connected to what drives the effort, and to build the model so that both sides can count it. By the time of the sale it was how we contracted rather than a philosophy, and it had three moving parts.
The three service elements
The service itself came in three parts, held in deliberate balance:
- Core. The routine operation: monitoring, patching, backups, access, the scheduled work of keeping a system running.
- Remediation. Fixing what broke: incident response and the follow-up that stops it recurring.
- Kaizen. The improvement work. Kaizen is a term borrowed from Japanese manufacturing practice, and the idea behind it is not ours. What we did was hold it in balance with the other two, so that an application demanding more remediation also carried more improvement time, not less. That balance is what makes the fee able to fall: the improvement work is how the remediation load comes down.
Tiers, and the criteria that decide them
Each application sat in a tier, from one that was largely self-aware and automated at the bottom of the ladder to one of high complexity and low operability at the top. The tier was decided by a handful of criteria, every one of them countable by both sides:
- Business criticality: what it costs the customer when the application is down.
- How often it changes, because every release is a chance to break it.
- How well it is built: whether the system can be deployed and recovered without heroics, and how many discrete technologies the provider must support and document.
- How much of it you can observe: whether it can be monitored well enough to see an incident coming.
- Resolver groups: the number of other teams, the customer’s or third parties’, whose involvement an incident requires.
Keep the list short and fixed. Too many criteria and the scorecard becomes a negotiation in disguise. Too few and the factor doing most of the work stays hidden. How many tiers the criteria sort the estate into is a choice for the provider, and fewer is usually better than more. Of the criteria, resolver groups is the best predictor of effort I have found, because every additional team in an incident adds waiting, hand-offs and disagreement about whose fault it was.
Fair use and the fee designed to fall
Each tier carried an inclusive allowance of hours for remediation. Exceeding it did not trigger an invoice argument. It triggered a reprioritisation of the improvement backlog towards whatever was generating the remediation, which is what the Kaizen element was for.
Then the clause I still think of as the bravest line in the model. If an application ran at or below its fair use allowance for an agreed period, it could move down a tier, and the fee moved down with it. Three consecutive months is the period I would set: long enough to be evidence and short enough that the customer could see the benefit arriving. A fee designed to fall, written in on purpose.
Model both directions before you sign. A route to a lower fee has to work for the provider as well as the customer. If better operation reduces the effort, the provider can preserve its economics while sharing the benefit; but that has to be demonstrated on your own cost base, not assumed.
A worked example, invented
The following estate, scores and fees are invented to show the mechanism. None of the numbers is a rate or a recommendation, and the five tiers are an illustration rather than a rule.
A provider takes on an estate of ten applications for a mid-sized retailer. Each application is scored on the criteria above and placed in a tier. The provider has set a monthly fee per tier from its own cost base: the hours of core work a typical application at that tier needs, the inclusive remediation allowance, a proportionate allocation of improvement time, and margin.
| Tier | Description | Applications in tier | Monthly fee per application (GBP, invented) | Monthly total (GBP, invented) |
|---|---|---|---|---|
| 1 | Self-aware, automated, one resolver group | 2 | 900 | 1,800 |
| 2 | Well instrumented, occasional incidents | 3 | 1,600 | 4,800 |
| 3 | Mixed technologies, two or three resolver groups | 2 | 2,800 | 5,600 |
| 4 | Poor operability, frequent incidents | 2 | 4,500 | 9,000 |
| 5 | High complexity, low operability, many resolver groups | 1 | 7,000 | 7,000 |
| Estate total, month one | 10 | 28,200 |
The two tier four applications are the ones consuming the remediation allowance. Over the first two quarters the improvement work goes there: monitoring is added, deployment is automated, one of the third parties is designed out of the incident path. Both applications then run at or below their fair use allowance for three consecutive months and, under the contract, move down to tier three.
| Tier | Applications after the review | Monthly total (GBP, invented) |
|---|---|---|
| 1 | 2 | 1,800 |
| 2 | 3 | 4,800 |
| 3 | 4 | 11,200 |
| 4 | 0 | 0 |
| 5 | 1 | 7,000 |
| Estate total after review | 24,800 |
The fee has fallen by 3,400 a month, about twelve per cent of the estate total, in this invented case. The provider’s remediation hours on those two applications have fallen by more than that, because the work that was consuming the allowance has stopped. Margin on the estate is preserved or improved, the customer is paying less for a better-run estate, and the provider has a story to tell the next prospect that no per-cent-of-spend competitor can match. That is the economics of a fee designed to fall: it is only a loss if the improvement work was not real.
Exceptions and uplifts
No tiering model survives contact with a real estate without exceptions. Write them down and price them separately, so that the base fee stays anchored to responsibility.
- A spend-linked uplift. Where the underlying platform cost genuinely drives provider effort, for instance in cost management or reserved-capacity planning, an uplift tied to spend on the relevant tiers is defensible. Keep it an uplift, small and explicit, rather than letting it become the basis.
- Consumption terms. Virtual machine hours, storage or licence pass-throughs that the provider resells should sit on their own line at their own terms, not inside the tier fee.
- Onboarding. Taking an application into service is a project: discovery, documentation, monitoring, runbooks. Price it as one, so the recurring fee is not carrying a one-off cost.
- Out of hours. State the hours the tier fee covers and the uplift for extending them.
- Major change. New features, migrations and re-platforming are engineering work and belong in a separate statement of work. The tier fee keeps the system running and improving; it does not rebuild it.
- Tier up as well as down. If an application becomes materially more demanding, a new integration, a new resolver group, it moves up. The review conditions must work in both directions or the customer will not believe the downward one.
- Minimums. A small estate needs a floor fee to cover the fixed cost of the service desk, tooling and on-call, whatever the tier arithmetic says.
Choosing your basis
Before settling on a model, answer five questions on paper:
- What drives our effort? If it is people and their devices, per user or per device may be right. If it is the difficulty of systems, tier them.
- Can the customer count the unit? A unit the customer cannot verify becomes an argument at every review.
- What does the model tell our team to want? Say it out loud. If the answer is “more incidents” or “a bigger bill”, choose again.
- Can the fee fall, and would we survive it? Model the estate at its improved state. If the economics only work while the estate is bad, the model is a bet against your own service.
- What are the exceptions? List them now and price them separately, so that the base fee stays clean.
A pricing basis is not a rate card. Your rates come from your cost base, your margin and your utilisation, exactly as they do for a consultant day rate. The basis decides what those rates are attached to, and therefore what kind of provider you become.
Where to go next
The MSP pricing model playbook, in development, sets out the tiering criteria, the three service elements and the tier-down clause in full. The application tiering worksheet, also in development, is the working version: score an estate, sort it into tiers and split the work across Core, Remediation and Kaizen. For how a managed service differs from a retainer, see what a monthly retainer is, and for how the revenue is counted, recurring revenue.