Feature-Request Review Replies That Feed Your Roadmap

To reply to a "please add X" app review, do four things: name the exact feature they asked for, tell them honestly where it sits (building it, weighing it, or not planned), promise only what you can actually keep, and log the request somewhere it won't evaporate. No fake dates. No "coming soon" you'll regret. That's the reply. The rest of this page is the templates, the honest-no scripts, and the part most teams miss: turning a stack of these into an actual roadmap.

Feature requests are the friendliest reviews you'll get, which is exactly why they're the easiest to fumble. A person who writes "love the app, please add a dark mode" isn't angry. They're invested enough to tell you how to make the product better and then hand you their email address in public. Reply badly, with a canned "thanks for the feedback!" or a promise you can't keep, and you waste your single warmest signal. Reply well and you get a happier user, a stronger listing, and a data point you can build on.

A one-star bug report is a fire. A feature request is a gift, and it wants a different reply. The reviewer isn't demanding you fix something broken; they're telling you what would make them love the app more. That changes the goal: you're making this specific user feel heard while quietly harvesting product intelligence you'd otherwise pay for.

It also changes the trap. The complaint trap is getting defensive; the feature-request trap is getting generous, over-promising to sound responsive. "Great idea, we'll add that soon!" feels warm today and turns into a broken promise the day you don't ship it. Every future reader who scrolls your listing sees a request marked "soon" that's sat for eight months, and now you look worse than if you'd said nothing. Honesty scales; enthusiasm doesn't.

Every good reply to a feature request runs the same four beats. Once you internalize the shape you can write one in under a minute, in any tone your brand uses. (For the complaint, refund, and praise variants, see the full [app review response templates](/blog/app-review-response-templates); this page is the request-specific one.)

Here's the shape in the wild. Notice the reply commits to nothing it can't deliver, yet the reviewer walks away feeling handled, because being heard, not being promised, is what they came for.

That reply is honest to the character. It doesn't say "coming in the next update." It says "on our list, no date, logged, I'll tell you." Every clause is keepable. And it fits comfortably under Google Play's hard 350-character reply limit, which forces exactly the discipline feature-request replies need: you can't ramble your way into an over-promise if there's no room. (If cramming the four moves into 350 feels tight, that's its own skill; we break it down in [how to write a 350-character review reply](/blog/write-a-350-character-review-reply).)

The whole game is saying true things that still feel warm. There's a small vocabulary for this, and it's worth memorizing because the wrong word is what gets screenshotted back at you.

Use "on our list," "we're weighing it," "logged and counting toward priority," or "actively building, targeting this quarter" only when it's literally true. Avoid "soon," "in the next update," "definitely," and any specific day. The difference between "soon" and "on our list" looks tiny on the screen and is enormous in six months, because one of them is a promise with a clock on it and the other is a status you can hold forever without lying.

Not every request should ship. Some are off-strategy, some are one person's edge case, some ask for the opposite of what the product is for. The instinct is to go vague and hope they forget. Don't. A clear, kind "not planned, and here's why" earns more respect than a mushy "we'll consider it" that everyone reads as a no anyway.

The move is: thank them, be straight that it's not on the roadmap, give a one-line reason if you have a good one, and where you can, point to a workaround or an existing feature that gets them 80% of the way. You're allowed to say no. You're not allowed to be evasive about it.

That reply says no to two things and yes to one, out loud, and comes off as confident rather than dismissive. The next reader learns what the product is for. The reviewer learns you have a spine and a plan. Both of those are worth more than a limp "great ideas, we'll think about it!" that commits to nothing and reassures no one.

Some feature requests are for things that already exist, or shipped last week and the reviewer hasn't updated. This is the easiest win on the board. Correct the record warmly, tell them exactly where to find it, and you've converted a mild complaint into a moment of delight, often a rating bump, since they were already close. The upside here is measured, not hoped for: across 4.5M reviews, Hassan et al. found a user who got a reply was roughly six times more likely to raise their rating (4.4% vs 0.7% with no response). A "we already shipped that, here's where" reply is that mechanic at its most frictionless.

And if the request is one you did ship because people like them asked, this is the reply that proves the loop is real. "You asked, we built it" is the single most powerful thing a small team can say in public, and feature-request reviews are where you get to say it honestly.

That one's in German on purpose. A huge share of feature requests arrive in languages that aren't yours, and a reviewer who asks in German and gets a fluent German answer feels like they reached a team, not a translation queue. Replying in the reviewer's own language is one of the highest-return things you can do, and one of the most tedious by hand, which is a theme we'll come back to.

Here's what separates a support task from a product advantage. One feature-request reply makes one user happy. Two hundred of them, read together, tell you what to build next, for free, from the people who care enough to ask. The trouble is that they arrive one at a time, scattered across two stores, buried between bug reports and five-star cheers, and by the time you've replied to each you've lost the pattern. Nobody remembers that dark mode came up forty times last month; they remember the last review they read.

So the real workflow isn't reply-and-forget. It's reply, tag, cluster, and count. When "please add offline" shows up fifty times, that's not fifty support tickets. It's a prioritized roadmap item with fifty pieces of attached evidence and fifty users waiting to hear you shipped it. The teams that win at this treat their review inbox as a product-discovery channel that happens to also require replies, not the other way around.

This is the exact gap [Reply Argus](/features) is built to close. It watches your App Store and Google Play reviews in one inbox and drafts a reply to each feature request in the four-move shape, in the reviewer's own language, grounded in your past approved replies and your knowledge base so it never promises a feature you've already killed or one that already shipped. You approve or edit. Then the requests don't just get answered; they get clustered into a PM roadmap board, so "forty people asked for dark mode" becomes a ranked backlog item you can export straight to Jira, Notion, or a Google Sheet. Reply and product research, same pass. Speed compounds here too: the faster you answer a request, the fresher the goodwill, which is why [how fast you reply](/blog/how-fast-should-you-reply-to-app-reviews) is a lever worth pulling.

The payoff move is going back. When you finally ship the feature forty people asked for, those forty reviews are a ready-made announcement list, the warmest re-engagement you'll ever run. Replying again to say "you asked for this, it's live in 6.0" does what no marketing email can: it proves, in public, that your roadmap is shaped by the people using the app.

This only works if you can find those forty reviews when the build lands, which is exactly why the tag-and-cluster step matters more than any single reply. A great feature-request reply is nice; a system that remembers who asked so you can tell them when it's done is a growth loop. Start with the four moves on your next "please add X" review; the loop is what you build once the pile lives in one place.

Grab your last "please add X" review and rewrite it in the four moves: name the ask, place it honestly, promise only what you'll keep, log it. It takes a minute and it teaches the shape better than any template. When a minute times two hundred requests a month, across two stores, in five languages, with a backlog to track, stops fitting in your week, [start free with Reply Argus](/signup). No card, and it drafts your first reply in minutes and starts clustering your requests into a roadmap you can actually act on.