Three customers request “scheduled reports,” another asks for “weekly email summaries,” and someone else wants “automatic CSV exports.” If these posts remain separate, votes fragment and the roadmap understates demand. If they are merged carelessly, the product team may erase three distinct use cases.
Duplicate management needs a repeatable process that consolidates demand without flattening the evidence behind it.
Quick answer: how to merge duplicate feature requests
Use this workflow in your feature request management software:
- Export or record the source posts before making changes.
- Confirm that the requests describe the same underlying outcome.
- Select a canonical post with clear, durable wording.
- Preserve votes, comments, segments, attachments, and original wording.
- Merge the duplicate posts into the canonical record.
- Verify totals, attribution, integrations, and internal references.
- Redirect customers and update any public roadmap item.
- Keep an audit note explaining what was merged and why.
Upvoty supports this workflow through feedback boards, customer segments, moderation controls, and Merge AI. Whatever system you use, treat a merge as a small data migration rather than routine inbox cleanup.
Why duplicate requests cause problems in feature request management software
Duplicates divide one signal across several records. A product manager looking at the most popular requests may see 18 votes on one post, 12 on another, and 9 on a third. None appears important enough to reach the top of the board, even though the combined customer demand is substantial.
The damage goes beyond vote totals. Comments become scattered, making it harder to identify constraints such as required export formats, delivery schedules, user permissions, or compliance needs. Product teams can also publish overlapping roadmap cards, send conflicting status updates, or create multiple engineering issues for one problem.
Merging appears to solve this. It can create a different problem when the operation retains the total votes but strips away why people voted.
Consider a sample SaaS reporting product with these public posts:
/feedback/scheduled-csv-exports, asking for a CSV file every Monday so finance can reconcile usage./feedback/weekly-email-reports, asking for a summary email sent to account administrators./feedback/automated-client-reports, asking agencies to send branded reports to each client.
All three concern scheduled reporting. They do not necessarily describe one feature. The first needs export generation, the second needs email distribution, and the third introduces branding and multi-client delivery.
That distinction matters. A broad post called “Automated reports” could collect every vote while giving the product team almost no useful scope information.
Step 1: back up feature request data before merging
Export the affected records first. Include post IDs, URLs, titles, descriptions, vote totals, voter identities where permitted, comments, tags, customer segments, attachments, status history, assignees, priorities, and linked development issues.
A full account export is useful, although a focused merge worksheet is often easier to inspect. Create one row per source post and record the intended destination ID. Add the date, moderator, and reason for the proposed merge.
For the reporting example, the worksheet might identify scheduled-csv-exports as the likely destination while leaving the other two posts unchanged until their use cases have been reviewed. Nothing has been merged yet.
This backup protects against three common failures: merging into the wrong destination, losing a comment during a manual transfer, and discovering that an external integration still points to a retired post.
Treat voter data carefully. Email addresses, account details, and comments can contain personal information. The data accuracy principle in Article 5 of the GDPR supports maintaining correct records, while access to exports should remain limited to people who need them for the merge.
If your feature request management software provides data exports, retain the pre-merge file according to your normal security and retention policy. Do not leave unrestricted spreadsheets in shared folders indefinitely.
Step 2: decide whether requests are true duplicates
Read the complete posts and their comments. Titles alone are poor evidence because customers often use the same term for different jobs or different terms for the same job.
A true duplicate usually shares the same user outcome, triggering condition, object being changed, and main constraints. Differences in phrasing or customer industry do not make requests separate when the expected product behavior remains the same.
The three reporting posts can be tested against four questions:
- Who receives or uses the output?
- What output must the product generate?
- What triggers delivery?
- Which constraints would materially change implementation?
The CSV and email-summary requests both involve a schedule, but they produce different outputs. The agency request adds branded templates and recipient management. Merging all three would hide meaningful scope.
A better decision is to keep “Scheduled CSV exports” as its own request. “Weekly email reports” can become the canonical post for requests about recurring summary emails. The agency post should remain separate and be linked through a shared tag such as scheduled-reporting.
Use merging only for genuine duplicates. When requests overlap without matching, link or tag them. When one request has already shipped under another post, close it with a reference to the released feature. When a submission contains several independent requests, split it before collecting more votes.
Step 3: choose the canonical feature request
The canonical post becomes the customer-facing record after the merge. Select it for clarity and continuity, not simply because it has the largest vote count.
A good canonical post has wording that will still make sense after several duplicates are added. Its description states the customer problem, avoids promising a specific implementation, and leaves room for the recurring constraints found in source comments.
Age also matters. An older URL may already be linked from support conversations, internal documents, search results, or a public roadmap. Keeping it can reduce broken references. However, an old post with a misleading title may be a poor destination.
For the example, suppose /feedback/weekly-email-reports clearly asks account administrators to schedule a recurring summary. A newer duplicate called /feedback/send-dashboard-every-friday has better detail but a narrow title. Keep the older URL, then improve its title and description before merging.
Write the canonical description so existing voters can still recognize their request. For example:
> Let account administrators schedule recurring summary reports for selected recipients. Requested controls include delivery frequency, recipient selection, report scope, and the ability to pause a schedule.
Do not include every suggested setting in the title. Detailed variations belong in comments, tags, or structured notes until the team decides what to build.
Step 4: preserve votes, comments, segments, and original use cases
The hard part is not increasing the number beside the vote icon. It is retaining the evidence required to interpret that number.
A reliable merge should preserve or explicitly record four layers of context.
First, preserve vote attribution. A customer who voted on two duplicates should normally count once on the canonical request, unless your prioritization method intentionally measures interactions rather than unique voters. Confirm how the software handles overlapping voters before assuming that 18 plus 12 equals 30.
Second, retain comments with their authors and timestamps. A copied block of unattributed text is less useful because the product team cannot follow up with the original customer. If comments cannot move automatically, summarize the use case in an internal note and keep a secure export of the source discussion.
Third, retain customer segments. Ten requests from free users and ten requests from enterprise administrators can produce the same vote total while implying different commercial impact, access requirements, and support urgency. Upvoty’s segments feature is designed to keep those groups visible during analysis.
Fourth, preserve original language. Product terminology can hide what customers were trying to accomplish. Keep a source note such as “Customer called this an emailed dashboard and needs it before the Monday operations meeting.” That sentence may later influence scheduling, time-zone behavior, and delivery failure alerts.
For the weekly email example, the canonical request should retain comments about recipient roles, Monday morning delivery, PDF attachments, and avoiding emails when no data changed. These are not four votes for four features. They are discovery inputs attached to one outcome.
Step 5: merge duplicates inside feature request management software
Perform the merge only after the destination and preservation rules are clear. Start with two records rather than a large cluster. Verify the result, then continue.
The exact controls vary among Upvoty, Canny, Featurebase, and Nolt. Before using any platform’s merge function at scale, test what happens to overlapping voters, comment timestamps, source URLs, attachments, tags, and status subscriptions.
Use this comparison to decide the correct consolidation action:
| Action | Use it when | What happens to demand | Main risk |
|---|---|---|---|
| Merge | Requests seek the same outcome with equivalent scope | Votes and discussion move to one canonical record | Distinct constraints become hidden |
| Link | Requests are related but require different product behavior | Each post keeps independent demand | Reviewers may still double-count related interest |
| Tag | Several requests belong to one theme | Individual records remain intact for thematic analysis | A broad tag can become an unhelpful catch-all |
| Split | One post contains multiple independent outcomes | Each outcome can collect focused evidence | Existing votes cannot be assigned precisely |
| Close as shipped | Another released feature already solves the request | Customers receive a resolution rather than a merge | The existing solution may only partially address the use case |
For the reporting cluster, merge /feedback/send-dashboard-every-friday into /feedback/weekly-email-reports. Keep /feedback/scheduled-csv-exports separate. Tag both with scheduled-reporting, and leave an internal note explaining that output format changes the engineering scope.
Avoid editing source posts into empty shells before merging. Their descriptions and comments are the material you need if the operation fails or the team later questions the decision.
Step 6: verify the merged feature request
Open the canonical record as both a moderator and a normal customer. Administrative views can conceal redirect, permission, or subscription problems that affect public users.
Check the resulting vote count against the unique voter list rather than adding visible totals. If five people voted on both source posts, a deduplicated total should account for that overlap. Record the before-and-after figures in the audit note without presenting them as new customer demand.
Then inspect comments in chronological order. Confirm that authors, dates, attachments, replies, and mentions remain understandable. A source comment saying “same as above” may lose meaning when moved beneath a different description. Add a moderator clarification where needed instead of rewriting the customer’s words.
Review segment totals too. The total number of voters might be correct while a segment assignment has disappeared. This can distort customer feedback prioritization, especially when product decisions consider plan, account type, or revenue relevance alongside raw demand.
Finally, test connected systems. A Jira or Linear issue may contain the retired URL. Support macros, CRM notes, and Slack messages may do the same. Where an integration relies on issue IDs rather than titles, preserve those identifiers and update links deliberately. Jira’s official documentation explains how issue links and remote links are represented through the Jira Cloud REST API, which is useful when auditing an automated sync.
Step 7: redirect customers and update the public roadmap
A merged source URL should lead customers to the canonical post when the software supports redirects. Sending visitors to a generic board page forces them to search again and can prompt another duplicate submission.
Add a short moderator note to the destination: “Merged related requests about scheduling recurring summary emails into this post.” Do not imply that the feature has been approved. Consolidation means the team has organized the evidence, not committed to delivery.
If either request appears on a customer-facing roadmap, retain one roadmap item and remove the duplicate. Recheck its title, description, and status. The combined discussion may reveal a larger scope than the original card suggested.
A trustworthy roadmap distinguishes collected demand from planned work. The guide to building a public product roadmap customers can trust explains how to communicate status without turning every popular request into a promise.
This is what customers should see on a well-maintained voting board after consolidation: one clear request, an understandable status, and the discussion that explains the need.
!Public voting board showing feedback and feature requests
Notify affected voters when the destination’s status changes, not merely because an administrator performed routine cleanup. An unnecessary merge notification can confuse customers who do not remember the original wording. When work ships, close the loop through the canonical post and changelog. This customer feedback loop guide covers the handoff from request to release communication.
Step 8: keep an audit trail for every merged request
Create an internal note containing the source IDs, source URLs, destination ID, merge date, moderator, reason, and any exceptions. Note whether votes were deduplicated and whether comments or attachments required manual handling.
This record helps when a customer asks where their post went. It also prevents future moderators from separating or re-merging requests without understanding the original decision.
Do not retain personal data solely because it might be useful one day. Keep operational records proportionate to the purpose and apply your established retention rules. Customers may also have rights concerning access to their personal data under Article 15 of the GDPR, so the team should know where merge exports and audit records are stored.
Review recently merged records after several weeks. New comments can expose a scope distinction that was missed. If recurring email summaries attract many requests for downloadable accounting files, the original decision to keep CSV exports separate remains justified. If every new comment treats both formats as interchangeable delivery options, the team can reconsider the structure with better evidence.
How Upvoty manages duplicate feature requests
A manual workflow can work at low volume, but it adds repeated checks each time a board grows. Upvoty brings the relevant records into one feedback management process.
Customers first submit ideas and vote through feedback boards. Because the discussion remains attached to the request, a moderator can compare descriptions, comments, and visible demand without assembling separate support tickets.
Next, Merge AI helps with identifying and consolidating duplicate feedback. The moderator still needs to decide whether two submissions represent the same outcome. AI can identify linguistic similarity, but terms such as “report,” “export,” and “email summary” do not settle product scope.
The moderator selects a clear destination and merges genuine duplicates. Votes and customer context can then be managed around one canonical post rather than competing entries. Segments add another view of who is asking, while smart tags can connect adjacent requests that should remain separate.
The feedback dashboard gives the team a central place to review the consolidated records and their supporting activity.
!Dashboard for managing customer feedback and feature requests
When the team commits to work, the canonical request can move onto the product roadmap. After release, a changelog entry and automatic voter notifications can update the people connected to that request.
The practical benefit is continuity. The request that collected the evidence remains connected to prioritization, roadmap communication, and release follow-up.
Common mistakes when merging duplicate feature requests
Merging based only on similar titles
“Mobile reporting” could mean a responsive dashboard, a mobile app, push notifications, or reports generated from mobile data. Compare outcomes and constraints before merging.
Adding vote totals without deduplicating voters
One active customer may vote on every duplicate while waiting for moderation. Counting that person several times inflates demand. Verify unique voters and document how the platform handles overlap.
Rewriting customer comments
Correcting grammar or converting comments into internal product language can alter meaning. Preserve the original comment and add a separate moderator note when clarification is required.
Using one oversized canonical request
A broad record such as “Improve reports” attracts votes but cannot support a clear roadmap decision. Keep independently shippable outcomes separate and connect them with tags.
Deleting source records immediately
Deletion can break URLs, remove history, and make recovery difficult. Prefer a supported merge with redirects, then retain a proportionate audit record.
Treating a merge as a roadmap commitment
Customers may interpret a consolidated vote count as evidence that work is approved. Keep collection, consideration, planning, and release statuses distinct.
Feature request management software FAQ
Should duplicate feature request votes be added together?
Yes, when the requests describe the same outcome, but overlapping voters should usually count once. Confirm the platform’s behavior and compare the final unique voter count with the source records.
Can two similar requests stay separate?
Yes. Keep them separate when implementation, user role, output, permissions, or success criteria differ materially. Link or tag them so reviewers can analyze the broader theme without combining the underlying evidence.
What should happen to comments after a merge?
Comments should retain their author, timestamp, replies, and attachments where possible. If the software cannot move them safely, record the important use cases in an internal note and keep a controlled pre-merge export.
How often should a product team review duplicates?
Review new submissions during normal moderation and inspect high-volume themes before roadmap planning. A smaller board may need a weekly review, while an active public board may require daily moderation. Use submission volume and decision cadence rather than an arbitrary schedule.
Can AI merge feature requests automatically?
AI can identify semantically similar posts and reduce manual searching. Final approval should remain with someone who understands product scope, because similar language can conceal different users, permissions, outputs, or workflows.
Which feature request management software is best for duplicate requests?
Choose software that preserves votes and comments, identifies overlapping voters, supports customer segments, redirects retired URLs, records moderation activity, and connects accepted requests to a roadmap and changelog. Test the merge behavior with sample records before comparing secondary features. The product feedback tools selection guide provides a broader evaluation process.
If duplicate requests are splitting demand across your board, consolidate them without discarding the customer evidence behind each vote. Use Upvoty to manage feature requests from submission and merging through roadmap updates and release communication.
