Why your JSM CSAT surveys fire at the wrong time (and how to fix it)

A customer receives a satisfaction survey, but their ticket is not actually resolved. It has simply moved to a status that looks like Done

This is not an edge case. It is the default behavior in Jira Service Management (JSM).

Here is why it happens, and the setting that can prevent it.

The default behavior many teams miss

By default, JSM sends a CSAT survey when a ticket moves into the Done status category. It does this even when the Resolution field is empty.

That distinction matters. The status category and the Resolution field are separate. Your workflow might contain several Done-category statuses, and a ticket can move into any of them without anyone recording a resolution.

The survey is sent anyway.

What this means: a customer may be asked, “How did we do?” after a ticket was closed as a duplicate, closed by mistake, or moved to Done temporarily during another process. The response does not measure what you think it measures.

Why this damages your CSAT data

One incorrect survey is easy to overlook. A pattern of incorrect surveys can undermine the entire dataset.

If your workflow uses Done-category statuses for duplicates, cancellations, holding states, or other outcomes that are not genuine resolutions, each one can trigger a survey.

Your CSAT average then combines meaningful feedback with noise. You can no longer tell whether a score reflects the quality of your service or a customer’s confusion about a ticket that was barely handled.

The fix: separate status from resolution

You have two options. Choose the one that fits the level of control you need.

Option 1: Adjust the workflow. Make sure only genuine resolution statuses lead directly to the Done category. Route duplicate closures and cancellations through a separate path that does not trigger the customer notification associated with CSAT.

Option 2: Adjust the notification settings. Go to Project settings > Customer notifications and find the Request resolved rule. Edit its condition so the notification—and the CSAT survey it contains—fires only when the Resolution field is set, rather than whenever the status category changes.

Option 2 is faster. Option 1 is more thorough because it also improves your reporting outside CSAT.

A second quirk: sending CSAT without the default notification

Some teams disable the default resolved notification so they can send a custom, branded email instead. However, disabling that notification also removes the built-in CSAT link.

The workaround: build an automation rule with these steps:

1. Trigger: Issue Transition, set to your real Resolved status

2. Action: Send Web Request, calling the issue's properties REST endpoint to generate a feedback token

3. Action: Send Email, with your custom message, including the generated survey link

This takes more work than changing a setting, but it is the practical option when you need a custom resolution email and still want to collect CSAT data.

Check your instance now

Run these three checks. They should take about five minutes:

1. Open Project settings > Satisfaction settings. Confirm CSAT is actually turned on, if you think it should be.

2. List every status in your Done category. For each one, ask: does this status mean the ticket was genuinely resolved? If not, it should not sit in that category, or it needs its own notification rule.

3. Pull your last 20 CSAT responses. Check the tickets behind them. If any were closed as duplicates, cancellations, or placeholders, you have confirmed the problem is live in your own data right now.

   
   

How this fits into your wider JSM setup

Survey timing is part of a broader question: does your reported data reflect what actually happened? The same principle applies to SLA reporting in Jira Service Management. A misconfigured calendar or pause condition can produce a number that looks authoritative until someone checks the underlying details.