BLOG
Remote hands vs. smart hands: what you actually need
13 June 2026 · Layer One
Ask three datacenter providers what “remote hands” and “smart hands” include and you’ll get three different answers. Some use the terms interchangeably. Some draw a line between them and put the more interesting work behind a higher tariff. Some never define them at all and just bill you when you ask for something. That ambiguity isn’t harmless. It’s where customers end up paying for work they didn’t want, or finding out a job is “out of scope” at the worst possible moment.
So it’s worth being precise about what you actually need on the floor, regardless of what a price list calls it.
What remote hands means (to us)
For us, remote hands is everything that happens on the hardware. Reboots and power cycles. Swapping a failed drive, a PSU, a NIC. Running and reseating cables. Connecting to a BMC. Visual inspections when you need eyes on a rack and you’re not in the building. All of it with photo proof, so you can see what was done rather than take our word for it.
That’s a clear line: physical work on physical kit. It doesn’t try to be clever about it. The value is in being reliable and traceable, not in deciding what your systems should do.
The configuration question
This is where “smart hands” usually enters the conversation, and where the ambiguity does real damage. The logical configuration of your systems (the switch config, the OS, the firewall rules, the things that define how your estate behaves) belongs with your engineers. They know the environment, they own the consequences, and they’re the ones who’ll be debugging it at 2am if it’s wrong.
Handing that to a third party who touches it occasionally, between dozens of other customers’ racks, trades away exactly the control you should be keeping. A pair of hands that’s great at swapping a drive is not the right place for your routing policy to live.
Console sessions: the best of both
The honest answer to “but sometimes I need someone on site to configure something” is the console session, and it’s the model we work to. We provide the hands and the physical access. We connect to the console (through our laptop, live on site at the rack). Your engineer then works through that session in real time, doing the logical configuration themselves.
You get the on-site presence without giving up control. We stay on the hardware where we belong; your configs stay yours, made by the people who own them. Nobody has to pretend a field engineer is also your network architect.
What to ask your provider
Before you sign anything, the useful questions aren’t about the labels. They’re about who holds what. A short checklist:
- Who holds the credentials? If logical config is in scope, whose logins are being used, and where do they live afterwards?
- What exactly gets documented? Is there a record of what was done on each visit, and where does it go?
- What proof do you get? Photos per job, or just an invoice line that says “remote hands, 1 hour”?
- What’s explicitly out of scope? The answer you don’t want to discover mid-incident.
The terms will keep getting used loosely. The answers to those four questions won’t.
Not sure which of these you actually need for your racks? Drop us a line and we’ll sort out the scope before you commit to anything.