De-escalation the Second and Third Time With the Same User

Thursday, 14:05, at Ashgrove Housing. Marcus has a ticket open from Lorraine, a housing officer, about a tenancy application that will not save. He has his hand on the phone. It is her third ticket in six weeks. The first two were handled by two different technicians. Each did a perfectly decent job in the moment. Each ended the call with Lorraine going back over what the previous person had promised. Fen, the desk lead, opened a pattern log after the second one. Marcus has read it, and he knows, before he dials, that the first thing Lorraine will say will not be about the tenancy application. It will be "last time, your colleague told me", and it will be partly true, and he will have no idea which part.

The first time a person is frustrated, the conversation is about the problem. The second and third time, the conversation is about the history. The techniques that handle the first will not handle the second, because the person is not reacting to this ticket. De-escalation the second and third time is the set of changes a desk makes once frustration has become a pattern. They are one named owner for the person, one agreed channel, and a written summary after every contact. They also include a script that stays calm and warm without reopening the last argument. The first conversation itself, the sixty seconds that decide whether a hard call recovers, is already written in the Working With Frustrated Users series. This article leans on it rather than repeating it. This article is part of our De-escalation & Difficult Users series. It is about what the desk does differently once it knows the name.

It covers what changes once it is a pattern, and the named owner for the person. Next come the agreed channel and the written summary after each contact. Then it covers the calm script that does not re-litigate, and the tone that stays warm. Next come the case where the second time is the desk's fault, and a table of what changes from the first contact to the third. It ends with a short war story and the repeat-contact script to copy, in that order.

What Changes Once It Is a Pattern

The first contact with a frustrated person is handled by whoever picks it up, with whatever the moment demands. That is right for a bad day and wrong for a pattern. On a bad day the heat is attached to the fault and leaves with it. In a pattern the heat is attached to the relationship. The relationship, from the person's side, is a series of strangers each promising something slightly different. Every new technician is a fresh chance to be let down and a fresh audience for the story of the last time. The desk cannot fix that by being nicer on the next call. It can only fix it by stopping being a series of strangers.

Three structural changes do that, and the script comes fourth. A named owner is one technician who handles every contact from the person for a stated period. So there is one voice and one memory. An agreed channel is the one route, usually the ticket by e-mail, through which the desk and the person talk. That provides a record and a pause. A written summary after each contact is the short message, sent the same day, that says what was agreed, what happens next and when. That way, the argument about what was said cannot start. None of these is a technique for the call. They are the furniture of the relationship. Once they are in place, the call itself gets easier because less of it is about the past.

The changes are introduced at the second entry in the pattern log, not the third. The second time is when the desk still has the credit to do it kindly. By the third time the person has a story about the desk and the changes look like a response to them, which they are. The person will say so. At the second time the owner can say "I'm going to be your contact for IT things for a while, so that you don't have to explain everything twice". It is a courtesy. The pattern log and the test that says when to open one are in When Frustration Becomes a Pattern; this article starts at the second entry.

A Named Owner for the Person

The named owner is a person, not a ticket assignment, and the distinction matters because tools assign tickets and patterns attach to people. The owner picks up every new ticket the person raises, and takes every call. They read the pattern log before each contact so that nothing the person says about the last time is news. If a fix needs a second-line engineer, the owner stays on the ticket as the person's contact and the engineer works behind them. The person has one name, one voice, and one memory of what was promised, which is the thing they were missing. In tools where ownership is claimed, as it is in QuerySolv, the owner's claim on the person's tickets is visible to the whole desk. In that setup, a colleague who sees the name knows to leave it rather than to be helpful and start the stranger problem again.

Choose the owner for the writing, not for the patience. The owner will send more messages to this person than anyone else on the desk and every one of them will be read closely. So the owner needs to write plainly and warmly under pressure, which is a skill described in Writing Clearly Under Pressure. The owner also needs to be someone who does not take the person home in their head. That is a question to ask them, not to guess. The owner is rarely the newest technician, who has the least standing, and not automatically the most senior, who has the least time. Often it is the desk lead for the first few weeks and a technician after that. The one person it must never be is the technician who was shouted at last time, unless they volunteer, in which case ask twice.

Tell the owner it is a role with a time limit, and tell the desk the same. "You own Lorraine's contacts until the end of next month, and then we review" is a job. "You've got Lorraine now" is a sentence that makes people update their CV. The time limit also protects the person, who should not be on a named-owner arrangement for a year because nobody remembered to review it. And the desk needs to stop the thing it was doing before. On most desks that is a private rota for who answers when the name comes up. That rota is the opposite of a named owner. It spreads the person across everyone, guarantees a stranger each time, and exists so that nobody has to hold the relationship. (It is also, in my experience, the first thing a new desk lead is told about and the last thing anyone admits to running.)

An Agreed Channel

The agreed channel is the route through which the person and the desk talk from now on. For nearly every pattern it is the ticket, by e-mail, with the phone used for the fix and not for the argument. Writing does two things a call cannot. It leaves a record both sides can read, which ends the dispute about what was said before it begins. It also puts a pause between the person's message and the desk's reply, which is where calm comes from. A person who phones at 14:05 gets the technician's first reaction. A person who e-mails at 14:05 gets the technician's reply at 14:40, after the technician has read the log, checked the ticket, and decided what to say. The second reply is better, every time, and so is the second message from the person, who has also had thirty-five minutes.

Say it as a courtesy, and mean it, because it is one. "So that nothing gets lost between us, I'd like to keep everything on the ticket. If you phone, I'll take the call, and I'll confirm what we agreed by e-mail straight after, so you have it in writing." The person has not been refused a phone call. They have been told that every call will be followed by a summary. That is a promise the desk is making to them. Most people hear it that way. The person who insists on phoning gets the call and the summary. The person who walks into the office gets walked back to the desk with "let me log that so it doesn't get lost". That is the hallway move described in The Hallway Request, Handled Well. Then comes the summary.

Do not close channels; route them. A desk that tells a person "you may only contact us by e-mail" has drawn a line that will be crossed in the first week. It has made the crossing the subject. That is a fight nobody wins. Every channel still lands in the same queue, and the owner picks the contact up from whichever door it came through. The channel agreement is about where the conversation lives, which is on the ticket, not about which doors are locked. Most people settle into the ticket on their own once they notice that every call ends up there anyway and the e-mail is faster.

The Written Summary After Each Contact

The written summary is three lines, sent to the person the same day as any contact. It is the single most effective de-escalation tool a desk has for a pattern, because it removes the thing patterns feed on. Line one: what we agreed. Line two: what happens next, and who is doing it. Line three: when you will hear from me, with a time. A fourth line, when needed, says what the desk cannot do, in one sentence and without apology. The summary is sent after every call, every walk-in and every chat, whether or not the contact went well. It is sent by the owner, in the ticket, so that it sits in the history beside everything else.

The summary works because the next argument cannot start. When Lorraine phones in a week and says "your colleague promised it would be fixed by Tuesday", the owner can say "I've got the note from the fourteenth here; we agreed I'd have an answer from the application vendor by Tuesday, and I sent you that answer on Monday". The conversation moves on, because the record is shared and the person has it too. Without the summary, the owner has memory against memory. And memory against memory at a help desk is a dispute the desk never wins. The desk's memory is split across four people and the person's is not.

Write the summary in the warm plain voice the desk uses everywhere else, and make it short enough that it is read. The status updates that prevent the chase are the same idea applied to every ticket; the summary is that idea applied to a relationship. An example, after the call Marcus is about to make: "Lorraine, thanks for the call just now. We agreed: the application form fails to save when the postcode field is empty, and I've reproduced it. Next: I've raised it with the application vendor as their fault and asked for a fix date. You'll hear from me by Monday 16:00 either way, and if you need to save an application before then, leaving a single space in the postcode field works. Marcus." Nothing in it is about the last ticket, and nothing in it can be misremembered.

The Calm Script That Does Not Re-litigate

To re-litigate is to reopen the argument about a previous ticket, who said what and whose fault it was. The pattern conversation is pulled towards it from the first sentence. The person wants to establish the history before discussing the problem, because the history is their evidence that the desk cannot be trusted with the problem. The technician wants to defend the history, because it is their colleagues in it. Both are reasonable, and both lead to a conversation about the fourteenth of last month instead of the tenancy application, which stays broken. The script's job is to acknowledge the history in one sentence and then refuse, warmly, to live there.

The acknowledgement is one sentence, and it concedes what the log says is true. "I've read the last two tickets before calling, and I can see the second one went four days without an update, which shouldn't have happened." Then the turn: "I'm not going to go back over those on this call, because I can't change them. What I can do is own this one, so here is where it is." The person has heard three things. The owner has read the history and is not pretending it did not happen. The desk's failure, where there was one, is admitted. The subject is now the present. Most people accept that turn, because what they wanted was the first two things and the third is a relief.

Three refusals keep the script honest. The owner does not defend colleagues' past work on the call, because "I'm sure she did her best" invites the reply, and the reply is the re-litigation. The owner does not accept blame for everything, because "you're right, we've been terrible" is not true. The person knows it is not true. A person who has just been agreed with on a false claim trusts the agreer less, not more. And the owner does not argue the facts of the last ticket on the phone, even when the person is wrong about them. The record is in writing and the argument is not the subject. Where the person is wrong, the summary afterwards can say, gently and once, what the ticket shows. The call cannot.

When the person goes back to the history a second time, the owner says the turn sentence again, in the same words and the same tone. The owner then offers the history a home. "I can hear that the last ticket still bothers you, and it should have a proper answer. If you'd like, write down what went wrong and I'll pass it to Fen, who runs the desk, so it's looked at separately from this one. On this call, I'd like to get the application saving." The complaint about the past has somewhere to go that is not the present call, and the owner has not refused to hear it. A surprising number of people say "no, it's fine, let's just fix this", because the point was to be offered. Some do write it down, and the lead reads it. The history gets its answer, which is its own kind of de-escalation and the one that lasts.

The Tone That Stays Warm

Warm is not soft, and the difference is the whole art of the repeat contact. Soft gives ground on the problem. It promises faster than the desk can deliver, agrees with claims that are not true, and apologises for things that did not happen. All of that is to lower the temperature on this call at the cost of the next one. Warm gives nothing on the problem and everything on the person. It uses their name, says "we" about the fix, admits what the log admits, and talks about the present in concrete times. The test, which Empathy Without Being a Doormat puts better than I can, is whether the technician would say this sentence to a colleague they like who was having a bad month. "I can see this has been a mess for you, and I've got it now" passes. "I'm so sorry, this is all our fault, I'll get it done today" fails, because none of it is a promise the desk should make.

Certain words cool a conversation on contact, and the owner's summaries and calls should be free of them. "As I said", "again", "as previously explained" and "per my last e-mail" all mean "you were not listening", and the person hears exactly that. "Unfortunately" at the start of a sentence announces bad news before it arrives and makes the reader brace. "Policy" is a wall with a sign on it. The words that keep a conversation warm are small and specific. They include the person's first name, "we", "let's", and a time of day instead of "soon". They also include the name of the thing that is broken rather than "the issue". Tone in the hardest moments, the apology and the bad news, has its own article in Tone in Hard Moments. The repeat contact borrows from it and adds one rule, which is that the tone is the same on the third call as on the first. The person is listening for the moment the desk gets tired of them. Do not provide it.

When the Second Time Is the Desk's Fault

Sometimes the log shows that the second time is not the person's pattern but the desk's. The honest owner says so first. The pattern article asks the desk to check its own part in every ticket in the log before calling anything a pattern. The check sometimes comes back with the desk's name on it. Examples include the update that went out a day late and the fix that was sent as resolved and did not hold. Another is the ticket closed for silence after a question the person never saw. When that is what the log shows, the second contact opens with the specific apology, by date, with the cause, and with what has changed. "The ticket on the fourteenth sat for four days because it was assigned to someone on leave and nobody caught it; that is our fault, we've changed how leave handoffs work, and I've read it all before calling you."

The specific apology does what a general one cannot, and it does it once. A general apology ("sorry for any inconvenience") is noise the person has heard before. A specific one proves the owner has read the history, and concedes exactly what is true and nothing more. It gives the person a reason to believe the next ticket will be different. It does not promise that nothing will ever go wrong again, because that promise will be broken and the breaking will be remembered. It promises that this owner has read the file. And then the owner moves to the present, exactly as in the script. The apology is the acknowledgement sentence with the desk's name in it and the turn still follows. An apology without a turn is just a longer way of staying in the past.

What Changes From the First Contact to the Third

The table below lays the first, second and third contact side by side. It shows what the person usually brings to each, what the desk does, who does it, and what is written down. The second column is the one most desks skip, going from "handle it in the moment" straight to "the lead has a word". The skipped column is where most patterns would have ended. Nothing in the third column replaces the second. By the third contact the owner, the channel and the summary are simply assumed. The only new thing is that the lead reads the log and decides whether a conversation about behaviour, the subject of Setting Boundaries That Hold, is due.

A Short War Story: The Three Promises at Redbrook Engineering

At Redbrook Engineering, a design lead called Dev raised four tickets in two months about a licensing server that dropped his CAD session every few hours. Four different technicians took them, each handling the call well and each ending it with a slightly different promise. These were a fix by Friday, a workaround by Monday, an answer from the vendor "this week", and a new licence "once procurement signs it off". Dev, who was careful by trade, wrote all four down with dates and took the sheet to the engineering director. The director took it to the IT manager. The IT manager spent a Saturday reading the four tickets to work out which of the promises had actually been made. They found that three had, and that none of them had been written to Dev afterwards. The cost was a weekend and a two-hour meeting in which the desk was described as "four people who don't talk to each other". It also cost the desk a design lead who did not raise a ticket for the next year and instead went to the director directly. The desk lead, Aisha, gave Dev a named owner the following week. The owner's first message to him was a summary of all four tickets with the one promise the desk could actually keep. Four good calls with four different promises are worse than one bad call with a summary, because the person is keeping the record whether or not the desk is.

The Repeat-Contact Script

The script below is for the named owner, and it has two halves. One is the call, which the owner reads before dialling and does not read from. The other is the written summary, which is sent within the hour afterwards. The call half is a sequence of five moves with the words that carry each. Change the words to your own voice but keep the order, because the order is the de-escalation. The loop line is said in the same words each time it is needed, which is usually once and occasionally twice. The summary half is the three lines and the optional fourth, with blanks. Keep a filled copy of each summary in the ticket as an internal note as well as the sent reply. That way, the log and the history agree.

THE REPEAT-CONTACT SCRIPT — FOR THE NAMED OWNER
Person: ______________   Ticket: ________   Log entries so far: ____   Owner: ______________
Before dialling: log read [ ]   last summary read [ ]   this ticket's facts checked [ ]

THE CALL — FIVE MOVES, IN ORDER
1. OPEN WITH THE PRESENT
   "Hello ______, it's ______ from IT. I'm calling about ticket ______, the ______."

2. ACKNOWLEDGE THE HISTORY ONCE, IN ONE SENTENCE, CONCEDING ONLY WHAT THE LOG SHOWS
   "I've read the last ____ tickets before calling, and I can see that ______________,
    which shouldn't have happened."
   (If the desk owes an apology: "That was our fault, because ______, and ______ has changed.")

3. THE TURN
   "I'm not going to go back over those on this call, because I can't change them.
    What I can do is own this one. Here is where it is: ______________."

4. THE LOOP LINE (same words, same tone, each time the history comes back; usually once)
   "I can hear the last ticket still bothers you, and it should have a proper answer.
    If you write down what went wrong, I'll pass it to ______, who runs the desk,
    so it's looked at separately. On this call I'd like to get ______ working."

5. CLOSE WITH THE NEXT STEP AND A TIME
   "So: ______________ by ______.  You'll hear from me by ______ either way,
    and I'll send you this in writing in the next hour."

Never on the call: defending a colleague's past work; agreeing with a claim the log
does not support; arguing the facts of a previous ticket; "as I said"; "again";
"unfortunately"; "policy".

THE WRITTEN SUMMARY — SENT WITHIN THE HOUR, ON THE TICKET
   ______, thanks for the call just now.
   We agreed: ______________________________________________.
   Next: ______________ is doing ______________.
   You'll hear from me by ______ (day and time) either way.
   [Optional, one sentence, no apology:] What I can't do is ______________.
   ______ (owner's first name)

   Copied as an internal note: [ ]     Pattern log entry added: [ ]

Marcus made the call at 14:10. Lorraine opened with the colleague who had promised. Marcus said he had read both tickets and that the second had gone four days without an update. He said that was the desk's fault and had been fixed by a change to how leave was covered. He said he would not go back over it, that he owned this one, and that the postcode field was the problem. She went back once; he said the loop line; she said "no, let's just sort this". The summary went out at 14:42. Her next ticket, a month later, arrived with no mention of anyone's colleague. Fen noted this in the log as "no entry", and closed the log a month after that. Most pattern logs end that way, with a page that stops being written on. It is the least dramatic outcome available, and the one the desk should be aiming for.

Frequently Asked Questions