Finding the Repeat Tickets Hiding in the Closed Queue

Friday, 15:30, at Tollgate Foods. Lena runs a desk of three for a food distributor with a packing hall, two depots and an office. She has just opened the list of tickets closed this week for the first time in her life. Ninety-four tickets. She has been in the queue all week, like everyone else, and the queue shows what is open. What is closed scrolls past once, on its way out, and is never looked at again. Somewhere in the ninety-four, she suspects, is a thing the desk fixed four times this week under four different names. She has twenty minutes before the depot run and no idea where to look.

A repeat ticket is an incident the desk has fixed before, the same way, under a different number. Repeats are the raw material of problem management: a problem is a cause, and the only evidence a cause exists is the trail of incidents it leaves behind. Finding that trail is the first real work of the practice, and it is harder than it sounds. That is because the queue is built to show what is waiting and repeats live among what is done. This article is part of our Problem Management series. This article is about where to look.

It covers why repeats are invisible from inside the queue and the six searches that find them, with what each one misses. Then come the top-ten-by-category report and why it lies a little, and the reopen report as a problem finder. Next come the Friday sort, which is twenty minutes a week, and the pattern that only shows across months. After that come a worked example from Lena's ninety-four tickets and what to do with a repeat once you have found it. Last come a short war story and the repeat-ticket hunt checklist to copy.

Why Repeats Are Invisible From Inside the Queue

Repeats hide in four dimensions at once, and each one alone is enough. They are spread across people: four technicians each closed two label-printer tickets this month, and two feels like nothing to each of them. They are spread across time: eight a month is two a week, and no week looks unusual. They are spread across categories, because the requester picked "Printing" once, "Hardware" once, and "Other" the rest of the time. And they are spread across words, because nobody describes a problem the same way twice. You get "label printer stuck", "labels not printing", "packing line 2 printer", "the printer by the door again". A search for any one phrase finds a quarter of them.

The queue cannot help, because the queue is a list of what is open, and a repeat is only a repeat once it is closed. The moment a technician closes the fourth label-printer ticket, it leaves every view anyone reads. The closed list is the only place where repeats exist, and the closed list is where nobody goes, because nothing in it needs doing. It is the archive. Archives are where patterns live, and also where they are safest from being noticed.

The closing-time habit from Problems vs Incidents, where the technician asks "have I seen this before?" at close, catches what one person repeats. It does not catch what the desk repeats, because no one person has seen enough of it. That takes a search across everyone's tickets, on a schedule, by someone whose job it is that week. Both are needed. The habit is free and the search is twenty minutes, and a desk that does neither finds its repeats at forty-one.

Six Searches That Find Them

There are six ways to search for repeats, and they find different things, so the hunt uses several. The first is by the fix rather than the symptom: a full-text search of resolution notes for the words technicians use when they restore something without repairing it. "Restarted", "rebooted", "unlocked", "reconnected", "cleared", "reset", "power cycled". A resolution note that says "restarted the print spooler, working now" is a confession that nothing was fixed. A month of such confessions sorted by what was restarted is a list of problem candidates. This search only works if resolution notes say what was done. That is the case for a note written the way resolution notes worth reading later describes, and not for a note that says "done".

The second is by the thing: the name of a device, a server, a room or an application, searched across subjects and notes. "Scanner 7", "PH-2", "the till at Harbor Street", "the finance share". Most tools search subject and body; some search notes too. Check what yours covers, because a device name is most often in the note. The third is by the person or the site. A requester who raised nine tickets in a month, or a site that raised three times its share, is either unlucky or sitting on a problem. Most tools can sort or group closed tickets by requester, and a spreadsheet export can do it in any tool.

The fourth is the category report, the fifth is the reopen report, and both deserve their own sections below. The sixth is the short close: tickets closed within ten or fifteen minutes of being opened. A fast close is almost always a restore, because a repair takes longer than that. A list of fast closes sorted by subject is the cheapest problem finder most tools can produce. Not every fast close is a repeat; a password reset is a fast close and a genuine fix. But every repeat tends to be a fast close, because the desk has done it before and knows the move.

The Top Ten by Category, and Why It Lies a Little

The category report is the first thing most desks look at and the last thing they should trust on its own. Most tools can show tickets by category for a period. The top ten tells you the shape of the month: "Access" is the biggest pile, "Printing" is third, "Other" is second, which is its own finding. The report is useful for direction. It is not a list of problems, because a category is a guess made at the start of a ticket by whoever opened it. The guess is about the symptom, not the cause.

The two ways it lies are opposite. One problem can spread across three categories: the label printers at Tollgate Foods turned up under "Printing", "Hardware" and "Other". No single category showed more than three. And one category can hold three problems: "Printing" was also toner, a driver that reinstalled itself, and a printer whose tray was bent. Reading the top ten, Lena would have seen "Printing, 11" and learned nothing about which of the four things inside it was worth an afternoon. Categories are a map of where tickets were filed, drawn by the people least able to say what was wrong.

The report gets more honest when the category is set at close as well as at open, by the technician who found the cause. That is the argument of Categorize at Close, Not Just at Open. Until then, use the top ten to choose where to look, open the biggest two or three piles, and read the resolution notes inside them. The reading is where the repeats are. The report just tells you which drawer to open first.

Reopen Reports as a Problem Finder

A reopen is a closed ticket that the requester came back to because the fix did not hold. A list of reopens is a list of fixes that were not fixes. Many tools count a reopen automatically when a requester replies to a closed ticket. Some need a technician to change the status by hand. Either way, the report exists or can be made from a status filter. It is one of the shortest lists on the desk. Read it monthly. Every ticket on it was a restore that the requester noticed was only a restore, which makes it a repeat with a witness.

The reopen list has a bias, and the bias is useful to know. It only contains repeats where the same requester came back on the same ticket. A problem that hits a different person each time never reopens anything, because each person raises a new ticket. The scanner in the cold store had forty-one tickets and no reopens at all. So the reopen report finds the problems that follow one person around, and the other five searches find the problems that move. The honest way to count reopens, and what the count can and cannot tell you, is in Measuring Reopens Honestly. For the hunt, the only question is which closed tickets came back and what the fix had been.

The Friday Sort

The Friday sort is twenty minutes, once a week, in which one person reads the week's closed tickets looking for things that happened more than once. It is the single most productive habit in this series. It is also the one most desks never start, because it has no deadline, no requester, and no ticket. Put it on the calendar at a fixed time and give it to one named person. Rotate the name monthly so everyone learns what the desk's repeats look like. Friday afternoon is the traditional slot; the week is complete and nobody is starting anything new.

The method is the same in any tool. Open the list of tickets closed in the last seven days, with subject, requester, category, time open and resolution note visible. Or export those columns to a spreadsheet, which is quicker to sort and is what I do. Sort by subject and read down; the eye catches "label printer" three times in a column faster than any search does. Sort by resolution note and read again, because "restarted spooler on PH-2" clusters even when the subjects did not. Sort by time open and read the top: the five-minute closes. Then sort by requester and read the names that appear more than twice. Four sorts, four reads, and a tally on a scrap of paper of anything seen more than once.

If the spreadsheet is the tool, one formula does most of the counting. In a column beside the resolution notes, it counts rows whose note contains a word. In whatever spreadsheet you have, it is written as something like COUNTIF over the note column with the pattern "*restart*". Change the word, read the number. Ten words, ten numbers, two minutes. The formula is not the point; the point is that the week's restores become a count rather than a feeling. A count can be compared with last week's.

Anything seen three or more times in one week goes straight onto the problem candidate list. Anything seen twice goes onto a running tally that the next Friday adds to. The tally is the memory the queue does not have. After four Fridays it holds a month's repeats in one place. That is more than the desk has ever known about itself. The sort produces candidates, not problems. Deciding which candidates become records is the weekly review's job, described in Problem Management in an Hour a Week. The sort feeds that review.

The Pattern That Only Shows Across Months

Some repeats never show in a week, because they happen once a month, and a once-a-month repeat is invisible to any weekly sort by definition. The first working day of the month, when the finance close runs and a report server falls over. The Monday after a patch window. The week the sales team is all in the office. The first cold morning, when the heating comes on and a circuit in the depot trips. None of these is visible on any Friday. Each is obvious across three months of Fridays, if the tallies are kept.

The three-month view is the Friday sort done once a quarter on a quarter's tickets, with one extra sort: by date and by time of day. Export the quarter, add a column for the day of the week and one for the hour, and sort by each. Repeats that cluster on a weekday, at an hour, or in the first days of a month are telling you about a schedule somewhere. That could be a backup, a scan, a sync, or a job that someone set up and forgot. The tickets are the only record of the schedule, because the person who set it has usually moved on. A scheduled task does not raise a ticket for itself.

The slowest pattern is the one spread across categories and months at once. It is found only by someone who reads the quarter's resolution notes as one document. Sixty tickets in four categories whose notes all say "slow in the morning, restarted, fine by ten" are one problem. No search finds them, because the subjects differ and the fix word is common. What finds them is a person reading down the notes with a question in mind. Budget an hour a quarter for that read. It is the least efficient search on the list and it has found the most expensive problems I have ever seen.

A Worked Example: Lena's Ninety-Four Tickets

Lena exported the ninety-four closed tickets to a spreadsheet at 15:32 and sorted by subject. Three subjects contained "label" and one contained "packing line 2 printer", which she recognised as the same device. Sorted by resolution note, four notes read some version of "power cycled the label printer, printing again". Two of those were tickets whose subjects had not mentioned a printer at all. One had been "cannot dispatch order", raised by a supervisor. Six in one week. The category column, when she looked, said Printing, Printing, Hardware, Other, Other and Dispatch. The category report that morning had shown "Printing, 11", and she would not have found the other four from it.

She then searched the closed tickets for the three months before, by the device's name and by "label", and read every hit. Twenty-three tickets, across all three technicians, under five categories, from two depots, every one closed in under ten minutes with a power cycle. Then came the time-of-day sort, because twenty-three in twelve weeks is a schedule-shaped number. Seventeen of the twenty-three were logged between 06:00 and 07:30. That is when the packing hall starts and the overnight temperature in the hall is at its lowest. The tally, when she wrote it out, looked like this.

Twenty-three tickets at eight minutes of desk time is about three hours, which is not the number that mattered. Each one had stopped a packing line for the time it took a supervisor to find a phone, raise a ticket and wait, which was closer to twenty-five minutes. Twenty-three of those is nearly ten hours of a packing line standing still. Lena opened a problem record at 15:51, with twenty-three linked tickets, a hypothesis that read "cold start, printer in the coldest corner of the hall", and a next-review date. The twenty minutes had found the most expensive thing on the desk. It had been in the closed list the whole time, in five categories, under eleven different subjects.

From Candidate to Problem Record

A candidate becomes a problem record when the fix is confirmed to be the same, the count passes the threshold, and someone is named. The first check matters: two tickets about the same printer, one fixed by a power cycle and one by replacing the tray, are not the same repeat. The count that goes on the record is the count of the same fix. Read the notes before counting. Then apply the five-times test, open the record with the skeleton from the previous article, and hand it to an owner the same day. A candidate without an owner by Monday is a tally mark that will still be a tally mark in June.

Make the next search cheaper while the tickets are open in front of you. Add the problem's number to the resolution note of each linked ticket. Agree one word that every future ticket for this symptom will carry, in the subject or the note. That way, next Friday's sort finds them in one search rather than four. Then tell the desk: "label printer power cycles are problem 3, link them". The hunt gets faster every month it is done, because the desk's words converge. The sort that took twenty minutes in month one takes ten by month three.

A Short War Story: The Slow Mornings at Stonebridge Insurance

Stonebridge Insurance's desk of four closed about sixty tickets over four months whose resolution notes all said some version of "slow this morning, restarted, fine by ten". The tickets were filed under E-mail, Network, Laptop and Other depending on what the requester had been trying to do when it stuck. Each was a short close. Each technician had seen a dozen or so. The category report never showed any one category moving. Omar, the newest technician, was given the Friday sort in his third month. Having no idea what was normal, he exported the quarter and sorted by the hour the ticket was logged. Fifty-one of the sixty had been raised between 08:30 and 09:30. The cause was the endpoint security full scan, scheduled by a predecessor to run at 08:30 on every machine, every day, at the moment the whole company logged in. Moving it to 12:30 took five minutes and the tickets stopped the following week. The four months had cost roughly a quarter of one technician's time, plus an hour a morning of the claims team's patience. The pattern had been in a column nobody had ever sorted by.

The Repeat-Ticket Hunt Checklist

The checklist below is the Friday sort and the quarterly read on one page. It is written for a spreadsheet export because that works in any tool. But every step has an equivalent in a tool that can sort and filter its closed list. Fill in the top, tick the sorts as they are read, and write the tally at the bottom. The tally lines from the last four Fridays are the input to the weekly problem review. The whole sheet is twenty minutes on a normal week and the quarterly section is an hour.

REPEAT-TICKET HUNT — ONE PAGE
Desk: ______________   Week ending: __________   Hunter: ______________
Tickets closed this week: ____    Exported with: subject, requester,
category, time open, resolution note  [ ]

THE FOUR SORTS (read each one top to bottom)
  [ ] By subject          seen more than once: __________________________
  [ ] By resolution note  same fix more than once: ______________________
  [ ] By time open        closes under 10 minutes: ____  subjects: ________
  [ ] By requester        names appearing 3+ times: ______________________

THE SIX SEARCHES (tick the ones run this week)
  [ ] Fix words in notes: restarted ____  unlocked ____  reset ____
                          cleared ____  reconnected ____  power cycled ____
  [ ] By thing (device, server, room, application): ______________________
  [ ] By requester or site above its share: _____________________________
  [ ] Top ten by category read; biggest two piles opened: _______________
  [ ] Reopens this week: ____   fix that did not hold: __________________
  [ ] Short closes read: ____

TALLY (carry forward from last week)
  Symptom / fix                      last wk   this wk   total   since
  ________________________________   ____      ____      ____    ______
  ________________________________   ____      ____      ____    ______
  ________________________________   ____      ____      ____    ______

CANDIDATES (3+ this week, or 5+ on the tally)
  ________________________________   count ____   handed to: __________
  ________________________________   count ____   handed to: __________

QUARTERLY (once every three months, one hour)
  [ ] Quarter exported; day-of-week and hour columns added
  [ ] Sorted by weekday: cluster on __________
  [ ] Sorted by hour: cluster at __________
  [ ] Sorted by date: cluster on first working day / after patching / other
  [ ] Resolution notes read as one document; cross-category repeat: ________

Lena ran the sheet every Friday after that. By the fourth week it took twelve minutes, because the desk had started writing "label printer" and "problem 3" in the same note. The tally sheet from those Fridays became the problem list, and the problem list became the agenda for the weekly hour. The ninety-four tickets had always been there. What changed was that somebody read them.

Frequently Asked Questions