How to track feature requests in Zendesk
Feature requests come into Zendesk dressed as support tickets: "how do I restrict what viewers can edit?" is a permissions feature request wearing a how-do-I hat. The agent answers honestly ("you can't yet"), solves the ticket, and the signal is gone — until the same request arrives next week from a different account and also disappears.
Zendesk ships everything needed to stop the leak: tags, views, triggers, and reporting. Here's a setup that works with agent habits instead of against them.
“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 NotionStep 1: define the tags before anyone tags
Zendesk tags are freeform text applied to tickets, and they feed views, automations, and reports (Zendesk's tag documentation). Freeform is the risk: without an agreed list you'll have feature_request, featurerequest, and fr within a month.
Decide up front:
- One umbrella tag:
feature_request - Area tags:
fr_reporting,fr_permissions,fr_api,fr_billing— keep it to 10–20
Document the list with one-line definitions where agents can see it. If you want the umbrella tag to be even lower-friction, add a custom ticket field ("Request type") whose options apply tags automatically — dropdown selections beat remembering tag spellings.
Step 2: tag at solve time, not in a batch later
The agent rule is one sentence: if your answer contains "we can't do that yet," add feature_request plus one area tag before you solve. It rides along with the solve macro; it costs five seconds.
What the tag preserves is the valuable part — the customer's own words, their organization, and the ticket link:
"We can't roll the dashboard out to the finance team until viewers can't edit anything. Right now we just don't invite them." — ticket #4521, Priya @ Northwind (enterprise)
Nobody re-types anything into a spreadsheet. That's why this survives contact with a busy queue.
Step 3: build the view and the weekly count
Create a view filtered on feature_request, grouped however suits you. This is the raw feed. Once a week or month, someone reads through it and rolls tickets into counted themes — because tags find tickets but don't dedupe them. "Viewer permissions," "read-only seats," and "stop edits from invited users" are one theme: "granular permissions — 9 tickets, 6 orgs."
Zendesk Explore can chart tag volumes over time, which is useful for spotting a theme accelerating. The theme list itself should live wherever your team keeps its centralized feedback queue, with ticket links as receipts.
Step 4: promote themes to the tracker with the receipts
Set a threshold — a count, or one strategically heavy account — and when a theme crosses it, open the issue in Linear, Jira, or GitHub with the evidence pasted in: count, organizations, plans, representative quote, ticket links. In roadmap discussions, that issue argues for itself; the process for ranking it against everything else is covered at feature requests.
Add a trigger for the exceptions that shouldn't wait for a weekly review: a feature_request ticket from an org marked enterprise in a renewal window can notify a product channel immediately.
Step 5: close the loop from the view
When the feature ships, the theme's ticket list is your requester list — every one with a known email and an existing ticket thread. Follow up on each: "You asked about read-only access in February; granular permissions shipped today, here's the doc." Support tickets are the cheapest loop-closing channel a SaaS team has, and doing it visibly is also what convinces agents the tags lead somewhere. The broader practice is at close the loop.
Where the tag system runs out
Three limits show up on schedule:
- Untagged is invisible. Requests phrased as workaround stories, or buried in long threads, don't get tagged. Coverage depends entirely on agent attention on a busy day.
- Dedupe is manual and grows linearly with ticket volume.
- The counts live in Zendesk, the roadmap lives in the tracker, and reconciling them is a human's job.
At the point those costs bite — typically past a few dozen requests a month — teams add an extraction layer on top. That's what we build: Modem connects to Zendesk, pulls feature requests out of tickets whether or not they were tagged, dedupes them into quantified themes alongside feedback from Slack and calls, and files tracker issues with requesters attached for the ship-day follow-up. What makes the cross-channel numbers trustworthy is the context graph underneath: the same request in a ticket and a sales call resolves to one theme, with both requesters and their accounts still attached. We build Modem — judge the pitch with that in mind — and the other tools in this lane are compared in best tools to mine feedback from Zendesk tickets. Under that volume, tags plus a weekly review is a perfectly good system.
The smallest version you can start this week
Create feature_request and ten area tags, add the one-sentence rule to the solve macro, and build the view. Put 30 minutes on the calendar to do the first theme count. Ship-day follow-ups on the first promoted theme will do more for agent tagging discipline than any reminder.
