The Moments That Matter in a Ticket's Life

Thursday, 16:10, at Ashgrove Housing. Fiona runs a desk of three for a housing association with two hundred staff. She is reading a satisfaction comment on ticket 7718 from Derek, a housing officer: "Nobody told me anything for three days and then it was closed." She opens the ticket expecting to find neglect. She finds the opposite. Ola claimed it within twenty minutes and wrote four internal notes over the three days. Ola passed it to Tariq when it turned out to be a permissions problem on the tenancy system. Tariq fixed it on the Wednesday and marked it resolved with the note "perms corrected on tenancy share". Inside the ticket, three days of work. Outside the ticket, from where Derek sat, an automatic acknowledgement on Monday and a closure notice on Wednesday, with nothing in between. Both views are accurate. Only one of them was Derek's.

A moment that matters is a point in a ticket's life where the requester forms an opinion of the desk. And there are five of them: the first reply, the waiting update, the handoff, the fix and the close. Between those points the requester is doing their own job and the ticket is out of their mind. At those points they look up, and whatever they see is what they remember. The previous article in this series, How Support Feels Versus How Fast It Closes, showed two tickets whose speed and experience pointed in opposite directions. This one takes the five moments apart, one at a time, and says what good looks like at each. It is part of our Experience Over Metrics series.

It covers why five moments and not the whole ticket. We cover each of the five in turn, with the question the requester is silently asking and what good looks like. Then comes the one moment that decides how the whole ticket felt. We cover mapping the moments for a fictional desk, with its findings, then a short war story and the moments map to copy, in that order.

Why Five Moments and Not the Whole Ticket

The requester does not experience the ticket; they experience the points at which the ticket touches them. A ticket open for three days is, from the desk's side, three days of notes, lookups, a reassignment and a fix. From the requester's side it is a handful of e-mails, or the absence of them. It is also some number of times they thought "I wonder what is happening with that" and either found out or did not. Their memory of the desk is assembled from those touches. If the touches were good, the three days were fine. If there were no touches, the three days were three days of nothing, however hard the desk worked. Derek's comment is exactly what that feels like from outside.

The five moments are the points where a touch is possible and expected. The first reply is when a person first speaks to the requester. The waiting update is anything said while the work is still going on. The handoff is the moment the ticket changes hands. The fix is when the problem is solved. The close is when the desk says it is over. Some tickets have no handoff and some are fixed in the first reply, so not every ticket has all five. But no ticket has a sixth; whatever else happens to a ticket, the requester only looks up at these. The picture below lays them out in a row. It shows the question the requester is silently asking at each one, what good looks like, and what it feels like when the moment is skipped.

Reading the picture from the bottom row is instructive. A ticket that skips the first reply leaves the requester feeling ignored; skipping the update leaves them forgotten. A bad handoff makes them start over; a silent fix leaves them unsure; a close that does not ask leaves them dismissed. None of those words appears on a dashboard. All of them appear in satisfaction comments, in more or less those terms, and they are the vocabulary of a desk that does good work in private.

The First Reply

The requester's question at the first reply is "did anyone see it?", and the answer has to come from a person. The automatic acknowledgement with a ticket number is not a first reply; it tells the requester a mailbox exists, which they knew. A first reply has a name on it. It says in a sentence what the named person understands the problem to be. It gives a time by which the requester will hear more. "Hi Derek, I have this. It sounds like you can see the tenancy share but cannot open the new folders in it. I am going to check the permissions this afternoon and will update you by 16:00." Three sentences. The requester now knows a human has it, knows the human understood, and knows when to stop wondering.

The time matters as much as the name. A first reply without a time is a promise with no end. The requester will start asking "any update?" at whatever interval their anxiety sets, which is usually a shorter interval than the desk's. A first reply with a time tells them when to expect the next touch, which means they can put the ticket down. The discipline of a human first touch inside a fixed window, and what it does to the rest of the ticket, is the subject of first-touch discipline in the intake series. Here the point is that the first reply is the requester's first evidence that the desk is more than software. It sets the tone for every moment after it.

What good looks like, then, is a named person, a one-sentence restatement of the problem, and a time. The reply is sent within the desk's first-response window and written by a person even if it starts from a template. What bad looks like is the acknowledgement alone, or a reply from "Support Team" with no name. Or it is a reply that asks three questions the requester already answered in the ticket. The last of these is the quiet killer. It tells the requester that nobody read what they wrote, and from then on they will assume that nobody reads anything.

The Waiting Update

The requester's question while waiting is "is anyone on it?", and the honest answer is a message that arrives before they ask. A waiting update is anything the desk says while the work is still going on. It covers what has been found, what is being tried, what is being waited for, and when the next word will come. Its job is not to report progress for the desk's benefit. Its job is to answer the question the requester is about to ask, before they have to ask it. That way, they never have to.

The update that works has three parts and is often three sentences long. What changed since the last message, even if the answer is "I have confirmed it is the permissions and not the share itself". What happens next, named concretely. And the next time, which replaces the old one. "I have checked, and it is a permissions problem on the two new folders rather than the share. I am passing it to Tariq, who looks after that system, this afternoon. I will make sure you hear from one of us by tomorrow at 12:00." When nothing has changed, say so, and say when something will. "Still waiting on the vendor, who have promised an answer by Thursday; I will write to you Thursday afternoon either way" is a real update. The words "either way" are the most reassuring two words a desk can write. The full craft of the update that prevents the chase is in Status Updates That Prevent the Chase. This moment is where that article earns its keep.

Derek's ticket had four internal notes and no updates. That is the commonest shape of the failure: the desk was talking about the ticket, inside the ticket, to itself. A ticket can be busy inside and silent outside. In QuerySolv, as in most tools, an internal note never reaches the requester, which is the point of it and also the trap. A technician who has written four careful notes feels like they have communicated. From the requester's chair they have said nothing at all. Every internal note is a candidate for a public reply. Most of them should become one, shorter, with the jargon taken out.

The Handoff

The requester's question at a handoff is "do I have to start again?", and the answer has to be no, said out loud. A handoff is the ticket changing owner: to second line, to another team, to the colleague covering tomorrow. From the desk's side it is a reassignment and a note. From the requester's side, if nothing is said, it is a new name appearing on a message with no explanation. Or worse, if nothing is said, it is a new person asking what the problem is. The second version tells the requester that their history evaporated. And they will repeat the whole thing, more tersely, with a sentence at the top about having already explained this.

Good looks like an introduction, written by the person handing over, before the new owner speaks. "Tariq looks after the tenancy system and is taking this from here. He has the full history, so you will not need to explain anything; he will be in touch by 12:00 tomorrow." The new owner's first message then confirms the introduction rather than restarting: "Hi Derek, Tariq here, picking up from Ola. I can see the two folders and the permission that is missing; I am fixing it now." The requester has been passed between two people and has never had to repeat a word. The handoff that carries its context, and the one that dumps the ticket over a wall, are compared in The Handoff That Does Not Dump. And the experience side of that article is this moment.

Handoffs are also where tickets go quiet, because the handing-over technician considers the ticket gone and the receiving one has not yet picked it up. Neither feels responsible for talking to the requester during the gap. The gap can be hours or days. Whoever is handing over owns the requester until the new owner has spoken. That one rule closes most handoff silences, and it costs the sentence above. (The ticket does not mind being passed around. The requester does.)

The Fix

The requester's question at the fix is "is it fixed now?", and the answer has three parts: told, shown, and understood. Told means the requester hears it is fixed from the desk before they discover it by trying the thing. A fix applied in silence is not experienced as a fix; it is experienced as the problem mysteriously stopping. And a problem that stops mysteriously can start mysteriously, so the requester stays wary. "I have corrected the permissions on both folders and you should be able to open them now" is a told fix. A status that changes to "Resolved" with no message is a fix the desk told itself about.

Shown means the requester sees it work, on their own screen where possible, or is asked to try it and say so. For a fix made remotely or by a change on a server, the message asks: "Could you try opening the two folders and let me know if either one still refuses?" For a fix made at the desk-side, it is the technician saying "go on, try it" and waiting. Shown is what turns the desk's belief that it is fixed into the requester's knowledge that it is. Shown is the step most often skipped by technicians who are confident and right. They are usually right. The requester does not know that yet.

Understood means the requester could say, in their own words, what was wrong and what was done, at the level they need and no deeper. "The new folders had been created without the housing officers' group on them. So your account could see them but not open them. I have added the group" is enough for Derek, and more than enough. "Perms corrected on tenancy share" is a note to another technician that happened to be sent to a housing officer. The craft of checking that an explanation landed without quizzing the person is in Confirming They Understood. At the fix moment, the test is simpler. It is whether the requester would recognise the problem if it came back and know what to say about it.

The Close

The requester's question at the close is "is it over?", and the answer should be theirs to give. A close that asks sends the fix and asks for confirmation. It leaves the ticket in a resolved state the requester can object to, before anything is marked closed. "If that has sorted it, I will close the ticket; if anything is still wrong, just reply and it comes straight back to me." The requester now has the last word, which is a small thing that changes how the whole ticket is remembered. The ending was agreed, not announced. How long to wait for that confirmation without chasing forever is the subject of User Confirmation Without Chasing Forever. The moment itself is the ask.

Two more things belong at the close. One is a short note of what was wrong and what was done, in plain words. The requester can find it in a month when it happens again. The other is an open way back. "Just reply and it comes straight back to me" is only true if a reply to a closed ticket actually reopens it to the same person with the same history rather than starting a fresh ticket in the queue. Most tools can be set up so that it does. Check yours. The way back is what lets the requester accept a close without fear. A desk whose closes feel final in the wrong way, "please open a new ticket if the problem persists", teaches requesters to resist closing at all.

Derek's ticket was closed with "perms corrected on tenancy share", no ask, and no note he could use. The fix was good. Tariq had done exactly the right thing to the right folders. The close turned a correct fix into a dismissal, and the dismissal is what Derek wrote about. The last moment is the one the requester carries out of the room, and it is the cheapest of the five to get right.

The One Moment That Decides

Ask a requester a month later how a ticket went and they will tell you about the moment they had to ask. They will not tell you about the fix, which they expected, or the duration, which they have forgotten. They will tell you about the point at which they had to initiate contact to find out what was happening, because the desk had not. On most tickets that moment is the waiting update. The first reply was fine, and the fix was fine. In between there was a silence long enough for the requester to write "any news?" The writing of that message is what they remember. It is remembered as having to chase, and having to chase is remembered as not mattering to the desk.

This is why the waiting update is highlighted in the picture and why the rest of this series keeps returning to it. The first reply and the close are events; the desk is prompted to do them by the ticket arriving and the fix landing. The update has no prompt. Nothing in the ticket's life forces a technician to write to a requester while the work is still going on. So the update is the moment most easily skipped and the moment whose absence the requester feels most directly. A desk that fixes only its waiting updates, and nothing else about its moments, will see its comments change in a month. I have watched it happen on three desks, and it has not yet failed.

The deciding moment can be a different one on a particular ticket. A handoff where the requester had to re-explain decides that ticket; a close that arrived while they still had a question decides that one. The general rule is the one on the picture. A ticket is remembered at the moment the requester had to ask, whichever moment that was, and the design job is to make sure there is no such moment. If there is a sentence this whole series could be reduced to, it is that one.

Mapping the Moments at Ashgrove Housing

Fiona mapped the moments by taking twenty resolved tickets from the previous month, at random. She read each one from Derek's side of the glass: public replies only, in order, with the internal notes hidden. At each of the five moments she wrote down what the requester would have seen. She scored it as went well, mixed or went badly, and noted the common failure when there was one. It took her a little over two hours, most of it spent resisting the urge to defend the internal notes. The event history on each ticket, every message and owner change with a time, made the reading a matter of scrolling. A desk whose tool keeps less would reconstruct from the sent mail and take longer.

The numbers are Ashgrove's and nobody else's; a different desk will have a different shape. And the point of the map is to find yours. What Fiona's showed was that her desk's fix moment was fine and its close was not. Her map also showed that the waiting update was missing on most tickets that waited. And it showed that eight of twenty requesters had to ask before they were told anything. She picked two of the six fixes to start with, the waiting update and the close. She chose them because they were the two moments with the most red and because each is a sentence a technician can be asked to write. She did not touch the first reply for a month, on the grounds that three habits at once become no habits.

The map also showed her something the satisfaction score had not: the tickets with the worst moments were not the slow ones. They were the two-day tickets with one handoff, where the first technician considered the ticket gone and the second had not yet spoken. On those tickets, the requester sat in the gap. The slow tickets, oddly, did better, because a technician who knows a ticket will take a week tends to say so. It was the medium tickets, the ones nobody thought of as a wait, that waited in silence.

A Short War Story: The Busy Silence at Bellweather Logistics

At Bellweather Logistics, a dispatch supervisor called Marta raised a ticket on a Monday about the depot's handheld scanners losing their connection in the far bay. A technician called Lewis spent most of three days on it. He was in the bay with a laptop, on the phone to the network supplier, and in the ticket. There he wrote eleven internal notes that together would have made a decent runbook. He sent Marta nothing, because he was busy fixing her problem and because, in his mind, anyone could see the ticket was being worked on. On the Thursday morning Marta telephoned the operations director to say that IT had ignored the scanner fault for three days and the far bay was loading by hand. The director walked to the desk, and Lewis, holding a phone to the supplier with one hand, showed him eleven notes. The cost was a day of the desk lead's week spent in meetings about communication. There was an operations director who had learned to walk to the desk instead of raising tickets. There was also a supervisor who still, a year on, prefaces every request with "I know you are busy, but". The lesson was the one Lewis wrote on a sticky note on his monitor afterwards: work the requester cannot see is work the requester believes did not happen.

The Moments Map

The map below is the one Fiona filled in after her twenty tickets, blank, for your own desk. The top half is the standard. For each moment, it records the question the requester is asking and what the desk promises to do about it. It records who does it and when, and what the trace in the ticket looks like. That way, the promise can be checked rather than hoped for. The bottom half is this month's reading of ten or twenty tickets against that standard, with counts. It also records the one or two moments the desk will work on next. Fill in the top half once, with the team, and argue about the wording until everyone can say it from memory. Fill in the bottom half every month. The standard is the design; the reading is whether the design is happening.

THE MOMENTS MAP — ONE PAGE
Desk: ______________________   Agreed by the team on: ____________   Reviewed: monthly

THE STANDARD (fill in once)
Moment           The requester is asking    What we promise                      Who / when                      The trace in the ticket
1. First reply   "Did anyone see it?"       A named person, a one-line           Whoever claims it, within       First public reply signed,
                                            restatement, a time to come back     ____ minutes / hours            with a time in it
2. Waiting       "Is anyone on it?"         An update before they ask: what      The owner, by every promised    No requester message asking
   update                                   changed, what is next, next time     time, and at least every ____   for status; gaps under ____
3. Handoff       "Do I start again?"        An introduction by the old owner;    Old owner writes it before      Introduction message precedes
                                            new owner confirms, never re-asks    reassigning; new owner          the reassignment; no re-asking
                                                                                 replies within ____
4. Fix           "Is it fixed now?"         Told before they notice; shown or     The owner, at the fix           Resolving message: what was
                                            asked to try; said in plain words                                     wrong, what was done, what to try
5. Close         "Is it over now?"          Asked first; a short note; the way   The owner; closes only after    Confirmation request precedes
                                            back stays open                      a yes or after ____ days silent  the close; note present

THIS MONTH'S READING (____ tickets, chosen at random, public replies only)
Moment            Went well   Mixed   Went badly   Not applicable   The common failure seen
1. First reply    ____        ____    ____         ____             ______________________________
2. Waiting update ____        ____    ____         ____             ______________________________
3. Handoff        ____        ____    ____         ____             ______________________________
4. Fix            ____        ____    ____         ____             ______________________________
5. Close          ____        ____    ____         ____             ______________________________

Tickets where the requester had to ask before being told anything:  ____ of ____
The moment we will work on next month:  ______________________
The one habit that moment needs:        ______________________________________

Fiona's team argued for forty minutes about the wording of the waiting update row, settled on "before they ask", and wrote it on the whiteboard above the desk. Derek raised another ticket six weeks later, about a printer this time, and his comment read: "Ola told me when she'd be back to me and she was. Thanks." It was a two-day ticket. He did not mention the two days. Nobody ever does.

Frequently Asked Questions