Key takeaways

  • Remote hands = you decide the steps, an engineer on site carries them out.
  • Smart hands = the engineer also uses judgement: diagnosing, choosing a fix and adapting on the floor.
  • The right choice depends on whether you already know what needs doing, not on how big the job looks.

Your equipment sits in a facility you can’t easily get to. When something needs doing on the floor, you have two broad options: send instructions and have someone follow them, or send a problem and have someone solve it. Providers call the first remote hands and the second smart hands, though the terms are often used loosely, or interchangeably. Mixing them up is how you end up paying for skill you didn’t need, or booking a visit that can’t finish the job.

The short answer

Remote hands is on-site technical support where you supply the steps and an engineer carries them out. Smart hands is on-site technical support where the engineer also applies engineering judgement: they diagnose the problem, decide how to fix it and adapt if what they find isn’t what the runbook expected.

The clearest test is a question: who decides what to do? If it’s you, that’s remote hands. If you’re relying on the engineer to work it out, that’s smart hands.

What remote hands looks like in practice

Remote hands suits work where you already know the answer and just need a person to act on it. Typical examples:

  • Restarting or power-cycling a server, switch or firewall
  • Re-seating a cable or a card
  • Swapping a part you have supplied, such as a drive or a power supply
  • Reading a status light or a display and reporting what it says, with a photo if useful
  • Staying on site while your vendor or your own team works on the console remotely

What these have in common is that the decision has been made before the engineer arrives. You give them the steps, they follow them and tell you what happened. You can read more on our remote hands service page.

What smart hands looks like in practice

Smart hands suits work where the steps aren’t known in advance, or where doing the job properly takes skill. Typical examples:

  • Tracing a fault when a link is down and you don’t yet know why
  • Re-terminating or replacing structured cabling
  • Racking and stacking new equipment and bringing it up to spec
  • Diagnosing a hardware problem and deciding whether it’s the part, the port or the cable
  • Colocation infrastructure support that needs a qualified engineer to understand the environment

Here the engineer is reasoning about the problem, not just following one instruction. The full picture is in our guide to smart hands and on the smart hands service page.

A quick way to decide

Ask three questions before you book:

  1. Do I know exactly what needs doing? If you can write the steps down in order, remote hands can carry them out. If you can’t, you need someone who can work it out.
  2. What happens if the first step doesn’t work? If the answer is “we’d need someone to investigate”, you are in smart hands territory, even if the first step is a simple reboot.
  3. Could a wrong move cause damage or an outage? The more the outcome depends on the engineer’s judgement, the more it matters that the person on site has the skills to make it.
When a remote hands job becomes a smart hands job

A reboot that doesn’t fix the fault is the classic case. The task was simple, but the outcome needs someone to diagnose what comes next. If you think that could happen, agree with your provider beforehand how it will be handled, so the visit doesn’t stall on site.

Choosing between them

There is no rule that says one is better. They answer different questions.

  • Choose remote hands when you have a clear runbook, a known fault or a planned change and only lack a person on site.
  • Choose smart hands when the problem isn’t understood yet, the work needs skill, or you want an engineer to take responsibility for getting to a working result.

If you’re unsure, describe the job to your provider and ask them which fits. A good provider will tell you honestly if the simpler service is enough.

How to get more from either

Whichever you choose, a short visit works best with a good brief:

  • Write the steps in order, in a form an engineer can follow without guessing
  • Give the facility, cabinet and U position, and any asset labels
  • Have any access details the data centre needs, such as a booking reference or a site contact
  • Identify any parts you are supplying and make sure they are on site
  • Name someone on your side who can be reached during the visit
  • Say what “done” looks like and what you want confirmed or photographed

Most disappointing visits come from an unclear brief, not from the engineer.

How DACPROS handles it

DACPROS provides both from a hub in Hammersmith, London, and attends data centres across the UK. Attendance is Monday to Friday, 09:00–17:00, and is scheduled according to location, scope and engineer availability. Out-of-hours attendance may be available if arranged in advance.

If you already know the steps, see remote hands. If you need an engineer to work it out, see smart hands. Or tell us about the job and we’ll help you work out which fits.