Feature Request Template: Copy-Paste Form & GitHub Version

Why a template beats an open text box

An empty box gets you the user's proposed solution and nothing else. You cannot tell how often the problem happens, whether there is a workaround, or whether ten other requests describe the same problem in different words. Five structured questions fix that, and they take the user less than a minute.

1. Customer-facing feature request form

Use this in a help-center form, a Typeform or Tally form, or an email reply. Keep the optional email field: it is how you close the loop later.

Customer form

Feature request

1. What are you trying to do?
   Describe the task, not the feature. Example: "Send my client a weekly report."

2. What gets in the way today?

3. How do you handle it right now?
   (Workaround, another tool, or "I can't.")

4. How often does this come up?
   ( ) Daily  ( ) Weekly  ( ) Monthly  ( ) Rarely

5. How much does it affect you?
   ( ) Minor annoyance  ( ) Slows me down  ( ) Blocks me

6. Anything else? Add a screenshot or an example if you have one.

7. Email (optional): we'll tell you when the status changes.

2. Internal feature request template

For sales, support, and customer success logging requests on a customer's behalf. The quote and the conversation link matter most: they stop the request from being rewritten into what the team member thinks the customer meant.

Internal form

Internal feature request (sales, support, success → product)

Customer / account:
Plan and monthly value:
Requested by (name, role):
Link to the conversation:

In the customer's words (paste a quote):

The problem behind it:
Current workaround:
How often it happens:

Business impact:
( ) Nice to have  ( ) Hurts satisfaction  ( ) Blocks a deal or upgrade  ( ) Renewal at risk
Deal size or renewal date, if relevant:

Similar requests already logged (links):
Submitted by:              Date:

3. GitHub feature request issue form

For open-source projects and developer tools. Save it as .github/ISSUE_TEMPLATE/feature_request.yml. The required duplicate check cuts down on repeat issues.

feature_request.yml

# .github/ISSUE_TEMPLATE/feature_request.yml
name: Feature request
description: Suggest an improvement or a new capability
title: "[Feature]: "
labels: ["enhancement", "needs-triage"]
body:
  - type: markdown
    attributes:
      value: |
        Thanks for the idea. Describe the problem first; we can work out the solution together.
  - type: textarea
    id: problem
    attributes:
      label: What problem are you trying to solve?
      description: The task you were doing and what got in the way.
      placeholder: When I export a report, I have to reformat every column by hand...
    validations:
      required: true
  - type: textarea
    id: workaround
    attributes:
      label: How do you handle it today?
  - type: dropdown
    id: frequency
    attributes:
      label: How often does this come up?
      options:
        - Daily
        - Weekly
        - Monthly
        - Rarely
    validations:
      required: true
  - type: textarea
    id: solution
    attributes:
      label: What would a good solution look like? (optional)
  - type: checkboxes
    id: checks
    attributes:
      label: Before you submit
      options:
        - label: I searched existing issues and this has not been requested yet.
          required: true

A filled-in example

Notice what this request gives you that “please add scheduled reports” does not: a weekly frequency, a 40-minute workaround, and a business cost (late client reports). That is enough to score it with the RICE calculator.

Filled-in example

Feature request: Scheduled report emails

1. What are you trying to do?
   Send each of my 12 clients their dashboard every Monday morning.

2. What gets in the way today?
   There's no way to schedule an export, so I have to remember to do it.

3. How do you handle it right now?
   I export 12 PDFs by hand every Monday and attach them to emails. About 40 minutes.

4. How often does this come up?
   (x) Weekly

5. How much does it affect you?
   (x) Slows me down

6. Anything else?
   Two clients asked why their report was late last month.

7. Email: maria@agency.example

Reply templates for every outcome

Every request deserves an answer, including no. Replace the placeholders and keep the tone plain. A clear “not now” with a reason keeps more goodwill than silence. For when to use each one, and the hard cases, read how to respond to feature requests.

Need more detail

Hi {name},

Thanks for the suggestion. Before we decide, can you tell me a bit more?

- What were you trying to do when you needed this?
- How are you handling it today?

A sentence or two is plenty. It helps us build the right thing rather than the first idea.

{your name}

Yes, it is planned

Hi {name},

Good news: this is on our roadmap and we plan to start on it {timeframe}. You can follow progress and vote here: {roadmap link}.

We'll email you when it ships. If you'd like to try an early version, just reply and I'll add you to the list.

{your name}

Not now

Hi {name},

Thanks for raising this. We've logged it, and it isn't something we can take on in the next few months because {short honest reason}.

In the meantime, {workaround}. I've added your vote, and if more people need it we'll revisit. You'll get an email if the status changes.

{your name}

No, we will not build it

Hi {name},

Thanks for the detailed request. I want to be straight with you: we don't plan to build this. {Product} is focused on {focus}, and {feature} would pull us away from that.

If it's essential, {alternative tool or workaround} handles it well. I'd rather tell you now than leave it open-ended.

{your name}

It already exists

Hi {name},

Good news: you can already do this. Here's how: {steps or doc link}.

If it doesn't quite cover what you need, reply and tell me what's missing.

{your name}

From template to roadmap

Collect requests in one place, not across email, chat, and spreadsheets.
Group requests that describe the same problem, and count the people behind each.
Ask the clarifying questions where a request is vague.
Score the shortlist with RICE, then put the winners on a public roadmap.
Tell requesters when the status changes, and again when it ships.

Questions people ask

What should a feature request template include?

The task the user was trying to do, what got in the way, their current workaround, how often it happens, and how much it affects them. Those five fields let you judge the request without a follow-up call.

Should users describe the feature they want?

Let them, but ask about the problem first. Users are experts on their problem and rarely on the best solution, and the problem description is what lets you group similar requests.

Where do I put a GitHub feature request template?

Save the YAML file as .github/ISSUE_TEMPLATE/feature_request.yml in your repository’s default branch. GitHub then shows it as an option when someone opens a new issue.

How should I reply to a feature request I will not build?

Say no clearly and early, give a short honest reason, and offer a workaround or alternative if one exists. A vague "we’ll consider it" is a slow no that costs more trust than a polite direct one.

Feature request template: copy, paste, and get better requests