Most failed remote hands visits do not fail because the engineer lacked skill. They fail because the ticket left room to guess. A vague label, a missing rack position or an unstated limit is enough to put the right cable in the wrong port.
This guide shows how to write a remote hands ticket that an engineer you have never met can follow on the first visit. It builds on our free remote hands request template, which you can copy and fill in.
What should a remote hands ticket include?
A remote hands ticket should include six things: the requester, the timing, the exact location, the steps in order, the limits and the evidence you want back. Leave one out and the engineer must guess or stop to call you.
Provider portals reflect this. The Equinix order form, for example, asks for the data center, cage and cabinet, lets you add call contacts before and after the work, and lets you enable messaging with the technician while the work is in progress.
- Requester: your name, role, a phone number that answers during the work, and your own ticket or change number.
- Timing: start and latest finish with the time zone, plus whether a change window or approval already exists.
- Location: facility, suite or cage, cabinet and the U position of each device.
- Task: numbered steps, one action per line, and what the engineer should see after each.
- Limits: what not to touch, when to stop and call, and how to roll back.
- Evidence: which photos you want and where the work notes should go.
How do you write steps an engineer can follow?
Write steps as one action per line, using label text exactly as printed, and state what the engineer should see when each step is done. Write them as you would read them aloud on a phone call.
Steps are also where tickets are weakest. The table shows the same request written two ways. The strong versions are longer, but each removes a question the engineer would otherwise have to ask while standing in front of a live rack.
Avoid words that need judgment, such as bad, old or the usual one. Replace them with something the engineer can see or read: a label, a port number, an amber light. If a step depends on a result, say what the result looks like and what to do if it looks different.
| Weak | Strong |
|---|---|
| Reboot the web server in rack 4. | In cabinet 04, U22, find the server labeled WEB-02. Press and hold the power button for five seconds until the front light goes off. Wait one minute. Press it once. Confirm the light turns green and tell me. |
| Swap the bad cable. | Unplug the cable labeled SW1-24 at the switch, port 24. Fit the new cable from the box on site. Connect the other end to patch panel B, port 12. Check the link light is on at both ends. |
| Replace the failed drive. | Drive bay 3 on the server in U10 shows an amber light. Remove it. Photograph the drive label. Fit the new drive from the parts bag. Confirm the light turns green. Tag the old drive and leave it with the site contact. |
How do you identify the right device and cable?
Identify every device by location and by label, and every cable by both ends. Wrong-port and wrong-host mistakes start when only one of these is given.
- Give the cabinet or rack ID and the U position of each device.
- Quote the label as printed on the front and the back, plus make, model and serial number.
- Give both ends of every cable: A end port, B end port, type, length and label text.
- Ask for a photo of the label before any action, so you can confirm it from your desk.
- Name the neighbors of the target device if they are similar or critical.
What limits and stop conditions should the ticket state?
The ticket should name what must not be touched, when the engineer must stop and call, and how to undo the change. Most remote hands mistakes happen to the device next to the target.
Say whether troubleshooting beyond the written steps is allowed and who approves it. For larger changes, attach a method of procedure that lists the steps, checks and rollback in order, and refer to it in the ticket.
- Do not touch: devices, ports and cabinets that are off limits.
- Stop and call if: a label does not match, a light is not as described, or anything looks different from the ticket.
- Rollback: how to put things back if a step does not behave as expected.
How do you arrange access and authorization?
Agree access and authorization before the day of the work, and keep both out of the ticket text where they are sensitive. The engineer cannot act on a request the facility will not let them enter for.
Operators tie requests to approved people. Equinix, for example, requires Smart Hands ordering permission before a user can place orders, and charges and orders are per cage, so work in two cages needs two orders. Check how your facility handles this before the first urgent request.
- Confirm that the engineer is registered with the facility and that your name is on the authorized requester list.
- Raise any facility ticket needed for entry and put its reference in your request.
- Do not put door codes or passwords in a ticket. Share them by a separate secure route, if they are needed at all.
- Say who receives parts and where they go on arrival.
What proof should you ask for?
Ask for photos and work notes that let you check the result without calling the engineer. State them in the ticket, because evidence that is not requested is often not captured.
- A photo of the labels before the work starts.
- Photos of the rack front and rear after the work.
- Photos of indicator lights where a light is the proof of success.
- Work notes in your own ticket system, with times and parts used.
- The name of the person who signs off and how they will confirm.
Why do remote hands tickets fail?
Tickets fail for a short list of repeat reasons, and almost all can be fixed at the writing stage.
- Several tasks are packed into one ticket, so steps and evidence blur together.
- Nicknames are used instead of the label text.
- The location stops at the room, with no cabinet or U position.
- No stop condition or rollback is given.
- Access, parts delivery or escort was not arranged.
- No evidence was requested, so nothing proves the work was done.
Key takeaways
- Include six things in every ticket: requester, timing, location, numbered steps, limits and evidence.
- Write one action per line, use label text exactly as printed, and state what the engineer should see.
- Name what must not be touched, when to stop and call, and how to roll back.
- Agree access and authorization before the day, and ask for photos and work notes in the ticket.