The Questions to Settle Before Deploying

Most RMM deployments begin with agent rollout and work backwards. These six questions determine the structure and are cheap to answer first.

The recommendations in “The Questions to Settle Before Deploying” become sustainable only when the recurring work has visible owners and enough capacity. A team assessing daily work tracking 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.

One: what are you being paid to do

Monitor and report? Monitor and fix? Everything including the client's own applications?

The answer determines what you monitor, because alerting on something you are not paid to fix generates work with no revenue.

Write it per client, not as a company position.

Two: who acts on an alert, and when

During hours, out of hours, at weekends.

If nobody is on at three in the morning, do not alert at three in the morning — queue it.

An alert with no recipient is a log entry with delusions.

Three: what does the client have to approve

Reboots, software installation, configuration change, access to specific machines.

Establish it at onboarding and record it.

The absence of this answer is the commonest source of stalled work.

Four: what is in scope

Which machines, which servers, which network devices, which applications.

And explicitly: what is not.

The out-of-scope list is the more useful of the two, because it is what you point at when something fails.

Five: how is this billed

Per device, per user, per outcome — each has its own note and each changes behaviour.

Notably: per-device billing makes you reluctant to decommission machines, and the client notices.

Six: what happens at the end

How the agent is removed, what data you hand over, how long you retain records.

Deciding this at onboarding is much easier than at termination, which is usually the point of lowest goodwill.

Writing the answers down

One page per client. Six headings.

Updated when the contract changes.

It is the document a new technician reads before touching the estate, and most providers do not have it.

What this prevents

Monitoring things nobody is paid to fix.

Alerts arriving when nobody is awake.

Work stalled waiting for an approval nobody identified.

And an exit that becomes a dispute.

What to check

Can you produce the six answers for your newest client?

Does your alerting respect your actual staffing hours?

Is there a written out-of-scope list anywhere?

And do you know how you would offboard your largest client?

The point

Six questions settle the shape of a deployment: what you are paid to do, who acts on alerts, what needs approval, what is in scope, how it is billed, and what happens at the end..

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.