How to say no to a feature request (and keep the customer)

How do you say no to a feature request politely?

Use four parts in this order: thank them and restate the ask, give the real reason, offer what they can do instead, then set the status and tell them where to watch it.

1. Thank them and restate the request

Restating proves a person read it. "Copying every order into a sheet by hand each Monday sounds like a slog" tells the customer you understood their week. "Thanks for your feedback!" tells them a macro fired. Restate the problem, not only the feature they named: the feature is their guess at a fix, and the problem is where your alternative will come from.

2. Give the specific reason

One sentence, and the true one. "It would take us a month and only a few accounts need it" is a reason. "It's not on our roadmap right now" is not a reason, it is the decision repeated back. Write "we're not going to build this", not "we are unable to prioritize this at this time". Apologize once at most. You are making a product decision, not confessing to something.

3. Offer what works instead

A workaround, an export, a setting they missed, a smaller version you would build, or another kind of tool that does this job well. If nothing exists, say so: "there is no good way to do this in the app today" is more useful than a workaround that falls apart on the first try.

4. Set the status and close the loop

Mark the request declined on your public board, with the same one-line reason, and say in the reply that you did. Now everyone who voted gets the answer you gave the one person who wrote in, and the next person with the same idea finds it before they ask. That last step is what closes the customer feedback loop.

Why do teams rarely say no?

Mostly they say nothing instead: on the median board, 2.8% of requests are declined and 62% have no public decision at all (220 boards with exact status counts).

Those numbers come from our feature request statistics for 2026, where we read every public request we could reach on 242 feature request boards on 1 November 2026. The study also found that 25% of boards have never declined a single request. Not one, on the whole board.

The data cannot say why. The usual reasons are easy to guess, though. A no feels permanent and a maybe feels kind. Nobody owns the board, so nobody owns the answer. An open request costs nothing you can see this week. And the person who asked might be your biggest account, so it feels safer to let it sit.

None of that makes the request go away. It just moves the decision from you to the customer, who has to work it out from the silence.

What does silence cost?

Time, first of all: unresolved requests on the median board have waited 515 days, and 70% of them are more than a year old (181 boards).

A request with no decision is not neutral to the person who posted it. It reads as a maybe, and people plan around maybes. They keep a clumsy workaround in place. They hold off on looking at other tools. They tell their team it is probably coming.

We cannot measure what that wait costs you in cancelled accounts, and nobody we know of publishes that number. What is plain without a study: a clear no on day three lets the customer plan, and a silent maybe on day 515 does not. If your board has requests that old, a short pass that gives each one a decision is the cheapest fix on this page.

When should you say no to a feature request?

Say no when a request fails one of five checks: it fits where the product is going, it helps more than one customer, you can keep it working, it is safe, and it beats what else that time would build.

• It does not fit the product. A scheduling app asked to do invoicing is being asked to become a second product. Say so, and point to a tool that already does that job.
• It helps one customer. One loud account is still one account. If you would not build it for a small customer, a large one asking does not change what it costs you. If they need it badly, quote it as paid custom work or say no.
• You cannot keep it working. Integrations, imports and syncs are cheap to ship and expensive to keep alive. Count the upkeep, not just the first week.
• It is not safe. Requests to skip a permission check, share data across accounts or store something you should not hold get a fast, firm no.
• Something else matters more. This is the one where "not now" is honest. To weigh requests against each other, use a scoring method from our guide on how to prioritize features.

How do you say no to a request with lots of votes?

Say it in public, on the request itself, with the tradeoff spelled out. Votes measure demand, not fit, and a high count is not a promise to build. The median board has shipped only 4 of its 10 most-voted requests (n = 182 boards).

Votes and shipping are only loosely linked. On the median board, 33% of the most-voted tenth of requests have shipped, against 23% of all the others (182 boards). So on the median board, most popular requests have not shipped. The unusual part is saying so out loud.

When you do, write it for the whole crowd, not for one person:

• Name the tradeoff: what building it would cost and what it would push back.
• Say what you are building instead, so voters can see where the time went.
• Say what would change your mind, but only if something really would.
• Leave comments open. People who disagree will say so either way; better on the request than in a review.

Running the board well before you get here helps a lot: our feature voting best practices cover statuses, duplicates and how often to look.

Three short scripts you can copy

One for a clear no, one for not now and one for something that already works. Each is short enough to paste into an email, a chat or a board comment.

Thanks for this, and for explaining how you'd use it. We've decided not to build [feature]. [One true sentence on why: who the product is for, what it would cost to keep working, or what it conflicts with.]

What I'd do instead: [workaround, export, or the closest thing that exists].

I've marked it declined on our board with the same reason, so everyone who voted sees the answer too.

Thanks for the request. It makes sense, but it won't happen in the next few months: we're working on [current focus] first.

I've left it as "considering" on the board rather than "planned", because I don't want to promise a date we can't keep. Vote on it there and you'll see the moment it moves.

Good news: you can do this today, it's just hard to find. Go to [Settings > Section] and [the step]. [Link to a short video or help article.]

If that doesn't cover what you need, reply and tell me what's missing. I'll add it to the request on our board so it counts.

Fill in the brackets and keep the reason true. If you cannot write the reason in one honest sentence, you have not decided yet, and the "not now" script is the right one. The declined script above is one of six; the rest, from the first reply to the shipped email, are in our feature request email templates.

Why say no in public, with a declined status?

A private reply answers one person. A declined status with a one-line reason answers everyone who voted, and everyone who would have posted the same idea next month.

A good declined entry has three things: the status (declined, not planned or won't do: pick one and use it every time), one line on why, and the request left where people can find it. That is the whole job. A public roadmap with plain status columns makes the no as visible as the yes, which is the point.

FeatQ is our product, so one honest note: a FeatQ board has no declined status today. Its statuses are new, considering, planned, in progress and shipped. To say no on a FeatQ board, post the reason as a comment from your admin account and leave the request up. Voters see that comment on the request, but it does not email them. What a FeatQ board does email, to voters who opted in, is every status change, such as planned or shipped: the part of a feature request tool that turns a yes into an answer people actually receive.

Mistakes to avoid when you say no

Most bad noes are not rude. They are vague, late or hidden, and the customer has to decode them.