Blog

Notion Feature Requests: Track Them Well or Move Them

Notion Feature Requests: Track Them Well or Move Them

Sketch of feature request cards and lanes

If you search for "Notion feature requests," you want one of two things. Either you want to ask Notion's team for a feature, or you want to use Notion to manage the requests your own customers send you. This guide covers the second job: how to set up a request database in Notion, where it stops working, and how to move your feedback to a purpose-built board when it does.

TL;DR

  • A Notion database with status, source, and an upvote formula is a workable feature request tracker for a small team and a small number of requesters.
  • Structure matters more than the tool: every request needs a problem statement, a proposed solution, and alternatives considered, the same fields GitHub's issue forms use.
  • Notion has no native public voting, no per-user vote limits, and no notification when a request ships. Those gaps are where homemade trackers usually stall.
  • When requesters outnumber your team, a hosted public board with voting, statuses, and a roadmap takes the manual work away. Migrating by CSV keeps your history.

Table of Contents

Two meanings of "Notion feature requests"

The first meaning is asking Notion for something. That is a support and community matter, and the best route is the help and feedback options inside the app, plus Notion's community forums, where a category exists for requesting missing features. A request lands better when it describes the job you are trying to do, not the button you wish existed.

The second meaning is the one most product managers mean: Notion as your own feedback system. Teams reach for it because they already live there. A database costs nothing extra, and it can be shaped any way you like. Plenty of ready-made options exist, including a customer feedback and feature request database template in Notion's own gallery, which frames the main pitfall well: feedback scattered across email and chat is close to useless until someone centralizes, structures, and prioritizes it.

The rest of this article is about that second meaning.

Set up a feature request database in Notion

Start with a single database, not a page of bullet lists. Every request is a row, and every row has the same properties. A minimal version that works:

PropertyTypeWhy it exists
TitleTitleOne sentence naming the problem, not the solution
StatusSelectNew, Under review, Planned, In progress, Shipped, Declined
SourceSelectSupport ticket, sales call, community, in-app, internal
RequesterText or relationWho asked, so you can follow up
Problem statementTextWhat the person is trying to do and what blocks them
Proposed solutionTextTheir idea, kept separate from the problem
Alternatives consideredTextWhat they do today instead
Upvoted byPersonRaw material for a vote count
Segment or planSelectLets you weigh a request by who sent it

The three text fields are borrowed on purpose. GitHub's documentation on issue templates explains that structured forms with specific fields encourage contributors to include the information maintainers need. The same logic holds for product feedback. A request that arrives as "add dark mode" tells you little. One that arrives with a problem, a workaround, and a proposed fix can be judged in a minute.

Keep statuses honest

Use a small set of statuses and define each in one line. "Under review" means someone on the team has read it and is gathering evidence. "Planned" means it is committed to a roadmap slot. If "Planned" just means "we liked it," people will read it as a promise, and you will spend your time apologizing. Our guide on stopping roadmap and backlog drift goes deeper on keeping the two lists separate.

Create views for the people who read it

A database is only as useful as its views. Three are enough to start:

  1. Triage: filter to status New, sorted by created date. This is the weekly inbox.
  2. By votes: filter out Shipped and Declined, sort by vote count descending.
  3. Shipped: filter to Shipped, grouped by month, which gives you raw material for release notes.

Add voting with an upvote formula

Notion has no vote button, but the community workaround is well documented. Notion's own guide on an upvote formula for team decisions describes adding a Person property and a formula that counts how many people are in it. Each teammate adds themselves to a request they back, and the formula gives you a number to sort on.

This works well for internal prioritization, for example when your support, sales, and success teams each flag the requests they hear most. It has real limits:

  • Only people with access to the workspace can vote, so customers are out unless you give them access.
  • Anyone who can edit can also remove other people's votes, by accident or otherwise.
  • A count of heads treats a free-tier hobbyist and your largest account as equal.

The third point is the one that matters most. Counting votes is only the start. A sensible score also includes who asked and how much the problem costs them. Our article on MoSCoW prioritization shows how to bring that evidence to a workshop instead of arguing from the loudest voice.

Collect requests from customers

Internal voting is the easy half. The harder half is getting customer requests into the database in the first place.

Notion's guide on building a website with Notion notes that you can publish a roadmap page and even let visitors submit feature requests by turning on public editing. Public editing is a blunt instrument, though. Think about what you are handing over before you switch it on: anyone with the link can change content, so moderation becomes your problem.

A safer pattern is a form. Embedding a third-party form on a Notion page sends submissions into your database without giving visitors edit rights. Pair it with a required field for the problem the person is trying to solve, and you get the same structured input you would ask of an internal teammate.

Two other intake channels are worth wiring in:

  • Support conversations. Agents should log a request in the database at the moment a customer mentions it, with a link to the ticket. Our set of feature request email templates gives support teams six ready replies that also ask for the context you need.
  • In-product prompts. Asking at the moment of friction beats asking in a quarterly survey. We cover that in feedback inside your app.

For a wider view of what to run continuously and what to run occasionally, see how teams collect user feedback through always-on channels and a periodic probe.

Let AI do the sorting

Notion's agents can take over some of the grunt work. One of the company's guides describes a multi-agent system that turns customer feedback into a monthly report: an intake agent spots feature requests in call recordings, an extractor pulls the exact customer quote, and a matcher checks whether the request already exists in your database. Another guide shows a Custom Agent that watches a feedback channel and files new bugs and feature requests as tasks, then drafts a weekly update from the same database.

AI agents sort feedback before human review

These are real time-savers for the internal side of the process. Treat the output as a draft, though. An agent can deduplicate and summarize, but it cannot decide that a request from a churning enterprise customer outweighs ten from free users. That call stays with a person.

Where a Notion tracker starts to strain

Most teams that outgrow a Notion tracker describe the same symptoms:

  • Duplicates pile up. Without a public list to check, ten customers ask for the same thing in ten different words, and each gets a new row.
  • Customers cannot see what happened. Nobody gets told when their request moves to Planned or Shipped, so the person who asked has no reason to ask again, or to stay.
  • Votes live in one place and context in another. Support tickets, call notes, and the database drift apart.
  • Maintenance becomes a job. Someone has to own the formulas, the views, the permissions, and the cleanup.

None of this makes Notion a bad tool. It is a flexible workspace, and a feedback board is a specific product with specific behavior: public posting, one vote per person, comments, status changes that notify followers. Building that on top of a database is possible, but you are building and maintaining software.

There is a broader caution too. Analysis of Notion's own product culture, from Cult.FYI, points to a habit of asking whether a feature is truly useful or just what customers say they want. Whatever tool you pick, a vote count is a signal to investigate, not an order to build.

Write a request template your submitters will use

Whether you stay in Notion or move elsewhere, publish short submission guidelines. People submit better ideas when they know what a good one looks like. Four lines are enough:

  1. Search first. Someone may have asked already, and you can add your vote.
  2. Describe the problem before the solution. What were you trying to do?
  3. Say how you handle it today. Workarounds reveal how painful the gap really is.
  4. One idea per post. Bundles are hard to vote on and impossible to ship halfway.

If your product is developer-facing and your code lives on GitHub, you can enforce the same structure with an issue form. Per GitHub's documentation, issue forms are written in YAML and stored in the .github/ISSUE_TEMPLATE folder of the repository, and they support text inputs, dropdowns, checkboxes, and file uploads. A feature request form needs just a few fields:

name: Feature request
description: Suggest an improvement
labels: ["enhancement"]
body:
  - type: textarea
    attributes:
      label: Problem statement
    validations:
      required: true
  - type: textarea
    attributes:
      label: Proposed solution
  - type: textarea
    attributes:
      label: Alternatives considered

That gives maintainers the three fields that make triage fast. For non-developer customers, a GitHub issue is the wrong front door. A public board with the same three questions is friendlier.

Our view: the tool matters less than the loop

We build a public feedback board, so you should know where we stand. We have watched teams run feedback out of spreadsheets, kanban boards, chat channels, and Notion databases, and the tool is rarely what fails. The loop fails. A request goes in, nothing visibly happens, and the customer stops sending ideas.

That is why we built Petĩra around three things: one place where ideas are posted and voted on, statuses that move from under review to planned, in progress, and shipped, and a public roadmap so people can see the result. Notion is excellent for the thinking that happens after the feedback is in: the specs, the research notes, the decision records. A board is better for the part where customers are involved.

Our advice is simple. If five people on your team are the only ones who ever touch the requests, keep them in Notion. If customers are the ones asking, give them a place built for it, and keep Notion for the work behind it.

— Aron

Moving feedback out of Notion or a card board

Fear of losing history is the usual reason teams stay put. It should not be. Both Notion databases and card-based kanban boards export to CSV, so the move is mostly a mapping exercise:

  1. Export. Download your database as CSV. For a card board, export the board or list to CSV or JSON.
  2. Clean. Merge obvious duplicates, and decide which statuses survive. Map Notion's custom statuses onto a small standard set.
  3. Map columns. Title, description, status, author, vote count, and created date are the fields that matter. Put the problem statement and alternatives into the description.
  4. Import. Upload the CSV into your new board and spot-check ten items.
  5. Announce. Tell requesters where the list lives now, and post the first status updates. This is where the old tracker's silence ends.

Petĩra imports from CSV, and also from Canny and Fider exports, so you can bring feedback along from several kinds of source. You can also export everything as JSON or CSV at any time, so you are never locked in.

Petĩra for teams ready to move

Petĩra is a hosted public feedback board: customers post ideas, vote, and comment, and you move each idea through under review, planned, in progress, and shipped on a public roadmap. It includes an embeddable widget, email notifications, moderation tools, private boards, custom domains, custom CSS, and Slack, Discord, and GitHub integrations.

Every plan includes unlimited users, ideas, and votes, and the price is flat instead of rising as more people participate. The Free plan costs €0 per month. Pro is €19 per month or €190 per year, and Team is €49 per month or €490 per year. You can see exactly what each tier unlocks on the pricing page, or look at the Petĩra homepage to see the board in action. If you are comparing the market first, we published a comparison of the pricing of 12 feedback tools.

Once requests start shipping, close the loop with release notes that put readers first and a roadmap structured as now, next, later.

FAQ

Can I use Notion as a public feature request board?

Yes, to a point. You can publish a page and, as Notion's website guide explains, allow visitors to submit requests by turning on public editing. You will have to handle moderation, duplicates, and vote counting yourself, because Notion does not provide one vote per person for outside visitors.

How do I count votes in a Notion database?

Add a Person property such as "Upvoted by" and a formula property that counts the people in it. Notion describes this setup in its upvote formula guide. Sort by the formula, and filter out answered or built items to keep the backlog clean.

What should a feature request template include?

A problem statement, a proposed solution, and the alternatives the person has tried. GitHub's issue template documentation shows how to make fields required so submissions arrive complete. Add the requester's plan or segment so you can weigh requests later.

How do I migrate feedback from Notion or a card board to another tool?

Export the database or board to CSV, clean up duplicates and statuses, then map the columns to the new tool's fields and import. Check a sample before you announce the move. Petĩra accepts CSV imports, so the same file works for either source.

Sources

Recommended