Duplicate Feature Requests and Split Votes in Zendesk
For tickets, merging is safer than most agents assume. Zendesk adds every CC from the ticket you're closing to the survivor, and makes that ticket's requester a CC too, so nobody on the thread gets dropped. What doesn't survive is the tag, type, priority, and status on the closed ticket, according to Zendesk's own merge documentation. If that ticket was carrying your feature_request tag, the merge quietly erases it unless the surviving ticket already had the same tag.
For community posts, the gap is bigger. Zendesk's Gather/community forums have no merge action at all. Two posts asking for the same thing keep separate vote counts forever, because the documented set of post management actions includes move, pin, feature, close for comments, and change status, among others. None of them combine two posts into one. A request that lands as three duplicate posts with six, four, and three votes reads as three weak ideas, when it's one idea worth thirteen votes.
“export is broken for us”
“any update on SSO?”
“we hit the rate limit again”
Read + clusteredWhat a ticket merge actually carries over
The mechanics are worth knowing precisely, because the gaps are specific, not vague. When you merge one ticket into another:
- Every CC on the ticket being closed is added as a CC on the surviving ticket, and the closed ticket's requester joins as a CC too. This is the part most agents worry about, and it's handled.
- Tags, type, priority, and status on the closed ticket are not carried over. Only the most recent public comment shows up in the merge preview; everything earlier stays on the now-closed ticket, tagged
closed_by_merge. - The merge is permanent. Zendesk's docs state plainly that merges "can't be undone or reverted."
Zendesk has shipped real improvements here. Merge suggestions surface likely duplicates in the context panel automatically, and bulk merging lets you fold a whole batch into one destination in a single action. Neither one restores the tags. If your feature-request signal lives in a tag, not in Explore's ticket-count-by-subject, the merge is the moment it disappears, and it's silent unless someone remembers to check.
Why community posts are worse
Ticket merging at least ships a partial answer. Community posts don't have one. Zendesk's own community forum carries a request posted in 2010 asking for exactly this: "The ability to merge forum posts, especially in feature requests, the same question or idea gets posted multiple time. The ability to merge these would be very valuable." More than fifteen years later, the idea's status is still Parked, not shipped. A later reply on that same thread spells out what a real fix would look like: "an option that would allow you to combine the original requests, the comment threads, and the vote totals." A Zendesk employee's suggested workaround in that thread is to mark one post a duplicate and redirect readers to the canonical one, which keeps the discussion legible but does nothing for the number that actually drives prioritization. The vote total stays split across both posts.
The result is structural, not a training problem. A popular request that gets re-posted by three different customers, in three slightly different phrasings, will sit at three separate vote counts below the threshold that would have gotten it noticed as one request past it.
A support lead's actual week
At Cobalt Depot, a ninety-customer fleet-maintenance SaaS shop, support lead Marisol Ibarra spent August chasing the same complaint through three separate reports. Drivers couldn't attach a photo to a completed inspection from the mobile app.
Ticket #5142 (DeShawn, ops manager at Haulwright): "Inspectors can't add a photo once the checklist is submitted. We need proof of damage before dispatch, and right now they're texting me pictures separately."
Ticket #5188 (Priya, fleet admin at Marrow Logistics): "Following up on a submitted inspection to add a photo isn't possible. Is this planned?"
Community post, 7 votes (an admin at Talbot Freight, a third customer): "Add photo attachment after inspection submit. Currently the only workaround is a separate email."
Marisol merged #5188 into #5142, since they came from different requesters and CCs combine cleanly. Both DeShawn's and Priya's names now sit on one ticket, which is exactly what the docs promise. But the feature_request and fr-mobile tags had been added to #5188, not #5142, and neither survived the merge. The surviving ticket read as an unlabeled bug report until Marisol caught it during her Friday tag review and re-tagged it by hand.
The community post was a separate problem entirely. Its 7 votes had no path into the ticket. Marisol's monthly count under-reported the request by exactly that number, because Zendesk had no way to fold a vote total into a ticket count, or a ticket count into a vote total. The same ask, counted three separate ways, in three tools that don't talk to each other.
The manual system that actually holds up
Short of an extraction layer, this is workable, but it takes discipline rather than tooling:
- Tag before you merge, not after. Make the rule explicit. Whichever ticket has the
feature_requesttag becomes the merge destination, never the source. If both have it, copy the tags onto the survivor manually before merging. - Leave a receipt in the merge comment. Note the tags and the requester count that existed on the ticket being closed, since that history disappears from view once it's
closed_by_merge. - Track community post votes in a separate running tally, keyed by theme rather than by post ID, and update it whenever a duplicate post appears. This is the only way a request like "mobile inspection photos" keeps its full weight, instead of splitting into a handful of smaller counts spread across whichever tickets and posts happen to describe it.
- Reconcile weekly. Pull the tag-based ticket count and the vote tally side by side for anything near your promotion threshold, since either one alone under-counts.
This is close to what we describe in how to run a feedback triage process: a known state, a small taxonomy, and a scheduled sweep. It's also exactly the manual reconciliation that Zendesk Explore can't do for you, since Explore reports on whatever tags and votes already exist; it doesn't notice when the same request is undercounted across two systems.
Where the manual system runs out of road
The system above works because Marisol can hold "mobile inspection photos" in her head across a ticket and a community post. Past a couple dozen live themes, or once requests start arriving from Slack and sales calls too, that recall stops being reliable, and the reconciliation step becomes the job rather than a Friday task.
That's the point where teams add something that reads every ticket and every community post, matches new mentions to an existing theme regardless of what it's tagged, and keeps a running total that isn't split by which surface the customer happened to use. That's the category Modem works in. It connects to Zendesk tickets, pulling in comments, requesters, tags, and status, alongside Slack, email, and call transcripts, and dedupes new mentions into one topic automatically, whether they came in on a ticket, an email, or a call. The two inspection-photo tickets above resolve to one topic with DeShawn's and Priya's names and the feature_request tag intact, instead of the tag disappearing into #5188's closed_by_merge history. The community post's 7 votes are outside what the Zendesk integration reaches today, since Zendesk's community forums aren't part of that sync, so that vote count still needs the manual tally above. Compare it against the rest of the field in best tools to mine feedback from Zendesk tickets; we build Modem, so weigh that pitch accordingly. Below a few dozen live requests a month, the manual system above is genuinely sufficient.
A place to start this week
Write the one-line merge rule (destination ticket keeps the tag, always) somewhere your team will see it, and start a single running spreadsheet row per open theme with a vote-plus-ticket count. The next time a duplicate post shows up, that row is where its votes go, instead of a fourth number nobody adds to the other three.
