The Tickets Everyone Is Avoiding

Ticket 3309 at Pinecrest Academy, a school with ninety staff and a desk of three, is forty-seven days old. Its subject is "Shared mailbox permissions for the finance office are wrong", and its history is instructive. It has been assigned to three different people. It has been opened, according to the tool's view count, nine times. It has received two internal notes, one saying "will look at this next week" and one, twelve days later, saying "still on my list". It has had no public reply in thirty-one days. Every technician on the desk knows exactly which ticket 3309 is and could describe the problem from memory. Each has at some point this month looked at it, felt the particular weight of a ticket with no obvious first move, and opened a different one. Nine visits, two touches. Everybody has been to see 3309. Nobody has stayed.

An avoided ticket is one that is open, owned and visible, and is not moving. Its owner, and usually everyone before its owner, has found reasons to do something else first. It is not a ticket nobody has time for; the desk closed sixty tickets last week. It is a ticket that is being chosen against, repeatedly, by reasonable people, because something about it is hard, boring, political, or unfamiliar. This article is part of our Ticket Aging & Follow-Up Discipline series. It is about the tickets that aging reports find and aging reports cannot fix.

It starts with what avoidance is and what it is not, the five reasons tickets get avoided, and the signals that reveal them in any queue. Then comes the conversation that gets an avoided ticket talked about without anyone being blamed. Next is the pairing fix, which is the single most reliable way to move one, followed by reshaping a ticket so it stops being dreadful. Then the two hardest kinds, political and boring, and how to stop the next one forming. A worksheet to work through with the ticket open finishes the article.

What Avoidance Is and What It Is Not

Avoidance is a specific kind of stale. Most stale tickets are stale because they are waiting on somebody who has gone quiet, and the fix is a nudge. An avoided ticket is waiting on the desk, the desk knows it, and the desk keeps not doing it. The difference is visible in the history. A ticket waiting on a requester has a question in it that was never answered. An avoided ticket has a technician in it who never asked one. The weekly pass that finds both kinds, and the three questions that tell them apart, is The Stale-Ticket Sweep. This article is what happens when the sweep's third question, "what is the next step?", gets the answer "I don't know".

Avoidance is also not laziness, and treating it as laziness is the fastest way to make it worse. The technicians avoiding 3309 closed sixty tickets last week. They are not avoiding work; they are avoiding this work, and the reason is almost always in the ticket rather than in the person. A ticket may have no clear first step. Or a first step that involves a difficult conversation, or a first step that needs knowledge nobody on the desk has. That ticket will be avoided by whoever holds it. Reassigning it moves the avoidance to a new owner without changing the ticket. Three assignees in forty-seven days is not three lazy people. It is one badly shaped ticket passed between three sensible ones.

Avoided tickets are patient. They can wait longer than you can, and they cost more every week. The finance office at Pinecrest has been forwarding mail to each other by hand for seven weeks. The requester has stopped believing the desk will fix it. The technicians have each spent a few minutes a week feeling bad about it, which adds up to more time than the fix would have taken. Nobody has calculated that, because calculating it would mean opening the ticket.

Why Tickets Get Avoided

Five reasons cover nearly every avoided ticket, and the fix depends on which one applies, so the first job is to name it. The first reason is that the ticket is hard: the technician does not know how to do it and is not confident they can find out. A permissions model nobody on the desk understands, an application whose vendor has gone quiet, a network fault that only appears on Tuesdays. Hard tickets get avoided because starting one means admitting, at least to yourself, that you might fail, and most people would rather close three easy tickets and feel competent.

The second is that the ticket is boring: the technician knows exactly how to do it and the doing is long, repetitive and unrewarding. Re-permissioning four hundred folders by hand. Auditing which of ninety staff still need a licence. Migrating a mailbox archive that will take a day of watching a progress bar. Boring tickets get avoided because every other ticket in the queue is more interesting, and the queue is always full of other tickets.

The third is that the ticket is political: the next step is a conversation with someone the technician would rather not have a conversation with. The requester is a director who asked for the wrong thing. The fix requires telling a department head that their team's process is the problem. Two managers want opposite things and the ticket is where they meet. Political tickets get avoided because the technical work is five minutes and the human work is unbounded. The technician has correctly judged that the human work is above their pay grade and incorrectly concluded that the ticket should therefore wait.

The fourth is unknown territory: nobody on the desk has ever done this before, and there is no runbook, no colleague who remembers, and no obvious place to start. The first request for a thing the organisation has never asked for, usually arriving as a one-line ticket that hides a week of research. These get avoided because the first step is "work out what the first step is", and that is not a step anyone can put a time estimate on.

The fifth, which is the one people forget, is already failed once: the ticket was worked, a fix was applied, it did not work, and the technician does not want to go back. The reopened ticket carries a small humiliation in its history, and opening it means reading your own confident note from three weeks ago. These get avoided out of plain embarrassment, and they are the easiest kind to move once somebody says so out loud.

I avoided a certificate renewal for six weeks once, because I did not understand certificates and did not want anyone on the desk to find out. The certificate expired on a Saturday, and then everyone found out at once.

How to Spot Them

Avoided tickets leave a signature in the history, and once you know the shape you can find them in any queue in ten minutes. The table lists the signals in rough order of reliability. None is proof on its own; two together are a strong hint, and three is a ticket to put on the worksheet this week. Most tools record assignments, status changes and notes in the history, so the signals are there. Some tools can also report how often a ticket changed hands or how many times it was opened, which makes the search faster. But the history alone is enough.

The last signal is the quickest test and the one most desks skip because it feels unscientific. Ask the team, together, which ticket they would least like to be handed. There will be a pause, and then there will be a number, and usually two or three people will say the same number at once. That is the avoided ticket. The history will confirm it, but the team already knew.

Do not go looking for a name. The search for avoided tickets is a search for tickets. The moment it becomes a search for the technician with the most of them, the desk will learn to hide them better. By reassigning, by parking in a hold status, by closing and reopening. The person who currently holds 3309 is the third person to hold it, and the first two were no better. If your tool offers each technician a private view of their own numbers, leave it private; the useful question is "which tickets?", not "whose?".

The Avoidance Conversation Without Blame

The conversation about an avoided ticket has one rule: the ticket is the problem, not the person. That sounds like a courtesy and is in fact a diagnosis, because in nearly every case it is true. A conversation that starts from the truth gets further. The question is not "why haven't you done 3309?" but "what would make 3309 easier to start?" The first question asks for a defence. The second asks for information, and the information is the fix.

Have it in private, in a few minutes, with the ticket open on a screen between you. Say what you noticed, in the ticket's terms: "3309 has been with you eleven days and the last note is 'will look at this'. I think it is one of the ones that is hard to start." Then ask which of the five it is, in plain words. Is it that you are not sure how? Is it that it is a slog? Is it that there is a conversation in it you would rather not have? Is it that nobody has done one before? Or is it that you tried once and it did not work? Most technicians, asked that way, will tell you immediately, and often with relief, because they have been carrying the answer around for a fortnight.

Never ask "why haven't you done this". Not in the stand-up, not in passing, not in a tone. The question has no good answer, and it makes the next avoided ticket harder to admit to. It teaches the desk that the safe move with a dreadful ticket is to reassign it quietly before anyone asks. The desk lead who asks "what would make it easier?" gets told about avoided tickets early. The desk lead who asks "why haven't you?" finds them in the aging report, three months later, with four assignees.

Then agree a first step together, in the conversation, and write it in the ticket before the conversation ends. Not the whole plan; the first step, the one that takes under an hour and that the technician is sure they can do. "Export the current permissions on the finance mailbox to a file and attach it to the ticket" is a first step. "Sort out the finance mailbox" is the thing they have been avoiding. A ticket with a written first step and a date is no longer an avoided ticket, by definition. It may become one again, which is what the pairing fix is for.

The Pairing Fix

Pairing is two people working one ticket at the same time, at one screen or one call, for a fixed short period, usually thirty minutes. It is the single most reliable way to move an avoided ticket, and it works on all five reasons, for a simple cause. The thing that made the ticket avoidable was being alone with it. A hard ticket with a second person is a puzzle. A boring ticket with a second person is a conversation with a progress bar in it. A political ticket with the right second person is a draft e-mail written in ten minutes. An unknown-territory ticket with a second person is two search histories instead of one. And a ticket that already failed once, with a second person, stops being embarrassing, because the second person did not write the confident note.

Choose the second person for what the ticket is missing. If the ticket is hard, pair the owner with whoever knows the most about the subject, even if that is only slightly more. If it is political, pair with whoever has the standing to have the conversation, which is often the desk lead. If it is unknown territory, pair with anyone who is good at starting things, because starting is the whole problem. If it is boring, pair with anyone at all; company is the fix, and the second person can bring their own boring ticket and swap halfway. If it already failed once, pair with someone who was not involved the first time and will read the history fresh.

The rules of a pairing session are short. Thirty minutes, booked in both calendars, with the ticket as the only agenda. The owner drives; the second person asks questions and takes the notes. The goal is not to finish the ticket; it is to leave it with a written next step, a date, and, if possible, the first step already done. At the end, the owner writes the note, and the pair agrees who does the next step. If the ticket still has no obvious path after thirty minutes with two people, that is a finding too. It goes to the next section.

Pairing costs an hour of desk time per ticket, counting both people. The avoided ticket at Pinecrest had already cost more than that in visits and notes and apologies, and the finance office's hand-forwarding had cost many times more. A desk that pairs on one avoided ticket a week will find, after a month, that it has fewer of them. The technicians have learned what the first step of a dreadful ticket looks like and started writing it themselves.

Reshaping the Ticket

Some avoided tickets cannot be moved by a first step because they are not one ticket. "Set up the new warehouse office" is a project wearing a ticket's clothes, and no technician will ever find its first step because it has thirty. The fix is to reshape it: split it into the pieces that can each be done in an afternoon. Give each piece its own ticket and owner, and let the original ticket become the one that tracks the others. Many tools can split a ticket or link related tickets under a shared name. Where yours cannot, list the child ticket numbers in the parent's notes, and the parent's number in each child. That does the same job by hand.

Other avoided tickets need re-scoping with the requester, because the thing asked for is not the thing needed. The director who asked for "everyone in finance to see everything in the shared mailbox" needed four people to see one folder. The ticket was avoided because doing what was asked was wrong and saying so was awkward. A ten-minute call with the requester, asking what they are trying to do rather than what they asked for, often turns an avoided ticket into an easy one. It also sometimes turns it into a political one, which is a step forward: at least now the desk knows which conversation it is avoiding.

A third kind needs a decision rather than work. The ticket is avoided because the next step is a choice between two things the desk is not allowed to choose between. Spend money or do not, change the policy or do not, give this person access or refuse them. The desk cannot make the decision, and so it does nothing, and the ticket waits. The fix is to escalate for the decision, with the options written out and a default stated. "Option A costs this and does that; option B costs nothing and leaves the problem. If we hear nothing by Friday we will do B and close the ticket as not approved." Many tools have an escalation flag or level that marks a ticket for attention; some raise its priority instead. Check which yours does, because a flag that does not move a clock is a request for a decision, not a demand for speed. The note has to say what the decision is.

A fourth kind should be closed honestly, because the desk cannot do it and will not be able to. The vendor has gone, the system is being replaced next quarter, the request needs a skill the organisation does not have and will not buy. Avoided tickets of this kind sit for months because closing them feels like failure. It is not; it is the end of a pretence. How to write that close so that the requester is told the truth and left with a route, rather than abandoned, is the subject of Closing the Ticket You Cannot Fix.

The Political Ticket

The political ticket deserves its own section because it is the one where the technician's instinct, to wait until it goes away, is both the most natural and the most expensive. The technical part is small. The human part is a conversation with somebody who outranks the technician, or who is angry, or who is two people who disagree. The technician is right that it is not their conversation to have. They are wrong that the ticket should therefore wait, and the gap between those two is where a desk lead earns their title.

The desk lead's move is to take the conversation, not the ticket. The technician keeps the ticket and does the technical part. The lead has the ten-minute call with the director, or writes the three-option e-mail to the two managers. Or tells the department head, politely and with evidence, that their process is the cause. The outcome of the conversation goes into the ticket as a note, the technician does the work, and the ticket closes. If the lead does not have the standing either, the lead escalates. The rules for who can have which conversation are the ones in Escalation Boundaries. The point for this article is that a political ticket is escalated for authority, not for skill. The technician should not be left holding it as though it were a technical problem.

The three-option e-mail is the tool that resolves most political tickets, and it is worth learning the shape. It states the problem in one line and offers three ways forward with the cost and consequence of each in one line apiece. It recommends one and names a date by which the desk will proceed with the recommendation unless told otherwise. It is polite, it is short, and it moves the decision to the person who should make it while giving them an easy way to make it. People who have been avoiding a decision for seven weeks will often make it in a day when it arrives as three lines and a date. (They were avoiding the conversation too.)

The Boring Ticket

The boring ticket is avoided for the most honest reason of all, which is that it is boring, and the fixes are correspondingly plain. Timebox it: ninety minutes, booked, with the ticket as the only task, and a note at the end saying how far it got. Batch it: four hundred folders become eight batches of fifty, each an afternoon, each a note, each a visible step. Pair it: company turns a slog into a shift. Or look at it more carefully, because a surprising number of boring tickets are the same boring ticket, recurring. A recurring boring ticket is not a ticket at all but a problem waiting to be fixed at the root, or a task waiting to be automated. The habit of finding tickets that keep coming back is covered in Finding the Repeat Tickets, and the boring ticket is where to start looking.

One more honest option: the boring ticket may not need doing. The licence audit that nobody has asked about since it was raised, the archive migration for a mailbox nobody has opened in a year. Ask the requester whether the result still matters, by a date, and if it does not, close it with a reply and a clear conscience. A ticket that is boring and unwanted is the easiest ticket in the queue. It just does not look like it from the inside.

Preventing the Next One

Avoided tickets are prevented by a rule and a habit. The rule: no ticket is owned for more than a week without a written next step and a date in it. That rule, kept, makes avoidance visible in days rather than months. A ticket whose owner cannot write a next step is a ticket the owner needs help with. The rule turns "I will get to it" into "I need a pair". The weekly sweep enforces the rule on every ticket that has gone quiet; the desk lead enforces it at the stand-up on every ticket that has not.

The habit: rotate the hard ones. When a ticket of a kind the desk finds difficult comes in, the person who knows how does it with the person who does not. The person who did not writes the runbook afterwards. Over a few months the desk has fewer tickets that only one person can start, and a ticket anyone can start is rarely avoided. The hero who takes every hard ticket is doing the desk a kindness. As a side effect, it produces a queue full of tickets nobody else dares open while the hero is on leave.

Finally, watch the handoffs. A ticket passed from one technician to another with a one-line "can you take this?" is a ticket that arrives already avoidable. The new owner has no idea what has been tried and will spend their first hour finding out. That is an hour they will choose not to spend. The handoff that includes what was tried, what was found, and what the next step is, is a handoff that produces a ticket somebody can start. It is the subject of The Handoff That Does Not Dump. Most avoided tickets with three assignees had three bad handoffs in them.

A Short War Story: The Mailbox Nobody Wanted at Redbrook Engineering

Redbrook Engineering, a design consultancy with seventy staff and a desk of three, had a ticket to fix the permissions on the finance shared mailbox. It had been reassigned four times in nine weeks, each new owner inheriting a note that said only "see above". The technical fix was a fifteen-minute change. The finance director had asked for a configuration that would have let every member of her team read every other member's mail, including the payroll folder. Each technician in turn had decided that telling her so was somebody else's job. That was why nobody made the change. Theo, who held it fourth, said as much when Imogen, the desk lead, asked him what would make it easier to start. The two of them spent twenty-five minutes writing a three-option e-mail. It set out what she asked for and why the desk advised against it, a folder-level alternative, and a do-nothing option, with a Friday date. The director replied inside a day and chose the folder-level option. Theo made the change that afternoon. The cost was nine weeks in which two finance staff forwarded mail to each other by hand, and a director who had concluded that IT did not answer. Four technicians had each spent a little of every week not looking at the ticket. The lesson was that the ticket had been avoided because of a conversation, not a configuration. The fix was to pair the owner with the person who could have the conversation.

Nobody at Redbrook had been lazy for nine weeks. Four careful people had each decided, correctly, that it was not their call, and nobody had made it anyone's.

The Dreaded-Ticket Worksheet

The worksheet is for one ticket at a time, filled in by the owner and one other person, with the ticket open, in about fifteen minutes. It walks through the diagnosis, the first step, the pairing and the reshape, in order, and ends with the note that goes into the ticket. Use it on the ticket the team named when you asked which one they would least like to be handed, and then on the next one. By the fourth or fifth the questions will be in people's heads and the sheet can go in a drawer.

DREADED-TICKET WORKSHEET — ONE TICKET, FIFTEEN MINUTES
Ticket: #______   Opened: ________   Assignees so far: ____   Last touch: ________
Owner: ____________   Second person: ____________   Date: ________

HOW WE KNOW (tick what applies)
  [ ] Owned and silent 14+ days   [ ] Passed around (3+ owners)
  [ ] Promissory notes only       [ ] Looked at many times, not touched
  [ ] Flagged and still           [ ] Everyone knows the number

WHY (one main reason, one secondary at most)
  [ ] Hard: we are not sure how          [ ] Boring: we know how, it is a slog
  [ ] Political: a conversation in it    [ ] Unknown territory: never done one
  [ ] Already failed once
  In the owner's words: ________________________________________________

WHAT THE REQUESTER ACTUALLY NEEDS (one line; call them if unsure)
  ____________________________________________________________________

IS IT ONE TICKET?
  [ ] Yes   [ ] No: split into ____ pieces, each an afternoon; parent tracks them

THE FIRST STEP (under one hour; the owner is sure they can do it)
  What: _______________________________________  Who: ________  By: ________

THE PAIR
  Missing piece:  [ ] knowledge  [ ] authority  [ ] a fresh reader  [ ] company
  Second person: ____________   Thirty minutes booked on: ________ at ______
  Goal of the session: first step done, next step written, date set

IF IT NEEDS A DECISION, NOT WORK
  Option A: ________________________  cost/consequence: ______________
  Option B: ________________________  cost/consequence: ______________
  Option C: ________________________  cost/consequence: ______________
  Recommend: ____  Sent to: ____________  Default if no answer by ______: ____

IF THE DESK CANNOT DO IT
  [ ] Close with a reply: what was found, why, and the route that remains

THE NOTE (copy into the ticket)
  Reason avoided: ________  First step: ________ by ________
  Pair: ________ on ________   Next step after that: ________ by ________

The sheet has one quiet purpose beyond the ticket in front of you. A desk that fills in six of them over two months has a record of why its tickets get stuck, and the reasons cluster. If four of six say "political", the desk lead is not having enough conversations. If four say "hard" and name the same system, the desk needs training or a runbook on that system. If four say "unknown territory", the organisation is asking for new things faster than the desk is learning them. That is a conversation for the IT manager, and a worksheet is the evidence to take into it.

Ticket 3309 at Pinecrest, for the record, took thirty-five minutes once two people sat down with it. Ten to find out that the finance office needed four people to see one folder, fifteen to make the change, and ten to write the reply. Forty-seven days, nine visits, three owners, thirty-five minutes. The dreadful tickets are almost never dreadful. They are alone.

Frequently Asked Questions