How to close the feedback loop on feature requests

Someone asks for a feature. Maybe you build it, maybe you don't. Either way, they rarely hear back, so the next time they have an idea, they keep it to themselves. Closing the feedback loop fixes that. It costs four short messages per request and no extra tools, as long as you know when each one is due and who should get it.

Google gave Android developers review replies back in 2012 for exactly this. One of the reasons it named was to "let users know when their feature requests have been implemented."

The short answer

To close the feedback loop on feature requests, reply four times at most: when you receive a request, when it is planned, when it ships and, instead of the last two, when you decide against it. Send the first within two working days, the others on the day the status changes, and send each one to everyone who asked or voted, not only to the first person.

What closing the feedback loop means

The phrase comes from customer experience, where Bain & Company built its Net Promoter System around it:

"To close the loop is not only to let customers know that you have heard their feedback but also to bring the customer’s voice right inside the organization."

Bain splits it in two. The inner loop is the reply to one person. The outer loop is the change a company makes because many people asked, and Bain counts "even product features" among them. A feature request runs through both: one person asks, the request becomes part of your product decisions, and the loop only closes when the people who asked hear the outcome.

Why the replies are worth it

• Ratings move. On Google Play, "developers respond to more than 100,000 reviews in the Play Console, and when they do, we’ve seen that users update their rating by +0.7 stars on average," according to Google's 2019 developer update.
• People change their minds when you answer. A study of 2,328 top free Google Play apps found that 4.4% of reviews that got a developer response were raised afterwards, against 0.7% of reviews that got none (Hassan et al., Empirical Software Engineering).
• Speed is part of the message. Bain describes leading companies that contact every customer who complains "within 24 hours." A feature request is not a complaint, but the same rule applies: a quick reply says someone is listening.

The four replies, and when to send each

The wording for each one is in the feature request template. This is about timing and recipients.

1. Received: within two working days

The first reply only has to say that a person read it. Send it to the person who asked, and include one question if anything is unclear, such as how they would use it. If the request already exists, say so and tell them their vote was added to it. That reply does double duty: it closes the first loop and teaches people to search the board before they post.

If you already know the answer, skip ahead. A request you will never build should get the declined reply right away, not a friendly acknowledgement followed by months of silence.

2. Planned: when it gets a release

Wait until the request has a place in a release, not just a spot on a wish list. Then tell everyone who asked or voted. Name the release or the season if you are confident, and leave out exact dates. A slipped date undoes the goodwill the reply was meant to earn. The guide to feature prioritization covers how requests get to this point.

3. Shipped: the day it ships

This is the reply people remember, so send it to everyone attached to the request: the person who asked, every voter and everyone who commented. For an iOS app, "the day it ships" means the day the update is live on the App Store, not the day you submit it. App Review can take a day or two, and an "it's live" message for an update nobody can download yet makes things worse.

4. Declined: as soon as you decide

The reply most teams skip, and the one that earns the most trust. Send it to everyone who asked or voted, give one honest reason, and offer a workaround if there is one. "Not now" is a fine answer if it is true. Then tell people what would change your mind, for example more votes from paying users.

Who counts as someone who asked

The same request arrives through every channel you have, and each person who sent it is owed the replies. Answer them where they asked:

• In the app or on your board: a status change and a short comment on the request, which everyone following it sees.
• By email or support chat: a reply in the same thread, so the person has the context.
• In an App Store review: a developer response. Apple notifies the reviewer, who can then update the review. The guide to replying to App Store reviews covers the rules, and finding feature requests in reviews shows how to spot them.
• In a public post: a reply to the post when it ships. It closes the loop for the person and shows everyone reading that asking works.

Then put them all on one request. Merge duplicates into a single entry and note where each one came from, so that a status change reaches everyone at once instead of five people out of twelve.

How to do it without a spreadsheet

The spreadsheet version breaks at the shipped reply, because by then nobody remembers the four support emails and the review from March. A routine that holds up:

• One list. Every request lives in one place, a feedback board, whatever channel it arrived through.
• Votes instead of duplicates. People who want the same thing vote on the existing request, so the people to tell are already listed on it.
• Statuses as the trigger. Each status change is one reply. When you move a request, you send the message, never later.
• An email at the moment of asking. An optional email field with "We'll tell you when it ships" next to it gets you the address you need months later.
• Visible statuses. A public status is a reply too. People who never left an email still see "Planned" or "Completed" the next time they open the board.

Closing the loop with WishKit

WishKit is a feedback board for websites, and for iOS apps through a native SDK. This is what it does for each reply today, and what is still up to you:

• Received: the iOS app confirms "Successfully submitted", and the person sees their own request while it waits for your approval. On the web board it carries the note "Only visible to you until it gets approved." There is no automatic email for this step.
• Planned: set the status to Planned. With status badges turned on, people see it on the request in the app and on the board. On Premium, add a comment as well, and it appears on the request labeled Admin.
• Shipped: move a request to Completed and WishKit emails every voter who left an email, with the subject "Update: [request] is implemented." The person who asked counts as the first voter, so they get it too. It is part of Premium and switched on per project under Projects, Edit, "Notify voters when a feature moves to completed."
• Declined: a rejected request leaves the board, so write the declined reply first. View upvoters on the request lists every voter with a name and email to send it to.

On Premium, merging duplicates carries the voters over to the request you keep. App Store reviews can be answered from the same dashboard and turned into requests. Premium is $15 a month flat, or $12.50 billed yearly, with unlimited users.

Mistakes that leave the loop open

• Only telling the first person. The twelve people who voted later wanted it just as much.
• Announcing too early. "It's live" before the update is in the App Store sends people looking for something they cannot find.
• Replying from a no-reply address. A shipped email is the moment people want to answer. Let them.
• Using the newsletter instead. Release notes and changelogs reach everyone and no one. The person who asked should hear it directly.
• Declining in silence. A request that quietly disappears teaches people that asking is pointless.

Frequently asked questions