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”

↓ only what gets re-typed

/feedback form → 1 report filed

the other two fade out, never filed

↓ read in place

Read + clustered

all 3 counted · nothing re-typed

What 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.

The manual system that actually holds up

Short of an extraction layer, this is workable, but it takes discipline rather than tooling:

1. Tag before you merge, not after. Make the rule explicit. Whichever ticket has the feature_request tag becomes the merge destination, never the source. If both have it, copy the tags onto the survivor manually before merging.
2. 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.
3. 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.
4. 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 one person can hold a phrase like "mobile inspection photos" in their 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.

What replaces it is 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. Modem works in that category. 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. Two tickets describing the same request resolve to one topic with both requesters and the feature_request tag intact, instead of the tag disappearing into the merged ticket'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.