Acknowledging Impact Honestly, Whoever Is at Fault

Thursday, 15:20, at Stonebridge Insurance. Tom handles claims, and since Monday the policy system has taken forty seconds to open a record that used to open in two. His e-mail to the desk is short. "I have had to tell four customers today that I cannot see their policy while they wait on the phone. Four. This is making us look incompetent and it is YOUR system." Leila reads it on the desk and knows three things. The policy system had an upgrade on Sunday, the network team changed a firewall rule on Tuesday, and Tom's own workstation is six years old. Any of the three could be the cause. None of them is proved. She has to reply inside the hour. The one sentence she must not write is the one her fingers reach for, which is "we apologise for any inconvenience caused".

Acknowledging impact means stating, in plain words, what the problem is costing the requester, without yet stating who caused it. The two are different kinds of statement. The impact is a fact about Tom's afternoon. He has just handed it to you: four customers, forty seconds each, on the phone, in front of colleagues. The blame is a conclusion about causes, and nobody has it yet. Most of what goes wrong in replies to angry requesters comes from mixing the two. That can mean refusing to acknowledge the impact because the fault is unproven. Or it can mean accepting the fault because acknowledging the impact felt like the same thing. This article is part of our Working With Frustrated Users series. This article is about keeping them apart.

This article covers why impact is a fact and blame is a conclusion, then what to say in each of the three situations. Those are when it is the desk's fault, when it is not, and when nobody knows yet. Next come the apology that is specific and short, and how to acknowledge without admitting things you do not know. We finish with the words that help and the words that hurt, a short war story, and the acknowledgment reply to copy.

Impact Is a Fact, Blame Is a Conclusion

The impact is whatever the requester has told you the problem is doing to their work. It is true the moment they say it. Tom cannot see policies in front of customers. Grace on a clinic front desk has a queue to the door. A dispatcher has forty pallets and no labels. You do not need to investigate any of these to repeat them back; the requester is the authority on their own afternoon. That is what makes the acknowledgment safe to give immediately, before any diagnosis, in the first minute of the conversation covered in The First Sixty Seconds With a Frustrated User. You are not conceding anything. You are proving you read the message.

Blame is a different animal, and it is a conclusion you reach after looking. It answers "who caused this?", and the honest answers are "we did", "someone else did", "the requester did" or "we do not know yet". Each of those changes what you say next, and none of them can be known from the requester's e-mail alone, however certain the e-mail is. Tom wrote "it is YOUR system", and he may be right. The way to find out is to look at what changed on Sunday, Tuesday and on his machine, not to agree because he used capitals. Agreeing with an unproven blame feels kind and is a loan against the desk's credibility, repayable with interest when the cause turns out to be elsewhere.

The separation gives you a sentence you can always write. "You've had to tell four customers today that you can't see their policy, and that has made you look bad in front of them. I can see exactly why you're angry." Nothing in it says who broke what. Everything in it tells Tom that the person replying understood the cost. Then, and only then, the reply moves to what the desk knows about the cause, which is one of three things.

When It Is the Desk's Fault

When the desk caused the problem, say so, plainly and early, in a sentence that names what the desk did. "We missed this. Your ticket sat unassigned for three days, which is our failure, not yours." "The change we made on Sunday night caused this, and we did not test it against your screen." The requester already suspects as much; hearing it from you is a relief rather than a revelation. It removes the need for them to prove it, which is the argument they were gearing up for. A desk that admits its own faults quickly is believed when it says a fault is elsewhere. That is the whole value of candour, and it is considerable.

The desk's fault includes the things the desk owes and did not deliver, not only the things it broke. A missed response target under the service-level agreement (SLA) is the desk's fault even if the fix was hard. A ticket closed as resolved that was not resolved is the desk's fault even if the technician believed it. A promise of an update by three that passed in silence is the desk's fault even if three was busy. These are the cases where the apology is owed. What a missed target teaches the desk is covered in SLA Breaches and What They Teach. Here the point is that owning the miss is the first sentence, not the last.

What follows the admission matters as much as the admission. "We missed this" needs "and here is what I am doing about it now" in the same breath. Otherwise it is a confession with no plan, and the requester is left holding both their problem and your guilt. The shape is: what we did, what it cost you, what happens now, when you hear next. Four short sentences. Resist the urge to explain how the miss happened in detail, because at this point the mechanism is interesting to the desk and not to Tom. If he asks, tell him later, in three sentences, with the fix in place.

When It Is Not the Desk's Fault

When the cause lies elsewhere, acknowledge the impact just as fully and then say what you know about the cause as information rather than defence. The difference is in the order and the tone. "You've lost most of an afternoon to this and you've had customers on the line while it happened. What I've found is that the slowdown started with a firewall change on Tuesday, which the network team made, and I've asked them to look at it as urgent." The requester hears the impact first, then a cause stated as a finding, then that someone is acting. What they do not hear is "it's not us", which, however true, is the sound of a desk stepping back from a problem that is still theirs to carry.

Not the desk's fault does not mean not the desk's problem. The desk is the requester's single point of contact with everything technical. When the cause is the network team, the vendor or the finance department's spreadsheet macro, the desk is still the one who owns the ticket and chases the fix. Say so: "This isn't something I can fix directly, and it is still mine to chase; you'll hear from me, not from them." Handing the requester a name in another team and wishing them luck is not acknowledging the impact; it is moving it. How to escalate to another team without the ticket falling between the two is its own subject, elsewhere in this library.

The hardest version is when the cause is the requester. They deleted the folder, or ignored the warning, or installed the thing. Acknowledge the impact exactly as before, because losing a folder is a bad afternoon whoever lost it. Then state the cause as a fact about the system, not a verdict on the person. "The folder was removed from the shared drive at 14:10 from your account; I can restore it from last night's backup, which means you'll lose today's changes to it." No "you deleted it", no sigh, no lesson. The requester knows. Saying it would only add shame to loss, and shame is what makes people stop raising tickets. The boundary between acknowledging a requester's situation and taking the blame for it, so that the desk stays warm without becoming a doormat, is drawn in Empathy Without Being a Doormat.

When Nobody Knows Yet

Most of the time, when the angry message arrives, nobody knows yet, and this is the situation the acknowledgment was built for. Leila does not know whether Sunday's upgrade, Tuesday's firewall rule or Tom's workstation is slowing the policy system. She can still write a complete, honest reply. It gives the impact in full, the fact that the cause is not yet known, the three things she is checking, and when he hears next. "I don't know yet what's causing it. There were two changes this week that could, and I'm checking both against your machine first. You'll have an answer or an update from me by 16:30." That is not a weak reply. It is the strongest one available, because every word of it is true and will still be true at 16:30.

"I don't know yet" is a sentence many technicians will not write, on the theory that it sounds incompetent. It sounds competent, provided it is followed by what you are doing to find out and when. What sounds incompetent is a confident wrong answer followed two days later by a different confident answer, which is what the alternative produces. Requesters forgive uncertainty that comes with a plan. They do not forgive certainty that turns out to be invented. (I have tried both. The second one is remembered for years.)

When nobody knows yet and many people are affected, the acknowledgment becomes a notice rather than a reply. It needs to go out before the diagnosis for the same reason. People who are affected want to know that someone has seen it, more than they want to know why. The shape of that first notice, and who it goes to, is in The First Notice. For a single requester, the same shape at smaller scale is enough: seen, understood, looking, back to you at a time.

The Apology That Is Specific and Short

An apology is owed when the desk did something or failed to do something it should have, and a good one names the thing. "I'm sorry your ticket sat for three days without a reply." "I'm sorry we closed this as fixed when it wasn't." "I'm sorry I said three o'clock and didn't call." Each is one sentence, each names the act, and each can be checked against the ticket. That is what makes it land. A requester who has been let down wants to know that the desk knows what it did. A specific apology proves it in a way no general one can.

The general apology proves the opposite. "We apologise for any inconvenience this may have caused" apologises for nothing in particular to nobody in particular. The "may have" wonders aloud whether there was any inconvenience at all. It is the apology a form letter makes, and requesters recognise it as one. Every organisation has a version of it, usually approved by someone who was worried about admitting fault and succeeded in admitting nothing. If you find it in your templates, remove it. Replace it with a blank where the specific thing goes, and make the blank impossible to send empty.

Short matters as much as specific. One sentence of apology, then the plan. An apology that runs to a paragraph becomes about the apologiser's feelings rather than the requester's afternoon. A requester with four customers to call back does not have time to make you feel better about your mistake. Say it once, say it precisely, and move to what happens now. If you find yourself apologising a second time in the same reply, you are asking for forgiveness, which is not the requester's job. Their job is to get back to work. Yours is to make that possible.

Acknowledging Without Admitting What You Do Not Know

The fear behind most bad acknowledgments is that acknowledging the impact will be heard as admitting the fault, and the fear is not foolish. A sentence like "I'm sorry the system has been so unreliable" does exactly that. It accepts, on the desk's behalf, that the system is unreliable and that the desk is sorry for it, before anyone has looked. Forwarded to a manager, it becomes IT's admission. The way out is not to acknowledge less but to acknowledge precisely, with the impact in the requester's words and no adjective of your own about the cause.

Compare two sentences. "I'm sorry the policy system has been so slow and unreliable this week." "I can see the policy system has been taking around forty seconds to open a record for you since Monday, and that you've had customers waiting while it did." The first admits unreliability and apologises for it; both are the desk's judgements and neither is yet known to be fair. The second states what Tom reported, with his number in it, and says nothing about the cause or the desk's view of it. It is more specific, more useful and safer, and it reads as more sympathetic, because it shows that the detail was read. Precision is what lets you be warm without being careless.

Before you write any sentence about the cause, look. If you run QuerySolv, the ticket's event history shows every reply, handoff and change with a time against it. So "did the desk drop this?" is a question you can answer in a minute before you write the sentence. It is not a thing you guess at and apologise for in advance. The same minute spent reading the earlier tickets tells you whether this is a repeat the desk closed too early, which is the desk's fault, or a new fault wearing an old ticket's clothes, which is not. Acknowledging honestly is cheap once you have looked. It is impossible if you have not.

Words That Help and Words That Hurt

The table collects the sentences that come up in almost every acknowledgment, with the version that helps and the one that does not. The pattern in the right-hand column is the same throughout: the requester's words, a fact rather than a judgement, and one of three honest positions on the cause. The pattern on the left is also consistent: a judgement, a generality, or a defence wearing an apology's clothes.

"Thank you for your patience" deserves a particular word, because it appears at the end of so many replies to people who have run out of it. Said to a requester on their third ticket, it is heard as a small joke at their expense, and it is not one you meant to make. Replace it with the next time they will hear from you. Patience is easier to find when it has a deadline.

Spoken and Written Acknowledgment

On the phone, acknowledgment is a sentence or two in the gap after the requester finishes, and it is mostly tone. The words matter less than that they come immediately and contain something the requester just said. "Four customers. Right. That's a bad afternoon." Three fragments, and Tom knows he was heard. The temptation on the phone is to keep talking after the acknowledgment, filling the silence with the beginnings of a diagnosis. Stop after the acknowledgment and let it sit for a second. The requester usually fills the silence themselves, with the next useful fact.

In writing, the acknowledgment is the first line of the reply and it carries more weight. That is because there is no tone to soften it and because it will be read more than once, possibly by the requester's manager. That is the argument for precision: write the impact in their words, with their numbers. Write nothing about the cause that you could not defend to that manager. Put the honest position on the cause in the second line and the plan in the third. Keep the whole reply to six lines. The three suspects and your working notes go in an internal note on the ticket, where the next technician needs them and the requester does not.

Whichever channel, the acknowledgment is the beginning of the repair, not the end of it. A perfectly phrased acknowledgment followed by silence is worse than a clumsy one followed by a kept promise, because it raises hope and then confirms the history. What the desk does in the hours and days after the acknowledgment, the follow-through and the follow-up, is the subject of Turning a Bad Interaction Into a Recovered One. The acknowledgment buys you the right to do that work. It does not do it for you.

A Short War Story: The Rent Statements at Ashgrove Housing

At Ashgrove Housing, the quarterly rent statements went out with last quarter's balances on them, and forty housing officers started getting calls from tenants within the hour. Derek ran the desk that morning and had six of the officers in his queue by ten o'clock. He sent a single reply to all of them that began "We sincerely apologise for the system error that caused incorrect statements to be issued." He did that because it was quick, it sounded responsible, and it made the phone stop ringing for about twenty minutes. The cause, found that afternoon, was a spreadsheet macro in the finance team that had been pointed at the previous quarter's export. It had nothing to do with any system the desk ran. By then Derek's sentence had been forwarded to the housing director as IT's admission and quoted in two letters to tenants. Finance had used it as the reason their own fix could wait, since IT was "handling it". It took the desk nine days and a meeting with three directors to unsay one sentence. The corrected statements went out a week later than they needed to because everyone had believed the apology. Derek's desk now has a rule on the wall: acknowledge the impact in the first line, and apologise only for the thing you have looked at.

The Acknowledgment Reply

The reply below is one template with three middles, because the opening and the ending are the same whatever the cause and only the second block changes. Fill the first block from the requester's own message, choose one of the three middles honestly, and complete the ending with a time you will keep. The whole thing should fit in six lines when filled. If it runs longer, you have started explaining, and the explanation belongs in a later message when the requester asks for it.

ACKNOWLEDGMENT REPLY — ONE TEMPLATE, THREE MIDDLES

LINE 1: THE IMPACT, IN THEIR WORDS (always)
  "I've read this. You've ____________________________ (what they said it cost them,
   with their numbers), and ____________________________ (who saw it or who waited)."

LINE 2: THE CAUSE, ONE OF THREE (choose honestly; never guess)

  A. THE DESK'S FAULT
     "We ____________________ (the specific act or miss: sat unassigned for __ days /
      closed this as fixed on ____ when it was not / changed ____ on ____ without
      testing ____). That is our failure. I'm sorry for ____________________."

  B. NOT THE DESK'S FAULT
     "The cause is ____________________ (the fact, stated plainly, without naming the requester).
      It isn't something I can fix directly, and it is still mine to chase."

  C. NOBODY KNOWS YET
     "I don't know yet what is causing it. ____________________ (the one or two
      things that could, and which are being checked) is where I'm starting."

LINE 3: WHAT HAPPENS NOW (always)
  "I'm ____________________ (the next concrete step) now."

LINE 4: WHEN THEY HEAR NEXT (always)
  "You'll have an update from me by ____:____ on ________, whatever I've found."

LINE 5: YOUR NAME and a direct way to reach you.

NOT IN THIS REPLY
  - "any inconvenience"       - "may have caused"        - "thank you for your patience"
  - "probably" or "I think" about the cause
  - adjectives about the system ("unreliable", "flaky", "slow") that are yours, not theirs
  - more than one sentence of apology
  - the mechanism of the fault (save for when they ask; three sentences, later)

INTERNAL NOTE (not sent): the suspects, what you have checked, what is left, the time promised.

Leila chose middle C at 15:40. "I've read this. You've had to tell four customers today that you couldn't see their policy while they waited, and the record has been taking around forty seconds to open since Monday. I don't know yet what's causing it; there were two changes this week that could, and I'm checking both against your machine first. I'm running the same record from a desk machine now. You'll have an update from me by 16:30 whatever I've found." At 16:25 she wrote again: the slowdown was the Tuesday firewall rule, and it affected everyone on Tom's floor. She reported that the network team had reverted it and the record now opened in two seconds. Tom's reply was one line. "Thanks for telling me straight." That is the whole return on honesty, and it compounds.

Frequently Asked Questions