The Stale-Ticket Sweep: Three Questions per Ticket

Thursday, 15:00, at Acme's desk of three. Rosa has forty minutes blocked in her calendar under the word "sweep", which her colleagues have learned not to book over. She filters the queue to Awaiting Reply and scrolls to the bottom. Ticket 5583, "Projector in meeting room 2 flickers", untouched for twenty-three days. She opens it and reads the last message. It was her own question to the facilities coordinator about whether the flicker happened with the laptop unplugged. She sees no answer. Three questions, two minutes, one decision, and she moves to the next one. By 15:40 fourteen tickets have left the stale end of the queue and none of them has been closed quietly.

A stale ticket is one nobody on the desk has touched for longer than its follow-up rhythm allows. On most small desks that means fourteen days, or three for anything High or above. The stale-ticket sweep is a fixed weekly pass through every ticket in that state, asking the same three questions of each and leaving each one in a different condition than it was found. It is the ongoing habit that stops a queue from needing a rescue. This article is part of our Ticket Aging & Follow-Up Discipline series, and it is the practical centre of it.

It covers why the sweep is weekly and not daily, who runs it and when, and how to build the sweep list in any tool. Next come the three questions, one at a time, with what each answer leads to. Then come the six ways a ticket can leave the sweep, the note that records what happened, and the rules that keep the sweep honest. It ends with a forty-minute worked example and a checklist to run it by until it becomes a habit that no longer needs one.

Why a Sweep and Not a Daily Glance

The daily glance and the weekly sweep do different jobs. And a desk that tries to do both with one habit ends up doing neither. The daily glance is about today: what is due, what is breaching, what arrived overnight, what the requester chased. It is fast, it is shallow, and it is supposed to be. The sweep is about the tickets that have fallen out of today altogether. Those are the ones that are not due, not loud and not new, and are therefore invisible to a glance by design.

Stale tickets are invisible because nothing about them changes. A queue sorted by anything useful puts the active tickets where the eye lands and the dormant ones where it does not. The requester has stopped chasing. The countdown has either expired or was never set. And the ticket has settled to the bottom of whatever list it is in. Nothing will bring it back up except a person deciding to go and look. The sweep is that decision, made once and put on a calendar so it does not have to be made again.

Weekly is the right interval for a reason that has nothing to do with convenience. The threshold for stale is about two weeks. And a weekly pass means every ticket that crosses the threshold is seen within seven days of crossing it. That is soon enough to still remember what it was about. Fortnightly means a ticket can be untouched for a month before anyone notices; monthly means the sweep turns into a dig-out. Daily is too often, because tickets do not go stale by the day. A sweep with nothing in it is a sweep that gets skipped the following week.

The sweep is also the aging half of a broader weekly queue routine, which covers unassigned tickets, wrong departments, duplicates and the rest of the things a queue accumulates when nobody is looking. That broader routine is described in Queue Hygiene: A Weekly Routine. Run them together if the desk is small and the queue is short. Run the sweep on its own if either is not, because the sweep has a single question behind it and the general routine has a dozen.

Who Runs It and When

One named person runs the sweep, at a fixed time, in a calendar slot that is defended like a meeting with a customer. On a desk of one the person is you. On a desk of two to five it is whoever runs the desk, or it rotates weekly with the name written down a month ahead. On a desk larger than that, each technician sweeps their own tickets and the desk lead sweeps the unassigned ones, in the same hour. That way, "I thought you had it" cannot survive the afternoon.

Thursday afternoon is the best slot on most desks, for three practical reasons. The week's new tickets have mostly arrived and been triaged by then, so the sweep is not competing with intake. There is still Friday to act on anything the sweep turns up. So a next step decided on Thursday can be done before the weekend. And a Thursday sweep produces a Friday-morning answer to the question every manager asks on Friday morning, which is whether anything is being neglected. Monday sweeps get cancelled by Monday. Friday sweeps get cancelled by the weekend. Thursday it is.

Forty minutes is the budget for a desk of up to five people with a queue under about two hundred open tickets. If the sweep regularly needs longer, the threshold is too tight for the desk's capacity, the follow-up cadence is not being kept during the week, or the queue has grown past what a sweep can hold. The first two are fixed in this series. The third is a backlog, and a backlog is dug out rather than swept. The Backlog Recovery series is the one for that, and the sweep is what you start the week the dig-out ends.

Building the Sweep List

The sweep list is every open ticket whose time since last desk touch is past the threshold. And the way to get it depends on the tool. The clean way is a saved view or filter. In that view, status is any of the open states. Last updated is more than fourteen days ago. Tickets are sorted oldest-touch first. The next best is an export of open tickets with their last-updated date into a spreadsheet, sorted the same way. The rough way, which works on any tool, is to filter the queue to one status at a time and scroll to the untouched end. What "last touch" means, and why it is the clock to use here rather than the date opened, is set out in What Ticket Age Actually Measures. The short version is that the sweep looks for silence, not for length.

Sweep by status, in a fixed order, because the three questions have different likely answers in each. Start with Open tickets that are assigned, because a ticket somebody owns and has not touched is the kind most likely to be avoided rather than waiting. Then Awaiting Reply, where the likely answer is a quiet requester. Then On Hold, where the likely answer is a vendor or a date that nobody has checked. Finish with anything unassigned and old, which should be a short list on a healthy desk and a loud one on an unhealthy one. In most tools each pass is a filter on one status and a scroll to the untouched end. If the filter shows a count beside each status, as many do, the count tells you how long the pass will be before you start it. Keep a standing view for unassigned tickets as well, whatever your tool calls it, because unassigned and old is the pass that must never be skipped.

Resist the urge to tidy the list before sweeping it. The list is going to be untidy, because it is made of the tickets that have been neglected, and tidying it is a way of not starting. Open the first ticket at the untouched end and ask the first question.

Question One: Is This Still a Problem?

The first question is whether the thing the ticket was opened for still needs doing. A surprising share of stale tickets are not problems any more. The requester left. The laptop was replaced. The flickering projector was in a room that has since been turned into storage. The report that would not export was for a process the finance team retired at the last quarter end. Nobody told the desk, because nobody tells the desk, and the ticket has been faithfully waiting for a world that moved on.

Read the ticket before deciding, and read it to the end, because the answer is often in a reply the desk never acted on. Then check the three things that most often make a ticket moot. Check whether the requester still works there (the directory will say), and whether the device or system in the subject still exists. Check whether a newer ticket from the same person covers the same thing. If any of those says the problem is gone, the ticket is closed with a reply that says so. That is the only acceptable way to close a ticket from the sweep. Never close silently. Not even the obvious ones. The requester who left still has a manager who may be wondering.

If the answer is "probably still a problem", confirm it rather than assuming. One line to the requester: "This has been open a while with no recent news. Is this still happening, and if so, when did you last see it?" That line is a touch. It sets a date for the requester to answer by. It converts a stale ticket into one with a clear owner of the next move. The wording that gets such lines answered is the subject of Follow-Up Messages That Get Replies. If the answer is "no idea and the requester is unreachable", the ticket goes down the third road: a close with the door open, explained below.

The sweep is not the place to feel bad about how long a ticket sat. The guilt costs a minute per ticket and buys nothing. Ask the question, write the answer, move.

Question Two: Whose Move Is It?

The second question is who has to do something before this ticket can move. And the honest answers are a short list: the desk, the requester, a vendor, another team inside the organisation, or someone who has to approve or decide. A stale ticket is very often stale because that question has no written answer, and everybody involved believes the move belongs to somebody else. The ticket is in Awaiting Reply, so the desk thinks it is the requester's. The requester answered three weeks ago, so they think it is the desk's. Nobody is wrong, and nothing is happening.

The status should answer this question, and when it does not, the sweep fixes the status before anything else. A ticket in Open that is actually waiting on a supplier's delivery date goes to On Hold with the date in the note. A ticket in Awaiting Reply where the requester has in fact replied goes back to Open and to the top of somebody's list. That is because it has been the desk's move for however long the reply has sat there. The distinctions between waiting on a user, waiting on a vendor and being on hold for a date matter more here than anywhere else in the ticket's life. They are the subject of their own article in the workflow series. For the sweep, the rule is that the status must name whose move it is, and if it cannot, the move is the desk's.

When the move belongs to somebody outside the desk, the second question has a second half. Have they been told, recently, in a way that asked for something specific by a date? A ticket that is waiting on a vendor who was last contacted a month ago is not waiting on the vendor. It is waiting on the desk to contact the vendor. The same goes for the requester and the approver. "Whose move" is only an honest answer if the person whose move it is knows that, and the sweep checks.

Statuses, like tickets, go stale. A ticket can sit in Awaiting Reply so long that the status becomes a description of the past rather than a statement about the present. (It was waiting on the requester, once, in the spring.) Reading the history to the end is how the sweep tells the two apart.

Question Three: What Is the Next Step, and When?

The third question is what, specifically, happens next, who does it, and by what date. This is the question most stale tickets have never been asked. And it is the one that turns a stale ticket into a live one. "Investigate further" is not a next step. "Check the event log on the meeting room PC on Friday morning while the projector is on, Rosa, by Friday 12:00" is a next step. The test is whether a colleague reading the note cold could do the thing without asking anyone.

The date is not optional, and it is the part the sweep is strictest about. A next step without a date is a wish, and the ticket will be back in next week's sweep with the wish intact. The date can be generous. A part with a four-week lead time gets a next step of "chase supplier if not delivered" dated four weeks out. The ticket goes On Hold until then. That is a perfectly healthy ticket. What it cannot have is no date, because no date means no one will look at it again until the sweep does. The sweep is a safety net, not a plan.

When the third question has no answer, that is itself an answer, and an important one. A ticket for which nobody on the desk can name a next step is either beyond the desk's ability, beyond the desk's authority, or not really a ticket at all. In the first case, it needs escalating for help rather than more time. In the second, it needs a decision from whoever has the authority. In the last, it needs closing honestly. How to close a ticket the desk cannot fix, without pretending it was fixed and without abandoning the requester, is covered in Closing the Ticket You Cannot Fix. The sweep does not write that close; it identifies that one is needed and puts a date on it.

The Six Ways a Ticket Leaves the Sweep

Every ticket in the sweep leaves it in one of six conditions, and the sweep is not finished with a ticket until one of them applies. The table is the reference; the paragraphs after it are the reasoning. The sixth row is the one that worries new desk leads most. It is also the one that most often turns out to be the right answer.

"Worked" is the outcome to be careful with. The sweep is a review, not a work session. And a sweeper who starts fixing the first ticket will be on it at 15:40 with thirteen left. The ten-minute rule is there to protect the rest of the list. If the next step is longer than that, it becomes a dated next step for tomorrow. In that case, the sweeper moves on. The point of the sweep is that every stale ticket gets a decision. The point is not that every stale ticket gets fixed on Thursday, which would be lovely, and will not happen.

"Reassigned" needs one courtesy. A ticket handed to a colleague from the sweep arrives with a note that says what the next step is and why they are the right person. The colleague is told in person or by message, not left to discover it. A ticket that appears in somebody's list with no explanation is a ticket they will avoid, and avoidance is how it went stale in the first place. Most tools e-mail or badge an agent when a ticket is assigned to them, which covers the notification. The note explaining why is still yours to write, and the word in person is still worth saying.

"Closed with a reply" is the outcome new desk leads flinch from, because it feels like admitting defeat on a ticket the desk has already failed to act on for a month. It is the opposite. A ticket closed with an honest reply, and a door that opens again if the requester answers, is a ticket the requester can trust. A ticket left open and untouched for another month is a ticket the requester has already stopped trusting. Where a requester's reply on a resolved or closed ticket reopens it automatically, which many tools do, the close carries no risk. In that case, if they come back, the ticket comes back, with its history. Where the tool needs a status change by hand, the rule is that a reply on a closed ticket is reopened the same day by whoever sees it, and never answered as a new ticket.

The Sweep Note

Every ticket that passes through the sweep gets an internal note in a fixed shape, three lines, written in under a minute. The first line is the three answers: still a problem (yes, no, asking); whose move (desk, requester, vendor, other team, approver); next step with owner and date. The second line is which of the six outcomes applied. The third line is the word "sweep" and the date. That way, a future reader of the history, which may be you, can see at a glance that the ticket was reviewed, when, and what was decided.

The note is internal because it is a desk record, not a message to the requester. And it is a note rather than a status change because a status change alone records nothing about why. An internal note, the kind of entry most tools offer that the desk can see and the requester is never sent, is the right place for the three answers. The requester gets the public reply, if one is needed, and the desk gets the reasoning. Check once that your tool's internal notes really are internal before you write anything in one you would not want the requester to read. Two years from now the reasoning is the part that is worth having.

The note also has a quiet second purpose: it is a touch. A ticket that has been reviewed, decided and dated is no longer stale by definition. It drops out of next week's sweep list unless the date passes without action. That is the mechanism by which the sweep list gets shorter week by week, and the reason it should never be gamed. A sweep note that says "reviewed, no change" with no next step is a reset of the clock without a decision. And the ticket will be back in a fortnight, older and no wiser.

Rules That Keep the Sweep Honest

Five rules, and the desk writes them on the checklist so that they are the desk's rules and not the sweeper's mood. First, no ticket leaves the sweep untouched. Every one gets one of the six outcomes and the note, even if the outcome is "dated" and the date is next week. Second, nothing closes silently. A close from the sweep is a reply to the requester, every time, including when the requester has left the organisation. The reply goes into the history and the history is what the next person reads. Third, the clock is never reset without a decision. "Reviewed" is not a touch. Fourth, the ten-minute rule: the sweep decides, it does not do, except for the small things. Fifth, the sweep ends on time, and anything not reached is first in the list next week. There is a note in the sweep log saying how many were left.

There is one more rule that is not about the sweep and is enforced by it. Tickets are never deleted, by anyone, for any reason. A ticket created by mistake, a duplicate, a test somebody forgot about: these are closed with a line saying what they were, or merged into the ticket they duplicate. They stay in the record. Some tools allow deletion and some never do, and the rule is the same either way. A merge in most tools cannot be undone, and many only allow it between tickets of the same requester. So the sweep merges carefully and closes freely. A queue nobody deletes from has an honest history, which is the only kind worth sweeping.

A Forty-Minute Sweep at Acme

Here is Rosa's Thursday sweep in full, fourteen tickets, 15:00 to 15:40, with the outcome for each. The outcomes in the table are abstract until you have seen a real list leave through them. Acme is a desk of three supporting about a hundred and ten staff across two sites. It has a stale threshold of fourteen days and a queue of 131 open tickets on the day.

Open and assigned, five tickets. Two had a next step the owner could name on the spot and had simply not written down. Both got a dated note and stayed with their owners. One was waiting on a supplier's delivery that the owner had been chasing by phone without noting it. That ticket went On Hold with the delivery date and a chase date three days after it. One had been assigned to a technician who, on being asked, said "I have no idea where to start with that". That ticket went to the escalated-for-a-decision row with a note to the desk lead and a pairing session booked for Monday. One was a duplicate of a newer ticket from the same requester and was merged into it.

Awaiting Reply, six tickets. Three got a nudge. It included a specific question, a date the following Wednesday, and a line saying the ticket would close if there was no answer, with a reply reopening it. Two were for requesters who had left, which the directory confirmed. Both closed with a reply addressed to the ticket, stating that, so that a manager searching later would find the reason. One, the flickering projector, had a reply from the facilities coordinator that had arrived nineteen days earlier and been missed. It went back to Open, the desk's move, with a next step dated Friday morning and a short apology in the public reply.

On Hold, two tickets. One was waiting on a budget decision that had been made a month before, which nobody had told the desk. It went to Open with the purchase as the next step. The other was waiting on a vendor case, which on checking the vendor's portal had been closed by the vendor three weeks earlier for lack of a response. It got a vendor nudge with the case number and the original promised date. It also got a note to escalate within the vendor if there was no answer by Tuesday. Unassigned and old, there was one ticket, a request for a new mailbox that had arrived during a holiday week and fallen through. Rosa claimed it and did it, which took eight minutes and was the only "worked" of the afternoon.

Fourteen in, fourteen out: five dated, three nudged, three closed with a reply, one reassigned by escalation, one merged, one worked. Forty minutes. Next Thursday's list was nine, and the Thursday after that it was six. The list does not go to zero, and a sweep that finds nothing is usually a threshold that is too loose. Six is about right for a desk that size. Six is a sweep that takes twenty minutes and leaves time for the coffee it was supposed to be accompanied by.

A Short War Story: The Vendor Who Went Home at Meridian Parts

Meridian Parts, a distributor with a warehouse of thirty pickers and a desk of two, had a ticket for a label printer that produced unreadable barcodes about one time in five. The ticket had been On Hold "with the vendor" for seventy-one days when Hal ran the desk's first sweep. The vendor's case, when he looked it up, had been closed forty-four days earlier with the note "no response from customer". That was because the vendor had asked for a diagnostic file that nobody at Meridian had seen the request for. For those ten weeks the warehouse had been hand-checking every fifth label and rewriting the bad ones, which the warehouse manager estimated at three hours a day across the shift. The warehouse had stopped mentioning the problem to IT because the ticket said the vendor was on it. Hal reopened the vendor case with the file the same afternoon and the printer had a firmware fix inside a week. The cost was roughly a hundred and fifty hours of warehouse time and a warehouse manager who, for a while, preferred to fix things himself. The lesson was the second sweep question. A ticket waiting on a vendor is still the desk's ticket, and "whose move" is only true if the vendor knows it is theirs.

The status had said On Hold for seventy-one days, accurately. It had just stopped being true after the first twenty-seven.

The Sweep Checklist

The checklist below is the sweep on one page: the setup, the three questions, the six outcomes and the note, in the order they happen. Print it and keep it beside the keyboard for the first six weeks, after which it will be in your hands and you can stop. The log line at the bottom goes into a shared note or a spreadsheet, one row per week. The log line is the record a manager will ask for when they ask whether the sweep is working.

STALE-TICKET SWEEP — ONE PAGE
Desk: __________________  Sweeper: ____________  Day/time: ____________
Stale threshold: ____ days since desk touch (High and above: ____ days)

BEFORE YOU START
  [ ] Calendar slot protected; nothing else booked over it
  [ ] Sweep list built: open statuses, last desk touch over threshold,
      oldest touch first
  [ ] Count noted: Open/assigned ____  Awaiting Reply ____  On Hold ____
      Unassigned ____   Total ____

FOR EACH TICKET (two minutes; read the history to the end)
  1. Still a problem?        [ ] yes   [ ] no   [ ] ask the requester
     Requester still here? [ ]  Device/system still exists? [ ]  Newer duplicate? [ ]
  2. Whose move?             [ ] desk  [ ] requester  [ ] vendor
                             [ ] other team  [ ] approver
     Does the status say so?  [ ] yes   [ ] fixed it
     Have they been asked, with a date, in the last cadence?  [ ] yes  [ ] no
  3. Next step:  what ______________________  who ________  by ________
     Could a colleague do this from the note alone?  [ ] yes

OUTCOME (exactly one)
  [ ] Worked (under ten minutes)      [ ] Nudged (question + date + consequence)
  [ ] Dated (On Hold until ______)    [ ] Reassigned (new owner told, note why)
  [ ] Escalated for a decision        [ ] Closed with a reply (door open)

THE NOTE (internal, three lines)
  Line 1: still a problem / whose move / next step, owner, date
  Line 2: outcome
  Line 3: "sweep" + today's date

RULES
  No ticket leaves untouched.   Nothing closes silently.
  No reset without a decision.  Decide, do not do (ten-minute rule).
  End on time; what was not reached goes first next week.

LOG LINE
  Week of ______: in ____ / worked __ nudged __ dated __ reassigned __
  escalated __ closed __ / not reached __ / oldest touch at start ____ days

The checklist shrinks with use. By the second month most desks have stopped reading the questions and kept only the counts and the log line, which is the right end state. The questions have become the way the desk looks at a stale ticket, and the log is the evidence. If the log line shows "not reached" growing three weeks running, the threshold or the slot needs changing. In that case, the log is what you take to the conversation about which.

Thursday, 15:00, the following week. Rosa filters to Awaiting Reply, scrolls to the bottom, and finds nothing older than eleven days. The projector ticket is Resolved, with the facilities coordinator's reply thanking her, nineteen days late and entirely welcome. Nine tickets this week, then six. The sweep has not fixed the desk. It has made the desk impossible to ignore from the inside, which is the thing a stale queue was relying on.

Frequently Asked Questions