What It Is Not: Four Adjacent Things

RMM overlaps with several other disciplines. Treating it as a substitute for any of them leaves a gap nobody notices until something fails.

The recommendations in “What It Is Not: Four Adjacent Things” become sustainable only when the recurring work has visible owners and enough capacity. A team assessing this workflow overview can use time and project records to see where operational effort accumulates, without treating activity data as a substitute for technical evidence or direct discussion with technicians.

For an independent operational benchmark, compare the local practice with NIST Cybersecurity Framework; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

It is not endpoint security

It reports that antivirus is running. It does not detect or respond to an attack.

The overlap is growing as platforms bundle security features, which blurs the line commercially and not technically.

A client told they are "monitored" frequently hears "protected", and correcting that is your job rather than theirs.

It is not asset management

It inventories what has an agent.

It does not track licences, ownership, warranty, cost or lifecycle, and machines without an agent are invisible to it.

Which means the RMM inventory is a subset of the asset register, and treating it as complete is how estates acquire unmanaged machines.

It is not a service desk

It raises alerts. Somebody still has to triage, communicate and resolve.

The ticketing, the client communication and the measurement of response live in the PSA.

An RMM without a service process behind it generates work nobody owns.

It is not internal IT monitoring

The adjacent discipline it most resembles and the one with different assumptions.

Internal monitoring assumes you own the machines, set the standard and can mandate change.

Everything about multi-tenancy, contracts, billing and client approval is absent there and central here, which is why internal monitoring advice transfers badly.

The gaps this confusion produces

Security assumed to be covered because monitoring exists.

Assets assumed to be known because the dashboard lists machines.

Response assumed to happen because alerts are raised.

Each has produced visible failures in this industry, and each is a definition problem rather than a tooling one.

Saying it to clients

Clients buy a feeling of being looked after and the words they use are imprecise.

Write down what is monitored, what is managed, what is protected and what is none of those.

One page per client, agreed at onboarding, and it is the document that resolves the argument after an incident.

What to check

Would your clients describe monitoring and protection as the same thing?

How many machines in your clients' estates have no agent?

Who triages an alert at two in the morning?

And is there a written statement of scope per client?

The point

Clients hear monitoring and understand protection.

Correcting that is your job rather than theirs.

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.