# What to do with rejected feature requests

> Close a rejected feature request with the reason in plain words, set the status to closed, and record the decision in a private note. Keep a simple decision log so your team can find old decisions, and set a specific condition for when the request should come back for review.

Source: https://escutaproduto.com/resources/rejected-feature-requests
Last updated: 2026-10-11

## Why closed requests still need an owner

A rejected feature request is still a product decision, and product decisions get forgotten. Six months later, a new teammate reads the same request, sees that it is closed, and has no idea whether it was rejected because it was wrong, because the timing was bad or because nobody wrote anything down. They ask again, or worse, they build it without knowing the history.

Closing a request is a small piece of work with a long payoff. You make the decision visible, you explain it to the people who asked, and you leave a trail that someone else can follow. Treat closed as a state that needs care, not as the place where items go to disappear.

## Write the close message with a reason

When you close a request, the customer should hear the reason, not only the outcome. A reason tells them the request was read and weighed, and it gives them something to disagree with if they have new information. "We have closed this" with no reason reads like a dismissal even when the decision was careful.

Keep the reason to one or two sentences. Name the real cause, such as the cost to maintain it, the fact that it conflicts with a rule you hold to, or the fact that only one customer needs it. Do not invent a justification you do not believe, because the customer will find out.

Here is a template you can adapt:

> Hi Marco, thank you for asking for a dark theme for the inbox. We have closed the request for now. A second theme would mean maintaining two sets of colors and testing every screen twice. That is more than we can take on today. If you have a setting that is hard to read, tell me which one and I will look at the contrast on that element.

The reply names the reason, leaves a door open for a specific problem, and does not promise a theme that does not exist.

## Set the status and leave a decision trail

Set the status to closed. The status tells everyone who opens the item that the decision is made. Then add an internal note with the decision, the date and the reason in one short paragraph. A good note reads like a message to a teammate who was not in the room: what was decided, why, and who was told.

Keep the note factual. Write "Declined for now, the cost of a second theme is higher than the number of people who asked" rather than "Nobody wants this". Notes are private, so they are the right place for candid reasoning, but candid does not mean dismissive.

## Make the old decisions findable

This is where many small teams get stuck. The inbox search looks at the message text, the name and the email on each item. It does not search the internal notes. That means a search for the word "theme" finds the customers who wrote about a theme, but it will not find a note that says "declined, cost of second theme". If you rely on search alone, the reasoning disappears.

Two habits fix this. First, use the message text to your advantage: the customer's words are searchable, so a closed item still shows up when someone searches for the request. Second, keep a short decision log in a spreadsheet or a doc, with one row per decision: the item's link, a plain title, the decision, the date and the condition for revisiting. A spreadsheet is searchable in a way the notes are not, and the CSV export from the inbox gives you the list of items to start from.

Filter the inbox by status closed to see everything you have declined, and check the log before you decide something similar. Consistency is the main thing this log buys you.

## Set a trigger for revisiting

A rejected request should come back only for a reason. Without a trigger, the request sits in closed forever, or it gets reopened every time someone is annoyed. Write the condition in the decision note, in terms you can check:

- "Revisit if three or more teams ask for a second theme in the next quarter."
- "Revisit when the export API is public, because the work depends on it."
- "Revisit after the next redesign of the inbox settings page."

A condition like "when we have time" is not a trigger, it is a wish. Conditions like the ones above are specific enough that you will notice when they are met. Review the closed items with conditions every quarter, or during the weekly triage, and reopen the ones that now meet the condition.

## How to reopen a closed request

When a trigger is met, reopen the item, set the status to new or planned depending on your decision, and add a note that says why. Then tell the customer who first asked. A short message is enough: say that the request came back for review, what changed, and what you will do next. Do not reopen it silently, because the customer may have already moved on, and a surprise reply from a closed thread can feel like a trick.

If a new customer asks for something you closed, do not just paste the old answer. Check whether the new message brings new information. If it does, treat it as a reason to review. If it does not, reply with the reason and link them to the earlier decision in your own words.

## Closing and reopening requests in Escuta Produto

In Escuta Produto, closed is one of the five statuses, alongside new, planned, in progress and done. Use it for decisions not to act, and use planned for requests you have accepted. Write the reason in the private note on the item, then send the reply from your own email to the address on the item, since Escuta Produto does not send automatic emails.

The page URL saved with every item (see [the widget docs](/docs/widget)) shows where each request came from. For the broader reply patterns, including how to say no without losing the customer, read [how to say no to a feature request](/resources/say-no-to-feature-requests). The status meanings and the transitions between them are in [how to design a feedback status workflow](/resources/feedback-status-workflow). If a rejected request keeps coming back in different words, the grouping steps in [how to triage customer feedback](/resources/how-to-triage-customer-feedback) help you see the pattern before you decide again.

## Frequently asked questions

### Should you tell a customer why their feature request was rejected?

Yes. Give the real reason in one or two sentences, such as the cost of maintaining it or the fact that only a few customers need it. A reason lets the customer respond with new information, while a bare closure reads as a dismissal.

### How do you keep rejected feature requests searchable?

Inbox search covers the message, name and email but not internal notes, so keep a decision log in a spreadsheet or doc with the item link, the decision, the date and the revisit condition. Filter the inbox by closed to review everything you have declined.

### When should you revisit a rejected feature request?

When a specific condition you wrote down is met, such as a dependency shipping or several paying teams needing the same change. A vague hope like when there is time is not a trigger, so review closed items with conditions on a regular schedule.

### How do you reopen a closed feature request?

Set the status to new or planned, add a note explaining why it came back, and tell the customer who first asked what changed. Do not reopen it silently, because a surprise reply from a closed thread can feel like a trick.