Reopen Rate

A service team marks a case solved when it believes the issue is addressed, but a customer or agent may later reopen it, and reopen rate tracks how often that happens for a defined set of cases. Start with a cohort of tickets solved during a chosen period, count how many distinct tickets in that cohort reopen within an observation window, divide by the number solved and multiply by 100.

If 70 of 1,000 solved tickets reopen, the illustrative rate is 7%. Counting tickets once differs from counting every reopen event, and a single difficult case may reopen twice, so report which version is used.

A solved date alone may not be enough, because a case solved yesterday has had less time to reopen than one solved three weeks ago, so use a consistent follow-up window or allow a period to mature before comparing teams. Different systems handle "solved" and "closed" differently, as some allow reopen from solved status but require a new linked case after final closure, so read the platform's workflow before assuming its built-in reopened metric matches your chosen formula.

Zendesk, for example, provides a reopened-tickets report and can filter reopen activity by the role of the person updating a ticket, which matters if a team wants to separate customer-driven reopenings from agent corrections, though its reporting recipe is a product-specific example. A reopened ticket does not always mean the first answer was wrong, since the customer may supply new facts, add a related request or reopen accidentally, so sample cases and reasons before judging quality.

Still, a persistently high rate can signal premature closure, weak diagnosis or confusing instructions, and if teams are rewarded mainly for closing tickets quickly they may move unresolved problems out of the active queue, so review the incentive design. Confirming a fix can help when appropriate: for a technical failure a clear test or reproduction step provides evidence that the issue is gone, while for an information request a concise answer may be sufficient without extra customer work.

Do not leave every case open forever just to avoid reopens, because that makes backlogs and resolution times worse, so use reasonable closure rules and let a customer return easily if the issue persists. Segment by issue type, since a billing question may naturally attract a follow-up while a simple password-reset ticket might not, and comparing teams with different case mixes without adjustment can be unfair.

Look at the actual customer experience alongside the metric, because a low reopen rate might reflect satisfied customers but could also mean people cannot find a way to reply, so satisfaction, repeat contacts and escalation provide more context. One support process may automatically reopen a case when any customer message arrives while another makes a new ticket, and that configuration can change the ratio without changing service quality, so document routing changes.

Use a reason code or sample review to understand patterns, asking whether the fix was incomplete, the answer lacked clarity or a different problem was raised, so improvements match the cause. Track both the reopened cohort and case volume, because a change from five to ten reopens can double a small team's rate even when the absolute difference is modest, so show the numerator and denominator together.

Managers can use the measure to balance speed and durable resolution; it is an early warning signal, not a verdict on an individual agent, so coach from case evidence, not the percentage alone. Set a target only after establishing the workflow and normal case mix, then watch whether any process change reduces repeat work without making support slower or harder to reach.