How to handle duplicate feature requests

Duplicate feature requests look harmless: the same idea, posted twice. In practice they quietly break the thing a feedback list is for. Counts are split, so popular requests look smaller than they are. Discussion is split, so the best description of the problem sits on a post nobody reads. And customers who voted on the “wrong” copy never hear back when the feature ships.

This guide covers why duplicates happen, how to find them, how to merge them without losing anyone, and how to keep new ones from appearing.

Why duplicates happen

Customers aren’t careless; they just describe the same need in different ways.

• Different words. “Dark mode”, “night theme” and “a darker UI for the evening” are the same request.
• Different angles. One customer asks for “CSV export”, another for “a way to get my data into Excel”. The need behind both is getting data out.
• Different languages. A customer in Lyon and a customer in Kraków ask for the same thing in French and Polish.
• Different channels. One request arrives on the board, another in a support ticket that someone copies over, a third from a sales call.
• No search before posting. If posting is easier than searching, people post.

What a duplicate is, and what it isn’t

Before merging, decide what counts. A useful rule: two posts are duplicates when doing one would fully satisfy the people who asked for the other.

• “Export to CSV” and “export to Excel” are usually duplicates if a CSV opens in Excel for your customers.
• “Export to CSV” and “scheduled exports by email” are related, not duplicates. Shipping the first doesn’t satisfy the second. Group them under one larger item instead of merging.

Merging related-but-different requests hides real needs. When in doubt, group rather than merge.

How to find duplicates

Search before you triage

When a new request comes in, search the existing list for its key words and a couple of synonyms. It takes a minute and catches the obvious cases.

Read by category

Sorting requests into categories (reporting, integrations, permissions and so on) puts similar posts next to each other. Duplicates jump out when you read one category at a time.

Use similarity, not just keywords

Keyword search misses the cases above: different words, different languages. Tools that compare meaning rather than exact words find “night theme” when you search for “dark mode”, and match posts across languages.

Do a periodic sweep

New requests aren’t the only source. Once in a while, sort by most voted and check the top of the list for near-twins further down.

How to merge without losing anyone

Merging is where most of the damage is done. A good merge keeps everything that made both posts valuable:

1. Pick the clearest post as the one to keep. Usually the one with the best description, not necessarily the oldest.
2. Move every vote. Each person who voted on either post should count once on the merged one.
3. Keep the authors as followers. The person who wrote the duplicate cares just as much. They should hear when the request moves.
4. Keep the discussion. Comments on the duplicate often hold the best details: use cases, workarounds, edge cases.
5. Leave a trail. The merged post should say what it was merged into, so a customer who bookmarked it isn’t lost.
6. Tell the author, politely. “Thanks, this is the same as an existing request, so we’ve combined them; you’ll get updates there.”

Never just delete a duplicate. Deleting throws away voters and tells the author their post didn’t matter.

How to prevent duplicates

Merging is cleanup. Prevention is cheaper.

• Show existing requests before the post form. When people see a list of what’s already been asked, many vote instead of posting.
• Suggest similar posts while people type. A short “Is this the same as…?” list under the title catches most duplicates at the source.
• Make voting easier than posting. One click to vote, more steps to post.
• Give support a link to share. When a request arrives in a ticket, the agent finds the post and sends the link, instead of creating a new one.
• Write clear titles yourself. When you tidy a post, rename it to describe the need plainly. Clear titles are easier to find.

A worked example

Say your list has these four posts:

• “Dark mode” with a handful of votes and a short description.
• “Night theme please, my eyes hurt in the evening” with a couple of votes and a long comment thread.
• “Mode sombre” from a customer in France, with one vote.
• “Darker colours for the sidebar” with one vote.

The first three are the same request: a dark theme for the whole app. The fourth is related but narrower; a full dark theme would probably satisfy it, so it’s a reasonable merge too, but check the comments first in case the customer means something else, like contrast in a light theme.

Keep the post with the clearest title, “Dark mode”, and rename it if needed to “Dark mode for the whole app”. Merge the other posts into it, keep every voter and every author as a follower, and move the useful details from the long thread into the description: the evening use, the eye strain, the sidebar. The result is one request whose real size is visible, with a description that explains why people want it.

Then reply on the merged posts, so the authors know where their request went. One line is enough.

Duplicates across languages

If your customers write in several languages, keyword search won’t catch duplicates at all. A Spanish post and an English post about the same thing share no words. You need either someone who reads every language or a tool that translates posts and compares their meaning. The same applies to reading the board: customers are more likely to vote on an existing request if they can read it in their own language. Our page on multilingual feedback goes into this.

Why it matters for priorities

Clean counts are the foundation of prioritization. If one request is split across four posts, it competes with itself and loses to a smaller request that happens to live in one place. After a proper merge, the real size of each request shows, and so does who is waiting for it. Our guide on prioritizing feature requests builds on this.

How AntNexo helps

AntNexo’s AI compares the meaning of new posts with existing ones, in any language, and suggests a merge when it finds a likely duplicate; you can also let it merge automatically when it’s sure. A merge moves the votes, keeps the authors as followers and leaves a link from the merged post. In the widget and on the board, customers see similar requests before posting, so many vote instead.

See how the AI triage works, or how it fits into feature request management.