Accepting a solution with no problem behind it
'Add a dark mode' says what someone wants, not why. Ask for the job first, and let the solution come out of the answer.
Feature request template: capture the job before the idea
A feature request template collects the problem behind a request: the job someone is trying to do, the workaround they use now, and how often the gap costs them time. The most useful answers describe the job without designing the feature, which keeps requests comparable with one another. Keep the form short enough that people describe real use, then compare requests by the problem they solve rather than by which one sounds most exciting.
What people search
Feature request template: 70 average monthly searches.Google Ads Keyword Planner · 2026-10-09 · United States
Field blueprint
Ask about the job, the workaround and the cost of the gap
| Field | Type | Required | Why you ask it |
|---|---|---|---|
Your name | Short text | Required | Lets the product team ask a follow-up about how you use the product. |
Email address | Required | Where the team replies once the request has been reviewed. It is required so the loop can close. | |
Company or accountLeave blank if you work alone. | Short text | Optional | Shows whether several customers describe the same need, which counts for more than one loud request. |
What are you trying to do?For example: check which orders are still open before a monthly call | Long text | Required | The job behind the request. Requests that name a job can be compared with each other. |
How do you handle this today?A spreadsheet, a manual copy, another tool, or a colleague who does it for you. | Long text | Required | The workaround shows what the gap costs and what a good replacement has to do. |
Short name for the featureFor example: export a filtered list | Short text | Required | A short label for the list. The detail belongs in the fields above, so keep the name neutral. |
How often would you use it?Every dayEvery weekEvery monthRarely | Single choice | Required | Frequency turns a nice-to-have into a measurable cost in time. |
How important is this to your work?Think about what happens if this never ships. | Rating | Optional | The requester's view is one signal. Weigh it against the job, the frequency and how many others describe the same need. |
Which area does this touch?Dashboards or reportsSign-in or permissionsMobile appData exportOther | Dropdown | Optional | Gives the reader a first sort, so the request reaches the person who knows that area. |
Would you like to hear what we decide?YesNo | Single choice | Optional | A separate choice, so people who want an update can ask for one without the form promising it. |
Examples from your work (optional)A short example is enough. Remove personal details first. | Long text | Optional | Real examples show the edge cases that a summary leaves out. |
Try it
Try the request as a customer would
After a response arrives
What the team does with a request
Read the problem before the proposed fix
A saved request is picked up by the hourly production job, which notifies only the form's creator. Group requests by the job they describe rather than by the first solution offered, because two different features may answer the same underlying need.
Count distinct accounts before counting votes
Requests are listed in a grid, and CSV export lets you count how many separate people describe the same job. Do this before a request reaches a roadmap, so one large account does not set the priority alone.
Close the loop with a decision
Tell requesters what was decided and why, including a no. Set the timing through your own process, and avoid promising a date you cannot meet.
Mistakes to avoid
Requests that look useful but are not
Reading vote counts as priority
Ten requests may come from one large account, or from ten small teams with the same minor need. Count the distinct accounts behind a request before you treat its volume as demand.
Letting the form collect bug reports
A broken behavior needs steps to reproduce and the version in use. Send those reports to a bug report form, and keep this one for changes people want to see.
Making a promise in the confirmation
A message that says the request is on the roadmap, before anyone has reviewed it, sets an expectation the team may not meet. Thank the person and describe what happens next.
Frequently asked questions
What should a feature request form include?
Include the requester's contact details, the job they are trying to do, the workaround they use today, how often the gap costs them time, and a short name for the feature. Keep one optional field for examples, so the team reads the need before the proposed solution.
Is there a free feature request template I can use?
Use the field list in this guide as your starting template. Remove any field you cannot act on, and keep the questions about the job and the workaround, because those are what make requests comparable.
How do I prioritize feature requests?
Look at the job behind each request, how often it happens, how many separate customers describe it, and how well it fits the direction of your product. Vote counts can start a conversation, but they should not set the order by themselves.
Should a feature request form allow anonymous requests?
Anonymous requests are hard to clarify, because the team cannot ask what the job was or when it matters. If you accept them, say that a reply may not be possible, and keep the question about the job required.
Browse by category
More requests in Customer Service & Support
Requests
Return Authorization (RMA)
Requests
Service Cancellation
Requests
Support Ticket Request
Surveys
Net Promoter Score (NPS)
Surveys
Customer Onboarding Feedback
Reports
Warranty Claim
How to build it
Choose a category and a form type in the wizard. Answer three Atty Suggestions questions, then give the form a title. Atty builds the fields in the background. Edit the fields and ask Atty to refine them, then publish and share the /f/ link.
