Feature request template: free copy-and-paste formats
Free feature request templates to copy or download: a customer form, an internal template, a GitHub/Jira version, a decision template and email examples — with a filled-in example.
Updated 7 October 2026 · Helpful BoB
What is a feature request template?
A feature request template is a fixed set of questions for writing down what someone wants changed in a product, why they need it, and who it affects. It turns a one-line message like “can we add export?” into something a team can actually assess.
Different moments need different templates. A customer needs a short form. Your team needs a fuller record. Engineering may want it in an issue tracker. And at some point someone has to decide and reply. Below are five templates, one for each of those moments, followed by a filled-in example.
1. Customer feature request form
Use this when customers submit requests themselves, on a feedback page or in a support form. Keep it to four questions — customers are describing a problem, not writing a spec. Ask about the problem first, not the solution.
Customer feature request form
FEATURE REQUEST FORM 1. What are you trying to do? 2. What gets in the way today? 3. How often does this happen? ( ) Daily ( ) Weekly ( ) Monthly ( ) Rarely 4. Have you found a workaround? If so, what is it? Your name, company and email (so we can reply):
2. Internal feature request template
Use this when a request reaches your team through a sales call, a support ticket or a Slack message. Whoever heard it fills it in, in the customer’s own words where possible. The evidence and workaround fields are the ones most often skipped and the most useful later.
Internal feature request template
FEATURE REQUEST Title (short and specific): Requested by (name, role, company): Date received and source (call, email, support ticket, Slack): Problem — what the customer is trying to do and what gets in the way: Proposed solution (as the customer described it): Who is affected (one user, a team, a segment, every customer): How often it comes up: Evidence (original quote, links to tickets or notes): Workarounds already tried: Status: New / Under review / Decided
3. GitHub / Jira feature request template
The same fields in Markdown, ready to paste into a GitHub issue template, a Jira description or a wiki page. For GitHub, save it as .github/ISSUE_TEMPLATE/feature_request.md.
Feature request template — Markdown
## Feature request: [short, specific title] **Requested by:** [name, role, company] **Received:** [YYYY-MM-DD] via [call / email / ticket / Slack] ### Problem What is the customer trying to do, and what gets in the way today? ### Proposed solution How the customer imagines it working. A starting point, not a spec. ### Who is affected - Users or teams: - How often: ### Evidence > Original customer wording - Links to tickets, notes or recordings: ### Workarounds tried ### Decision Build / Adapt / Defer / Decline — with a one-line reason and the next step.
4. Feature request decision template
Most templates stop once the request is written down. This one is for the next step: deciding what to do about it. Fill it in before a request becomes an engineering commitment, so everyone who reads it agrees on what was decided, what is in scope and what the customer will be told.
Four outcomes, not a queue
Build, adapt, defer and decline are four legitimate answers to the same request. None of them is a failure, and none of them is a stage the request passes through on its way to being built.
| Outcome | What it means | What it does not mean |
|---|---|---|
| Build | The problem deserves engineering time now, at a scope you have written down. | Choosing Build does not approve an estimate or a release date. Engineering gives those separately, after the unknowns are checked. |
| Adapt | You will address the underlying problem, but not with the solution that was requested. | Write down what you are not doing as clearly as what you are, or the customer will assume the original request is coming. |
| Defer | The need may be real, and you are not committing to it yet. | A defer without a revisit condition is a silent no. Say what would change your mind. |
| Decline | You are not going to do this. | Give the reason and any alternative, including what the alternative does not cover. |
Copy this into whatever your team already reads. The headings matter more than the tool.
Feature request decision — blank template
FEATURE REQUEST DECISION Request: Customer problem, in one sentence: Who is affected, and in what situation: EVIDENCE Original request and source: Other supporting evidence: Evidence against this interpretation: What we still need to check: COMMERCIAL CONTEXT Customer/account and owner: Confirmed commercial consequence: Requested deadline and reason: Commitment already made, if any: OPTIONS Requested solution: Existing capability or smaller alternative: What happens if we do nothing: DECISION Build / Adapt / Defer / Decline: Reason and main trade-off: Scope and exclusions: Engineering owner; estimate and confidence: Maintenance or support implications: Work this would displace: Success check: Decision owner and date: NEXT STEP Action, owner and due date: Approved customer response: Delivery commitment: none / approved scope and date Revisit condition:
5. Feature request email examples
Two emails people often need: one a customer sends to ask for a feature, and one the team sends back once a decision is made. The first leads with the problem; the second says what was decided without promising more than was agreed.
Email: requesting a feature
Subject: Feature request: [short description] Hi [name], We use [product] for [what you use it for]. One thing slows us down: [Describe the problem in one or two sentences — what you are trying to do and what gets in the way.] Today we work around it by [workaround], which costs us [time or effort]. What would help is [the outcome you need]. One way to do this might be [your idea], but we are open to other approaches. This affects [who, and how often]. Happy to show you on a call if that helps. Thanks, [Your name] [Role, company]
Email: replying to a feature request
We understand you need [outcome] because [situation]. We have decided to [adapt / defer / decline]. The reason is [plain explanation]. [Alternative and its limits, if available.] [Revisit condition, if deferred.] The next agreed step is [action and owner]. [No delivery date committed, if relevant.]
What each field is for
If you build your own template, these are the fields worth keeping. Cut any that your team never reads.
| Field | What it captures | Why it matters |
|---|---|---|
| Title | A short, specific summary | Makes requests easy to find and spot as duplicates |
| Requested by | Name, role and company | Lets you go back and ask, and reply when it is decided |
| Problem | What the customer is trying to do, and what gets in the way | Separates the real need from the suggested solution |
| Proposed solution | The customer's idea | A starting point, not a commitment |
| Who is affected | One user, a team, a segment, everyone | Shows how far the problem reaches |
| How often | Daily, weekly, rarely | Shows how much the problem hurts |
| Evidence | The original wording and links | Keeps the interpretation honest |
| Workarounds | What they do today instead | Shows urgency and often suggests a smaller fix |
| Decision | Build, adapt, defer or decline, with a reason | Closes the loop instead of leaving the request in limbo |
Filled-in example: notification preferences
A customer asks for an on/off switch for every type of email notification. Here is the decision template filled in for that request, so you can see what a complete answer looks like.
Request
Give every user their own on/off switch for each type of email notification.
Meridian Ops · operations lead, on a renewal call
Problem
Routine email makes the updates people actually need harder to find, so important messages get missed.
Decision
Adapt — assess a daily digest and quieter defaults, not per-user switches.
A daily digest and quieter defaults may reduce the email noise reported in four of the five conversations. That still needs testing. The fifth conversation identified a need for team-specific rules; this approach does not address it. Keep that need open for a separate review.
Evidence
Renewal call · Meridian Ops · operations lead
“we get an email for everything, so the ones that matter get lost.”
Support conversation · Meridian Ops · shift supervisor
“I filter them all into a folder and read the folder once a day.”
Product conversation · Two further operations users
“most of it is routine. I only need to be interrupted for exceptions.”
Evidence against
One of the five conversations does not describe volume at all: that team wants different notification rules per team, which a digest would not give them. That request stays open and unmet.
Commercial context
Raised during a renewal conversation. Nobody has confirmed it is a condition of renewal, and no date has been promised to the customer.
Scope
- —Assess a daily digest that groups routine item events into one send.
- —Quieter defaults for new workspaces.
- —Urgent exception alerts continue to arrive immediately.
Not in scope
- —Per-event on/off controls for individual users.
- —Team-specific notification rules.
Before estimating
- Which time zone a digest should be sent in for teams that work across regions.
- How events should be grouped inside one digest so it stays readable.
- What happens when a digest send fails — retry, or fall back to individual mail.
Engineering has not estimated this yet. The unknowns above are checked first; the estimate and its confidence are theirs to give.
Customer reply
“You told us routine emails make important updates harder to find. We’re assessing a daily digest while keeping exception alerts immediate. We have not committed to individual notification switches or a release date. Would this approach address the problem for your team?”
Team draft for review before sending.
Revisit when
Revisit per-user controls if a confirmed workflow is still unmet once quieter defaults are in place.
Decision owner
Head of product · decision recorded on the request
Evidence, not enthusiasm
Notice what the evidence section does. Four of the five conversations describe too much routine mail; one asks for team-specific rules, which a digest does not address. That disagreement stays on the page. If you delete it, the decision looks stronger than it is, and the one team you did not serve will raise the request again.
The commercial section is where most decisions get quietly distorted. The account is worth attention — but account value is context, not proof that this feature wins or retains the business. A confirmed commercial consequence is something the customer has actually said: this is a condition of renewal, this blocks a rollout, this is why the deal is paused. An expectation is your own read of the conversation. Write down which one you have.
Three checks before you send anything
- Can engineering see the scope, the exclusions and the open questions without asking you?
- Can the account owner explain this to the customer without adding a promise you did not make?
- Can the next person to read it tell what would justify revisiting it?
If any of those is a no, the page is not finished. The customer reply is part of the decision, not a follow-up task — a decision the customer never hears is the same as no decision at all. A person reviews the draft and sends it.
The reply on the example above says what is being assessed, names what has not been committed, and asks whether it addresses the problem. The answer to that question tells you whether the decision was right.
What to do after a request arrives
- 01Group similar requests. Put requests that describe the same problem together, keeping each original quote.
- 02Check the evidence. Note what supports the request and what does not. Disagreement is useful information.
- 03Decide. Choose build, adapt, defer or decline, and write down the scope and the reason.
- 04Reply to the customer. Tell them what was decided and why, without promising more than the team agreed.
For the whole process, read our guide to customer feedback management.
Frequently asked questions
- What should a feature request include?
- A short title, who asked and when, the problem the customer is trying to solve, their proposed solution, who is affected and how often, the original evidence, and any workaround they already use. The problem matters more than the proposed solution.
- How long should a customer feature request form be?
- Short. Three or four plain questions is enough for customers: what they are trying to do, what gets in the way, how often, and any workaround. Your team adds the rest when it reviews the request.
- What is the difference between a feature request and a spec?
- A feature request describes a customer problem and an idea for solving it. A spec describes what the team has decided to build, with scope and exclusions. The decision template sits between the two.
- How do you reply to a feature request you will not build?
- Say you understand the need, state the decision plainly, give the reason, offer any alternative and its limits, and name the next step. Do not imply a date you have not agreed.
Where to go next
For the wording of an adapt, a defer or a decline, read how to say no to feature requests. For how BoB keeps the request, the evidence and the decision together, see how it works.
Decision recorded, scope written, customer answered: revisit per-user controls if a confirmed workflow is still unmet once quieter defaults are in place.