FeatQ

Feature request email templates

Six copy-ready emails for every stage of a feature request: received, need detail, planned, declined, shipped, and asking users for ideas. Send the declined one too: on the median board in our study of 242 public boards, only 2.8% of requests are declined and 62% have no public decision.

Download feature-request-email.md

1. Request received

Subject: Re: [their subject line]

Hi [Name],

Thanks for asking for [feature]. If I have it right, you want to [their problem, in their words] so you can [the outcome they want].

I've added it to our feature request board: [link]. Other customers can vote on it there, which shows us how many people need the same thing.

I can't promise it yet. I'll email you when we decide, whichever way it goes.

[Your name]

By Max Reid, founder of FeatQ. Numbers from our State of Feature Requests 2026, data collected 1 November 2026.

The six feature request emails

Replace every bracket before you send. Keep the customer's own words for the problem, and cut any line you cannot make true, such as a timing you do not know. Each email is short on purpose: a customer reads it on a phone between other things.

1. Request received

Send within one working day of the request.

Subject: Re: [their subject line]

Hi [Name],

Thanks for asking for [feature]. If I have it right, you want to [their problem, in their words] so you can [the outcome they want].

I've added it to our feature request board: [link]. Other customers can vote on it there, which shows us how many people need the same thing.

I can't promise it yet. I'll email you when we decide, whichever way it goes.

[Your name]

2. Need more detail

Send instead of the first email when you cannot restate the problem yet.

Subject: Re: [their subject line]

Hi [Name],

Thanks for the request. Before I add it to the board, can you tell me a bit more?

1. What were you trying to do when you needed this?
2. What do you do today instead?
3. How often does it come up: daily, weekly, or a few times a year?

A line or two for each is plenty. It helps us build the version you need, not the one we guess at.

[Your name]

3. Planned or in progress

Send when you commit to building it, then again if it slips.

Subject: We're building [feature]

Hi [Name],

You asked for [feature], and we're going to build it. It's marked planned on our board: [link].

What to expect: [rough timing you can stand behind, such as "we're aiming for this quarter, and I'll tell you if that moves", or leave this line out if you don't know]. The first version will [one line on scope, such as "export to CSV; PDF comes later"].

If you have a minute, reply with [the one detail that would help, such as "the columns you need"]. I'll write again when it ships.

[Your name]

4. Declined

Send as soon as you decide the answer is no.

Subject: About your [feature] request

Hi [Name],

Thanks for asking for [feature], and for explaining how you'd use it. I'd rather give you a straight answer than leave it open: we've decided not to build it. [One true reason: who the product is for, what it would cost to keep working, or what it conflicts with.]

What I'd do instead: [a workaround, an export, a setting, or another kind of tool that does this job well].

I've marked the request [declined / not planned] on our board with the same reason, so everyone who voted can see the answer there too. If that changes, I'll update it there.

Thanks for telling us what you need.

[Your name]

Use whatever your board calls it: mark it declined (or not planned, or won't do) and use the same word every time. For the reasoning behind the reply and when a no is the right call, read how to say no to a feature request.

5. Shipped

Send the day the feature is live for this customer.

Subject: You asked for [feature]. It is live.

Hi [Name],

You asked for [feature] in [month] (for voters: You voted for [feature] on our board). It's live now.

To use it: [one or two steps, such as "go to Reports, then Export, and pick CSV"]. More detail here: [link to the release note or help article].

[If you cut scope: "It doesn't do [the part left out] yet. That part is still open on the board: [link]."]

Thanks for asking, and for waiting. If it doesn't work the way you expected, reply and tell me.

[Your name]

Send it to everyone who asked or voted, not only the first person. For the public announcement, start from the release notes template or turn a list of shipped requests into entries with the changelog generator. The median board has shipped only 4 of its 10 most-voted requests (n = 182 boards). When one of yours does ship, tell the people who waited for it.

6. Asking customers for feature requests

Send after a customer reaches a real milestone, not during a support issue.

Subject: One question about [your product]

Hi [Name],

You've been using [your product] for [time], so I'd like to ask one question: what's one thing you wish it did?

Reply with a sentence or two. Or add it to our board, where you can also vote on what other customers have asked for: [link].

I read every reply. We can't build everything, but I'll tell you what happens to yours.

[Your name]

For structured research with rating scales instead of one open question, use the product feedback form template.

Copy the complete feature request email set

All six emails in one block of plain text, with no formatting marks, so it pastes cleanly into Gmail, a help desk macro or a saved reply. The Markdown download holds the same emails with headings, for a team wiki or a docs folder.

All six emails, plain text
1. REQUEST RECEIVED

Subject: Re: [their subject line]

Hi [Name],

Thanks for asking for [feature]. If I have it right, you want to [their problem, in their words] so you can [the outcome they want].

I've added it to our feature request board: [link]. Other customers can vote on it there, which shows us how many people need the same thing.

I can't promise it yet. I'll email you when we decide, whichever way it goes.

[Your name]

----------

2. NEED MORE DETAIL

Subject: Re: [their subject line]

Hi [Name],

Thanks for the request. Before I add it to the board, can you tell me a bit more?

1. What were you trying to do when you needed this?
2. What do you do today instead?
3. How often does it come up: daily, weekly, or a few times a year?

A line or two for each is plenty. It helps us build the version you need, not the one we guess at.

[Your name]

----------

3. PLANNED OR IN PROGRESS

Subject: We're building [feature]

Hi [Name],

You asked for [feature], and we're going to build it. It's marked planned on our board: [link].

What to expect: [rough timing you can stand behind, such as "we're aiming for this quarter, and I'll tell you if that moves", or leave this line out if you don't know]. The first version will [one line on scope, such as "export to CSV; PDF comes later"].

If you have a minute, reply with [the one detail that would help, such as "the columns you need"]. I'll write again when it ships.

[Your name]

----------

4. DECLINED

Subject: About your [feature] request

Hi [Name],

Thanks for asking for [feature], and for explaining how you'd use it. I'd rather give you a straight answer than leave it open: we've decided not to build it. [One true reason: who the product is for, what it would cost to keep working, or what it conflicts with.]

What I'd do instead: [a workaround, an export, a setting, or another kind of tool that does this job well].

I've marked the request [declined / not planned] on our board with the same reason, so everyone who voted can see the answer there too. If that changes, I'll update it there.

Thanks for telling us what you need.

[Your name]

----------

5. SHIPPED

Subject: You asked for [feature]. It is live.

Hi [Name],

You asked for [feature] in [month] (for voters: You voted for [feature] on our board). It's live now.

To use it: [one or two steps, such as "go to Reports, then Export, and pick CSV"]. More detail here: [link to the release note or help article].

[If you cut scope: "It doesn't do [the part left out] yet. That part is still open on the board: [link]."]

Thanks for asking, and for waiting. If it doesn't work the way you expected, reply and tell me.

[Your name]

----------

6. ASKING CUSTOMERS FOR FEATURE REQUESTS

Subject: One question about [your product]

Hi [Name],

You've been using [your product] for [time], so I'd like to ask one question: what's one thing you wish it did?

Reply with a sentence or two. Or add it to our board, where you can also vote on what other customers have asked for: [link].

I read every reply. We can't build everything, but I'll tell you what happens to yours.

[Your name]
Download feature-request-email.md

Subject lines that get opened

Send the first two emails as replies in the customer's own thread, so the subject stays Re: [their subject line] and the history stays attached. The other four start a new email: put the feature name in the subject, so the customer sees in the inbox which request it is about, not a newsletter. The alternative subjects are for when you start a new email anyway.

StageSubjectAlternative
Request receivedRe: [their subject line]Got it: [feature]
Need more detailRe: [their subject line]Three questions about [feature]
Planned or in progressWe're building [feature][feature] is planned
DeclinedAbout your [feature] requestA straight answer on [feature]
ShippedYou asked for [feature]. It is live.[feature] is ready to use
Asking customers for feature requestsOne question about [your product]What should [your product] do next?

Skip "Update on your request" and "Your feedback matters". Neither says which request or what happened, so both read like automated mail.

When to send each email

Received or need detail: within one working day. Send one or the other, not both. If you can restate the problem in a sentence, send the first; if you cannot, ask.

Planned: when you commit, and again if it slips. Shipping takes a while: on the median board in our study, requests that shipped took a median of 165 days from the day they were posted (120 boards with at least 3 dated completions). If a month or two passes after the planned email, send two lines: still coming, and roughly when.

Declined: as soon as you decide. The longer a request sits open, the more the customer reads it as a yes. On the median board, 62% of requests have no public decision (220 boards with exact status counts).

Shipped: the day it is live for that customer, not the day it merges.

Asking for requests: after a milestone, such as a first month of use or a first finished project, and not more than a few times a year per customer.

About the numbers: for our feature request research, we read every public request we could reach on 242 feature request boards on 1 November 2026. They describe what was public that day on the median board, not why teams answer the way they do.

When a board beats one-to-one email

One email answers one person. When five customers ask for the same thing, you either send five emails at every stage or lose track of who asked. A public feedback board keeps one record per request: customers vote instead of writing in again, and a status change answers all of them at once.

Email still wins for the first reply, for the need-detail questions, and for any no that needs care. Use both: reply by email, then point the customer to the request on the board. That is the step that closes the customer feedback loop for everyone who asked, not only the person who wrote in.

FeatQ is our product. On a FeatQ board, changing a request's status, for example to planned, in progress or done, emails every voter who opted in, and done requests appear on the board's changelog. It has no declined status today, and an admin comment shows on the request but does not email anyone, so send the declined email yourself and post the same reason as a comment on the request. The feature request tool page covers how requests move from intake to shipped.

Next steps

Save the six emails as saved replies or macros, one per stage, so nobody writes the declined email from scratch on a bad day. Then look at the one you skip most often. If it is the no, our guide on saying no to feature requests walks through it.

Continue with the release notes template for the public side of a launch, or return to all product team templates. FeatQ payment options are listed on the pricing page.

Frequently asked questions

Practical answers about voting, privacy and pricing.

Reply within a day, restate the problem in the customer's words so they know a person read it, say where the request now lives, and be honest that it is not a promise yet. Then email again when you decide: planned, declined, or shipped.

Thank them, say plainly that you will not build it, give one true reason, and offer the closest thing that works today. Mark the request declined or not planned on your board with the same reason, so anyone who voted can see the answer there.

Yes. Email everyone who asked for or voted on it, name the request they made, and tell them how to use it in one or two steps. It is the email that shows asking was worth it.

Ask one open question at a calm moment, such as after a customer reaches a milestone, not in the middle of a support issue. Ask what they wish the product did, give them a board link where they can vote on existing ideas, and promise only what you will do: read it and tell them what happens.

A subject line with the feature name, the customer's problem restated, the current status, what happens next, and a link to the request. Leave out "we value your feedback": telling them what happened to their request already shows that.

Still have questions? Contact us

Answer every voter, not only the one who emailed

Put shared requests on one board, and voters who opted in get an email when the status changes.

View FeatQ pricing