Your team has been collecting CSAT ratings for three months. You have hundreds of responses. And when the IT director asks "so how are we doing on customer satisfaction?", you open a spreadsheet you exported last Tuesday and hope the numbers are still roughly accurate.
That's the CSAT reporting problem in Jira Service Management. The data exists — it's just buried in individual tickets, disconnected from your existing dashboards, and visible to nobody in real time.
Why JSM's Default CSAT Reporting Falls Short
Jira Service Management includes a basic satisfaction rating built into its email follow-up flow. You can see individual scores on tickets, and there's a project-level summary view. But the moment you need anything more than "average score this month," the native tooling starts to crack:
- No cross-project aggregation. If you run multiple JSM projects (IT Help Desk, HR, Facilities), there's no built-in way to see combined satisfaction data.
- No filtering by agent, category, or SLA breach. The summary view shows an average — not the breakdown that would actually tell you what's going wrong.
- No trend over time. You can't see whether satisfaction is improving or declining across the last 90 days.
- No trigger into automation. Because CSAT lives outside the normal Jira field model, you can't use it in JQL, Jira Automation, or board filters without additional tooling.
The fix isn't to export to a spreadsheet every Tuesday. It's to get your CSAT data into Jira's field model so it behaves like any other issue field — queryable, filterable, and usable in dashboards.
Step 1: Make Sure Your CSAT Data Is Stored as a Jira Field
This is the prerequisite everything else depends on. If your satisfaction ratings are stored in a third-party tool's database — separate from Jira — you're stuck doing manual exports. You need the score to live as a native Jira field on each issue.
When CSAT is stored as a custom field on the ticket, it unlocks everything in the standard Jira toolbox: JQL queries, dashboard gadgets, board filters, and Jira Automation conditions.
Check your current setup: can you write a JQL query that filters issues by their CSAT score? If not, your data isn't in the right place yet. (Myra stores scores as native Jira fields by default — that's the design choice that makes the rest of this article possible out of the box.)
Step 2: The JQL Queries You Actually Need
Once CSAT is a Jira field, start with these five queries. Build them into saved filters so you can reuse them in dashboards without retyping.
Tickets with a low CSAT score this month:
project = "IT Help Desk" AND "CSAT Rating" <= 2 AND resolved >= startOfMonth()
Low CSAT tickets that haven't had any follow-up:
project = "IT Help Desk" AND "CSAT Rating" <= 2 AND resolved >= -30d AND comment is EMPTY
This finds the low-rating tickets where nobody on your team has gone back to investigate or close the loop. That silence is what turns a bad experience into a churned customer.
Tickets resolved within SLA but still rated poorly:
project = "IT Help Desk" AND "CSAT Rating" <= 2 AND resolved >= -30d AND "Time to resolution" < "2h"
Fast resolutions with low scores are diagnostically valuable — they tell you speed isn't the problem. Something else is: the fix was wrong, the communication was poor, or the customer's expectations weren't managed.
High CSAT tickets from a specific agent (to understand what's working):
assignee = "jane.smith@company.com" AND "CSAT Rating" = 5 AND resolved >= -60d
Open tickets where a low score was given (still unresolved after bad feedback):
project = "IT Help Desk" AND "CSAT Rating" <= 2 AND status != Done
This last one is alarming when you see results. If a customer rated you poorly and the ticket is still open, that's a follow-up that needs to happen today.
Save each of these as a named filter. You'll use them as data sources in the next step.
Step 3: Build the Dashboard in Jira
Go to Jira's Dashboards menu and create a new dashboard. Aim for a single-screen layout that a service manager can read in 30 seconds — resist the urge to add everything.
The four gadgets that matter:
1. Average satisfaction score — Two Dimensional Filter Statistics
Rows: CSAT Rating values (1–5). Columns: ticket category or request type. Statistic: count of issues. This gives you a heat map of which request types are generating your worst ratings. The category with the most 1–2 star ratings is your next process improvement target.
2. CSAT trend — Created vs Resolved chart (or Pie Chart on low-score filter)
Use the "Tickets with low CSAT this month" filter as the data source. Narrow it to 13 weeks and watch the bar heights. A trend is more useful than a number: a 3.8 average that's been rising for eight weeks is better news than a 4.1 average that's been falling.
3. Unacknowledged low scores — Issue Statistics on the "no follow-up" filter
Count the tickets matching your second JQL query. This number should be zero — it's not a KPI you report upward, it's an ops hygiene metric that someone owns.
4. Agent satisfaction breakdown — Two Dimensional Filter Statistics
Rows: Assignee. Columns: CSAT Rating bucket (1–2, 3, 4–5). This makes coaching conversations concrete. "Your reopen rate is high" is vague. "You have 14 tickets rated 1–2 stars this month versus an average of 4 for the team" opens a real conversation.
Share the dashboard with your project team and set it as the default view for the team lead. Visibility changes behaviour — agents who know their scores are visible tend to close the loop more consistently.
Step 4: Set One Automation Rule Off Low Scores
A dashboard is passive. To make it active, add one Jira Automation rule that fires when a low score comes in:
Trigger: Issue updated
Condition: Field changed — "CSAT Rating" changed to "1" or "2"
Action: Add comment — "@[team lead] Low CSAT received on this ticket. Please review before closing."
That's the minimum viable closed-loop automation. You can evolve it later — assign a reviewer, create a linked follow-up task, adjust priority — but start with the comment. It ensures no low score goes unnoticed without requiring any manual triage.
The Reporting Habit That Makes It Stick
A dashboard no one looks at changes nothing. The teams that get value from CSAT reporting all have the same habit: a 15-minute weekly review.
Every Monday (or Friday, depending on your rhythm), the team lead opens the dashboard, looks at the unacknowledged low scores, and picks one thing: the ticket category generating the most 1–2 star ratings that week. That category gets one process change this sprint — better documentation, a new approval step removed, a template updated.
One change per week, applied consistently, compounds into meaningful improvement. The teams that try to redesign their whole service desk based on CSAT data end up paralysed by the volume of signals. The teams that pick one thing and fix it move the average score up steadily.
The One Metric to Start With
If you're building this from scratch, start with a single number: the percentage of resolved tickets with CSAT data (your response rate), and separately the percentage of low-score tickets that received a follow-up comment within 48 hours.
The first tells you if your data is reliable enough to act on. The second tells you if your team is actually closing the loop. Neither is a vanity metric — both have direct operational consequences.
Once those two are moving in the right direction, add the trend analysis and agent breakdown. In that order.
Myra stores CSAT and NPS scores as native Jira fields, so every query and dashboard gadget in this article works without any export step. Scores appear on tickets the moment a customer responds, and they're available in JQL immediately. Install free from the Atlassian Marketplace.