How to track feature requests from support conversations

Every product team says it listens to customers. Ask where the feature requests live and you get a spreadsheet last edited in March, a Slack channel called #feedback with 900 unread messages, and a support lead who “has a pretty good feel for it”.

Support hears more feature requests than anyone. Most of them never reach the roadmap, and not because nobody cares. They arrive one at a time, in different words, in different tools, and nobody has the hour a day it takes to collect them by hand. This guide is about making that hour unnecessary.

Why the spreadsheet stops working

The spreadsheet is how everyone starts, and it works for a while. It breaks in three predictable ways.

• It depends on someone remembering. An agent closing their fortieth chat of the day doesn’t stop to open a sheet. The requests that make it in are the ones from loud or memorable customers.
• Duplicates pile up. Row 14 says “Excel export”, row 88 says “export to xlsx”, row 131 says “download reports”. The sheet says three requests with one vote each. Reality is one request with three votes.
• The context is gone. A row saying “Excel export, Acme” doesn’t tell you what Acme was trying to do, how big they are, or whether they were about to leave.

None of this is fixed by a better spreadsheet. It needs requests captured from the conversation itself, automatically, with the context still attached.

What counts as a feature request

A feature request is a customer asking for something the product doesn’t do. That sounds obvious until you read real messages, because customers rarely say “feature request”. They complain, and the request is the last sentence:

Two more cases that trip people up:

• “Can I export to Excel?” If the product can, that’s a question, and the fix is documentation. If it can’t, it’s a feature request phrased as a question. Same words, different type, depending on your product.
• “It would be great if the export didn’t crash.” That’s a bug wearing a wish’s clothes. The product promised an export that works. It goes to engineering, not the roadmap.

The feedback taxonomy guide has the full set of types and the tests that separate them.

Same wish, different words

The most useful thing you can do with feature requests is merge them. Customers describe the need, not the feature, so the same request arrives in a dozen phrasings across email, chat and reviews.

Name each request after the need, in your product’s language, and keep the customers’ own words underneath. When a new ask comes in, the question is “which existing request is this?”, and only then “is this new?”

What to record for each request

A vote count alone is almost useless. For every ask, keep enough to decide and enough to follow up:

Counting is not prioritising

Once requests are merged, the temptation is to sort by count and build from the top. Don’t. Counts favour the needs of your largest customer segment and your most talkative users, which isn’t the same as what’s worth building.

Look at the same list with a bit more context:

Dark mode wins on count and loses on everything else. The Excel export comes mostly from paying customers, and six of them mentioned leaving in the same conversation. That’s your top request, and the raw count would have hidden it.

Also watch the trend. A request that went from two asks a month to fifteen after a competitor launched something similar is more urgent than one that has had forty asks spread over three years.

Tell them when it ships

When a request ships, tell everyone who asked. A short personal note (“you asked for this in March, it’s live now, here’s how”) turns a feature into proof that you listen. It also costs almost nothing if you kept track of who asked, and it’s impossible if you didn’t.

Keep the note short and specific:

Hi Maria, back in March you asked if you could export reports to Excel. As of today you can: open any report and click Export → Excel. Thanks for asking. Tell me if it works for your month-end.

This is planned for SignalScoop: it will keep track of who asked for what in every channel, and send that note when you mark a request as shipped.

A 30-minute weekly routine

Whatever tool you use, a fixed weekly slot beats good intentions. Thirty minutes is enough if capture is automatic.

The reading step matters more than it looks. Five real quotes explain a request better than any summary, and they are what convinces an engineer that the work is worth doing.

To see which requests are hiding in your own messages, paste one below. It finds every signal in it, feature requests included. Nothing you paste is stored.

Checklist

• Look for requests in every message, including complaints and questions.
• Merge asks into requests named after the need.
• Keep who asked, their words, where, when, and a link back.
• Rank by paying customers, churn risk and trend, not by count alone.
• Tell everyone who asked when it ships.
• Block 30 minutes a week and keep the order.