Home › Topics › De-escalation & Difficult Users › Repairing It

Repairing the Relationship With a Difficult User Afterwards

Friday, 10:15, at Acme. Jonah runs the desk, and the review date in Carla's pattern log is today. Carla is a production planner whose log ran from spring to autumn. It had six entries, a behaviour standard in the summer, and the IT manager's conversation with her manager. Then came six weeks of her contacts coming through Jonah. The six weeks have been quiet. Two tickets, both civil, both fixed. Mei, the technician Carla shouted at in June, asked Jonah on Thursday whether Carla was "just normal now, or what", and Jonah had no answer. Then an e-mail arrived from Carla with the subject line "Can we talk?" and one sentence in it: "I'd like to sort things out with your team properly." Jonah has read it four times. He is not sure a meeting is a good idea, and fairly sure that doing nothing is a worse one.

Repair is the deliberate return of a relationship from managed to ordinary. The person goes back to the normal queue, the technicians stop flinching at the name, and the pattern log closes. It is not forgiveness, which is private, and not pretending the pattern never happened, which does not work. It is a short piece of management with a meeting, a named contact, a review date and a decision at the end. Most desks skip it because the consequence ran out and the quiet felt like the end. The quiet is not the end. It is the opening. This article is part of our De-escalation & Difficult Users series. It is the last step on the ladder the series has climbed.

It covers why repair is worth attempting, and the honest limit, then when to attempt it and when not to. Next come the reset meeting, the named contact and the review after a month. Then it covers the user who becomes an ally, when it does not repair and what that means, and measuring repeat conflict without a blacklist. It finishes with a table of the three end states, a short war story and the reset meeting outline to copy.

Why Repair Is Worth Attempting

The person still needs their printer fixed. So the only question is whether that happens inside a relationship that works or one that is managed forever. In a managed relationship, contacts go through the lead and every message is summarised. That protects the technicians and costs the lead time every week for as long as it runs. A repaired relationship costs the lead an hour, once, and then costs nothing. Across a year, a desk with four managed relationships has given a day a month to routing and summaries. That is for people who could mostly have been back in the queue by autumn. Repair is cheaper, and kinder in both directions, and the two reasons point the same way.

Most difficult users are not difficult people, and the pattern log usually says so when read honestly. The chronic complainer started with a ticket the desk mishandled. The queue-jumper learned to jump at a desk where jumping worked. The shouter had never been told. Those are habits formed by circumstance, and they change when the circumstance does. That is what the standard, the manager's conversation and the six quiet weeks have done. The person who arrives at the review date with a civil log has, more often than not, already changed. In those cases, the person is waiting to be told the desk has noticed. Repair is the telling.

The honest limit is that some relationships do not repair, because the desk cannot fix a person. The article says so now so that nobody reads the rest as a promise. A managed relationship that stays managed is an acceptable end state. The desk's job is to attempt the repair once, properly, and measure whether it took, not to keep attempting it until it does. A later section is about what it means when it does not. The attempt is owed. The outcome is not.

When to Attempt It, and When Not To

Repair is attempted after the consequence has been applied and has run its period, never instead of it. The timing is the difference between repair and caving. A reset meeting offered in the week the standard was sent is a desk losing its nerve, and the person will read it as that. One offered at the end of the six weeks the standard named, with a quiet log in hand, is a desk keeping its word and then opening a door. The person will read it as that too. The sequence matters more than the warmth: consequence, period, review, then repair, with the dates in the log to prove it.

Three situations rule it out, or change who does it. Not while a ticket is open and hot. The fault is fixed first and the meeting happens in a calm week, or it becomes a ticket review. After abuse, it happens only if the IT manager leads it, the technician who was abused is nowhere near it, and the person has asked. The desk does not seek out a person who threatened a technician. And Abuse Is Not a Ticket is clear that the technician's exclusion from that person's contacts is not negotiable in any meeting. And not with a person whose manager was the problem until that has been addressed, because the person will go back to the same instructions on Monday.

The best sign is the person asking first, as Carla did. "Can we talk?" means the willingness, which is the hard part, has already happened. Where the person does not ask, the lead offers at the review date in one line: "the arrangement we put in place ends this week; I'd like twenty minutes to agree how things work from here, if you're willing." Some decline, which is itself information. Most accept, and some are visibly relieved. From their side the last three months have been a series of letters from a department they work with every day. Nobody enjoys being managed. (The lead does not enjoy it either, which is worth saying in the meeting.)

The Reset Meeting

The reset meeting is twenty minutes between the desk lead and the person. The person's manager is present only if the person wants. The technician who was on the receiving end is never there. Neutral room, or a call if the person is remote; not the desk and not the person's office. The lead brings the log and does not open it. The purpose is stated in the first sentence and it is forward-looking. It says: "I'd like to agree how the desk and you work from here, so that neither of us has to think about the last few months again." That sentence tells the person the past will not be re-litigated, which they are braced for. It tells them that the lead wants the same outcome they do, which they did not expect.

The meeting covers five things, in order, and the order puts the desk's obligations first. What the desk will do: the response target, the update before a chase, a named person on every ticket, the same for everyone, said as a promise. What the desk needs: contacts through the queue, heat in writing rather than on the phone, the technician on the ticket as the person to talk to. This is said once, kindly, as the other half of the deal. The named contact, for a period. The meeting covers how to raise something genuinely urgent, with the actual words and route, so that the person never again has to shout to be heard. Most reset meetings forget this, and the queue-jumper needs it most. And what happens next: the review date, a month out, and what the lead will look at.

Two things the meeting does not do. It does not re-litigate: the lead does not walk through the six entries. If the person wants to explain them, the lead listens for a minute, says "I understand, and it's behind us", and returns to the five things. And it does not extract an apology, or offer one the desk does not owe. If the person apologises, the lead accepts it in a sentence. If the desk owes one, for a ticket the log shows it mishandled, the lead gives it, specifically and once, as De-escalation the Second and Third Time describes. Apologies traded across a table are a negotiation, and the meeting is not one. The best question, asked near the end, is "what would make the desk work for you?". The answer is usually small, specific and doable by Tuesday.

Remember: repair comes after the consequence has run, never instead of it. The reset meeting looks forward, puts the desk's promises first, never re-litigates, and ends with a named contact and a review date a month out.

The Named Contact

The named contact after a reset is a courtesy the person is offered. The named owner during the pattern was a measure the desk imposed. "For the next month, if you'd rather, send anything to me directly and I'll make sure it's picked up; or just use the queue, whichever you prefer." Most choose the contact for a fortnight and then drift to the queue, because the queue is faster and the contact has shown that the desk is paying attention. The contact is the lead, or a senior technician who was not in the pattern. It is never the technician who was shouted at. The lead tells that technician so before the meeting. That way, Mei is not left wondering whether she is about to be volunteered.

The contact's job is to be the same every time. Pick the contact up within the hour, and say who is handling it and when they will hear. Send the three-line summary after any call. The mechanics are unchanged. The tone is now the desk's ordinary warm voice rather than the careful one. The contact also does something the owner did not: tell the person, once, when a ticket went well. The contact says: "that one was fixed in forty minutes; thanks for the clear description." People managed for three months have heard nothing from the desk but process. One sentence of ordinary appreciation lands harder than it should, and it should.

The contact arrangement ends at the review, and it is ended out loud. "From next week you're back in the normal queue like everyone else; it's been fine, and you don't need me in the middle." The person is not left to work out whether the arrangement has lapsed. The desk is not left running a side channel nobody closed. Side channels nobody ends become permanent, and a permanent side channel for one person is the queue-jumper's pattern reinstalled by the desk itself.

The Review After a Month

The review is a thirty-minute look at the log and the tickets a month after the reset meeting. It answers one question: has the relationship gone back to ordinary? The lead reads the month's tickets and checks five things. First come any new log entries, and of what kind. Next is how each first message reads cold, with the name covered, as the pattern article's test asks. Then comes whether the person used the queue or the contact, and for what. Next is whether any ticket was reopened, and by whom. A reopen is the fastest way back into a pattern and is usually the desk's fault. Last is whether the urgent route was used, and whether it was urgent.

The review asks two people as well as the log. The lead asks the person, in one line, how the month has been from their side, and listens without defending anything. And the lead asks the technicians, including the one who was on the receiving end, whether the name still causes a flinch when it appears. A relationship is not repaired until it is repaired at both ends. A desk whose technicians still dread a name has moved the cost rather than removed it. Mei's answer matters as much as Carla's. Sometimes it is "honestly, she's been fine", and the review is over. Sometimes it is "I'd still rather not take her calls", and the review has found something for the lead to do.

Three outcomes, and the person is told which. Back to normal: the log closes with a date and the contact ends out loud. The person is in the queue like anyone else with nothing any technician sees. Extend: the month was mostly good with one wobble, usually a reopen that was the desk's fault. In that case, the contact runs another month with the same review. Escalate: there are new entries of the old kind, so the arrangement reverts to managed and the log reopens. The ladder in When to Involve Managers, and Which Ones continues from where it was, with the reset meeting dated in the record. Whichever it is, the lead tells the person in a sentence. A review whose outcome the person never hears is another letter from a department.

The User Who Becomes an Ally

A proportion of repaired relationships go further than ordinary. In those cases, the loudest critic the desk had becomes its most useful friend in the business. That surprises desks every time and should not. The chronic complainer cared about something the desk was failing at, and nobody listened. The queue-jumper needed the desk to work and it did not. Once it works, and they have been listened to, the energy that went into complaining goes somewhere. The desk can choose where. The person who knew exactly what was wrong with the desk for two years is best placed to say when it is right, to people who did not believe the desk.

Use it, carefully. Ask them to test the thing that used to break for them, before anyone else, because they will notice what others miss. Ask them to read the portal text and say where it is unclear, since they are the reader it was failing. Ask whether they would be the desk's contact in their department for a change that is coming. None of these is a reward for having shouted: the ally is still in the normal queue. The first time a request from them is treated as urgent because of who they are, the desk has rebuilt the side door it spent a year closing. The ally gets listened to. They do not get a shortcut, and genuine allies understand that better than anyone, because the shortcut was what they used to be angry about.

When It Does Not Repair, and What That Means

When the review finds the old entries back, the failure means one of three things, and the lead works out which before deciding anything. The first is that the desk is still failing the person in the specific way the pattern was always about, and the reset meeting did not find it. The check is to read the month's tickets with the desk's own part in mind, as the pattern article asks. Look for the reopen, the late update, the thing that still does not work. If so, the failure and the fix are the desk's, and the repair is attempted again once it is fixed. This is the commonest reason a repair fails, and the only one the desk can address alone.

The second is that the person's manager is the problem. The person is told to get results from the desk by whatever means, and no agreement with the lead survives the Monday meeting with their manager. The log shows this as a pattern that stops when the person is spoken to and starts again a week later, every time. The fix is above the desk, in the IT manager's conversation with that manager, and until then the relationship stays managed. The third is that the person will not change. The log shows that as a pattern nothing has touched: not the standard, not the manager's conversation, not the reset. The desk cannot fix a person. It can protect its technicians by keeping the relationship managed, and say so plainly to the IT manager. That way, the next step is taken by the people whose step it is.

The managed relationship is a legitimate end state, and the lead should stop treating it as a failure once it is reached. Contacts go through the lead, with a summary after every call, normal service, and the technicians out of the person's path. That costs the lead a little time each week and the technicians nothing, which is the point. It is reviewed each quarter in case something has changed, and recorded as "managed, reviewed on" with a date. Some people are difficult to a help desk for reasons it will never know. The desk's job with them is not to repair the relationship but to make sure it is not their technicians' problem.

Measuring Repeat Conflict Without a Blacklist

The desk measures repeat conflict by counting events and outcomes, never by keeping a list of people. The difference decides whether the measure is management or surveillance. A blacklist is a list of requesters with a conclusion attached, kept so that the desk treats them differently. It is the thing every tired desk wants and no fair desk keeps. There is no "difficult" flag on a requester's record, and no marker a technician sees when the name comes up. There is no archive of closed logs shown to a new technician as a warning. A closed log is closed. The person is a requester like any other. The desk's memory of the pattern lives in the lead's dated file, nowhere a technician would see it before answering the phone.

What the desk counts is logs and their outcomes, quarterly. Here is a worked example from a desk like Jonah's. Eleven logs opened in a year, of which six closed at the second-time stage with no further entries. Two reached a standard and then repaired. One reached the IT manager's conversation and then repaired. One is managed, and one is at HR. Beside those counts sit the measures that keep them honest. One is the reopen rate on the tickets in those logs. A high reopen rate among difficult users means the desk is causing some of the difficulty. The other is the satisfaction scores on the same tickets, read with the care that Satisfaction by Category and, Carefully, by Agent asks for. If you run QuerySolv, the reports on reopen and escalation rates and the per-technician reports give the lead those figures without a separate spreadsheet. The per-technician view is read as that article says: for coaching, never as a ranking.

The per-technician cut needs more care here than anywhere, because the numbers are small. A technician who appears in four of the eleven logs may be the one who takes the hardest calls or the one with the shortest fuse. Or they may be the one who was on the phones the week the scanners broke. The count cannot say which. Read the tickets before concluding anything. Never read a per-person figure from a handful of logs. Treat whatever the reading shows as a coaching conversation, which the soft-skills series is for, never as a score. The count that matters most is the simplest: how many logs closed as repaired, and how many stayed closed. That is the desk's measure of whether this series worked, and the one to put in front of the IT manager once a year.

The Three End States

The table below sets the three end states beside each other. It shows what each looks like in the log and the tickets, what the desk does, what the record says, and when it is reviewed. Repaired is the aim and managed is acceptable. Escalated is not a failure but a step that belongs to the people above the desk. Every item in the "what the desk does" column is a routing or a record rather than a judgement. That is what makes it defensible to the IT manager, to HR and to the person. The desk decides how it talks to people. It does not decide what they are.

End stateWhat it looks likeWhat the desk doesWhat the record saysReviewed
RepairedA month with no log entries; civil first messages; the queue used; technicians report no flinch at the nameEnds the named contact out loud; closes the log; returns the person to the normal queue with nothing visible to technicians"Closed, repaired" with the date; the lead's file keeps it in case the pattern returnsNot again, unless a new log is opened
ManagedEntries continue after the reset, or the person's manager is the cause, or abuse rules repair outContacts through the lead; summary after every call; normal service; the technicians out of the person's path"Managed, reviewed on" with each quarter's date and the reasonQuarterly, for any change above the desk
EscalatedThe old entries return and the manager's conversation changed nothing, or the conduct is HR's outrightKeeps the managed routing; hands the record up the ladder; tells the technicians honestly where it standsThe manager escalation note for each step, with the reset meeting and review dated in itAt each step, by the person taking it

A Short War Story: The Date That Passed at Westbrook Dental

At Westbrook Dental, a practice manager called Irene had a pattern log that reached the behaviour standard. It reached a six-week period of contacts through the desk lead, Omar. When the six weeks ended Omar simply stopped routing, told nobody, held no meeting and set no review. The period had been quiet and he had a backlog. Irene's next ticket went, by the normal queue, to Leon, the technician she had shouted at in the spring. He had not been told anything had changed and replied in the careful, cold register he had used since June. Irene read the coldness as the desk still holding a grudge, said so in her reply, and copied the practice's clinical director. The log reopened at entry seven. The IT manager had the conversation with Irene's manager a second time, without the credibility of a desk that had finished what it started. Leon asked to move to the infrastructure team at the next review, citing nothing in particular. The cost was the whole ladder climbed twice and a second manager conversation that went worse than the first. It also cost the desk a technician, lost to a team that did not answer phones. The end of a consequence is a decision and a conversation, not a date passing. A quiet six weeks that nobody closes is a relationship that nobody repaired.

The Reset Meeting Outline

The outline below is the lead's one page for the reset meeting, read before and filled in after. It is kept with the log. The top block is the preparation. It covers the dates that prove the sequence was kept, and the check that the technician knows who the contact will be. The middle block is the five things the meeting covers, in order, with the words that open each, in the lead's own voice, in that order. The bottom block is filled in afterwards: the contact, the urgent route, the review date and, a month later, the outcome. A filled outline is the record that the repair was attempted properly, which is what the desk owes whether or not it took.

THE RESET MEETING OUTLINE — ONE PAGE
Person: ______________   Department: ______________   Lead: ______________   Meeting date: ________
Not attending: the technician(s) in the log  [ ] confirmed and told the contact will be ______

BEFORE THE MEETING (the sequence, with dates)
  Standard sent: ______   Consequence period: ______ to ______   Manager conversation: ______
  Log entries during the period: ____   Open tickets today: ____ (none hot:  [ ] )

THE MEETING — FIVE THINGS, IN ORDER (twenty minutes)
  Opening: "I'd like to agree how the desk and you work from here, so neither of us has to
            think about the last few months again."
  1. What the desk will do:  reply within ______;  an update before you need to chase;
                             a named person on every ticket;  the same for everyone.
  2. What the desk needs:    contacts through the queue;  heat in writing, not on the phone;
                             the technician on the ticket is the person to talk to.
  3. The named contact:      "For the next month, if you'd rather, send anything to ______
                             and they'll make sure it's picked up; or just use the queue."
  4. The urgent route:       "If something genuinely can't wait, ______ (the words and the
                             route), and it will be treated as urgent on its merits."
  5. What happens next:      "I'll look at how the month has gone on ______ and tell you."
  The question near the end: "What would make the desk work for you?"  Answer: ______________
  Not in this meeting: walking through the log; apologies traded; any open ticket.
  If the desk owes an apology for a specific ticket: given once, by date: ______

AFTER THE MEETING
  Named contact: ______________  until ______   Urgent route given: ______________
  The technician(s) told the outcome, in one line, by ______ on ______  [ ]
  Review date: ______  Review covers: log entries; first messages read cold; queue or contact used;
                       reopens and by whom; the urgent route; the person's and the technicians' view
  OUTCOME (filled in at the review):  repaired / extended to ______ / managed / escalated
  Person told the outcome on: ______   Log closed on: ______  or  next review: ______

Jonah met Carla on the Tuesday, in a meeting room neither of them used, for eighteen minutes. He opened with the sentence, put the desk's promises first, and did not open the log. She explained the June call anyway, for about a minute. He said it was behind them and asked what would make the desk work for her. She said she had never known how to say something was urgent without it sounding like shouting. So he gave her the words and the route. She used Jonah as the contact twice in the first fortnight and the queue after that. At the review, Mei said Carla had been "honestly fine", and the log closed on the Friday with a date. Carla tested the new planning module the following spring, before anyone else, and found three things wrong with it, in writing, politely. That was the most useful thing anyone at Acme did for the desk that year.

Frequently Asked Questions

Should the technician who was shouted at be in the reset meeting if they want to be?
The default is no, and the lead should not encourage it. The meeting is a management conversation. The technician's presence turns it into a reconciliation between two people, which is not the desk's to stage. If the technician genuinely wants to be there and the person agrees, the lead can allow it. In that case, the lead runs the meeting and the technician is free to leave at any point. Nobody is ever asked to attend, and declining is never noticed.
The person apologised to the technician directly, unprompted. Is that the repair?
It is a good sign and it is recorded as a fact with its date. The technician decides how to receive it without any pressure from the lead. The apology does not replace the reset meeting, the named contact or the review. Those are about how the desk and the person work from now on, not about the June call. A sincere apology and a quiet month together are what a review usually finds when it closes a log as repaired.
What if the person refuses the meeting?
The lead notes the offer and the refusal with dates, and ends the consequence period as the standard promised. The lead returns the person to the normal queue with the technicians briefed that nothing more is planned. The relationship is then ordinary by default, and the next ticket is the review. If the old entries return, the log reopens and the ladder continues. If they do not, the log closes a month later as repaired, meeting or no meeting. The offer is what the desk owed.
How do we stop a closed log from following the person around?
Keep it out of anywhere a technician looks when a ticket arrives. There is no flag on the requester, no note on their record, no mention in the team brief once it closes. The lead's file keeps the closed log with its dates, and the lead opens it only if a new pattern appears, when the history is relevant. A new technician learns nothing about the person except what the current tickets show, which is how it should be for every requester.
Can a managed relationship ever be repaired later?
Yes, and the quarterly review is where the lead looks for the reason to try. That could be a change of manager, a change of role, a long run of quiet entries, or the person asking. The same sequence applies, with a reset meeting, a contact and a review, and the earlier attempt and its outcome in the record. Some relationships repair on the second attempt because the thing that was preventing it, usually the person's manager or a fault the desk had not found, has gone.
What do we report upward about difficult users, and how often?
Report once a year, or when asked. Include the number of logs opened, how many closed at each stage, how many repaired and stayed repaired, and how many are managed. Include the reopen rate on those tickets beside the desk's overall rate. No names, ever, in anything that goes above the IT manager, and no per-technician figures. The point of the report is to show the ladder works and where the desk's own faults contributed, not to list people.

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.