Feedback and the Weekly Ticket Review for Technicians

Friday, 15:30, at Castlemere College. Fiona runs the desk, four technicians and herself. She has a spreadsheet open with a column for each of them and a row that says "reopened this month". Ben's cell says six, out of forty-one tickets. Everyone else's says two or three. She has the e-mail to the team half written, with the table pasted in, and the sentence "let's all try to get these down" at the bottom. Her cursor is over the send button when she stops. That is because she has just realised she has no idea what Ben's six tickets were about. She has not read them. She has counted them. The e-mail would tell Ben he is bottom of a table and tell him nothing about what to do differently on Monday. It would tell the other three that a table exists and that they are on it.

The ticket review is a weekly half hour in which a technician and their lead sit with a handful of the technician's closed tickets and read them. They read as the requester read them and as a stranger would read them next year, with the single purpose of making next week's tickets better. It is the best training tool a desk has after the first month, because the ticket is the work itself rather than a number about the work. It is also the one most desks skip in favour of the spreadsheet. This article is part of our Training & Developing Technicians series. This article is about doing the review every week, kindly, and never turning it into a league table.

This article covers why reading tickets beats counting them, then the weekly rhythm and how the tickets are chosen. Next come reading the notes, reading the replies, and the reopen as a lesson rather than a mark. We cover coaching, not ranking, and the minimum sample before any number is read at all. Then come how to give the feedback, what to do when the review finds a pattern, and the review for experienced technicians. A short war story follows, then the ticket review sheet to copy.

Why Reading Tickets Beats Counting Them

A number about a ticket is a shadow of the ticket, and a lead who coaches from the shadow is guessing at the shape. "Six reopens" could be six fixes that did not hold, six requesters who misunderstood a reply, or six tickets closed before the fix was confirmed. It could be one requester with a recurring fault who reopened the same ticket six times. Each of those needs a different conversation. Reading the six tickets takes fifteen minutes and tells Fiona which it is. Counting them took ten seconds and told her nothing she could act on. The count is useful later, for seeing whether the coaching worked; it is useless first.

Reading also finds the things no metric catches. A reply that is technically correct and reads as a brush-off. A note that says "fixed" above a fix that took an hour and will take the next person an hour again. A ticket that was escalated with no reason, or closed with a question still open in the last message from the requester. A first reply that went out four minutes after the ticket arrived and said nothing. None of those move a number this month. All of them are habits, and habits are what the review exists to catch while they are small.

The review is also where the technician learns what good looks like on this desk, in detail, from their own work. A tone guide says "write like a person"; a review says "this sentence, here, in your reply to the bursar, is what that means, and this one is not". Specific beats general in every kind of teaching, and the technician's own tickets are the most specific material available. They also cannot be argued with, which saves a great deal of time.

The Weekly Rhythm: Half an Hour, Ten Tickets

The review is thirty minutes, once a week, for every technician on the desk including the lead. It has a fixed time that is treated as a ticket with a service level and not as a meeting that moves when the queue is busy. The queue is always busy. A review that is skipped in a bad week will be skipped in the next bad week. By the third it is a thing the desk used to do. Fiona's run on Friday afternoons, when the queue is quietest, and each one is in the calendar for the quarter.

Ten tickets are chosen from the technician's closes in the previous week. The choice is a mix rather than a sample of the best or the worst. Five are picked at random, so that the ordinary work is seen. Two are the ones that took longest, because long tickets show the path. Two are ones that were reopened or escalated, because those are where the lessons are densest. One is chosen by the technician themselves. It is often the one they are proudest of or the one that worried them, and both are worth reading. The random five matter most. A review of only the problem tickets teaches the technician that the review is where problems are discussed. They will dread it. A review that reads five unremarkable tickets and finds them good is the review that gets attended willingly.

Each ticket gets about three minutes, read in the order the requester saw it: the request, the first reply, the notes between, the resolving reply, and whether it came back. The lead reads it aloud or both read in silence, and then each says one thing. The sheet at the end of this article has a row per ticket with four columns, and four columns is the right number. A review with twelve criteria per ticket is an audit, and nobody has ever been coached by an audit.

Reading the Notes

The notes are read with one question: could a stranger, picking this ticket up in a year with no one to ask, understand what was wrong, what was tried, what fixed it and why? That is the stranger test, and it is the only test a note needs. That is because every reader of a note is a stranger to the moment it was written, including the technician who wrote it, six months later. The standard a desk sets for its notes, and the few things every note should hold, are in A Ticket Note Standard. The review is where that standard is applied to real tickets, one at a time, by name.

The commonest finding in the notes is absence. "Fixed", "sorted", "done", "user happy" are the four words most often found alone in a resolving note, and each one records that something happened without recording what. The lead's question is never "why didn't you write more?" but "what did you do?" When the technician explains, the follow-up is "that is the note; write that". Most technicians who write "fixed" can describe the fix in two sentences when asked. The review is the place they discover that the two sentences are the note. The gap is habit, not ability, and habit yields to a weekly nudge.

The second commonest finding is the note written for the writer, full of abbreviations and references to "the usual thing", which the technician can read and nobody else can. The review catches this by having the lead read the note cold and say what they understood, which is often less than the technician expected. The technician hears the gap without anyone having to describe it. The resolution note at the close has its own standard and its own article, Resolution Notes Worth Reading Later. The review checks it exists and that it would help the next person, and leaves the craft to that article.

Reading the Replies

The replies are read as the requester read them. That means the lead reads the first reply and asks "if I were the bursar, what would I now know, and how would I feel?" The answer should be "that someone has it, when I will hear more, and fine". A first reply that says "we are looking into it" tells the requester nothing they could not have assumed. One that says "I have your ticket about the projector in room twelve; I will be up at two and will let you know by three either way" tells them everything. It took one extra sentence. The review reads for that sentence.

Tone is read next, and the review is the only place tone gets taught after the first month. That is because nobody else reads a technician's replies once the buddy has stepped back. The desk's voice, and how five people can write in one voice without sounding like a form letter, is the subject of One Voice Across Five People. The review applies it by reading a reply and asking whether it sounds like the desk or like a policy document that has been upset. Common findings include the reply that opens with "as per", and the reply that explains the cause in detail the requester did not want. Others are the reply that is correct and cold, and the reply that is warm and does not say what happens next. Each is one sentence to fix, and the fix sticks because it was found in the technician's own words.

The resolving reply gets the closest reading, because it is the one the requester acts on. It should say what was done in words the requester can test, what to do if the fault returns, and that the ticket will close unless they say otherwise. A resolving reply that says "this should be resolved now" has made a prediction and asked the requester to verify it, which is where many reopens begin. The review asks of every resolving reply: what would the requester do after reading this? If the answer is "try it and hope", the reply needs a sentence.

The Reopen as a Lesson, Not a Mark

A reopen is a ticket the requester has reactivated after the desk marked it resolved. The review treats each one as the most informative ticket of the week rather than as a fault to be counted against anyone. A reopen says that the desk and the requester disagreed about whether the problem was over. The disagreement has one of a few causes. The fix did not hold, or the fix was for a different problem than the one the requester had. Or the ticket was closed before the fix was confirmed, or the requester misread a correct reply. What each cause says about the desk is laid out in What a Reopen Is Telling You. In the review the job is to find which one it was, for this ticket, by reading.

The question that finds it is "what did the requester read, and what did they do next?". Read the resolving reply, then read the requester's reopening message, and the gap between them is usually visible. "I've reset your password" followed by "it still doesn't work on my laptop" is a fix for the wrong problem, and the lesson is in the first questions, not the close. "The printer is working again" followed by "it stopped again at four" is a fix that did not hold, and the lesson is about confirming before closing. "Please try now" followed by silence and then "this was never fixed" a week later is a close that outran the confirmation. Each has a different Monday-morning change, and a count of three reopens would have hidden all of them.

Say out loud, early and often, that a reopen in the review is a good thing to find, and mean it. A technician who believes reopens are counted against them will stop them the easy way, which is to stop closing tickets. The desk will discover a month later that the backlog has grown and the reopen count has fallen and nobody is happier. A technician who believes a reopen is a lesson will close promptly, learn from the ones that come back, and have fewer of them by spring. The requester's reply reopening a resolved ticket is the desk's most honest feedback. It should be treated as a gift that arrives badly wrapped.

Coaching, Not Ranking

Coaching is using a technician's own work to make their next work better, in private, with them. Ranking is placing technicians in an order by a number. The second destroys the first the moment it appears. A technician who knows a table exists will work the table, and every table can be worked. Reopens fall when tickets stop closing, resolution time falls when hard tickets get escalated early, and satisfaction rises when the survey only goes to the easy ones. None of that was anyone's intention. The number changed the behaviour it was meant to measure, which numbers about people reliably do.

Per-technician numbers are still useful, read correctly, and reading correctly means two rules. First comes a minimum sample. No figure about one person is looked at until there are forty or so tickets of a comparable kind behind it. That is because below that the figure is noise with a name on it. A technician who handled eleven tickets of which three came back has a reopen rate that would change by a third if one ticket had gone differently. Second, the figure is a question to bring to the review, not a verdict to deliver in it. Say "your access requests are taking longer than the desk's; let's read three" rather than "your resolution time is the worst". The reasoning behind both rules, and the particular care that satisfaction scores need, is in Satisfaction by Category and, Carefully, by Agent. The way a team view can show load without becoming surveillance is in Dashboards That Motivate Instead of Surveil. This article leans on both rather than re-arguing them.

The tool will offer the numbers, and the lead decides what they are for. If you run QuerySolv, the reports can be cut by technician, with response and resolution times, reopens and satisfaction. The right use of that cut is as the starting point of the Friday conversation, with the tickets open beside it, and nothing else. In any tool the test is the same: if a per-person figure has been seen by anyone other than the technician and their lead, it has become a ranking, whatever it was called. (The wall screen does not need a column for names. It has never needed one.)

Giving the Feedback

The feedback for each ticket is two things, said in this order. First comes one thing to keep doing, named specifically. Then comes one thing to change, named specifically, with the sentence or the step pointed at. "Your first reply told her when you would be up and when she would hear; keep that. The resolving note says 'cleared it'; next time write which queue you cleared and why the job was stuck, so that whoever gets the next one can follow." That is the whole of it for one ticket, and it takes thirty seconds. Ten tickets, ten pairs, and the technician leaves with ten specific sentences and no general impression of having been assessed.

The technician speaks first on each ticket, before the lead, and the lead listens for what they already know. Most technicians can name the weak point in their own ticket if given five seconds to look at it. A technician who names it themselves has learned it; one who is told has merely heard it. "What would you do differently?" is the lead's opening on every ticket. "nothing, that one was fine" is an acceptable answer that the lead should agree with when it is true. The review is not a hunt. Five of the ten tickets should produce "keep doing that" and nothing else. If they never do, either the technician needs the first month again or the lead is looking too hard.

Write the one line for the week down and give it to the technician, because a review that lives only in conversation is forgotten by Tuesday. One line, not ten: the single change that would improve the most tickets next week. "Write the resolving note for the stranger" or "ask when it last worked before touching anything" or "tell them when they will hear from you". The next review opens by reading last week's line and three tickets that show whether it landed. Two things must not happen. The first is the compliment sandwich, where the change is wrapped in praise until the technician cannot find it. The second is the list, where twelve findings are delivered at once and none survive the walk back to the desk. One to keep, one to change, per ticket. One line for the week.

When the Review Finds a Pattern

Three weeks of the same finding is not a technician fault, it is a training gap, and the response is training, not a sterner conversation. If the notes in one category are consistently thin, the technician probably does not understand the fix well enough to describe it. In that case, a day shadowing a colleague on that category will do more than a fourth reminder. If the first replies are consistently late, something in the technician's morning is in the way, and the review should ask what. If the reopens are consistently in one kind of ticket, the knowledge base article for that fix may be wrong, which is a finding about the desk and not about the person reading it. The review finds the pattern. The lead's job is to ask what is causing it before deciding who is.

Patterns across technicians are the desk's, not anyone's. If every review in a month finds resolving replies that say "this should be fixed now", the desk has no agreed resolving reply. In that case, the fix is a template and a sentence in the tone guide, not four separate conversations. If every review finds thin notes on access requests, the access request workflow is probably unclear, and the runbook needs writing. The lead keeps a line per week of what the reviews found in common, and reads it once a month. That monthly read is how the ticket review stops being coaching for individuals and becomes the desk's own improvement loop. It is also the single best source of knowledge base articles the desk is missing, found by reading rather than by asking.

The Review for Experienced Technicians

Experienced technicians need the review as much as new ones and resist it more. The way through is that everyone is reviewed, including the lead, and that the experienced can review each other. A senior technician whose tickets are read by a peer, with the same four columns, gets feedback they have not had in years. Most find, after the first awkward Friday, that they wanted it. The lead's own tickets are reviewed by whichever technician is most senior, in front of nobody, and the lead takes the feedback visibly. A desk where the lead's notes are read and found wanting, and the lead says so and fixes them, is a desk where the review is a habit and not a hierarchy.

The content shifts with experience. New technicians' reviews are mostly about notes and first replies, because those are the habits still forming. Experienced technicians' reviews are mostly about the path. They cover the escalation that could have been a fix, the fix that could have been a knowledge base article, and the known error that was diagnosed from scratch for the fourth time. The experienced technician's review also surfaces the tickets that should have been problem records. The move from fixing a thing to fixing the cause is the start of a path that Development Beyond the Desk follows. The review finds the first step of it, usually in a ticket the technician thought was routine.

A Short War Story: The Table at Northgate Retail

At Northgate Retail, the desk lead, Clive, began e-mailing the team a monthly table of reopens per technician, with the technicians in order. That was because the regional manager had asked for reopens to come down and a table seemed like accountability. Amira worked the store printer tickets that nobody else wanted and had the highest reopen count because printers do that. She was at the bottom for two months running. In the third month she stopped marking tickets resolved and left them in a waiting state instead. She asked the store to confirm and closed only when they did, which stores do slowly. Her reopens fell to zero. The desk's open ticket count rose by about sixty over the quarter. The stores began telephoning to ask why their printer tickets were still open when the printer was working. The regional manager asked a sharper question than the first one. Clive worked out afterwards that the table had cost roughly a hundred hours of chasing and a quarter of worse service. He also realised that he had never once read Amira's reopened tickets. They were almost all the same model of printer failing in the same way, a known error waiting to be written. A ranked number changes the behaviour it measures. The behaviour it produced was a technician protecting herself from a spreadsheet instead of fixing printers.

The Ticket Review Sheet

The sheet below is one page per technician per week, filled in during the half hour and kept by the technician, not filed against them. The top names the week and how the ten tickets were chosen. Each ticket has a row with four columns: the first reply, the notes, the resolving reply, and whether it came back and why. Each column holds a few words, one to keep or one to change. The bottom carries the technician's own view first, then the one line for the week, then last week's line and whether it landed. The sheet is deliberately too small for a list of faults. If something does not fit, it was not the one thing.

THE TICKET REVIEW SHEET — ONE PAGE, ONE TECHNICIAN, ONE WEEK
Technician: ______________   Reviewer: ______________   Week of: ________
Tickets closed this week: ______   Chosen: 5 random, 2 longest, 2 reopened or
escalated, 1 the technician picked.   Last week's one line: ______________________

Ticket   First reply              Notes (stranger test)     Resolving reply          Came back? Why?
______   ______________________   ______________________   ______________________   ______________
______   ______________________   ______________________   ______________________   ______________
______   ______________________   ______________________   ______________________   ______________
______   ______________________   ______________________   ______________________   ______________
______   ______________________   ______________________   ______________________   ______________
______   ______________________   ______________________   ______________________   ______________
______   ______________________   ______________________   ______________________   ______________
______   ______________________   ______________________   ______________________   ______________
______   ______________________   ______________________   ______________________   ______________
______   ______________________   ______________________   ______________________   ______________

In each cell: a few words; "keep:" or "change:" and the thing itself.

THE TECHNICIAN'S OWN VIEW (said first, written here)
  The ticket I am most pleased with and why: ______________________________
  The one I would do differently and how: ______________________________

PER-PERSON NUMBERS (coaching only; not read below ____ comparable tickets)
  Question the numbers raise for the review, if any: ______________________
  Tickets read to answer it: ______  ______  ______

ONE LINE FOR NEXT WEEK
  ______________________________________________________________

DID LAST WEEK'S LINE LAND?  yes / partly / not yet     Seen in tickets: ______  ______  ______

FOR THE DESK, NOT THE PERSON (patterns the lead carries to the monthly read)
  ______________________________________________________________

Fiona deleted the e-mail and read Ben's six tickets instead, which took twelve minutes. Four were the same lecture-theatre projector, reopened by the same technician in the estates team each time it dropped its signal. They were a known error nobody had written down. Two were resolving replies that said "should be working now" to requesters who had tried it, found it was not, and said so. On Friday she and Ben read the ten. He named the "should be working now" problem himself before she did. The one line for the week was "say what you did and what to do if it comes back". The projector got a known-error entry on Monday. Ben's reopens were two the next month, which Fiona noticed and did not put in a table.

Frequently Asked Questions