Playbook
MSP pricing model: price managed services per application
When your fee is a proxy for the customer’s spend, you get paid more when they do worse. How to price per unit of responsibility, with a fee designed to fall.
The methodApplication tiering: Core, Remediation and Kaizen
This playbook is an MSP pricing model for managed services priced per application rather than on a proxy for the customer's spend. It scores each application in an estate on a small set of criteria, sorts them into tiers, splits the work into three service elements, and designs a fee that falls as the estate improves, so the managed service becomes a productised (productized) offer with a countable unit behind it. It is for managed service providers, cloud firms and consultancies with an ongoing service line who currently charge per user, per device or as a percentage of the cloud bill, and who have noticed that this puts them on the wrong side of the customer's interests.
A fee that tracks the customer's spend rewards you when the customer does worse. If their cloud bill rises because their estate is inefficient, you earn more. If you do your job and the estate gets cheaper to run, you earn less. Per seat and per device have the same defect in milder form: the unit you charge for has little to do with the responsibility you carry. The customer works this out, usually in the second year, and the renewal conversation becomes about your incentive rather than your service. Meanwhile the work itself is uneven. One application generates most of the incidents and most of the cost, and a pricing model built on seats or spend cannot see it.
Application tiering starts with a scoring exercise. Every application in scope is rated on a handful of criteria, among them business criticality, how often it changes, how well it is built and how much of it you can observe, and the scores sort the estate into tiers that carry different fees because they carry different amounts of responsibility. The work is then split into three service elements. Core is the standing service of keeping things running: monitoring, response, patching, the things every tier gets. Remediation is the bounded work of fixing what the scoring exposed, priced separately and finished. Kaizen is continuous improvement, the small ongoing changes that move an application down a tier over time. The fee is designed to fall: a tier-down clause commits you to reducing the fee when an application's score improves, which is the point at which the customer's interest and yours point the same way. The playbook covers the mechanics and what the fee is anchored to, and how to hold margin as the fee falls, which means the work has to fall faster than the fee does.
There is no rate card and no price per tier. Those depend on your cost base, your tooling and the estates you take on, and the playbook teaches the unit, the tiers and the three elements rather than a number. It does not cover the sales motion for a managed service, or the transition from a project into an ongoing service, both of which matter and both of which come after the unit you charge for is right.
The business that became DevOpsGroup, a services company helping other businesses build and run software, ran a managed service line for years alongside project work. The first version of it came out of a migration: we moved a customer's estate to the cloud, and at the end somebody had to run it, so we did, on a flat card that had been written for the project. Over time the model grew into tiers scored per application, with a fee meant to fall as we improved what we were looking after. I should be honest about the record, because the playbook is. The contracts we actually signed carried exceptions, including an uplift linked to cloud spend and, in some cases, terms priced by the hour of compute. The pure model and the signed model were not the same thing, and the gap between them is a lesson in the playbook rather than a footnote. Where the per-application basis held, the renewal conversations were about the estate. Where the proxy crept back in, they were about us.
The playbook is in development, with an application tiering worksheet alongside it. Joining the waitlist means you hear when it is ready, and tells me which kinds of estate the people waiting are pricing. Nothing is for sale yet and there is no date.
What you will get
Who it is for
Questions
- Why price per application rather than per user, per device or per cent of spend?
- Those bases price a proxy for the customer's spend or estate, so the fee rises when the customer's systems get worse. Per application prices the unit of responsibility you actually carry, and lets the fee fall as the estate improves, which is what a buyer wants to pay for.
- How do you sort an estate into tiers?
- Score every application in scope on a handful of criteria, among them business criticality, how often it changes, how well it is built and how much of it you can observe. The scores sort the estate into tiers that carry different fees because they carry different amounts of responsibility. The playbook gives the criteria and the scoring method; the fee per tier comes from your own cost base.
- What is a tier-down clause?
- A contractual commitment that when an application's score improves enough to move it to a lower tier, its fee falls to that tier's rate. It aligns your incentive with the customer's: you are paid for the improvement work, and then you charge less for a healthier estate. It also forces you to make sure the work falls faster than the fee.
- Is pricing as a percentage of cloud spend always wrong?
- It is always misaligned, because you earn more when the customer's bill rises. It is not always avoidable; some customers and some contracts push towards it, and the playbook says so from experience rather than pretending otherwise. The method is to price per application as the base and to know exactly what any spend-linked element is doing to your incentives.