GUIDE · PRICING AND PROFITABILITY
How to prepare for an MSP pricing review
A pricing review goes wrong when it starts with a number. It goes right when it starts with what each agreement actually buys, what it actually costs you to deliver, and why the two drifted apart. This is the preparation I would ask for before looking at anyone's pricing, including my own.
By The founder of MSP Reboot, who co-founded an MSP in 1999 and ran it until it was sold in 2023.
Published
What a pricing review is for
Most MSP pricing was not designed. It grew one client at a time: a discount to win the first big account, a flat fee that made sense for twelve users and still applies at forty, a “we’ll include that for now” that became permanent. Nobody decided the current price list. It accumulated.
A review is not about finding the right price per user. It answers three plainer questions: what did each client actually receive over the last year, what did it cost you to deliver, and does the agreement you signed still describe that work? The price changes, if any, come out of those answers.
Gather six things first
Twelve months is the useful window. Shorter hides seasonal work; longer mixes in agreements that have already changed.
- Every current agreement, and the version each client actually signed. Not the template. Note the price basis (per user, per device, flat, tiered), the start date and the last time the price changed.
- Twelve months of invoices per client, split into recurring, project and ad-hoc lines. Many MSPs find that “recurring” quietly includes fixed project work and the other way round.
- Ticket and time data per client. Hours logged, ticket count, and how many tickets were after hours or marked urgent. If time is not logged consistently, say so and use ticket counts; do not invent hours.
- Per-client tool and licence cost. Every agent, seat and mailbox you pay for on the client’s behalf, including the ones you bundle and do not re-bill.
- Work delivered outside the agreement. The site visit that was “just quick”, the onboarding of a new office, the vendor calls. Your technicians know where these are; ask them.
- A one-line note on each client relationship. Growing, stable or shrinking; easy or difficult; strategic or historical. This is context for decisions, not a score.
If the data is messy
It usually is, and that is a finding in itself. Do not delay the review to clean every ticket. Mark the clients where the data is unreliable and treat their row with less confidence. A review on 80% good data beats no review.
Lay it out one client per row
A spreadsheet is enough. The point is to see every client in the same columns, so the outliers become obvious without a formula telling you what to think.
| Column | What goes in it | Why it matters |
|---|---|---|
| Price basis and amount | e.g. per user, 28 users, monthly total | Shows how many different pricing models you are actually running |
| Last price change | Month and year | Old prices are where scope drift hides |
| Scope in the agreement | Short list of what is included | The baseline to compare delivered work against |
| Work actually delivered | Hours or tickets, plus out-of-scope items | The gap between this and the row above is the review |
| Direct tool and licence cost | Monthly, for this client only | Bundled tooling is often the largest unpriced cost |
| After-hours and urgent load | Count over 12 months | Disruption that does not show up in hours |
| Exceptions | Anything done differently for this client | Each one costs process time on every ticket |
| Relationship note | Growing / stable / shrinking; easy / difficult | Context for what you decide, not a ranking |
Questions to answer before changing anything
About the price list
- Can you explain in one sentence how a new client is priced? Does that sentence match what existing clients pay?
- How many different price points exist for effectively the same service?
- Which clients are on a price set more than three years ago, and what has changed in their environment since?
- Would you sign your own agreement, at your own price, for the work you actually deliver to that client?
About each client
- Where is the delivered work clearly larger than the agreed scope, and since when?
- Which inclusions were never intended, and which exclusions have you stopped enforcing?
- Which clients generate most of the after-hours and urgent work, relative to their size?
- Which tool costs grow with the client (devices, mailboxes) while the price does not?
About you
- Which clients do you personally handle, and is that reflected anywhere in the price?
- Where did a discount or inclusion start as a favour, and is the reason still true?
- What would you charge a brand-new client for exactly what your oldest client receives?
A hypothetical example
Hypothetical — not a client and not a result
The figures below are invented to show how the sheet reads. They are not drawn from any real MSP and do not represent a typical or expected outcome.
Imagine a client on a flat monthly fee agreed four years ago for twelve users at one site. The sheet shows they now have thirty users across two sites. The agreement covers workstation and server support; over the last year the MSP has also handled the client’s Microsoft 365 administration, a phone-system vendor relationship and quarterly visits to the second site, none of which is in the scope column. Per-mailbox security and backup licences have grown with headcount and are bundled, not re-billed.
Nothing in that row says “raise the price by X”. It says the agreement no longer describes the relationship. The options are a conversation, not a calculation: rescope the agreement to what is actually delivered and price it the way new clients are priced; move the extra work to a defined add-on; or stop doing some of it. Which one is right depends on the client, the relationship note and what you want the business to look like, which is why the review needs a person and not a formula.
Traps that make the review useless
- Starting from a benchmark. Published figures describe other businesses with other cost bases. They are worth discussing in context, never as a target.
- Averaging across clients. An average margin hides exactly the clients the review exists to find.
- Repricing everyone at once. Change the outliers first, at renewal where you can, and learn from those conversations.
- Ignoring the technicians. They know which clients generate unlogged work. A review built only from the PSA will understate it.
- Treating price as the only lever. Scope, standards, exceptions and tooling are often easier to change than the number.
What to do with what you find
Sort the clients into three groups: rows where agreement and delivery match (leave them alone), rows where they have drifted and the client is worth keeping (rescope and reprice, usually at renewal, with the evidence from the sheet), and rows where the relationship costs more than it returns in money, time or morale (decide whether to change the terms or end it).
Then fix the cause, not just the price. If drift came from unwritten inclusions, write the standard. If it came from client exceptions, the service-delivery review is the next step. If it came from you personally absorbing work, the owner-dependency checklist is.
Bring the sheet to the free hour.
Even half-finished, a per-client sheet makes the introductory hour far more useful. We will look at where your agreements and your delivery have drifted apart, and you will get a straight view of whether deeper pricing work is worth paying for.