Automation is the half of this category that is hard to compare and easy to oversell. Every vendor demonstrates the same three things: a script library, a trigger, and a dashboard with a green number on it. What decides whether any of it earns its keep is narrower: whether the jobs you actually repeat are the jobs the tool can hold, and whether a technician still has to check afterwards. An automation that needs checking has moved the work rather than removed it.
Ask vendors to quote against your actual endpoint count
MSP automation tools, and the jobs worth automating first
The jobs that pay back fastest are the ones done often, done identically, and cheap to get wrong: disk cleanup, service restarts, reboot after patching, onboarding a new machine to a client's standard, and closing an alert that cleared itself. The ones that rarely pay back are the ones that look impressive in a demo, because they are usually rare, client-specific and expensive when they misfire. Count how many times a month a job runs before automating it. MSP automation is an arithmetic problem before it is a software problem.
What to ask before a console is allowed to act on its own
Three questions, and the answers should be visible in the product rather than promised. What did it decide, and when: an action log a person can read, per device, without exporting anything. What is it not allowed to do: a way to scope automations to a client, a group or a maintenance window rather than the whole estate. And how do I stop it: a single switch that halts a running job across the fleet. A product that cannot answer the third should not be trusted with the first, because the failure mode of automation is doing the wrong thing quickly on every machine at once.
An RMM dashboard is a summary, not a report
The dashboard is what gets demonstrated and it is the weakest evidence in the product, because a green number is only as honest as the check behind it and the machines missing from the count. The questions worth asking are which devices are excluded from each figure, what a check does when it cannot run at all, and whether the number a client sees in a monthly report is derived from the same query. Where those diverge you get the worst outcome available: a reassuring report over a fleet nobody has looked at.
What an advanced monitoring agent does between checks
The interesting part of an agent is not the check, it is the gap between checks. A monitoring agent worth the name buffers what it saw while the machine was off the network and sends it when the machine comes back, rather than reporting silence as health. It also decides locally: a disk filling can be cleared without waiting for a console to notice, which is the cheapest automation there is. Ask what the agent can do with no connection and what it does with the results when the connection returns, because a laptop on a bad line is the normal case rather than the edge case.
Questions people ask about rmm automation
Is RMM automation the same as scripting?
Scripting is the mechanism; automation is scripting plus a trigger, a scope and a record of what happened. A script library with no scoping and no log is a shared folder with a run button.
What should an MSP automate first?
Whatever is done most often and identically across clients. Onboarding a machine to a standard and post-patch reboots are the usual first two, because both are frequent, dull and easy to check.
Does automation reduce the licence cost?
No. Every vendor here prices per endpoint whatever the automation does, so the saving is in hours rather than in the bill. That is the right way round for an MSP, whose cost is people.
How do I know an automation worked?
By reading the action log for a device rather than the dashboard. If the product cannot show you what it did to one named machine last Tuesday, treat its summary figures with the same suspicion.