Turning a Bad Interaction Into a Recovered One

Wednesday, 16:10, at Acme. Leon's laptop died at 09:40, twenty minutes before a client pitch he had been building for a month. He raised a ticket, rang the desk, got voicemail, and the ticket sat unassigned for fifty minutes while the morning's triage ran late. He presented from his phone, badly, and the client said they would "think about it". When Marta on the desk finally called him at 10:35, he said several things about the desk that she wrote down in a note and did not repeat. The laptop had a dead drive; she imaged a spare and had it on his desk by 15:30. The ticket is now fixed and ready to close, and the desk's instinct is to close it and be grateful the day is over. What happens in the next twenty-four hours decides Leon's story about IT for the next two years. It will be "they lost me a pitch" or "they lost me a pitch and then they sorted it properly."

Service recovery is the work done after a bad interaction. It aims to leave the requester at least as well disposed to the desk as they were before it, and ideally better. It is done after the fix, not instead of it, and it is mostly small. It means a few kept promises, one message the next day, a specific gesture that shows the desk remembered, and sometimes a short note to the right manager. None of it is expensive. All of it is skipped on most desks, because the fix feels like the end and the technician is tired. This article is part of our Working With Frustrated Users series, and it is about the day after.

It covers why the fix alone does not recover anything, then the follow-through for the rest of this ticket. Next come the message a day later, the small specific gesture, and closing the loop with the requester's manager, and when not to. What recovery is not and how to tell whether it worked follow. A short war story and the recovery follow-up message to copy finish the article, in that order.

The Fix Is Not the Recovery

A requester who has had a bad interaction remembers the interaction, not the fix. Leon's laptop works. Leon also remembers fifty minutes of silence, a voicemail, a pitch from a phone, and the way he spoke to Marta. He is slightly ashamed of how he spoke and will convert that, as people do, into a firmer belief that the desk deserved it. The working laptop does not touch any of that. It removes the fault and leaves the story exactly where it was. If the desk closes the ticket now, the story is finished and the desk is the villain in it. Leon will tell it at every dinner where someone mentions IT.

The story can still be changed, because stories are decided by how they end, and this one has not ended. Suppose the next day Leon gets a short message from Marta that shows she remembered the pitch. It says plainly what went wrong on the desk's side and tells him one thing that has changed because of it. The story becomes a different one: the desk failed, and then it did something about it. People tell that story too, and they tell it with a kind of pride, because being the person whose complaint changed something is a good thing to be. I have had requesters become the desk's firmest defenders after an interaction that started with them threatening to go to the director. Not because the fault was small. Because the recovery was real.

Recovery is therefore not a soft extra. It is the part of the interaction that decides what the interaction meant, and it costs about fifteen minutes spread over two days. The desk that skips it is choosing to let the worst version of each bad day stand as the record. The desk that does it is editing the record while it is still open. There is no third option in which the requester simply forgets, however much the desk would like there to be.

The Follow-Through: Keep Every Time on This Ticket

Recovery starts before the fix lands, with the follow-through. The follow-through has one rule: on this ticket, from now on, every promised time is kept, without exception, and there are more of them than usual. A requester who has just been let down is watching the desk closely for the next failure, and will find one if it is there. So you give them nothing to find. "Spare machine on your desk by 15:30" means 15:20. "I'll check in at two" means a message at 13:55 even if the message is "still imaging, on track." The requester's complaint was that the desk went silent; the follow-through is a visible, slightly excessive refusal to go silent again.

Over-communicating on a recovery ticket is correct, where on an ordinary ticket it would be noise. Three updates in an afternoon to a requester who has not complained is a technician who needs to be told to get on with it. Three updates in an afternoon to Leon is the desk rebuilding, in front of him, the one thing it broke, which was his belief that somebody had his problem. Each update is short, has his name in it, and ends with the next time. The proactive update, as a general skill, is the subject of Status Updates That Prevent the Chase. On a recovery ticket, turn the dial up one notch past what that article suggests and leave it there until the ticket closes.

If the plan changes, say so before the time passes, not after. "I said 15:30; the image is taking longer than I expected and it will be 16:15. I'm sorry about that; nothing else has changed." A changed time announced early is a kept promise of a different kind. On a recovery ticket it is the single most convincing thing you can do, because it is exactly what did not happen the first time. A changed time discovered by the requester when 15:30 passes in silence is the original failure again, and this time there is no recovering from it. Resetting the plan honestly when it moves is covered in Resetting Expectations When the Plan Changes; here, do it early and do it in the first person.

The Message a Day Later

The next working day, after the fix has landed and the requester has had a night to find out whether it held, send one message. Not the closing note; that went with the fix. This is a separate, short, personal message with four parts. It checks that the fix held and states plainly what went wrong on the desk's side. It names one specific thing that has changed because of it and leaves the door open. "Leon, checking the replacement machine has behaved overnight. Yesterday your ticket sat unassigned for fifty minutes while triage ran late, which is why nobody called you before the pitch; that was our failure. From this week the first thing triage does is check for anything marked urgent before working the rest. If anything is off with the new machine, reply here and it comes straight to me." Five sentences.

Each part does a job. The check shows the desk is still thinking about the requester after the ticket was fixed, which is rare enough to be noticed. The plain statement of fault, specific and in the past tense, is the acknowledgment the requester may not have received properly in the heat of the day. The shape of it, specific and short, is laid out in Acknowledging Impact Honestly. The one thing that has changed is the heart of the message, because it turns the requester's bad morning into a cause with an effect. People forgive a failure that produced a change far more readily than one that produced an apology. And the open door is the practical part. If the drive image missed something, Leon should find that out from a reply to this message rather than from a new ticket raised in anger.

The day-later timing is deliberate. Send it the same afternoon and it reads as part of the fix, or as the technician wanting to be told it is all fine now. Send it a week later and the moment has gone. The next working morning is when the requester has stopped being angry and started telling the story. It is the last point at which the story can still be edited. If the reply to the message is "actually, it is doing something odd," that is the recovery working, not failing: the requester told you instead of a colleague. If you run QuerySolv, a reply to a resolved ticket reopens it. So the follow-up conversation and the original fault stay in one history rather than splitting into a second ticket that nobody connects to the first.

The Small Specific Gesture

A gesture, in recovery, is a small act that the desk was not obliged to do. It is specific to this requester and this failure, and costs the desk a little effort rather than any money. It is not a gift. Leon lost a pitch because his machine died and nobody had a spare ready. The specific gesture is Marta walking over the following week with a loan laptop already imaged. She says "this lives in the sales cupboard now, logged in. So if anything dies before a pitch you take it and tell us afterwards." That took her forty minutes and a spare machine the desk already owned. It speaks directly to the failure, it is useful to Leon in a way he will use, and it is the thing he will mention when he tells the story.

The test for a gesture is whether it could only have been offered by someone who had listened. A fruit basket could be sent to anyone about anything, and it tells the requester that the desk has a budget line for complaints. (It also tells the rest of the sales team that the way to get fruit is to shout, which is not a lesson a desk wants to teach.) A loan machine in the sales cupboard could only have been thought of by someone who heard "twenty minutes before a pitch". The specific gesture is a form of acknowledgment with its sleeves rolled up: it proves the impact was understood by doing something about the impact in particular.

Gestures are usually one of a small number of shapes. A workaround the requester can keep: the spare in the cupboard, the printed card with the self-service steps, the shortcut set up on their desktop. A piece of knowledge they lacked: ten minutes showing them the thing that would have saved the morning, offered as "would it help if I showed you", never as a lesson. A direct line for the next time: "for the rest of this month, if anything goes wrong before a client meeting, call this number and it rings on my desk." Or a visible change to the desk's own process, which is the one that tends to matter most. It says the desk took the failure as information rather than as weather. Pick the one that fits the failure. If none fits, do not invent one; the day-later message on its own is a recovery, and a gesture that does not fit undoes some of it.

Closing the Loop With the Requester's Manager

Sometimes the right final move is a short note to the requester's manager, and the test for when is simple: did the manager hear about the failure? If Leon's manager heard about the pitch, then she has a version of the story too. And she did, because the client said "we'll think about it". It is the worst version, because it arrived second-hand and angry. A three-line note from the desk, after the recovery is done, gives her the ending. It says what happened, what the desk got wrong, what has changed, and that Leon has a loan machine in the cupboard for next time. Send it with Leon's knowledge, ideally with him copied, so that it cannot read as going over his head.

The note is short and it is not a defence. "Your team's pitch on Wednesday was hit by a dead laptop and a fifty-minute gap before we called Leon back, which was our failure at triage. The machine was replaced by mid-afternoon, triage now checks for urgent tickets first, and there's an imaged spare in the sales cupboard for anything before a client meeting. Leon knows all of this; I wanted you to have it from us too." Nothing in it argues, nothing in it blames the client or the laptop, and nothing in it asks for anything. It gives the manager a story with an ending, and managers repeat the stories they are given.

Do not close the loop with the manager when the manager did not hear or when the requester would rather they did not. Do not do it when the note would be the first the manager had heard of a mistake the requester made. In those cases the note is the desk making a problem visible to protect itself, and requesters can tell. The recovery is for the requester. The manager is included when including them finishes the requester's story, not when it finishes the desk's. When in doubt, ask Leon: "Would it help if I dropped your manager a line about what changed?" He will tell you, and asking is itself part of the recovery.

What Recovery Is Not

Recovery is not grovelling. One specific apology in the day-later message is right. A second one is asking the requester to make you feel better. A third makes the requester responsible for your feelings about their bad morning. The requester wants to know that the desk understood, that it changed something, and that it will not happen again, and all three are better shown than said. A technician who keeps apologising is a technician who is still talking about themselves.

Recovery is not spending. A desk that reaches for a voucher, a gift or a budget line when a requester is angry has taught the organisation that anger has a price and the desk pays it. The small specific gesture costs effort, which is the right currency, because effort is what was missing the first time. Money is what the desk reaches for when it does not want to think about what the requester actually needed, and requesters know the difference between being compensated and being understood.

Recovery is not blaming a colleague, a vendor or a process in the day-later message. "Triage ran late because Sam was off" is the desk's internal business. In a recovery message it reads as the desk explaining why the failure was not really its fault. That is the opposite of what the message is for. "Your ticket sat unassigned for fifty minutes, which was our failure" is the whole of what the requester needs about cause. What the desk does about Sam's absence is a desk conversation. The next article in this series, What Angry Tickets Teach the Desk, is where it gets had, without blame and once a month. And recovery is not over-promising. "This will never happen again" is a promise about the future that no desk can keep. When it does happen again the recovery is remembered as the second lie. "Here is what has changed" is a promise about the present, and the present can be checked.

Knowing Whether It Worked

You know whether a recovery worked from the requester's next contact with the desk, and the signs are small. The greeting is back: "Hi Marta" where last week it was "Laptop dead AGAIN". The next ticket is raised through the ordinary channel rather than a phone call to the one technician they trust. A reply to the day-later message, even one word. A satisfaction comment that mentions the recovery rather than the fault. And, over months, the absence of the story. Nobody in sales says "remember when IT lost Leon the pitch", because the story they tell is the one with the cupboard in it. These are not metrics, and you will not put them on a dashboard. They are what you are actually working for.

The table puts the four recovery moves in order with their timing, what each one tells the requester, and what the desk loses by skipping it. Read the last column honestly against your own desk. Most desks do the first row because they must, and skip the rest because the ticket is closed and the queue is full. The queue is always full. The rest take fifteen minutes.

A Short War Story: The Payroll Export at Marchbank Accountants

Fiona ran the payroll bureau at Marchbank Accountants. On the last working day of a month the export that fed forty clients' payroll files failed at 11:00. The desk's reply came from a technician who had not read the ticket's subject line. It asked her to "confirm which application is affected and whether a restart has been attempted," which Fiona answered with a sentence about restarts that the desk still quotes. The export was fixed by 13:30 by a second technician, Rhys, who found a certificate had expired overnight. The ticket was closed with a correct, dull resolution note. The desk, with the queue full and the day half gone, moved on. Fiona did not. Over the following quarter she rang Rhys directly for everything and refused the ticket form on the grounds that "nobody reads it". She told two partners that IT had nearly cost the firm its biggest payroll client. She asked at a management meeting whether the bureau could have "its own IT person". Rhys estimated later that the three months of direct calls and the partner's inquiry cost the desk about four working days. A day-later message would have taken fifteen minutes. That would mean one line checking the export had run clean and one admitting the first reply had not read the subject line. Then there would be one saying triage now reads the subject before the template, and one leaving the door open. The desk added that message to its routine for every ticket where someone had been angry. Fiona, to Rhys's surprise, became the bureau's loudest advocate for the ticket form, on the grounds that "they actually read it now". That is the lesson: a fixed fault left as the last word leaves the requester to write the ending. They write the one they were feeling at the time.

The Recovery Follow-Up Message

The message below is the day-later note as a template with the four parts marked. Fill every blank from the specific interaction. Give the requester's name, what they lost in their words, the desk's actual failure in plain past tense, and one thing that has genuinely changed. That change must be true and checkable, because the requester will check. Send it from the technician who handled the recovery, in the first person, the next working morning. Keep the manager's note for the cases where the manager heard, and send it only with the requester's knowledge. If a blank cannot be filled honestly, leave the sentence out rather than fill it with something general. A four-line message with nothing general in it recovers more than a six-line one with a "we value your feedback".

RECOVERY FOLLOW-UP — THE NEXT WORKING MORNING

TO THE REQUESTER (from the technician who handled it, first person)

  ________ (first name),

  1. THE CHECK
     Checking that ________________________ (the fix, in their terms) has held
     since yesterday / overnight.

  2. WHAT WENT WRONG ON OUR SIDE (specific, past tense, one sentence)
     Yesterday ________________________________________________ (the actual
     failure: sat unassigned for __ minutes / closed as fixed when it was not /
     the first reply did not read ________), which is why ____________________
     (what it cost them, in their words). That was our failure.

  3. ONE THING THAT HAS CHANGED (true, checkable, present tense)
     From ________, ______________________________________________________
     (the change: triage checks ____ first / a spare ____ is kept at ____ /
     ____ now goes to a named person / the template for ____ now asks ____).

  4. THE OPEN DOOR
     If anything is off with ________, reply to this and it comes straight to me.

  ________ (first name), ________ (a direct contact route)

  Not in this message: a second apology; the name of a colleague, vendor or
  process as the reason; "never again"; "we value your feedback"; anything
  that could be sent to any other requester unchanged.

THE GESTURE (within the week; only one that fits the failure)
  [ ] A workaround they keep: ______________________________________
  [ ] Knowledge, offered not taught: "would it help if I showed you ________"
  [ ] A direct line for a fixed period: ____________ until ________
  [ ] A visible change to our process: ____________________________
  [ ] None fits; the message stands alone.

TO THE REQUESTER'S MANAGER (only if they heard about the failure; requester knows or is copied)

  ________,

  ________'s ________ (what the requester was doing) on ________ was hit by
  ________________ (the fault) and ________________ (the desk's failure), which
  was ours. It was ________ (fixed how, when). ________________ (the change)
  is now in place, and ________________ (the gesture, if any). ________ knows
  all of this; I wanted you to have it from us as well.

  ________ (name)

  Three to five lines. No defence, no blame, nothing asked for.

Marta sent Leon's message at 08:50 on the Thursday. He replied at 09:12 with "Machine's fine. Appreciate you saying that about triage. The cupboard thing would be good." The loan laptop went into the sales cupboard the following Tuesday, with a card on it. Leon's manager got three lines that afternoon, with Leon copied, and replied "Thanks, useful to know." The next ticket from Leon, six weeks later, began "Hi Marta, no rush on this one." It was about a docking station. The pitch, in the end, was lost, and the client went elsewhere, which the desk could not have changed. The story about it was recovered, which it could.

Frequently Asked Questions