Feature Request Response Template: Defer or Decline
Copy customer replies for deferred and declined feature requests. Explain the decision, offer a checked workaround, and set an honest reconsideration trigger.
By Feedbackly · Updated
Product walkthrough
Watch the Feedbackly walkthrough before testing your public request workflow during the seven-day trial.
Watch the product walkthroughSee requests, comments, and status updates
Practical context for Feature Request Response Template: Defer or Decline
A useful feature request response names the customer's problem, states the decision, gives a reason they can understand, and explains what happens next. Use the templates below when a reviewed request is deferred or declined. Replace every bracket and remove any line you cannot support before sending the reply through your existing customer communication process.
Deferring means you are leaving a decision open under a stated condition. Declining means you have decided against the requested direction within the scope you describe. Neither reply needs an invented release date. If the team has not reviewed the request, acknowledge receipt and name the next review step instead of using either decision template.
Confirm the decision before writing the reply
Start with the internal request record: the task, evidence, decision owner, reason, and any condition for reconsideration. Check that the person sending the reply has the current decision. 'We do not have capacity this month' and 'this is outside the product's intended scope' call for different explanations. Do not soften the second into a suggestion that implementation is simply waiting in line.
Describe the underlying task in the customer's language. A request for a scheduled export might concern getting a report to a colleague before a meeting. Reflect that outcome before discussing implementation. If the request contains several needs, identify the part your decision addresses; declining automatic delivery does not settle whether reusable report settings would help.
Choose a reason that is both accurate and appropriate to share. Explain the relevant product boundary, unresolved question, dependency, or capacity choice. Keep private account details and internal commercial discussions in the internal record. A public explanation should still give the reader enough information to understand the decision.
- +Unreviewed: name the next review action without implying a decision.
- +Deferred: state what would cause a fresh review, if anything.
- +Declined: explain the scope of the decision without disguising it as a queue position.
Copy a response to a deferred feature request
Use this reply when a specific dependency, evidence gap, or planning condition keeps the request open. A reconsideration trigger can be completion of a dependency or a relevant change in the task. Choose one your team can observe. An update checkpoint is a commitment to communicate, so include it only when someone owns that action.
A workaround should be tested in the relevant conditions before you recommend it. Explain what it helps with and what remains manual. If there is no useful workaround, say that plainly and remove the optional line. Avoid calling a partial workaround a solution to the original request.
DEFERRED FEATURE REQUEST — EDIT BEFORE SENDING Thanks for explaining [task and obstacle]. We understand that you need [desired outcome]. We reviewed [specific request]. We are deferring it because [shareable reason]. It is not scheduled for delivery, and we have not committed to a release date. [Optional, only if checked: For now, you can use [workaround]. This helps with [part of the task], but [remaining limitation].] We will reconsider this when [observable condition]. [Optional, only if owned: We will post an update at [checkpoint], even if the decision has not changed.] If [specific evidence that could affect the decision] changes, please add that context at [request or contact destination].
- +Keep 'not scheduled' separate from 'planned for later'.
- +Name an actual review condition rather than a vague promise to revisit soon.
Copy a response to a declined feature request
Use a declined reply when the requested direction does not fit the product or the team has otherwise made a clear decision against it. Explain which direction you mean. You can acknowledge a real problem while deciding that your product will not provide the requested solution. Avoid suggesting that enough votes will overturn a decision unless your actual process supports that rule.
You do not need to invite more evidence in every refusal. If the boundary is firm, close with the supported path or a clear acknowledgement of the remaining gap. If a materially different need could change the assessment, state that distinction without asking the customer to repeat the same argument.
DECLINED FEATURE REQUEST — EDIT BEFORE SENDING Thanks for describing [task]. We understand the difficulty with [current obstacle]. After review, we have decided not to build [specific requested direction] because [shareable product boundary or reason]. This request is not on our delivery plan. [Choose one, then remove the other: - The supported way to handle [part of the task] is [checked path], with [important limitation]. - We do not currently provide a workaround that meets this need.] [Optional, only if relevant: A different need involving [specific distinction] would require a separate review. You can describe that at [destination].] Thank you for helping us understand the problem.
- +State the decision directly and respectfully.
- +Do not promise an alternative feature that has not been agreed.
Worked example: decline delivery, defer reusable settings
This fictional example concerns an imaginary reporting app. A customer asks for a report to be emailed to an outside contractor every Monday. During review, the team identifies two tasks: rebuilding the same filters and distributing the file. It declines automatic external delivery under its current product scope. It separately defers reusable filter settings until an investigation of recurring report setup is complete.
The reply should preserve those two decisions. Saying 'we will consider this for a future release' would hide the delivery decision. Saying 'we cannot help with reporting' would be too broad. The reviewer checks that manual download works, then explains that it still requires the customer to distribute the file themselves.
The owner records an internal action to finish the setup investigation. That action is not a release commitment. If the investigation does not finish, the customer update should say so rather than quietly substituting a new expected delivery date. Use the following completed message as an example of structure, not as a claim about Feedbackly's reporting features.
FICTIONAL COMPLETED REPLY — NOT CUSTOMER DATA Thanks for explaining your Monday reporting task. You need to avoid rebuilding the same filters and get the result to a contractor. We have decided not to add automatic delivery to external recipients within our current reporting scope. That part of the request is not on our delivery plan. Reusable filter settings are a separate request. We have deferred that decision until we finish observing the recurring setup task. They are not scheduled for delivery. For now, manual download works for creating the file, but you still need to send it yourself. We checked that path in our sample reporting workflow. The review owner will update the reusable-settings request after the setup investigation. We have not committed to a release date.
- +One submission can contain needs with different decisions.
- +A checked partial workaround still needs its limitation stated.
Keep the public request and customer message consistent
Before sending, compare the reply with the public request. A status of Planned beside a message saying 'not scheduled' gives conflicting information. Use the statuses your software actually supports and explain any decision that does not fit those labels. Keep the internal reason, customer-facing explanation, and next action linked so a later reviewer can understand the history.
Feedbackly supports Under review, Planned, In progress, and Completed. It has no dedicated Deferred or Declined status. Use an explanatory public comment for the decision and keep any internal decision label in your own tracker. Do not mark unbuilt work Completed simply to make it disappear from review. Comments are public; retain private evidence elsewhere.
Copying these replies does not send a message or configure notifications. Feedbackly's request-following emails concern status changes for verified, subscribed followers when delivery is configured. Adding a decision comment does not itself trigger that status-change email. Use your existing customer communication channel when an individual reply is needed, then record that follow-up in your internal tracker.
- +Check the request, reply, recipient, and every remaining placeholder.
- +Record who will observe the reconsideration trigger or deliver an update.
- +Check whether the customer received the intended follow-up through your chosen channel.
Keep exploring this topic
These next reads help you move from the concept on this page to a framework, tool, template, or deeper comparison you can apply right away.
Questions teams usually ask
How do I say no to a feature request politely?
Acknowledge the task, state the decision, and explain the relevant reason. Offer a workaround only if it helps and has been checked. Respectful wording does not require a promise to build the feature later.
Should every deferred request have a release date?
No. A deferred request is not a scheduled commitment. Record an observable reconsideration condition, and include an update checkpoint only when someone owns that communication.
Can I use Deferred or Declined as a Feedbackly status?
Those are not supported status labels. Feedbackly provides Under review, Planned, In progress, and Completed. Explain the decision in a public comment and keep private decision notes in your internal tracker.
Keep public requests connected to clear decisions
Try Feedbackly for public requests, discussion, voting, and visible status. Keep private review notes in your own tracker and explain decisions where customers can find them.