How to Set Up a Free Feature Request Board for Your SaaS

Write one sentence explaining why the board exists before configuring anything. A useful purpose might be: “Give customers one place to suggest product improvements, support existing ideas, and follow decisions.” That sentence helps you reject features and fields that do not serve the workflow.

Decide what the board will not handle. Support incidents, account questions, security reports, and private commercial requests usually need other channels. Explain those boundaries near the submission form so urgent problems do not wait in a public moderation queue.

Free plans differ in the limits they apply. Some restrict boards, submissions, voters, team members, branding, or notifications. Compare the limit with your expected use rather than choosing the tool with the longest feature list.

• Can customers submit and vote without confusing setup?
• Does participation require authentication, and is that appropriate for your audience?
• Can the team moderate posts before they become public?
• Are the roadmap statuses understandable and sufficient?
• Can you identify and contact interested users when something ships?
• What happens when you reach the free plan’s submission or user limit?
• Can you export your information if your process changes later?

Shipvox’s free plan is designed for a small first portal, with a defined monthly feedback allowance and captured-user limit. Those boundaries are visible on the pricing page so a team can decide whether the free tier matches its current stage.

Long forms reduce participation, while a title-only form creates vague requests the team cannot evaluate. Ask for a short title and a description that encourages the customer to explain their situation and desired outcome.

• What are you trying to do?
• What happens today?
• Why does this matter to your workflow?
• Is there a workaround you currently use?

Avoid asking customers to estimate business impact, implementation effort, or internal priority. Those are decisions for your team. The submission experience should help a user describe the need in their own language.

A public board needs a lightweight review process. Moderation protects customer privacy, keeps the discussion relevant, and prevents the same idea from splitting across several posts. It should improve clarity without silently changing the meaning of a request.

1. 1

   Check privacy

   Remove account details, personal data, confidential screenshots, or security information before publication.

2. 2

   Search for duplicates

   Combine only requests that share the same underlying outcome, then preserve the context from each customer.

3. 3

   Clarify vague ideas

   Ask a follow-up question when the team cannot understand the current problem or desired result.

4. 4

   Route other issues

   Move urgent support, billing, and security matters to the private channels where they can receive the right response.

Tell customers that a vote shows interest but does not guarantee delivery. Without that expectation, a visible count can look like a binding election. Your team still needs to consider impact, strategy, cost, risk, and what quieter users need.

Encourage comments when the reason behind a vote is important. The practical guide to feature voting explains the biases to watch and the evidence to pair with totals.

Requiring a signed-in identity can add a small amount of friction, but it improves vote integrity and gives the team a way to follow up. Choose the tradeoff intentionally based on whether participation quality or maximum volume matters more for your stage.

Start with under review, planned, in progress, and shipped. Define each status in customer language and move a request only when the underlying decision changes. New submissions should never appear planned automatically, regardless of vote count.

• Under review: the team is learning and has not committed.
• Planned: the team intends to address the need, with scope or timing still subject to change.
• In progress: active work toward the outcome has begun.
• Shipped: the relevant improvement is available to customers.

If you later publish a broader view, follow the same principles described in the public product roadmap guide. A board earns trust through accuracy, not through the number of items it displays.

An entirely empty board asks the first visitor to invent the conversation. Before launch, add a few genuine themes already heard from customers. Do not manufacture votes or pretend those ideas came from named users. Simply present known topics clearly so visitors can recognize and support them.

• Link the board from your app’s help or account menu.
• Include it in support replies when a customer suggests an improvement.
• Share it in onboarding or customer-community resources.
• Use the same link after research calls so customers can follow progress.
• Add it to your website footer as a durable feedback destination.

Do not announce the board everywhere at once if nobody owns moderation. Begin with a small group of engaged customers, observe where they hesitate, adjust the instructions, and then widen access.

1. 1

   Review new posts

   Check privacy, clarity, relevance, and duplicates on a predictable schedule.

2. 2

   Respond selectively

   Ask useful questions and acknowledge meaningful context without creating an expectation that every post receives a custom product decision immediately.

3. 3

   Review themes

   Periodically compare demand, impact, strategy, evidence, and cost with the people responsible for product decisions.

4. 4

   Update statuses

   Reflect real decisions promptly and explain material changes when customers may otherwise misread them.

5. 5

   Return after shipping

   Notify interested users, describe what changed, and learn whether the original workflow improved.

A free board is successful when it helps you establish a repeatable feedback habit. Upgrade or change tools when real usage requires more submissions, captured users, team members, portals, automation, or control—not because a generic growth checklist says you should.

Before paying for more capability, check that the team is already moderating, reviewing, and closing the loop consistently. Software can remove limits and manual work, but it cannot supply ownership. The process you prove on the free plan is what makes a larger system valuable later.