An online store manager replied to a customer, marked the ticket as solved and moved on to the next one. The next day, the customer writes again: the refund has not arrived, and the previous message did not make it clear when to expect it. The team's report already shows one solved issue, but for the customer, the work is not finished.
Reopened tickets help reveal this gap. But a status change alone does not prove an agent made a mistake: someone may have said thank you, asked a new question or reported that the problem had returned. If these situations are mixed together, the metric will only put additional pressure on the team.
It is more useful to build a small, manageable process: agree on what counts as a reopening, measure it using consistent rules and investigate the causes. Below is a practical method for a support manager who wants to reduce unnecessary work, not just improve a number in a report.
What exactly counts as a reopened ticket
A reopening is the return of an already solved ticket to active work. Status names and the rules for this transition may differ from one system to another. So first describe the business event: the team considered the issue solved, but its involvement is needed again for the same reason.
Distinguish this from repeat contact. A customer may create a new ticket about the same unresolved problem — in that case, the old ticket's status does not change, even though there is additional work. Conversely, a “Thank you” reply may change the status without requiring another resolution. A technical counter and a quality assessment answer different questions.
Do not combine the number of tickets and the number of reopenings into a single metric either. One ticket may return to active work several times. The Zendesk metrics reference, for example, describes Reopened tickets and Reopens separately. This illustrates a difference in definitions, not the availability of similar reports in HelpDeskStar.
Write down a short rule for the team: how to handle thanks, a new topic in an old conversation, an accidental closure and the recurrence of the same fault. There is no need to keep an old conversation artificially open or hide a new problem inside the previous one just for the sake of statistics.
How to measure the rate without using the wrong denominator
For internal analysis, it is useful to take a cohort — a defined group of tickets — and observe each one for the same length of time. For example, select tickets first marked as solved during a particular week and check whether they return to active work within the next seven calendar days after each ticket's first resolution. Seven days is a working example here, not an industry standard.
Reopened ticket rate = number of unique tickets in the cohort that returned to active work within the defined window / total number of unique tickets in that cohort × 100%. The numerator and denominator must contain tickets from the same group. Count each ticket in the numerator once, even if it reopened more than once.
Do not divide all reopenings this month by all closures in the same month without qualification. Some reopenings will relate to older tickets, while the most recent closures will not yet have had enough time for observation. Such an ongoing operational report can be useful, but it is a different metric, not a cohort rate.
Wait for the full observation window
If the last ticket in the cohort was solved on Friday, a summary with a seven-day window can only be produced after that period has ended for that ticket. Until then, mark the report as preliminary. Otherwise, the latest week will almost always look better because customers have not yet had time to return.
Keep the total number of reopening events separately. It will show the workload involved: two teams with the same rate may have different numbers of cycles before final resolution. When assessing causes, it is also useful to include new tickets about the same problem, but do not silently mix them into the technical status metric.
For a small sample, always show absolute numbers alongside the rate. Primarily compare the same issue categories and the same observation windows. The overall figure may change simply because the team has started receiving more complex technical requests, not because its performance has worsened.
What data is needed to investigate causes
Start with the ticket history, not the agent's name. For each reopening, you need the ticket ID, issue category, time of first resolution, time of reopening, final reply before closure and the customer's next message. If the system has no ready-made report, a limited sample can be classified manually in a spreadsheet with links to the tickets.
Do not copy phone numbers, payment details or complete conversations into this spreadsheet unnecessarily. For management analysis, an ID, a brief description of the cause and access to the original restricted to authorized employees are usually enough. The spreadsheet should support the work, not create another uncontrolled customer database.
A few clear categories are enough for the first review:
- The problem was not fixed. An interim answer was given or the wrong scenario was checked.
- The answer is unclear. Conditions, a timeframe or the customer's next action are missing.
- Another department needs to act. Support closed the ticket before the result was confirmed.
- The problem occurred again. The initial solution worked, but the fault recurred.
- This does not require another resolution. Thanks, a new topic or an administrative status change.
Allow a “Cause not yet established” label. Forcing a situation into a convenient category creates false confidence. If there are several causes, choose the main one for the report and add a short clarification, without turning the classification into dozens of nearly identical options.
Review the conclusion with the person who handled the ticket
The manager should review the sequence of events and discuss it with the employee. The agent may have closed the ticket in accordance with the current instructions, while the instructions themselves did not account for a payment delay or a contractor's response. Punishing the person who handled it will not fix that cause.
Likewise, not every new message means poor quality. If a customer asks about another order in an old conversation, the new topic needs to be routed correctly. If they report a recurring fault, the durability of the solution needs to be checked. The same status does not make these situations identical.
How to reduce repeat contacts rather than hide them
For each common cause, identify one process change and the person responsible for it. When answers are unclear, improve the closing message. When dependent work is unfinished, change the condition for closure. When a product error returns, give the team that can address its source a specific description of the conditions needed to reproduce it.
The final reply should make clear what has been done, which result has been verified and what to do next. If an action is still in progress, state its status honestly and specify the agreed next contact instead of a formal “The issue has been resolved.” Do not promise an exact timeframe on behalf of another department unless it has been confirmed.
Templates and instructions are useful for common questions, but a template does not replace checking the specific case. A refund explanation must take the transaction's stage into account. Advice on access must include checking whether the user was actually able to sign in. An overly general answer is quick to send but often shifts the diagnostic work onto the customer.
Do not set the team a target of “zero reopenings” without assessing quality. Such a requirement may encourage people not to close solved tickets or to create new ones instead of reopening old ones. Alongside the repeat rate, review unfinished tickets, the time to actual resolution and the content of replies. A better number should mean less customer effort, not a different way of keeping records.
Example: refunds in an online store
A hypothetical team noticed that customers write again after receiving the message “The refund has been processed.” The review reveals two different situations: accounting has not yet confirmed the transaction, or the payment has already been sent but the customer does not understand what happens next. This is a training scenario, not a company case study with measured results.
For the first situation, the team changes the rule: the manager's message is not confirmation of a completed transaction. The ticket retains a responsible person, the action expected from accounting and the time of the next check. For the second, the reply is clarified: what exactly has already been done, the confirmed conditions for waiting and when to get in touch again if the money has not arrived.
After the change, two completed cohorts from this specific category are compared using the same observation window. The remaining reopenings are also read: a different cause may now predominate. A particular percentage improvement should not be promised in advance — it can only be established from actual data.
Which tools to choose and where HelpDeskStar can help
With a low volume of tickets and one person handling them, you can start with a manual log. It will let you test definitions and categories without a separate automation project. The limitations of this approach are the time required, the risk of missing an event and the difficulty of keeping the history consistent across employees.
When tickets arrive through different channels and require several people's involvement, it is important to retain context in a shared system. The article on choosing a helpdesk for a small business describes HelpDeskStar's basic capabilities: working with statuses, responsible people, communication history and internal tasks. These help organize the review process itself and the implementation of agreed actions.
Before implementation, test with your own scenario how the status changes after a customer's reply in your configuration, who receives that ticket and where previous actions are visible. Separately, establish whether you can obtain the data needed for the calculation. Having statuses does not in itself mean the system has a ready-made cohort report or automatically identifies the cause of a reopening.
There is no need to change the entire platform for the sake of one metric. If the current tool reliably stores the history and lets you collect the necessary data, fix the process first. But if context gets lost between chats and departments, the issue goes beyond analytics: the team needs a shared place to work on tickets.
Where a support manager should start
Choose one ticket category, agree on a definition of reopening and set a consistent observation window. Review a completed cohort, separate technical status transitions from the return of unresolved problems and find a cause the team can influence. Make one specific change and test it on the next comparable group.
If a shared history and clear responsibility are missing, discuss with the HelpDeskStar team a demonstration based on one of your repeat contacts. Check not an abstract number of features, but the entire path: the customer's return, restoring context, the agent's action and confirmation of the result.