Ticket reopen rate is the share of resolved tickets that come back because the problem wasn’t really fixed. It’s the cheapest check you have on whether “closed” means “solved”. If your resolution numbers look great and your customers still sound annoyed, this is usually the number that explains the gap.
The measure pairs naturally with first contact resolution. First contact resolution tells you how often an agent fixed something on the first try. Ticket reopen rate tells you how often the agent only thought they had. You need both, because each one on its own is easy to flatter. I wrote recently about when customer service actually ends, and the short answer is: not when the agent clicks Resolve. Reopen rate puts a number on that.
Why should a help desk track reopened tickets at all?
Because every reopened ticket is a customer who believed you, then found out they shouldn’t have. They’ve lost time twice, and the second contact is almost always angrier than the first. A desk that closes 1,000 tickets a month with 9% coming back has done 910 tickets of lasting work, and it has 90 customers who now trust its “resolved” email a little less.
There’s a process reason too. ITIL V3 treats closure as its own step: the incident closure and evaluation stage includes verifying that the users are satisfied before the record is closed. Ticket reopen rate is the evidence of how well that check is actually happening on your desk, rather than how well the process document says it happens.
How do you calculate ticket reopen rate?
The formula is simple. The definitions are where people go wrong.
Ticket reopen rate = tickets resolved in the period that were reopened within the window ÷ all tickets resolved in the period
Three decisions make or break it.
First, count by resolution cohort, not by reopen date. Take every ticket resolved in October and ask how many of those came back. Don’t count “reopens that happened in October”, because half of those belong to September’s work and you’ll end up blaming the wrong week, and sometimes the wrong agent.
Second, set a fixed window. I use seven calendar days from resolution. A ticket that comes back on day three is a failed fix. A ticket that comes back after five weeks is usually a new problem on an old thread, and counting it punishes whoever happened to touch the original. Pick your window, write it down and don’t change it mid-year, or your trend line breaks.
Third, count each ticket once. A ticket reopened three times is one failed resolution for this metric. The repeats matter, but track them separately as a list for review, not as extra points in the rate.
That cohort approach has one cost: you can’t report October’s reopen rate until the seven-day window has closed on the last ticket resolved on 31 October. In practice that means the number is ready on 8 November. Tell people that up front so nobody asks why it’s late.
What should you exclude from reopened tickets?
Most help desk tools reopen a ticket whenever the customer replies to it. That includes “Thanks, all working now.” If you count those, you’re penalising the agents whose customers are polite enough to say thank you.
Here’s an illustrative month: 1,240 tickets resolved, 93 reopened within seven days. That’s a raw reopen rate of 7.5%. When the team reads the 93, 31 turn out to be thank-you notes, out-of-office auto-replies or a customer replying to the wrong thread. Take those out and you have 62 genuine reopens, a rate of 5.0%. Same desk, same month, and a two-and-a-half-point difference purely from definitions.
Exclude:
- Thank-you and acknowledgement replies with no new request in them
- Automatic replies (out of office, mail delivery failures)
- Replies that belong to a different issue, which should be split into a new ticket
Don’t exclude:
- “It worked for a day and now it’s broken again”
- Tickets the customer reopened because nobody explained the fix
- Tickets reopened by your own staff because the first agent closed them too early
That last group is the one people want to hide, and it’s the most useful. If the exclusion rules are vague, the exclusions will grow every month. Keep the list short and agree it in your weekly metrics meeting before anyone sees agent-level numbers.
How do you build it in Excel?
Export one row per resolved ticket from your help desk tool. You need four columns, and a fifth you fill in yourself.
| Column | Contents |
|---|---|
| A | Ticket ID |
| B | Date resolved (first resolution) |
| C | Date first reopened (blank if never) |
| D | Days to reopen: =IF(C2="","",C2-B2) |
| E | Exclude: type Y for thank-you or auto-replies, leave blank otherwise |
Put the first day of the month in H1 and the first day of the next month in H2. The reopen rate for that month is:
=COUNTIFS(B:B,">="&H1,B:B,"<"&H2,D:D,"<=7",E:E,"<>Y")/COUNTIFS(B:B,">="&H1,B:B,"<"&H2)
Using “less than the first of next month” in H2, rather than “less than or equal to the 31st”, stops you losing tickets resolved during the last day when your export carries a time as well as a date. Tickets that never reopened have an empty text value in column D, so the "<=7" test skips them. Format the cell as a percentage. Check it against a hand count for one week before you trust it; if the formula and your count disagree, the problem is nearly always tickets with a blank or text resolution date.
Then split it by agent.
| Agent | Resolved | Reopened (7 days) | Reopen rate | Resolved and stayed resolved |
|---|---|---|---|---|
| A | 290 | 8 | 2.8% | 282 |
| B | 380 | 9 | 2.4% | 371 |
| C | 410 | 37 | 9.0% | 373 |
| D | 160 | 8 | 5.0% | 152 |
These figures are illustrative. Agent C tops the resolved count by 30 tickets, the person everyone assumes is the star. Look at the last column and C and B have done almost exactly the same amount of lasting work, except C has sent 37 customers back round the loop to get there. Start with a coaching conversation about what C checks before clicking Resolve, and leave discipline out of it.
Be careful with small numbers. With 40 resolved tickets, a single reopen moves an agent’s rate by 2.5 points, which is the same sampling trap I described for call monitoring sample sizes. Look at agent-level reopen rates over a quarter, not a week.
What target should you set, and how does it get gamed?
I don’t believe in a universal number for this one, because ticket mix drives it. A desk that mostly resets passwords should see very few reopens. A desk handling integration faults for business customers will see more, because some fixes can only be confirmed once the customer runs their next batch job. Set the target from your own baseline: measure three clean months with the exclusions above, then aim to bring your highest agents down towards your median rather than picking a figure from a vendor slide.
Then watch for the ways it gets beaten.
The first trick is a new ticket instead of a reopen. The agent asks the customer to “log a fresh ticket for that”, and the reopen disappears. Catch it by also counting repeat contacts: a new ticket from the same customer, in the same category, within seven days of a resolution. This only works if your ticket categories are consistent, so fix those first.
The second is parking in pending. Tickets sit in “waiting for customer” until the customer gives up, then auto-close. Nobody reopens a ticket they’ve stopped caring about. Track how many tickets close through auto-close and how long they waited, side by side with the reopen rate.
Then there’s never closing at all. If agents are scored hard on reopens, some will simply keep tickets open longer. Your reopen rate falls and your backlog quietly grows. This is why I never show reopen rate without resolution time next to it.
And some desks make reopening impossible. Some tools let an administrator stop customers reopening resolved tickets. It makes the metric look perfect and moves the problem into angry new tickets. Leave reopening switched on.
The most useful thing to do with reopened tickets happens away from the report. Pull ten each week, read them with the agent who closed them, and ask one question: what would you have needed to know to fix this the first time? The answers will tell you more about your knowledge base and training gaps than any rate ever will.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
