What Angry Tickets Teach the Desk When Read Together

The last Friday of the month, 15:00, at Southmere Council. Jo runs the desk, and on the table in front of her are twelve printed tickets. They are the ones the team flagged this month because the requester was angry. Three technicians are round the table. Amir, who joined in the spring, has four of the twelve, and he has been quiet since Wednesday, when he saw the list. Jo has forty minutes. In them she needs to find out what the twelve have in common and decide what the desk changes because of it. She must make sure Amir leaves the room knowing that four tickets about the same broken login page are information about a login page, not about him. All three of those are the same job, done properly.

An angry-ticket review is a short, regular meeting in which the desk reads every ticket where a requester was frustrated, side by side, and looks for what they share. Read one at a time, as they arrive, angry tickets look like twelve separate bad days and twelve separate people to blame, usually whoever answered. Read together once a month, they nearly always turn out to be three or four tickets about the same thing. That is the same system, the same step in a process, or the same promise the desk keeps making and breaking. The individual conversations are the subject of the rest of this series. This article is part of our Working With Frustrated Users series. This article is about what the conversations add up to.

This article covers why angry tickets are data rather than verdicts, then how to flag them as they happen so that the review has something to read. Next come the monthly read itself and the three patterns to look for: the same system, the same step and the same promise. We cover fixing the system instead of the person, then protecting the team from taking it personally. We finish with what goes upward from the review, a short war story, and the angry-ticket review sheet to copy.

Angry Tickets Are Data, Not Verdicts

An angry ticket, read on its own, feels like a judgement on whoever handled it. That feeling is wrong often enough to be dangerous. The technician who answered was the address, not the cause, which is the argument of the first article in this series, Why Users Get Angry at the Help Desk. What the ticket records is that something in the organisation's technology or the desk's process pushed a person far enough to shout. Twelve of those in a month is twelve measurements of where the pushing happens. A desk that treats each one as a verdict on a person learns nothing and loses people. A desk that treats them as measurements learns where to dig.

The measurements are unusually honest, which is their value. Satisfaction surveys are answered by people who were pleased or very displeased and by almost nobody in between. Response and resolution times measure the desk against targets the desk set. An angry ticket is a requester telling the desk, unprompted and in their own words, exactly which part of their day the desk made worse. The words are preserved. No other data the desk holds is that direct about what matters to the people it serves. It is uncomfortable to read, which is why it is usually not read, and that is a waste of the only free consultancy the desk will ever get.

Reading them together is what turns twelve complaints into a pattern. One requester angry about the HR system's login page is a bad morning. Seven in a month, from four departments, each handled by a different technician, each starting with a password reset that did not take, is a login page. Nobody sees the seven while handling the one, because each technician saw one or two and assumed the others had a different cause. The review exists to put them on the same table, where the pattern is visible to anyone who looks. It is nearly always visible within ten minutes. The hard part is making the ten minutes happen every month.

Flagging Them as They Happen

The review can only read what was marked. So the first habit is to mark an angry ticket at the time, in a way the whole desk does identically. The mark is simple: a tag or a custom field. In tools with neither, use a fixed word in an internal note, such as HEAT, that a search will find at the end of the month. Pick one form and write it on the wall. The marking rule is equally simple: if the requester was angry at any point, in any channel, the ticket gets the mark, whoever was at fault and however it ended. Marking is not an admission. It is a note that this one goes on the table.

Alongside the mark, the technician writes one line about the heat, separate from the technical notes: what the requester was angry about in their words, and roughly how far up the ladder they were. "Third time this month, label printer, drivers waiting; anger, manager copied." That line is what the review reads first, because the technical resolution tells you what broke and the heat line tells you what hurt. The two are often different things. The ticket about the dead drive was resolved by imaging a spare; the heat was about fifty minutes of silence before anyone called. A review that reads only resolutions will fix drives and miss the silence.

Make marking cheap and make it safe. Cheap means it takes ten seconds and happens before the next ticket, not at the end of the week from memory. Safe means nobody is ever asked "why do you have four marked tickets?" in a tone that makes them stop marking. The first month a desk does this, the technician with the most marked tickets is usually the one who answers the most phones. Or it is usually the one with the honesty to mark them all. Neither is a fault. If the count is used as a stick, the marks disappear within a quarter and the review reads a reassuring, empty list. The list is only useful while people are willing to make it longer.

The Monthly Read

The review is forty minutes, once a month, with everyone who answers requesters in the room and the marked tickets printed or on a shared screen. Reading, not discussing, takes the first ten minutes. Each ticket's heat line is read out, with the system involved and the step in the process where the heat started. The read also includes the technician's one-line view of what the requester actually wanted. Nobody comments during the read. Comments during the read turn the meeting into twelve separate defences, and the pattern never gets a chance to appear. Read all twelve, then look at the table.

Then sort. Group the tickets by system first: how many were about the HR login, the label printer, the shared drive. Then by step: how many started at intake, in the gap before first contact, at a handoff, at a close that was not a close, at a promised time that passed. Then by promise: how many involved a specific thing the desk said would happen and did not. Most months, one grouping will account for half the tickets, and that is the month's pattern. Some months there are two. A month with twelve unrelated tickets is rare and is worth saying out loud, because it means the heat was weather rather than structure. The team can hear that.

Preparation is lighter than it sounds, because most of the lists already exist. The marked tickets are one search. Reopened tickets, tickets that breached a response or resolution target, and tickets with a poor satisfaction comment are three more. They overlap heavily with the marked list. The overlap is itself informative, because a ticket that was angry but never breached a target is telling you the targets measure the wrong thing. If you run QuerySolv, the reports on reopens, escalations and satisfaction are three of the four lists ready-made. In that setup, the event history on each ticket shows how long it sat and who touched it. So the step where the heat began is a timestamp rather than a guess. On any tool, the four lists and forty minutes are enough.

The Three Patterns: Same System, Same Step, Same Promise

The same system pattern is the easiest to see and the one the review finds first. In this pattern, a disproportionate share of the month's heat is about one application, one device type, one site or one supplier. Seven of Southmere's twelve were about the HR system's login page, which had started rejecting the first password reset and accepting the second since an upgrade nobody connected to it. Each technician had handled one or two, reset the password twice, and closed the ticket. The pattern was invisible from inside any one ticket and obvious from the table. The system pattern's fix is almost always a problem record and a permanent change. The discipline of finding the repeats and raising the problem is in Finding the Repeat Tickets. The angry-ticket review is one of the best feeds that discipline has, because requesters shout about the repeats first.

The same step pattern is subtler, because the tickets are about different things and share only where in the process the heat began. Three of Southmere's remaining five had nothing in common technically. All three had sat unassigned for more than two hours because they arrived between the morning and afternoon triage passes. The requesters had rung in the gap. The system was different each time; the step was identical. Step patterns point at the desk's own process: the intake gap, the handoff that drops context, the close without confirmation, the hold status that nobody revisits. They are fixed by changing the routine rather than the technology. They are the patterns a desk most needs an outside eye on, because the routine looks fine to the people inside it.

The same promise pattern is the one that hurts most to find and pays most to fix. The desk says a thing will happen, routinely, and it routinely does not: "someone will call you back within the hour", "you'll get an e-mail when it's done", "we'll have that sorted by Friday". The promise is in a template, or in a habit, and nobody checks whether it is kept. Southmere's last two tickets were both from requesters told "you'll hear back within the hour" by the auto-reply. It had said that since before anyone on the current team was hired, on a desk whose actual first-response time was closer to three. The fix for a promise pattern is either to keep the promise or to stop making it, and the second is usually faster. A desk that promises an hour and takes three has created a complaint in every ticket. A desk that promises four and takes three has created none. What the service-level agreement (SLA) targets themselves should promise, and what they never should, is the subject of SLA Breaches and What They Teach. The review's job is to notice that a promise is being broken often enough to make people shout.

Fixing the System, Not the Person

The review ends with one change, and the change is always to a system or a process, never to a person. This is a rule, not a preference. It is worth being strict about, because the person fix is always available and always feels like action. "Amir needs to be quicker at password resets." "Dana should have called back." Each may even be true in the single case. Neither fixes next month, because next month a different technician will meet the same login page and the same intake gap. The review will have the same twelve tickets with different names on them. The system fix is the only kind that reduces the count. The login page gets a problem record and the upgrade is rolled back. The intake gap gets a midday glance at the unassigned list. The auto-reply stops promising an hour. Those three changes, from Southmere's one review, removed the cause of ten of the twelve tickets.

A system fix is any change that makes the heat less likely regardless of who is on shift. Examples are a problem raised, a routine added, a template reworded, a spare kept somewhere, a form field made mandatory, or a promise retired. A person fix is a change that depends on an individual doing better. It is not a fix, because people have bad days and the desk has to work on those too. The test for the review's chosen change is to ask whether it would have helped if every technician on the team had been swapped for a stranger with the same training. If yes, it is a system fix. If it only works because Amir will try harder, it is a hope with a deadline.

Choose one change a month, write it down with an owner and a date. Check at the next review whether it was made and whether the count of that pattern fell. One change made is worth more than five agreed, because five agreed is a list and a list is where good intentions go to be archived. The reopen review and the monthly close review, which are the review's cousins, work the same way, one change at a time. They are described in The Reopen Review. Many small desks fold the three into one monthly hour, reading the reopened, the breached and the angry tickets together. That is sensible as long as the angry ones are read as angry and not only as late.

Protecting the Team From Taking It Personally

The person with the most marked tickets is in the room. The review is either the moment they learn that the heat was about a system or the moment they start marking fewer tickets. Jo's job in the first ten minutes is to make the first outcome certain. She does it by how she reads: the heat line, the system, the step, and never the technician's name as the subject of a sentence. "Ticket about the HR login, third reset, requester had been locked out since Monday, anger with manager copied" tells the room what happened. "Amir's ticket about the HR login" tells the room whose fault it was, and the room, including Amir, will hear it that way however it was meant.

Protecting the team is not the same as pretending nobody ever handled a call badly. Sometimes a technician did send the sharp sentence, and the ticket shows it. That is a conversation for the lead and the technician, in private, on the day. It is about the sentence, not the ticket's heat; the heat would have been there anyway. The review is not the place for it, and a review that becomes the place for it stops getting honest marks within two months. What the review can do, openly, is read the sharp sentence as data too. If three different technicians sent a sharp sentence this month, the system question is what made three calm people sharp. The answer is usually workload, a broken tool, or a requester base that has been let down for so long that every call starts on rung three. That is a system finding with a system fix, and it protects the team by taking their side against the cause.

The simplest protection is to say the thing out loud every month, because people need to hear it more often than it feels necessary to say. "These twelve are about a login page, an intake gap and an auto-reply. None of them is about anyone in this room." Said by the lead, with the sorted table in front of everyone, it is not a platitude; it is a reading of the evidence. The desk that says it every month keeps technicians who can answer an angry call without flinching, because they know where the call will end up. It ends up on a table, as a line, next to six others, pointing at a system. The desk that never says it keeps technicians who dread the phone, and then does not keep them.

What Goes Upward From the Review

The review produces a short note for whoever the desk reports to. The note is four lines: how many angry tickets this month, the main pattern, the one change being made, and anything the desk needs from above to make it. "Twelve this month, seven about the HR login page since its upgrade; we have raised a problem and asked the HR system's owner to roll back; we need the change window on Thursday evening approved." That is the whole report, and it is a better account of the desk's month than any response-time figure. That is because it says what hurt the organisation's people and what the desk is doing about it. Managers who receive this note monthly stop asking the desk for dashboards, because the note already answers the question the dashboard was for.

The note's numbers are honest or they are nothing. The count of angry tickets will go up in the first few months of doing this, because marking becomes a habit. A lead who presents that rise as a worsening desk will be told to make it fall, which is done most easily by marking less. Present it as what it is: the desk has started counting something it used to ignore. The number that should fall is the count within the pattern you fixed. That one falls visibly once the fix is in, which is the evidence that the review is worth its forty minutes. A pattern that does not fall after its fix is the review's most useful finding of all, because it means the cause was somewhere else. The next review knows where not to look.

The last thing to watch for, and to report, is a count that falls to nothing. Zero angry tickets in a month on a desk of any size is not a good month. It is either a month in which nobody marked, or a month in which the people who used to shout have stopped raising tickets at all and found another way. The second is the silence described in The Seven Ways Support Quietly Fails. The review should treat a sudden quiet from a formerly loud department as a pattern in its own right, worth a phone call to ask how they have been getting help. Anger is a requester still trying. The review wants to keep hearing it.

A Short War Story: The Four Tickets at Linwood Veterinary

Linwood Veterinary ran a desk of two for six clinics. When the practice manager, Aisha, asked for a monthly look at complaints, the first review consisted of the senior technician reading out four angry tickets. Three had been handled by the junior, Ben. The senior technician concluded in front of him that "Ben needs to work on his phone manner." Ben stopped marking tickets the following week. The next three reviews read two, one and zero angry tickets, which Aisha presented to the partners as an improvement. In the fourth month the Harbour Street clinic's head nurse told a partner directly that the appointment system had been double-booking every Tuesday since the autumn. The nurse also said that "IT just resets it and goes away". The partner asked Aisha why none of this was in her reviews. It was not in them because the Tuesday tickets had been angry, unmarked, and closed by Ben, who had learned in the first review what a marked ticket cost him. The double-booking turned out to be a scheduled job running against the wrong clinic calendar, fixed in an afternoon once anyone looked for a pattern. By then it had cost the Harbour Street clinic an estimated forty missed appointments and Linwood its junior technician, who left in the spring. Aisha's reviews now begin with the sentence "nothing on this table is about anyone in this room." The count went up for three months before it started, honestly, to fall.

The Angry-Ticket Review Sheet

The sheet below is the review on one page. It includes the preparation, the read, the sort, the one change, the words said out loud, and the four-line note upward. Fill it in during the meeting, by hand or on a shared screen, and keep the completed sheets. That is because the second most useful thing the review produces is a run of twelve sheets at the end of a year. They show which patterns came and went and which change made each one go. The sheet is deliberately dull. Reviews that are interesting are usually arguing about a person.

ANGRY-TICKET REVIEW — ONE PAGE, ONCE A MONTH
Desk: ______________   Month: ________   Lead: ______________   Present: ______________________

BEFORE THE MEETING (one person, twenty minutes)
  [ ] Search for the heat mark (tag / field / note word "______"): ____ tickets
  [ ] Reopened tickets this month: ____     [ ] Breached response or resolution: ____
  [ ] Poor satisfaction comments: ____      Overlap with the heat list: ____ of ____
  [ ] Print or share: ticket number, system, heat line, step where heat began, technician's one-line view

THE READ (ten minutes; no discussion until all are read)
  For each ticket, read aloud: system / heat line in the requester's words / step / what they wanted
  Never read the technician's name as the subject of the sentence.

THE SORT
  By system:   ______________ ____   ______________ ____   ______________ ____
  By step:     intake gap ____  first contact ____  handoff ____  close ____  hold ____  promised time ____
  By promise:  "____________________________" made ____ times, kept ____ times
  Largest grouping: __________________________  holds ____ of ____ tickets
  Second grouping (if any): ________________________  holds ____

THE ONE CHANGE (a system fix: would it help if every technician were replaced by a trained stranger?)
  Change: _____________________________________________________________________
  Type:  [ ] problem raised  [ ] routine changed  [ ] template or promise changed
         [ ] spare or workaround placed  [ ] form or field changed  [ ] escalated to system owner
  Owner: ______________   Done by: ________
  Last month's change: ___________________  Made? [ ]  Pattern count then ____ now ____

SAID OUT LOUD BY THE LEAD
  "These ____ tickets are about ________________, ________________ and ________________.
   None of them is about anyone in this room."

WATCH FOR
  [ ] A department that used to appear and has gone quiet: ______________  (call them)
  [ ] Sharp replies from more than one technician this month: ____  (system question: what made calm people sharp?)
  [ ] Zero marked tickets: marking stopped, or requesters stopped. Find out which.

THE FOUR-LINE NOTE UPWARD
  This month: ____ angry tickets.  Main pattern: ______________________________.
  Change being made: ___________________________________________________.
  Needed from above: ___________________________________________________.

Jo's first review at Southmere took thirty-five minutes. Seven tickets were the HR login, three were the intake gap, two were the auto-reply's promise of an hour. She raised the login as a problem and asked the HR system's owner for the rollback. She added a midday look at the unassigned list to the rota. She changed the auto-reply to say "a person will reply today and tell you when to expect the next update," which was true. Then she said the sentence, with the sorted table on the screen. Amir, whose four tickets had all been the login page, said "right" in the voice of someone putting something down. The following month the desk marked nine tickets, none of them about the login. The review took twenty minutes, most of which was spent on a label printer.

Frequently Asked Questions