How to say no to a feature request

Say no with the real reason

A no works when the customer can see why. "We are not building that right now" sounds like a brush-off. "We are not building a bulk delete yet because deleting feedback removes the trail our team uses to spot repeats" sounds like a decision someone made on purpose.

Start with the reason, then the decision. Most people accept a no they understand, even when they wanted the yes. What they do not accept is a vague answer that leaves them guessing whether anyone read the request.

Why a clear no is kinder than a vague maybe

A vague maybe feels polite in the moment. It costs more later. The customer waits, checks back, asks again and eventually concludes that you ignore them. A clear no closes the loop in one message. The customer knows where they stand and can plan around it.

This does not mean every no has to be blunt. Warm wording helps. Clear wording matters more.

Offer a workaround only if you would support it

A workaround is useful when it solves most of the problem and you are willing to explain it again next month. Do not offer a hack you would hate to support. If the customer follows a workaround and it breaks, the no becomes a second disappointment.

Ask yourself one question before you offer one: would I be comfortable if this workaround became the official answer for everyone who asks? If the answer is no, skip it and say what you can do instead, even if that is just the reason.

Write the reply in four parts

Keep a no to four short parts. You can use this as a template:

Hi Ana, thanks for asking about a bulk delete for old feedback. We are not going to build it now. Deleting items would remove the history our team uses to spot repeats, and that matters more to most customers than a clean list. If you need to hide old items, closing them with a note keeps them out of the way while the record stays. We have noted your request, and if the situation changes for us, I will tell you.

The four parts are: the thanks, the decision, the reason, and what the customer can do now. The last sentence is optional but useful, because it tells the customer their request had weight.

Record the decision where the team can find it

A decision that lives only in your head comes back. Someone reads the same request next month, has no context and starts the debate again. Record the decision on the item with a note: what you decided, the date and the reason. If the request came from several people, note that too.

Then set the status. Use closed for a decision not to act. Use planned if you said yes. The status and the note together answer the question "what happened to this?" for anyone on the team.

When no should become not yet

Some requests are not wrong, just early. A no for now can be a not yet, but only if you can say what would change your mind. Write that condition in the note: "revisit when more than one team uses the API for exports." Then, when the condition is met, you have a reason to reopen the item instead of a vague hope.

Review these notes during your weekly triage. A not yet with no condition is really a no, and it should be closed as one.

Keeping the customer after a no

Customers who hear no often stay, if the no was honest and they felt heard. Two things help. First, acknowledge the cost to them, not only the reason for you. "I know this would save you time" tells them you understood their situation. Second, thank them for the specific idea, not for "the feedback". Specific thanks shows you read the request.

If the customer is angry, do not argue the decision in the same thread. Reply once with the facts and let the answer stand. Repeated defenses turn a closed item into a fight.

Handle the customer who will not accept no

Some customers push back, and a few push hard. Listen once more, then check whether they gave you new information. A new fact, such as a second team that needs the feature, is a reason to look again. A repeat of the same argument is not. Say that kindly: "I understand this matters for your team. I have not changed my decision, and I do not want to keep you waiting for a yes that will not come." Then stop replying to the same point. A calm, final answer helps more than a longer debate, and it protects the time your team needs for planned work.

Saying no in Escuta Produto

Open the item in the product inbox. Read the full message and the metadata, so you know the customer's plan and context before you decide. If the item came from several people, search for the same words to find the others. Escuta Produto has no merge feature, so use search and a short note that lists the other items.

Write the reply from your own email, to the address saved on the item. Then add an internal note with the decision, the reason and the date. Set the status to closed or planned. The widget docs explain how the email reaches the item in the first place.

For the rest of the weekly routine, including how to group repeats before deciding, see how to triage customer feedback. For the wording of the reply itself, how to reply to customer feedback has more templates.