Acting on the Feedback: Low Scores First, Then the Patterns

Wednesday, 08:50, at Stonebridge Insurance. Nadia runs the five-person desk, and the first thing in her inbox is a survey answer from the night before: ticket 14,207, rated poor, with a comment. "Third time this has been 'fixed'." The requester is Graham in claims. Nadia opens the ticket. It is a scanner that stops being seen by Graham's machine every week or so. The fix, each time, has been to reinstall the driver. Each time the resolving reply has said the problem is sorted. It was, for about six days. Graham has now told the desk, politely and in five words, that it has been solving the wrong problem three times. The desk has an hour or so to show him that somebody read it.

Acting on the feedback is everything the desk does after a survey answer arrives, and it has two speeds. The fast one is the low score, which a person follows up within a working day. A low score is a requester who has just told you something went wrong and is waiting to see whether anyone cares. The slow one is the pattern review, which reads a month or a quarter of comments together and finds the things no single ticket shows. A desk that does the first without the second fixes tickets and never fixes causes. A desk that does the second without the first produces insightful reports for people who have stopped answering. This article is part of our Measuring Satisfaction series, and it is about doing both.

It covers why the score is a doorbell rather than a verdict, then the low score followed up within a day by a person. Next come what the follow-up is looking for, what not to do, and closing the loop with the requester. Then it covers the thank-you for the high score, the middling score and the comment without a score, the pattern review, and the technician's side. A worked example from Stonebridge's month, a short war story and the low-score follow-up message to copy finish the article.

The Score Is a Doorbell, Not a Verdict

A low score tells you that something happened and where to look; it does not tell you what happened or whose fault it was. The requester clicked "poor" with the ticket in front of them. They were reacting to a fix that did not hold, or a wait that felt long, or a reply that read as curt, or a policy the desk did not write. The click does not distinguish between those. Reading a low score as a judgement on the technician who closed the ticket is the commonest mistake in this whole subject. It is wrong often enough that a desk which makes it will punish the wrong people and miss the real cause about half the time.

Read it instead as a doorbell. Somebody is at the door, they have something to tell you, and the only sensible response is to go and open it. Nobody improves a house by studying the doorbell. What the desk learns comes from the conversation that follows, which is why the first action is always a person making contact and never a change to anything. Response Bias and How to Read Around It explains why the number itself carries so little. The comment and the follow-up carry nearly all of the value, and this article is about collecting it.

The Low Score, Followed Up Within a Day by a Person

Every low score gets a message from a named person within one working day. Not an automated acknowledgement, not a template with the requester's name dropped into it, not a reply from the technician who was rated unless the comment is plainly about the fix and not about them. A person, usually the desk lead or a senior technician, who has read the ticket, has read the comment, and writes a short message that proves both. The day matters because the requester has just taken the trouble to say something went wrong. The desk's silence after that is a second answer to their complaint, and it is "we do not care".

Read the whole ticket before you write, because the ticket usually contains the answer. Graham's ticket, read from the top, showed three reinstalls of the same driver by two different technicians over seven weeks. Each one closed with a confident reply. None of them had a note asking why a driver kept needing to be reinstalled. The comment "third time" was not an opinion; it was a count, and it was correct. Five minutes with the event history told Nadia more than any conversation would have. It meant that her message to Graham could say what she had found rather than ask him to explain it again. That is the one thing a requester who has explained it three times does not want to do.

Write to the requester, in plain words, with three things in the message. Say that you have read what they said, what you can see from the desk's side, and what happens next, with a time. Keep it short. The message is not an apology letter and it is not a defence; it is a person telling another person that the door has been opened. If the comment was about a technician's manner, the message is from someone else and says so. If the comment was about a policy the desk does not own, the message says who owns it and that the desk will pass it on. Then the desk passes it on. The template at the end of this article is this message, with blanks.

What the Follow-Up Is Looking For

The follow-up is trying to find out which of four things the low score was about. Each of the four is fixed by different people doing different work. The first is the fix: it did not work, did not hold, or solved a different problem from the one the requester had. The second is the time: the ticket took longer than the requester expected, or sat without an update, or waited on something nobody told them about. The third is the manner: the requester felt talked down to, made to repeat themselves, blamed, or ignored. The fourth is outside the desk: a policy, an approval, a supplier, a budget, where the desk delivered the bad news and received the score for it.

The ticket usually says which. A reopen or a repeat ticket points to the fix. A long gap between messages, or a status that sat at waiting for days, points to time. A terse resolving reply, or a thread in which the requester asks the same question twice, points to manner. A comment that mentions a rule, a form, a manager or a vendor points outside. Where the ticket is ambiguous, ask the requester one question, not five: "which part of this went wrong for you?" People who have been asked one honest question answer it; people who have been sent a questionnaire about their complaint do not.

The table below lists the four causes with how each shows in the ticket, what the follow-up does about it, and who owns the change. Its purpose is to stop the desk defaulting to the third cause, manner. That is the one that feels most like a verdict on a person and is in practice the least common. At the fictional desks in this series, the fix and the time account for most low scores between them. Manner is a minority. The outside causes are a larger share than any desk expects until it starts counting.

What Not to Do

Do not argue with the score. The requester felt what they felt, and a message explaining why they were wrong to feel it has never once changed how anyone felt. Even where the ticket shows the desk did everything right, the follow-up acknowledges the experience, explains without defending, and asks what would have made it better. "Nothing, I was just annoyed" is a complete and useful answer.

Do not ask the requester to change the rating. Not directly, not by hinting, not by resolving the problem and then sending a second survey. The rating was their honest reaction at the time, and it stays. A desk that negotiates its scores upward is collecting favours, not feedback, and the technicians will notice within a week that the figure is for sale. The follow-up is not a service recovery technique aimed at the number; it is the desk doing its job for a requester who told it something was wrong.

Do not forward the low score to the technician as a reprimand, and do not send it to them with no comment, which they will read as one. One low score is one person's reaction to one ticket and is not a performance issue; the article on cutting satisfaction carefully by agent gives the minimum counts before any per-person reading is honest. The technician should see the comment, because comments are how people learn. But they should see it from a lead who has read the ticket and has a view on what it was actually about. And do not answer with a template dressed as a person. "We're sorry you feel that way" has never once made anyone feel a different way.

Closing the Loop With the Requester

The follow-up is not finished when the message is sent; it is finished when the requester knows what changed. If the fix was wrong, they hear when the real fix is in, from the person who promised it, on the date promised or earlier. If the ticket was slow, they hear what the desk did about the cause, even if the cause was "we were short-staffed that week and the update should have gone out anyway". If the cause was outside the desk, they hear who it was passed to and, where possible, what that person said. The loop closes when the requester can see that their click produced an action, and that is the only thing that makes the next click likely.

Keep the conversation on the ticket. A follow-up conducted by separate e-mail, or by phone with no note, leaves the ticket's record ending on a confident resolving reply and a low score. The real story is somewhere else. Reply on the ticket, or if the conversation was by phone, write what was said as an internal note immediately after. If you run QuerySolv, a requester's reply to the resolving message reopens the ticket. The follow-up conversation lands on the same record with its whole history behind it. The public reply and the internal note sit side by side where the next technician can read both. In any tool, the test is whether someone opening the ticket in six months can see the low score, the follow-up and the outcome in one place.

Closing the loop also means telling the requester when nothing will change, which is harder and more important. "The approval sits with HR; we have asked them twice to shorten it and will keep asking, and I wanted you to know we heard you" is an honest close to a loop the desk cannot shut. Requesters respect it far more than silence. The craft of that conversation is in Turning a Bad Interaction Into a Recovered One; the point here is that the loop is still closed, even on a no.

The Thank-You for the High Score

A high score with a comment gets a one-line thank-you, from a person, within a day or two. Not every "good" click, which would be noise, but every comment. Somebody took the time to write "Priya sorted this in ten minutes, brilliant". A desk that says nothing back has taught them that writing was pointless. The thank-you is two sentences: thank you for saying so, and I have passed it to Priya. That is all. It takes thirty seconds, and it is the cheapest goodwill the desk will ever buy.

Then pass it on, by name, where the technician's colleagues can see it. Praise from a requester is the most motivating thing a technician receives, more than any figure on a dashboard. It is routinely lost in a report that reduces it to a count of good answers. Read the comment out at the team meeting, forward it to the technician with one line of your own, put it on the desk's noticeboard if you have one. A desk that only surfaces the complaints has told its technicians that the survey exists to catch them, and they will treat it accordingly. A desk that surfaces the praise too has told them the truth, which is that most of the comments are kind.

The high scores also deserve reading for patterns, because they tell you what good looks like in the requesters' words. If a quarter's comments praise speed ten times and explanation twice, speed is what these requesters notice. Delight is as informative as anger. It is simply less urgent, so it gets read second, and it must still get read.

The Middling Score and the Comment Without a Score

The middle answer, "okay" or its equivalent, is the one most desks ignore and the one that most often carries a specific, fixable complaint. People who choose the middle label are telling you the ticket was acceptable and something about it was not. When they add a comment it is usually that something, stated mildly: "fine, though I did have to chase", "sorted, but the first reply asked me things I'd already put in the form". These are not emergencies and they do not need a follow-up message within a day. They need reading, a theme word, and a place in the pattern review. There, three "had to chase" comments in a month become a finding about the desk's update habit.

A low score with no comment still gets the follow-up, and its one question is "what went wrong?"; most people answer. A comment with no score usually arrives through another channel, a reply that says "thanks, but" or a remark in the corridor. Log it on the ticket as an internal note and treat it as a comment. The survey is one channel for feedback. The desk acts on feedback, not on surveys.

The Pattern Review

Once a month, read every comment of the month together, with a word beside each one, and count the words. This is the pattern review, and it is the part of acting on feedback that produces changes to the desk rather than to a ticket. The theme words do not need to be clever: speed, fix, manner, policy, portal, supplier, chase, explain, thanks. Three months of theme counts will show you what the requesters keep saying, and what they keep saying is where the desk's next improvement is. The themes also tell you which of the other series to open. Repeated "fix did not hold" comments about one system belong in Finding the Repeat Tickets. Repeated "had to chase" comments belong with the follow-up cadence. Repeated "didn't know where to look" comments are a knowledge base article nobody has written.

Review the low scores as a group, not only one at a time, because the follow-ups will have found causes and the causes have a shape. If four of this month's five low scores were about the fix and three of those were the same printer model, that is a hotspot, not four unlucky technicians. If three were about time and all three waited on the same supplier, that is a supplier conversation. A pattern review that produces no action is a book club. Every review ends with one line that says what the desk will change this month because of what it read. That applies even if the line is "nothing this month; the comments were about the new starter approval, raised with HR again".

Report the themes alongside the score, because the themes are the part of the satisfaction figure a reader can act on. "Forty-one answers, thirty-four good; five low scores followed up. Two were a scanner driver that is now a problem record, one a supplier delay, one a tone issue being coached, one a policy question passed to finance" is a paragraph a manager can do something with. The score alone is not. The monthly habit of reading the closes together is described more broadly in The Monthly Close Review; the pattern review is the same meeting with the comments open.

The Technician's Side

A single low score is not a performance conversation, and the technicians need to hear that from the desk lead before the first one arrives. It is a ticket to look at together, usually for a cause that has nothing to do with the person who closed it. Sometimes it is for a reply that could have been warmer, which is coaching. The lead reads the ticket first, forms a view, and then talks to the technician about the cause, not the number. If the cause was the fix, the conversation is about diagnosis and testing before the close. If it was manner, the conversation is private, specific, and about the reply, with the series on tone in hard moments as the reference rather than a reprimand.

Technicians should see every comment on their own tickets, good and bad, because comments are the fastest way anyone learns what the requesters actually notice. What they should not see is a running per-person score with too few answers behind it to mean anything. The feedback belongs to the technician as information. It does not belong to the room as a league table.

A Worked Example: Stonebridge's Month

Here is Nadia's month at the fictional Stonebridge desk, as the pattern review recorded it. Forty-one answers from 338 tickets closed with a reply: thirty-four good, two okay, five poor. All five poor scores were followed up within a day; four requesters replied, one did not. Two of the five were Graham's scanner and a colleague's scanner of the same model on the same floor. Both had drivers reinstalled repeatedly. They became a single problem record and, a week later, a firmware update from the supplier that ended the tickets. One was a laptop repair that waited eleven days for a part with no update after day two, which was the desk's. The follow-up apologised for the silence and the lead added that ticket type to the weekly follow-up sweep. One was a requester told no on a software request under the policy, who was annoyed with the policy and said so. The comment was passed to the policy owner and counted as outside the desk. The fifth, with no reply to the follow-up, had a resolving message two lines long; the lead read it as curt, and had a quiet word.

The two okays both mentioned chasing. Of the thirty-four goods, nine had comments; six thanked a technician by name, and all six were read out at the Friday meeting. Nadia's line for the report was: "Forty-one answers, thirty-four good. Five low scores followed up, four resolved to the requester's satisfaction, one unanswered. Two became a problem record now closed by a supplier fix; one was a missed update now covered by the weekly sweep; one was policy, passed on; one was tone, coached. Theme of the month: chasing, three mentions." That is the whole of acting on the feedback for one month. It took about four hours of her time across the month, most of it reading tickets.

A Short War Story: The Unread Mailbox at Kestrel Aviation Services

At Kestrel Aviation Services, an aircraft maintenance company with a three-person desk led by Imogen, the survey answers were delivered to a shared mailbox called feedback@example.com. It had been set up by a predecessor. Nobody on the current desk had been told it existed. Over two months a requester called Fiona, who ran the hangar office, rated three tickets poor. The comments escalated from "badge reader fixed again, let's see" to "this is the third time, nobody has replied to any of these" to "I give up". Each one was about the same door controller that was being rebooted rather than replaced. The fourth time the reader failed, during a visit by a customer's safety auditor, Fiona went to the chief operating officer. The officer asked Imogen in a meeting of twelve people why the desk had ignored three written complaints. Imogen, who had never seen them, had no answer. The controller was replaced that weekend on overtime. The mailbox was found the following Monday with sixty unread answers in it. The desk spent the better part of a year living down a reputation for not reading its own survey. Feedback that is collected and not read is worse than feedback never asked for, because the requester knows you asked.

The Low-Score Follow-Up Message

The template below is the message a named person sends within one working day of a low score. The top block is the message; the four bracketed sections are alternatives, and only the one that fits the cause is kept. The rules block beneath it is for the desk and is not sent. The message is short on purpose. A requester who has just said something went wrong wants to see that it was read and that something will happen. A long apology reads as a desk talking about itself. Write it on the ticket as a public reply so that the record carries it, and send the internal note of what you found at the same time.

THE LOW-SCORE FOLLOW-UP MESSAGE
(public reply on the ticket, from a named person, within one working day)

Subject: Ticket ______ — you told us it did not go well

Hi ______________,

You rated ticket ______ as poor and wrote: "________________________".
Thank you for saying so. Most people do not, and I would rather know.

I have read the whole ticket. From our side I can see that ______________
________________________________________________________________.

[If the fix did not hold]
  I have reopened the ticket. ______________ will ______________ and
  will contact you by ______________. What was tried before is noted on
  the ticket so you will not be asked to explain it again.

[If it took too long]
  It took ______ days; it should have taken about ______. The reason was
  ______________, and you should have had an update on day ______.
  We have changed ______________ so that this does not repeat.

[If it was how you were spoken to]
  I am sorry about that. I have read the replies and I have spoken with
  the desk about them. You will hear from me, not from the same person,
  on anything further about this ticket.

[If it was a rule, approval or supplier outside the desk]
  The decision on this sits with ______________. I have passed your
  comment to them today and asked for ______________. I will tell you
  what they say, even if the answer does not change.

If you have two minutes, one question: which part of this mattered most
to you? ________________________________________________________

I will write to you again by ______________ either way.

______________ (name, role)   ______________ (direct contact)

RULES FOR THE DESK (not sent)
  Sent within one working day of the low score, by a named person.
  Sender has read the whole ticket and the comment before writing.
  Not sent by the technician who was rated, if the comment is about them.
  Never asks the requester to change or repeat the rating.
  Never argues with the score; explains, does not defend.
  Findings go on the ticket as an internal note the same day.
  The promised date is kept, or the requester is told before it passes.
  The cause (fix / time / manner / outside) is tagged for the pattern review.

Nadia's message to Graham went out at 09:20 on the Wednesday, with the fix block filled in. The ticket was reopened. A technician called Ravi was assigned with a note saying that three driver reinstalls had not held and the next step was the controller board. There was a promise of contact by Thursday noon. Graham replied in nine minutes: "Thanks. First time anyone's said that." Ravi found a second scanner on the same floor doing the same thing. The two tickets became one problem record, and the supplier's firmware update ended it. Graham has rated two tickets since. Both good, and neither of them was asked for.

Frequently Asked Questions