Looking for On-Demand Tech Support?
Techmate has the boots-on-the-ground IT Support where and when you need it.
Schedule a Discovery CallHow to Write a Remote Hands Request That Gets Done Right the First Time
Quick answer: A good remote hands request states the exact location (facility, cage, rack and rack unit), identifies the device by label and serial number, lists numbered physical steps, defines what “done” looks like, sets stop conditions and names the engineer to call. Techmate technicians in 450+ US cities work from requests like this for onsite IT network services.
Remote hands exists because your engineers cannot be everywhere. Your servers live in a colocation facility hours away, or your network gear sits in a closet at a branch you have never visited. So you send instructions, and someone else’s hands do the work.
The quality of that work depends almost entirely on the quality of those instructions. A technician can only be as precise as the request they receive. “Please reboot the server” might result in the wrong server being power-cycled. “Check the cabling” might result in a photo of a tangle and nothing else.
The stakes are higher than they look. Uptime Institute’s Annual Outage Analysis (Uptime Institute, 2025) found that nearly 40% of organizations suffered a major outage caused by human error over the past three years, and 85% of those incidents came from staff not following procedures or from flawed procedures. A remote hands request is a procedure. Write it like one.
This guide gives you a remote hands request template, explains each field, and shows good and bad examples side by side for both a data center and a branch office.
What is a remote hands request?
A remote hands request is a written work order asking an onsite technician to perform physical tasks on your behalf, usually in a data center, colocation facility or network closet. Common remote hands tasks include power cycling devices, reseating cables or components, swapping failed drives or power supplies, connecting console cables, reading status lights and taking photos.
When the tasks require more skill or judgment (installing and cabling new equipment, basic troubleshooting, rack and stack), they are often called smart hands. The request-writing principles are the same for both, though the level of detail grows with the complexity of the task. If you are unsure which you need, see our glossary of smart hands, remote hands and field services or the remote hands task catalog, which ranks 50 common requests by complexity.
Why do remote hands requests fail?
Most failures fall into five buckets:
- Wrong device. The request said “the Dell server in rack 12,” and there are four.
- Ambiguous action. “Check the connection” could mean look, reseat, replace or test.
- Missing access. The technician was not on the facility’s access list, or nobody knew who had the closet key.
- No success criteria. The technician finished the step but nobody confirmed the outcome.
- No one to call. Something unexpected happened and the requester was unreachable.
Every field in the template below exists to prevent one of these. When a failure leads to an outage, it gets expensive quickly: in Uptime Institute’s Annual Outage Analysis (Uptime Institute, 2026), 57% of respondents said their most recent major outage cost more than $100,000.
What fields belong in a remote hands request template?
Copy this structure into your ticketing system or send it as a plain-text request.
| # | Field | What to include | Failure it prevents |
|---|---|---|---|
| 1 | Request title | Short, specific summary: “Replace failed PSU2 on DB-PROD-03” | Ambiguous action |
| 2 | Priority and window | Urgency and any change window: “P2, perform between 22:00 and 02:00 local” | Work at the wrong time |
| 3 | Facility | Facility or office name, address and suite | Wrong site |
| 4 | Location in facility | Cage or suite number, row, rack and rack unit (U); closet name and floor for offices | Wrong device |
| 5 | Device identification | Hostname label, make, model, serial number and asset tag | Wrong device |
| 6 | Reference photo | Photo or diagram of the rack with the device circled, if available | Wrong device |
| 7 | Access | Confirmation the technician is on the access list, plus key, badge or escort details | Missing access |
| 8 | Parts | What parts are needed and where they are (onsite spares, inbound shipment with tracking) | Wasted visit |
| 9 | Steps | Numbered physical actions, one action per step | Ambiguous action |
| 10 | Success criteria | What the technician should see or confirm when finished | No success criteria |
| 11 | Stop conditions | Situations where the technician should stop and call before proceeding | Outage from guessing |
| 12 | Contact during work | Engineer name, phone and backup contact | No one to call |
| 13 | Deliverables | Photos, readings, serial numbers or notes to return | No record of the work |
Not every request needs every field filled in at length. A status-light check needs fields 1 to 7, 10 and 12. A firewall swap needs all 13, plus a rollback plan.
How do you write remote hands steps a technician can follow?
The steps section is where precision matters most. Follow four rules:
One action per step. “Unplug the power cable from PSU2 and remove the PSU” is two steps.
Use physical identifiers, not logical ones. The technician can see labels, port numbers and LEDs. They cannot see IP addresses or hostnames unless those are printed on a label.
Describe what they should see. “The PSU2 LED will be amber” helps the technician confirm they are on the right component.
Include the undo. If a step might cause an outage or not work, say how to reverse it.
For tasks you request often, write the steps once as a reusable runbook and attach it to the request. Our guide to field IT support runbooks covers how to structure them.
Bad example (data center)
Server DB3 has a bad power supply. Please replace it. Part is onsite.
Good example (data center)
Title: Replace failed PSU2 on DB-PROD-03
Location: Cage 214, Row C, Rack C07, U18 to U19
Device: Label “DB-PROD-03”, Dell PowerEdge R750, Service Tag ABC1234
Parts: Replacement PSU in the spares bin at the bottom of Rack C07, labeled “PSU R750”
Steps:
- Locate DB-PROD-03 at U18 to U19. Confirm the label and service tag match.
- At the rear of the server, confirm PSU2 (right side, viewed from rear) shows an amber or unlit LED and PSU1 shows green.
- Call Maria (below) before touching the server.
- Unplug the power cable from PSU2 only. Do not touch PSU1.
- Press the release tab and slide PSU2 out.
- Insert the replacement PSU until it clicks.
- Reconnect the power cable to PSU2.
Success criteria: Both PSU LEDs are green. Maria confirms redundancy is restored.
Stop conditions: If PSU1 is not green, or the label does not match, stop and call Maria.
Contact: Maria Chen, 555-0100; backup: on-call line 555-0199
Deliverables: Photo of rear of server showing both green LEDs; serial number of the removed PSU.
The good example takes five more minutes to write. It saves an hour of confusion and removes almost all risk of the wrong server losing power. Hardware failures like this are routine: in an Opengear survey of 1,000+ CIOs, CSOs and network engineers (Business Wire, 2025), 26% of network engineers named server hardware failures as a common cause of outages. Templates for the swaps you do most often pay off fast.
Bad example (branch office closet)
The switch at the Denver office is down. Please swap it with the new one we sent.
Good example (branch office closet)
Title: Swap failed access switch SW-DEN-02 with pre-configured spare
Location: Denver branch, 3rd floor, IT closet behind reception (key with office manager, Jordan, 555-0130). Wall rack, second switch from top.
Device: Label “SW-DEN-02”, 48-port switch, serial on the rear label ending in 7Q2
Parts: Pre-configured replacement in a box labeled “SW-DEN-02 SPARE”, delivered to reception (tracking in ticket)
Steps:
- Photograph the front of the switch with all cables in place.
- Call Sam (below) and confirm you are at the right switch.
- Apply a numbered label to each cable that matches its port number, if not already labeled.
- Disconnect all cables and power, unmount the old switch.
- Mount the replacement in the same position and connect power.
- Reconnect every cable to the same port number it came from.
- Wait for port lights, then call Sam to confirm the switch is online.
Success criteria: Sam confirms the switch is reachable and users at the branch have network access.
Stop conditions: If the replacement does not power on, or cables are unlabeled and the photo is unclear, stop and call Sam.
Contact: Sam Ortiz, network engineer, 555-0140; backup: NOC 555-0199
Deliverables: Before and after photos, serial of the removed switch, failed unit packed for RMA.
Office and branch requests need two things data center requests often do not: who has the key, and who at the site can confirm users are working again.
What should you ask the technician to send back?
Remote hands deliverables close the loop and create a record. Ask for:
- Photos before and after, especially for cabling and rack work
- Serial numbers of any parts removed and installed
- LED or display readings at completion
- Anything unexpected, such as damaged cables, missing labels or loose equipment
Over time, those photos become a visual history of your rack, which is invaluable for audits and future changes. See our photo documentation standards for what good closeout photos look like.
How do you handle access for remote hands?
Data centers and colocation facilities are strict about access, and they should be. Before sending a remote hands request:
- Confirm whether the facility’s own staff will perform the work or whether you are sending a third-party technician
- If third-party, submit the technician’s name to the facility’s access list in advance
- Provide any cage combination or key instructions through a secure channel, not in the ticket body
- Note whether the technician needs an escort
For offices and network closets, access is usually simpler but more often forgotten. Name the person who has the closet key, the hours they are onsite and a backup. For logical access, such as a temporary login on a device, follow the principles in how to give remote hands technicians secure, time-bound access.
Should you use the facility’s remote hands or a third-party provider?
Most colocation providers offer remote hands, which is convenient for simple tasks like reboots and visual checks. For more complex work, or when you need consistent technicians across facilities and offices, many companies use a third-party smart hands services provider.
| Need | Facility remote hands | Third-party provider |
|---|---|---|
| Simple tasks (reboot, visual check) | Convenient, usually fast | Works, may be more than needed |
| Complex tasks (rack and stack, troubleshooting) | Varies by facility | Typically stronger |
| Consistency across many facilities | Different at each facility | One provider, one standard |
| Coverage for offices and closets | Not available | Available |
| Access logistics | Already onsite | Requires access list setup |
Techmate provides remote hands and smart hands services in data centers, colocation facilities and network closets across 450+ US cities. See what smart hands actually covers in a data-center visit and our guide to smart hands IT services.
What mistakes make remote hands requests take longer?
- Writing from memory. Rack positions change. Check the current rack elevation or the last closeout photos before writing.
- Mixing instructions and background. Put context in one short paragraph at the top and keep steps clean.
- Leaving parts unconfirmed. “Part is shipping” is not the same as “part was delivered and is in the spares bin.”
- No backup contact. The engineer gets pulled into another incident and the technician waits.
- Sending passwords in the ticket. Use a secure channel and time-bound credentials.
- Never updating the template. When a request fails, add the missing field or step so it cannot fail the same way twice.
What should you check before sending a remote hands request?
Before you submit any remote hands request, check:
- Could someone who has never seen this rack find the right device?
- Is every step a single physical action?
- Does the technician know what success looks like?
- Does the technician know when to stop?
- Will someone answer the phone during the work window?
- Is access arranged and parts in place?
If all six are yes, send it. To see how a request moves from ticket to technician with Techmate, read how Techmate dispatch works.
The bottom line
Remote hands is only as good as the request behind it. Precise location, unambiguous device identification, numbered steps, clear success criteria, stop conditions and a reachable contact turn a risky task into a routine one. Build the template into your ticketing system once and every future request gets better.
Need reliable remote hands for your racks, cages or closets? Contact Techmate.
Frequently Asked Questions
What should a remote hands request include?
Include the facility and exact rack location, device identification with label and serial number, numbered physical steps, success criteria and stop conditions. Add access arrangements, where the parts are, a contact who will answer during the work and the deliverables you want back. For complex or production-affecting tasks, attach a rollback plan as well.
What tasks can remote hands perform?
Common tasks include power cycling devices, reseating or replacing cables and components, swapping drives and power supplies, connecting console cables, reading status lights and taking photos. More complex work, such as rack and stack, guided troubleshooting and cutovers, is usually called smart hands and needs a more detailed request and an engineer on the line.
What is the difference between remote hands and smart hands?
Remote hands usually refers to simple physical tasks performed exactly as instructed. Smart hands refers to tasks requiring more technical skill or judgment, such as installation, cabling, troubleshooting and network changes. The request template is the same for both, but smart hands requests need fuller steps, stop conditions and a rollback plan.
How do I make sure remote hands works on the right server?
Identify the device by physical location (cage, row, rack and rack unit), printed label and serial number, and attach a reference photo if you have one. Then make the first step a confirmation: the technician checks the label and serial against the request and calls the engineer before touching anything.
Should I use my data center’s remote hands or a third party?
Facility remote hands is convenient for simple tasks like reboots and visual checks because staff are already onsite. Third-party providers are often better for complex work and for consistent standards across multiple facilities, and they can also cover offices and network closets, where no facility staff exist.
What should remote hands technicians send back after a job?
Ask for before and after photos, serial numbers of removed and installed parts, final LED or status readings, and notes on anything unexpected, such as damaged cables or missing labels. Store them with the ticket so the next request at that site starts from current information rather than memory.
Want your remote hands requests and coverage reviewed across all your sites? Book a free 30-minute IT support audit and we will help you tighten your templates and match each request type to the right provider.
