How to write the perfect remote hands ticket: the format providers appreciate

November 11, 2026 5 min read By Noxtel

When the remote hands technician opens your ticket while you are on call, they need to know exactly which equipment failed and which measurements you took. If at that moment they cannot know which equipment failed, what you measured and what you expect, they have nowhere to start: they diagnose from scratch and you pay for that waiting time without knowing it.

A well written ticket is not a long text. It is five fields that answer the five questions the technician already has prepared. This is the exact format, with one example of how it looks bad and another of how it looks good.

Why “the server is slow” is not a ticket

“The server is slow” is not a symptom, it is a conclusion. The technician does not know which of your servers it is, nor which room it is in, nor what slow means for your operation. Every missing data point is a question, and every question is a shift of waiting time.

The most expensive cost is not the waiting, it is the discussion. When nobody wrote down what was expected as a result, two people can review the work and conclude that everything was done. What follows is an exchange of emails to agree on whether something was done well.

The 5 fields your ticket must have

Equipment identified. Exact location, model and serial number. If the technician has to infer the model from the cabinet description, they lose time on the very first step.

Observable symptom. What is happening, since when, and how often. Write measurements and not adjectives: “480 ms ping against 8 ms in normal operation” works; “it is slow” does not.

What has already been checked. What you tested and with what result. This field prevents the technician from repeating the path you already walked, which is the most common cause of feeling that nothing is moving.

Requested action. What you expect them to do, and also what you do not expect. Bounding the scope prevents a review from turning into maintenance that nobody authorized.

Closure criterion. How you know it was resolved. Without this line, the ticket gets closed for lack of a response instead of because of a solution.

The badly written ticket and why it does not move

This is the most frequent case. It has all the information, but none of it is actionable:

Title: Problem with servers Description: The server is slow, it is causing problems for the sales team. Please check. It has been going on for a few days. Bundle something.

The equipment is missing, the measurement is missing, the scope is missing and the closure criterion is missing. The technician cannot start without asking, and the first answer always comes with doubts: that turns a twenty minute review into several hours of back and forth.

The title counts too. “Problem with servers” does not say which equipment or what is failing: it forces you to open the ticket to understand it. “Rackserv-SRV-07: 480 ms latency” already summarizes equipment and symptom, and the technician can decide their entry path.

The well written ticket, with the 5 fields

The same failure, described in a way that can be worked on immediately:

Title: Rackserv-SRV-07: intermittent network latency at 480 ms Field 1, equipment: Rackserv-SRV-07, rack A-14, backup node. Supermicro SYS-1029U model, serial S5A7K3. Monitor 10.20.4.87. Field 2, symptom: Since Monday, October 20, the latency between this node and the main switch rises to 480 ms intermittently, around 12 times per hour. It occurs mostly between 14:00 and 16:00. The application service stays up. Field 3, already checked: We restarted the network service of the node on Tuesday 21 at 09:30 and the latency dropped to 9 ms for two hours, then rose again. We found no power loss in the UPS log. Field 4, requested action: Review the uplink port and the cabling of rack A-14. Do not restart the node or change the switch configuration: we are measuring behavior under load. Field 5, closure criterion: We close when the ping to the main switch stays below 20 ms for six hours, with a photo before and a photo after, and with the time at which the change was made.

Evidence cuts both ways. A photo of the front of the equipment taken before the disassembly and another one upon finishing would prove within six months that the work was done, when nobody remembers who did it or what was changed.

Common mistakes that send the ticket back

Attaching the evidence at the end. The photo of the alert, the photo of the front of the equipment and the monitor screenshot go in marked fields, not pasted at the end without context.

Confusing cause with symptom. “It lost network” is a diagnosis, not an observation. Write down what you measured and let the technician determine the cause.

Asking for everything at once. “Check why it is slow and change it while you are at it” mixes diagnosis and change. Separate the investigation from the authorized work in one ticket.

Closing out of exhaustion. Without a written closure criterion, the ticket is marked resolved because nobody has time to follow up.

The template you can copy tomorrow

If you want the format on a single line per field, here it is. Replace the brackets and you will leave no room for wrong interpretations on your provider:

Equipment: [name or serial, rack and room, model] Symptom: [what is happening, since when, how often, with which measurement] Checked: [what you tested and what happened] Requesting: [what is expected] · [what is not authorized] Closure: [measurable condition] + [evidence before and after]

The difference between the two tickets is not wording, it is time: one starts with a round of questions, the other with the technician walking into the room. Write it as if it were going to be read by someone who does not know your operation.

Before sending it, read it back as if it were someone else’s and ask yourself whether the technician would know what to do without writing to you. That is the difference between an intervention that starts in ten minutes and one that spends a shift on questions.