When to Involve Managers, and Which Ones

Tuesday, 16:45, at Bluewater Bank. Marta, who runs the desk, sent Simone, a branch operations manager, the desk's behaviour standard a fortnight ago. She sent it with four dated entries from the pattern log. A line said that Simone's contacts would come through Marta until the end of the month. This afternoon Simone rang Theo directly at his desk, told him Marta had "signed off" a change to the branch's shared mailbox, and asked him to do it before five. Marta had signed off nothing. Theo logged it, said Marta would be in touch, and then came to Marta's desk with a question she had been dreading. Does this go to Kwame, the IT manager, or to Simone's manager, or to HR? And does Theo have to be in the meeting? Marta realised she knew that the standard had been crossed and did not know, in any order she could defend, what happened next.

There are three managers who can be involved in a difficult-user problem, and they do three different jobs. That is the first thing a desk lead needs to know and the thing most leads work out by getting it wrong once. Involving a manager means handing part of the problem to someone with authority the desk does not have. That authority is over the desk's own standard, over the user's conduct, or over the organisation's rules. Each of the three owns one of those, and the order in which they are involved is not a matter of taste. This article is part of our De-escalation & Difficult Users series. It is about which manager, when, with what in hand, and how to keep the technician out of the room while it happens.

It covers the three managers and their three jobs, and the steps between them and what opens each. Next it covers involving your own manager, involving the user's manager, and involving HR. Then comes a table of what each conversation covers and leaves out. Next it covers keeping the technician out of the line of fire, the record, and what to do when a manager says no. It ends with a short war story and the manager escalation note to copy, in that order.

Three Managers, Three Jobs

The IT manager owns the desk, its people and its standard, and is the only one of the three who can decide what the desk does. The IT manager agreed the behaviour standard before it was sent, and applies the consequence when it is crossed. The IT manager takes over a person's contact when the lead cannot, and carries anything upward that the lead cannot carry. Everything the desk does here is done on the IT manager's authority. That is why the IT manager hears about a pattern before anyone outside the department. A desk lead who goes to a user's manager without the IT manager knowing has committed the department to a position the department's own manager has not seen.

The user's manager owns the user's conduct at work and nothing about the desk. They are the only one of the three who can change how the user behaves by asking. Most people who are difficult to a help desk are not difficult to their own manager, who does not know what they are like on the phone to IT. Nobody has ever said. The user's manager can have a conversation that changes things in a week, which no amount of desk process can do. What the user's manager cannot do is tell the desk how to run, which routing to use, or whether a technician should "just take her calls again". That is the IT manager's, and the two are peers in the conversation, not customer and supplier.

HR owns the rules of conduct and any formal step. HR is the only one of the three who can say what the organisation will do about a person. The desk does not know what that is and should not pretend to; it varies by place, by organisation and by contract. HR is involved when the conduct is something HR owns by definition: a threat, a slur, anything that touches a protected characteristic. HR is also involved when the conversation with the user's manager has changed nothing and the organisation's own process is the next step. What HR cannot do is run the desk's response: routing, the named owner and the standard are still the IT manager's, whatever HR decides. (HR will also, in my experience, ask whether this is in the ticket. It should be.)

The Steps Between Them

The three managers are involved in order, each step taken by the person in the step before. The picture below draws the route with the condition that opens each step. The technician owns the ticket and the record and takes no step alone. The desk lead or IT manager is involved when the pattern log reaches three entries, or at once for any abuse. The user's manager is involved when the behaviour standard has been sent in writing and crossed again, or when the user has gone round the desk to complain. The IT manager makes that contact. HR is involved when the user's manager's conversation has changed nothing, or when HR owns the conduct outright. The IT manager takes it there. A red arrow over the top of the first two boxes is the exception. Abuse goes from the technician to the IT manager the same day with no gate, as Abuse Is Not a Ticket sets out.

The gates are the discipline, and the discipline is what makes the later steps work. A user's manager who is told about a pattern before the standard has been sent will reasonably ask why the desk did not say something to the person first. They will be right. HR, asked to act before the user's manager has had a conversation, will send it back to the user's manager. The desk will have spent its credibility on a step it could have skipped. The order looks slow from the desk, where the pattern has run for months. From the organisation's side it is the minimum that shows the desk tried. That is most of what the desk brings to the later conversations.

Involving Your Own Manager

The desk lead involves the IT manager at three points, and all three are earlier than most leads do it. The first is when the pattern log reaches three entries, so that the IT manager knows a name before anything is sent: a two-line message, not a meeting. The second is before the behaviour standard goes to a person, because the IT manager's agreement is what makes the consequence real. That is a ten-minute conversation with the log open. The third is the same day for any abuse, any crossing of a standard already sent, or any person senior enough that the lead should not be the name on the message. A lead who involves the IT manager only when things have gone badly wrong has given the IT manager a crisis instead of a decision.

Bring the record and ask for a decision, not for sympathy. The IT manager needs the pattern log, the standard with the date it was sent, and the entry that crossed it. They also need one question: "the standard says contacts through me and the IT manager speaks to her if it continues; it has continued; will you?" The decision is the IT manager's. The lead's job is to make it easy by proposing it. The article Saying No Upward describes the same approach: sending a decision to its owner with the conditions already drafted. An IT manager handed a log and a drafted next step decides in a minute. The IT manager who is handed "Simone is being impossible again" asks the lead what they recommend, which is the same work done later in a worse mood.

Where the IT manager is the one who agreed the standard, applying its consequence is not a new decision but the completion of an old one. In that case, the lead can say so. "You agreed on the third that if she crossed it you'd speak to her" is a reminder, not a request. Where the IT manager wants to soften the consequence, the lead's honest answer is that a consequence not applied the first time is a bluff. The next standard the desk sends will be read as one. That is the lesson of Setting Boundaries That Hold. Managers can be persuaded of that. Few of them enjoy the sentence.

Involving the User's Manager

The IT manager contacts the user's manager, and the technician never does. The lead does so only where the lead and the manager are genuine peers and the IT manager has agreed. The reason is standing. A conversation about one of their people's conduct, coming from the manager of another department, is a normal conversation between managers. The same conversation from a technician is a complaint from a junior member of staff about a senior one. It will be heard as that whatever its content. Theo was never going to be the one to speak to Simone's manager. Nor, in most organisations, should Marta. Kwame has the conversation, and Marta writes the note that lets him have it in ten minutes.

The conversation covers facts, dates, the standard and what the desk needs, in that order, and it is short. "Simone has had four contacts with the desk since the spring where the behaviour was the issue rather than the fault; here they are with dates. We sent her our behaviour standard on the third, which applies to everyone. On the sixteenth she phoned a technician directly and told him I had approved a change I had not. The desk is handling her tickets at normal speed and will continue to. What I'd like from you is a conversation with her about how she deals with the desk, and I'd like her contacts to come through the desk lead until the end of the month." Nothing in that is an opinion of Simone. Nothing in it asks for a sanction. Everything in it can be checked against the ticket history, which is the point.

The conversation leaves out the technician's feelings, the desk's opinion of the person, any guess at why they behave this way, and any request for a particular outcome. "She's been awful to my team" is a feeling and will be heard as one. "We think she's under pressure" is a guess, and her manager knows more about that than the desk. "She should be disciplined" is HR's, and asking a peer for it ends the peer conversation. The desk asks for a conversation and for the routing, and lets the user's manager decide what else their own person needs. Most user's managers, told plainly and with dates, say some version of "I had no idea", and the behaviour changes within the week. It is the most reliably effective step on the whole ladder, and it is the one desks delay longest.

Two harder cases need a plan. The user's manager who defends the person, disputes the record or explains that the desk is the real problem has heard the facts and declined them. The IT manager says so once, in writing, with the record attached. The IT manager then goes one step up to that manager's manager or to HR, depending on the conduct. The user's manager who is themselves the problem, because the pattern is theirs or because they have been the one going round the desk, is simply the user. In that case, the IT manager has the conversation with their manager instead. In both cases the desk's routing and standard continue unchanged. The desk does not wait for the organisation to agree before protecting its technicians.

Involving HR

HR is involved by the IT manager, with the record, when the conduct is HR's by definition or when the conversation with the user's manager has changed nothing. The desk's part ends at the handover. HR's by definition means a threat, a slur, anything touching a person's background, gender, age, disability or similar, or anything the organisation's own conduct rules name. For those, HR hears about it at the same time as the user's manager, not after, and for a threat the same day. The second route, no change after the manager's conversation, usually arrives a month or two after the standard was sent, when the log shows the same entries continuing.

What the desk brings to HR is the record and nothing else. That is the pattern log, the standard and its date, the incident notes, the dates of each manager conversation and what was asked for. What the desk does not bring is a view on what should happen. What happens is governed by rules the desk does not own and that vary by place, by organisation and by contract. The IT manager should say to the technician, in advance, that HR has been involved and that what HR does is HR's. That way, the technician is not waiting for an outcome the desk cannot promise. A technician told "HR will deal with it" and then nothing has been told a story with no ending, and will fill the ending in.

HR may ask the technician for an account, and the IT manager prepares them for that and sits with them for it if they want. The account is the incident note, read aloud if need be. The technician does not need to add to it, defend it, or characterise the person. The technician's part in any process is to say what happened, which they have already written down. The IT manager's part is to make sure they do not carry it alone. The conversation about what a manager owes the people on a desk in a hard stretch is in The Manager's Responsibilities. This is one of the moments it is written for.

What Each Conversation Covers and Leaves Out

The table below sets the three conversations beside each other: who has it, when, what it covers, what it leaves out, and what the desk is asking for. The "leaves out" column is the one to read twice, because every item in it is something a tired lead will want to say. Every one of them weakens the conversation. The "asks for" column is small on purpose. The desk asks for conversations and for routing. It never asks for a punishment, because the moment it does, it has stopped being a department reporting conduct and started being a party to a dispute.

Keeping the Technician Out of the Line of Fire

The technician is not in the meeting, not on the copy line, not the name on the message to the user's manager, and not the person who takes the user's next call. The IT manager says all four of those things to the technician before the first conversation happens. The technician's part in a difficult-user problem is the factual note, the in-the-moment line, and the one-sentence brief. The management of it is management's. A technician copied on the e-mail to the user's manager is now in a thread the user may one day see. A technician "brought in to give their side" in a meeting is now a party to a dispute between two members of staff. That is what the whole ladder exists to prevent.

The technician is also not asked to make peace. "Could you just have a chat with her and clear the air" is a sentence managers say when they would rather the problem went away than be handled. It asks the person with the least power in the situation to resolve it by being gracious. The reset meeting that repairs a relationship, which is the subject of Repairing the Relationship Afterwards, is run by the lead or the IT manager. It does not require the technician to attend, apologise for anything, or receive an apology they did not ask for. The technician is told the outcome of each step in one line, and is asked whether they are all right. That is the extent of their involvement unless they choose more.

The IT manager absorbs the pushback, which is part of what IT managers are paid for. The user's manager who says the desk is overreacting says it to the IT manager. The director who wants to know why "a junior technician" is "making complaints" is told that the technician made a note and the department made the decision. The user's complaint about the standard is answered by the lead or the IT manager with the record. None of it reaches the technician's desk, and if it does by a side route, the IT manager closes the route. A desk where technicians know the manager will stand in front of them reports patterns early. A desk where they are not sure reports them never, and the pattern becomes a resignation.

The Record

Everything the desk does in a difficult-user problem is in the ticket history and the internal notes before any manager is involved. The record is read, by the person about to take the step, before every step. The pattern log is internal notes and a lead's one-page summary. The standard is a public reply on its own ticket, with its date. The incident notes, if any, are held by the lead. And the manager escalation note at the end of this article is written by the lead for each step. If you run QuerySolv, the internal notes and the event history on each of the person's tickets mean the desk's side of the story is already in one place with timestamps nobody chose. That is the kind of record that survives being questioned. In any tool, the test is whether a stranger could read the record and reconstruct what the desk did, when and why, without asking anyone.

What travels with each step is the ticket numbers and dates, the words as said, the standard and the date it was sent, what the desk has already tried and the result, and what the desk is asking for. What never travels is the technician's opinion of the person, any adjective, the technician in person or on the copy line, any request for a particular punishment, and anything the desk cannot show in the ticket history. That last one is the test for the rest. If the desk cannot point to the ticket, it does not go in the note. The one unsupported line is the one the user's manager will find.

When the Manager Says No

Each of the three managers can decline, and the desk's response to each is the same. The desk records the request and the answer, keeps its own response in place, and protects the technician through routing whether or not anyone above agrees. The IT manager who will not apply the consequence is told, once, in writing, that the lead recommended it and why. The lead then applies the parts of the consequence that are the lead's alone. Those are contacts through the lead, the named owner, and the team brief. The standard has lost some force, but not all, because the routing is real whoever agreed it.

The user's manager who declines is answered with the record, once, and the IT manager goes up a level. If that level also declines, the desk has learned where the organisation's support for its standard stops. HR that finds nothing to be done, which happens, is thanked, and the desk's routing continues. In every case the technician is told honestly: "I asked for a conversation with her manager; he didn't think it was warranted; your contacts with her are still through me and that doesn't change." A technician told the truth about a refusal trusts the desk more than one told a comforting version, which the next phone call will expose. Managers say no. The desk's job is to make sure that when they do, the technician is still not in the person's path.

A Short War Story: The Step That Was Skipped at Kingsmead College

At Kingsmead College, a desk lead called Ruth had a pattern log on a facilities manager called Gordon with five entries, mostly for shouting at technicians in the corridor. After the fifth she took the log straight to HR, without telling the IT manager and without a behaviour standard having been sent. That was because she was tired and HR felt like the serious option. HR read it, found that Gordon had never been told any of it, and passed it to his manager, the estates director. He heard about it from HR before anyone in IT had spoken to him. Feeling ambushed, he defended Gordon in a meeting the IT manager attended without having seen the log. The IT manager spent three weeks repairing the relationship with the estates director. The behaviour standard, when finally sent, was read by Gordon as the desk's revenge for losing the meeting. Ruth's log, which had been accurate on every line, was treated as a grievance file for a year. The cost was a quarter of the IT manager's goodwill with a peer, a standard that arrived too late to be believed, and a lead who stopped keeping logs. The steps exist so that each manager hears about a pattern from the right person, in the right order, with the desk having visibly tried the step before. Skip one and the record stops being evidence and becomes a complaint.

The Manager Escalation Note

The note below is written by the desk lead for each step up the path, one page. It is the thing the IT manager reads before deciding. It is the thing the IT manager takes into the conversation with the user's manager. It is also the thing that goes to HR as the cover sheet for the record. The first section says which step this is and what opened it. The second is the record, as facts with dates, in the order they happened. The third is what the desk has done and is asking for, the only part with room for judgement. The fourth is filled in after the step, with the answer, so that the next note can say what was tried. Nothing in it describes the person. Everything in it points to a ticket.

MANAGER ESCALATION NOTE — ONE PAGE PER STEP
Person: ______________   Department: ______________   Written by: ______________ (desk lead)   Date: ________
Step:  [ ] to the IT manager   [ ] to the person's manager   [ ] to HR
What opened this step:  [ ] three log entries   [ ] standard sent and crossed again
                        [ ] went round the desk   [ ] no change after the manager's conversation
                        [ ] abuse (same day, no gate)   [ ] HR owns the conduct outright

1. THE RECORD (facts, dates, ticket numbers, words as said; no adjectives)
   ______  ticket ______  ______________________________________________
   ______  ticket ______  ______________________________________________
   ______  ticket ______  ______________________________________________
   Behaviour standard sent on ______ by ______  (ticket ______)
   Incident notes held by the lead: ______ (dates)
   Every line above can be shown in the ticket history:  [ ] checked

2. WHAT THE DESK HAS DONE
   Named owner: ______________ since ______      Contacts through the lead since ______
   Service to the person unchanged: same priority, same speed  [ ] confirmed
   Previous steps and their answers: ______________________________________

3. WHAT THE DESK IS ASKING FOR (conversations and routing only; never a sanction)
   [ ] agreement to send the standard        [ ] the consequence in the standard applied
   [ ] a conversation with the person by their manager
   [ ] contacts through the lead until ______
   [ ] the record handed to HR; what follows is HR's
   Technician(s) involved: ______________  Not in the meeting, not copied, not the next contact  [ ]
   Technician told what is happening, by ______, on ______  [ ]

4. THE ANSWER (filled in after the step)
   Decided by: ______________   On: ______   Decision: ______________________________
   If declined: the lead's recommendation recorded in the ticket on ______  [ ]
   Routing continues regardless  [ ]     Technician told the outcome in one line, on ______  [ ]
   Next step, if any, and the date it opens: ______________________________

Marta wrote the note for Kwame that evening, with the four entries, the standard's date, and the call to Theo. It included the one thing she wanted: the conversation the standard had promised. Kwame read it in two minutes on Wednesday morning, and spoke to Simone's manager before lunch. He told Marta afterwards that the manager had said "I had no idea" and would speak to her that day. Theo was told, in one line, that Kwame had spoken to Simone's manager and that her contacts stayed with Marta until the end of the month. He was not in any meeting, was not copied on anything, and did not take another call from Simone that quarter. Her next ticket arrived by e-mail, civil, with a problem in it, which Marta answered in the usual way. The log recorded "no entry" for the first time since spring.

Frequently Asked Questions