Support Reporting
Part of Support reporting technology
Comparing reopened tickets with genuinely new issues
Classify why customers return, separate status changes from new problems and compare returned work using a consistent resolved-case cohort.
A reopened ticket is a system event. A genuinely new issue is a judgement about the customer's request. Read the return contact alongside the earlier case, then decide whether the original remedy failed, the customer supplied a related update or they raised a separate problem. A reopen count cannot make that distinction.
Classify the reason for returning
Use a small set of issue labels alongside the platform status:
| Return contact | Issue classification | Reporting treatment to consider |
|---|---|---|
| The original fault persists or the remedy did not work | Same issue, unresolved | Count as returned work on the original issue |
| The customer supplies information the team requested | Continuation | Keep with the existing issue; review before calling it a failed resolution |
| The customer sends only an acknowledgement | No new service issue | Keep out of an issue-failure rate |
| The customer raises a separate request in the old thread | New issue | Create or split a distinct work record if the workflow allows |
| The customer replies after the old record can no longer reopen | Inspect the linked follow-up | Classify its content before counting new demand |
These are proposed classification rules, not platform defaults. Agree on how to handle a message containing both an unresolved old problem and a new request. Let reviewers inspect the customer's wording while keeping unnecessary personal details out of an analysis sheet.
Reopened Tickets vs. Genuinely New Issues: Key Differences
- Reopened Ticket (System Event)A status change indicating a customer returned to a closed ticket; does not necessarily mean a new issue.
- Genuinely New Issue (Judgement-Based)A distinct customer problem identified after reviewing the return contact and original case.
- Same Issue, UnresolvedOriginal fault persists or remedy failed – count as returned work on original issue.
- New Issue in Old ThreadCustomer raises a separate request – create or split a new work record if allowed.
How to Classify Customer Return Contacts Correctly
- Review the return message alongside the original caseCheck for context, urgency, and whether it addresses the original resolution.
- Apply one of five classificationsSame issue unresolved, continuation, acknowledgement, new issue, or follow-up to closed case.
- Use platform features like 'Split Ticket' only for unrelated requestsFreshdesk’s Split Ticket function applies only when a response contains multiple issues.
- Keep system event separate from issue classificationRecord counts may differ—track both the reopen event and the actual issue type.
- Compare like with like in reportingUse a consistent cohort of resolved cases and define treatment for late returns.
Keep the system event separate
Zendesk Explore counts tickets reopened after being solved. A ticket solved and reopened within the same update is excluded from that metric. A response to a Closed Zendesk ticket creates a new follow-up ticket referencing the old one. Its new ID does not establish a new customer problem.
Freshdesk documents a Split Ticket option for a new or unrelated customer response on an existing ticket. That feature splits a customer response, not any message in the thread.
Record count and issue count can therefore differ. One unresolved issue may occupy an original and a follow-up record. A new issue may arrive in an old thread and need a separate record. Retain both the platform event and the reviewed issue classification.
Compare like with like
For a returned-work rate, start with cases first marked resolved in a defined period. Follow them for the same stated length of time and count returns about the same issue, including linked follow-ups if your rule allows them.
Do not compare a recent cohort before its follow-up window has elapsed. State how late returns and cases with no reliable link are treated.
For new demand, count distinct new issues first raised during the period. Report this separately from returned work. Dividing this week's reopen events by this week's new tickets does not produce a resolution-failure rate: the reopened cases may have been resolved earlier, and the new-ticket count may include follow-ups to old issues.
A useful classification review includes a failed remedy, a requested document, a thank-you, an unrelated question and a reply to an old closed case. Compare reviewers' issue labels, resolve disagreements and update the rule before using the result as a performance measure.
Key Metrics for Support Performance
- Returned Work Rate
- Measure of unresolved issues reopened within a defined follow-up window.
- New Demand Count
- Distinct new issues raised during the period, reported separately.
- Follow-Up Ticket Creation
- Automatically generated in Zendesk when a closed ticket receives a reply.
- Split Ticket Feature Availability
- Available in Freshdesk for separating unrelated customer responses.
