A One-Page Ticket Note Standard for the Whole Team

Monday, 08:50, at Redbrook Engineering. It is Kai's first day on a desk of six. Yusuf, who runs it, gives the usual induction: "Have a read through some closed tickets to see how we do things." Kai reads thirty. Ade writes essays, with a paragraph of context before every action. Bron writes "done." Cal writes timestamped lines that are a pleasure to read. Dagny writes to the requester inside the internal note, and Elin writes things in the public reply that should have stayed internal. Yusuf's own notes are excellent and rare. By 10:30 Kai has concluded, reasonably, that there is no way "we do things." Kai has started writing like Bron, because Bron sits nearest and seems relaxed.

A note standard is a short written agreement on when ticket notes are written and what each one holds. It also covers how long a note is, what tone it takes, and how the team checks that it is happening. It is one page because a one-page standard is read, pinned and remembered. An eleven-page one is read by its author and, eventually, by an auditor. This article is part of our Writing Ticket Notes That Survive You series. It is the last article in the series for a reason. The other five are habits of individuals, and this is how they become the habit of a team.

This article covers why a standard and why one page, then the five moments when a note is written. Next come what each kind of note holds, length and tone, and the resolution note. Then come the review that keeps the standard alive and an example ticket written badly and then to the standard. We cover training a new technician on it in an afternoon, then rolling it out to a team that already has six styles. A short war story follows, then the one-page standard itself, to copy.

Why a Standard, and Why One Page

The stranger who reads your desk's tickets next year reads notes from everyone on it, and needs them to look alike. Six styles mean six things to learn before a search result can be understood. A new technician does not learn six; they learn the nearest one. A standard is how the desk decides which style the nearest one will be. It also settles arguments before they happen. When a note is late, what a note is missing, and what should never have been in one are all answered by pointing at the page rather than at the person.

One page is a hard limit, not a target. A standard the team can read in five minutes is one they will read. The moment it needs a contents page it has become a policy. Policies are read at induction and at disciplinary hearings and at no point in between. Everything on the page should be something a technician can check against a real ticket in a glance. Reasons, examples and arguments live elsewhere, in this series, in the team's example tickets, in the induction afternoon. The page says what. The rest says why. Standards grow the way category lists do, by addition without removal. So the rule for changing it is one line in, one line out.

The standard is tool-neutral by design, and it should outlive the tool. It says "internal note" and "public reply" and "the ticket's history" without naming buttons. That is because the desk will change tools before it changes its mind about what a good note is. A standard full of menu paths dies on migration day. Where the tool matters, which is rarely, the standard says "wherever your tool puts internal notes" and leaves the rest to the training afternoon.

When to Write: The Five Moments

The standard names five moments at which a note is written. A ticket that passes through a moment without a note is late, whatever the note eventually says. The first is pick-up. The moment a technician takes the ticket, a line says what they understand the problem to be and what they will check first. The second is after each change or finding: a line before anything is changed and the result straight after, or a line for each thing learned. The third is before walking away: lunch, the end of the day, a wait on someone else, an hour on another ticket. The fourth is on handoff: whenever the ticket moves to another person, department or tier. The fifth is at resolution.

Five moments is the whole of the "when," and it is enough. A simple ticket passes through three of them, pick-up, a change and resolution, and carries three notes. A hard ticket passes through the middle moments many times and carries many notes, each short. The discipline of writing at the moment rather than afterwards, and the reasons memory makes a poor substitute, are in the working note habit. The standard does not repeat the reasons. It says the five moments, and the review checks them.

What Each Note Holds

Each moment has a shape, and the standard gives the shape as a short list of lines. That way, a technician can glance at the page and know whether the note in front of them is complete. The pick-up note holds the symptom as understood, who and where it affects, since when, the exact error text if there is one, and the first thing to be checked. The change note holds what is about to change, where, why, and then the result. The parking note holds the state right now including anything half-done, and what is being waited on and since when. It also holds the next step with an owner and a time, and what the requester was last told. The handoff note holds what the receiver needs to know first and what the requester expects. The resolution note holds four lines, covered below.

Two things attach to these notes when the ticket is a fault rather than a request. The first is the repro, the numbered steps that make the problem happen again. It belongs on the pick-up note or soon after it and is described in writing reproducible steps. The second is the set of words that make the ticket findable later: the error text verbatim, the device and application by their real names, the requester's own phrase, and links to related tickets. The article notes for the stranger explains these words, which the standard reduces to three lines. The table is what the standard carries for each note type, with the length that is normal for each.

Length and Tone

Length is set by the reader's questions, not by a word count. A note is long enough when the colleague at five o'clock can continue from it without a phone call. It is short enough when they can read it in the time the requester is saying hello. In practice that is two to six lines per note and four lines for a resolution. The standard says so, because a number is easier to check against than a principle. Ade's essays fail the standard on length, and it is worth being clear about why. It is not because they are wrong. It is because a paragraph of context before each action means the next reader cannot find the action. Bron's "done" fails for the opposite reason, and the reason is the same: the reader's questions are not answered.

Tone is plain and factual, written in short sentences, in the past tense for what was done and the present for what is true now. Machines, accounts and files are named exactly as the systems name them. Suspicions are labelled "suspect" or "not confirmed," things ruled out are labelled "ruled out," and findings are labelled "confirmed by." There are no adjectives about people, no verdicts about who is at fault, no jokes and no secrets, for the reasons set out in what never to write in a ticket. The standard carries that list as seven short lines under a single heading. The test the standard gives for tone is one question: could this note be read aloud to the requester, their manager and an auditor at once without anyone in the room being embarrassed? If yes, the tone is right. The desk's requester-facing voice in public replies is a separate subject with its own guide, and the standard leaves it alone.

The Resolution Note

The resolution note is the one the stranger reads first, because it is the one the search result shows. The standard gives it four lines: what the requester saw, what caused it, what was changed and from what to what, and how the fix was verified and by whom. "Cause not found" is an allowed second line and must be written as exactly that, with what was ruled out beside it. That is because a ticket that says "restarted it, working now" has hidden an unknown cause behind a tidy ending. The resolution note has its own article in resolution notes worth reading later, with examples. The standard carries only the four lines and the rule about causes, and the review checks them.

The resolution note is also where the standard most often slips, because it is written at the moment the technician most wants to be somewhere else. The ticket is fixed, the requester is happy, and the next ticket is waiting, and "Sorted" is right there. The standard's answer is not exhortation but the review, which reads resolution notes before any other kind, because they are the ones that are searched for.

The Review That Keeps It Alive

A standard nobody checks is a poster. The review is what makes it a standard, and it is deliberately small. Once a week, each technician reads five closed tickets belonging to a peer against the page and scores each on five questions. This takes about ten minutes and is done in pairs so that the score is a conversation rather than a mark. Once a month, the lead reads the scores, not the tickets, and picks the one question the desk is failing most to talk about at the team meeting. Once a quarter, the team rereads the standard itself and changes at most one line. That is the whole apparatus. It costs each person ten minutes a week and the lead an hour a month. It is the difference between a desk that has a standard and a desk that once wrote one.

Scores are for finding patterns, not for finding people. A desk where every pair scores low on the fourth question has a findability problem, which is fixed by a reminder and an example, not by a conversation with anyone in particular. A single technician who scores low on everything has a time problem, usually, and the conversation is about the time. The review is cheaper than it sounds because the ticket's own history already shows when each note was written against when each status changed. So the first question is answered by a glance at the timeline rather than by reading. QuerySolv keeps that event history complete on every ticket, and most tools keep enough of it to do the same. The remaining four questions are answered by reading the notes, which is the point. Notes that are going to be read get written differently.

An Example That Meets the Standard, and One That Does Not

Here is ticket 8814 from Redbrook twice, once as Bron wrote it and once as the standard would have had it. The ticket was about the drawing office's plotter, a wide printer for engineering drawings. It was printing every drawing with a faint grey band across the middle. The ticket took a day and a half and two people. Read down the left column to see what the stranger gets. Read down the right to see what the same work looks like when it is written at the five moments.

The right-hand column took perhaps six minutes to write across a day and a half. A stranger searching for "band," "smudge," "PLT-DO-01" or "roller" finds it. The left-hand column took perhaps twenty seconds and is found by searching for the ticket number, which the stranger does not have. Both describe the same work by the same two people. Only one of them is work the desk still owns.

Training a New Technician in an Afternoon

The standard is one page, so the knowledge takes an afternoon. The habit takes a month, and the review builds it. The afternoon is below as a schedule, and it has a shape: read, rewrite, compare, watch, do, and check. The rewriting step is the one that teaches. Rewriting three real bad tickets from the archive forces the new technician to ask the five questions of someone else's work before they are asked of their own. And the archive always has material. Anonymise the three tickets first, which is itself a lesson in what should never have been in them.

By five o'clock the new technician has read the standard, applied it to six tickets, watched it applied to several more, and been reviewed against it once. That is more exposure to the desk's way of writing than most technicians get in a year. It happens before they have had time to learn the nearest style. Kai, at Redbrook, learned Bron's style in two hours on a Monday morning because nobody had decided what else to teach. The afternoon is what deciding looks like.

Rolling It Out to a Team That Already Has Six Styles

Do not rewrite history. The archive stays as it is, and the standard applies to notes written from a Monday that the team agrees on. Trying to fix two years of "done" is a project nobody finishes and a punishment nobody deserves. The stranger will cope with an archive that improves from a visible date. An old ticket may matter because it is found in a search and its cause is now known. In that case, the one-line "Cause:" note goes on it then, as part of the new standard rather than as a dig through the old one.

Agree the standard in one meeting of thirty minutes, with the page already drafted. That is because a standard written by committee from a blank sheet is the eleven-page policy in the making. Everyone's style loses something and everyone's gains something. Ade loses the paragraphs of context and gains a reader. Bron loses "done" and gains four lines. Dagny moves her messages to the requester into the public reply where they belong. Elin moves her technical detail into the internal note. Yusuf, whose notes were already good, gains a team whose notes look like his, which is the only way his own will ever be read in context. The meeting is not for debating the five moments. It is for deciding the start date and who pairs with whom for the first review.

Expect three objections and have the answers ready. "I don't have time" is answered with the trade: four minutes of notes across a long ticket against the hours the next person spends without them. The review will show which tickets took longer. "The requester can see it" is answered with the internal note, and with the observation that a note the requester could see is the right standard anyway. "My notes are fine" is answered by the stranger, who is the only judge, and by the review. In the review, a peer reads five of them and says whether they could have continued from the last line. The first review, two weeks after the start date, is a conversation and not a verdict. The lead's job in it is to find the question the whole desk is failing, not the person.

A Short War Story: The Nearest Style at Pennywell Garden Centres

Pennywell Garden Centres ran a desk of four with four styles of note. When Tamsin joined she sat beside Greg, who wrote "sorted" and had done for six years. So within a month Tamsin wrote "sorted" too. The desk had five technicians and two of them left nothing behind. Eight months later the company was bought by a larger chain. The buyer's IT auditors sampled two hundred of the desk's closed tickets to establish what had been done to the till systems and the stock database during the year. That is the kind of question a buyer asks. A hundred and forty of the two hundred had no usable note. Tamsin's and Greg's tickets, which between them covered most of the till work, were the worst of those. The desk spent three weeks reconstructing about sixty changes from memory, supplier case records and the servers' own logs. The integration plan slipped by a month while they did it. The buyer's team wrote in its report that the desk's records "did not support an assessment." That is the politest sentence an auditor has. The lead wrote a one-page standard the week the report arrived and trained the five of them on it in an afternoon. That was about eight months later than the afternoon it would have taken to train Tamsin. A new technician learns the nearest style, and a desk that has not chosen one has chosen the nearest.

The One-Page Standard

The standard below is the whole thing, as a page the desk can print, pin and point at. Change the hostnames and times in the examples to your own, add your desk's name at the top, and resist adding anything else until something has been removed. The headings match the sections of this article so that a technician who wants the reasons behind a line knows where to find them. Everything on the page is a thing a technician can check against a real ticket in a glance. Nothing on it depends on which tool the desk uses this year.

TICKET NOTE STANDARD — ONE PAGE
Desk: ______________________   In force from: ____________   Owner: ____________

PURPOSE
  The fix is temporary; the note is the record. Every note is written for
  three readers: you in three weeks, a colleague at five o'clock, and a
  stranger next year with a search box.

WHEN TO WRITE: THE FIVE MOMENTS
  1. Pick-up        the moment you take the ticket
  2. Change/finding before you change anything, result straight after;
                    or each time you learn something
  3. Parking        before you stop for lunch, the day, a wait, or another ticket
  4. Handoff        whenever the ticket moves to another person or team
  5. Resolution     at close
  Never go five minutes on a ticket without writing a line.

WHAT EACH NOTE HOLDS
  Pick-up:     symptom as understood; who, where, since when; exact error
               text in quotes; requester's own phrase; first thing to check
  Change:      time; about to change ____ on ____ because ____; result
  Finding:     time; looked at ____; found ____
  Parking:     state now, including anything half-done; waiting on ____ for
               ____ since ____, chase ____; next step, owner, time; what the
               requester was last told
  Handoff:     what the receiver needs first; what is ruled out; what the
               requester expects and when
  Resolution:  SYMPTOM / CAUSE or "Cause not found; ruled out ____" /
               FIX, from what to what / VERIFIED by whom, how, when
  For faults:  repro steps once known; "Related: ____" for linked tickets;
               "Cause: ____" once known, added to earlier linked tickets too

LENGTH
  Two to six lines per note. Four lines for a resolution.
  Long enough that a colleague can continue without phoning you;
  short enough to read while the requester says hello.

TONE
  Plain and factual. Short sentences. Machines, accounts and files named
  exactly as the systems show them. Times written as times.
  Label theories: "suspect", "not confirmed", "ruled out", "confirmed by".
  Test: could this be read aloud to the requester, their manager and an
  auditor together?

NEVER WRITE
  A password, key, code or security answer
  An opinion of the requester
  A guess in the grammar of a fact, including "fixed" for "stopped"
  Blame
  A joke about anyone
  Personal detail the ticket does not need
  Someone else's data in a screenshot

THE REVIEW
  Weekly:    each technician reads five of a peer's closed tickets against
             the five questions; score 0, 1 or 2 each; ten minutes, in pairs
  Monthly:   the lead reads the scores and raises the weakest question
  Quarterly: the team rereads this page; one line in, one line out

TRAINING
  New technicians: one afternoon, on day one, before they learn the
  nearest style. Read, rewrite three, compare, watch, do, check.

Yusuf wrote Redbrook's page on the Tuesday of Kai's first week, from a draft much like this one. The six of them agreed it in twenty-five minutes on the Wednesday. The only real argument was about whether "two to six lines" should be "two to eight." Ade lost that argument. Kai had the training afternoon on the Thursday, three days late, and rewrote three of Bron's tickets as the exercise. Bron took that in good part and then quietly rewrote three more of his own. The first review was a fortnight later. The desk scored lowest on findability, so the following week's reminder was about error text and the requester's phrase. Nothing was said to anyone in particular. Kai's notes, a year on, look like Cal's. So, mostly, do Bron's.

Frequently Asked Questions