Collecting feedback

How to handle duplicate feature requests

· 4 min read · By the Sikia team

On this page
  1. Why do duplicate feature requests happen?
  2. How do you tell if two requests are really duplicates?
  3. How do you merge duplicate requests?
  4. How do you find duplicates?
  5. What about requests that bundle several asks?
  6. What are the common mistakes?
  7. Doing this with Sikia
  8. FAQ

Duplicates are a good sign: several people want the same thing. They become a problem when they split the vote count, hide real demand, and leave you answering the same question in five places.

Why do duplicate feature requests happen?

  • Users don't search first. Posting is faster than searching, especially in chat.
  • People describe the same need differently. "Dark mode," "night theme" and "the app hurts my eyes at night" are one request.
  • Requests arrive through different channels. Discord, Slack, email, an in-app widget and your board never see each other.
  • Different languages. The same ask in Spanish and English won't match any keyword search.

You can reduce duplicates but not prevent them. Treat merging as routine work.

How do you tell if two requests are really duplicates?

Ask one question: would a single solution fully satisfy both people? If yes, merge. If it only partly would, link them or create a parent request.

Request A Request B Duplicate? Why
Dark mode Night theme for the dashboard Yes Same problem, same fix
Export to CSV Export a PDF for my accountant No Same area, different outcome
Bulk edit tags Change the due date on many tasks at once Partly Both want bulk editing; consider one parent request
Recurring invoices Automatic payment reminders No Different problems that sound related

Merge by problem, not by solution. Two users who both say "add a calendar view" may want different things: one wants to see deadlines, the other wants to plan the week. Their quotes tell you which.

How do you merge duplicate requests?

  1. Pick the canonical request. Choose the clearest one, not necessarily the oldest. Rewrite its title in plain problem language if needed, like "Dark mode."
  2. Move the voters. The author of each duplicate becomes a vote on the canonical request, along with anyone who voted on the duplicate. Count each person once, even if they voted on both.
  3. Keep the quotes. Attach each duplicate's original text and a link to where it was posted. Quotes are your evidence for prioritizing and designing.
  4. Add any new detail. If a duplicate mentions a new use case, add a line to the canonical description.
  5. Close the duplicate with a pointer. "Merged into 'Dark mode.' Your vote moved over."
  6. Tell the author. A one-line reply shows they weren't ignored, and you can notify them when it ships. See how to close the feedback loop.

Don't merge a bug into a feature request. "Export fails on large files" and "faster exports" are different kinds of work.

How do you find duplicates?

  • Search before you create. Try the obvious keyword plus a couple of synonyms.
  • Use fuzzy title matching. Trigram similarity catches typos and word-order differences. Full-text search catches shared keywords. Neither catches true synonyms, so a person or a language model has to confirm.
  • Clean up in batches. For a messy backlog, paste the titles into the duplicate request finder. It groups likely duplicates in your browser so you can review and merge them.
  • Schedule a pass. A monthly cleanup keeps counts honest before you prioritize. Clean counts matter most when you rank requests by votes; see how to prioritize feature requests.

What about requests that bundle several asks?

Split them. "Add dark mode, keyboard shortcuts and a Linux app" is three requests. Create or find each one, add the author as a vote on all three, and attach the same quote to each.

What are the common mistakes?

  • Deleting duplicates. You lose the person, their words and your ability to tell them it shipped.
  • Over-merging. Lumping everything into "Better reporting" creates one huge request nobody can build or estimate.
  • Merging by solution. Two requests for the same button can hide two different problems.
  • Merging silently. Users who see their post closed with no explanation assume they were dismissed.

Doing this with Sikia

For each captured message, Sikia looks for the existing request it duplicates using trigram and full-text search, and then the model confirms the match. It suggests merging the message as a vote with the user's quote attached, and a teammate approves it in the inbox. Non-English messages are translated to English with the original kept, so the same ask in two languages lands in one place. There's also a merge tool in Sikia's MCP server.

FAQ

Should I merge or close duplicate feature requests?

Merge. Closing without moving the vote and quote throws away demand and the person you'd notify later.

What if the duplicate has more votes than the original?

Make the clearest request the canonical one, regardless of age or votes. After the merge, the voters are combined either way, with each person counted once.

How do I stop users from posting duplicates?

Show existing requests prominently, write clear titles, and ask people to search first. Some duplicates will still arrive.

Should I merge similar requests from different customer segments?

Yes, if the problem is the same. Keep each voter's account details so you can still see which segments are asking.

Free tools for this

Do this without the spreadsheet

Sikia captures requests from Slack, Discord and an in-app widget, merges duplicates into votes, and emails the people who asked when you ship.

Related guides