Jira Service Management is where requests, incidents, and service work already live. Customer feedback is how you learn whether that work felt good to the people who raised it.
This page is the starting point — not a product pitch. If you are new to the category, start here, then move into common problems and concrete use cases.
Why service teams measure feedback
Without a satisfaction signal, JSM tells you about volume, SLAs, and reopen rates — not how the experience felt. Feedback closes that gap:
- CSAT — Was this interaction satisfactory?
- NPS — Would you recommend us?
- CES — How hard was it to get help?
Together they cover transaction quality, relationship loyalty, and effort. Separately they answer different leadership questions.
Where feedback usually shows up in JSM
Most programs collect after a request is resolved — by email, in the customer portal, or through a survey link. Scores may sit on the issue, in a report, or in an external tool.
How you collect and where the data lives determines whether feedback becomes an operations input or a quarterly slide.
What “good” looks like (without naming a vendor)
A healthy JSM feedback practice usually:
- Asks at the right moment (fresh context, not stale inbox mail alone)
- Keeps the score next to the ticket that caused it
- Lets teams slice trends by queue, request type, or time
- Turns poor scores into owned follow-up — not ignored rows
You do not need every metric on day one. Many teams start with CSAT and add NPS or CES later.
Where to go next
If something already feels wrong — low response rates, scores outside Jira, reports nobody trusts — go to the problems layer next. If you already know the job (“collect CSAT”, “report satisfaction”, “run CSAT+NPS+CES”), jump to use cases.