Tell users when you ship the feature they asked for

Feature request follow-up means recording who asked for what, then contacting each of them when the feature ships, or when you decide not to build it. People who send suggestions are engaged customers, and silence teaches them that nobody reads the board. It works when customers already submit requests and you ship some of them. It costs a spreadsheet and a few emails.

How to do it

1. Log every request in one place with the requester's name, account and what problem they described. A spreadsheet is enough to start. Feedback tools add voting and automatic notifications.
2. Reply when the request arrives. Say it is logged and what happens next. Do not promise dates you cannot keep.
3. Update the status as work moves: under review, planned, in progress, shipped, not planned. If you use a feedback tool, check whether status changes email the requesters. Featurebase, for example, lets you send a default status notification to a request's requesters, or draft your own message to them.
4. When it ships, write a short personal note: what is new, where to find it, a thank you, and one question about whether it solves their problem. Offer early access to the next one (see VIP new features access).
5. If the feature is on a higher plan, say so plainly in the same note. Do not hide the price.
6. When you decide not to build something, tell the people who asked, with the reason. A clear no is better than a request sitting open for years.
7. Review monthly: how many requests shipped, and how many requesters you contacted.

What it looks like in practice

Say you run a scheduling tool. In March, a customer named Dev writes in asking for recurring bookings. You log it, reply "logged, and I will tell you when we decide," and tag his account. In June you start building it, and move the request to "in progress". In September it ships. Dev gets a note from you the same day: "Recurring bookings are live under Settings, Bookings. You asked for this in March. Could you try it on one real client this week and tell me what is missing?" This is a hypothetical setup, shown for the shape of the messages. It carries no result.

When it backfires

• Promised dates slip. "Next month" is read as a commitment. Use status words, not dates, unless the date is certain.
• Promotional emails fall under CAN-SPAM. If your note pitches an upgrade, it can count as commercial email. The FTC's guide says commercial messages need a clear opt-out and your valid postal address, opt-outs must be honored within 10 business days, and each violating email can carry penalties up to $53,088. The guide also says transactional or relationship messages are defined narrowly.
• You build for the loudest voices. A request log shows who wrote in, not what most customers need. Check each request against how many accounts have the problem.
• Shipping something different from what was asked. If you built a partial version, say so, and ask whether it solves the problem before announcing it widely.
• Exposing customers. Do not publish requesters' names or companies on a public board or changelog without their agreement.

Sources

• Featurebase help: sending request status updates, read Oct 8, 2026
• FTC: CAN-SPAM Act compliance guide for business, read Oct 8, 2026