Why Jira Service Management CSAT Survey Response Rates Are So Low
On Atlassian's own community forum, one Jira Service Management admin reports a CSAT response rate of 7 percent, well below the 8-15% an Atlassian partner in that same thread calls typical for a default setup. Either number is low. That is not because customers lack opinions about the support they got. It is because the survey arrives as one more email in an inbox, sometimes hours after the ticket closed, with no follow-up if it goes unanswered.
The fixes that actually move the number are mechanical. Send the request through the same channel the customer already used, fire it the moment the ticket resolves instead of on a delay, and build a reminder since Jira Service Management doesn't ship one. Below is how those pieces work, a worked example of what the resulting numbers look like in practice, and the point where even a fixed response rate stops telling you what you need to know.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThree reasons the default setup underperforms
Jira Service Management sends its satisfaction survey when a request's Resolution field gets set and the "Request resolved" customer notification is enabled, or when the ticket transitions into a Done-category status, per Atlassian's own troubleshooting guide. That guide lists several documented reasons the survey can fail to send at all, including satisfaction settings switched off for the whole project, customer notifications disabled, the reporter added as a watcher or assignee (which routes them an internal notification instead of a customer one), the resolution getting set twice through a post function and a transition screen, and issue-level security restricting the customer from seeing the resolved ticket. For company-managed projects there's a subtler cause. If an issue's Request type field was never populated before it resolved, no customer notification goes out for that ticket, even with the project's satisfaction setting on.
That last cause is easy to miss because it isn't a settings toggle. Satisfaction surveys are turned on once, for the whole project, in Space settings > Request management > Satisfaction settings; there is no per-request-type on/off switch. What does vary ticket by ticket is whether the Request type field actually got set before someone hit resolve. A request type added later, or tickets created through an API integration that skips the field, can quietly produce a run of tickets that never had a chance to trigger a survey.
For teams where the survey is sending correctly, the responses linked in that same community thread point to three more reasons the number stays low:
- The channel is email, and email loses. One contributor's direct comparison found portal comment notifications get a better response than email notifications, because a chunk of the emailed surveys never get opened at all.
- Timing decays fast. Response rates drop sharply the longer the gap between resolution and the survey landing in front of the customer. A survey that fires the instant a ticket resolves outperforms one batched for later.
- There's no native reminder. Jira Service Management has no out-of-the-box way to nudge a customer who saw the survey and didn't answer. The workaround, confirmed by an Atlassian partner responding in the same thread, is an automation rule that re-sends the request after a set window if the satisfaction field is still empty.
None of these are exotic fixes. Confirm the project's satisfaction setting is actually on, check whether the Request type field is reliably populated on tickets before they resolve, favor portal notifications where your customers are already logged in, and write one automation rule for a 48-hour reminder.
Worth ruling out first, before touching any of that. A survey that never sends looks identical to a survey nobody answers. If a slice of tickets come in through an integration or a request type that doesn't reliably set the Request type field before resolution, those customers were never in the pool to begin with, no matter how well portal notifications and reminders get tuned elsewhere. That's worth checking in the ticket data itself, not just in project settings, and it's the kind of gap that quietly caps a response rate no amount of automation-rule tuning will fix.
What a support team actually sees at that rate
Elke Renner runs support operations at Duskfield Systems, a company that sells accounts-payable automation software to mid-market finance teams. Her ticket volume runs through Jira Service Management, and every quarter she reports a CSAT number to the VP of Customer Success.
Last quarter, Duskfield closed 340 requests. 31 customers rated the resolution. Elke's update to her manager:
Elke Renner: "We closed 340 tickets. 31 people rated us, and the average came back strong. I can tell you what those 31 thought. I genuinely don't know what the other 309 thought, and neither does the dashboard."
VP of Customer Success: "Can we just get more people to respond?"
Elke Renner: "We can try. Even at 20%, that's still 68 opinions standing in for 340 tickets, and the tickets where someone was annoyed enough to escalate in Slack before the ticket even closed don't necessarily show up as a bad rating. Some of them never get a rating at all, because the customer already vented to their account manager and considered it handled."
Elke made the changes above. She found a handful of tickets coming in through an integration that wasn't setting the Request type field before resolution, and fixed the integration so those tickets stopped falling out of the survey pool entirely. She also switched the notification from email-only to portal-first, and started an automation rule that re-sent unanswered surveys after two days. Response climbed from 9 percent to roughly 16 percent the following quarter. It was a real improvement, and it was still built on a minority of tickets talking for the rest.
What a higher response rate still doesn't fix
A response rate fix changes how many customers rate you. It does nothing for the customers who don't, and it does nothing for the information a rating doesn't carry in the first place. A low score with no comment tells Elke someone was unhappy; it doesn't tell her which part of the interaction caused it. That answer is usually sitting earlier in the same ticket thread, or in the Slack message the account manager already forwarded her, in plain language, before any survey went out.
Once a support team is stitching together JSM ticket content, an account manager's Slack note, and a handful of survey comments to reconstruct why one account is unhappy, the CSAT number has stopped being the useful unit. The useful unit is the conversation itself, wherever it happened, tied to the account it came from.
That's the point where we build Modem. Modem's Jira Service Management integration reads customer requests, public replies, and internal notes from JSM as feedback threads, carrying status, priority, reporter, and the source ticket along with them, and links each reporter to the same customer record it builds from Slack, email, and support conversations elsewhere when Jira returns an email address for that reporter. A dissatisfied customer's complaint is a signal the moment they type it in the ticket, not only if they later click a star rating on an email that might land in a spam folder. We build Modem and sell it, which is an obvious conflict of interest to flag here, so weigh the pitch accordingly. The broader case for pulling product signal out of a service queue rather than a satisfaction score is covered in the best Jira Service Management feedback tools, and how those threads tie back to specific people and accounts is covered in what a customer context graph is.
Three changes worth making before anything else
Confirm satisfaction surveys are turned on for the project, then check whether every request type customers actually use is reliably setting the Request type field before tickets resolve, not just the ones that have always worked. Switch the notification to portal-first if most of your customers log into the portal already. Write one automation rule that re-sends an unanswered survey after 48 hours. None of that requires new tooling, and it's the same sequence that moved Duskfield's number. Just don't mistake the higher number for the whole picture, since it's still a minority report on every ticket that didn't get answered.
