The Working Note: Write While You Work, Not After

Monday, 14:10, at Meridian Parts. Lena has had ticket 7731 open since half past ten. The drawing office cannot get licences for the design software. Eleven engineers are drawing on paper, which they are enjoying less than it sounds. She has been interrupted four times. Marcus, the desk lead, leans over. "Where are you with the licence thing? Hamid is asking." Lena opens her mouth and discovers that she does not know. "I restarted the licence service. Then I checked the count, I think, and changed the port. Or was that on the old server?" She has done five things in three and a half hours and could swear to two of them. The ticket says "Investigating."

A working note is a note written on the ticket at the moment the work happens. It is a line or a few lines, stamped with the time, saying what you just saw, what you just did, and what came of it. It is the opposite of the summary written from memory at the end, and the difference is the subject of this article. This article is part of our Writing Ticket Notes That Survive You series, which makes the case that the note matters more than the fix. This one is about when to write it, which turns out to decide what it says.

It covers why memory is a bad note-taker, then timestamps and why "then" is not a time. Next come the five-minute rule and the note you write before you click, then internal notes versus public replies and what belongs in each. Then come the note you write before you walk away from a ticket, good and bad entries side by side, and how to make the habit stick. A short war story and the working-note skeleton to copy finish the article, in that order.

Why Memory Is a Bad Note-Taker

Memory keeps the shape of the afternoon and drops the order, the times and the failures. Ask anyone to describe a fix they finished an hour ago and you get the ending: what worked, told as if it were the first thing tried. The three dead ends before it are gone. The dead ends are the most valuable part for the next person, because they are the three things that do not need trying again. A summary written at 17:30 describes the ticket you wish you had worked. The real one had more steps and less dignity.

Order is the first thing to go, and order is evidence. If you changed two settings and the problem stopped, which one fixed it? If you cannot say which came first, you cannot say, and the next technician will change both again on faith. Interruptions make this worse. Lena did not forget her five actions because she is careless. She forgot them because a phone call and two walk-ups were inserted between them, and memory files by topic rather than by time. By 14:10 the licence ticket was four separate fragments with no thread.

Detail goes next. Take the exact wording of the error, the exact time the service was restarted, the exact licence count, and the exact file that would not open. Each is recoverable at the moment and unrecoverable an hour later. "Some kind of licence error" is what memory offers, and it is useless for search and useless for diagnosis. The working note captures the detail at the only moment it is cheap, which is while it is on the screen in front of you.

Reconstructing from memory also costs more than writing as you go, which surprises people who think of notes as overhead. Thirty seconds after each action adds up to perhaps four minutes across a long ticket. Sitting down at the end to reconstruct the same afternoon takes ten minutes and produces a worse note. It is skipped whenever the day gets busy, which is most days. Writing as you go is not the thorough option. It is the lazy one done properly.

Timestamps: Write the Time, Not "Then"

A timestamp is the time an action happened, written into the note beside it. Most tools stamp each note automatically with the moment it was saved, and that is useful. But it is the time you wrote, not the time you acted. If a note covers three actions, the saved time belongs to the last of them at best. Put the time of each action in the line: "11:20 restarted the licence service; 11:35 checked the licence count." A note that says "then I restarted it" has told the reader the order of two events and nothing else. "Then" is not a time.

Times matter because they connect your ticket to everything else that happened in the building. The file server slowed at 11:42 and your restart was at 11:40. That is either a coincidence or your doing, and the time is the only way to tell. The requester says it broke "about eleven." The change log says the network team pushed a change at 10:55. The log on the licence server shows a restart at 11:20 that was you. Diagnosis is mostly putting events in order, and the working note with times is the desk's own event log. Without times it is a list of things that happened at some point, in some order, to someone.

Times also tell the next reader how long things take, which is a kindness. If the note shows the count check took two minutes and the full service reinstall took forty, the colleague at five o'clock can tell the requester something honest about the next step. Where your tool records the time of every note and event anyway, the times inside your lines are not duplication. The tool's stamp says when you spoke, and your stamp says when you acted. Write both and let the reader have the difference.

The Five-Minute Rule

The five-minute rule is this: if you have been working a ticket for five minutes and have not written a line on it, stop and write one. Five minutes is long enough to have done something and short enough that you still remember exactly what. The line can be short. "11:15 picked up; drawing office reports 'no licence available' on every machine since about 09:00; checking the licence service on LIC-01 first." Twenty seconds, and the ticket now says something a colleague could act on.

The sharper form of the rule is to write before you click. Any action that changes something, a restart, a setting, a permission, a password, a rule, gets a line before it happens. Fill in the result straight after the action. For example: "11:20 about to restart the licence service on LIC-01; drawing office warned." Then: "11:21 restarted; service came up clean; drawing office still gets the error." Writing before you click does three things. It records what you changed even if the change goes wrong and takes your session with it. It leaves the system's state on record if you are interrupted mid-way, so nobody has to guess whether the change was finished. And it makes you say what you are about to do, which is where a surprising number of bad ideas get caught. I have typed "about to delete" and then not.

The interrupt test is the way to check whether the rule is working. At any moment, if you were pulled off the ticket for the rest of the day, could a colleague read it and carry on without phoning you? If the answer is no, you are behind on your notes, however much progress you have made in your head. The ticket is only as far along as its last line. Everything past that is a rumour.

Internal Note Versus Public Reply

An internal note is text on the ticket that only the desk can see. A public reply is a message sent to the requester and kept on the ticket as part of the conversation. Most tools draw this line, and the rest of this section assumes yours does. QuerySolv, for one, keeps public replies and internal notes apart on the same ticket. So the conversation with the requester and the desk's own working notes sit in one history without ever being confused for each other. If your tool has a single text box that the requester always sees, you write the working lines in plain language the requester could read. You lose nothing, because nothing in a good working note needs hiding.

The internal note is where the work lives. Hostnames, settings, counts, things tried, results, what you suspect and why, who you asked, what they said, and what is next. It is written for the three readers who know the systems: you later, a colleague, and the stranger. It is technical, terse and complete. It is not, however, private, in the sense of being safe from every eye but the desk's. Tickets get exported, forwarded, audited and requested, and the internal note comes with them. Write it as if the requester might one day read it, which costs nothing when the note is about machines and facts. The things that should never be in it, whoever can see it, have their own article in what never to write in a ticket.

The public reply is a translation of the latest working note into the requester's language, not a different story. The requester needs three things: where the ticket is, what they should do or not do, and when they will next hear from you. "We have found that the licence server is holding licences for machines that were switched off over the weekend. We are releasing them now and expect the drawing office to be able to open drawings within the hour. I will confirm by 15:30." No hostnames unless the requester uses them. No suspicions presented as findings, because "it might be the server" arrives at the other end as "the server is broken." The timing and shape of these updates belong to status updates that prevent the angry follow-up. The rule here is only that the public reply says what the internal note knows, in fewer and plainer words.

The Note Before You Walk Away

The parking note is the working note you write whenever you stop working a ticket for longer than it takes to get a coffee. That means lunch, the end of the day, a wait on someone else, or an hour on a louder ticket. It is the most important note on the ticket, because it is the one the colleague at five o'clock reads first. It carries four things. The state right now, including anything half-done. What you are waiting on, from whom, since when, and when you will chase. The next step, who does it, and by when. And what the requester was last told, so nobody promises them something different.

Half-done is the line that earns its place. Systems pass through states nobody would guess from the outside. A name-server record may have changed but still be cached on half the building. A permission may be granted on one of two folders, or a licence file reissued but not yet installed. A password may have been reset but not yet used by the requester. If you walk away with the system in a state like that and the note does not say so, the colleague who picks it up will either undo your work or build on top of it blind. "DNS record for the licence server changed at 15:50; machines that have not rebooted still point at the old address until tomorrow" is one sentence and it prevents a day of confusion.

The parking note and the ticket's status should agree. If the note says you are waiting on the supplier, the status should be the one your desk uses for waiting on a supplier. That puts the ticket in the view where waiting tickets are chased and not in the one where active tickets are worked. Which waiting status means what is the subject of pending user versus pending vendor versus on hold. The point for notes is that a ticket whose status says one thing and whose last note says another will be believed by nobody, and rightly.

Write the parking note even when you are sure you will be back in an hour. You will not always be back in an hour. The louder ticket becomes the afternoon, the afternoon becomes the next morning, and the licence ticket sits with "Investigating" as its last word while eleven engineers draw on paper. Marcus did not need to know what Lena had done so he could do it himself. He needed to know so he could tell Hamid something true.

Good Entries and Bad Entries

The table below takes the bad entries that appear on most desks and shows the working-note version beside each. They all come from ticket 7731, so that reading down the right-hand column tells the story of the licence server as it should have been told. Notice that every good entry has a time, names a thing, and says what happened. Notice also that none of them is long.

Every entry in the right-hand column took under a minute to write at the time and would have taken Lena ten minutes to reconstruct at 17:30, badly. Marcus's question at 14:10 would have had a thirty-second answer: "Twelve stale licences found, releasing them now, Hamid will know within the hour." That is the whole return on the habit. The note is written once and read many times, and every reading is cheaper than the one that was never written.

Making the Habit Stick

Habits attach to triggers, so give the working note three. Write when you pick up a ticket, write before you click anything that changes a system, and write before you put the ticket down. Picking up, changing, parking. If those three moments reliably produce a line each, the five-minute rule mostly takes care of itself. The gaps between them are rarely longer than five minutes of actual work. The hard one is the middle trigger, because the click is right there and the note box is a tab away. Keep the note box open beside the thing you are changing, and type the line into it before your hand moves to the other window.

The team can help in two cheap ways. The first is the "any update?" test, asked out loud: if this requester phoned right now and I picked up, could I answer from the ticket alone? A lead who asks that question of a random open ticket once a day changes a desk's notes within a month, without a policy, a meeting, or a slide. The second is a weekly read of five tickets by a peer, which is the review in a one-page ticket note standard for the whole team. Notes that somebody is going to read are written differently from notes that nobody is. That is not a criticism of anyone. It is just how writing works.

Some technicians keep a scratch text file or a paper notebook beside them and write there first. That is fine as long as the lines are pasted into the ticket within the hour. The ticket is the record and the file is not. The danger is the file that never makes it: the notebook that goes home in a bag, the text file on a desktop that gets wiped when the laptop is replaced. I kept a very good notebook for several years. It is in a box in a loft, and every ticket it describes says "Fixed."

Expect the habit to take about a month to become automatic and to slip whenever the desk gets loud. Loud days are exactly when the notes matter most, because loud days are when tickets get parked and handed over. So treat a slip as the signal to go back to the three triggers rather than as evidence that the habit does not work. A good working note on a quiet day is a courtesy. On a loud one it is the only thing holding the ticket together.

A Short War Story: The Half-Remembered Fix at Harbourview Clinic

Noor spent a Tuesday at Harbourview Clinic on a ticket about the reception scanner, whose scans had stopped arriving in the patient-records folder. Between interruptions she changed four things. She changed the scanner's destination path, the password on the service account the scanner used, and a permission on the records folder. The fourth was a rule on the records server's firewall that she opened at 11:00 "to test" and meant to remove. Scanning worked by 16:30, and at 17:20 she wrote the ticket's only note from memory: "Fixed scan-to-folder; updated the destination path and folder permissions." The firewall rule was not in it, because by 17:20 she had forgotten making it. Nine days later the nightly backup of the records server began failing with a connection error. Two technicians spent a day and a half comparing the server against its twin. Then one of them found an undescribed firewall rule dated nine days earlier and traced the date to Noor's ticket. The clinic went eight nights without a backup of patient records, which the practice manager was obliged to report. The desk spent three technician-days on what a one-line note at 11:00 would have prevented. The note you write from memory is missing the thing you forgot, and the thing you forgot is the thing that breaks.

The Working-Note Skeleton

The skeleton below is the working note as a set of entry types, each with a time and the lines it should carry. You will not use every type on every ticket; a simple one has a pick-up, a change and a close. Copy the entry type you need, fill in the time, and write the lines in plain words, naming machines and accounts exactly as the systems show them. Keep each entry to a few lines. The parking entry is the one to practise until it is automatic, because it is the one that is read when you are not there to be asked.

WORKING NOTES — TICKET ________
One entry per sitting. Time first. Write the CHANGE line before you click.

__:__  PICKED UP
       Symptom as I understand it: ______________________________
       Who, where, since when: __________________________________
       Exact error text, if any: "_______________________________"
       First thing I will check: ________________________________

__:__  CHECKED
       Looked at: _______________________________________________
       Found: ___________________________________________________

__:__  CHANGE
       About to change: ______________ on ______________
       Why: _____________________________________________________
       Result, filled in straight after: ________________________

__:__  TOLD REQUESTER
       Public reply sent saying: _________________________________
       Next update promised for: __:__

__:__  PARKED
       State right now, including anything half-done: ___________
       ___________________________________________________________
       Waiting on: __________ for __________ since __:__
       Chase on: __________
       Next step: __________ by __________ owner: __________
       Status set to: __________

__:__  HANDED TO __________
       They need to know first: __________________________________
       Requester expects to hear by: __:__

__:__  RESOLVED
       Hand over to the resolution note: symptom, cause, fix,
       how it was verified.

Lena rewrote 7731 at 14:30 from the fragments she could recover. It took her twenty minutes and produced a note with two gaps in it that she could not fill. The next ticket she picked up got a line at pick-up, a line before each change, and a parking note before she went home. The whole set took her under four minutes. When Marcus leaned over the following week to ask where she was with the file-share thing, she pointed at the screen and went back to typing. He read it, told the requester, and went away. That is what the habit buys: not better notes, exactly, but a desk where the question "where are we with this?" has stopped needing a person to answer it.

Frequently Asked Questions