How Support Feels Versus How Fast It Closes

Tuesday, 08:40, at Tollgate Foods. Amira runs a desk of four and has the monthly report open on one screen and the satisfaction comments on the other. The report is the best she has produced: 311 tickets, service levels met on all but seven, median resolution under three hours. The comments are from two tickets closed in the same week. Ticket 3120 was from Grace in dispatch, about a label printer that had stopped printing. It was closed in fifty-one minutes and met every target the desk has. Grace's comment reads: "Fixed, apparently. Nobody told me. I'll ask Nathan directly next time." Ticket 3127 was from Yusuf in quality, about a laptop that would not talk to the lab's docking station. It took twenty-six hours, needed a part, and missed the resolution target for its priority by most of a day. Yusuf's comment reads: "Best IT experience I have had here. I knew what was happening the whole time."

Amira's report says the first ticket was the good one. Grace and Yusuf say the opposite, and they are the ones who decide whether to raise a ticket next time. Experience, in a help desk, is what the requester remembers about getting help. That includes whether anyone seemed to see the request, whether they were told what was happening, and whether they had to chase. It includes whether they understood the reply, and whether the ending felt like an ending. The standard metrics measure the desk's clock. Experience is measured by the requester's memory, and the two are related but not the same thing. This article is part of our Experience Over Metrics series. The series is about the second measurement and how to put it beside the first without throwing the first away.

The article covers the two tickets, moment by moment, then what the requester actually remembers. Next come what the standard metrics miss and why, experience-level thinking in plain words, and why speed still matters. Why fast tickets feel bad and why slow ones can feel good follow. A short war story and the ten-ticket experience audit to copy come next, in that order.

Two Tickets, One Week

Ticket 3120 began at 08:49 when Grace sent an e-mail to the desk address saying the dispatch label printer had stopped and the morning's orders were waiting. The tool acknowledged it automatically at 08:49 with a ticket number and no name. At 09:02 the ticket was claimed by Nathan, who tried the obvious things remotely and could not see the printer on the network. He reassigned it at 09:15 to Dev on second line, with an internal note about the switch port. Grace saw none of this. At 09:31 she replied to the acknowledgement: "Any news? We have a van waiting." Nobody answered the reply, because Dev was already at the switch. The fix landed at 09:36: a port that had been disabled by a cleaning contractor's trolley catching the cable. The printer came back. Grace found out because a label came out of it. At 09:40 the ticket was marked resolved, and the resolving message read "Resolved: switch port re-enabled." Her question about the van was never answered. Fifty-one minutes, service level met, every box ticked, and the requester left with a view of the desk she will carry for a year.

Ticket 3127 began at 10:10 the next day when Yusuf used the web form to say that his laptop would not connect to the docking station in the lab. He could not reach the two instruments wired to it. The acknowledgement went out, and at 10:31 Nathan replied under his own name: "Hi Yusuf, I have this. It looks like either the dock or the port on the laptop; I need to try a spare dock, which I can do at 14:00 when I am in the lab block. I will update you by 15:00 either way." At 14:55 he did: "The spare dock works, so the fault is the port on your laptop. It needs a part, which I have ordered and expect tomorrow morning. Keep the spare dock until then; you can reach both instruments through it. I will update you by 11:00 tomorrow." At 10:40 the next morning the part arrived and Nathan handed the repair to Dev. His message to Yusuf said: "Dev is doing the repair at 11:30 and has the full history, so you will not need to explain anything." Dev fixed it and plugged the laptop into the original dock. He had Yusuf open both instrument consoles on his own screen before asking "Anything else while I am here?" Yusuf said no. Dev closed the ticket at 12:14, twenty-six hours after it opened, with a note saying what had been wrong and what had been done.

The picture below puts the two tickets side by side as timelines of five moments each: the first reply, the waiting update, the handoff, the fix and the close. The colour at each moment is how it went for the requester. Grace's ticket is red almost all the way down; Yusuf's is green all the way down. The report graded them in the other order.

Notice what the fast ticket did not lack. It did not lack skill: Dev found a disabled port in twenty minutes. It did not lack urgency: two people touched it inside half an hour. It lacked five sentences, addressed to Grace, at five points, and those five sentences are the whole difference between the two comments. Nathan wrote all five of them on the second ticket, and it took him perhaps four minutes across two days. The desk is not short of skill or effort. It is short of the habit of talking to the person who asked.

What the Requester Actually Remembers

The requester does not carry a stopwatch. Grace could not have told you, a week later, whether her printer was back in fifty minutes or two hours. She could have told you, in detail, that she asked a question and nobody answered it. Yusuf could not have told you whether his laptop took one day or two. He could have told you that Nathan said 15:00 and wrote at 14:55. People remember how they were treated at a handful of points. They remember the points where they had to do something they should not have had to do: ask, re-explain, chase, guess. The duration between those points, when nothing was asked of them, barely registers.

This is not a complaint about requesters being irrational. It is how anyone judges a service they cannot see inside. When you send a parcel, you do not experience the sorting depot. You experience the message that says it is on the van and the person who hands it over. When you wait for a repair at home, the hours are bearable if someone said "between two and four" and unbearable if nobody said anything. A help desk ticket is the same shape. The work happens out of sight. The requester's experience is made entirely of the moments the desk chooses to surface, plus the moments the desk forces on them by going quiet.

The memory also outlasts the ticket by a long way. Grace's comment ended with "I'll ask Nathan directly next time", and she will. That means the next dispatch problem becomes a shadow channel, a direct request that never becomes a ticket. The desk's volume will fall in a way that looks like success. Yusuf's comment will turn into a recommendation the next time a colleague in quality says the desk is slow. Neither effect appears in a report. Both of them decide what the desk's next year looks like. A ticket is closed in minutes and remembered in seasons.

What the Standard Metrics Miss

The standard metrics are good at what they measure, and what they measure is the desk's side of the ticket. Response time measures how long until the desk did something. It counted Grace's automatic acknowledgement as a response at zero minutes. The counter had no way to know that an acknowledgement with no name and no time is not a reply to a person. Resolution time measures the clock from open to resolved. It gave the fast ticket full marks for a fix the requester learned about from a printer. Service-level attainment, the share of tickets inside their targets, rolls those two up and reports the roll-up as a colour. The handful of numbers a desk should track, and why, are in The Handful of Metrics Worth Tracking. None of them is wrong, and none of them can see what happened to Grace.

Satisfaction gets closest, because it asks the requester, and it is still a partial witness. The survey arrives at the end and asks about the ending. So a bad week with a good fix often scores well and a good week that ended in a confusing message scores badly. The survey hears only the people who still answer, who are the people who still bother. The series on what a satisfaction score actually measures explains why that sample flatters. Grace answered because she was annoyed. Most of the people who feel as she does do not answer. They stop raising tickets, which lowers volume, which the report presents as a quieter month.

The table below puts each standard metric beside the thing it genuinely sees and the thing it cannot. Read the right-hand column as a list of the places experience hides. Every entry in it is a moment in the ticket where a human was or was not addressed, and no clock measures that.

If you run QuerySolv, the standard reports already give you volume, backlog by age, response and resolution times, reopen rates and satisfaction. In that setup, the left-hand column is covered without any work. The right-hand column is not in any tool's reports, because it is not a count. It is a reading of a ticket from the requester's side, and a person has to do it. That reading is the audit at the end of this article, and the rest of this series is about making it regular. The report is not lying. It was never asked how Grace felt.

Experience-Level Thinking in Plain Words

Experience-level thinking is the habit of writing down how support should feel, beside the existing promise of how fast it should be, and then checking both. Some people call the written-down version an experience level agreement, by analogy with the service level agreement. This library calls it an experience target, which is shorter and does not sound like a contract. Whatever it is called, it is a sentence like "no requester should have to ask for a status update". Or it might say "every requester is told what was wrong in words they could repeat". The point of writing it is that a sentence can be tested against ten tickets on a Friday afternoon, where a feeling cannot.

The idea sits beside the service level rather than on top of it. A service level is the SLA when it is written down as a service level agreement. In the plain-words sense given in SLA in Plain Words, it is a promise about time. For example, a priority-two ticket gets a first response within an hour and a resolution within a working day. An experience target is a promise about the moments inside that time. For example, the first response will come from a named person and say when they will be back. Nobody will wait more than a day without hearing something. The close will ask before it closes. The service level keeps the desk fast. The experience target keeps the desk kind while it is being fast, or honest while it is being slow. One without the other fails in a predictable direction, and this article's two tickets are what one of those failures looks like.

Nothing about this needs a framework, a certificate or a consultant. It needs the desk to decide, in a sentence each, what a requester should be able to say about every ticket. Then the desk needs to go and look at whether they could. Experience-level thinking is mostly a decision to read tickets from the other end. (The industry has, inevitably, produced a vocabulary for it. The habit is older than the vocabulary.) The rest of this series is that habit broken into its parts: the moments, the measurement, the targets, the design and the report.

Speed Still Matters

None of this is an argument against being fast. A slow desk that writes beautiful updates is a slow desk. The warehouse that cannot ship for two days will not be consoled by the warmth of the correspondence. Speed is part of experience, often the largest part. A ticket fixed in ten minutes with a good message is better than the same ticket fixed in a day with the same message. Everyone, including Yusuf, would rather have had the part in stock. The service level exists because speed matters, and nothing in this series proposes loosening it.

The argument is that speed is necessary and not sufficient. A desk which measures only speed will optimise only speed, which is how the silent close and the one-word resolving message get their funding. The tool makes the close a click and the message a paragraph. A desk judged on the clock will pick the click every time, for sound reasons, until the requesters leave. Treating experience as a second measurement does not slow the desk. It stops the desk from spending the speed it has on tickets that nobody wanted closed that way.

There is also a quieter point about where speed comes from. Grace's fifty-one minutes were fast because two skilled people happened to be free, not because the desk had designed anything. Yusuf's twenty-six hours were slow because of a part, which no amount of design would have put in the drawer. Most of the variation in resolution time is not in the desk's control on the day; most of the variation in experience is. A desk can promise and deliver the five sentences on every ticket. It cannot promise a part. Measure what you can design, as well as what you can only hope for.

Why Fast Tickets Feel Bad

Fast tickets feel bad for a short list of reasons, and all of them are visible in Grace's. The first is the fix in silence: the problem is solved and the requester is not told. So they learn about it by trying the thing. Or, worse, they do not try it and raise a second ticket a week later about a fault that was fixed on the first day. The resolving message that says "Resolved: switch port re-enabled" is a note the desk wrote to itself in the requester's hearing. It tells Grace nothing she can use and does not mention the van. The habit that cures it is in Avoiding the Silent Close, and it costs two sentences.

The second reason is the acknowledgement mistaken for a reply. An automatic message with a ticket number tells the requester that a machine saw the request. It does not tell them that a person did, and a person is what they asked for. Desks that count the acknowledgement as a response have a response time of zero and a first-reply experience of nothing. Grace's "Any news?" forty minutes in was not impatience. It was the first moment she had any evidence that the desk was more than a mailbox. She had to create that evidence herself.

The third is the unannounced handoff, the fourth is the unanswered question, and the fifth is the close that does not ask. Each is a small omission by a busy person doing good technical work, which is exactly why they persist. Nobody did anything wrong, so nothing triggers a review. A fast ticket with all five omissions is not a bad ticket by any measure the desk runs. It is a bad experience by the only measure the requester runs. The desk closed the ticket; the requester closed the account.

Why Slow Tickets Can Feel Good

Slow tickets feel good when the requester never has to wonder. Yusuf's day went well because at every point he knew three things: who had his problem, what they were doing about it, and when he would next hear from them. That is the whole recipe, and the recipe is cheap. Nathan's first reply gave a name and a time. His update arrived five minutes before the time he had given and set a new one. His handoff introduced Dev and said, in so many words, that Yusuf would not have to explain anything again. Dev's fix was demonstrated, not announced, and the close asked a question before closing. Five moments, each handled with a sentence or two, and a missed resolution target became the best comment of the month.

The honest estimate is the heart of it, and the craft of giving one belongs to the managing-expectations series. Here the point is only that an estimate converts a wait from an open-ended anxiety into a scheduled event. "Tomorrow by 11:00" lets Yusuf plan his morning around the spare dock. "We are working on it" lets him plan nothing and check his e-mail every twenty minutes. The two sentences take the same time to write. One of them gives the requester their day back.

There is a limit, and it should be said. A ticket that is slow because the desk is overloaded cannot be rescued by updates forever. The third "still waiting on the part" message starts to sound like the desk hiding behind its own courtesy, and the requester is right to think so. Good communication buys patience. It does not buy an unlimited amount. A desk that finds itself writing many kind updates about many slow tickets has a capacity problem that no sentence will fix. The experience measurement will tell you that too, which is one of its uses. (It is the only measurement that will tell you politely.)

A Short War Story: The Green Quarter at Redbrook Engineering

Callum ran the desk at Redbrook Engineering through a quarter in which every service level was met every month. That had never happened before, and he mentioned it, with some pride, at the quarterly review. The engineering director, Susannah, said that was interesting. She explained that her department had set up its own rota in which two of her engineers took turns fixing colleagues' computers. That was because "raising a ticket means it gets closed before anyone has talked to you." Callum pulled the engineering department's tickets and found a hundred and forty closed inside target over the quarter. Of those, more than half had a resolving message under ten words. A third had been fixed with no message to the requester at all. Twenty-two had an unanswered "any update?" from the requester sitting in them. The cost was two engineers spending something like a day a week each on support work that nobody had asked them to do. It was also a department that had stopped reporting faults in the shared systems because it no longer thought of the desk as the place to report them. And it was three months of green that Callum had to stand up and un-say. The lesson he took was the one on this page. A desk that measures only the clock will be told it is doing well right up to the moment a department tells it otherwise.

The Ten-Ticket Experience Audit

The audit below is the thing no report prints: a reading of ten closed tickets from the requester's side, done once a month, in about an hour. Pick the ten at random from last month's resolved tickets, not the ten you are proud of and not the ten with complaints. For each one answer the questions as the requester would, from what the requester could see. That means public replies only and never internal notes. Score each moment as went well, mixed or went badly, using the same three colours as the picture above. Write one line about the thing the requester had to do that they should not have had to do. Then put the ticket's service-level result beside its experience result and look at the pairs. The audit is easier where the ticket keeps its complete event history, every message and owner change with a time, as QuerySolv does. In a tool that keeps less, you will reconstruct it from the e-mail trail, which is slower and still worth doing. Ten tickets is not a sample anybody would publish. It is the number at which a pattern shows, and it has shown one on every desk I have run it on.

THE TEN-TICKET EXPERIENCE AUDIT — ONE PAGE, ONCE A MONTH
Desk: ______________________   Month: ____________   Read by: ______________________
Ten resolved tickets chosen at random: ______ ______ ______ ______ ______
                                        ______ ______ ______ ______ ______

FOR EACH TICKET, FROM WHAT THE REQUESTER COULD SEE (public replies only)
Ticket: ________   Service level: met / missed    Closed in: ________

  1. FIRST REPLY       A named person? yes / no   A time to come back by? yes / no
                       Went: well / mixed / badly
  2. WAITING UPDATE    Did an update arrive before the requester asked? yes / no / no wait
                       Requester messages asking for status: ____
                       Went: well / mixed / badly
  3. HANDOFF           Owner changed? yes / no   If yes, was the requester told, by name? yes / no
                       Did the requester have to re-explain? yes / no
                       Went: well / mixed / badly / no handoff
  4. FIX               Was the requester told it was fixed before they noticed? yes / no
                       Could they repeat what was wrong in their own words? yes / no / unclear
                       Went: well / mixed / badly
  5. CLOSE             Was confirmation asked before closing? yes / no
                       Was every question in the ticket answered? yes / no
                       Went: well / mixed / badly

  The one thing the requester had to do that they should not have had to:
  ____________________________________________________________________

SUMMARY FOR THE MONTH
  Tickets that met the service level AND went well at every moment:   ____ of 10
  Tickets that met the service level AND went badly at any moment:    ____ of 10
  Tickets that missed the service level AND went well at every moment: ____ of 10
  The moment that went badly most often:  ______________________
  The one change the desk will make this month:  ______________________________

Amira ran the audit the Friday after the two comments arrived. Six of her ten tickets had met the service level. Four of those six went badly at the waiting update, and three went badly at the close. The two tickets that had missed their targets both went well at every moment, which told her something about Nathan's habits and something about where her parts came from. The one change she made was to retire the automatic acknowledgement as the desk's idea of a first reply. Instead, she required a named reply with a time inside the hour. That is the subject of the next article in this series, where the five moments get a page each. Her report the following month still showed green. It also, for the first time, showed what Grace saw.

Frequently Asked Questions