Commercial

How to choose an RMM: stop scoring feature lists

Search for how to choose an RMM and you will find the same article twenty times: a checklist of features to look for, every one of which every serious product already has. This piece makes a different claim. Feature comparison can no longer pick an RMM, because the features have converged, and the differences that will actually cost you money live in places a comparison matrix never looks. That holds whether you are an MSP responsible for thirty client estates or an internal IT team buying proper tooling for the company you work for.

The feature matrix stopped working years ago

Ten years ago the matrix earned its keep. Some RMMs had patch management and some did not. Some could manage Macs, some could not. Remote access was a differentiator rather than an assumption. You could line up four products, tick boxes, and the winner genuinely was the better tool for you.

That world is gone. Monitoring, patching, scripting, remote access, software deployment, antivirus visibility, reporting, an API: every credible product ticks every row. The market converged for a boring reason, which is that a feature matrix is also the vendor's roadmap. Whenever a competitor's tick became a reason to lose a deal, the gap got filled, sometimes properly and sometimes with the minimum implementation that lets sales say yes.

So when you score five products against forty criteria and they finish within a few points of each other, that is not evidence they are interchangeable. It is evidence your instrument cannot measure the difference. The differences are still there, and some of them are enormous. They are just not feature-shaped.

But surely the features do differ

The obvious objection first: of course a tick is not a tick. One product's patch engine is superb and another's technically exists. True, and it proves the point rather than refuting it. If the same row on the matrix can hide both a superb implementation and a token one, the matrix is not carrying the information you need. The question is never "does it have patch management", it is "what happens on the machine where patching goes wrong", and no comparison table has a column for that.

The demo cannot rescue you either, because a demo is the vendor's best case by construction: a clean tenant, a handful of healthy devices, a rehearsed path through the happy flows. Every product looks excellent under those conditions, which means the demo, like the matrix, fails to discriminate. You are not buying the product's behaviour on its best day. You are buying its behaviour on your worst one, at 2am, on a laptop that has not checked in since Tuesday. The rest of this article is about the five places that behaviour actually varies: the agent, the defaults, the automation model, the pricing shape, and the exit.

What actually differs: how the agent fails

An RMM is an agent with a console attached, not the other way round. The console is what you are shown in the sales cycle; the agent is what you live with. And agents differ most not in what they collect but in how they behave when something goes wrong on the endpoint.

The failure mode that should frighten you is the quiet one. An agent that crashes leaves a trail. An agent that keeps checking in while silently failing to do part of its job leaves a green dashboard and a false belief. We have written before about a patching integration that reports "no updates found" when it actually means "could not look", and that pattern generalises across the whole category: the worst agent bugs manifest as reassurance.

So interrogate the failure behaviour directly. Does the platform distinguish "checked and found nothing" from "failed to check"? What does it do with a device that is online but has stopped reporting one data type? How does the agent recover from a corrupted install, and how would you ever know it needed to? Ask each vendor these questions and you will learn more from the quality of the answers than from any datasheet. A vendor who can describe their agent's failure modes in detail has met them and fixed them. A vendor who insists the agent just works has customers doing their QA.

The defaults are the product you really bought

In principle every RMM is infinitely configurable, and vendors lean on this: whatever you dislike, you can change. In practice, teams run far closer to the defaults than anyone admits, because tuning monitoring policies is exactly the kind of important, non-urgent work that loses to a full ticket queue every single day. Two years in, most estates are running a lightly edited version of whatever the product shipped with.

That makes the out-of-box experience a preview of your long-term reality, and nowhere more than alerting. An RMM that installs on a hundred devices and produces eight hundred alerts in its first week has told you precisely what it thinks an alert is worth, and a team drowning in noise stops seeing real incidents long before anyone gets around to fixing the thresholds. The volume you see in week one, untuned, is the honest signal. Judge it as such.

The automation model is a worldview, not a checkbox

Every product ticks "automation", and the tick hides the deepest difference in the category. One school gives you a script library and a scheduler: powerful, and quietly a commitment to author, test and maintain a codebase of remediations yourself, forever. That is a fine trade for a team with real engineering capacity, and a slow-motion failure for a team of two, because the library decays as Windows moves underneath it and the person who wrote it leaves.

The other school ships the remediation logic as part of the product, increasingly with AI attached. Here the risk inverts: instead of maintenance burden, opacity. If a platform advertises AI-driven anything, make it concrete. What exactly will it do without a human approving it? What is the worst action it can take unattended? Can you see, afterwards, precisely what it did and why? Confident, specific answers describe a real capability with real guardrails. Vague gestures at intelligence describe a demo.

Neither school is wrong, but they suit different teams, and this single axis should shape your shortlist more than thirty matrix rows put together. Buy the automation model you can realistically operate, not the one that impressed you.

Pricing shape matters more than the price

Two quotes for the same estate can differ by a third and still matter less than the shape of the number. Per-technician pricing punishes growing the team, so it quietly discourages hiring. Per-endpoint pricing scales smoothly but adds up fast across a large estate. Bundles bury the RMM inside a suite where the real per-unit cost is unknowable, which is precisely the point of them. We have covered this ground from the seller's side in our piece on MSP pricing models, and the logic is symmetrical when you are the buyer: whatever the metric, you will optimise against it, so pick the metric you can live with optimising.

Then look at the term. A three-year commitment with an auto-renewal clause is not a discount, it is the vendor pricing in your future dissatisfaction. Among MSPs who switch RMMs, the most common trigger is not a missing feature but a contract that could not flex when the business changed. If the product is as good as the salesperson says, it can be that good on a rolling term.

"We can always migrate later" is the costliest sentence in the deal

The other standard objection to all this care: just pick something reasonable, and switch if it disappoints. Everyone in this industry knows how that ends, because everyone has met an MSP running an RMM they have hated for five years. Migration means touching every endpoint, rebuilding every policy and automation, retraining every technician, and re-learning every alert's meaning, all while the day job continues. The switching cost is so high that mediocre platforms retain customers for years on inertia alone. Vendors know this, which is why retention does not prove quality.

So evaluate the exit while you still have leverage, before signing. Can you export your data, all of it, in a usable format, without a professional services engagement? Can you mass-remove the agent cleanly? What does the contract say about your data after termination? A vendor confident in the product makes leaving easy, because they expect you to stay for better reasons. A hard exit is a confession.

So how do you choose an RMM? Run the ugly trial

The remaining shortcuts fail for the same underlying reason. "Buy the market leader" outsources the decision to other people's circumstances, and in a category reshaped by consolidation, the leader you buy is often an acquisition target whose roadmap and pricing you cannot predict. "Buy the cheapest" optimises the one number this article has argued matters least. Both are ways of avoiding the work of evaluating against your own estate, and your estate is the only benchmark that counts.

The method that does work is cheap and unglamorous. Shortlist two or three products on the axes above. Then trial each one on your fifty ugliest devices: the ancient tablet in the warehouse, the laptop that lives on hotel wifi, the server nobody dares reboot. Give it a month and score four things: how the agent behaved when it failed, how much noise the defaults produced untuned, whether the automation actually closed work without you, and how honest the answers were when you asked about leaving.

That is how to choose an RMM: not by counting ticks, but by testing the behaviours the ticks conceal, on the estate you actually run.

Where this fits with Helios

An RMM vendor telling you how to buy an RMM should expect scepticism, so we will keep this short and testable. Helios is built around the axes this article says matter: an agent designed to say "could not check" rather than pretend, defaults tuned to be quiet until something is wrong, automation through Helio AI that shows its reasoning and its actions, per-device pricing on a rolling term, and your data exportable whenever you want it. We would rather you held every vendor to that standard, us included, because it is the standard the ugly trial reveals anyway.