Zendesk Satisfaction Reason Report

A CSAT score tells you how many customers were unhappy. It does not tell you what to do about it, which is why most CSAT reviews end in a conversation about agent coaching regardless of what actually went wrong.

Zendesk collects the missing half. When a customer leaves a negative rating and satisfaction reasons are enabled, they are asked a follow-up question with a short list of causes. That single field turns CSAT from a scoreboard into a work queue, because each reason belongs to a different owner: “the issue took too long” is a staffing and routing problem, “the issue was not resolved” is a quality problem, and “the agent’s attitude” is a coaching problem.

This guide builds the reason report in Zendesk Explore, covers the sample-size traps that make reason analysis unreliable, and shows how to connect each reason to a metric you can already move.

What this report should answer

Which single reason accounts for the largest share of our negative ratings?
Is that reason concentrated in one team, tag, channel, or account?
Which reasons are growing, even if the overall score is flat?
Does the reason customers give match what the operational metrics say happened?
What share of bad ratings give no reason at all?

For the definition see satisfaction reason and CSAT. This report belongs next to How to report CSAT in Zendesk and the support metrics dashboard — the reason field explains a score, it does not replace it.

Before you build: confirm reasons are actually being collected

Reasons are not on by default, and they are only ever collected on negative ratings. Two things to verify first.

Are reasons enabled? In the legacy CSAT experience this is the satisfaction reasons follow-up question. In the updated CSAT survey the equivalent is the drop-down of possible reasons a user might submit a negative rating. Either way, if it is switched off, the Ticket satisfaction reason attribute exists but returns nothing useful.

Which CSAT experience are you on? This is the detail that ruins year-over-year reason reporting. Zendesk’s updated CSAT survey and the legacy CSAT option cannot both be active, and switching between them changes how ratings are collected and which channels are surveyed — the updated survey covers email and messaging, while legacy live chat tickets stay on the legacy experience. If your account migrated mid-year, reason distribution before and after the switch is not a like-for-like comparison. Annotate the changeover date on the chart and analyse each period separately.

The default reason set is short and worth knowing by heart, because the whole value of the report is in how these four map to different fixes:

Reason	What it actually means	Where to look
The issue took too long to resolve	Speed failure — waiting, not outcome	resolution time, requester wait time
The issue was not resolved	Quality failure — the answer did not work	reopen rate, first contact resolution
The agent’s knowledge is unsatisfactory	Enablement failure — wrong or incomplete answer	macros, help centre content, QA reviews
The agent’s attitude is unsatisfactory	Behaviour failure — tone, empathy, escalation handling	coaching, QA scorecards
Some other reason / No reason provided	Unclassified	satisfaction comments

Admins can customise and localise this list. If yours has been edited, build your mapping table before you build the report — otherwise every future analysis re-litigates what each reason means.

How to build the report in Zendesk Explore

1. The reason distribution

In Explore, open Reports > New report, choose Support > Support - Tickets, and click Start report.
In Metrics, add Bad satisfaction tickets.
In Rows, add Ticket satisfaction reason.
Sort descending.

Use Bad satisfaction tickets as the metric, not Rated satisfaction tickets and not Tickets. Reasons only exist on negative ratings, so any metric that includes good ratings puts a huge NULL row at the top of your chart and makes every percentage meaningless.

Then convert to shares of negative ratings. “Took too long is 34% of our bad ratings” is a sentence people act on; “took too long is 61 tickets” is not.

2. The comment layer

Reasons are categories; comments are evidence. Build a second, table-style report:

Same dataset, metric Bad satisfaction tickets.
In Rows add Ticket satisfaction reason, Ticket satisfaction comment, Ticket ID, and Assignee name.
Filter to a single reason.

This is the report that survives contact with a leadership meeting. Ten verbatim comments behind a percentage stop the debate about whether the number is real. It is also where you catch mis-categorisation — customers routinely pick “some other reason” for things that are clearly speed complaints.

Reading these is a manual task, and it is worth doing weekly on the largest reason only. Do not try to read everything.

3. Segment the dominant reason

Take the top reason and find its concentration. Add one attribute at a time to Rows:

Ticket tags — which issue types generate this complaint (Zendesk CSAT by Tag Report)
Ticket group — team-level pattern (Zendesk CSAT by Group Report)
Assignee name — individual pattern, and the one to treat most carefully (Zendesk CSAT by Assignee Report)
Ticket channel — whether one intake path produces a specific complaint
Ticket organization name — account-level friction (Zendesk CSAT by Organization Report)
Ticket priority — whether urgent work generates disproportionate complaints (Zendesk CSAT by Priority Report)

Assignee is where reason reporting most often gets misused. Bad ratings are already a small number; splitting them by reason and then by agent produces cells of two or three tickets. Treat assignee-level reason data as a prompt to go read the tickets, never as a performance measurement.

4. Trend each reason separately

Add Time - Ticket solved by week to Columns, keeping reason in Rows, and chart it as a stacked area or multi-line.

This is the highest-value view in the report, because reason mix shifts long before the headline score does. A team whose score is stable at 91% while “not resolved” quietly doubles its share of complaints has a quality regression in progress and a lagging indicator that will move next month. See Flat volume, rising reopens for the same dynamic in a different metric.

Trend shares, not counts. If total ratings grow, every reason’s count grows and the chart tells you nothing.

Validate the reason against what actually happened

Customers report their perception. Sometimes the perception and the data disagree, and the disagreement is itself the finding.

Build a small comparison for tickets rated bad, split by reason, adding operational metrics as columns:

Reason	Metric to check	What agreement looks like
Took too long	Median full resolution time, requester wait time	Clearly above your overall median
Not resolved	Reopens, replies per ticket	Elevated reopen or reply count
Knowledge	Reopens, escalation or group transfers	Elevated group reassignment rate
Attitude	None — behavioural	Read the comments and QA the ticket

Three outcomes, three different conclusions:

Reason and data agree. Straightforward. Fix the operational metric and the reason share should fall.
Customers say “too long” but resolution time is normal. You have an expectation problem, not a speed problem. Usually caused by silence during the ticket rather than total duration — check next reply time and agent wait time. Customers experience gaps, not totals.
Customers say “not resolved” but reopen rate is low. Customers gave up instead of replying. This is the most dangerous pattern in the report, because the queue looks clean precisely because people stopped asking. Cross-check repeat contact rate — the same person may be back with a new ticket instead of a reopen.

Sample size decides whether any of this is real

Reason data sits at the bottom of a funnel that narrows three times: tickets surveyed, surveys answered, and answers that were negative and included a reason. A team solving 4,000 tickets a month with a 25% response rate and a 92% score has roughly 80 negative ratings, and perhaps 60 with a reason attached.

Practical rules:

Report reason shares of negative ratings, never of all tickets.
Set a floor of about 30 reasoned negative ratings before you interpret a distribution at all.
Below that, widen the window to a quarter rather than segmenting a month.
Never segment twice. Reason × group is usually the limit; reason × group × week is noise.
Track the no-reason share as a data-quality metric. If most bad ratings arrive without a reason, fix collection before analysing anything.

Response bias applies on top of this. Customers with strong feelings answer surveys, so reason distribution over-represents extremes. See CSAT response rates in Zendesk for how far to trust a sparse sample.

How to interpret the patterns

“Took too long” dominates but the score is stable

Speed complaints are the most common single reason in most Zendesk accounts, so a large share is not automatically a finding. Compare against your own trend, not an external benchmark. A stable share with a stable score means this is your baseline; a rising share is the signal.

“Not resolved” is rising

Prioritise this over everything else. It is the only reason that says the work itself failed, and it predicts repeat contact, reopens, and churn. Pair with Zendesk Reopened Tickets Report and How to lower ticket reopens in Zendesk.

One reason is concentrated in one tag

The most actionable result the report can produce. It usually means a specific issue type has a broken workflow, a missing help centre article, or a genuine product defect. Route it to the owning team with the ticket list attached rather than treating it as a support performance issue.

“Knowledge” is concentrated in recent hires

Expected during onboarding and a reason to check ramp support rather than performance. See Agent onboarding: metrics to track progress.

Most bad ratings have no reason

Either reasons are not enabled, the follow-up is being skipped, or your reason list does not describe your customers’ actual complaints. Read the comments on no-reason tickets — if a theme appears repeatedly, add it as a custom reason.

Attitude complaints appear suddenly in one queue

Check what changed in that queue’s workload before treating it as behaviour. Agents under sustained backlog pressure write shorter, blunter replies. This is often a capacity symptom wearing a coaching costume — see Support team burnout: metrics that reveal risk.

Common mistakes

Using a metric that includes good ratings. Reasons only exist on negative ratings; anything else buries the report under NULLs.
Reporting reasons as a share of all tickets. The resulting fractions of a percent look trivial and get ignored.
Segmenting to individual agents on thin data. Two bad ratings is an anecdote, not a pattern.
Comparing reason mix across a CSAT migration. Legacy and updated CSAT collect differently; the break is in the instrumentation, not the customers.
Treating the reason as the whole truth. Validate against resolution time and reopens before you act.
Ignoring the no-reason bucket. It is a data-quality signal and often the largest single row.
Trending counts instead of shares. Rising survey volume makes every reason look worse.
Skipping the comments. Categories tell you where to look; comments tell you what to fix.

What to do when one reason starts growing

Confirm the sample clears your floor of reasoned negative ratings.
Convert to share of negative ratings and confirm the share, not just the count, is rising.
Check for an instrumentation change — CSAT migration, new channel surveyed, edited reason list.
Segment once to find concentration: tag, group, channel, or account.
Validate against the matching operational metric.
Read ten comments from the affected segment.
Route to the owner the reason implies, not to support by default.
Re-measure after a full survey cycle, comparing share to share.

Where this report fits in your dashboard

How to report CSAT in Zendesk — the score this report explains
Zendesk CSAT Improvement Playbook — what to do with the findings
Zendesk Sentiment Analysis Report — mood signals for unrated tickets
Zendesk Customer Effort Score Report — friction from the customer’s side
Zendesk QA Scorecard — where knowledge and attitude findings get worked
support metrics dashboard — the hub

FAQ

Which dataset has satisfaction reasons? Support > Support - Tickets. The attribute is Ticket satisfaction reason, available alongside Ticket satisfaction rating and Ticket satisfaction comment.

Why is my reason report mostly empty? Reasons are only collected on negative ratings, and only when the follow-up question is enabled. Filter to bad ratings and confirm the setting before assuming a data problem.

Can I add my own reasons? Yes, admins can customise and localise the reason list. Document the mapping from each reason to an owning team, otherwise the report gets re-interpreted every time it is reviewed.

Do good ratings have reasons? No. The follow-up question fires on negative ratings only, so this report is always an analysis of dissatisfaction.

How many bad ratings do I need before the distribution means anything? Around 30 reasoned negative ratings as a working floor. Below that, widen the time window instead of segmenting further.

Should I report reasons by agent? Only as a prompt to read the tickets. Bad-rating counts per agent per reason are far too small to support performance conclusions.

See what is actually driving bad CSAT in your Zendesk data - start free