A customer reported a bug three weeks ago. The ticket got resolved, or at least marked resolved. Two weeks later they're back with a new ticket: "Is anyone looking at this? I reported this exact issue before." Same root cause, same customer, but now it's two tickets in your queue instead of one — and your team has to spend time re-establishing context that already existed on the first ticket.
Multiply that by a support desk handling a few hundred requests a month, and a meaningful slice of "ticket volume" isn't new problems at all. It's the same handful of unresolved or under-communicated issues resurfacing as fresh contacts, because the customer has no way to tell whether their original report actually went anywhere.
Why Resolved Tickets Keep Coming Back
The instinct is to treat this as a triage problem — tag duplicates, merge them, move on. But merging after the fact doesn't fix what caused the duplicate contact in the first place: the customer had no visibility into what happened after they submitted feedback.
Three things drive this specifically in JSM shops:
Feedback disappears into a black box. A customer rates a resolved ticket poorly, or leaves a comment explaining what still isn't working. If that rating just becomes a number in an average, nothing visibly changes on the customer's side. From where they sit, submitting feedback and submitting nothing look identical — so the natural next move is to open another ticket.
There's no visible proof the team is tracking anything. Support pages that just say "we value your feedback" don't give a customer any reason to believe a specific complaint is being worked. Without a live, honest signal that scores are being collected and acted on, every follow-up question defaults to a new ticket instead of trusting the original one is still moving.
The same underlying issue spawns unlinked tickets. If three different customers hit the same bug and each opens a separate request, your team ends up triaging the same root cause three times instead of once — and none of those tickets are connected to each other or to the fix in progress.
None of this shows up as a single alarming metric. It just shows up as ticket volume creeping upward while the number of genuinely new problems stays flat.
Closing the Loop Instead of Just Logging the Score
The fix isn't a new triage process — it's making the feedback loop visible and connected, so customers and agents both have proof that a rating led somewhere.
Turn negative feedback into a tracked, linked issue — not just a data point. When a customer leaves a low CSAT or NPS score with a comment, that comment should become an artifact your team can act on, not a row in a spreadsheet. Myra lets you go from a feedback item directly to a Jira issue: create a new linked issue on the spot, or attach the feedback to an existing one if it's a known, in-progress problem. That link is what breaks the duplicate-ticket cycle — the second customer's complaint gets attached to the same tracked issue as the first, instead of spinning up a parallel, disconnected ticket your team has to re-diagnose from scratch.
Show customers a real, moving score instead of a static claim. Myra's Portal Score Display puts your live CSAT (or NPS) score directly on the JSM customer portal, calculated from actual resolved tickets rather than a number someone updates by hand once a quarter. A visible, accurate score does something a silent backend average can't: it tells every customer landing on the portal that feedback is being actively collected and is worth giving, rather than leaving them to guess whether anyone reads it.
Use the Feedback Items view to catch patterns before they multiply. Myra's Reports tab surfaces Total Responses and score trends for each survey, and the Feedback Items section underneath shows the actual comments behind those scores. Reviewing that list regularly — not just the aggregate number — is how you catch a recurring complaint (a broken integration, a confusing portal step) while it's one or two tickets, rather than after it's generated a dozen "checking in again" follow-ups.
Making This Concrete
If you're already running Myra's built-in CSAT survey, none of this requires new tooling — just using the pieces you have differently:
- Open the Reports tab for your CSAT survey and sort the Feedback Items list by lowest scores first. Look for repeated language, not just repeated scores — customers describing the same problem in different words is easy to miss if you're only watching the average.
- For any low-scoring item tied to a known issue, use the Actions menu to Link to an existing issue rather than creating a duplicate. Future low scores on the same problem get attached to that same thread.
- For a genuinely new problem, use Create a linked issue so there's a direct trail from the customer's words to the ticket your team is actually working.
- If it isn't already on, toggle Portal Score Display in your survey's Configuration settings so the live score is visible the moment a customer opens the portal — not just visible to your team internally.
None of these steps change how many tickets your team resolves in a week. What they change is how many of next month's tickets are actually new information, versus the same handful of unresolved issues asking to be heard again. That's a cheaper problem to fix than it looks — the data was already sitting in your CSAT responses. It just needed a visible place to go.
Myra collects CSAT, NPS, and CES feedback directly in the JSM portal, turns negative responses into linked Jira issues, and displays a live, accurate score as a trust signal — all stored inside your own Jira tenant. Try it free on the Atlassian Marketplace.