How to Handle Duplicate Feature Requests: Detection, Merging, and Process

Open any feedback board that’s been running for a year and you’ll find the same feature requested five different ways. “Dark mode.” “Night theme please.” “Option to reduce eye strain.” “Dark UI like Linear has.” “Theme customization.”

The reflex is to treat this as mess — noise to be cleaned up, a tax on whoever does triage. That reflex gets the situation backwards. Five separate requests for the same thing is your users independently converging on a need, phrased in their own words, without ever seeing each other’s posts. That’s about the strongest demand signal a feedback board can produce.

The real problem isn’t that duplicates exist. It’s what happens when nobody consolidates them: the demand signal gets split five ways, and a feature that forty people want looks like five features that eight people want. This guide covers how to detect duplicates, how to merge them without annoying the people who submitted them, and how to build a handling process that doesn’t collapse as your board grows.

Duplicates Are Signal, Not Noise

Start with the reframe, because it changes how you treat every part of the process.

When one user requests a feature, you’ve learned that one user wants it. When a fifth user requests the same feature independently — different words, different use case, no awareness of the earlier posts — you’ve learned something much more valuable: this need is widespread enough that people keep running into it on their own. Nobody campaigned for it. Nobody linked their friends to a thread. The demand is organic.

Duplicates also carry information that votes don’t. A vote says “me too.” A duplicate request says “me too, and here’s my version of the problem” — a fresh use case, a different workflow, sometimes a phrasing that finally makes the need click for your team. The user who writes “I need to export my data before our compliance review each quarter” has told you far more than the vote counter did. When you merge duplicates properly, you keep all of that context in one thread instead of losing it across five.

So the goal of duplicate handling is not to prevent duplicates or punish them. It’s to consolidate them — fast enough that the demand signal stays readable.

The Cost of Letting Duplicates Sit

Unmerged duplicates do specific, compounding damage.

They split votes. This is the big one. Forty people who want the same feature, spread across five threads, produce five requests with eight votes each. If you prioritize by demand, that feature now loses to a twelve-vote request that only exists once. Your prioritization isn’t measuring demand anymore — it’s measuring which request happened to attract the crowd first.

They fragment the discussion. Use cases, workarounds, and design suggestions scatter across threads. Whoever eventually builds the feature reads one thread and misses the context in the other four.

They make the board look unmanaged. Visitors who see the same request five times draw the obvious conclusion: nobody is reading this board. That perception suppresses future submissions from exactly the thoughtful users you most want to hear from.

They multiply your communication debt. When the feature ships, five threads need closing. When it’s declined, five sets of voters need the explanation. Every duplicate you don’t merge today is a status update you’ll owe in duplicate later.

Three Ways to Detect Duplicates

Detection approaches stack — mature boards use all three.

Manual triage

The baseline: a human reviews new requests on a regular cadence and checks each one against existing threads. On a small board this is genuinely fine — if you get a handful of requests a week, triage takes minutes, and a human catches things automation misses, like two requests that share zero vocabulary but describe the same underlying need (“bulk edit” and “I keep changing the same field on 50 items one by one”).

The failure mode is scale and memory. Past a few hundred open requests, no triager reliably remembers what’s already on the board, and search-by-keyword misses synonyms. Manual-only detection quietly degrades as the board grows — usually without anyone noticing until the duplicates are already entrenched.

Search-before-post

The second layer moves detection to the moment of submission. When a user starts typing a new request, the board searches existing requests live and shows matches: “Is this what you’re looking for?” If the user sees their idea already exists, they vote on the existing thread instead of creating a new one.

This is the highest-leverage mechanism, because every duplicate it prevents costs you nothing — no triage, no merge, no notification. It converts would-be duplicates directly into votes, which is exactly what you wanted anyway. Most dedicated feedback board tools do this out of the box; if you’re collecting requests through a form, email, or spreadsheet, you get none of it, which is a real hidden cost of DIY setups.

Its limit is that it depends on vocabulary overlap. “Dark mode” surfaces “dark theme,” but it won’t surface “reduce eye strain at night.” Some duplicates will always get through.

Automated and AI flagging

The third layer catches what slips past the first two: the system compares new requests against existing ones by meaning rather than keywords and flags likely duplicates for review. Semantic matching catches the “dark mode” / “easier on the eyes at night” pairs that keyword search misses.

The important design property is that it flags rather than auto-merges. Judging whether two requests are truly the same need is a product decision — two similar-sounding requests can hide different problems, and a false merge is worse than a missed one. fdback takes this approach: it flags potential duplicates automatically, and a human confirms the merge. Treat any tool that merges without review with suspicion.

Merge Etiquette: Consolidating Without Burning Goodwill

A merge done carelessly reads as “your request was deleted.” A merge done well reads as “your request joined forces with others.” The difference comes down to four rules.

Preserve the votes. When you merge request B into request A, B’s voters must carry over to A. This is non-negotiable — it’s the entire point of merging. If your tool discards votes on merge, the merge destroys the signal it was supposed to consolidate. (Check for double-counting too: a user who voted on both threads should count once.)

Preserve the comments and context. B’s discussion — use cases, workarounds, specifics — should remain readable from A, whether it’s moved into the thread or kept attached to the merged request. Whoever builds the feature will want all of it in one place.

Pick the right canonical thread. Usually that’s the oldest request or the one with the most votes and discussion. But favor the one with the clearest title and problem description — that’s the thread new visitors will find, vote on, and judge your board by. You can always edit the canonical title to be clearer; do that rather than canonicalizing a vague thread out of seniority.

Notify the person whose request was merged. Silence is what makes merges feel like deletions. A two-sentence comment fixes it: “Merging this into [link] so all the votes and use cases live in one place — your vote carries over, and you’ll get updates as it progresses.” If their version contained a unique detail, say you’ve noted it on the main thread. That single acknowledgment turns the interaction from rejection into inclusion. (For more copy-paste responses like this, see our feature request response templates.)

When Not to Merge

The judgment call that makes duplicate handling a human job: similar requests are not always the same request.

“Export to CSV” and “export to PDF” share a verb, not a need — one feeds spreadsheets, the other feeds reports for humans. “Slack integration” might mean notifications for one requester and creating feedback from Slack messages for another. Merge those and you’ve buried two distinct needs under one vague thread, and voters on the merged thread now want different things — which makes the vote count less meaningful, not more.

The test is the underlying problem, not the surface phrasing: would one shipped feature fully satisfy both threads? If yes, merge. If it would satisfy one and leave the other waiting, keep them separate — and consider linking them as related so triage sees the family resemblance without collapsing it.

When in doubt, ask. A clarifying comment (“Is [existing thread] what you’re after, or is your case different?”) costs one minute and routinely surfaces distinctions you’d have flattened.

A Duplicate-Handling Process That Scales

Putting it together into something a small team can actually run:

1. Route everything to one board. Duplicates can only be detected against requests that live in the same place. If feature requests arrive via support tickets, sales calls, and DMs, log them all to the board — otherwise the same request lives in three systems and no amount of merging fixes it.

2. Let search-before-post do the first pass. Prevention is free. Make sure your submission flow surfaces existing requests as users type.

3. Triage new requests on a fixed cadence. Weekly works for most teams. For each new request: check for existing matches (aided by automated flags if your tool provides them), merge true duplicates using the etiquette above, and link near-duplicates as related instead of merging them.

4. Merge on sight, not “someday.” Duplicates get more expensive with age — more votes to consolidate, more comments to preserve, more people to notify. A duplicate merged in week one is a two-minute task.

5. Close every merged loop when the feature ships. Because votes carried over, everyone who ever requested the feature — through any of the merged threads — gets the “it’s live” notification. This is where the earlier discipline pays off: the feedback loop closes for forty people at once, including the thirty who asked in threads that no longer exist.

One habit worth adding: when a request keeps getting duplicated even though it’s already on the board, treat that as data too. It usually means the canonical thread has a bad title, or your board’s search is missing an obvious synonym. Rename the thread with the words users actually use.

FAQ

Should I delete duplicate requests instead of merging them?

No. Deletion discards the votes, the comments, and the submitter’s goodwill in one move — the person who posted it sees their contribution vanish. Merging preserves all three. The only requests worth deleting outright are spam and accidental double-posts by the same user seconds apart.

What’s the difference between a duplicate and a related request?

A duplicate describes the same underlying need: one shipped feature would fully satisfy both threads. A related request shares a theme but has its own need — “export to CSV” and “export to PDF” are related, not duplicates. Merge duplicates; link related requests so they stay individually voteable.

Do votes transfer when requests are merged?

In any tool with proper merge support, yes — voters from the merged request are carried onto the canonical one, and users who voted on both count once. Verify this before adopting a tool, because it’s the entire point of merging. If you’re tracking requests in a spreadsheet, you’ll need to consolidate counts by hand and keep a note of who asked, so you can still notify them when it ships.

Should I tell users their request was a duplicate?

Yes, always — but frame it as consolidation, not correction. “This is already being tracked here, your vote carries over, and you’ll get updates” takes one comment and turns a potentially deflating moment into proof that the board is actively managed. Bare “duplicate, closed” labels with no link and no explanation are how boards teach users to stop posting.