A ticket that gets reopened is a ticket you resolved twice. For the customer, it's a failure. For the support team, it's wasted capacity — the same problem, re-triaged, re-assigned, and re-resolved, often by the same person who should have closed it properly the first time.
Most service desk teams track their reopen rate as a KPI but struggle to explain what's driving it. Feedback data — specifically CSAT and CES scores tied to the tickets that later get reopened — gives you the causal link you're missing.
The Connection Between Low CSAT and Reopens
The relationship isn't perfect, but it's consistent enough to be actionable: tickets with low CSAT scores are significantly more likely to be reopened than tickets with high scores.
This makes intuitive sense. A customer who rates a resolution 1 or 2 stars is signalling that the fix didn't land. The reopen often follows — either the customer explicitly reopens it ("this didn't work"), or they submit a new ticket for the same underlying issue a few days later.
When you look at reopen data through this lens, two patterns typically emerge:
Pattern 1: Same-day reopens. The fix was wrong or incomplete. The customer tried it, it didn't work, and they came back within hours. These usually have 1-star ratings and comments like "still broken" or "this didn't fix the problem."
Pattern 2: Delayed reopens (3–14 days). The fix worked temporarily or only partially. The customer rated it 3 stars and moved on, but the underlying issue resurfaces. These are harder to predict and often involve systemic problems — misconfigured software, recurring access issues, or hardware that's failing gradually.
Using CES as an Earlier Signal
Customer Effort Score — asking "how easy was it to get your issue resolved?" — is often a better predictor of reopens than CSAT. A customer who found the process difficult (lots of back-and-forth, unclear instructions, required escalation) is more likely to experience the problem again, because the resolution process itself may have been incomplete.
High-effort tickets correlate with:
- Multiple comments on a single ticket before resolution
- Reassignment between agents
- SLA breaches (the issue was hard enough to take longer than expected)
- Vague resolution notes ("asked user to restart and monitor")
If you're collecting CES alongside CSAT, flag tickets with CES ≤ 2 (on a 1–5 scale) for review before closure. A few minutes of extra QA on high-effort tickets prevents a disproportionate number of reopens.
Building a Reopen-Prevention Workflow
The practical workflow combines feedback data with pre-closure checks:
Step 1: Identify your reopen profile
Before building any automation, pull 60–90 days of reopen data and cross-reference with CSAT scores. You're looking for:
- What percentage of reopened tickets had a CSAT score < 3?
- What ticket categories have the highest reopen rates?
- Which agents have above-average reopen rates?
In JQL:
project = IT AND status changed to Reopened AFTER -90d ORDER BY created DESC
Add the CSAT Rating field to the results view if your feedback tool stores it as a Jira field.
Step 2: Require resolution notes on low-CSAT categories
For ticket types that consistently generate reopens (e.g., "VPN access issues," "Printer configuration"), add a mandatory resolution note field to the issue screen. Free text is fine — you're not building a knowledge base entry, just requiring the agent to articulate what they did.
This has two effects: it forces a moment of reflection before closure, and it gives the customer (and the next agent) a clear record of what was tried.
Step 3: Add a resolution quality check for flagged tickets
Use Jira Automation to add a reviewer step before tickets in high-reopen categories can be resolved:
Trigger: Transition to "Resolved"
Condition: Issue type is in [your high-reopen categories]
Action: Add a comment from the automation bot — "Please confirm: Has the customer acknowledged the fix? Are there any known related issues?"
This isn't a bureaucratic hurdle — it's a prompt. Most agents will read it, confirm mentally that yes, the fix is solid, and move on. The ones who aren't sure will pause, which is exactly when you want them to pause.
Step 4: Send CES on high-complexity tickets
On tickets that exceeded your SLA or involved more than 3 agent comments, send a CES survey at resolution instead of (or alongside) CSAT. CES measures how hard the customer had to work — and high-effort scores on your most complex ticket types point directly to the process breakdowns you need to fix.
The Data Flywheel
The goal is to get into a cycle where feedback data makes process improvement continuous rather than periodic:
- Collect — CSAT and CES on every resolved ticket
- Flag — low scores trigger review; high-effort tickets get extra scrutiny
- Analyse — monthly look at reopen rate by ticket category and CSAT distribution
- Fix — one process or training change per month, targeted at the biggest reopen driver
- Measure — did the change reduce reopens in that category?
Most service desk teams that run this cycle for 6 months reduce their reopen rate by 30–50%. That's not just a metric improvement — it's real capacity freed up, real customer frustration prevented, and real agent time redirected to new work instead of redoing old work.
One Number to Watch
If you can only track one thing right now, make it reopen rate on tickets with CSAT < 3. That single correlation — how often your lowest-rated resolutions come back — tells you more about your service quality than your average CSAT score does.
Myra collects CSAT and CES scores inside your JSM portal and stores them as native Jira fields — ready for JQL queries, dashboards, and Jira Automation rules the moment a response comes in. Install free from the Atlassian Marketplace.