How to respond to feature requests (with templates)

A customer who sends a feature request has done you a favor: they told you what would make them pay longer. The minimum repayment is an answer. Not "thanks for the feedback!" — an actual answer about what happens next.

The good news is there are only five possible answers, so you only need five templates. The structure below covers them, plus the two habits that matter more than the wording: respond in the channel they used, and follow up when the status changes.

First, the rules that apply to every response

Reply where they asked. If the request came in a Slack channel, answer in the thread. If it came through support, answer in the ticket. Intercom's support team makes the same point: use the channel the customer chose, not the one that's convenient for you (Nicereply).

Restate the request in your words. One sentence. It proves you read it, and it surfaces misunderstandings before they get built.

Never fake a maybe. "We'll keep it in mind" as a synonym for no corrodes trust faster than a clean no does. If the answer is no, use the no template.

Log it before you reply. Every request goes into your feature request tracking with the requester attached — the reply is only half the job, and the follow-up (template five) is impossible if you didn't record who asked.

Template 1: it already exists

The happiest case, and more common than you'd think.

Thanks for this — good news: you can already do this.
[One or two steps, or a link to the doc.]
 
If that doesn't cover what you had in mind, tell me what's
missing and I'll log it properly.

Resist any tone of "you didn't read the docs." The docs failed them, and their request just told you where.

Template 2: it's coming

Thanks for asking about this — it's in progress. We're
building [restate the feature] and it's currently
scheduled for [quarter / release / "the next couple of
months"].
 
I've added you to the list for this, so you'll hear from
me when it ships.

Only give a date you'll hit. "This half" beats a specific week you'll miss.

Template 3: maybe — it's a real candidate

The honest middle. The mistake is dressing it up as a yes.

Thanks — this is a real candidate and you're not the
first to ask. Honestly: it's not committed yet. We
prioritize by how many customers hit a problem and how
hard it bites, and I've logged your request so it counts
toward that.
 
Can I ask what you're doing today instead? That detail
usually moves things up the list.

That closing question is not filler — the workaround a customer describes is the best severity signal you can collect.

Template 4: no

Covered at length in our guide on how to say no to a feature request; the short form:

Thanks for laying this out. Straight answer: we're not
going to build this. [One honest reason — direction,
focus, maintenance cost.]
 
[If one exists:] The closest thing that works today is
[workaround / other tool].
 
I've still logged it — if enough customers push in this
direction, we do revisit.

Template 5: the follow-up when it ships

The template almost nobody sends, and the one that builds the most goodwill per sentence:

You asked us [when] for [feature]. It shipped today —
here's the doc: [link].
 
Thanks for pushing us on this one.

This message requires knowing who asked, which is why logging with the requester attached is a rule and not a nicety. Disclosure: we build Modem, and this follow-up is the specific thing it automates — requests are captured from Slack, Discord, support, and email with the requester attached, and when the PR that resolves a topic merges, Modem matches it back and drafts exactly this message for everyone who asked. That works because requesters stay attached to the topic in the context graph, so "everyone who asked" is a lookup rather than a search through months of closed conversations. If your volume is low enough to do it by hand, do it by hand; the message matters, not the tooling.

Personalize the skeleton, not the whole message

Templates get a bad name because teams paste them verbatim. The fix is cheap: the skeleton stays, and you personalize two things — the restatement of their request, and one detail from their context ("since you're piping this into your compliance reports..."). Support-team guidance lands in the same place: templates ensure completeness, personalization stops them sounding scripted (Savio).

The smallest version to start this week

Put the five templates in your support tool's snippet library or a shared doc. Then take this week's requests and make sure each one gets three things: a logged entry with the requester's name, a reply from the right template, and — for anything that ships — template five. If you only adopt one habit, adopt template five.