What belongs in the base rate, what is billed separately, and how response time should be written so it means something at three in the morning.
Remote hands is the line item every hosting quote mentions and almost none of them define. Two operators can offer what looks like the same service and mean quite different things by it: one covers a reseat and a cable check inside the rate, the other bills for both. Before you compare two offers on price, you need to know what remote hands covers, what triggers a response, and what happens when the task turns out to be bigger than a five-minute fix.
What the work looks like
Across a fleet of any size, remote hands is mostly small and mostly routine. A card comes loose and needs reseating. A fan fails and needs swapping. A unit throws an error and needs a power cycle. A network cable pulls partway out of a switch port. A machine needs relocating a rack over because a row is being rebalanced. Each is minor on its own, and none requires a specialist, but across a large enough deployment they happen often enough that how they are scoped and billed changes your monthly cost in a way a single line item on a term sheet does not make obvious.
- Reseating a card or module after a fault alert
- Power-cycling a unit that has dropped offline
- Swapping a failed fan or PSU where a spare is on site
- Checking or reseating a network or power cable
- Basic firmware reflash on a unit already on site
- Visual inspection following an alarm or alert
The question is not whether an operator offers remote hands. Almost all of them do. The question is which of these tasks sit inside the base rate as a matter of course, and which ones start a separate invoice the moment a technician touches the machine.
What sits inside the base rate
Most hosts fold a baseline of low-skill, short-duration work into the standard hosting fee, because refusing to would mean invoicing for every reseat on a fleet of any scale, which is impractical for both sides. The boundary is usually drawn by task type or by time on task rather than by a flat allowance stated as a number of visits. Beyond that boundary, work that needs parts, that needs a specialist rather than a site technician, or that takes meaningfully longer than a routine fix tends to move into billed territory.
Ask the operator to define the boundary in the agreement itself, not describe it verbally. What is the baseline scope, in plain task terms? What moves a job out of that baseline: the type of task, the time it takes, or the need for a part or a specialist? Is the answer written down anywhere you can point to later, or is it something you were told once and have to remember?
Response time that means something at three in the morning
A quoted response time is only as good as its definition, and a definition has several parts that a sales conversation tends to skip. The clock has to start from a stated event: an alert firing in a monitoring system, a ticket being logged, or a human confirming receipt are three different starting points, and they do not produce the same number. The commitment has to name its hours: does it apply around the clock, or only during a defined working day, and does a fault raised outside those hours simply wait? And the commitment has to say what "response" means: acknowledgement that someone has seen the ticket is not the same promise as a technician arriving at the rack, and a quote that blurs the two is not really quoting anything.
Ask the host to write the definition into the agreement rather than the marketing page: what event starts the clock, what hours the commitment covers, whether the number describes acknowledgement or physical response, and what you are owed if it is missed. A number without those four pieces attached is a description of intent, not a commitment you can hold anyone to.
Escalation, documentation and proof of work
Most faults resolve at the first level: a site technician handles the reseat or the swap and closes the ticket. Some do not, and the interesting question is what happens next. Is there a defined trigger for escalating from a site technician to a specialist or to facility management, or does escalation depend on someone noticing the ticket has sat too long? Who makes that call, and does the fleet owner get visibility when it happens, or only a note in a monthly summary after the fact? A fault that stays unresolved at the first level for an extended period behaves, from a device-level uptime perspective, exactly like the measurement gaps we cover in our piece on uptime and availability: the site can look fine while your row is not.
Escalation only matters if you can see it happened, which is a question of evidence. A ticket that says "resolved" without a note on what was done tells you nothing you can check. Ask what gets logged for a typical remote hands job: a timestamp for when the fault was first seen and when it was closed, a note on what was done, and, where a part was replaced, some record of what went in. Ask whether that record is visible to you as it happens, through a portal or a live ticket, or only compiled and sent after the fact. The difference matters less for the routine reseat than it does the day something on your row goes wrong twice in the same month and you need to know whether the first fix addressed the cause.
How the work beyond the baseline is billed
Three billing models are common for work outside the baseline. Some agreements include a block of hours per month and bill anything above it at an agreed hourly rate, which suits fleets with steady, predictable work. Others bill per incident, a fixed charge per ticket regardless of its length, which is easy to forecast but treats a two-minute reseat like an afternoon's work. Per-hour billing, usually with a minimum increment, tracks the effort most closely and makes a month's cost harder to predict. Whichever model applies, ask whether unused included hours roll over and how a job that crosses from baseline into billed work is counted.
What to get in writing before you sign
Before comparing two remote hands offers on their headline promise, get four things into the agreement itself: the baseline scope stated as task types, what moves a job outside that scope, the full definition behind the response time figure, and how escalation and documentation work in practice. A host who can hand you these four things in writing has scoped this before. A host who answers with "we will take care of it" has not been asked the question in enough detail yet.
The aim is not the fastest-sounding promise but knowing what the promise covers before a fault on your row tests it. Our hosting page sets out how we scope remote hands as part of the standard agreement rather than as a service you discover the terms of on your first invoice.
