Searching for how to collect CSAT in Jira Service Management usually means you already run JSM and want satisfaction scores without standing up a separate feedback product.
This use case walks the path Myra is built for: ask in the right channel, store the answer on the ticket, and act when scores are poor.
The outcome
Requesters can rate resolved work from the customer portal or email. Every CSAT response lands on the related Jira issue. Agents see feedback in context. Leads can report jira csat without exporting CSV files to another BI tool first.
The workflow
- Pick the trigger — typically when an issue transitions to Resolved/Done, via Jira Automation.
- Choose the channel — portal survey for portal users; email survey when the conversation happened over mail.
- Ask a clear CSAT question — keep it short; optional comment field for “why.”
- Write the response to Jira — score and comment stay on the issue as native feedback data.
- Route detractors — low scores can open a follow-up issue so someone owns the recovery.
That loop is the difference between a jira customer satisfaction survey program and a one-off form.
Why teams do this inside JSM
CSAT only improves operations when it inherits ticket context: request type, queue, assignee, SLA breaches, reopen counts. Collecting outside Jira forces you to rejoin that context later — if you ever do.
Myra keeps collection and storage on the Atlassian side so csat jira reporting stays operational, not archaeological.
What to measure after launch
- Response rate by channel (portal vs email)
- CSAT by request type / queue
- Reopen rate on tickets with low CSAT
- Time-to-follow-up on negative scores
If those four are visible, your collection use case is working.
Ship it
Install Myra from the Atlassian Marketplace, enable CSAT on one JSM project, and connect your resolution automation. Free to try — plans from $10 USD/month.