When Frustration Becomes a Pattern Rather Than a Bad Day

Tuesday, 09:40, at Meridian Parts. A new ticket lands in the queue with the subject line in capitals. Dana, who has been on the desk for two years, sighs before she has read a word of it. She knows the name. Gareth runs the planning team, and his tickets arrive the same way every time. The subject is in capitals, and the operations director is copied in. "Third time I've raised this" appears in the first line whether or not it is. A phone call to the desk follows about forty minutes later, asking why nobody has replied. Oliver, the desk lead, looks over from the next desk and says "him again?" without looking at the screen. Nobody on the desk has ever written down that Gareth does this. Everybody on the desk knows.

That gap, between what everybody knows and what anybody has written down, is where this series starts. A pattern, at a help desk, is the same person behaving the same way across separate tickets over a stretch of time. It is distinct from a bad day, which is one person behaving badly once, about one thing, and usually for a reason the ticket explains. The first is a thing the desk can manage. The second is a thing the desk absorbs. The conversation for absorbing it is already written, in the Working With Frustrated Users series, which this article links and does not redo. This article is part of our De-escalation & Difficult Users series. It is about the moment a desk realises it is not looking at a bad day any more.

It covers the difference between a bad day and a pattern, and the test that tells them apart. Next come the record in the ticket history and how to read it, and what the record is not, which matters as much. Then come the four recognisable types: the chronic complainer, the queue-jumper, the shouter and the one who goes to your boss. The article covers what each is usually about, and what the pattern says about the desk itself. The ladder of responses this series climbs, a short war story, and the pattern log to copy follow, in that order.

A Bad Day Against a Pattern

A bad day has a cause in the ticket, and a pattern has a cause in the person's habits. That is the whole difference and the reason the two need different handling. When a requester shouts about three mornings of outage, the shouting is attached to the outage. Fix the outage, handle the conversation well, and the shouting goes with it. When a requester shouts about every ticket, including the one that was answered in four minutes, the shouting is attached to the requester. No amount of fixing will remove it, because it was never about the fix. The desk that treats a pattern as a series of bad days will handle each one beautifully and get nowhere. The desk that treats a bad day as a pattern will punish someone for having a printer catch fire on the wrong morning.

The test is whether you would recognise the behaviour without the name. Cover the requester's name and read the ticket cold. If what remains is a person under pressure about a specific thing, with a tone you can trace to that thing, it is a bad day, however loud. If what remains is a tone you have seen before, in the same shape, about things that had nothing in common, you have a pattern. In that case, the name under your thumb is the one you expected. Dana did not need to read Gareth's ticket to know how it would read. That is the test failing in the direction of a pattern, and it is more reliable than any count.

Counts still help, because memory exaggerates in both directions. Three contacts, across separate tickets, is the point at which most desks should stop calling it bad luck. That applies when the behaviour and not the problem is what you remember. Two can be coincidence; two bad days a month apart happen to pleasant people. Three in a few months, on tickets about different things, with different technicians on the other end, is a shape. The number is not a law. It is the point at which the desk owes itself a look at the record rather than another sigh.

The look matters because the desk's memory of a person is the least reliable record it keeps. It remembers the shouter's last three calls and forgets the eleven civil tickets. It remembers the name and not the dates. I have watched a desk describe a requester as "constantly on the phone" and then find, in the history, four calls in a year. The desk was not lying. It was remembering the calls and not the gaps, which is what desks do.

The Record in the Ticket History

The ticket history is the only account of a person's behaviour that two people will agree on. Reading it is the first thing to do once the test above says "pattern". Search for every ticket from the requester over the last year or so, in every channel. Read them in date order, with the problem on one side of your mind and the behaviour on the other. You are looking for five things. Look at contact frequency compared with people in similar roles. Look at reopens, and by whom. Check escalations and copied-in managers, and whether the ticket was overdue at that point. Look at how the first message reads. And check whether the behaviour is the same with every technician or attached to one.

Read the first message of each ticket with particular care, because it is the requester before the desk has done anything. A first message may open with "third time of asking" on a brand new fault. Or it may copy the operations director in before anyone has had a chance to be slow. Either tells you the heat is arriving with the person. A civil first message followed by a hot second one tells you something happened in between. The something is usually in the history: a day without an update, a reply to the wrong question, a fix that did not hold. The order of events is the evidence. A loud message after a missed update is a bad day the desk caused. A loud message before any update was due is a pattern.

Where every channel lands in one queue, this reading is one search. If you run QuerySolv, a requester's tickets from the web form, e-mail and chat sit in the same queue and each carries its complete event history. In that setup, the whole story is a filter on a name and a quiet half hour. Where the desk runs a shared mailbox beside a chat tool beside a phone log, it is three searches and a spreadsheet. In that setup, the phone log is usually the one that was never kept. Do it anyway.

Write down what you find as counts and dates, not as a verdict. "Fourteen tickets in the year; four reopened by the requester, two of those after a fix that did not hold; six with a manager copied in on the first message; one escalation where the ticket was already two days over target; tone the same with all four technicians." That paragraph is a record. "Gareth is a nightmare" is a feeling with a name attached. Feelings do not survive being read aloud in a meeting with the person's manager. The record also has a habit of being fairer than the memory it replaces. Two of Gareth's reopens were the desk's fault, and the desk had forgotten both.

What the Record Is Not

The record is not a blacklist. The quickest way to turn a fair desk into an unfair one is to let it become one. A blacklist is a list of names with a conclusion attached, kept so that the desk can treat the people on it differently. A record is a set of facts about contacts, kept so that the desk can respond to behaviour consistently and show its working. The first lowers the service a person gets; the second changes how the desk talks to them and nothing else. The ticket about the broken scanner gets the same priority and the same speed whether or not the requester's name is in the log. The moment it does not, the desk has become the thing it was complaining about.

The record is also not a character file, and nothing in it describes the person. It describes what was said and done, with dates. The rules for what never goes in a ticket are in What Never to Write in a Ticket. They apply with double force here: no adjectives about the requester, no diagnoses, no guesses about why they are like this, no jokes. Assume the requester will one day read every word. In many organisations they can ask to. A note that says "shouted for two minutes about the VPN; said 'you people are useless'; call ended by agreement at 10:14; fix sent by e-mail 10:40" is a note the desk can defend to anyone. A note that says "usual nonsense from G." is a note that ends careers, and not the requester's.

Keep the record where the desk keeps its other records, and where the requester cannot see it. That means the internal note on the ticket, with a short summary carried to a separate log once the entries add up. A spreadsheet the lead owns works; so does one internal ticket linked to each of the person's tickets. What does not work is the desk's chat channel, where the record becomes a running commentary and the commentary becomes the thing the requester's manager is shown. (Nobody has ever regretted keeping a log boring.)

The Recognisable Types

Patterns come in a small number of shapes. Knowing the shape tells you what the person is usually about, which is the beginning of handling them. The table below gives the four that account for most of the names a desk recognises. None of them is a diagnosis of a person. They are shapes of behaviour, and the same person can show two in a bad quarter and none in a good one. Naming the shape stops the desk responding to the behaviour as if it were the problem, when the problem is almost always sitting just behind it.

The Chronic Complainer

The chronic complainer is the person whose every ticket contains a complaint about the desk. The history almost always shows that the first one was deserved. Somewhere a year or two back there is a ticket that went wrong. It was lost, closed without a fix, answered with a template that missed the point, or left for a fortnight with no update. The requester was right to be angry; nobody said so, and the requester has read every ticket since as confirmation. The complaint has detached from the fault and attached to the relationship. Fixing today's ticket well does not touch it, because today's ticket was never the subject.

The second thing the history often shows is something the desk genuinely cannot fix, and the complainer's job depends on it. A reporting tool that is slow by design, or a home connection that drops twice an afternoon. The requester raises it, and the desk closes it with "working as designed" or "outside our scope". The requester, who still has to do the job on it, raises it again in a different form. That is not malice. It is a person using the only lever they have. The desk's first move is to find both things in the history: the original failure and the standing limit. Name them in writing: "I can see the ticket from last spring that was closed without a fix, and I'm sorry about that; and the reporting tool is slow for everyone and I can't change it, but here is what I can do about the part that blocks you." Most chronic complainers have been waiting a long time for one of those sentences. Several have been waiting for both.

The Queue-Jumper

The queue-jumper marks everything urgent, phones minutes after submitting the ticket, and appears at the desk with "just quickly". The history shows that the urgency is the same whether the fault is a dead laptop or a missing icon. The temptation is to read this as selfishness. It is more often a lack of trust in the queue. Nobody has ever shown the requester that a ticket marked normal gets handled. So they have learned that only the ones they push get done. Sometimes they learned it at this desk, in the bad year before you took it over; sometimes from a manager who measures them by the hour. Either way, the push is a strategy, and strategies change when they stop working and something else starts to.

The first move is to make the queue visible to them, once, honestly. Show what is ahead of their ticket and when they will be reached, and then reach them at that time. The in-the-moment handling of the person who insists everything is urgent is in The Everything-Is-Urgent User. The proactive updates that stop the chasing before it starts are in Status Updates That Prevent the Angry Follow-Up. This article's job is only to say that the pattern is usually a trust problem, rebuilt by promises kept rather than by explanations of the priority grid. A queue-jumper who has been reached on time three tickets running usually stops jumping. The grid did not persuade them. The clock did.

The Shouter

The shouter is loud on the phone and personal in a way that is hard to pin down. They are civil in writing, the same with every technician, and often apologetic afterwards. The history shows that the volume has nothing to do with the size of the fault. The shouting is a habit, or it is fear. From the desk's side it does not much matter which, because the response is the same. Move the relationship into writing and give the person one named owner. Write down in advance where anger stops and abuse starts so that no technician has to decide that while being shouted at. The line itself, and what a technician does at it, belong to Staying Professional Under Fire. The fourth article in this series picks up what the desk does when it is crossed.

What the pattern adds is the question of why the shouting has never stopped. The honest answer is usually that nobody has ever named it to the person. Technicians absorb it, each assuming someone else has had that conversation. Nobody has. The shouter has been shouting at a desk for three years. Nobody with the standing to say it has ever calmly told them that this is not how the desk is spoken to. The third article in this series is about saying it. This one is about noticing that it has never been said.

The One Who Goes to Your Boss

The one who goes to your boss skips the desk and takes the ticket to the IT manager, or to their own director who takes it to the IT manager. The history shows the escalation arriving before the desk has missed anything. The desk hears about the ticket from above, which is the worst way to hear about a ticket. The ticket is then handled fast, which teaches the requester that the side door works. This shape is about status more than about service: a belief that the desk responds to rank, often supported by a history where it did. Senior people learn it from assistants who learned it from the previous IT manager. That manager answered the phone personally for anyone above a certain grade and left the rest in the queue.

The first move belongs to the IT manager, not the technician. It is to close the side door kindly and every single time: "thanks for flagging it; I've put it in the queue as ticket 4471 and Dana will be in touch today". That comes with no special speed and no hint of annoyance. The requester learns, over a handful of tickets, that the side door leads to the same room. The IT manager who instead fixes it personally has confirmed the pattern and will see it again next week. Where the person is genuinely senior, the question of what a senior person is entitled to is in No Shadow SLA. The answer is: the same queue, with the desk's real priority rules applied honestly. An executive whose laptop is dead is urgent because the laptop is dead. An executive whose icon is missing is not, and the IT manager is the person who gets to say so. It is one of the few genuine perks of the job.

What the Pattern Says About the Desk

Every pattern is partly a mirror, and the honest desk reads its own reflection before it reads the person. The chronic complainer usually started with a ticket the desk mishandled. The queue-jumper usually learned to jump at a desk where jumping worked. The shouter has never been told to stop because the desk never told anyone anything. The one who goes to your boss goes there because the boss, or the last one, let them in. None of that excuses the behaviour. It means that before the desk opens a pattern log on a person, it owes itself a short check on each ticket in the history. Was the response on time, did the update go out before the chase, did the fix hold? If the answer is no on half of them, the pattern the desk has found is its own, and the person is reporting it loudly.

That check is the same one the frustrated-users series asks the desk to run on every angry ticket. It is described in What Angry Tickets Teach the Desk. Run that check on the person's history as a set. A pattern of angry tickets from one person about one recurring desk failure is the desk's failure wearing a name. Fix the failure, tell the person it is fixed, and watch the pattern for a quarter before calling it theirs. Some patterns dissolve the month the desk starts sending updates on time. The desk is then free to feel slightly embarrassed, which is cheaper than a manager meeting.

The Ladder From Here

Once the desk has a pattern and has checked its own part in it, the rest of this series is a ladder, and the picture below draws it. At the bottom is the bad day, handled in the moment by the technician and noted on the ticket. The second step is the second or third time. At that step, the desk opens the pattern log, gives the person a single named owner and a single channel, and sends a written summary after every contact. The third step is a pattern proper, three or more entries. At that step, the desk lead sends the behaviour standard once, in writing, with a consequence named. The fourth is the standard crossed again, where the consequence is applied and the IT manager speaks to the person. The fifth is still continuing, where the user's own manager and then HR are involved and the technician is kept out of it. Above all of it runs a band for abuse, which skips the ladder entirely. In that case, the contact ends, the words are noted, and the IT manager hears about it the same day.

Two things about the ladder before the series climbs it. Each step keeps everything from the step below: the named owner from step two is still the named owner at step five. And most people never reach the third step. That is because a named owner, one channel and a summary after every contact remove the two things most patterns feed on. Those are the argument about what was said and the sense that nobody is in charge. The second article in this series, De-escalation the Second and Third Time, is about those three moves. It is where most pattern logs quietly end.

A Short War Story: The Name Everyone Knew at Tollgate Foods

At Tollgate Foods, a depot administrator called Maureen was known to the whole desk as the person who phoned about every ticket within the hour. When a new desk lead called Isaac arrived, the technicians told him about her in his first week as a warning. Isaac read her history before he met her, and found twenty-two tickets in eighteen months. Of those, nine had gone past the desk's own response target before she phoned. Four had been closed by the desk without a reply to her last message. Two had been reopened by her after a fix that did not hold. Her first messages were civil on every one. He went to the depot and apologised for the four silent closes by date. He set up updates that went out before she could chase, and asked her to try the queue without phoning for a month. She phoned twice in the next quarter, both times about tickets that had genuinely stalled. The pattern had cost the desk eighteen months of a technician's flinch every time her name appeared. It had cost Maureen eighteen months of being the depot's most reliable reporter of a desk that was dropping tickets. A pattern that nobody has read the history of is only a rumour, and this one had been about the desk.

The Pattern Log

The log below is opened once the test in this article says "pattern" and the desk's own check has been done. It is kept by the person's named owner with the desk lead reading it. The desk's own check sits in the middle of the page on purpose, so that nobody reaches the bottom without filling it in. The bottom section hands over to the second article in this series. Keep the log as an internal note or a lead's file, never anywhere the requester's colleagues can see it. Expect to close most of them with "continuing, no further entries" rather than with an escalation.

PATTERN LOG — ONE PERSON, ONE PAGE
Requester: ______________   Department: ______________   Opened: ________  By: ________
Named owner on the desk: ______________   Agreed channel: ______________
Read by: desk lead [ ]   IT manager [ ]   (never shared with the requester's colleagues)

WHAT COUNTS AS AN ENTRY
  A contact where the behaviour, not the problem, is the reason it is written down.
  Facts only: date, ticket, channel, what was said or done, what the desk did.
  No adjectives, no guesses about why, nothing you would not read aloud to the person.

ENTRIES
  Date ______  Ticket ______  Channel ______  Technician ______
  What was said or done (words as said): __________________________________
  What the desk did: __________________________________
  Was the ticket itself on time at that point?  yes / no   If no: ______________

  Date ______  Ticket ______  Channel ______  Technician ______
  What was said or done (words as said): __________________________________
  What the desk did: __________________________________
  Was the ticket itself on time at that point?  yes / no   If no: ______________

THE DESK'S OWN CHECK (before calling it a pattern)
  [ ] Every ticket in the log was answered within the desk's normal target
  [ ] An update went to the requester before each chase, not after
  [ ] No ticket in the log was reopened for a fix that did not hold
  [ ] The behaviour appears with more than one technician
  [ ] The first message of each ticket carried the heat, before the desk had acted
  [ ] Three or more entries, on separate tickets, within ______ months
  Anything the desk owes the requester from this check: ______________________

AT THREE ENTRIES
  Named owner confirmed: ______   One channel agreed with the requester: ______
  Desk lead told on: ______   Summary after every contact from now on:  [ ]

REVIEW
  Reviewed on ______ by ______   Outcome:  closed / continuing / standard sent / escalated

Dana opened a log on Gareth on the Tuesday, after reading his fourteen tickets. She filled in the desk's own check honestly: two reopens the desk had caused, and one update that had gone out a day late. She sent him a two-line note about both, which he did not answer. The next three tickets arrived in capitals with the director copied in, on faults that were handled inside the hour each time. By the third entry Oliver had read the log, agreed it was a pattern, and taken the next step. That step is the subject of the next article. The desk had stopped sighing at the name. It had started writing things down, which turned out to be the same thing done properly.

Frequently Asked Questions