Home › Topics › IT's Internal Brand › Service Recovery

Service Recovery Moments: When a Failure Builds Trust

Monday, 08:05, at Harbourview Clinic. The appointments system has not come back after a change made on Sunday evening. The morning clinic starts at half past eight. Reception already has six patients standing in front of a screen that says "connecting". Nadia, who runs the two-person desk and made the change, can see the fault and reckons forty minutes to put it right. She has two choices and about ninety seconds to make one. She can fix it quietly and hope that reception puts it down to the system being the system. Or she can walk to the front desk now, with nothing fixed, and say what happened. The first choice feels safer. It is the one that writes the sentence "IT broke the appointments and didn't even tell us", and that sentence lasts for years.

Service recovery is what the desk does after a failure, from the first minute to a week later. It decides whether trust ends up below where it was or above. The surprising part, which anyone who has run a desk for a while has seen, is that above is possible. A failure handled well shows people things the ordinary service never shows them. It shows that the desk notices before they do and tells the truth without being asked. The desk fixes the thing, comes back to check, and does one small thing more. This article is part of our IT's Internal Brand series. And it is about those moments, because they are where a reputation is rewritten fastest, in either direction.

It covers the recovery curve and why a well-handled failure can end above the line, then the five moments of a recovery. Next come the apology that works and the three that do not, the follow-up a week on, and the small thing done unasked. We turn to recovery at the scale of one ticket, then a short war story. We finish with the service recovery playbook for a fictional desk, to copy, in that order.

The Recovery Curve

Draw trust as a line over time. Before the failure it runs flat, at whatever level the desk has earned. At the failure it drops, sharply, to about the same low point whatever the desk does next. The drop is caused by the failure and not by the handling. From that point the line can go two ways. Handled badly, with silence, a quiet fix and no word afterwards, it drifts upward a little as people forget. It never gets back to where it was. Handling the failure well means a notice in minutes, an honest account, a fix, an all-clear, a follow-up a week on and one small thing more. Handled that way, trust climbs through the old line and settles above it. The picture below draws both.

A line chart of trust over time after one failure, handled two ways. A dotted horizontal line marks trust before the failure. Both lines drop sharply at the failure to the same low point. The green solid line, labelled handled well, climbs through four marked events: first notice within minutes, the fix and then the all-clear, the follow-up a week on, and the small thing done unasked, and it ends above the dotted line, labelled above where it started. The red dashed line, labelled handled badly, drifts upward only slightly with no notice and no follow-up and ends well below the dotted line. A footer says a failure handled well can leave trust higher than it was, and one handled badly rarely gets back to the line.
The dip is the same either way. What happens after it is the desk's to decide.

The curve is a sketch rather than a measurement, and it is worth saying what it does and does not claim. It does not claim that failures are good for a desk, or that a desk should seek them. It claims that the handling, not the failure, decides where the line ends. The handling is cheap: a walk to reception, three honest sentences, a message a week later. Those cost minutes. The sentence they prevent costs years.

Why can the line end above where it started? Because in ordinary service, people see competence, and competence is expected. In a failure, they see character. Did the desk tell them before they found out? Did it say "we did this" or "the system did this"? Did anyone come back afterwards? Nobody forms an opinion of a desk from a hundred tickets that went fine. They form it from the Monday the appointments went down, and from what Nadia did in the ninety seconds after.

The Five Moments of a Recovery

A recovery has five moments, in order. Each one has a thing the people affected need, a sentence that gives it to them, and a mistake that the desk makes under pressure. The table below is the shape of the whole article. Each moment is owned in detail by another part of this library. The first notice, the cadence of updates and the all-clear belong to the outage communication series. And the conversation with a person who is already angry belongs to the frustrated-users series. This article is about what the five moments do to the brand. It explains why the last two, which almost every desk skips, are the ones that lift the line.

MomentWhat people needThe sentenceThe mistake under pressure
First notice, within minutesTo know that IT knows, before they have to ask"The appointments system is down; we know; we are on it; next update at 08:30."Waiting until there is something fixed to say
The honest accountTo know what happened, in plain words, including whose change it was"A change we made last night had a fault in it.""The system experienced an issue" (no owner, no verb)
The fix and the all-clearTo know it is safe to carry on, and what to do if it is not"Working again since 08:50; if anything looks wrong, call the desk on the short number."Fixing it and going quiet, so people find out by trying
The follow-up, a week onTo know the desk is still thinking about it, and to be asked"Has anything from last Monday come back? What have we not noticed?"Treating the all-clear as the end
The small thing done unaskedNothing; that is the point"While we were at it, we fixed the slow printer by reception."Doing it and announcing it as a gesture

The first three moments stop the line falling further. The last two are what lift it above where it started, and they are the two that cost nothing and that nobody expects. A desk that does the first three is a competent desk recovering from a failure. A desk that does all five is a desk people tell new starters about, for the right reasons.

The Apology That Works, and the Three That Do Not

An apology that works has three parts and no adjectives. First comes what happened, in plain words with an owner. Then comes the effect on the people affected, named specifically. Last comes what has changed so that it does not happen the same way again. "A change we made on Sunday evening broke the appointments system. Reception could not book or check in anyone for forty minutes at the start of the Monday clinic, and six patients waited. We have changed how we test that kind of change, and the next one will be done at a time when the clinic is closed and checked before anyone arrives." Three sentences. It is not grovelling, and it is not a press release. It is an account, and people forgive an account.

The first apology that does not work is the one with no owner. "The system experienced an unexpected issue" is a sentence in which nothing was done by anyone. Everyone who reads it knows that a change was made by someone. The desk that writes it is not protecting itself. It is announcing that it will not say what happened, and the reader fills in the blank with something worse. Where a vendor's fault really was the cause, say so plainly and once, and then say what the desk is doing about depending on that vendor. Blame is not the point. The point is that somebody can be seen to be telling the truth.

The second is the one that apologises for the wrong thing. "We apologise for any inconvenience caused" apologises for a hypothetical, to nobody in particular. The people who stood at reception for forty minutes notice that their forty minutes has been described as "any inconvenience". The craft of naming the effect on the person, specifically and without exaggeration, is in Acknowledging Impact Honestly. That craft applies to a clinic full of patients exactly as it applies to one requester on the phone. Say what it cost them, in their units. Then say what changed.

The third is the one that over-apologises. It has four paragraphs of regret, three uses of "deeply", and a promise that it will never happen again. That is a promise no desk can keep and every reader knows it. An apology that is bigger than the failure reads as either panic or theatre, and both lower trust. One honest account, the right length for the thing that happened, delivered by a named person in the desk's ordinary voice, is enough. The voice for bad news, the mistake and the apology, and how to keep it steady, belongs to Tone in Hard Moments. The brand rule is shorter: say it once, say it plainly, sign it.

The First Hour

The first notice goes out before anything is fixed, within minutes. It says only that the desk knows, that it is working on it and when the next update will come. The reasoning and the wording are in The First Notice: Say Something in Five Minutes. And this article will not redo it, except to say what it does to the brand. A notice before people have asked tells them the desk saw the problem before they did. That is the single most reassuring thing a desk can show. A notice after they have asked tells them the desk was waiting to be told. Same words, five minutes apart, opposite effect.

Nadia walked to reception at 08:07 with nothing fixed. She said to the receptionist and to the six patients within earshot, "The appointments screen is down. It is our fault, a change last night. About forty minutes. Book on paper, and we'll put them in when it's back." Then she went and fixed it. The receptionist had been bracing for a morning of apologising to patients on IT's behalf. Instead she had been given a time, a reason and a plan. She repeated all three to every patient who arrived. For forty minutes, reception was the desk's spokesperson. That is what a first notice buys.

The all-clear closes the first hour, and it says three things: it is working, since when, and what to do if it is not. The message that goes out when it is fixed, and the written follow-up that comes after it, are the subject of The All-Clear and the Follow-Up. The brand point is that the all-clear is the moment most desks consider the recovery finished. And it is the moment the line has only just stopped falling. The climb has not started yet.

The Follow-Up a Week On

A week after the failure, the desk goes back to the people most affected and asks two questions. Has anything from that day come back? What have we not noticed? It takes ten minutes, it can be a message or a walk, and nobody expects it, which is why it works. The receptionist at Harbourview had two paper bookings that never got entered and a printer by the front desk that had been slow since the same Sunday. Neither had become a ticket, because people who have just lived through a failure do not raise tickets about the small stuff afterwards. They mention it to each other instead. The follow-up is how the desk hears it first.

The follow-up also says something the all-clear cannot, which is that the desk is still thinking about it after the pressure is off. Anyone can be attentive during an outage; attention is what outages are made of. Attention a week later, with nothing on fire, is rare enough that people notice it and repeat it. "They came back the next week to check" is a sentence that gets passed on. It is the first sentence on the climbing line that the desk did not have to earn through a fix.

Write the follow-up into the incident's record, or the ticket's, as a note, so that it happens. A recovery that depends on someone remembering a week later will not happen in the week the desk has another failure. For a single ticket, the same discipline is the confirmation step that a proper close already includes. The way to do it without chasing forever is in User Confirmation Without Chasing Forever. For an outage, it is a dated task in the incident review with a name on it. Either way, it is scheduled, not hoped for.

The Small Thing Done Unasked

The small thing done unasked is a related piece of work the desk does during or just after the recovery. The affected people did not ask for it. It costs the desk a little and the requester nothing, and is not announced as a gesture. Nadia fixed the slow reception printer on the same visit as the follow-up. The loan laptop arrives with the right charger and the user's bookmarks already on it. The knowledge base article that would have answered the question gets written and linked in the all-clear. None of these is a gift, and none of them is a strategy. They are the desk noticing the adjacent problem and dealing with it while it is there.

The rule that keeps this honest is that the small thing must be work, not a token. A tin of biscuits for reception after an outage is a gesture, and people recognise a gesture and discount it. A printer that has been slow for a month and is now fast is a fact, and facts are what reputations are built from. The desk should also resist announcing the small thing in the apology. "While we were there we also fixed the printer" said in passing, a week later, lands. "As a goodwill gesture we have fixed the printer" is a brochure sentence. The brochure is where trust goes to be discounted.

There is a limit, and it is the same limit as every other add-on at a desk-side visit. The small thing is small, it is related, and it does not become a second project. The discipline for what gets done on the spot and what becomes a ticket of its own is in While You're Here, and it applies here unchanged. The point is not to do more work. It is to do the one piece of work the failure revealed, before anyone has to ask.

Remember: the drop in trust is caused by the failure and is the same whatever you do. The climb is caused by the handling. The handling includes notice in minutes, an honest account with an owner, a fix and an all-clear. Then come a follow-up a week later, and one small related thing done without being asked. The last two are the ones that lift the line.

Recovery at the Scale of One Ticket

Most recoveries are not outages. They are the single ticket that went quiet for nine days, or the fix that did not work. Or they are the laptop that arrived without a charger, or the reply that read like a policy. Each of these is a failure for one person, the curve applies to one person, and the five moments scale down without changing shape. The first notice is the reply, today, that says "this went quiet and that was our fault; here is where it stands". The honest account is one sentence. The fix is the fix. The follow-up is a message a week later. The small thing is whatever the ticket revealed on the way.

The one-ticket recovery has an advantage that the outage does not, which is that the whole thing is written down in one place. If you run QuerySolv, a requester's reply to a resolved ticket reopens it with the full history attached. So "it's come back" lands on the record of what was done the first time rather than in a fresh ticket that knows nothing. In that case, an internal note can record the recovery steps for whoever picks it up next. Most tools can be made to work this way, and it is worth checking whether yours does. The recovery steps go in the ticket as internal notes, dated, so that a second technician can see what was promised and when. A recovery nobody can see in the ticket did not happen, as far as the next person is concerned.

The conversation itself, with a person who is frustrated and in front of you, is the subject of Turning a Bad Interaction Into a Recovered One. The brand article defers to it entirely for the words. What the brand article adds is the week after. The person whose ticket went quiet and then got fixed has a story about IT. And the story's last line is written by whether anyone came back. One message, seven days on, asking whether the fix held, changes the last line. (It also catches the fix that did not hold, which is the less romantic reason to send it.)

What Recovery Cannot Do

Recovery lifts the line once. A desk that fails the same way every month and recovers beautifully each time is not building trust. It is building a reputation for apologising well, and people would rather have the appointments system. The curve in the picture rises above the baseline because the failure was an exception, the account was honest and the fix held. If the failure recurs, the second curve starts lower and climbs less. By the third the apology is a form letter however it is written. Recovery is for the failure that happens. Prevention, in the earlier article in this series on making the invisible work visible, is for the failure that does not. No amount of the first replaces the second.

Recovery also cannot promise what the desk does not control. "It will never happen again" is a sentence the desk cannot sign, and the reader knows it. So write what is true: what was changed, what was checked, and what the desk will do if it does recur. A desk that promises only what it can deliver is believed when it delivers. The other kind is believed once.

A Short War Story: The Silent Saturday at Bellweather Logistics

On a Saturday morning at Bellweather Logistics the warehouse scanners stopped talking to the stock system. Dev, the technician on call, found the cause: a certificate on the scanner gateway that had expired overnight. He had it replaced and working inside three hours. He told nobody, because by the time he had finished the warehouse shift was half over and it seemed late to say anything. He went home. The warehouse manager had sent eleven drivers to wait in the yard while his team counted pallets by hand. He had rung the desk's number twice and left messages. His Monday morning sentence to the operations director was "IT didn't even tell us". The three-hour fix, which was fast and correct, counted for nothing against the silence. For the next year every warehouse ticket arrived with a copy to the director. When the same certificate came up for renewal, Dev renewed it a month early. He wrote a note to the warehouse saying so and why. He walked over the following week to ask what else had been slow. The director was taken off the copy line that autumn. A fix without a notice is remembered as an outage without a fix.

The Service Recovery Playbook

The playbook below is Harbourview Clinic's, generalised. The page covers any failure that touched more than one person. It says who does what and by when, from the first five minutes to a week on, and where each step is recorded. Fill in the names and the channels once, and keep it where the on-call person can find it. Use it for the single bad ticket too, scaled down. The record column matters most. A step that has no place to be written down is the step that gets skipped when the next failure arrives in the middle of this one.

SERVICE RECOVERY PLAYBOOK — ONE PAGE
Desk: ______________________   Owner of this page: ______________   Reviewed: ____________

TRIGGER
  Any failure that touched more than one person, or any single ticket that went quiet,
  was fixed wrong, or produced a complaint. Decide in the first five minutes; when in doubt, run it.

WITHIN 5 MINUTES — FIRST NOTICE (before anything is fixed)
  Who sends it: ______________   Where: ______________________ (the channel people already watch)
  Says: what is affected, that we know, that we are on it, when the next update comes.
  Recorded in: the incident record / the ticket, with the time sent.

WITHIN THE HOUR — THE HONEST ACCOUNT
  What happened, in plain words, naming the owner of the cause: ______________________
  Who it affected and how, in their units (patients waiting, orders held, hours lost): ______
  Next update time if not yet fixed: ______

AT THE FIX — THE ALL-CLEAR
  Working since: ______   What to do if it is not: ______________________ (a name and a number)
  Sent by: ______________   Where: ______________________   Recorded: [ ]

WITHIN 2 DAYS — THE ACCOUNT IN WRITING
  Three sentences: what happened, what it cost you, what has changed.  Signed by: ______________
  Sent to: the people affected and their managers.  Linked to the incident review: [ ]

A WEEK ON — THE FOLLOW-UP (scheduled now, with a name)
  Date: ______   By whom: ______________   Ask: "Has anything come back?  What have we not noticed?"
  Anything found becomes a ticket: [ ]   Recorded in the incident record / the ticket: [ ]

THE SMALL THING DONE UNASKED
  The related problem the failure revealed: ______________________________________
  Done by: ______________   On: ______   Mentioned in passing, never as a gesture: [ ]

AFTERWARDS
  What changed so it does not recur the same way: ______________________________________
  Added to the monthly note under "what went wrong": [ ]

Nadia's forty minutes at Harbourview became fifty, because of a second fault behind the first. The all-clear went to reception at 08:58 with a line about calling the desk directly if a booking looked wrong. The written account went to the practice manager on Tuesday, three sentences long, signed. The follow-up the next Monday found the two paper bookings and the slow printer, and the printer was fixed on the spot. A month later the practice manager, introducing a new receptionist to the clinic, described IT as "the ones who come and tell you before you've noticed". The failure had cost the clinic fifty minutes. The handling had bought it a sentence.

Frequently Asked Questions

Does admitting "we made a change that broke it" expose the desk to blame?
It exposes the desk to less blame than silence does, because people assume the worst version of what they are not told. An account with an owner, the effect and the change made is read as competence under pressure. Where a formal review follows, the account and the review should say the same thing, which is another reason to make the account true.
Who should send the first notice if the only technician is busy fixing the fault?
The technician, in one sentence, before starting the fix; it takes less than a minute and buys the time to work undisturbed. On a desk of two or more, the person not fixing it sends the notices and fields the questions. The playbook names both roles in advance so that nobody is deciding this at 08:05.
Is the follow-up a week later really necessary for a small outage?
Yes, and it is cheaper for a small outage than a large one. It takes one message or one walk to the people most affected, asking whether anything came back. It catches the problems nobody raised a ticket for, and it is the step people remember because they did not expect it. Schedule it in the record with a name, or it will not happen.
What counts as a "small thing done unasked", and what does not?
Work the failure revealed, related to it, small enough to do on the spot, and mentioned in passing afterwards if at all. The slow printer noticed during the follow-up counts; a box of biscuits does not; a half-day project does not either, and becomes a ticket. The test is whether it is a fact someone could repeat or a gesture someone would discount.
We have had the same failure three times. Will a good recovery still help?
Less each time, and by the third the apology reads as a form letter however carefully it is written. Run the recovery anyway, because the people affected still need the notice and the account. But put the effort into the fix that stops the recurrence and say in the account exactly what that fix is. Recovery lifts trust once; prevention keeps it.
How do we recover from a single ticket that went quiet for weeks?
Reply today, in the ticket, with the honest account in one sentence and where the ticket stands now. Fix it. Then send a follow-up a week after the fix to ask whether it held. Record each step as an internal note so that anyone else picking up the ticket can see what was promised. The shape is the same as an outage, for one person.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.