Prioritizing Zendesk Feature Requests by Account Value
No, not without setup. Zendesk organizations carry a name, domain mappings, and whatever tags or custom fields an admin has added, but revenue isn't one of the built-in fields. There's no default way to filter a feature-request report by "accounts paying over $50k" because Zendesk has no idea what any account pays. That number lives in Stripe, Salesforce, or a billing system Zendesk has never talked to.
You can still get there. Zendesk supports custom organization fields, including a decimal type built for exactly this, and once ARR or plan tier is sitting on the organization record, Explore can group and filter by it like any other attribute. The catch is that nothing keeps that field current on its own. Here's how to set it up, and the point past which the manual upkeep stops being worth it.
What a Zendesk organization actually tracks
An organization record in Zendesk is a name, a list of domains for auto-assigning requesters, and a set of tags or custom fields you define yourself. Zendesk's own guidance on tag reporting notes that "custom field values load faster and have easily identifiable values" than tags, which reads as Zendesk's own hint that tags aren't built for anything numeric. A tag can mark an account as tier-enterprise. It can't hold "$84,200 ARR," because tags are strings you either have or don't, not fields you can sum or sort.
For a real revenue value, you need a custom field. Zendesk's organization fields API supports decimal and integer types alongside text, dropdown, and checkbox, so a field like account_arr is a normal admin-side setup: one field, one type, done in a few minutes from Admin Center or via the API.
Getting revenue onto the organization record
The field is the easy part. Populating it is the actual work, and there's no native sync:
- One-time CSV import. Export accounts and ARR from Stripe or your CRM, match on domain or organization name, and bulk-update through Zendesk's organization import. This gets you a working snapshot the same afternoon.
- API updates from your source of truth. A small script that reads Stripe subscriptions or Salesforce opportunities and PATCHes the matching Zendesk organization keeps the field closer to current, at the cost of someone owning and maintaining that script.
- A sync app from the marketplace, where one exists for your CRM, doing roughly the same job with less code to babysit.
Whichever path you pick, the field is a snapshot, not a live read. Zendesk doesn't poll Stripe for you; the number is only as fresh as the last import.
Reporting on it once the field exists
With account_arr populated, Explore treats it as any other organization attribute. Build a report on the Support: Tickets dataset, filter to your feature-request tag, and add the organization's ARR field as an attribute alongside the row grouping. The result is a ticket list you can sort by account value instead of just counting rows, which is the entire point of adding the field in the first place: an admin filtering by tag alone sees volume, not whether the loudest ten tickets came from your ten smallest accounts or your biggest one.
“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 NotionNaomi Torres ranks the enterprise queue
Naomi Torres runs support ops at Coalbrook, a scheduling platform for field-service crews. Every quarter the product team asks some version of the same question: which feature requests are coming from the accounts worth keeping happy, not just the loudest ones.
Coalbrook set up account_arr on Zendesk organizations two quarters back, populated from a monthly CSV export out of Stripe. To answer this quarter's version of the question, Naomi built an Explore report filtered to feature-request and grouped by organization, then opened each of the top tickets by hand to see what was actually being asked for, since the report groups by ticket count and ARR, not by request type. The top request from six-figure accounts turned out to be recurring invoice export: four tickets total, three of them from accounts clearing six figures. Compare that to 22 tickets asking for a dark mode toggle, most of them free-tier signups. By ticket count, dark mode wins by a mile. By revenue, invoice export isn't close.
That answer holds up only as long as the ARR field is current, and it wasn't. The last CSV import was six weeks old, and two of the accounts in Naomi's report had upgraded since then without anyone going back to correct the field.
The ceiling on the CSV-and-custom-field approach
Naomi's setup works because Coalbrook is one export, one join, one report, done by one person who remembers to run it. That stops holding up in predictable ways:
- The field goes stale between imports. An account that upgrades or churns doesn't update
account_arruntil the next CSV runs, so any report pulled in between is quietly working off old numbers, exactly what happened with Naomi's two accounts. - Matching breaks on name mismatches. A CSV row for "Coalbrook Field Services LLC" and a Zendesk organization named "Coalbrook" don't match automatically, and a failed match just means that account's tickets report as $0 revenue, invisible to anyone filtering by value.
- The request itself might not be in Zendesk at all. A request that shows up on a sales call or in Slack instead of a support ticket never gets counted, no matter how current the ARR field is, because Explore only reports on what's inside Zendesk.
None of this is a Zendesk shortcoming exactly. Revenue was never Zendesk's job, and the custom field plus import approach does what it's built to do. It's the ongoing labor of keeping a duplicated number in sync across two systems that eventually costs more than the report is worth.
How Modem keeps revenue and tickets in the same record
A disclosure before the pitch: Modem is a vendor in this exact market, built to close the join described above, so the next two paragraphs are self-interested by design. Modem's Stripe integration reads subscription and billing data directly, and when we asked the Modem agent "what features are our most valuable customers asking for," it joined live subscription revenue against open topics and returned a table of customers, ARR, and their top requests, no CSV export or organization-field maintenance involved.
The same pattern extends to Zendesk. Modem's Zendesk integration pulls tickets with their status, priority, tags, and requester, matches each requester to a person by email, and holds that alongside whatever Stripe or Salesforce data is connected. That also sidesteps the CSV name-matching problem from the previous section: Modem builds companies from email domains rather than joining name strings across systems, so a Zendesk organization called "Coalbrook" and a Stripe customer called "Coalbrook Field Services LLC" never need to match on name at all. Anyone on a shared domain rolls up under the same company automatically. A feature request filed by a support contact at a six-figure account and a matching request from the same account's Slack channel land on one topic instead of two disconnected records, ranked by the account's actual value rather than a field someone remembered to update last month. Pricing is unlimited users on every plan, pay-as-you-go beyond included usage, so adding revenue context doesn't turn into a per-seat line item for the support team.
Below a few dozen requests a month, Naomi's custom-field-and-CSV approach is a reasonable Tuesday-afternoon project. Past that, or once revenue answers need to come from more than one system, that's the point where a live join starts paying for itself. For the identity side of this same problem, matching a ticket to the right company at all before you can rank it, see why Zendesk Explore can't tell you which companies asked for a feature. For the broader landscape of tools built for this exact join, see the best tools to prioritize customer feedback by revenue.
Get this running before your next quarterly review
Create one decimal custom field on Zendesk organizations, export account names and ARR from wherever that number already lives, and run one bulk update to populate it. Then build a single Explore report: your feature-request tag, grouped by organization, with the new field as a second attribute. That's enough to answer "which requests are coming from our biggest accounts" the next time someone asks, though the field will drift out of date again unless someone owns keeping it current.
