Operations
Remote hands vs smart hands: what is the difference?
· 6 min read
Remote hands is simple, prescriptive work carried out on your instruction: pressing a button, swapping a cable, reading a status light. Smart hands is skilled work requiring judgement on site: installing and configuring hardware, tracing faults, terminating fibre and troubleshooting alongside your engineers. The distinction matters because the two are usually priced differently and, more importantly, because assuming you have one when you need the other is how a 20-minute intervention turns into a lost night.

Every colocation provider offers something called remote hands. Most also offer something called smart hands. The terms are used loosely enough across the industry that two providers can mean quite different things by the same word, which is a problem when you are relying on the service at three in the morning.
What remote hands actually covers
Remote hands is work that requires physical presence but no real technical judgement. You know exactly what needs doing and you need someone standing in front of the rack to do it. Typical examples:
- Power cycling a device that has stopped responding
- Reseating a cable, an optic or a drive
- Reading a status light, an LCD panel or a console message back to you
- Pressing a physical reset button
- Confirming that a device is present in the rack position you think it is
The defining characteristic is that you supply the diagnosis and the instruction. The person on site executes it. If the instruction turns out to be wrong, remote hands will faithfully carry out the wrong thing.
What smart hands adds
Smart hands is work where the engineer on site contributes technical skill rather than just presence. They can interpret what they are seeing, work through a fault with you, and take decisions within the scope you have agreed. Typical examples:
- Installing and cabling new hardware to a build sheet
- Terminating, testing and certifying copper and fibre links
- Running a console session and working a fault with your engineer on the phone
- Tracing a cable path through containment to find where a link actually goes
- Replacing a failed component and verifying the replacement is working correctly
- Configuring a device under your direction
| Feature | Remote hands | Smart hands |
|---|---|---|
| Who diagnoses | You do, in advance | Worked out together on site |
| Typical task | Power cycle, reseat, read a light | Install, terminate, trace, configure |
| Instruction | One unambiguous sentence | A goal and a scope |
| If the diagnosis is wrong | The wrong thing is done faithfully | The engineer says so |
| Skill required on site | Presence and care | Judgement and qualifications |
| Documentation returned | Confirmation the task was done | Photographs, as-built records, test results |
Why the distinction costs people money
The failure mode is predictable. A device stops responding, you raise a remote hands ticket for a power cycle, and someone power cycles it. It comes back up and fails again an hour later, because the actual fault was a failing power supply that a skilled engineer would have spotted from the amber light and the smell. You have now spent two interventions and an hour of downtime confirming that your diagnosis was wrong.
The reverse mistake is less costly but still wasteful: paying smart hands rates for work that genuinely was a button press. Most providers, including us, will tell you when a request is simpler than you scoped it.
Facility smart hands and independent providers
There is a second distinction worth understanding: whether the service comes from the facility operator or from an independent provider. Facility smart hands is convenient, because the staff are already in the building. It is also constrained: the operator's technicians work across every customer in the hall, so their availability at any moment depends on what else is happening, and their familiarity with your specific estate is necessarily limited.
An independent provider gives you engineers who work to your build standard across every site you occupy, rather than a different team with different conventions in each facility. Where you have equipment in several operators' buildings, that consistency is usually the deciding factor.
What to ask before you need it
- What is the response SLA, and does it differ for prepaid and ad-hoc requests?
- Is the SLA a response commitment or a fix commitment? It should be response, and be sceptical of anyone promising a fix time.
- Who is authorised on your facility access list today, and how long does adding someone take?
- What documentation comes back after the work: photographs, as-built records, test results?
- For multi-site estates, will the same standard and the same labelling convention be applied everywhere?
The last question about access lists is the one people most often skip and most often regret. Operator authorisation takes days to process at most facilities. Doing it in advance is the single largest factor in how fast anyone can actually reach your rack.

