How to Set Up a Feature Request Board in Notion
Feature requests arrive through every channel: customer success tickets, sales calls, support chats, and Slack messages. Without a centralized intake system, requests get lost, duplicated, or forgotten. A Notion feature request board creates a single place to capture, vote on, and triage customer needs — and connects them directly to your roadmap when they are ready to build.
This guide covers building a production-ready feature request board in Notion that your entire company can use to submit requests and that your PM team can use to triage and prioritize.
Step-by-step guide
Create the Feature Requests database
In your team workspace, create a full-page database called "Feature Requests." Add these properties: Title (auto), Description (text), Status (select: New, Under Review, Planned, In Progress, Shipped, Declined), Source (select: Customer, Sales, Support, Internal, User Research), Customer Name (text), ARR Impact (number, in thousands of dollars), Vote Count (number), Linked PRD (relation to your PRDs database), and Submission Date (created time, auto).
Set up a public or internal submission form
Click "New View" and select "Form." Customize the form to show only the fields you want submitters to fill in: Title, Description, Source, and Customer Name. Toggle off all other fields from the form view. Share the form link in your internal Slack pinned messages, in your customer-facing help center, and in your CS team's triage workflow. Submissions create new rows automatically in the database.
Configure triage views for the PM team
Create a Board view grouped by Status. Add a filter to show only rows where Status is "New" or "Under Review." This is your daily triage view — the PM opens it each morning and processes new submissions. Add a Table view sorted by Vote Count descending for weekly prioritization reviews. Create a Gallery view filtered to Status = "Planned" that shows the feature image, description, and expected quarter — this is your stakeholder-facing view.
Link feature requests to your PRD when you decide to build
When a feature request is approved, change Status to "Planned." Use the Linked PRD relation property to connect it to the PRD you create in Vantage or Notion. This creates bidirectional traceability: you can open a PRD and see which feature requests it addresses. Add a "Planned Quarter" date property to the request so customers and CS can track when to expect it.
Build an ARR-weighted priority view
Add a Formula property called "Priority Score" with the formula: prop("Vote Count") * 1 + prop("ARR Impact") * 2. This weights ARR-significant requests higher than pure vote counts. Create a sorted Table view by Priority Score descending. This view becomes your primary input for quarterly planning — feature requests that customers are paying for and that multiple users want rise to the top naturally.
Set up status notifications via Notion automations
In the database, click the lightning bolt icon to open Automations. Create a rule: When Status changes to "Planned," send an email notification to the requester's email address with the Planned Quarter. Create a second rule: When Status changes to "Shipped," send a notification with a link to the release notes. These automations close the loop with requesters without requiring manual follow-up.
Common mistakes
Accepting all feature requests without triage criteria
A feature request board that accepts everything is noise, not signal. Define triage criteria: requests must include a description of the problem (not just the solution), a customer name, and an ARR estimate. Requests that do not meet these criteria get moved to "Needs More Info" status, not "Under Review."
Not closing the loop with requesters
The biggest complaint about feature request systems is that requests disappear into a black hole. Set a 48-hour SLA for acknowledging new submissions and use Notion automations to notify requesters when status changes. Requesters who hear nothing do not submit again.
Treating vote count as the only prioritization signal
The most vocal users are not always your most valuable users. A feature requested by 5 enterprise customers worth $500K ARR outweighs 50 freemium users requesting the same thing. Always include ARR impact in your prioritization formula.
No connection between the request board and the roadmap
Without a relation to your PRD database, feature requests are a dead end. Engineers ship features that never get linked back to the requests that justified them. Always connect the Linked PRD when a request moves to Planned.
Tips
Add a Notion embed of the feature request board in your company's internal wiki so every team member knows where to submit requests
Use Notion's Group By property to create a view grouped by Source — this shows you whether most requests come from sales, support, or direct user feedback, which indicates where you need better user research
Set a quarterly goal: review and triage 100% of requests in the backlog — features that have been in "New" status for over 90 days should be declined or explicitly deferred
Export the Planned features view as a PDF for quarterly all-hands presentations to show what customer feedback is driving the roadmap
How Vantage helps
When you create a project in Vantage, you can import your Notion feature request database as a context source. Vantage reads the top-voted, highest-ARR requests and uses them to ground the PRD — ensuring that the requirements your engineering team builds trace back to actual customer demand, not internal assumptions.