There's a person in every JSM instance who files a lot of tickets. Maybe they're the ops lead who raises five access requests a week, or the finance admin who's constantly hitting the same integration bug. Every one of those tickets gets resolved, and every one triggers a satisfaction survey. By ticket four, they're not rating their experience anymore — they're just closing the popup as fast as they can, or worse, ignoring your service desk's messages altogether because half of them are now surveys.
That's survey fatigue, and it's a data quality problem before it's a customer-experience problem. A rating submitted out of politeness or irritation on the fourth ask in a week isn't measuring satisfaction — it's measuring how annoying your survey cadence is.
The problem: JSM's survey doesn't know who it already asked
Jira Service Management's native satisfaction survey fires on resolution, full stop. There's no concept of "we already asked this person recently" or "let's space these out." Every resolved request is a fresh trigger, regardless of how many other requests that same reporter has closed in the last week.
For a service desk with a small number of low-volume requesters, this never becomes visible. But the moment you have even a handful of people who file tickets regularly — internal IT support, an account manager fielding client requests, a platform team handling recurring access requests — the same few people end up carrying a disproportionate share of your response volume, and an even larger share of your survey fatigue. Two things happen as a result:
- Your score gets noisy. Repeat requesters who are mildly annoyed by ticket #1 and openly frustrated by ticket #5 that week will rate differently depending on where in that sequence they are — not because your service quality changed, but because your survey did.
- Your response rate erodes for everyone, not just the power users. Once someone starts reflexively dismissing survey prompts because they've seen five in a month, that habit doesn't reset itself when the requests slow down.
The instinct is to just turn the survey off for certain people or projects, but that throws away real signal from your highest-volume relationships — often the ones worth the most attention.
The fix: rate-limit the ask, not the person
What you actually want is a frequency cap: ask a given requester at most once every N days, no matter how many tickets they close in that window. This is exactly the kind of thing JSM's all-or-nothing survey trigger can't do on its own, and it's why teams end up either living with the noise or building brittle custom automation to suppress duplicate surveys.
If you're using Myra for feedback collection, this is a native configuration rather than something to script. Myra's Feedback Surveys — the built-in CSAT and NPS surveys plus any custom ones you create — are governed by Collection Rules, which control exactly when and under what conditions a survey is triggered. Each survey keeps its own independent rule set, so you can tune this per touchpoint without affecting your other surveys.
The rule type that solves the repeat-requester problem specifically is Last Submission: it holds off on asking someone again until enough time has passed since their last response. Pair it with Reporter Only, which restricts the survey to the person who actually filed the request rather than every participant on the ticket, and you've got a rule set that asks the right person, at a sane cadence, instead of asking everyone, every time.
Here's how to set it up:
- Create a new Feedback Survey scoped to Request (or Project, if you want it collected from the portal page rather than per-ticket) — Last Submission is available on both of these scopes.
- Open the survey's Settings tab and scroll to Collection Rules. Toggle Enable Collection on — rules don't take effect until this is on.
- Every new survey starts with a default Always Allow rule. Delete it; that's the rule causing the fatigue in the first place.
- Click Add Rule, choose Last Submission, and give it a name (rule names are locked once saved, so make it descriptive — something like "14-day cooldown"). Add a short description of why it exists, for whoever inherits this project's settings later.
- Add a second rule, Reporter Only, so the survey only goes to the actual requester and not every watcher or participant on the ticket.
- Make sure at least one rule stays active. If Collection is on but every rule is off or deleted, the survey simply won't appear — Myra requires at least one active rule to trigger anything.
One thing worth knowing before you plan this around your built-in CSAT survey specifically: Myra's default CSAT survey ships with two predefined Collection Rules that are locked in and can't be removed, and the Last Submission rule isn't compatible with CSAT-type surveys at all — it's built for custom Rating or Number Pick surveys at Request or Project scope. If frequency capping matters to you, set it up on a dedicated custom survey rather than trying to retrofit the built-in CSAT one.
The takeaway
Survey fatigue isn't a reason to stop measuring your most active relationships — it's a reason to measure them on a schedule that respects how often you're actually interacting with them. If a handful of requesters are driving a disproportionate share of your ticket volume, check whether they're also driving a disproportionate share of your negative or check-the-box responses. If they are, the fix isn't fewer surveys overall — it's a frequency cap on the people getting asked too often, so the score you're left with reflects satisfaction, not survey exhaustion.