How to deduplicate feature requests

Why duplicates distort your count

Ten messages asking for the same thing look like a strong signal. If three of them come from one customer who kept sending reminders, the real count is much smaller. Duplicates also split the discussion. One request sits in the inbox as "CSV export", another as "spreadsheet download", and nobody sees them together until the backlog is a mess.

Deduplicating means grouping the messages that ask for the same outcome, giving the group one name, and counting the people behind it.

Search for the words, then read the matches

Start with the nouns and verbs in the request. Search the product inbox for them, then read every match. Search finds the words customers used, not the same idea expressed in different words, so try synonyms as well: "export", "download", "spreadsheet" and "CSV" can all describe one request.

Read the matches instead of trusting the search. Some results describe a different request that happens to share a word. "Export" might mean a PDF in one message and a CSV in another, and grouping them would hide a real difference.

Name one canonical request

Write one short name for each cluster and use it everywhere. A good canonical name describes the outcome and includes the object:

• Weak: "Better export"
• Strong: "Export invoices as CSV with custom columns"

When two requests look similar but ask for different outcomes, keep them apart. Two customers who both write "make search better" may want faster results in one case and better filters in the other. A single name that merges them would hide a split, and the roadmap would miss one of the two fixes.

Keep the canonical names in a spreadsheet or shared document, with one row per request. Each row holds the name, the underlying problem from the problem behind the request, and the distinct customer count.

Count distinct customers

For each cluster, count people rather than messages. Use the email or ID on each item where it exists. The widget fills in name and email when your app calls identify, and the form asks anonymous senders for an email, so many items will have one. The identify call is described in the widget docs.

Two rules keep the count honest. First, one person counts once per request, however many times they wrote. Second, anonymous items cannot be matched to each other, so count them separately and label the total as a ceiling, because some may come from the same person.

Write the count and the date in the internal note of the most complete item in the cluster. The next review then starts from the same number instead of recounting from scratch.

Close duplicates without losing the sender

When a cluster has a canonical item, set the duplicate items to closed. Write a short internal note that names the canonical request. Closed means you decided not to track the item separately, which is exactly what a duplicate is.

Then reply to the sender if you have an email address. Tell them the request is tracked and what it is called. A reply makes the customer feel heard and makes it less likely they will send the same request again.

A cleanup routine for old repeats

Old backlogs hide the biggest clusters, and they take longer to clear than a normal week. Expect the first pass to take a full afternoon for a large backlog. Run a one-time cleanup, then keep a weekly habit:

1. Sort the idea items by date and work through the oldest fifty.
2. For each new item, search for its key words before you read it in full.
3. Attach the item to an existing canonical name, or create a new one.
4. Once a month, review the canonical list. Merge names that describe the same outcome, and split any name that covers two outcomes.

Once a canonical request ships, the cluster is the list of people to tell. The steps for that are in how to tell customers their request shipped.

Deduplicate inside Escuta Produto

Escuta Produto has no merge feature, no tags and no AI grouping. The routine above works with what it does provide:

1. Filter the product inbox to type idea.
2. Use text search with the keywords for each canonical request.
3. Record the canonical name and the distinct customer count in an internal note.
4. Set duplicates to closed, with a note that names the canonical request.
5. Export the CSV each week, so the counts sit in a sheet next to the roadmap.

Keep a single area or theme label for each cluster if you use one, so related requests stay near each other. The labeling approach is in how to build a tagging system for customer feedback.