Why Ticket Notes Matter More Than the Fix

Thursday, 09:20, at Stonebridge Insurance. Priya picks up ticket 5118 from the underwriting team: "Claims portal is crawling again, same as last time, can you do whatever you did before?" She searches for "claims portal" and finds ticket 4402 from the spring. It was closed by Tomas, who is on a beach somewhere with his phone switched off. The resolution note on 4402 reads, in full, "Sorted." Above it sits one internal note: "Looking at this." Priya has the ticket number, the requester's name, the date it was closed and the exact time Tomas took to fix it. That was two hours and ten minutes. She has everything except what he did.

A ticket note is any text a technician writes on a ticket. That includes the internal notes to colleagues as the work goes along, the public replies the requester sees, and the resolution note at the end. Together they are the written record of what the desk saw, tried, learned and changed. They are the only part of the work that lasts. This article is part of our Writing Ticket Notes That Survive You series. This article is the argument for the whole series. The fix is gone the moment it is applied, and the note is what you have left.

This article covers why the fix evaporates and the note does not. Next come the three people who will read every note you write, and what each of them needs from it. Then we cover what an empty ticket costs the desk, in hours and in trust. We show one ticket written three ways, so you can see the difference on the page. A short war story follows, then the four-line working note to copy.

The Fix Evaporates and the Note Stays

A fix is an action, and an action leaves almost no trace of itself. Tomas restarted a service, changed a setting, or cleared a cache, and the portal sped up. Ten minutes later the server looked exactly as a server looks when nothing has been done to it. The underwriting team got their afternoon back and Tomas got a thank-you. The only evidence that anything happened is a status change from Open to Resolved and a one-word note. The fix was real. It just did not stay anywhere.

The ticket tool records that something happened, not what. Every reasonable help desk tool keeps a history of the ticket's own events: when it was opened, when it was assigned, when the status changed, when a reply went out. Some keep more than others. QuerySolv, for instance, keeps a complete event history on every ticket. So the who and the when of every handoff is never in doubt. No tool can record the why, or the things that were tried first and did not work. Those exist only in the technician's head, and heads are not a storage medium the desk controls.

This is why the note, not the fix, is the durable output of support work. The requester is helped once. The note helps every time the same thing happens again, and every time a colleague picks up a related ticket. It also helps every time someone asks, a year later, what was done to that server and why. A desk that fixes things and writes nothing down is a desk that solves each problem for the first time, forever. It is very busy and it learns nothing. I ran one for about a year before I noticed.

The Three Readers of Every Note

Every note you write has three readers, and none of them is the person writing it at the moment of writing. The first is you, in three weeks, when the same symptom comes back. You cannot remember which of the four things you tried was the one that worked. The second is a colleague at five o'clock, picking up the ticket because you have gone home, are on leave, or have been pulled onto something louder. The third is a stranger a year from now. That might be an auditor, a new technician, a manager answering a complaint, or whoever is trying to work out why a server is configured the way it is. The note that serves all three is the same note. It is just written with them in mind.

The picture below puts the three readers under one note. The note is four lines from ticket 4402 as Tomas might have written it on the morning. The lines cover what he saw, what he tried, what happened, and what he meant to do next. Under it, each reader gets a card with the question they bring to the ticket and what the four lines answer. The card also shows what they are left with when the note is a single word. The point of drawing it is that the same four lines satisfy three completely different people, which is more than can be said for most writing.

Reader One: You, in Three Weeks

You will not remember. This is not a character flaw; it is how memory works when it is asked to hold forty tickets a week. You remember that there was a portal thing, that it was annoying, and that you fixed it. You do not remember whether restarting the application pool worked on its own or only after you had also cleared the cache. You certainly do not remember the name of the scheduled job you suspected and never got round to checking. Three weeks later the symptom is back, and you are at step one again with a vague feeling of having been here before.

The cost to future you is the rediscovery. Everything you tried last time gets tried again, in roughly the same order, with roughly the same results, until you reach the step that worked and recognise it. On a two-hour fix, the rediscovery is most of the two hours. A four-line note turns it into five minutes. Read the lines, skip to the thing that worked, do it, and this time write down the scheduled job while you are there. Future you is the reader with the most to gain and the least excuse. You know exactly what they will need, because you are standing in it.

There is a smaller cost that compounds. When you cannot remember what you did, you cannot tell whether the problem is the same one or a new one that looks alike. "The portal is slow again" might be the same cause returning. That would mean your fix was a workaround and the real cause is still there. Or it might be a different cause with the same symptom. The note is what lets you tell the difference. Without it, every recurrence is a mystery. A desk full of mysteries never gets to the stage where it can fix anything for good. That stage belongs to finding the repeat tickets, and it runs on notes.

Reader Two: The Colleague at Five O'Clock

The second reader picks up your ticket when you are not there. They have two questions: where are we, and what is the next step. It is 17:00, the requester has phoned to ask what is happening, and the colleague opens the ticket to find out. If the last note says "Looking at this," they know nothing the requester did not already know. They cannot say what has been tried or what is planned. They cannot safely do anything, because they might be undoing something you did on purpose. So they say "I'll get Tomas to call you tomorrow," and the requester hears that the desk has lost a day.

Handoffs are where empty notes do their most visible damage. A ticket that moves between people, between shifts or between tiers carries only what is written on it. Everything else leaves with the person. The colleague who inherits a well-noted ticket can carry on from the last line. The colleague who inherits a bare one has to start again, or wait, or phone the original technician on their evening off. That last option is the one most often taken and most resented. The handover routine itself is covered in the shift handover. What that routine depends on is that every ticket already says where it stands, because a five-minute handover cannot reconstruct eight tickets from memory.

Write for this reader as if they are competent and in a hurry, because they are. They do not need your reasoning in full. They need the current state in one line, the last thing tried and its result, and the next step with a time. "Portal slow for underwriting; app pool restart helped for twenty minutes; next is to check the scheduled jobs on the database server at 11:45; requester knows to expect an update by 15:00." That is one sentence, and it turns a lost day into a continued one. The colleague at five o'clock is not asking for a report. They are asking not to be made to guess.

Reader Three: The Stranger a Year Later

The third reader was not there, does not know you, and may not know the system. They arrive with a question the ticket was never written to answer. Why is this server set the way it is? What was done to this user's account last spring? Has this error ever been seen before? Or did the desk handle this requester's complaint properly? They have a search box and whatever words you left in it. If the note says "Sorted," they learn that someone once thought so.

Auditors are the reader people imagine here, and they are real. The occasion might be a security review, a compliance check, a complaint that went formal, or an insurance claim after a data loss. In each case somebody asks the desk to show what was done and when, and the ticket is the evidence. A ticket with dated notes that say what changed, from what to what, is an answer. A ticket with a status history and no notes is a timeline with the events missing. I have sat in a review where the only record of a firewall change was a ticket that said "done as requested." The request had been a phone call. The review did not go well, and it did not go well for the right reasons.

The more common third reader is the new technician, who is nobody's auditor and simply wants to know how things work here. Six months of well-noted tickets are the best induction a desk can offer. They show what breaks, how it was fixed, who to ask, and what the servers are called. Six months of empty tickets show that the desk was busy. Writing so that this reader can find the ticket at all, by the words they would type into a search box, is the subject of notes for the stranger who finds this ticket next year. The point here is only that the stranger exists, and is reading.

What the Empty Ticket Costs

An empty ticket is one that was worked and resolved and says nothing useful about either. "Sorted," "Fixed," "Done," "User happy," "See previous," "As discussed." Each is true, and each tells the three readers the same thing, which is that they are on their own. The ticket was not left empty out of laziness, usually. It was left empty because the fix was finished, the next ticket was waiting, and writing felt like paperwork about something that was already over. The feeling is understandable. It is also exactly backwards, because the fix was the temporary part.

The first cost is rediscovery time, and it is the one you can count. Every time a symptom recurs and the earlier ticket is empty, the desk pays the investigation again. At Stonebridge, Priya spent an hour and fifty minutes on 5118 before she found what Tomas had found. That was a scheduled report that locked a database table every morning. Tomas had spent two hours and ten minutes finding the same thing. Four hours of skilled work went into discovering one fact twice, and the second discovery was entirely avoidable. Multiply by the number of recurring problems on your desk and the number of people who might pick them up. The total is larger than the headcount suggests, because empty tickets charge interest.

The second cost is the wrong fix repeated. Suppose nobody wrote down that restarting the application pool only helped for twenty minutes. The next technician restarts it, sees the portal speed up, writes "Fixed," and closes the ticket. Twenty minutes later it is slow again. The requester, who has now been told twice that it is fixed, stops believing the desk. Reopened tickets are the desk's most honest number, and a good share of them trace back to a fix that an earlier note would have ruled out. What a reopen is usually telling you is that somebody did not read, because there was nothing to read.

The third cost is trust, and the requester pays it. They raised the ticket, described the problem, answered the questions, and waited. The next time it happens they are asked the same questions again, because the answers were not written down. They are told the same fix will work, because nobody recorded that it did not. From where they sit, the desk has no memory. People stop raising tickets with a desk that has no memory and go and find the one person who remembers. That person becomes the hero, and the hero becomes the bottleneck. The desk has acquired a quiet failure from a problem that started with a one-word note.

One Ticket, Written Three Ways

Here is ticket 4402, the spring portal ticket at Stonebridge, written three ways. The requester's words were the same in each case: "The claims portal takes nearly a minute to open a case for the underwriting team, since about Monday. The claims handlers downstairs say it is fine for them." The work was the same in each case too. Tomas restarted the portal's application pool and saw the pages speed up and then slow again. He looked at the database server and found a scheduled report that locked a table from ten o'clock until it finished. He had the report moved to six in the morning. What differs is only what he wrote.

The first version is the one he actually wrote: one internal note at 09:50, "Looking at this," and one resolution note at 12:00, "Sorted." Priya read it in the autumn and learned that the ticket had existed. The second version is the one most desks write, a single summary at the end: "Restarted the app pool and moved a report job, portal OK now." It is better by a long way, and it is still a summary with the cause missing. Which report? Moved from when to when? Why did the restart matter at all? Priya would have known to look at report jobs, which would have saved her an hour. She would still have had to find the right one herself.

The third version is the four-line working note, written twice during the work and once at the end, as the work happened. It is below, exactly as it would sit in the ticket's internal notes.

09:50  WHAT I SAW: case pages take 45-60 s to open for underwriting
       users on the second floor; claims handlers on the ground floor
       open the same cases in 2-3 s. Started around Monday per Jonas.
       WHAT I TRIED: restarted the portal application pool on
       CLAIMS-WEB-01 at 09:48.
       WHAT HAPPENED: pages back to 2-3 s for underwriting.
       WHAT NEXT: watch for 30 min; if it comes back, look at the
       database server, not the web server.

10:25  WHAT I SAW: slow again from about 10:15, same users only.
       WHAT I TRIED: checked scheduled jobs on CLAIMS-DB-01.
       WHAT HAPPENED: "Underwriting exposure report" runs 10:00-11:30
       daily and holds a lock on the CaseHeader table while it runs;
       underwriting queries wait on it. Claims handlers use a
       different table and are not affected. Job was added on Monday
       by the reporting team, per the change log.
       WHAT NEXT: ask reporting team to move the job to 06:00;
       confirm with Jonas in underwriting tomorrow at 11:00.

12:00  RESOLVED: report job moved to 06:00 by the reporting team.
       Cause: new daily report locking CaseHeader during working
       hours. Underwriting confirmed pages open in 2-3 s at 11:05.
       If this recurs, check for new jobs on CLAIMS-DB-01 first.

Read the three readers against the three versions and the difference stops being a matter of taste. The table does it reader by reader.

The four-line version took Tomas perhaps four minutes to write across the morning, in three sittings of about a minute each. It would have saved Priya an hour and a half, saved Jonas a repeat of the same questions, and handed the auditor a complete answer. Four minutes against four hours is the most lopsided trade on the desk. The only reason it is not made every time is that the person paying the four minutes is never the person who collects.

A Short War Story: The Label Printer at Tollgate Foods

Tollgate Foods ran a packing line that stopped whenever the label printer at station four stopped. One Thursday it stopped for forty minutes while Dev, the desk's senior technician, worked out the cause. The printer had picked up a new network address overnight and the labelling software was still pointing at the old one. He fixed it in two minutes once he knew, wrote "Printer fixed, line running" in the ticket, and went to lunch. Seven weeks later the printer did it again on a Saturday shift, when Dev was off and Amara, who had joined in the spring, was on call. Amara found Dev's ticket and learned that the printer had once been fixed. She spent two hours and twenty minutes swapping cables, reinstalling the driver and restarting the line's controller. Then she tried the address and watched the labels start. The line was down for most of the shift. The overtime for the packing crew came to a day's wages for eleven people. The production manager asked, reasonably, why the desk had not known about a problem it had already fixed. Dev's two-minute fix had cost forty minutes the first time and two hours the second. The only thing that would have made the second time cost two minutes was one more sentence.

The Four-Line Working Note

The template below is the four-line note from the worked example, stripped back to its skeleton. Use one block each time you sit down with the ticket: at first touch, after each attempt that changes something, and when you stop for the day. Fill in whichever lines have changed since the last block; if nothing was tried, say what you saw and what is next. The time at the top is the time you did the work, not the time you wrote about it. The fourth line is the one that saves the colleague at five o'clock. Keep each line to a sentence or two. Writing these as the work happens rather than afterwards is its own discipline, covered in the working note habit. The resolution note that closes the ticket has its own four lines in resolution notes worth reading later. This is the note for everything in between.

THE FOUR-LINE WORKING NOTE
Time: ____:____   Ticket: ________   Written by: ____________

WHAT I SAW
  The symptom in plain words, with who and where it affects,
  and since when. Exact error text in quotes if there is any.
  ___________________________________________________________
  ___________________________________________________________

WHAT I TRIED
  The action taken, on which machine, account or service,
  at what time. One action per line.
  ___________________________________________________________
  ___________________________________________________________

WHAT HAPPENED
  The result of the action, in plain words: fixed, no change,
  partly better, worse. How you know.
  ___________________________________________________________

WHAT NEXT
  The next step, who does it, and by when. If waiting on
  someone, who and for what. If handing over, to whom.
  ___________________________________________________________

Rules
  One block per sitting. Write it before you move to the next
  ticket. Never write "tried a few things"; name them.
  Never write "fixed" without saying what changed.

Priya, after 5118, went back to 4402 and added the cause to it as a one-line note. That way, the next search for "claims portal" would find the answer twice. Then she wrote the four lines on 5118 as she worked, which took her about three minutes across the morning. Tomas came back from leave to find a note on his old ticket and a slightly pointed message in the team chat. He took it well, mostly. The portal has not been slow since, and if it ever is, the next technician will know within a minute which server to look at.

Frequently Asked Questions