We've been running Zendesk for about two years now, and our internal dashboard proudly shows a consistent 92% CSAT. Management loves it. I hate it.
The problem isn't the average; it's the distribution. When I segment the ratings by ticket category, one group—let's call them "Legacy Plan Power Users"—consistently scores us at 30-40%. Their volume is only about 5% of total tickets, but their ratings are so catastrophically low they single-handedly drag the overall average down from what would be a 97% for everyone else. The 92% is a completely misleading vanity metric.
I suspect the issue is a mix of product limitations they're hitting and agent inexperience with those specific, complex workflows. But the CSAT survey just asks "How did we do?" after the ticket closes, conflating our support performance with their frustration at the product itself.
Has anyone else deconstructed their Zendesk satisfaction data to the point of despair? I'm looking for strategies to either:
* Statistically present the data in a way that isolates this segment's influence for internal reporting.
* Configure Zendesk routing or surveys to tag these tickets so we can analyze them separately *and* potentially exclude them from the main CSAT calculation if they're truly measuring product, not support.
* Better yet, any way to trigger a different survey or process for known problematic segments?
Most advice I find is about "improving the score," but I want to understand and report it correctly first. I don't trust a metric that can be skewed so heavily by a small, perpetually dissatisfied cohort.
Data skeptic, not a data cynic.
You've perfectly described why aggregated CSAT can be a dangerous comfort blanket. That 92% is hiding a critical, systemic issue with a key user segment.
On your first point about statistical presentation, we had to do something similar. We built a separate dashboard view in our BI tool that excluded a specific tagged segment, but we always showed it side-by-side with the overall number. The crucial part was labeling them clearly: "Overall CSAT" and "CSAT Excluding Legacy Workflow Tickets." Management could see both the pretty number and the ugly truth, which made the case for investing in a fix.
For tagging, can you use Zendesk's conditional logic in the satisfaction survey? We set ours to add a specific tag if the ticket was tagged with certain product-area keywords *and* the user was on a particular plan. This automatically grouped them for reporting without relying on agents to remember. The real work, of course, starts after you've isolated them. Have you considered setting up a dedicated, specialized queue for these tickets?
buyer beware, but buy smart
That side-by-side dashboard approach is spot on. Transparency with the data forces the conversation. We implemented something similar and called the second metric "Adjusted CSAT," which helped frame it as a tool for improvement, not a way to hide the problem.
Your tagging strategy is a smart technical solution, but it requires the initial trigger, like a product keyword, to be present. What happens if the agent misses tagging the ticket correctly at the outset? The conditional logic in the survey won't fire. We found we needed a small, secondary audit process where a lead reviewed tickets from known legacy accounts to catch any that slipped through.
A dedicated queue is the logical next step, but it introduces a resourcing challenge. Did you find that segregating these tickets improved resolution times for that segment, or did it just create a bottleneck with your specialized agents?
You're right to focus on the tagging. Conditional survey logic is a bandage if the initial ticket metadata is wrong.
Two things we did:
1. Created an automation that tags any ticket from a known "Legacy Plan" account, period. No relying on agent keywords. This gave us a clean baseline dataset.
2. Built a separate Zendesk dashboard view filtered on that tag. We didn't call it "Adjusted CSAT," we called it "Core Product CSAT" vs. "Legacy Workflow CSAT." The naming matters. It frames the 30% as a specific product-maturity problem, not a support team failure.
Have you pulled the ticket data for that segment to see the top 5 resolved reasons? That's usually where you find the reproducible product limitation to take to Engineering.
Show me the query.
Agreed on the audit process - that's the inevitable human layer on top of the automation. We had the same need.
> Did you find that segregating these tickets improved resolution times for that segment
It did, but only after we built a custom Workato recipe that handled the routing. It didn't just dump tickets into a queue; it checked agent capacity and skill level against the ticket complexity in real-time. Without that, we created a different kind of bottleneck. A simple dedicated queue often just shifts the wait.
The real win wasn't just faster times, it was the consistency. That let us build a cleaner dataset to prove the root cause was product gaps, not agent performance.
Integration is not a project, it's a lifestyle.
That capacity-checking logic is the critical piece everyone skips. You can't just route based on a tag, you have to match ticket load against agent certification metrics in your IAM system.
We implemented similar logic but used PagerDuty's API to check on-call status for our senior engineers. If the primary SME was handling an incident, the recipe would hold the ticket or route to a secondary, pre-approved backup. This stopped the "dedicated queue" from becoming a single point of failure.
Without that audit trail showing a deliberate capacity decision, you're just creating a new performance sink that gets blamed on the agents in that queue.
Where is your SOC 2?
Oh, I feel this deeply. That sinking feeling when you know the "good" number is papering over a real, painful problem. You've hit on the exact right thing - it's the distribution, not the average.
Your suspicion about the survey conflating support and product frustration is key. We ran into this and ended up adding a second, super simple question just for that segment: "Was your issue resolved by support today?" It goes out on the same ticket, right after the standard CSAT. The delta between the two scores became our clearest evidence to product teams that the anger was about feature gaps, not the agent's effort. It's not a perfect fix, but it gives you a fighting chance to separate the signals.
For tagging, automate it at the account level immediately. Don't wait for a keyword or an agent to get it right. Once you have that clean segment, you can start building the case for those complex workflow solutions.
Test, measure, repeat
Oh, I know that feeling all too well, staring at a dashboard number that feels more like a lie than a metric. That "conflating our support performance with their frustration at the product itself" is the absolute heart of it. We migrated off a legacy system last year and the exact same pattern emerged.
One thing that really helped us, beyond the excellent tagging advice here, was to slice the data by *time-to-first-reply* for that segment. Often, the anger wasn't about the final resolution (which was often a workaround), but the sheer frustration of waiting for an agent who even understood their esoteric problem. Setting up a separate SLA for that tag forced us to staff appropriately and showed management the operational cost of those complex cases.
Have you looked at the verbatims for the 1-2 ratings from that group? We found a treasure trove of the same 3-4 product feature requests buried in the anger, which became our roadmap ammo. The separate survey question idea from user1286 is gold for that, too.
Backup first.