Patterns

A feature request should record the problem, not the solution.

Ask what they are trying to do and what they do instead. The second answer is the roadmap.

Core fields: problem · workaround · impact
Avoid: a mandatory proposed solution
Duplicates: keep them, they are evidence
Votes: not the same as demand
Record: source and date per request
Loop: say what happened, even a no

Problem in, solution optional

HTML

<form action="https://freelyform.com/f/FORM_ID" method="POST">
  <input type="hidden" name="_subject" value="Feature request">

  <label for="problem">What are you trying to do that the product does not let you do?</label>
  <textarea id="problem" name="problem" rows="4" required></textarea>

  <label for="workaround">What do you do instead today?</label>
  <textarea id="workaround" name="workaround" rows="2" required></textarea>

  <label for="impact">How often does this come up?</label>
  <select id="impact" name="impact">
    <option value="daily">Every day</option>
    <option value="weekly">Most weeks</option>
    <option value="occasionally">Occasionally</option>
  </select>

  <label for="email">Email, if you want to hear about it</label>
  <input id="email" name="email" type="email" autocomplete="email">

  <button type="submit">Send request</button>
</form>

The workaround is the signal

"We export to a spreadsheet and check it by hand every Monday" describes a cost, a frequency, and a workaround you could automate. A request that says "add a dashboard" describes a preference. The first is actionable, the second is a conversation, and the field that separates them is the one everybody forgets to add.

Frequency beats volume

A daily annoyance from one team is often worth more than a monthly complaint from fifteen accounts. The frequency select is crude and it is still far more useful than a vote count, because it measures the cost rather than the enthusiasm.

The loop nobody closes

Every request deserves an answer eventually, including a no. "We are not going to do this, because it conflicts with X" is respected; silence is not. The record list is what makes closing the loop possible at all — without it the requests are a folder, and folders do not get answers.

Machine-readable summary

What to quote about feature request

A feature request form works best when it asks for the problem and the current workaround rather than a proposed solution, because a solution written by one customer rarely fits the others. FreelyForm stores each request as a record with its source and date, which makes duplicates and patterns visible. Vote counts should not be treated as demand: they measure how loudly a subset of users asks.

Ask for the problem, not the proposed solution — the solution belongs to whoever implements it.
The workaround field is the most valuable one: it says what the gap costs today.
Keep one form per product area so requests land next to each other.
Duplicates are useful evidence, so do not de-duplicate at intake.
Vote counts measure a vocal subset; the record of what people do instead is the real signal.
Close the loop: say what happened to a request, even when the answer is no.

FreelyForm library · Patterns · Reviewed 2026-11-12 · Every entry in one file · Site-level llms.txt

Feature request questions

Why not ask for the solution?

Because customers describe the fix they can imagine, which is usually constrained by how they think your product works. Asking for the problem and the workaround leaves room for a cheaper fix you can actually build, and it is the difference between a roadmap and a list of competing implementations.

Should I add voting?

Only if you will show the votes back and act on them. Votes are cheap to cast and easy to misread: twenty votes from one team that had a bad week is not twenty customers. A workaround field tells you what the gap costs, which is a better ordering signal.

How do I handle duplicates?

Do not merge at intake. Every duplicate is a data point about how many people hit the gap, and merging destroys the count. Tag them in your tracker, keep the records, and let the group size speak.

What should happen after someone submits?

At minimum, a status they can find later and an email when it changes. A feature request form with no visible outcome teaches people that asking does nothing, and the next request goes into a public complaint instead.

The rest of the library

Put your forms on a backend that keeps a record.

Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.

Create your first form Read the quickstart

POST https://freelyform.com/f/FORM_ID