Zendesk CSAT Response Rate Report

A CSAT score without a response rate is a number without a size.

“We’re at 94%” could mean 470 customers out of 500 said support was good. It could also mean 17 out of 18 people did, from a queue of 900 tickets. Those two facts justify completely different decisions, and a satisfaction dashboard that shows only the score cannot tell them apart.

This guide shows how to report on CSAT response rate in Zendesk Explore, how to separate a survey delivery problem from a response behaviour problem, and how to read the number so leadership stops over-trusting a thin sample. Keep it beside the support metrics dashboard and the Zendesk CSAT Report.

What this report should answer

• What share of offered surveys did customers actually answer?
• What share of solved tickets were even offered a survey?
• Is the sample large enough to act on this week’s score?
• Which groups, channels, or accounts are underrepresented in the score?
• Did the score move because sentiment changed, or because the sample changed?

For the definition and formula, see CSAT response rate. This guide covers building and reading the report.

The two rates people confuse

Zendesk exposes two different percentages, and they answer different questions. Getting them mixed up is the single most common error in CSAT reporting.

The first is the response rate. The second is survey coverage. A team can have an excellent response rate and still have a meaningless score, because the survey only ever reached 8% of solved tickets.

Always build both. They have different owners: coverage is a trigger and workflow problem for an admin, response rate is a timing, channel, and wording problem.

The four states of a Zendesk survey

The Ticket satisfaction rating attribute has exactly four values, and every satisfaction metric is built from them:

From these, Explore derives the metrics you need:

• Rated satisfaction tickets — Good or Bad (the numerator for response rate)
• Surveyed satisfaction tickets — Offered, Good, or Bad (the denominator for response rate)
• Unsurveyed satisfaction tickets — Unoffered
• % Satisfaction rated — response rate
• % Satisfaction surveyed — coverage

The key insight: Offered tickets are your non-respondents. They are not missing data — they are a measurable, reportable group, and they are usually the largest group on the dashboard.

How to build the report in Zendesk Explore

1. Start with the prebuilt Satisfaction tab

Before building anything, open the Zendesk Support dashboard and check the Satisfaction tab. Response-rate reports already live there. Clone what fits and only build custom reports where the defaults stop answering your question.

2. Build the headline response rate

In the Support - Tickets dataset:

• Metric: % Satisfaction rated
• Rows: Ticket solved - Week (or Month)
• Filter: a rolling date range on ticket solved date

Add Rated satisfaction tickets as a second metric on the same report. Never publish the percentage without the raw count next to it — that count is the sample size, and it is what stops someone reading a 100% score off three responses.

3. Add coverage as a second line

Add % Satisfaction surveyed on the same time axis. You now have a two-line chart that separates the two failures:

• both low → you barely ask, and few answer
• coverage high, response low → asking works, the ask does not land
• coverage low, response high → the people you reach do answer; you are just not reaching many

4. Make non-response visible

Percentages hide volume. Build a stacked column showing all three outcomes per week:

• Good satisfaction tickets
• Bad satisfaction tickets
• CSAT offered but not responded to

The third is not a built-in metric, so create a standard calculated metric:

IF ([Ticket satisfaction rating] = "Offered") THEN [Ticket ID] ENDIF

Name it something clear like Offered not answered. This single chart is usually the most persuasive panel on the dashboard — it shows the silent majority beside the two bars people normally argue about. For more on building these, see Zendesk Explore Calculated Metrics.

5. Segment to find who is missing from the score

Break response rate down by:

• Ticket channel — response behaviour differs sharply between email, messaging, and voice
• Group — see Zendesk CSAT by Group Report
• Organization — B2B accounts often answer at very different rates
• Ticket priority — urgent work sometimes gets surveyed less because of how triggers are scoped
• Assignee — see Zendesk CSAT by Assignee Report

This is where response rate stops being a hygiene metric and becomes an analysis tool. If one channel answers at 4% and another at 30%, your blended CSAT is mostly the second channel’s opinion — regardless of where your volume actually sits.

6. Check for rating changes

In the Support - Updates history dataset, Explore tracks rating revisions:

• Bad to good satisfaction ratings
• Good to bad satisfaction ratings

These matter for response-rate work because a follow-up workflow that recovers bad ratings will change the score without changing how many people responded. Track them separately so recovery is not mistaken for improved sentiment.

Business hours, timing, and why response rate moves

Response rate is unusually sensitive to mechanics rather than sentiment:

• Survey delay. A survey sent immediately at solve catches the customer while context is fresh. One sent a day later competes with the rest of their inbox.
• Channel. An in-conversation messaging survey typically outperforms an emailed one, because it does not require the customer to switch context.
• Requester type. End users on shared or role-based addresses (billing@, it-help@) frequently never answer.
• Reopen and resolve cycles. A ticket solved, reopened, and solved again can change survey state in ways that confuse week-over-week comparisons.

None of these are sentiment. All of them move the score. That is why response rate belongs on the same dashboard as CSAT rather than in an annual audit.

How to interpret the patterns

Response rate falls and CSAT rises

Treat this with suspicion. When fewer people answer, the remaining respondents are more self-selected — often the customers with the strongest positive relationship. The score can improve because the sample narrowed, not because service improved.

Response rate is stable and CSAT drops

This is the trustworthy version of a bad week. The sample did not change, so the change in sentiment is likely real. Move on to Zendesk Satisfaction Reason Report to find out why.

Coverage drops sharply in one week

Almost always a trigger or automation change, not customer behaviour. Check what was deployed. A survey trigger scoped to the wrong condition can silently stop asking an entire segment.

Response rate is high but volume is tiny

A small queue can produce a genuinely high response rate and still not support week-to-week comparisons. With low volume, report a rolling window and resist reading single-week swings.

One channel has near-zero response rate

Either the survey is not reaching customers on that channel or it is badly formatted there. Test the actual customer experience on that channel before concluding those customers do not care.

Response rate is high only for solved-fast tickets

Customers whose issues dragged on may be disengaging entirely rather than rating badly. That is a systematic bias toward good outcomes — check response rate against resolution time to confirm.

Common mistakes

• Reporting CSAT without the response count. The score is unreadable without its sample size.
• Using total solved tickets as the denominator for response rate. That produces coverage, not response rate. Unoffered tickets never had the chance to respond.
• Ignoring the Offered bucket. It is your non-respondent population and usually the biggest group.
• Comparing weeks with very different sample sizes. A move from 12 to 15 responses is noise, not a trend.
• Treating a rising score as good news without checking the rate. A shrinking sample inflates scores more often than it deflates them.
• Chasing response rate as its own KPI. Aggressive re-surveying raises the rate and annoys customers. The goal is a representative sample, not a maximal one.
• Forgetting satisfaction reasons only apply to bad ratings. They are collected on negatives, so their denominator is different again.

What to do when response rate falls

1. Confirm whether coverage or response fell. They have different fixes.
2. If coverage fell, audit survey triggers and automations for recent changes.
3. If response fell, check timing — how long after solve does the survey arrive?
4. Segment by channel and fix the worst channel first rather than adjusting globally.
5. Review the survey experience as a customer on the worst-performing channel.
6. Check whether one large organization or a role-based requester group is dragging the blend down.
7. Re-baseline your reporting window. If the sample is now thin, switch to rolling 30-day reporting and say so on the dashboard.
8. Add the response count to every place the score is reported, including exec summaries.

Dashboard template

Panel 1 — CSAT score with response count The score and its sample size in one place. Non-negotiable.

Panel 2 — Response rate and coverage over time Two lines. Separates “we did not ask” from “they did not answer.”

Panel 3 — Good / Bad / Offered-not-answered, stacked by week Makes the silent majority visible.

Panel 4 — Response rate by channel Usually the largest source of variance.

Panel 5 — Response rate by group or organization Shows whose experience is underrepresented in the score.

Panel 6 — Rating changes (bad to good, good to bad) Separates recovery workflows from genuine sentiment shifts.

FAQ

What is a good CSAT response rate? Benchmarks vary too much by channel and audience to be useful as a target. The practical test is different: is the sample large enough and representative enough to support the decision you are about to make? A stable 15% that covers every channel is more useful than a volatile 40% concentrated in one.

Does a low response rate make CSAT useless? No. The responses are real customer feedback. A low rate limits how confidently you can generalise to all customers and raises the risk of selection bias. Report it beside the score and interpret accordingly.

Should I chase a higher response rate? Only up to the point of representativeness. Improve timing, channel fit, and survey friction. Do not add repeated reminders — you will bias toward the customers most willing to be nagged.

Why is my response rate different from the prebuilt dashboard? Usually a denominator or date-attribute difference. Confirm you are dividing rated by surveyed tickets, and check whether you are filtering on ticket created date versus ticket solved date.

Where should this sit in a support dashboard? Directly beside CSAT, not in a separate methodology section. It is part of reading the score, not an appendix to it.

See your Zendesk CSAT score and its real sample size together - start free