---
title: "Feature Request That Will Not Be Built: What to Tell Customers"
description: "A feature request that will not be built needs a closed no inside 30 days: decision, reason, alternative and reopen condition. Four steps and one script."
topic: "Playbooks & Operations"
author: "Raj Bheda, Co-founder, GainTrace"
audience: "Customer Success Manager"
published: 2026-09-18
modified: 2026-09-18
source: https://gaintrace.com/explore/playbooks/feature-request-that-will-not-be-built
---

# What Do I Tell a Customer About a Feature Request That Will Not Be Built?

*When product says no and the customer is still waiting*

**Short answer:** A feature request that will not be built gets a closed no within 30 days of the decision: the decision in one sentence, the reason in the customer's terms, the alternative that exists today, and the one condition that would reopen it. Send it yourself, in writing, where they asked. Of 79 Reddit threads about feature requests, none describes the no; the complaints describe the silence that replaced it.

**Key takeaways**

- A no that closes a feature request has four parts: the decision, the reason in the customer's terms, the alternative that exists today, and the one condition that would reopen it. Send it in writing within 30 days of the decision.
- Three ways of saying no are a no in name only. The soft no leaves the request open, the stale no answers by neglect, and the borrowed no hands the customer a messenger. All three surface again at renewal.
- Silence after a feature request is worse than a no. Practitioners in our corpus name the customer who stopped asking as the earliest churn signal they trust, and a closed no keeps the account asking.
- Give any reason except cost. Too few customers, product direction, bespoke scope and impossible inputs are all reasons a customer can plan around; cost is a price they will offer to pay.
- Measure decision latency and the post-no ask rate. No public benchmark exists for either, so compare your accounts to their own last quarter.

A feature request that will not be built is the one conversation on your calendar this week with no script: product has decided, the ticket is closed on their side, and the customer who asked in March is still expecting an answer from you. Most CSMs handle it by not handling it. The request stays open in the customer's mind, the CSM stops mentioning it, and the two of you reach the renewal call with different memories of what was said.
This page is for the CSM who has been handed a no and has to carry it. It gives the four parts of a no that closes the question, the four ways a no goes wrong, the four alternatives worth offering, and two numbers that show whether the customer heard you or quietly stopped asking.

## What should I say about a feature request that will not be built?

Say the decision, the reason, the alternative and the condition that would reopen it, in writing, in the thread where the customer asked, within 30 days of product deciding. Four sentences do it. The decision comes first and is not softened: "We are not going to build this." The reason is the real one, in the customer's terms. The alternative is what they can do this month. The reopen condition is the one thing that would change the answer, so the customer knows the no is a decision and not a mood.

> **The closed no:** A closed no is a feature request answer with all four parts: the decision in one sentence, the reason in the customer's own terms, the alternative that exists today, and the single condition that would reopen it. A request that has not received a closed no is still open in the customer's mind, whatever the tracker says, and an open request is a promise the customer wrote down and you did not.

The corpus has almost nothing on this conversation, which is itself the finding. Of 4,978 public G2 reviews of five customer success platforms, 23 mention a feature request (0.5%), and 11 of those 23 sit in the reviewer's dislikes field. Of 33,600 Reddit posts from four CS and SaaS communities between May 2024 and September 2026, 79 mention a feature request and not one describes telling a customer that theirs will not be built. The threads are about logging requests, routing them to product, and what happens to them afterwards, which is usually nothing.

> "It's a feature request and we cross our fingers for this in the future"
>
> — Customer Success Manager, small-business SaaS, public G2 review

That reviewer gave the product 4.5 stars in 2018 and was still waiting. The request is not the complaint in the review; the waiting is. A customer with a closed no can plan. A customer with crossed fingers checks each release note for a year and reads the absence as an answer about them.

> "So it becomes a feature request. Maybe it gets logged. Maybe the CSM says "great feedback." Maybe product argues about it next quarter. Maybe it turns into a Zapier workaround. Maybe it dies in the backlog forever."
>
> — r/startups, 2026

## Which four ways of saying no to a feature request cause the damage?

Four ways of delivering a no decide the outcome, and three of them are a no in name only: the soft no, the stale no, the borrowed no and the closed no. The first three leave the request open, and the customer keeps a record of it that you do not. The table names each one by the sentence that starts it.

| The no | What gets said | What the customer hears | What it costs |
| --- | --- | --- | --- |
| The soft no | "I'll pass that on to product." Then nothing. | A yes with a delay. The customer assumes the request entered a queue and checks each release for it. | The request stays open for the life of the account and surfaces at renewal as a thing you promised. |
| The stale no | The ticket sits for a quarter, then: "engineering declined it." | That nobody looked at it for three months and the answer was chosen by neglect. | The customer learns that asking is pointless and stops asking, which is the quiet before churn. |
| The borrowed no | "Product decided not to build it." No reason given, CSM as messenger. | That their CSM has no influence and no information, so the next escalation goes over your head. | You lose the relationship's authority. Later decisions get argued with someone else. |
| The closed no | Decision, reason in their terms, alternative, reopen condition, in writing, inside 30 days. | A decision made by people who understood the ask. | One uncomfortable message now, and a customer who keeps asking you for things afterwards. |

> "Do I push back, try to reframe the expectations? Or just open the ticket, let it collect dust for a few months, and then tell the customer the engineering team declined it?"
>
> — r/CustomerSuccess, 2026

That is a senior CSM at a SaaS company in 2026 describing the stale no as a live option, in a thread where the boss's instruction was to say yes to everything because the account is large. The stale no feels kind on the day. It costs the most later, because the customer discovers the decision by inference and dates it to the day they asked.

> "Positive comments are added to our presentations, but criticism is not properly addressed. Feature requests only get attention when they match the roadmap."
>
> — r/SaaS, 2026

## Why does silence after a feature request hurt more than a no?

Silence after a feature request teaches the customer to stop asking, and a customer who stops asking is the earliest churn signal practitioners in our corpus say they trust. The request itself is engagement: someone on the account cared enough about an outcome to tell you what was missing. A no keeps that person talking to you. Silence ends the conversation, and in the threads below the decision to leave was made in the quiet that followed.

> "Used to ping us weekly with feature requests and questions. Then nothing for 3 months. I assumed: "They figured it out, things are running smoothly." Reality: They stopped asking us because they were already testing competitors."
>
> — r/CustomerSuccess, 2025

> "The thing that actually moved earliest, every time, was how much the customer asked me for. When a healthy account goes quiet, no more "can you help us with X," no more small feature questions, no more looping me into their planning, that silence showed up weeks before anything in the dashboard did."
>
> — r/CustomerSuccess, 2026

Both writers reached the same conclusion from different seats: the volume of asks per account is a health input nobody counts. A closed no keeps the volume up, because the customer learns that asking produces an answer. The soft no and the stale no push it down, one unanswered request at a time. [My customer went quiet](https://gaintrace.com/explore/retention/customer-went-quiet-reengagement-playbook) covers what to do once the silence has started; this page is about not causing it.

The same expectation runs inside the company. A senior CSM at a 14-person startup in 2024 wrote that the CS team did not expect a fix, or even for the request to be built at all; what they wanted from product was a dialogue that did not go dead. Customers want the same thing from you. The no is tolerable. The dead line is not.

> "while we don't expect an immediate fix or for a feature request to be incorporate at all in many situations, we can't seem to sustain an open dialogue, and that's really what I'd like to do."
>
> — r/CustomerSuccess, 2024

## How do I deliver a feature request no in four steps?

Deliver the no in four steps, in order: get the decision and the reason from product in writing, translate the feature back into the outcome the customer wanted, send the closed no, and log the reopen condition where the next review will find it. The steps take an hour for a normal request and a day for a large account, and skipping any one of them brings back one of the four failures above.

1. **Get the decision and the reason from product, in two lines.** "Not building. Reason: it only serves accounts below 20 seats and conflicts with the permissions redesign." If product cannot give you a reason you would be comfortable saying out loud, the decision is not finished and you should not carry it yet. A no you cannot explain is a borrowed no.
2. **Translate the feature back into the outcome.** The customer asked for a button. What they wanted was a report by Friday without exporting to a spreadsheet. Ask them, if you did not at the time. The outcome is where the alternative lives, and it is how you find out whether the no matters to their renewal or to one person's afternoon.
3. **Send the closed no inside 30 days.** Decision, reason, alternative, reopen condition. In the thread where they asked, from you, not from a product update. Then say it again on the next call so it is heard twice, once in writing and once in person.
4. **Log it against the account, with the reopen condition.** One line in the account record: the request, the date, the no, the condition. If the condition is ever met, you are the person who tells them. If it is not, the renewal prep shows the no was delivered and dated, so a year later nobody is reconstructing the conversation from memory.

> **The message, written out:** "Hi Dana. On the bulk approval rule you asked for in March: we are not going to build it. The honest reason is that it would only apply to accounts running the legacy approval flow, which we are retiring in Q1, so we would be building something we then remove. What you can do this month is the scheduled export plus the approval filter, which gets the Friday report out without the spreadsheet step; I can set it up with your admin on Thursday. The one thing that would reopen this is the retirement slipping past Q2, and if that happens I will tell you the same week. Sorry it is not the answer you wanted." The names and details are illustrative; the four parts are the point.

> "A feature request is not a requirement ... It is a clue. I want to know what the person was trying to do, what stopped them and what they did instead."
>
> — r/CustomerSuccess, 2026

That is a product manager with ten years in the job, and the sentence is the whole of step two. The CSM who translates the request into the attempt, the block and the workaround before delivering the no can usually offer something, because the outcome has more than one route. The CSM who carries the feature name alone can only say no to it. If the customer believes the feature was promised to them, this stops being a feature request conversation: [what to do when a customer says a feature was promised](https://gaintrace.com/explore/onboarding/customer-says-a-feature-was-promised) handles that case.

## Which reasons for not building a feature request are safe to tell the customer?

Four reasons are safe to give a customer and one is not: too few accounts need it, it conflicts with where the product is going, it is bespoke work that belongs in a services scope, and it cannot be done with the data or inputs they have. The unsafe reason is cost, because a customer who hears "too expensive" hears a price and starts negotiating.

| Reason | Say this | Not this |
| --- | --- | --- |
| Too few customers need it | "It serves a handful of accounts and we prioritise by how many customers a change helps." Reviewers in our corpus accept this one when it is said plainly. | "Nobody else has asked for it." It invites a campaign, and the customer will go and find the others. |
| Conflicts with the product's direction | "It would build on a part of the product we are replacing" or "it cuts across the way permissions are going." Name the direction; the tier language is on [communicate the roadmap to customers](/explore/playbooks/communicate-the-roadmap-to-customers). | "It is not our vision." Direction without a concrete example sounds like taste. |
| Bespoke to their process | "This is specific to how your team works, which makes it a services scope, and I can get it costed." The no becomes a priced yes they can decline. | "We could build it for you." A free bespoke promise with no scope is the most expensive sentence a CSM can say. |
| Not possible with their inputs | "With the data in these formats it cannot be automated past about 80%. Here is the fastest way to handle the rest." A stated ceiling is a decision the customer can plan around. | "We will keep improving it." Each improvement is then measured against 100% and fails. |
| Cost | Do not give cost as the reason. Give the reason above it that is also true, and one usually exists. | "It is too expensive to build." The customer offers to pay, and now you are negotiating a feature instead of closing a request. |

> "Sometimes I would appreciate more granular permission settings but [the platform] always listens to their customers and considers feature requests if it makes sense for the majority of their customers."
>
> — Mid-Market reviewer, public G2 review

That is a five-star review from 2023 that contains an open, unbuilt request. The reviewer was told the rule, understood it, and scored the vendor on the rule instead of the request. Two founders in our Reddit corpus describe the other side of the same rule, and why the bespoke yes is the expensive one.

> "But 2 hours of development isn't really 2 hours. It's 2 hours today. Then maintenance. Then edge cases. Then support. Then documentation. Then onboarding."
>
> — r/SaaS, 2026

> "Custom work is capital that gets consumed by one buyer once. The same hours put into the core product get invested for every customer you have and every one you haven't met yet."
>
> — r/SaaS, 2026

## What can I offer instead of the feature request that will not be built?

Offer one of four things with the no, in this order of preference: a route to the same outcome inside the product today, a configuration they have not used, an integration or export that closes the gap, or a priced services scope. Offer one, with its cost on their side stated, and not the whole list. The alternative is what turns a no into a plan, and the corpus shows customers tolerate a workaround far better than they tolerate waiting.

Workarounds are the most common way a customer lives with a no. 62 of the 4,978 G2 reviews mention one (1.2%), and 59 of those 65 sentences sit in the dislikes field, which sounds bad until you read them: most describe a tolerable state of affairs the reviewer has accepted, often with the CSM's help.

> "My fantastic CSM will always try and find a workaround for our problem and if there isn't one she will ensure we have a conversation with their product team to get a solution on the roadmap."
>
> — Mid-Market reviewer, public G2 review

> "There are often times workarounds, but they can be a bit tedious."
>
> — CS Operations, mid-market SaaS, public G2 review

| Alternative | Fits when | The sentence |
| --- | --- | --- |
| A route to the outcome that exists today | The outcome is reachable with more steps or a different screen, and the customer did not find it | "You can get the Friday report with the scheduled export plus this filter. Twenty minutes with your admin and it runs itself." |
| Configuration they have not adopted | The product has a customisation layer they declined to learn, as in the 2026 thread where the account wanted UI changes and had ignored the custom dashboard builder | "The dashboard builder does most of this. I will build the first one with you so it is not homework." |
| An integration, export or automation | The gap is between your product and another tool, and a connector or a scheduled export closes it | "A weekly export into your warehouse gives you the join you want, and this is what running it costs." |
| A priced services scope | The ask is bespoke to their process and worth real money to them | "This is a services scope. I can have it costed by Friday, and you can say no to the number." |

Two things are missing from the table on purpose. "We will keep it on the list" is the soft no with a tracker attached. And a discount belongs in the [renewal](https://gaintrace.com/blog/saas-renewal-management) conversation with the gap named, not attached to a request; a concession given for a feature teaches the customer that requests are a pricing lever. The customer in the 2026 customisation thread had a whole dashboard builder available and had not opened it, which is the most common alternative of all: the thing they asked for exists in a shape they have not tried. To size the ARR sitting behind the open requests on your accounts, the [cost of churn calculator](https://gaintrace.com/tools/cost-of-churn-calculator) will do it.

## How do I know whether the customer accepted the no?

Two numbers tell you whether a no landed: decision latency, the days between the request being logged and the customer receiving a closed no, and the post-no ask rate, how much the account keeps asking you for in the 90 days after. No trustworthy public benchmark exists for either, or for how many customer feature requests get built; the percentages on vendor blogs come with no sample, no dates and no definition of a request, so measure your own and compare it to your own last quarter.

**Decision latency**

```
Decision latency = Date the customer received the closed no − Date the request was logged
```

Where:
- Closed no: the four-part message, not the internal decision date; a decision the customer has not heard is still open for them
- Logged: the day the request entered your tracker, not the day product first read it
- What good looks like: under 30 days on our own working threshold. Past 90 days the customer has usually stopped asking, and the answer arrives as confirmation of a suspicion

**Post-no ask rate**

```
Post-no ask rate = Requests and questions from the account in the 90 days after the no ÷ Requests and questions in the 90 days before × 100
```

Where:
- Requests and questions: anything the account asked you for: feature asks, how-do-I questions, calls they requested. Count them from the inbox and the shared channel, not from the tracker
- What good looks like: above 70%. A rate near zero means the no landed as "they do not listen", and the account needs a call with something useful in hand, not a check-in

> **Worked example:** A 48-account portfolio logged 37 feature requests in a quarter. Product reached a decision on 14 of them; 23 were still open past 30 days with no decision either way (62%). Of the 9 that were declined, 6 reached the customer as a closed no inside 30 days, and the median decision latency across the 9 was 22 days. Two accounts told the CSM how the no had landed without saying a word: one had asked for 5 things in the 90 days before its no and 4 in the 90 days after, a post-no ask rate of 80%; the other went from 6 asks to none, a rate of 0%, and was moved to the risk list before its health score changed. These figures are illustrative; run both on your own accounts.

**Before you send a no to any customer**
- [ ] You have the decision and the reason from product in writing, and you would say the reason out loud.
- [ ] You know the outcome the customer wanted, in their words, not the feature name.
- [ ] The message has all four parts: decision, reason, alternative, reopen condition.
- [ ] It goes in the thread where they asked, from you, within 30 days of the decision.
- [ ] The alternative has its cost on their side stated.
- [ ] The reopen condition is specific enough that you would recognise it happening.
- [ ] The request, the no and the condition are logged against the account.
- [ ] You have a reason to talk to this account again within 30 days that is not this request.
- [ ] If sales or support told this customer something different, you reconciled it before sending.

The last item is the one that fails most often. A request that sales called "on the roadmap" during the deal is not a feature request any more; it is a commitment, and the no has to be delivered as a correction of that commitment, with the salesperson aware. [How to stop sales from overpromising to customers](https://gaintrace.com/explore/onboarding/stop-sales-from-overpromising-to-customers) is the fix upstream. The intake and ranking that produce the decision in the first place are on [getting customer feedback to product](https://gaintrace.com/explore/playbooks/customer-feedback-to-product-from-cs-sales-support); this page starts where that one ends, with a decision made and a customer waiting.

## How does GainTrace keep the feature request no next to the account?

GainTrace reads the calls, emails and tickets on an account and keeps what was asked, what was answered and what was left open attached to that account, so the request from March and the no from May are both there when the renewal opens. [Health signals](https://gaintrace.com/platform/customer-health) track how much each account asks for against its own baseline, which is the post-no ask rate above running on its own, and the drop shows up as a signal before it shows up as churn. [Playbooks](https://gaintrace.com/platform/playbooks) put the closed-no follow-up on the CSM's list at 30 days, so the reopen condition is checked instead of remembered.

## Frequently asked questions

### What do I say when product declines my customer's feature request?

Send a closed no within 30 days: the decision in one sentence, the real reason in the customer's terms, the alternative they can use this month, and the one condition that would reopen it. Put it in writing in the thread where they asked, from you, and say it again on the next call. Then log the request, the no and the reopen condition against the account so the renewal prep shows it was delivered and dated.

### Should I tell the customer the real reason a feature is not being built?

Yes, with one exception. Too few customers need it, it conflicts with the product's direction, it is bespoke to their process, or it cannot be done with their inputs are all reasons a customer can plan around. Do not give cost. A customer who hears "too expensive" hears a price, offers to pay it, and turns a closed request into a negotiation. A truer reason above cost usually exists; give that one.

### How long should a customer wait for an answer on a feature request?

Thirty days from product's decision to the customer hearing it, on our own working threshold, and the customer should hear a status inside 30 days of asking even when there is no decision yet: logged, not committed, next update on a date. Past 90 days the customer has usually stopped asking, which in our corpus is the earliest churn signal practitioners say they trust, and the eventual no lands as confirmation rather than news.

### What if the customer threatens to churn over a declined feature request?

Go back to the outcome, not the feature. Ask what the missing feature costs them per month in time or money, then put the best alternative against that number: a route that exists today, unused configuration, an integration, or a priced services scope. Offer a conversation with the product manager so they can argue the decision with the person who made it. Do not reopen the decision under pressure, and do not attach a discount to a request; if the account is worth a concession, that belongs in the renewal conversation with the gap named. If they say the feature was promised during the sale, treat it as a commitment, not a request.

### Is a customer who stops sending feature requests a churn risk?

Often, yes. Two practitioners in our Reddit corpus, writing in 2025 and 2026, describe the account that used to ask weekly and went quiet as the churn they missed; one lost a customer who had been testing four competitors for ten weeks in the silence. Count asks per account per month from the inbox and shared channels and watch the change against that account's own baseline. Silence from an account that was always quiet is different from silence from one that used to talk to you every week.

### Can I build a declined feature for one customer as a paid customisation?

Only as a scoped, priced services project with its own maintenance owner, and only if the account is above your ACV line. A free bespoke build is the most expensive no a CSM can give: a founder in our corpus describes five months of a roadmap belonging to one contract that then ended anyway. Price it, scope it, and let the customer decline the number. Do not build it quietly to placate an account; that teaches every large customer that pressure works.

## How this was researched

We searched a corpus of 4,978 public G2 reviews of five customer success platforms, 29,027 sentences, for feature request language: 23 reviews mention a feature request (0.5%), 11 of them in the dislikes field, and 62 mention a workaround (1.2%), with 59 of those 65 sentences in the dislikes field. We then searched 33,600 posts from r/CustomerSuccess, r/SaaS, r/sales and r/startups published between May 2024 and September 2026: 79 mention a feature request (0.2%), 49 of them in r/CustomerSuccess, and a search for refusal phrasings ("will not be built", "won't build", "declined the request") found two unrelated matches, so no thread in the corpus describes telling a customer no. We read the threads where CSMs, product managers and founders describe requests, silence and the cost of bespoke work in their own words. The closed no, the four ways a no goes wrong, the five reasons, both formulas and the thresholds inside them are our own; the worked example uses illustrative figures.

## Sources

- [r/CustomerSuccess: Customer wants more customization then we offer](https://reddit.com/r/CustomerSuccess/comments/1rixkpp/)
- [r/CustomerSuccess: Customer went silent for 90 days. I thought they were just busy. They were shopping for replacements.](https://reddit.com/r/CustomerSuccess/comments/1nzh8n7/)
- [r/CustomerSuccess: The earliest churn signal I trust isn't usage dropping, it's the customer going quiet](https://reddit.com/r/CustomerSuccess/comments/1vddre0/)
- [r/CustomerSuccess: I've worked in product for 10 years. I got better when I stopped doing most of what makes a PM look busy.](https://reddit.com/r/CustomerSuccess/comments/1vn6j4o/)
- [r/SaaS: We were so good at building features that we forgot to ask if we should build them](https://reddit.com/r/SaaS/comments/1vyafb1/)
- [r/startups: AI helped us turn every customer workflow into a product feature](https://reddit.com/r/startups/comments/1tgedxg/)

## Next steps

Pick the oldest open request on your accounts this week and send it a closed no, or a dated status. [Start free](https://app.gaintrace.com/auth/login) or [book a demo](https://gaintrace.com/booking).