Closing the Loop: Why Telling Users Their Request Shipped Keeps Them Around

A user takes two minutes out of their day to tell you what would make your app better. Then they hear nothing. Weeks later the feature quietly appears in an update, and they never connect it to their request. You did the work, and you got none of the goodwill.

"Closing the loop" means going back to the person who gave feedback and telling them what happened. It sounds like a courtesy. In practice it is one of the cheapest ways to keep users engaged.

Why it matters

People want to know they were heard. Customer-experience research has long treated follow-up as part of the feedback process rather than an extra. Bain & Company, which created the Net Promoter System, describes closing the loop with customers as a central element of that system. Their note Closing the Loop and the Net Promoter System page on the same idea are the sources used here.

Silence teaches users to stop posting. If requests disappear into a void, the next idea goes into a one-star review or a support ticket instead, or nowhere at all.

A shipped request is a reason to come back. An email saying "the thing you asked for is live" is the most relevant message you will ever send that user. It is not marketing. It is an answer.

It turns users into advocates. Someone who suggested a feature and saw it ship has a story to tell. Those are the people who leave good reviews and recommend your app.

What closing the loop looks like in practice

You do not need a campaign. You need three habits.

1. Acknowledge quickly

When a request comes in, a short reply ("Thanks, we have seen this. Others have asked too.") tells the user a person read it. If the idea is a duplicate, merge it into the existing request so their voice adds to the count instead of getting lost.

2. Update at the moments that matter

Not every status change deserves an email. Pick the ones a user would actually care about: usually when work starts, when it is in beta, and when it ships. Too many emails feel like noise; none at all feels like neglect.

3. Say no honestly

Rejecting a request is also closing the loop. A one-line explanation ("This does not fit where the app is going, but here is what you can do instead") earns more respect than leaving it open forever.

A simple template

When a request ships, the message can be this short:

Your request is live

You asked for dark mode for the editor. It is in today's update. Thanks for the idea, and keep them coming.

No upsell, no newsletter. Just the answer.

How FeedbackKit helps

FeedbackKit is built around this loop. Status email goes out for the statuses on that project's list. A new project starts with a default list — approved, in progress, completed and rejected — and choosing a different list needs Pro. The person who submitted the request receives the email, on any plan, when they gave an address. A voter receives it when they opted in and the project is on Team. On Free or Pro the vote still counts, and the voter opt-in is not stored. When the new status is rejected, that email can include a short reason.

A reply from your team stays on the request, where the person who asked can read it in the app. You manage status changes and replies from the web dashboard or from the native admin apps for iPhone, iPad and Mac. Team includes what Pro includes, so choosing the notify list is available on Pro and on Team.

The takeaway

Collecting feedback is half the job. The other half is telling people what you did with it. Reply when a request arrives, email when it moves at the moments that matter, and be honest when the answer is no. Users who feel heard tend to stick around.

Try FeedbackKit for free