Feature Request Template: A Copy-Paste Format That Gets Used

Most feature requests show up as a one-line Slack message: "can we add dark mode?" No context, no requester, no sense of how many people actually want it. Three weeks later nobody remembers who asked or why it mattered.

A small template fixes most of that. Here is one you can copy today, a shorter version for your users to fill in, and a lightweight way to triage what comes in.

The template (copy this)

## Feature request: [short, specific title]

**Requested by:** [name / team / customer]
**Date:** [YYYY-MM-DD]
**Status:** New

### Problem
What is the user trying to do, and what gets in the way today?
Write it as a user story: "As a [role], I want to [goal], so that [outcome]."

### Proposed solution
What change would solve it? Keep it outcome-focused, not a full spec.

### Why it matters
- Who is affected — one user, a segment, or everyone?
- How often does this come up?
- What is the cost of not doing it (churn risk, support load, lost deals)?

### Evidence
Links to the original feedback, support tickets, or direct quotes.

### Effort (filled in by the team)
T-shirt size: XS / S / M / L / XL

### Decision
Planned · Considering · Declined — with a one-line reason.

The two fields people skip are the ones that matter most. Why it matters stops you from building for the loudest voice instead of the most common need. Decision — even a one-line "declined, out of scope this quarter" — is what lets you close the loop later instead of leaving requests in limbo.

A shorter feature request form for your users

The template above is for your team. When you want end users to submit requests, do not hand them six fields — cut it to four plain questions:

- What would you like to be able to do?
- What are you trying to accomplish?
- How do you work around it today?
- (optional) Your email, so we can follow up.

That last line matters. An email turns an anonymous wish into a person you can come back to the day you ship — which is the whole point of collecting requests in the first place.

What to do once requests come in

A template only helps if requests get read. Block 30 minutes once a week and:

1. Merge duplicates. Five "add a dark mode" notes are one request with five votes — that count is your priority signal.
2. Fill in effort and a decision. Even a quick T-shirt size and a Planned/Considering/Declined keeps the list honest.
3. Reply to the requester. "Shipped," "on the roadmap," or "not now, here's why" — all three build trust.

If the volume is high enough that the weekly pass feels like data entry, you can triage feedback with an AI agent instead of doing it by hand.

Where a static template breaks down

A doc or a Google Form works until you have more than a handful of requests. Then you hit three walls:

• Duplicates pile up and you lose the count that tells you what to build.
• There is no prioritization signal — every request looks equally important in a spreadsheet.
• You cannot close the loop, because the requester's email is buried three tabs away.

That is exactly what a feedback widget plus a voting board is for. Requests come in tagged and deduplicated, users upvote the ones that matter, and the whole thing lives in one inbox instead of a spreadsheet — customer feedback management without the busywork. When you ship, the people who asked get told automatically.

Start with the template, graduate to a board

Copy the template, use it for a month, and pay attention to where it strains. The day you are merging duplicates by hand or forgetting who asked for what, move the whole loop onto your site in one line of code.

Try the live feedback demo — or drop the widget on your site and start collecting structured feature requests today.