How to mine feature requests out of Zendesk CSAT comments
Zendesk's CSAT survey is a rating plus an optional comment box, and nothing in Zendesk classifies what a customer writes in that box. There's no "feature request" label, no automatic routing, nothing that tells a support lead "12 of this month's comments are actually product asks." Pulling requests, and the occasional bug report, out of CSAT comments means reading them, deciding what each one actually is, and tagging the underlying ticket the same way you'd tag any other feedback.
That's the honest answer. The rest of this guide is how to do that without it becoming a full-time job, and where the manual version runs out of road.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhat the Surveys dashboard actually shows you
Get this straight before building a process around it, because it's easy to assume Zendesk does more than it does. The Surveys dashboard (available as part of the Quality Assurance or Workforce Engagement Management add-on) shows a word cloud of the top 100 words across survey comments, which is good for spotting a term spiking but useless for telling you what kind of comment it came from.
The same dashboard also has an AI-generated "predicted drivers" feature that sorts English-language comments into a fixed set of categories: Account, Bad outcome, Bad product, Bad support, Complaint, Confusing, Crumbs, Fast support, Feedback for agent, Good support, Issue not solved, Issue solved, Negative sentiment, Positive sentiment, Praise, Refund, Slow support, Support not helpful, and Thanks. It's a real classification layer, and more than a lot of teams realize Zendesk offers. None of those categories is "feature request" or "bug," because the taxonomy measures support quality and account friction, not product signal. A comment complaining about slow support and a comment asking for bulk CSV import land in different buckets that both miss the point.
There's also a separate mechanism worth knowing about. For negative ratings, you can configure drop-down reason codes customers pick from to explain a bad experience. That doesn't help either. It only fires on negative ratings, and the requests worth catching usually arrive attached to a fine, or even glowing, rating ("everything worked, wish it also did X").
No built-in feature-request or bug bucket exists at any rating level. The comment is free text, full stop, and someone has to read it.
Get the comments in front of a person, on a schedule
Zendesk shows the rating and comment at the top of any ticket that received one, and Explore lets you build a custom query beyond the pre-built CSAT dashboards. A report listing rated tickets with their comment text is a reasonable place to start. Whether you build that in Explore or just work from a saved view of solved tickets with a satisfaction comment, the mechanism matters less than the cadence. Someone reads the batch weekly, not "whenever there's time," because "whenever there's time" becomes never once volume passes a few dozen ratings a week.
Sort by kind: praise, complaint, feature ask, or bug
CSAT comments split into four rough kinds: praise ("the rep was great"), complaints about the interaction itself ("took three days to hear back"), feature asks ("wish I could bulk-import these instead of one at a time"), and bug reports that never turned into a ticket of their own ("worked fine until I tried it on Safari, then the button just did nothing"). The last two are what you're mining for, and both show up at every rating level, because the rating is about the support experience and the comment is whatever the customer felt like adding.
Feature asks and bugs need different next steps even though they surface the same way. A feature ask goes into the tagging step below. A bug with no ticket of its own needs one opened and routed to engineering, not filed alongside product requests where it will just sit. A support lead reading a batch should be looking for the shape of either: a wish or a workaround someone built, or a "this broke" that nobody escalated because the ticket already closed with a good rating on it.
Tag the ticket, not the survey
You can't tag a satisfaction response directly, but the comment lives on a ticket, and ticket tags are freeform and usable as view conditions. For a feature ask, apply the same tag you already use for requests surfaced any other way (feature_request plus an area tag, if you're following the taxonomy from tracking feature requests in Zendesk). For a bug with no ticket of its own, open one and tag or type it the way your team already flags bugs, so it lands in the engineering queue instead of the feedback pile. Running two parallel systems, one for tickets and one for survey comments, is how teams end up undercounting a theme because half its evidence is sitting in a different bucket. If the tag list itself has already sprawled into five variants of "feature request," fix that first; the macro and tag audit is the place to start, because a CSAT comment tagged into a mess doesn't help either.
Here's what that looked like on a ticket from Waverlyn, a shift-scheduling platform for restaurant chains:
CSAT comment, rated 5/5: "Setup went fast and support answered same-day, only wish is we could bulk-import our shift templates instead of building each location one by one."
Support note added when tagging: Third mention of bulk template import this month. The other two were solved-and-closed tickets that never got flagged. Tagging
feature_request/fr-schedulingand pulling the other two into the same theme.
Read as a satisfaction signal, that comment is a perfect score. Read as product signal, it's a request that had already come up twice in support tickets that quarter, neither of them connected to CSAT until someone read the comment.
Turn tagged tickets into counted themes
Tags find tickets; they don't merge them into themes. Once a month, filter the tag, read through, and group by what's actually being asked: "bulk shift-template import: 5 tickets, 3 accounts, one from a CSAT comment nobody would have caught otherwise." That grouped, counted version is what makes a case in a roadmap conversation. A single flattering comment with a wish attached doesn't.
The limits of reading by hand
This holds up fine at low CSAT volume, where one person can read every comment in twenty minutes a week. It runs into the same three walls every manual system does, just with an extra twist specific to CSAT:
- Coverage depends on someone reading every comment, every week. Skip two weeks and the backlog either doesn't get read or gets skimmed, and skimmed is where "wish it also did X" buried in a five-star comment gets missed.
- A positive rating actively works against noticing the request, because the instinct when scanning is to skip the ones marked good.
- CSAT comments never connect to the same request made in Slack, a sales call, or a different ticket. The theme count above only reflects whatever channel someone happened to be reading that week.
Past a few dozen CSAT comments a month, or once requests are arriving across CSAT and three other channels, that's the point teams add an extraction layer instead of a reading habit. That's the category we work in, with one honest caveat specific to CSAT: Modem's Zendesk integration reads tickets, comments, requester details, tags, and status, alongside Slack, email, and call transcripts, and pulls out a request regardless of which of those channels it arrived through. It doesn't have a documented path into the CSAT rating or its comment today, so the read-and-tag habit above is still what gets a CSAT-sourced request in front of Modem: once it's tagged onto a ticket, that request is grouped into the same topic as the same ask made in a two-star ticket or a Slack message, with every requester attached. Disclosure: we make Modem, so weigh that against a neutral read of the tradeoff. Below the volume where an extraction layer earns its keep, or for the CSAT-specific reading step regardless of volume, the habit above, paired with the tag taxonomy in how to track feature requests in Zendesk, is what does the job.
Start with last week's comments
Pull last week's CSAT responses that came with a comment, however you can get that list, and read them for asks and bugs rather than scores. Tag anything that qualifies with your existing feature-request tag, open a ticket for anything that qualifies as a bug with none, and note it if either turns out to be the third mention of something you'd already have caught from tickets alone. That gap, between what tickets already told you and what CSAT was quietly adding, is usually the argument for reading it every week instead of never.
