Feature request template: collect the context your team needs

The best feature request form does not ask customers to write a product specification. It helps them explain the problem.

Long forms reduce submissions. Short forms that ask only for a title produce a backlog of guesses. Use a small customer form and add product detail during review.

Customer submission template

Title:
What are you trying to do?
What happens today?
How often does this come up?
What would a useful result look like?
Optional screenshot or example:

Make only the title and problem required. A customer should be able to submit useful feedback in under two minutes.

Internal review template

Customer problem:
Affected accounts or segment:
Linked duplicates:
Current workaround:
Frequency and severity:
Strategic theme:
Evidence:
Expected outcome:
Smallest test:
Effort and uncertainty:
Decision and reason:

Product or support can add this detail after talking with the requester.

Improve request titles

Rewrite vague titles without changing the meaning:

• “Reports” → “Schedule a report for email delivery”
• “Permissions” → “Limit contractors to selected projects”
• “Mobile” → “Approve work from a phone”

The title should help another customer recognize the same need.

Acknowledge and merge

Confirm receipt immediately. If the request already exists, merge it and preserve the new customer’s context. Tell them where they can follow progress.

Do not promise delivery in the acknowledgement.

Record the decision

A request is not managed until it has a state and owner. Use under review, planned, in progress, shipped, or not planned. Add a short reason internally.

Feedboard provides a customer-facing place for submissions and a shared record for the decisions that follow. Create your feature request board.

Adapt the template by channel

Support should capture the original conversation and add the customer automatically. Sales should include opportunity context and whether the request blocks a deal. A public form should remain short and avoid commercial questions.

Example completed request

Title: Schedule weekly client reports
Goal: Keep clients informed without exporting reports manually.
Today: An account manager exports a PDF every Monday and emails six clients.
Frequency: Weekly across twelve projects.
Useful result: Choose a report, recipients, and delivery schedule.

The team can now investigate scheduled delivery, client access, or another solution without losing the underlying job.

Review-quality checklist

Before prioritizing, confirm:

• The customer and segment are known.
• The problem is described separately from the solution.
• Duplicates are linked.
• Frequency and consequence are understood.
• A current workaround is recorded.
• Someone owns the next step.

What not to ask customers

Do not require impact scores, engineering effort, priority labels, or a complete specification. Customers know their workflow; the product team owns product judgment.

Close declined requests

Use a direct explanation:

We reviewed this use case, but it does not fit the reporting direction we are pursuing this year. We are keeping the context attached in case that direction changes.

An honest decision is more useful than leaving every request “under review.”

Build request quality into the interface

Suggest similar posts while the customer types a title. This reduces duplicates and lets them add context to an existing idea.

Use examples beside open questions:

What are you trying to accomplish? For example: “Send a weekly progress report to clients who do not have accounts.”

Avoid examples that steer customers toward your preferred solution.

Capture identity safely

Link authenticated users to their account, plan, and role internally. Do not publish commercial data or personal details.

When feedback arrives from a public visitor, ask for an email only if updates or follow-up are offered. Explain how it will be used.

Handle duplicates without losing evidence

A duplicate is not worthless. It adds another affected customer, workaround, and segment.

When merging:

1. Keep the requester attached.
2. Preserve their description privately.
3. Move votes and comments when supported.
4. Redirect the old link.
5. Notify the requester of the main post.

Add research questions after intake

For a promising request, follow up:

• Tell me about the last time this happened.
• Who was involved?
• What did you do instead?
• How often does it occur?
• What happens if the problem remains?
• Could you show us the current workflow?

Current behavior is stronger evidence than a hypothetical promise to use a feature.

Use a scoring discussion, not a scoring machine

The internal brief can include reach, impact, confidence, effort, strategic fit, and risk. Record the reasoning behind each value.

A score should help compare similar opportunities. It should not hide uncertain assumptions behind decimal points.

Define request states

State	Meaning
New	Received but not reviewed
Under review	Gathering context or evaluating
Planned	Team intends to pursue the outcome
In progress	Active design or development
Shipped	Customer-facing result is available
Not planned	Reviewed and declined

Give “under review” an owner and next review date. Otherwise it becomes permanent storage.

Measure the request system

Track acknowledgement time, duplicate rate, requests with customer context, time under review, decisions per period, and requesters notified after release.

High submission volume with slow decisions is not success.

Frequently asked questions

Should customers choose priority?

Let them describe urgency or allocate limited votes, but keep roadmap priority with the product team.

Should anonymous requests be allowed?

Anonymous access reduces friction but prevents follow-up and attracts spam. Use it only when the tradeoff fits your audience.

How long should the form be?

A customer-facing form should usually take under two minutes. Gather deeper detail in follow-up research.

Template for a public response

Thanks for describing how you currently handle this.
We linked your account to the request and are reviewing the underlying
problem. This status does not mean the feature is committed.
We will update this post when the decision changes or we need more context.

For a planned outcome:

We plan to improve this workflow. We are still validating the exact
solution and are not committing to a release date yet. Linked requesters
will receive another update when active work begins.

Audit form performance

Review abandonment, duplicate suggestions, requests needing clarification, spam, and the percentage of submissions that reach a decision.

If many requests lack context, improve the prompt or submission moment before adding mandatory fields.

Keep examples maintained

As the product changes, old examples can teach customers to request retired workflows. Review form hints, categories, and policies quarterly.

One current, well-explained template is better than separate forms that send support, sales, and customers into disconnected backlogs.

Minimum viable process

Start with one form, one intake owner, weekly duplicate review, five clear states, and automatic requester updates. Add scoring, segmentation, and integrations only when the team has a decision that needs them.

The template should reduce the effort required to understand customers. If maintaining the form and fields takes more time than reviewing evidence, simplify it.