Declaring Ticket Bankruptcy Carefully, Without Burning Trust

The message went out at 16:50 on a Friday, to everyone. "Hi all, as part of our backlog clean-up, all tickets older than 90 days have been closed. If your issue is still a problem, please raise a new ticket. Thanks, IT." Three hundred and ten tickets changed status in the same minute. Nobody on the desk read any of them. The technician who sent it went home feeling lighter than he had in a year. On Monday at 08:40 there were a hundred and forty replies in the shared mailbox, sixty of them angry, two of them from directors. One was from the finance manager, who had been waiting since the spring for a report export that the auditors now wanted by Wednesday. The backlog was gone. So was the next six months of goodwill.

Jonas inherited that desk a year later, and the message was still being quoted at him in meetings. It is the reason this article exists. Bankruptcy is sometimes the right call, and it is always a dangerous one. The difference between the version that works and the version that gets quoted at your successor is almost entirely in how it is done.

Ticket bankruptcy is the deliberate closing of a defined set of old, abandoned tickets in one pass. Every requester gets a reply saying what has happened and how to get the request back if it is still needed. The name is borrowed from the financial kind. The desk admits it cannot pay every old promise, says so in public, and starts again with a clean ledger and a reputation to rebuild. This article is part of our Backlog Recovery series. The pile bankruptcy operates on is the "probably dead" row of the inventory from Taking Stock Before You Dig. Bankruptcy usually happens on day two of The Dig-Out Plan.

It covers what bankruptcy is and what it is not, then the tests that say whether it is justified. Next come the temptations that say it is when it is not, and what never to bankrupt. We cover the message, line by line, then the invitation to re-raise and the way back. Next come the mechanics of doing it in an afternoon, measuring what it cost, and the announcement text to copy.

What Bankruptcy Is, and What It Is Not

Bankruptcy is a close with a reason and a reply, applied to a set, not a bulk status change applied to a date. The set is chosen ticket by ticket from the inventory. These are tickets that have been abandoned, by the evidence, and that the desk has decided not to chase individually. Every one of them gets the same carefully written reply, which says what happened and how to come back. The requester finds out from the desk, not from a status, and not from a colleague.

It is not deletion. Some tools allow tickets to be deleted and some never do, and the rule is the same in both: close, never delete. A closed ticket keeps its history, its requester, and its subject. That means the desk can find it when the requester replies and can count it when the reopen rate is measured. The desk can show it to an auditor who asks what happened to the request from the spring. A deleted ticket is an argument you cannot win, because the other side has the e-mail and you have nothing.

It is not the silent close, which is the status change with no reply. Silent closes are the quiet failure described in Avoiding the Silent Close. A silent close applied to three hundred tickets on a Friday afternoon is the same failure at scale, with a press release. In many tools a status change on its own sends the requester nothing. In others it sends an automatic line that says "your ticket has been closed" and nothing else. That is worse, because it looks like a decision without a reason. The reply is the bankruptcy. The status change is paperwork.

And it is not a way to make the number look good. The count will fall, which is pleasant, and it will fall again next year if the only thing that changed was the count. Bankruptcy clears the past. It does nothing about the inflow, the closing discipline, or the chase rule that let the past pile up. And a desk that bankrupts without fixing those is scheduling the next bankruptcy. The habits that stop that are in Keeping the Backlog From Rebuilding. Bankruptcy buys the time to build them. It is not a substitute.

When It Is Justified

Bankruptcy is justified when four things are true at once, and the inventory is where you check them. First, the tickets are old by the desk's own standard. Over ninety days is the usual line, and nothing under thirty days is ever in the set. Second, there is evidence of abandonment, not just silence. The requester has left, the system was replaced, or the request was overtaken. Or the last message was from the desk asking a question that was never answered. Third, the set is large enough that chasing each one individually would cost more than the dig-out has, usually more than fifty tickets. Fourth, the desk has decided, in writing, that it will not do these individually, and someone with the authority to accept the risk has agreed.

The first two tests do the work; the second two stop you doing it for the wrong reasons. A set of thirty abandoned tickets does not need bankruptcy; it needs an afternoon and a chase. A set of three hundred that a manager has merely agreed to "tidy up" is not a decision. It is a shrug with a date. The table below is the decision for each kind of old ticket, and bankruptcy is the right answer in only one row.

Notice that the Awaiting Reply row, which is usually the biggest pile in the inventory, is not bankrupted straight away. It gets one chase with a date, and the bankruptcy close happens only after the date passes. That chase is the difference between "we gave up on you" and "we asked twice and heard nothing", and requesters forgive the second one. It costs one predefined reply and nine days. Skipping it saves nine days and costs the desk's reputation with everyone who was about to answer.

When It Is Not Justified

The commonest wrong reason is that the number is embarrassing and a meeting is coming. A backlog of four hundred, a quarterly review on Thursday, and a bulk close on Wednesday evening is not a bankruptcy. It is a cover-up with a status change. And the review will find out the week after, from a director whose ticket was in the set. If the number is embarrassing, the honest move is to present the number with the inventory and the plan. The last article in this series covers that. In that case, bankrupt the dead tickets inside the plan, in daylight, with a reply each.

The second wrong reason is that management asked for it. "Just close everything old" is a sentence managers say because they want the problem gone. It is the desk's job to translate it into something that will not come back. The translation is "we will close the dead ones with a message, chase the waiting ones with a date, and do the live ones; here is the inventory that says which is which". A manager who hears that almost always prefers it, because the alternative is their name on the Friday message.

The third wrong reason is that the backlog is fresh. A pile that is mostly under ninety days old is not abandoned. It is behind, and the people in it are still waiting with some hope. Bankrupting a sixty-day-old ticket tells the requester that the desk's attention span is shorter than their patience. That is not a message any desk wants to send. A fresh backlog is a dig-out without a bankruptcy step, and it is harder, because there is nothing to close by decision. (It is also, in my experience, the version people most want to bankrupt, for exactly that reason.)

The fourth wrong reason is that the tickets are hard. Real work that nobody wants to do looks a great deal like abandoned work from a distance. A dig-out team in its second week, tired, behind the burn-down line, will start to see the two as the same thing. They are not. The test is simple: would the requester say the request is still needed? If yes, it is work, however old. The tickets everyone avoids are a subject of their own in the aging series. And they are avoided precisely because closing them feels like relief. The relief lasts until the reply.

What Never to Bankrupt

Some tickets are never closed by set, whatever their age, because the cost of being wrong is not a reopen but an incident. Keep a written list, check every bankruptcy candidate against it, and decide those tickets by hand with the decision recorded. The list below is the one I use; yours will have additions from your own organisation's history. And those additions are the most important lines on it.

• Anything about security: access that should have been removed, a suspected compromise, a device that was lost, a permission that looks wrong.
• Anything about data: a file that was lost, a backup that failed, an export someone is waiting for, a deletion request.
• Anything with money attached: a purchase that was approved, a licence that was requested, an invoice query, a refund.
• Anything with a legal, audit, compliance or HR angle, including anything a requester has said is for an audit.
• Anything raised about a leaver or a joiner, because access that was never removed or never granted does not become safe with age.
• Anything where the desk promised a date in writing and did not keep it; the requester is owed a conversation, not a template.
• Anything where the requester has already chased twice; a third silence followed by a close is the Friday message in miniature.
• Anything that is really a project, a change or a problem record, which belongs outside the queue and should be moved there, not closed.

Checking the list against three hundred candidates takes one person about two hours, reading subjects and last messages. It is the best-spent two hours of the dig-out. Most candidates pass in seconds. The ones that do not are the ones that would have been in Monday's angry replies. Finding them on Tuesday afternoon instead is the entire point. A list that produces zero exceptions on a pile of three hundred is a list that was not read carefully enough.

The Message, Line by Line

The reply on a bankrupted ticket does five things in five short paragraphs, and the order matters. It says what the desk is doing to this ticket, in the first sentence, so a reader who stops there knows. It says why, honestly and briefly, without blaming the requester. It says how to get the request back if it is still needed, in one action. It says by when the desk will respond to a re-raise, with a number. And it apologises, once, in one sentence, at the end, where it reads as sincere rather than as a preamble to an excuse.

The "why" is where messages go wrong. "Due to unprecedented ticket volumes" is a sentence that blames the weather. "We note you did not respond to our previous request for information" blames the requester, who did not know a reply was wanted and is now being closed for it. "As part of a process improvement initiative" blames nobody and means nothing. The honest why is short and owns the thing: "This ticket has been open for a long time without progress, and that is our failing. We are clearing old tickets so that we can give current ones the attention they need." It is not comfortable to write. It is the sentence that gets forgiven.

Never promise that it will not happen again unless you have changed something that makes it true. "We have put measures in place" is the industry's favourite empty sentence, and requesters recognise it. If the desk has started a weekly aging check and a closing rule, say so in one line. That line can be: "We now review every open ticket weekly and will not let a request go unanswered for more than a fortnight again." If the desk has not, say nothing about the future, because the next bankruptcy will be the proof.

Keep the whole thing under a hundred and fifty words. A long apology reads as a defence. A short one reads as a person. The requester has waited months for this message; they will not spend more than thirty seconds on it. And the thirty seconds need to land the first sentence, the one action, and the apology. Everything else is for the desk's benefit, and the desk's benefit is not what the message is for.

The Invitation to Re-Raise and the Way Back

The invitation is one action, and the action is "reply to this message". Not "raise a new ticket on the portal", not "contact the desk", not "let us know". A requester who has waited four months and been closed will do exactly one easy thing or nothing. And the easy thing has to put the request back in front of the desk with its history attached. Replying to the close does that in most tools, and it is the only invitation worth writing.

What happens to the reply depends on the tool, and this is a difference to test before the bankruptcy, not after. In many ticketing tools a requester's reply on a resolved or closed ticket reopens it automatically, by any channel. The reopen is counted, which is exactly what you want. The ticket comes back with its history, into the queue, with a number the desk can watch. In others, a reply to a closed ticket creates a new ticket, or is dropped, or lands in a mailbox nobody reads. Find out by closing a test ticket and replying to it from an outside address. If the reply reopens the ticket, the invitation is "reply to this message". If it creates a new one, the invitation is still "reply to this message". In that case, the desk's job is to link the new ticket to the old one by hand and read the history. If the reply is dropped, fix that before sending anything, because an invitation to a dead letterbox is the Friday message with better grammar.

Set a response promise on the re-raise and keep it. "If you reply, we will respond within two working days" is a small promise. Keeping it is how the desk proves the bankruptcy was a reset and not an escape. Put re-raised tickets at the front of the queue for a month; they have already waited. And a re-raise that then waits again is the one outcome worse than the original backlog. Count them. The count is in the next section.

Make it easy to re-raise and then do not be surprised by how few do. On a well-chosen set, with the never-bankrupt list applied and the Awaiting Reply chase done first, something like one in ten requesters replies. Most of those say "no longer needed, thanks". That is the evidence that the set was dead. A reply rate of one in three says the set was alive. In that case, the desk owes those people a faster response and itself a harder look at how the set was chosen.

Doing It in an Afternoon

The mechanics take an afternoon once the set is chosen, and the order protects you. First comes the list: ticket numbers, requesters, subjects, and the pile each came from, on one sheet. It has the never-bankrupt check marked done beside each. Second, the sign-off: one named person with the authority to accept the risk reads the sheet, not the tickets, and initials it. Third comes the message: written once, read by two people, saved as a predefined reply if your tool has those. It is sent on one test ticket to see what the requester actually receives. Fourth, the closes: each ticket gets the reply and then the closed status, in that order. That way nothing is closed without the message having gone. Fifth comes an internal note on each ticket, or a tag if the tool has tags, saying "closed under backlog bankruptcy" and the date. That way a reopen in six weeks is recognisable for what it is.

Send the replies in batches through the afternoon rather than all at once, and send them on a Tuesday or Wednesday morning, never on a Friday. Requesters reply within hours, and the desk needs to be there and fresh when they do. Three hundred messages at 16:50 on a Friday produce a hundred and forty replies to a mailbox nobody is watching. That is the one scenario this article is built to prevent. Fifty an hour from ten in the morning, with the cover technician reading the replies, produces a conversation.

Tell the organisation once, through management, on the same day. The organisation-wide note is short, and it goes from the IT manager rather than the desk. It says what was done, why, what to do if a request is still needed, and what has changed so that it does not recur. It does not list ticket numbers and it does not apologise more than the per-ticket message did. Its purpose is that nobody hears about the bankruptcy from a colleague first. The text is in the template at the end.

Then watch for thirty days. Every reply to a bankrupted ticket and every new ticket that says "I raised this before" goes on the same sheet as the original list. Every complaint about the message goes there too. At the end of the month the sheet says what the bankruptcy cost, in reopens, re-raises and conversations. That number goes in the brief to management as plainly as the number of tickets closed.

Measuring What It Cost

A bankruptcy is measured by what comes back, not by what went out. There are three numbers. The first is the share of bankrupted tickets that were reopened or re-raised within thirty days. The second is the share of those that turned out to be real work. The third is the number of conversations the desk had to have about the message itself, with a requester, a manager or a director. A healthy bankruptcy has a reopen share around one in ten, mostly "no longer needed", few real, and no conversations above the desk. Reading the reopen number properly, including what it means when it is high, is the subject of What a Reopen Is Telling You.

A reopen share above one in four means the set was alive. It is not a disaster if the desk responds to the reopens quickly and honestly, but it is a finding. It says the inventory's "probably dead" pile was guessed rather than sampled, or that the Awaiting Reply chase was skipped. Record it, respond to every reopen within the promised time, and do not bankrupt again until the inventory method has changed. A desk that bankrupts twice with the same error has told the organisation something about itself that the second message cannot undo.

A reopen share near zero is not automatically good news. It can mean the set was perfectly chosen, or it can mean the message did not reach anyone. Or it can mean the message reached them and they have stopped expecting anything from the desk. Check that the replies actually went (a test ticket to an outside address, again) and read the organisation's mood for a fortnight. Silence from a hundred people who were closed is sometimes agreement. It is sometimes the sound of a department that has started its own spreadsheet.

A Short War Story: The Nine Tickets at Redbrook Engineering

Redbrook Engineering's desk, three technicians supporting a design office and a small test laboratory, bankrupted 210 tickets over ninety days old in one afternoon. They sent a decent message and an invitation to reply, and the count looked wonderful on the Monday. Celine, the desk lead, had checked the set against the inventory but not against a never-bankrupt list, because the desk did not have one. Nine of the 210 were from the quality team about a data export from a laboratory instrument that they needed for a certification audit. Those tickets had been raised months earlier, chased twice, and quietly abandoned when nobody answered. The quality manager did not reply to the bankruptcy message; she had stopped expecting replies, and she took the problem to a contractor instead. The audit was passed with the contractor's export. The desk found out from the invoice. And the quality team did not raise a ticket for seven months. The cost was a contractor's bill and a department lost to a shadow channel. It also meant a lead who now reads the subject line of every bankruptcy candidate by hand. The lesson Celine wrote into the desk's procedure is that the never-bankrupt list exists for the tickets you do not recognise as important. The ones you do recognise were never going to be in the set.

The desk's list now has "anything the requester has said is for an audit" on it, in bold. It also has "anything chased twice", which would have caught all nine.

The Announcement Text

Two messages follow. The per-ticket reply goes on every bankrupted ticket. The organisation-wide note goes once, from the IT manager, on the same day. Replace the bracketed parts, keep the length, and send the per-ticket reply on a test ticket to yourself before sending it to anyone else. The second-to-last line of the per-ticket reply, about what has changed, is only kept if it is true.

PER-TICKET REPLY (sent on each bankrupted ticket, before it is closed)

Subject: Your request [ticket number]: closing old tickets

Hello [first name],

We are closing this request today. It has been open since [month]
without progress, and that is our failing, not yours.

We are clearing requests older than ninety days so that we can give
current ones the attention they need.

If you still need this, reply to this message and it will come
straight back to us with its history. We will respond within
[two] working days.

[What has changed: We now review every open request weekly and will
not leave one unanswered for more than a fortnight.]

We are sorry this one waited so long.

[Desk name]


ORGANISATION-WIDE NOTE (sent once, from the IT manager, same day)

Subject: IT support: clearing old requests today

Today the IT desk is closing [number] support requests that have been
open for more than ninety days without progress. Each person affected
is receiving a message on their request explaining this.

If one of those requests is still needed, replying to that message
brings it back to the desk, and we will respond within [two] working
days. Nothing has been deleted; the history of every request is kept.

This happened because the desk received more requests than it closed
for a long time, and we let the oldest ones go unanswered. [What has
changed, in one sentence.] Questions about this note can come to me
directly.

[Manager name]

Both messages are shorter than they feel they should be, and that is deliberate. The per-ticket reply must survive being read on a phone in a corridor by someone who has forgotten they asked. The organisation-wide note must survive being forwarded to a director with the comment "did you know about this?". Neither survives a paragraph about volumes, process, or the strategic roadmap.

Jonas's desk declared bankruptcy properly fourteen months after the Friday message, on a Tuesday morning, on 180 tickets. The chase was done, the list checked, the manager's note sent at eleven, and the cover technician was reading replies. Nineteen people replied. Fourteen said thanks, no longer needed. Four were real and were worked that week. One was from the finance manager, who wrote "this is a much better way of doing it", which, from her, was close to a commendation. The count fell by 180. The thing that mattered was that nobody quoted the message at anyone afterwards.

Frequently Asked Questions