What should a Remote Hands request include?
A good request lets someone act without calling you back. The template below covers the details that most often go missing. Copy it into an email or ticket and fill in each line.
- Site: facility name, address, suite, cage or room
- Location: rack, U position and device name or serial number
- Action needed: the exact physical task, in order
- What you already know: symptoms, lights, alarms, recent changes
- Timing: deadline, change window and how urgent it is
- Access: who can authorize entry, escort needs, badges and permits
- Parts: what is on site, what is being shipped and tracking details
- Contact: a person and a method you will monitor during the work
- Stop points: anything the technician must not do without confirmation
- Evidence: photos, serial numbers, test results or a completion report
What does a complete request look like?
Here is a fictional example. “Site: Example Data Center, Suite 100. Location: Rack 14, U20, switch SW-14A. Action: replace the failed top-of-rack switch with the unit shipped to the facility, label every cable first, and reconnect to the labels. Known: link lights off since 02:10, no recent changes. Timing: Thursday 22:00 to 23:00 change window. Access: A. Example authorizes entry, escort required. Contact: A. Example by phone during the window. Stop point: confirm with me before powering on. Evidence: before and after photos and serial numbers.”
Which details are most often missing?
- The exact rack and U position, which forces the technician to search
- Who can approve entry, which delays arrival at the door
- A reachable contact during the work, which stalls decisions
- The evidence you want back, which leads to a rework or a second visit
How does this template save time?
Each missing detail costs a round trip of messages. Sending them once reduces the time before work starts and gives you a record you can compare against the completion report afterward.
How should you word the action needed?
Vague instructions cause delays and mistakes. Name the device, the location and the exact step. The examples show how to turn a vague request into one that can be acted on.
Scroll the table sideways for more.
| Vague | Specific |
|---|---|
| Fix the switch | Replace failed switch SW-14A at Rack 14, U20 with the unit delivered to the facility. Label every cable first, then reconnect to the labels. |
| Check the server | Report the LED states on the front and rear of server SRV-22 and photograph them. Do not power it off. |
| Reboot it | Press the power button on SRV-22 for ten seconds only after I confirm by phone, then report what the lights do. |
| Move the cable | Move the cable from port 12 to port 14 on patch panel PP-3, then confirm link on both ends. |
How do you keep requests consistent across a team?
- Use one shared template so everyone sends the same fields
- Agree naming for sites, racks and devices and use it everywhere
- Link to the rack elevation or port map instead of describing it
- Have a second person check urgent requests before they are sent
- Keep completed requests and records together so the next visit starts with history
