Collecting feedback
How to handle duplicate feature requests
· 4 min read · By the Sikia team
On this page
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?
- Pick the canonical request. Choose the clearest one, not necessarily the oldest. Rewrite its title in plain problem language if needed, like "Dark mode."
- 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.
- 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.
- Add any new detail. If a duplicate mentions a new use case, add a line to the canonical description.
- Close the duplicate with a pointer. "Merged into 'Dark mode.' Your vote moved over."
- 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
Related guides
- Closing the loopHow to close the feedback loop with usersClosing the loop means telling users what happened to their feedback at each step: you heard it, you decided, and you either shipped it or won't. Record who asked and where for every request, merge duplicates without losing anyone, and use short templates so each reply takes seconds.
- PrioritizingHow to prioritize feature requests: votes, RICE and revenueNo single signal is enough: votes show how many users want something, revenue shows how much those users are worth, and RICE weighs value against effort. Merge duplicates first, shortlist by votes and revenue, score only the shortlist with RICE, then check it against your strategy before you commit.
- Collecting feedbackHow to collect feature requests from Discord without losing themTreat Discord as the inbox, not the database: give requests one dedicated channel, capture stray ideas from other channels yourself, and copy each one into a tracker with the user's handle, exact words and a link. Triage on a fixed schedule, merge duplicates as votes, and reply in the thread when the request moves.