Getting started
Public board (roadmap, voting, changelog)
The public board is the Canny-style, public-facing part of Usero. Turn it on and you get a page anyone can reach where they submit feature requests, upvote what others posted, and follow a roadmap of what you are building. You publish a changelog there to announce what shipped.
The board is separate from the rest of Usero. A board post is not the input that becomes an AI-authored pull request today; the PR pipeline runs off feedback from the widget, Slack, forms, GitHub issues, and the API. Treat the board as your public roadmap, not as the source of truth for what to build.
What it does
- Public submissions. Anyone reaches
usero.io/b/<slug>/submit, writes a request (a title and optional description, with an optional category and email), and it appears on the board. No account required. - Voting with no signup. Visitors upvote any post. Votes are deduped per browser (a long-lived
__portal_votercookie), so a count reflects distinct people rather than repeat clicks. Clicking the upvote again removes the vote. - Comments, with official replies. Each post has a comment thread anyone can join. A reply from your team is marked as official so it stands out.
- A roadmap. You move each post through statuses you control. The ones you flag as roadmap render as the public columns at
/roadmap. - A changelog. Announce what shipped at
/changelog. Entries are authored by you, not auto-generated. - Your own domain (Pro and Team). The board lives at
usero.io/b/<slug>by default; paid tiers let you point a custom domain at it.
Enable the board
- Open your project and go to the public board settings.
- Toggle the board on. Usero generates a board slug from your project name (you can change it; it must be unique). Your board is
now live at
usero.io/b/<slug>. - On first enable, Usero seeds a default set of statuses and categories (below) so the board works immediately. You can edit them afterwards.
That is the whole setup for the hosted URL. Pointing a custom domain at the board is a separate step covered below.
Statuses and the roadmap
Statuses are how you run the board. Each post sits in exactly one status, and you move it as work progresses. The seeded defaults are:
| Status | On the roadmap? | Meaning |
|---|---|---|
| Open | No | New, not yet triaged |
| Under Review | No | You are considering it |
| Planned | Yes | Committed, not started |
| In Progress | Yes | Being built now |
| Complete | Yes (done) | Shipped |
| Closed | No | Declined or a duplicate |
A status flagged as a roadmap status appears as a column on the public /roadmap view. By default that is Planned, In Progress,
and Complete, which gives a visitor the three-column "what is coming" picture they expect. You can add a status, rename one,
delete one, and change a post's status from the board settings.
Categories (Feature Request, Bug Report, Improvement, and so on) are a separate axis for tagging what a post is about. They are also seeded on first enable and fully editable.
Submissions, votes, and comments
- Submitting. The submit page asks for a title (5 to 200 characters), an optional description, an optional category, and an optional email. As the visitor types a title, the page shows similar existing posts so they can upvote instead of filing a duplicate.
- Voting. One click to upvote, one to remove it. The per-browser cookie is the dedup key, so the count is a reasonable proxy for distinct interested people. It is not login-gated, by design: the lower the bar, the more honest the count.
- Comments. Anyone can comment on a post. Your team's replies are marked official so users can tell an answer from the product team apart from community chatter. Use this to answer "why not" once, in public.
Changelog
The changelog at /changelog is where you announce shipped work. Entries have a type (feature, improvement, fix, or announcement)
and are published by your team from the changelog admin in your project. Marking a post Complete does not automatically create
a changelog entry; the two are separate so you control exactly what gets announced and how it is worded.
Custom domain (Pro and Team)
On the Pro and Team plans you can serve the board from your own domain instead of usero.io/b/<slug>:
- In the project settings, open the custom domain panel and enter the hostname you want (for example
feedback.yourapp.com). - Usero gives you a DNS record to add at your registrar. Add it, then return and let Usero verify it.
- Once the hostname is verified, your board is reachable on your domain. The board must be enabled and have a slug for the domain to resolve to it.
The custom domain is gated to the paid tiers. The free board uses the usero.io URL.
Where the board fits (and where it does not)
The board is the public roadmap. It is the right tool for showing users their request is logged, letting them vote, and closing the loop with a changelog. It is the wrong tool for deciding what to build on its own: most users never post on a board, so the vote count over-weights the vocal minority. Read it as one input among several, and get the quiet majority from the widget, support, and reaching out to users directly.
The board is also not connected to the AI-PR pipeline. Feedback that clusters and can open a GitHub pull request comes from the widget, Slack, forms, GitHub issues, and the API, not from board posts. See feedback clustering and the GitHub integration for that path.