Remote monitoring and management is the single largest recurring line in most managed service budgets, and it is the one most often signed without reading. The pricing model matters more than the price, because the model decides what happens in year three when the estate has grown and the vendor has been acquired.
Tooling in this market consolidates. A vendor is acquired, the product joins a bundle, the bundle is repriced, and customers on old agreements are moved onto new terms at renewal. It has happened repeatedly across RMM, backup and security tooling, and planning as though it will not happen again is optimistic.
StructureThe four models, and who each one favors
Almost every quote is one of these, or a blend of two.
| Model | Priced on | Favors | Risk to you |
|---|---|---|---|
| Per endpoint | Every managed device | Nobody, it is neutral | Servers priced as endpoints |
| Per technician | Named seats | Large estates, small teams | Growth in the team, not the estate |
| Per client site | Locations | Dense estates | Many small sites |
| Tiered bundle | A feature bracket | The vendor | One feature pulls you up a tier |
The tiered bundle is where the surprises live. A single capability that moves you into the next bracket can cost more than the rest of the contract, and the capability is usually one somebody added to a proposal without checking which tier it sits in.
NegotiationThe questions to ask before signing
These are unglamorous and they are worth more than any discount.
What is the price at renewal, in writing? Not the discount this year, the mechanism next year. A cap on the annual increase is the single most valuable thing to negotiate and the thing least often asked for.
What happens if the count goes down? Many agreements ratchet up and never down. Losing a client should reduce the bill at the next anniversary, and if it does not, that belongs in the model you are pricing against.
What is the minimum commitment? A floor turns a variable cost into a fixed one, which changes how the service should be priced to clients.
How does data come out? Ask specifically: what format, over what interface, and has anybody actually done it. A tool holding years of documentation and no practical export is not a tool you can leave.
What is the notice period, and when does it start? Auto renewal with a ninety day notice window means the decision has to be made three months before it feels urgent. Diary it on the day of signing.
ReferenceThe clauses, and what a refusal tells you
Every item below is ordinary and gets agreed to regularly. What matters is not only whether you get it, but what the answer says about how the next three years will go.
| Ask for | What good looks like | What a refusal means |
|---|---|---|
| A cap on the annual increase | A stated percentage, in the agreement | The renewal is where the margin is |
| Counts that fall as well as rise | Adjusted at each anniversary | You are pricing a fixed cost as a variable one |
| A named export format | A format, an interface, and a customer who has used it | Leaving is harder than the contract suggests |
| Notice measured from a date you control | A window you can act in without a diary alarm | The renewal is designed to happen by default |
| Price held through an acquisition | Terms survive a change of ownership | Exactly the scenario this market keeps producing |
| A test tenant at no cost | Somewhere to try upgrades before they reach clients | Every change will be tested in production |
The last row is the one people skip and then regret. Without somewhere to test, every platform update lands on real client machines first, and the incident that follows is attributed to your service rather than to the vendor's release.
TermsThe clauses that are not about price
An RMM runs code as the highest privilege on every machine you manage, for every client you have, from one console. It is the most concentrated piece of access in the business, and the commercial conversation is the only moment when anybody has leverage to ask about it.
What the vendor enforces on the console. Whether multi factor authentication can be required for every account with no exception, whether access can be restricted by address, and whether a technician's session can be limited to the clients they work on. Ask whether these are available, and then whether they are available on your tier, which is a different question.
What is logged, and for how long. Every script run, every remote session, every credential retrieved, kept long enough to be useful in an investigation that starts months later. Thirty days of console logs is not an audit trail, it is a rolling window that closes before most incidents are noticed.
What happens when something goes wrong at their end. A notification obligation with a timeframe in it, and a named contact rather than a status page.
This market has produced the scenario more than once, and the difference between hearing it from the vendor and reading it on a forum is the difference between a controlled morning and an uncontrolled one.
None of this is unusual to ask, and all of it is easier to get during a negotiation than after one.
ArithmeticWorking out what it really costs
The list price is rarely the number that matters. Four additions usually apply.
Integrations. Connectors to the ticketing system or the documentation platform are sometimes separate line items, and they are not optional in practice.
Onboarding. A migration between RMM platforms is measured in weeks of somebody's time, and that time is not free just because it is internal.
The agent overhead nobody counts. Some agents are heavy enough to matter on older machines, and the complaints arrive as performance tickets rather than as a licensing conversation.
The features you will end up buying. Vendors are good at making the next tier necessary. Price the tier you will be on in eighteen months, not the one on the quote.
ImmediateCount what you are actually billed for
Before negotiating a rate, check the quantity. On most per endpoint agreements the invoice counts installed agents, and an agent does not remove itself when a machine is decommissioned.
What accumulates is predictable: machines replaced under warranty whose replacement was enrolled without retiring the old one, virtual machines cloned for a test and left, laptops returned by leavers and wiped without being unenrolled, and an entire client offboarded a year ago whose devices are still listed.
None of these appear as a problem anywhere, because nothing is broken. They appear as a number on an invoice nobody reconciles.
Pull the device list, compare it to the asset register, and look at the last check in date. Anything that has not reported in ninety days is either a billing error or a machine that exists and is unmonitored, and both are worth knowing before renewal rather than after.
The same reconciliation is worth doing before any migration quote, because a vendor pricing a replacement is pricing the count you gave them. Quoting a number that includes two hundred machines that no longer exist produces a saving that evaporates on the first true up.
DecisionWhen switching is worth it
Switching an RMM is expensive in a way that is easy to underestimate: every script, every monitor, every automation and every piece of documentation is rebuilt, and the work happens while the existing platform still has to run.
A price increase alone is rarely enough. A price increase plus a capability you actually need and cannot get, or plus a support relationship that has visibly deteriorated, usually is.
The useful discipline is to cost the migration honestly and express the increase as a payback period. An increase that pays back the migration in eight months is worth acting on. One that pays back in four years is a renewal to sign while looking for a better reason.
The arithmetic is worth doing explicitly rather than in your head. Take the migration as hours multiplied by what those hours are worth, add whatever runs twice during the overlap, and divide by the annual increase you are avoiding.
Two hundred hours against an increase of a few thousand a year is a payback measured in years, and the answer is to sign and keep looking.
The same two hundred hours against an increase that doubles the line is a payback measured in months, and the answer is to move. The figures are yours; the discipline is writing them down before the emotional part of the conversation rather than after it.
Standing practiceMaking the next change cheaper
Whatever you sign, three habits reduce what the next repricing costs you.
Keep the automation portable. Scripts written in the platform's own language and stored only in the platform are hostages. The same scripts in a repository, called by the platform, are not.
Keep the documentation outside the tool. Whatever holds the client documentation should be something you could leave separately from the RMM, because the two are usually repriced at different times.
Export something once a quarter, and check it opens. The export that has never been tested is the one that fails in the week you need it, and by then you have no leverage left.
- Get the renewal mechanism in writing, not the discount
A cap on the annual increase is the single most valuable term to negotiate, and the one least often asked for.
- Ask what happens when the count goes down
Many agreements ratchet up and never down. If losing a client does not reduce the bill, that belongs in the model you price the service against.
- Price the tier you will be on in eighteen months
Vendors are good at making the next bracket necessary. One capability added to a proposal can cost more than the rest of the contract.
- Diary the notice date on the day you sign
Auto renewal with ninety days notice means deciding three months before it feels urgent, which is exactly when nobody is thinking about it.
The three habits that keep you portable
None of them prevents a repricing. All three reduce what the next one costs you.
FAQQuestions from the comments
Is per technician pricing better than per endpoint?
It depends on the ratio. A small team managing a large estate does better per technician. A large team on a small estate does not. Work it out on your own numbers rather than accepting the vendor default.
How much notice do these contracts usually require?
Thirty to ninety days before an auto renewal is typical, and ninety is common enough to plan for. Put the date in a calendar on the day of signing.
What does an RMM migration actually cost?
Weeks of somebody rebuilding scripts, monitors, automations and documentation, while the old platform still runs. Express it as a payback period against the increase you are avoiding.
Should documentation live in the RMM?
It is convenient and it is a lock in. Whatever holds client documentation should be something you could leave on its own schedule, because the two get repriced at different times.
Can a price increase be negotiated after the fact?
Sometimes, and the leverage is a credible ability to leave. That ability comes from portable scripts and a tested export, which have to exist before the conversation, not after it.
How do I know the invoice count is right?
Pull the device list, compare it against the asset register, and sort by last check in. Agents do not remove themselves when a machine is decommissioned, so replacements enrolled without retiring the original, cloned test machines, wiped laptops from leavers and an offboarded client all sit there being billed. Anything silent for ninety days is either a billing error or an unmonitored machine.
What security terms should be in an RMM contract?
That multi factor authentication can be enforced on every console account with no exception, that access can be restricted by address, that script runs and remote sessions are logged for long enough to investigate an incident noticed months later, and that the vendor has a notification obligation with a timeframe and a named contact rather than a status page.
Is thirty days of console logging enough?
No. Most incidents are noticed long after they start, so a thirty day window has usually closed before anybody looks. Ask what the retention is, whether it can be extended, and whether the logs can be exported somewhere you control, which is the version that survives a dispute with the vendor.
Do I need a separate test tenant?
It is the term people skip and then regret. Without one, every platform update lands on real client machines first, and when something breaks it is attributed to your service rather than to the vendor release that caused it.
What happens to my terms if the vendor is acquired?
Whatever the agreement says, which is usually nothing. This market consolidates, and asking for terms that survive a change of ownership is asking for protection against the exact scenario that keeps happening. A refusal is itself an answer worth having in writing.
Should I reconcile the count before asking for a migration quote?
Yes, and before any quote. A replacement vendor prices the number you give them, so a count carrying two hundred machines that no longer exist produces a saving that disappears at the first true up, and the conversation restarts from a worse position.