Skip to content
Choose what to build

Feature request template

By Cat Williams-Treloar, Founder·Updated Oct 21, 2026·7 min read

The short answer

A feature request template is a short form a customer or teammate fills in to ask for something, plus the record your team keeps of it. The form asks what they are trying to do, what is in the way, how often and how much it matters. The record keeps their words, the account and a link to your priority.

A feature request is a customer or teammate asking for something your product does not do yet. A feature request template is the form they fill in, and the record your team keeps once it is in. For what a request is and how it differs from a bug or an idea, see What is a feature request?.

TL;DR

  • Ask what they are trying to do, not which feature they want.
  • Five questions are enough. Every extra field costs you answers.
  • Keep their exact words, the account and what it pays.
  • Link every request to a priority, so ten asks become one row you can count.

When to use it: requests arrive from more than one place, or you keep answering "can you add X?" from memory. When not: you get a few a month. Reply, write it down in one list and move on.

A feature request template

Two parts. Part one goes to the customer or teammate. Part two is for your team.

A feature request form and record
## Part 1: the form (what the customer or teammate fills in)

1. What are you trying to do?
   <their answer>
2. What is in the way? What do you do today instead?
   <their answer>
3. How often does it come up?
   [ ] Daily  [ ] Weekly  [ ] Monthly  [ ] Rarely
4. How much does it matter?
   [ ] A nuisance  [ ] Slows me down  [ ] Blocks my work  [ ] I may leave
5. Can we follow up with you?
   [ ] Yes, at <email or handle>  [ ] No

## Part 2: the record (what your team keeps)

- Title: <what becomes true, in a customer's words>
- Their words: "<exact text>" (<name>, <where>, <date>)
- Account: <account> | Revenue: <per month, or unknown>
- Where it came from: <Slack | call | survey | support inbox | other>
- Link to priority: <existing row, or "new">
- Type: <bug | request | idea>
- Follow up OK: <yes | no>
- Told when shipped: <date, or not yet>

What goes in each part?

Part one: the form

What are you trying to do? The job, not the button. "Send my client a monthly summary" tells you more than "add PDF export".

What is in the way? What they do today, or why they cannot. This is where the real problem shows, and where you learn whether a workaround exists.

How often does it come up? Daily, weekly, once. A weekly need that costs an hour is a different job from a once-a-year annoyance.

How much does it matter? A short scale: a nuisance, slows me down, blocks my work, I may leave. It is their word for it. It is not your ranking, and it can be wrong, but it is evidence.

Can we follow up? A yes or no and how to reach them. A yes is how you ask one good question later, and how you tell them it shipped.

Part two: the record

The request, in their words. Paste the exact text. Do not tidy it. Your summary goes in the title; their words go underneath.

Account and revenue. Who it is and what they pay. One loud user and three quiet accounts that pay are different lines. If you do not know the revenue, write "unknown".

Where it came from. Slack, a call, a survey, the support inbox. You will want to go back to the source.

Link to the priority. The existing row this matches, or a new one. Matching requests belong on the same row, so you can count accounts.

Type. Bug, request or idea. Mark a broken thing as broken, and it goes ahead of most requests.

An example, filled in

This is an example, made up to show the level of detail.

Part one: what the customer wrote

What are you trying to do? Send my client a monthly summary of what we finished. What is in the way? I copy the list into a doc by hand. It takes me about an hour each month. How often? Monthly, and I have 6 clients. How much does it matter? Slows me down. Can we follow up? Yes, dana@example.com.

Part two: the record

Title: Send a monthly summary to a client. Their words: "I copy the list into a doc by hand. It takes me about an hour each month." (Dana, Northbeam Studio, in-product survey, 3 Oct) Account and revenue: Northbeam Studio, $49 a month. Where from: In-product survey. Link: Matches "Export a report as a PDF" (4 accounts so far, now 5). Type: Request.

Notice that the request says nothing about PDF. The link is yours to make, and the matching is where the count comes from.

When is a form overkill?

When the volume is low. Under a handful a month, you do not need a form: reply, ask the one question you need ("what were you trying to do?"), and add it to the list. A form helps when requests come from many places and you need the same five answers each time. If asking costs a customer more than a minute, shorten it.

How do I use the form without annoying people?

Ask once, at the moment they ran into the gap. Say what you will do with it. Then follow up when it ships, so asking feels worth it. There is more in get customer feedback without being annoying and feature request triage, which covers what to do once the requests are in. To write up the ones you build, use the feature description template.

How does Annsa help?

Annsa is the source of direction for your agents, and it takes requests in for you.

  • They come in automatically. From Slack, Intercom, call transcripts, in-product surveys (six templates), CSV and Google Sheets imports, GitHub, the API or typed in by hand. Each keeps the person, their exact words, the account and its revenue.
  • Matching requests are grouped, so five people asking five ways become one priority with five accounts behind it.
  • Ranking is shown, not hidden. Inside your bets, in your order: what a person marked broken first, then what customers asked for, then ideas. You choose; Annsa never decides for you.
  • When it ships, Share Back drafts a note to each person who asked. You send it.

Sources: Feature request, Wikipedia.

Questions people ask.

Q1

What should a feature request form include?

Five questions: what are you trying to do, what is in the way, how often does it come up, how much does it matter, and can we follow up. Skip fields that make people describe a fix. Annsa's in-product surveys bring requests in with the person behind them.
Q2

What is a feature request form template?

A set of questions you paste into a form tool, a survey or a message. The one on this page has two parts: the questions a customer answers, and the fields your team fills in after, such as the account, the revenue and the priority it links to.
Q3

Where should feature requests go?

Into one list, whichever way they arrive. Slack, a support chat and a call each hold a few, and nothing connects them. Annsa pulls them in from connected sources, keeps the person and their exact words, and groups matching requests.
Q4

Should I ask customers what feature they want?

Ask what they are trying to do instead. People are good at describing their problem and unreliable at designing the fix. Record their exact words either way, and decide the fix yourself.

Get your agents in a row.

Try Annsa