Home › Topics › De-escalation & Difficult Users › Abuse

Abuse Is Not a Ticket: Ending the Call and Reporting It

Wednesday, 13:20, at Bellweather Logistics. Ewa has been on the desk for eight months and is on the phone with Dominic, a depot supervisor, about handheld scanners that have stopped syncing. For the first two minutes he is angry about the scanners, which is fair; the depot cannot dispatch without them. Then the subject changes. He says something about her accent, then something about "people like you". Then he says that he knows where the IT office is and might come and explain it in person. Ewa says the sentence the desk agreed for this. She says that she will keep working on the scanners, will not be spoken to like that, and will end the call if it continues. He continues. She ends the call. She sits for a moment with her hand still on the phone. Hannah, the desk lead, is at lunch. The scanner ticket is still open. Ewa is not sure whether she was allowed to do what she just did.

She was, and the purpose of this article is to make sure that nobody on a desk is ever unsure of it again. Abuse, at a help desk, is an attack on the technician as a person rather than anger about a situation. That means insults about who they are, slurs, threats of any kind, or a personal attack that continues after it has been calmly named. It is not a ticket. It does not go in the queue, it has no priority, and it is not resolved by fixing the scanners. The moment itself, the sentence the technician says and the ending of the call, is handled in Staying Professional Under Fire and is not repeated here. This article is part of our De-escalation & Difficult Users series. It is about everything the desk does around that moment: the right that backs it, the ticket, and the report the same day. It covers the support the technician gets, and the statement that the desk does not tolerate this.

It covers the line between rude and abusive, then why abuse is not a ticket. Next comes the technician's right to end the contact, and how it is done on each channel. What happens to the ticket, the report to the manager the same day, and the support the technician gets afterwards follow. Next come no tolerance, stated plainly, abuse in writing, and a pattern of abuse. A table of the three side by side, a short war story, and the abuse incident note to copy follow, in that order.

The Line Between Rude and Abusive

Anger is about the situation. Rudeness is about the technician but stops when named. Abuse is about the technician and does not stop, or is a threat or a slur, which needs no naming first. The desk absorbs anger: shouting about three days of broken scanners, swearing about the system, "what do you people do all day". The desk names rudeness once, calmly, and most people stop. The desk ends abuse. The test is the subject of the sentence. "This desk is useless" is anger. "You are useless" is rudeness, and is named. "People like you", a threat to come to the office, a slur, or "you are useless" repeated after being named, is abuse, and the contact ends.

The line is written down in advance because a technician being attacked cannot judge where it sits. A person who has just been told that people like them should not be in the job cannot weigh whether that counts, and should not have to. So the desk writes the line down, agrees it with the IT manager, and every technician reads it before they take a call. Then the technician on the phone is applying a rule, not making a judgement about their own sensitivity. The behaviour standard that carries the line for ordinary conduct is the subject of Setting Boundaries That Hold. Abuse sits above that standard and is handled differently. That is what the rest of this article is about.

Two things are not abuse. Volume is not; some people are loud when they are frightened for their job. Swearing about a situation is not. A desk that ends calls for either will end calls with people who need help most and will lose the standing it needs when a real case arrives.

Why Abuse Is Not a Ticket

A ticket is a record of a fault and the work to fix it. Abuse is a record of conduct. The two must not be mixed. If the abuse is written into the scanner ticket as a public reply, whoever later reads the ticket sees a dispute instead of a fault. In that case, the technician's words become part of a conversation with the person who abused them. If the abuse is treated as the ticket, it gets a priority, a target and a resolution, none of which make sense. Abuse is not resolved; it is reported. The scanner ticket continues as a ticket. The abuse becomes an incident note. That is a different record, written by the technician, read by the manager, and kept where the requester cannot see it.

Two things are therefore happening after the call ends, and they are separate. The fault is still being fixed, at the normal speed, by the desk. The incident is being reported, the same day, to the manager. The technician does both, in that order, and then stops. What happens to the person is not the technician's to decide, nor to carry. The desk reports; it does not adjudicate. The decisions that follow, which managers are involved and in what order, are the subject of When to Involve Managers, and Which Ones.

The Technician's Right to End the Contact

Every technician has the right to end any contact that becomes abusive. That right is written down in the desk's own standards, signed by the IT manager. Every technician reads it before their first week is out. The signature means the manager has said in advance that a technician who ends an abusive call will not be asked to justify it. The technician will not be criticised for it, and will be backed if the person complains. The reading means nobody discovers the right by needing it. Ewa should not have been unsure. The right existed at Bellweather; it had never been written down, and so in the moment she had only her own judgement to rely on.

The right means three things in practice. The technician does not need permission; the right is theirs. The technician does not need to justify the decision in the moment; the factual note afterwards is the only account they owe. And the technician faces no consequence for ending a contact in good faith, even where the manager would have drawn the line a little differently. A technician who ends a call that was merely rude has made a small, forgivable error. A technician who stays on a call that was abusive because they were not sure they were allowed to leave has been failed by the desk.

How the contact is ended depends on the channel, and the sentence itself is in the frustrated-users article linked above. On the phone, it is one sentence and the receiver goes down. On chat, it is one line and the conversation is closed. In person, the technician stands, says the sentence, and leaves the area, or asks the person to leave if the technician is at their own desk. Where there is any threat, the technician does not stay to find out whether it is serious. In that case, the organisation's own security arrangements are used. By e-mail, the technician does not reply at all; the message is forwarded to the lead and the technician's part is finished. In every case the technician keeps the promise about the work: the scanners will still be fixed, and the person will be told so, by someone, in writing.

Remember: a technician may end any contact that becomes abusive, without permission, without justifying it in the moment, and without consequence. The work continues at normal speed through a different person, and the incident is reported to the manager the same day.

What Happens to the Ticket

The ticket is fixed at the same speed as it would have been. This is not generosity to the person; it is what protects the technician and the desk. A fix delayed after an abusive call will be read as retaliation, and the desk's position, which was clean, becomes an argument about service. The scanners were needed by the depot, which had done nothing wrong, and the ticket's priority was set by the depot's need. The desk's strength in what follows is that its own conduct was faultless, and the ticket is where that is proven.

The ticket changes hands. The technician who was abused does not take the person's next contact. The ticket's ownership passes to the desk lead or to a colleague the lead chooses, that afternoon. The requester is told, in writing, in one neutral sentence from the lead: "Hannah here from IT; I've taken over the scanner ticket and will have an update for you by 16:00." The person's next contact, by any channel, goes to the lead. The ticket notes and the incident note are the handover; the technician is not asked for a conversation.

The public history of the ticket stays about the fault. The words said do not go in a public reply, which the requester reads and which becomes a continuation of the conversation. The ticket carries one factual line visible to the desk, and the detail goes in the incident note. In tools that separate public replies from internal notes, as QuerySolv does, the internal note records that the call was ended and why. There the technician records it in a form the requester never sees. In any tool, the public side should show a fault being fixed and the desk's side a factual record of what happened and who was told.

The Report to the Manager the Same Day

The technician reports the incident to the desk lead the same day, before going home. The lead reports it to the IT manager the same day as well. The report has two parts. First is a short conversation, in person or by message, in which the technician says what happened in a few sentences. Second is the incident note, written while the words are fresh, which is the record. The conversation comes first, because the technician should not be alone with it for an afternoon. The note comes second, because it needs the technician to be a little calmer than they were at 13:22. Where the lead is out, the technician tells whoever is senior on the desk and writes the note.

Same day is the rule for three reasons. Memory of exact words fades within hours, and the words are the evidence. A note written the next morning says "he was abusive" where a note written at 14:00 says what he said. The technician should not carry an abusive call home as something not yet dealt with. The report is how the desk takes it from them. And a conversation with the person's manager a fortnight later is a weaker conversation than one the next morning.

The manager's part on receiving the report is fixed, and the first item is the most important. The manager asks whether the technician is all right, and means it, before asking anything else. The manager reads the incident note and does not edit it. The manager tells the technician they did the right thing, in those words. The manager takes over the contact with the person. And the manager decides, that day or the next, whether the person's manager and HR are told, which for a threat or a slur is yes. What the manager never does is ask what the technician said to provoke it. Nothing a technician says on a support call provokes abuse. The question, once asked, teaches every technician on the desk not to report the next one.

The Support the Technician Gets Afterwards

The technician comes off the queue for as long as they need that afternoon, and the lead says so rather than waiting to be asked. Some people want to go straight back to work, and may. Some want an hour. Some want the rest of the day, and get it without a form. The next ticket should not be answered by someone still shaking from the last call. The technician takes no further contact from the person, on any channel, and in most cases that is permanent. The person has one route to the desk from now on, and it is the lead.

The lead checks in a few days later, briefly and privately, and again a few weeks on. That is because the effect of an abusive call is not always felt on the day. Some technicians are fine; some find that the next loud caller, who is only angry, lands harder than it should. The lead's job is to notice, to ask, and to adjust the technician's load without making a performance of it. The way a desk recovers from any bad stretch is in Recovery After a Bad Stretch. The manager's responsibilities for the people on the desk, of which this is one of the sharpest, are in The Manager's Responsibilities.

Where there was a threat, the organisation's own arrangements for the safety of its staff apply, and the IT manager makes sure they are used. The desk does not assess whether a threat was meant. Where the technician is affected beyond what a few days settle, the organisation's support programme, if it has one, or the technician's own doctor, are the right places. In that case, the lead can say so plainly without offering anything more specific. The technician decides how much to talk about it and to whom. What the desk owes them is to have taken the incident seriously and reported it the same day. What the desk also owes them is to have removed the person from their path and asked, more than once, whether they are all right.

The record is the technician's protection, and the lead should say that too. Technicians sometimes hesitate to write the note because it feels like making a fuss. It is the opposite. It is the one thing that ensures the account of what happened is theirs, in their words, written at the time. It is not a reconstruction made later by people who were not on the call.

No Tolerance, Stated Plainly

The desk's position on abuse is a short written statement, signed by the IT manager, seen by HR, and visible to the people the desk supports. It says what abuse is, in the plain terms above, and that any technician may end a contact that becomes abusive. It says that the work will continue through another person at the same speed. It says that every incident is reported to the IT manager the same day. And it says that the IT manager will raise it with the person's manager and, where the conduct warrants it, with HR. It is three or four sentences, not a legal document, and it promises no particular outcome for the person, because that is not the desk's to promise.

HR sees the statement before it is used and says whether it fits the organisation's own rules of conduct. It should, since most organisations already require colleagues to treat each other without abuse. HR owns the rules. What happens to a person after a report, whether there is a formal step and what it is, varies by place, by organisation and by contract. The desk does not describe it, predict it or promise it to the technician. The desk's statement ends at the report. The IT manager may tell the technician afterwards what was done, where appropriate; the technician should not be made to carry the detail.

The statement applies to everyone, including people senior to the IT manager. That is the sentence to settle before it is published. A director who threatens a technician has done the same thing as a depot supervisor who does. The technician's right to end the contact is identical. What differs is who has the conversation afterwards: the IT manager, with the director or the director's own manager, that week. The way a technician declines a senior person's request is in Saying No Upward. Abuse is not a request, and its upward route is the IT manager carrying the report, not the technician carrying the conversation. If the organisation will not back the statement upward, the IT manager should know before a technician relies on it. In that case, the manager should say so to the desk rather than publish a statement the organisation will not hold.

Abuse in Writing

Abuse arrives by e-mail, by chat and through the web form as well as by phone. The written form is both easier to prove and easier to ignore. It is easier to prove because the words are there, and easier to ignore because there is no voice and no immediate fear. A technician reading an abusive e-mail at 09:10 can simply get on with the day, which many do, and which the desk should not let them do alone. A written attack on a technician as a person is reported in the same way as a spoken one, the same day, with the message attached to the incident note rather than quoted from memory.

The technician does not reply. Not to defend themselves, not to name the line, not to say the ticket continues. Any reply from the technician to an abusive message becomes a conversation with the person, and the person's next message will be addressed to it. The message is forwarded to the lead, and the ticket is handed over. The lead replies once, briefly, from the lead's own name. The reply says that the ticket has been taken over and will continue, and that the message has been noted. It says that any further contact should come to the lead. The lead does not quote the message back, characterise it, or invite a discussion of it. The message is kept exactly as received, in the incident note and in the ticket's internal record, and nothing is deleted. On chat, the technician closes the conversation with one line, does not reopen it however many messages follow, and saves the transcript whole. The lead takes the conversation over where the tool allows it and contacts the person by e-mail where it does not.

A Pattern of Abuse

One incident is reported and handled as above. A second incident from the same person, however far apart, is a pattern of abuse. The IT manager raises it with the person's manager and with HR at once, without waiting for a third. The pattern log described in When Frustration Becomes a Pattern is for conduct short of abuse, managed with a named owner, a channel and a standard. Abuse is logged there too so the history is complete, but it is not managed by those steps. There is no named-owner stage for a person who has threatened a technician and no standard to send. The first incident was reported above the desk, and the second goes further up on the day it happens.

From the first incident onward, the person's contact with the desk runs through the lead, and the technician who was abused is never put back in their path. Where the person's manager asks the desk to "put it behind us", the IT manager may restore normal routing for the person after a period. But the technician's exclusion from that person's contacts is not the person's manager's to negotiate. The desk will keep fixing the depot's scanners; who answers the phone when the depot supervisor calls is the desk's decision, and it has been made.

Anger, Rudeness and Abuse Side by Side

The table below puts the three side by side, with what each sounds like and what the technician does. It shows what the desk does afterwards, who is told, and where the record lives. The first two rows belong to the frustrated-users series and the boundaries article and are here for contrast; the third is this article. The difference is not how unpleasant the contact was but whether the words were about the situation, about the technician but stopped, or about the technician and did not.

What you hearWhat it isWhat the technician doesWhat the desk does afterWho is toldWhere it is recorded
Shouting about the outage, the desk or the history; swearing about the system; capitals; a manager copied inAngerPause, acknowledge the impact, one question, next step and a time; keep helpingFix the fault; check its own part in the historyNobody, unless it becomes a patternThe ticket, as normal; a factual note if notable
"You're useless"; remarks about the technician's competence or age; stops when calmly namedRudenessOne calm sentence naming it; keep helping; if it continues, end the call and continue in writingPattern log entry; named owner and summary if repeated; behaviour standard if it becomes a patternThe lead, that dayInternal note on the ticket; the pattern log
A slur; a threat of any kind; remarks about who the technician is; a personal attack that continues after being namedAbuseEnd the contact in one sentence, no warning needed for a threat or a slur; never reply in writing; the work continues through someone elseTicket handed to the lead at normal speed; contacts routed through the lead; technician off the queue as needed and never again in the person's pathThe lead and the IT manager the same day; the person's manager and HR as the IT manager decides, always for a threat or slurOne factual internal line on the ticket; the incident note, held by the lead, with the message or transcript attached

A Short War Story: The Question That Was Asked at Castlebridge Council

At Castlebridge Council, a technician called Femi ended a call with a parks officer called Trevor. Trevor had moved from shouting about a broken tablet to remarks about Femi's background and a promise to "sort him out" in the car park. Femi told his manager, Gail, within the hour. Gail's first question was what Femi had said to set him off, and her second was whether he had misheard. Femi, who had not, said it was probably nothing and went back to the queue. He took Trevor's calls for the next seven months, because nobody had changed the routing and he did not want to raise it again. He left the following spring with an exit note that mentioned "the culture on the desk" and nothing more. When his replacement reported Trevor a year later, the IT manager read the old tickets. The manager found that two other technicians had each ended a call with Trevor in the same period. Neither had reported it, because both had heard what Gail asked Femi. The council lost three years of trained desk staff to one unreported pattern. Trevor's manager, when finally told, said she had had no idea. A manager's first question after a report of abuse decides whether the desk ever reports one again.

The Abuse Incident Note

The note below is written by the technician the same day, after they have told the lead and before they go home. It is kept by the lead with any message or transcript attached. The first block is the facts, as a log, with the words said recorded as closely as memory allows and nothing added. The second is what the desk did, which is the technician's protection. The third is the manager's part, filled in by the lead and the IT manager with dates. The note is not shown to the person and is not attached to the ticket's public history. Keep adjectives out of it; "abusive" is the manager's conclusion to reach from the words.

ABUSE INCIDENT NOTE — ONE PAGE, WRITTEN THE SAME DAY
Technician: ______________   Date: ________   Time of contact: ______   Channel: phone / chat / in person / e-mail / form
Person: ______________   Department: ______________   Ticket(s) open at the time: ________

1. WHAT HAPPENED (facts only, in order, as a log)
   What the contact was about: ______________________________________________
   What was said or done, as close to the words as possible:
     ____________________________________________________________________
     ____________________________________________________________________
   Was the line named? yes / no   The words used to name it: ______________________
   Did it continue after being named? yes / no   Was there a threat or a slur? yes / no
   The contact was ended at: ______   How: ______________________________
   Message or transcript attached: yes / no / not applicable

2. WHAT THE DESK DID
   The work continues: ticket ______ handed to ______________ at ______
   The person told, in writing, by ______________ that the ticket continues: yes / no
   The person's contacts now route through: ______________   From: ______
   Technician off the queue from ______ to ______ (technician's choice)
   Reported to the desk lead at: ______   To the IT manager at: ______

3. THE MANAGER'S PART (completed by the lead and the IT manager)
   Technician asked whether they are all right, on the day: ______ (date, by whom)
   Check-in planned: ______ (a few days)   ______ (a few weeks)
   Threat involved: yes / no   If yes, the organisation's safety arrangements used on: ______
   Person's manager informed: yes / no   On: ______   By: ______________
   HR informed: yes / no   On: ______   By: ______________
   Second incident from this person on record: yes / no   If yes, raised with HR on: ______
   Technician excluded from this person's contacts: permanently / until ______

Held by: ______________ (desk lead)   Not attached to the ticket's public history.

Ewa told Hannah at 13:50, when Hannah came back from lunch, and Hannah's first question was whether she was all right. The note was written by 14:30, with Dominic's words in it as Ewa remembered them. Hannah took the scanner ticket, had the depot syncing by 15:15, and told Dominic so in two lines. Ross, the IT manager, read the note at 16:00, told Ewa she had done exactly the right thing, and spoke to the depot manager the following morning. Ewa did not take another call from Dominic. The desk's statement on abuse was written that week and signed by Ross. That was because, as Hannah put it, the only thing wrong with what Ewa did was that she had not been certain she was allowed to do it.

Frequently Asked Questions

What if I ended a call and, afterwards, I am not sure it was really abuse?
Write the note with the words as said and let the lead read it. A technician who ends a contact in good faith is not criticised for it, even if the lead would have drawn the line slightly differently. The cost of ending a rude call early is small, and the cost of staying on an abusive one is not. The desk's written line exists so that you are applying a rule rather than judging your own sensitivity. The note is how the rule is checked afterwards, not you.
The person apologised the next day. Does the report still go in?
Yes. The report records what happened, and an apology is recorded alongside it as a fact with its date. An apology may well affect what the IT manager and the person's manager decide, and that is theirs to weigh. It does not undo the report, and it does not return the technician to the person's path. That decision is the desk's and is made for the technician's protection, not as a judgement on the apology.
The abusive person is a director. Does the technician still end the call?
Yes, in exactly the same way, and the report goes to the IT manager the same day in exactly the same way. What changes is who has the conversation afterwards: the IT manager, with the director or the director's own manager, directly and promptly. The technician's right does not depend on the person's seniority. If the organisation will not back that, the IT manager should find out before publishing the statement rather than after a technician has relied on it.
Should the desk keep a list of people who have been abusive?
The desk keeps the incident notes, held by the lead, and records any routing change for the person in the pattern log. That way every technician knows the person's contacts go through the lead. That is a record of incidents and of the desk's response, not a list of people to be treated differently on their tickets. The person's tickets are handled at the normal speed and priority; only who answers them has changed.
What if the lead is the one who was abused?
The lead reports to the IT manager the same day, in the same way. The IT manager takes over the contact with the person. The lead does not handle their own incident, for the same reason a technician does not. The person who was attacked should not be the person managing what follows. If the IT manager is the one abused, the report goes to the IT manager's own manager, with HR informed. In that case, the contact is handled by someone else in the department.
Can we require users to accept the no-tolerance statement before they get support?
Publish it where people can see it, on the portal or the scope page, and refer to it in the behaviour standard. Do not make support conditional on acknowledging it. That is because the people the desk supports are colleagues and the organisation's own rules of conduct already apply to them. Whether anything beyond publication is appropriate is a question for HR, who own the rules, and the answer varies by organisation. The statement's job is to make the desk's position known and the technician's right unmistakable.

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.