How to audit Zendesk macro and tag sprawl before it buries feedback
Run two checks: sort your macros list by usage (Suite Growth or Support Professional plan and up) to find the ones nobody has touched in months, and pull a ticket export to see how many distinct tag strings mean the same thing. Do both quarterly, retire what you find, and write down the taxonomy so the next agent doesn't reinvent it. That's the audit. The harder problem is that Zendesk gives you no report that shows a feature request tagged sso, sso-request, and feature-sso is one request three times over. That dedupe step is manual, every time.
Macro and tag sprawl in Zendesk happens for a structural reason, not a discipline one. Any agent can create a personal macro, and any agent can type a new tag on any ticket. Neither requires review. A year in, a support team with only a handful of agents can rack up forty tags for feature requests, and nobody remembers which three are duplicates.
“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 macros multiply faster than anyone notices
Zendesk macros come in two kinds, and they don't get looked at the same way. Shared macros are built by an admin for the whole team, and every agent works from the same list. Personal macros are built by an individual agent for their own use, and only the creator can run one. Zendesk does make them visible to admins in Admin Center, where an admin can open a colleague's personal macro and even clone it, but nothing routes them there for review. An admin has to think to look. Every agent who writes three or four personal shortcuts for their own common replies adds to a pile that sits untouched until someone runs an audit like the one below, and that pile doesn't get cleaned up when they change teams or leave.
Zendesk does give you a way to see what's actually getting used. The macros page in Admin Center can be sorted by usage, alongside name, creation date, and last-updated date, though usage sorting is gated to Suite Growth or Support Professional plans and above. Zendesk also surfaces the three most-used macros from the past week at the top of each agent's list automatically, a convenience feature an admin can turn off from the same settings menu. Neither of these is an audit tool. The usage sort tells you what's popular this instant; it doesn't tell you which of your forty "acknowledge and log a feature request" macros duplicate each other, or which ten have a usage count of zero going back a year.
Why tags fragment the same request five ways
Tags have no visibility feature at all. A tag is free text, so an agent types feature-request on one ticket and feature request on the next, and Zendesk treats them as two separate tags with two separate counts. Macros add to the pile because a macro action can add, remove, or replace tags on a ticket, and Zendesk's own documentation warns that triggers or automations can conflict with a macro's tag update, causing tag collisions on the same ticket. The fragmentation isn't only agents typing inconsistently. It's macros, triggers, and manual typing all writing to the same tag field with no shared taxonomy enforcing consistency between them.
The result matches what shows up in aggregated Reddit sentiment on Zendesk admin overhead: the platform is "deep and endlessly configurable," and the admin work of keeping triggers, automations, and macros coherent with each other "never stops." Tag sprawl is that same dynamic playing out in the one field agents touch on every single ticket.
The audit: what Greta Solstad found at Panhandle Metrics
Greta Solstad runs support operations at Panhandle Metrics, a twenty-two-person analytics SaaS company with six support agents on Zendesk. She'd never run a macro or tag audit before; the account had been live for three years and had accumulated whatever each agent needed at the time.
She started with the macros page, sorted by usage, and filtered to the active list of 61 macros.
Greta, in the team Slack: Sorted our macros by usage just now. We have 61 active macros and 14 of them show zero uses in the sort window. Four are personal macros from Wes, who left in March.
She deactivated the zero-usage macros rather than deleting them outright, per Zendesk's own lifecycle: deactivating moves a macro to the inactive list without destroying it, and only a deactivated macro can be deleted for good. That gave her a two-week buffer to confirm nothing broke before deleting anything permanently.
Tags took longer. She exported three months of tickets and pulled the tag column into a spreadsheet, then sorted by frequency:
Greta, in the audit doc:
feature-request(203),feature request(31),fr-request(12),feature-req(9),enhancement(44). That's five tags for the same intent, andenhancementmight also just mean "small ask," not a real feature request. I have to read a sample to be sure.
Reading the sample took her most of an afternoon. She landed on one umbrella tag, feature-request, and folded the near-duplicates into it by selecting the affected tickets and applying a macro with a retag action across all of them at once, the bulk-macro workflow Zendesk documents for exactly this. She left enhancement alone once she confirmed it meant something genuinely different in practice. She wrote the taxonomy into the team wiki with one-line definitions, the same fix Intercom-based teams use for feature-request tag drift. A written taxonomy is what keeps the audit from needing to happen again in a year.
Three ways this comes undone
Greta's audit was worth doing once. It also has a shelf life, and it's short:
- The dedupe step doesn't scale with ticket volume. Reading a sample of tagged tickets by hand to confirm what
enhancementmeans in practice works at a few hundred tickets a quarter. At a few thousand, nobody has the afternoon. - New tags accumulate the moment the audit ends. Nothing stops the next agent from typing
feature ideanext week. The taxonomy document only works if every agent reads it before typing a new tag, and that compliance decays. - Tags and macros don't connect requests across channels. Panhandle's customers also ask for things in sales calls and a shared Slack channel. None of that shows up in a Zendesk tag export, so the count Greta found is a floor, not the real number.
Once those three limits show up, some teams stop trying to fix the field itself and add a layer that reads tickets by what they say, not by what they were tagged. Modem works that way: it connects to Zendesk and reads ticket content directly, so three tickets tagged feature-request, enhancement, and left untagged entirely still resolve to one counted topic if they're describing the same thing. Pricing is unlimited users on every plan with pay-as-you-go beyond included usage, not a per-seat cost that grows with your support team, and we should be upfront that we build Modem and have a stake in recommending it. The audit above is the honest, free version of the same fix, and it's the right starting point for a team Panhandle's size. For a wider comparison of tools that work on the same problem, see best tools to mine feedback from Zendesk tickets; for what happens after requests are counted correctly, see why Zendesk Explore can't tell you which companies asked for a feature.
The two exports that fix most of it
Sort your macros by usage, deactivate anything at zero for the quarter, and give it two weeks before deleting. Export ninety days of tickets, count the tag strings that look like they mean the same thing, and pick one canonical spelling for each. Write the taxonomy down somewhere every agent will see it. None of that needs new tooling. It needs an afternoon and a recurring line on someone's calendar.
