How to tell Zendesk tags apart from your actual product taxonomy
Zendesk tags are not your product taxonomy, and Zendesk's own tooling agrees: tags are flat text with no built-in parent-child relationship, so billing, invoice, and invoices are three unrelated strings to Explore, not three spellings of one feature area. A real taxonomy has a hierarchy, where a billing category contains invoice and refund as children. A tag field has no concept of "contains." It just has strings, and it counts each one separately.
The direct fix is to stop treating tags as the taxonomy and use the field Zendesk actually built for hierarchy, a nested drop-down ticket field where you define the tree once and agents pick a path through it. Short of migrating to that field, you're stuck reading Explore reports where near-duplicate tags have to be grouped by hand, one formula at a time. Both paths are covered below, along with where each one stops holding up.
“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 NotionWhy a tag can't hold a hierarchy
Zendesk tags are deliberately unstructured. Per Zendesk's own docs on working with ticket tags, a tag can only contain alphanumeric characters plus dash, underscore, colon, and forward slash — no spaces, no #, no @. That restriction is why multi-word tags fragment on their own: customer_refund and customer-refund are two distinct tags to Zendesk, not one tag with a formatting quirk, and triggers, automations, and searches all require an exact string match. Get the connector wrong once and you've created a fourth bucket for the same idea.
There's also a practical ceiling. The tag field on a single ticket supports up to 5,096 characters total, and admin tooling for tags is limited to viewing the most-active tags from roughly the past two months, per Zendesk's tag admin page, and bulk-deleting a tag from every open ticket that has it. There's no rename, and no merge. If invoice and invoices both exist, deleting one loses the tickets that only ever had that one; it doesn't fold them into the other.
Reporting inherits the same flatness. Zendesk's Explore recipe for reporting on similar tags exists specifically because tag strings don't group themselves. The documented fix is a calculated attribute built from an IF (CONTAINS([Ticket tags],"option")) THEN "Option-related tags" ELIF... chain, written and maintained by hand, one branch per synonym you've noticed. And filters in Explore can't exclude a tag at all; per Zendesk's own troubleshooting doc, excluding a tag from a report requires writing a custom metric with an INCLUDES_ANY formula, because there's no native "not this tag" filter. Every one of these workarounds is evidence that a tag field has no idea two of its values mean the same thing.
The field that actually gives you hierarchy
Zendesk does ship a field built for this, a nested drop-down ticket field. You define levels separated by ::; Zendesk's own example is Cameras::Camera 1::Buy Camera 1, and an agent picks a path through the tree instead of typing free text. For a product taxonomy, that looks like Billing::Invoice::Duplicate charge as one value, with Billing and Invoice as real parent categories a report can query independently.
Reporting on a nested field is still a regex job in Explore (the recipe for nested drop-down fields uses formulas like REGEXP_EXTRACT([field],"^[^:]*") to pull out just the top level), but the hierarchy itself is real and enforced at entry time, which a tag never is. An agent can't accidentally create Billing::Invoic the way they can type a fifth spelling of a tag; the tree only has the branches you built into it.
Billing, invoice, and invoices were never one bucket at Bexley Freight
Bexley Freight Systems, a freight brokerage SaaS with twenty-eight people, runs Zendesk for shipment and billing questions from carriers and shippers. Support operations there belong to Torben Kessy, and he went looking for feature request volume ahead of a roadmap review and pulled Explore's top-tags report.
Torben, in the roadmap doc: Pulled our top ticket tags for the quarter.
billinghas 84 tickets,invoicehas 51,invoiceshas 19,billing-questionhas 12. That's four buckets that are probably the same ask, and I don't actually know the real number without reading all 166 of them.
He spent an afternoon sampling forty tickets across the four tags and confirmed most were the same underlying request, carriers wanting a downloadable invoice history instead of emailing support for one each time. He wrote a calculated attribute in Explore using the CONTAINS pattern from Zendesk's own recipe to fold the four tags into one reporting bucket, then proposed a nested field for the next quarter so new tickets wouldn't need the same manual grouping:
Torben, in the proposal: I want a
Product Area::Sub-areadrop-down that replaces free tagging for the top twenty request types. Existing tickets stay tagged the old way. I'm not going back to relabel 166 tickets by hand, but everything from launch forward gets a real category an agent picks from a list, not types.
The nested field shipped. The 166 older tickets stayed exactly as fragmented as Torben found them, because nothing in Zendesk retags a closed ticket when a new field goes live.
Where the nested field and the manual grouping both stop working
Torben's fix is the right one for the size of team he runs, and it has three honest limits that show up as volume grows:
- It's forward-only. A new field or a cleaner tag doesn't touch tickets filed before it existed. Historical volume stays split unless someone runs a retagging project.
- The tree still requires exact selection. An agent has to recognize that a carrier's "I never got a receipt for June" belongs under
Billing::Invoicerather than typing a new tag for it. Wrong category is quieter than a typo'd tag, but it's the same failure. - Neither structure reads the request itself. The
CONTAINSformula groups by tag string, and the nested field groups by what an agent picked. Neither one looks at "can you send a monthly PDF instead of per-shipment" and recognizes it as the same ask as "invoice history download," because that match lives in the wording, not in a tag or a field value.
That third limit is the one that doesn't go away with better tagging discipline. Past a few hundred tickets a month, teams that hit it stop trying to make the tag or field structure catch every phrasing and add a layer that reads what the ticket actually says. Modem works in that category, connecting to Zendesk to read ticket content directly, so "invoice history," "billing receipts," and "can't find past invoices" resolve to one counted topic whether or not anyone tagged them consistently, with no CONTAINS formula to maintain and no nested field to design in advance. We build Modem, so weigh that against the free options above accordingly; a wider comparison of tools working this same problem is in best tools to mine feedback from Zendesk tickets. If your tag sprawl problem is really about unused macros and duplicate tag spellings rather than missing hierarchy, the cleanup process is covered in how to audit Zendesk macro and tag sprawl; if it's about Explore not attributing requests to the right accounts, see why Zendesk Explore can't tell you which companies asked for a feature.
The version you can build this week
Pull your top twenty tags, sample enough tickets from each to confirm what's actually a duplicate, and write the CONTAINS-based attribute to group them in Explore before your next roadmap review. If the same three or four buckets keep colliding quarter after quarter, that's the signal to design a nested drop-down field for them, not to relabel history, just to stop the next 166 tickets from splitting the same way.
