At a glance
Key takeaways
- Acknowledge every request the same day; the decision can come later, but silence reads as "no" and "we don't care".
- Pick one clear answer: it already exists, tell me more, planned, not now, no, or shipped. Avoid "we'll consider it" unless you really will.
- Record the request with a link to the conversation so you can tell the person when its status changes, which is what makes customers keep asking.
Why the reply matters more than the decision
A feature request is a customer telling you how they use your product and where it lets them down. Whether you build it is a separate question. Whether they ever ask again depends almost entirely on what happens in the next 24 hours.
Two failure modes are common. The first is silence: the request goes into a spreadsheet and the customer never hears back. The second is the polite non-answer, "great idea, we'll add it to the list", which sounds kind but tells the customer nothing and quietly becomes a broken promise.
The fix is a two-step habit. Acknowledge every request quickly, then give one clear answer once you have one.
Step 1: acknowledge the same day
You do not need a decision to reply. You need to show that a person read it and that it went somewhere specific.
Thanks, {name}. I've logged this with a link to our conversation, so it won't get lost.
I don't have an answer yet. I'll get back to you by {day} either way.
Then keep the date. If you cannot decide by then, send one line saying so and give a new date. Customers forgive slow decisions; they do not forgive being forgotten.
Step 2: choose which answer you are giving
Every feature request ends in one of six answers. Decide which one applies before you write anything:
| Situation | Answer | What the reply must include |
|---|---|---|
| You can already do this | It exists | The exact steps or doc link |
| The request is vague or names a solution only | Tell me more | One or two questions about the problem |
| You will build it and it is in the plan | Planned | Where to follow progress; no date unless work started |
| It makes sense, but not in the next few months | Not now | An honest reason and a workaround |
| It does not fit the product | No | A short reason and an alternative if one exists |
| It went live | Shipped | How to use it, and thanks |
If you are unsure between "planned" and "not now", choose "not now". Moving something up later is a pleasant surprise; moving it down is a broken promise. When several requests compete, a quick score with the RICE calculator makes the call easier to explain.
Seven reply templates
Short beats thorough. Each of these fits in a chat window or a three-line email. Replace the braces and adjust the tone to match how you normally write.
1. The same-day acknowledgement
Use the snippet in step 1. Send it from a person, not a no-reply address.
2. Tell me more
Thanks for this. Before we decide, can you tell me what you were trying to do when you needed it, and how you're handling it today?
Asking about the task, not the feature, often reveals a simpler fix. The feedback question generator has more wording for this.
3. It already exists
Good news: you can do this today. Go to {place} and {steps}. Here's the guide: {link}.
If it doesn't cover what you need, tell me what's missing.
When you send this reply often, it is a discoverability problem. Fix the UI, not just the reply.
4. Planned
This is planned. You can follow it and vote here: {roadmap link}.
I can't promise a date yet, but you'll get an email when work starts and again when it ships.
5. Not now
Thanks for raising this. It's a reasonable request, but it won't make it into the next few months because {reason}.
In the meantime, {workaround}. I've recorded your request, and I'll let you know if that changes.
6. No
I want to be straight with you: we're not going to build this. We're focused on {who the product is for}, and this would take us in a different direction.
If you need it, {alternative} does it well. Thanks for telling us, and please keep the feedback coming.
A clear no with a reason keeps the relationship. Recommending another tool when it fits builds more trust than any feature.
7. Shipped
You asked for {feature} back in {month}. It's live today: {link}.
Thanks for the push. If it doesn't solve the problem you described, reply and tell me.
This is the message that turns a customer into someone who sends better feedback. The public roadmap template has longer versions for each status change.
Hard cases
A paying customer says they will leave without it. Ask what happens on the day they leave: what would they switch to, and does that tool really do this? Often the request is a proxy for a smaller pain you can fix now. If it is truly a deal-breaker and does not fit the product, say no early, before the renewal, and help them leave cleanly. They may come back.
A prospect asks during a sales call. Do not sell a roadmap. Say what the product does today, ask how they handle the gap now, and log the request with the deal attached. If you would not build it for an existing customer, do not build it to close one deal.
The request is public, on social media, a community forum, or your roadmap. Reply in public with the short answer and move details to a private channel if account information is involved. Others are reading, and the reply is as much for them as for the person who asked.
Phrases that cause trouble later
- "We'll consider it." Only say it if you will, with a date.
- "It's on the list." Which list, and what happens next?
- "Soon." Nobody shares your definition of soon.
- "Great idea!" It reads as a yes. Thank them for the request, not the idea.
- "Lots of people have asked for this." Then they will ask why it isn't built.
Keep a record so you can follow up
Replies only work if you can find the request again when its status changes. For each one, keep the customer's words, a link to the conversation, the answer you gave, and the current status. When three different customers describe the same problem, merge them into one request and reply to all of them together.
A feedback tool does this bookkeeping for you. In TellTide, feature requests from the widget or API land in one inbox with the person's email attached. You can publish a request to the public roadmap, and the submitter gets an email each time its status changes or you reply. That way "you'll get an email when it ships" is a promise you keep without remembering it.
For the wider process of grouping, prioritizing, and deciding, read how to manage feature requests.
Keep every promise you make in a reply: Get TellTide Pro. Requests land in one inbox, and users get an email when their request moves or ships.
Questions teams ask before choosing this workflow
Should I reply to every feature request?
Yes, at least with a short acknowledgement. Early on, a fast personal reply is one of the few things a small company does better than a large one, and people who get a reply keep giving feedback.
How do I say no to a feature request without losing the customer?
Say it early and plainly, give a one-line reason tied to who the product is for, and offer a workaround or alternative if one exists. Customers rarely leave over a polite no; they leave over months of false hope.
Should I give a timeline when I say yes?
Only for work that has started. For everything else, say it is planned and promise to tell them when work begins. A missed date damages trust more than no date.
What if a large customer demands a feature?
Find the problem behind the demand first. Often a smaller change or a workaround solves it. If the request does not fit the product, say so early, before it becomes part of a renewal negotiation.
Abhijith
Founder of TellTide, writing practical guides about product feedback, feature requests, and public roadmap workflows for SaaS teams.
