Feature-Request Volume by Company in Zendesk
Yes, with real limits. Zendesk Explore's tag reports are built on the Support: Tickets dataset, so what you get by default is a count of tickets carrying a given tag, not a count of companies. You can add Organization as a row and filter by tag to get closer to an account view, but that only works for tickets where the requester's Organization field is actually populated. The report is buildable. What it counts is matched tickets, and every unmatched or under-tagged ticket disappears from it without a trace.
That gap between "tickets with a tag" and "accounts that want this feature" is where most Zendesk admins get stuck, and it's a real gap, not a configuration mistake. Zendesk's own documentation on tag reporting is explicit that "a tag can be added to multiple tickets and a single ticket can contain multiple tags," a ticket-to-tag relationship, not an account-to-tag one. There's no built-in view that already answers "how many named companies have asked for SSO," deduplicated and counted. You can build toward that answer, but it's a report you assemble by hand, and it stops being reliable the moment tagging discipline or organization matching gets sloppy, which for most support teams happens almost immediately.
“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 tag report is actually counting
Every Zendesk ticket has a requester, and if that requester belongs to an organization in your account, the ticket carries that Organization value. So a report with rows set to Organization, filtered to a tag like feature-sso, will genuinely group ticket counts by company where the link exists. That part works as advertised.
Where it gets unreliable:
- Unmatched requesters show up as blank. A contact who signed up with a personal email, or whose domain never got mapped to an organization record, generates a ticket with no Organization value. It's invisible to an org-grouped report, even though a real company is behind it.
- The same company can appear under two names. One contact files a ticket as "Acme Corp," another as "acme.io," and Explore has no reason to know they're the same account unless someone has already reconciled the organization records.
- Tag sync isn't instant. Per Zendesk's own docs, tag changes on tickets, users, or organizations can take up to an hour to reach Explore, so a report pulled right after a support shift ends can undercount.
- Selecting more than one tag in the filter panel changes the math. Zendesk's tag reporting article warns that "selecting multiple tags in the Filters panel multiplies the report's metric values by the number of matching tags," which means a ticket tagged both
feature-ssoandenterprisegets counted twice if you filter on both. It's a real quirk, not a hypothetical one, and it's easy to miss. - Tags themselves cap out. Explore stores only the first 255 characters of a tag, which rarely matters for short slugs like
feature-ssobut has bitten teams that tried to encode more context into the tag string itself.
None of this means Explore is broken. It means a tag report answers "how many tickets," and turning that into "how many companies, cleanly" is a step you do afterward, by hand, every time you want the number.
Rosa's actual count
Rosa Alvarez runs support ops at Corvid Metrics, a 40-person devtools company. The product lead asks a simple-sounding question in the weekly sync: how many companies have asked for SSO this quarter.
Rosa pulls up Explore, builds a report on the Tickets dataset, filters to feature-sso, and groups by Organization. The report comes back with 14 tickets.
Product lead: "Great, so nine companies, right, based on the ticket count?"
Rosa: "Not quite. Fourteen tickets, but three of them are 'Corvid' and 'corvidmetrics.io,' the same account under two organization records. Two more have no organization at all because the requester used a personal Gmail. And there's a ticket from Meridian that never got the tag because the agent solved it as a 'how do I' question instead of a feature request. So the real number is somewhere around ten or eleven, and I only know that because I went through the list line by line."
Rosa's answer is honest and it's also the whole problem: the tag report gave her a starting point, not a finished count. Getting to something she could put in a roadmap doc took a manual pass, tribal knowledge about which organization records were duplicates, and a guess about at least one ticket that should have counted and didn't.
Where the manual join stops being worth it
At low volume, ten tickets a quarter, Rosa's approach is fine. She knows her customer base well enough to catch the duplicates and the misses by eye. That stops scaling in a specific, predictable way. Past a few dozen tagged tickets a month, across more than one support agent, the manual reconciliation that made the count trustworthy takes longer than deciding what to build with the number once you have it.
The failure mode isn't dramatic. Nobody gets a wrong report and ships the wrong feature. What happens is quieter. The monthly count starts getting skipped because it's tedious, the org-matching backlog grows, and "which companies want this" turns back into a question someone answers from memory in a meeting instead of from a report.
This is also where Zendesk alone can't help, because the underlying data it's missing isn't a Zendesk problem. A company that raised the same request on a sales call, in Slack, or in a GitHub issue doesn't show up as a duplicate signal in Zendesk at all. Explore only knows about the ticket that happened to land there. If your customers report the same thing across more than one channel, an account-level count built purely from Zendesk tags is undercounting by definition, regardless of how clean your organization records are.
How Modem closes the gap
One disclosure up front: Modem is the tool we sell, and closing exactly this gap is what it's for. Read the rest with that in mind. Modem's Zendesk integration reads tickets, requesters, and organizations, and resolves each request to a person and a company automatically, rather than depending on the ticket's Organization field being populated correctly. A request from a personal email address and a request from a matched work domain both land on the same account if Modem's own matching connects them, which is exactly the reconciliation Rosa did by hand.
The bigger difference shows up across channels. If the same request also came in on a sales call transcript, a Slack thread, or a GitHub issue, Modem treats it as one topic with every requester attached, not three separate signals split across three separate tools. The count that comes out the other end, nine companies, say, with names and quotes attached, is a number you can hand to a product lead without a caveat about duplicate org records or missed tags. Modem's pricing is unlimited users on every plan with pay-as-you-go beyond included usage, so adding this doesn't mean licensing a new report-builder per admin.
Under a few dozen tagged tickets a month, Rosa's manual process is genuinely fine, and there's no reason to add a tool to solve a problem that costs fifteen minutes once a quarter. Past that volume, or as soon as the same requests start arriving through more than Zendesk alone, the manual join is the part that breaks first.
For how a tool resolves the same request across channels into one countable thing, see what is a customer context graph.
