Ticketing, and writing a ticket the next person can actually use

Why this matters

The ticket is the most-produced artefact in support work and the least thought about. Most are written for the system rather than for a reader: a one-line description, a resolution saying "fixed", and no way for anyone to learn anything from it.

That is a genuine cost. Tickets are how a fault gets escalated without losing information, how a pattern across ten machines becomes visible, and how the person picking up your work at 5pm knows what you already tried. The exam asks what a ticket must contain; the more useful question is what makes one usable, and the answer is mostly about writing for somebody who is not you.

The lesson

What a ticket must capture: contact, device, description, category, severity

A ticket has a fixed set of fields, and each exists to answer a specific question.

• Contact information. Who reported it and how to reach them — including when. A ticket with no working contact stalls.
• Device information. Asset tag or serial, model, and location. This is what links the ticket to the asset record, and it is what makes "this machine again" visible.
• Description of the problem. Covered in detail below.
• Category and subcategory. Not administrative decoration: categories are what produce the reports that justify fixing a recurring cause.
• Severity or priority. Usually a function of impact (how many people) and urgency (how time-critical). One person unable to print is not the same as a department unable to work, and the field is what lets the queue be worked in a sensible order.
• Progress notes, timestamped.
• Resolution.

Two fields that pay for themselves and are often missing: the time the fault occurred, which is what makes logs searchable, and whether it is reproducible, which decides whether the next person can work on it at all.

And one habit: fill in the description before starting work, not at the end. By the end you know the answer, and the description silently becomes a description of the answer rather than of the symptom — which makes it useless for finding the same fault next time.

Describing a problem in the user's words and in yours, and why both are needed

The best descriptions contain two things: what the user said, and what you observed.

The user's words matter because they contain information your paraphrase loses. "It makes a noise and then the screen goes black" is more useful than "display failure" — the noise is a clue and your category discarded it. Users also use words consistently: the same person saying "it crashed" means the same thing each time, and that is only visible if you quote them.

Your observation matters because it is verified. The exact error text, the code, what you saw happen, what you could reproduce.

The pattern that works:

Reported: "Word freezes when I print to the big printer upstairs, but not to my desk one. Started Monday." Observed: Word 2021 becomes unresponsive for 60-90 seconds when printing to \\PRINT01\HP-2ndFloor, then completes. Reproducible on this machine with any document. Not reproducible from a second machine. Event log shows no errors at the time.

That is four lines, and someone else could pick it up cold. It has the symptom, the scope test, the timing, and the negative result — and the negative result is what stops the next person repeating the first twenty minutes.

What to avoid: diagnosis in the description field. "Corrupt printer driver" in the description commits everyone who reads it to your first theory, and if you are wrong, the wrongness is now the official record.

Progress notes as a record of what has been eliminated, not what was attempted

Progress notes are where most tickets become useless, because they record activity rather than information.

The difference:

• Activity: "Restarted print spooler."
• Information: "Restarted print spooler — no change. Fault persists with the spooler freshly started, so it is not a stuck queue."

The second tells the next reader what has been eliminated. The first tells them what was done, which they cannot act on without repeating it to find out whether it helped.

What to write, each time you try something:

• What you changed or tested.
• What happened.
• What that rules in or out.
• Whether you undid it.

That last one matters enormously and is nearly always missing. A ticket listing six attempted fixes, with no indication of which are still in place, describes a machine in an unknown state.

Timestamps are free and make the sequence reconstructable. Negative results are the most valuable content in the whole ticket, and they are the ones people leave out because nothing happened — which is precisely the information the next person needs.

And when you hand over at the end of a shift, the notes are the handover. Writing "still investigating" is a way of telling the next technician to start again.

Resolution notes that answer the next occurrence rather than closing this one

The resolution field is read by two people: whoever gets this fault next, and whoever is looking for a pattern. Writing "fixed" serves neither.

What a resolution should contain:

• The cause, if you found it. Plainly if you did not: "cause not established; a restart cleared it" is honest and useful, and it is a data point if it happens three more times.
• What you did, specifically enough to repeat or reverse.
• How you verified, beyond the fault not recurring while you watched.
• Anything left in a changed state, and why.
• What would prevent it, if anything.

Why this is about the next occurrence rather than this one: by the time you write it, this one is over. The value is entirely in the future — the same user next month, a colleague with the same symptom, or the pattern that becomes visible when the fifth ticket says the same thing.

And the pattern point specifically. Four machines with the same fault over three months is a defect with a root cause worth fixing at source. Four tickets saying "fixed" is four unrelated annoyances, and nobody will ever connect them. The category field and a real resolution are what make the difference, and neither costs more than a minute.

The article worth writing from a good resolution is the knowledge base entry in the documentation lesson, and the best time to write it is immediately, while you still remember the detail.

Escalation: when, to whom, and what must travel with it

Escalation is not failure, and treating it as one is how tickets sit for three days.

When to escalate:

• You have reached the limit of your access or your authority.
• The severity exceeds what you should be handling alone — an outage, a security incident, anything with money or legal implications.
• You have spent the time the organisation expects on this and are not converging. Agreeing that limit in advance is worth doing.
• It needs a vendor, or a team that owns the system.
• Anything in the regulated-data or incident category, which the next lesson covers, and where the correct action is to stop rather than continue.

Who to escalate to: the defined route. Functional escalation moves it sideways to people with the right expertise; hierarchical escalation moves it upwards to someone with the authority to decide. Knowing which you need is half of doing it well — a technical dead end needs the first, a business decision needs the second.

What must travel with it:

• The description, unmodified, with the user's words intact.
• Everything tried and the result of each, especially the negative ones.
• The current state of the machine, including anything left changed.
• What you believe and how confident you are, clearly marked as belief rather than fact.
• Contact details and availability for the user.
• Anything preserved as evidence, and where it is.

An escalation that arrives as "can you look at this" wastes the recipient's first hour repeating yours. An escalation that arrives with the above is a colleague handing over work, which is what it should be.