Scope Request
Features

Everything in the box

This is the whole product, not the top tier of it. Where a line below belongs to a particular licence, the pricing page says which. Where it does not, it is in every licence including the free one.

What it will not do

There are no surveys, no NPS scoring, no live chat and no help-desk agent. There is no SAML, because the people voting on your board are your customers rather than your staff. There is no hosted edition: the product is the thing you install.

A short honest list is more use than a long one. If one of those is what you are shopping for, this is not the tool.

Products and boards

One install, as many boards as you need

A product is a thing you take requests about, and it has its own hostname, its own branding, its own staff and its own statuses. The hostname is what decides which product a visitor is looking at, so several products on one install really are several separate boards.

  • Several products on one install, each on its own hostname, each with its own staff who cannot see another product's queue.
  • Several boards per product, for example Feature requests, Integrations and Bugs, each with its own settings and sort order.
  • Board visibility: public, signed-in members only, paying customers only by plan code from a connector, or staff only.
  • Categories per board, with a colour, which the person posting has to choose from.
  • Custom fields per board, such as a product version or a hosting plan, each required or optional and public or staff-only.
  • Your own logo, brand colour and custom CSS per product. The brand colour is mixed into the whole palette rather than painted on one button.
  • Board rules that have to be accepted before a first post, saying what you moderate and who owns an idea once it is posted.
  • British English and Spanish interface files, with a language tag per post and emails sent in the member's own language.
Posting and voting

The duplicate that is never posted

The single most useful thing on the board is the search that runs while the title is being typed. After three characters it shows the closest existing posts with a vote button on each, so the commonest outcome of somebody starting to type an idea is a vote on the idea that already exists.

Posting

  • Title, description in limited Markdown, board and category. No raw HTML is accepted anywhere.
  • Live search for similar posts as the title is typed, with a vote button instead of a post.
  • Up to three images, five megabytes each, re-encoded to WebP with the metadata stripped and released only when the post is.
  • An author edit window you set per product, after which only staff can edit, and every staff edit is kept as a revision.
  • Staff can post on behalf of a customer from a ticket, a call or an email, and the customer gets the updates.
  • Pin a post or a notice to the top of a board.

Voting

  • One vote per person per post, withdrawable, and a vote also follows the post for updates.
  • Verified email addresses only. There are no anonymous votes.
  • Staff can add a vote on behalf of a customer and record whether it came from a ticket, a call or a sales conversation.
  • Votes follow a merge. The sets combine as a union, so a person who voted on both duplicates is counted once.
  • An optional importance on each vote: nice to have, important or blocker.
  • An optional vote budget per board, so a person with ten open votes has to withdraw one before casting another.
  • Hide vote counts until a post reaches a threshold, show voters as initials, or hide the voter list entirely. Set per board.
Moderation

Nothing a member writes is public until it is released

That is the rule the software is built around, and there is a test in the suite whose only job is to fail if any route ever breaks it. Everything in this section follows from it.

The queue

  • Hold everything, hold people below the trust threshold, or hold nothing. Set per board and separately for posts and comments.
  • One triage inbox per product holding queued posts, queued comments and flags, with bulk actions.
  • Tidy a title or a description before approving it, keeping the original as a revision.
  • AI triage that suggests a spam score, likely duplicates and a category. It only ever suggests; a person decides, and a test in the suite fails if the triage code ever acts.

The outcomes

  • Approve, optionally with an official response.
  • Merge into an existing post. Votes, subscribers and comments move, and the old URL redirects.
  • Reject with a stock reason and a note. The author is told privately and nothing is published.
  • Move it to support, which sends the text to your support desk and takes the post off the board.
  • Mark it as spam, which drops the author's trust to zero.

Keeping it clean

  • Trust earned per product after a few approved posts, with licence holders trusted from the start if you want them to be.
  • Blocked words, email domains, link domains and IP addresses, each set to hold or to reject.
  • Ban, suspend or shadow-ban a person or a whole email domain, per product or everywhere.
  • Members can flag content, and enough flags hide an item until it is reviewed.
  • An audit log of every approve, reject, merge, edit, ban and status change.
  • Posts nobody has voted for in a year are archived automatically, and a single new vote brings one back.
Statuses, roadmap and changelog

One set of statuses, three views of it

Under review, Planned, In progress, Released and Declined are seeded when you create a product. Each has a colour, each is public or private, and each is open or closed to votes. The roadmap is built from them, so there is no second list to keep in step.

Statuses

  • Add your own, in your own order, with your own colours.
  • A status change can carry a note, which is shown on the post and emailed to everyone following it.
  • Declined shows its reason, closes voting and drops off the main list after a month while staying reachable by search and by link.
  • A staff owner, a target quarter that can be public or private, and an effort size.
  • Links to a GitHub issue or pull request and a version number, staff-only by default.

Roadmap

  • Planned, In progress and Recently released, built automatically from the statuses and their roadmap column.
  • Filter by category, and mark an item as not on the roadmap so it stays internal.
  • A timeline view placing items by target quarter.
  • A roadmap for a single category, embeddable on a page of your own, with an allow list of origins per product. An empty list means nobody.

Changelog

  • Entries with a version, a date, New, Improved and Fixed labels, and their own public URL.
  • Link an entry to the posts it closes: they go to Released and every voter, commenter and subscriber is emailed the entry.
  • Subscribe by email with double opt-in, plus RSS and Atom feeds per product.
  • Write an entry now and have it published on release day.
  • A what's-new panel inside WordPress showing entries since the reader's last visit.
Telling people

Email that behaves like email should

Everything the board sends is an operational notice about something the recipient asked to hear about, it carries a one-click unsubscribe and a List-Unsubscribe header, and it is batched to at most one message per person per post per hour.

  • Members are told when a post is approved or rejected, when its status changes, when a staff member replies officially, when it is merged and when it ships.
  • Digest mode, so a person can choose one weekly summary instead of messages as things happen.
  • A preferences page per person, and follow or unfollow on any post.
  • Staff alerts when something enters the queue, plus a daily summary to each product's moderators carrying the queue counts and the age of the oldest thing waiting.
  • Chat alerts to Slack, Teams or Telegram. A Telegram token is encrypted at rest, masked on the screen and scrubbed out of the delivery log, because it travels in the URL.
  • Outgoing webhooks for post created, approved, status changed and merged, comment created and changelog published. HMAC-signed, retried with back-off, and no payload ever carries an email address.
  • Safe mode is on until you turn it off, with an allow list of addresses that may be written to. A copy of a live install can email nobody by accident.
  • Any SMTP or API mail service, set on a screen. There are no mail settings in a configuration file at all, deliberately, so nothing can quietly override the screen.
Identity

Members and staff are two different systems

A member's cookie cannot open an admin page, because members and staff do not share a login. Members get magic links and no password at all; staff get a passkey or a password with an authenticator app.

Members

  • Sign up with an email address and a magic link. Single use, short lived, and bound to the browser that asked for it.
  • A display name of their choosing. Their email address is never shown to anybody.
  • One-click sign-in from your own application through a signed hand-off: a token good for sixty seconds, used once.
  • Arriving through a connector with a paying plan code can make somebody trusted immediately.
  • Export everything held about them, and close their account. Posts stay as "Former member" because other people replied to them; votes are deleted.

Staff

  • Board admin, moderator and read-only, set per product. A moderator of one product gets a 404 on another's held items, not a 403.
  • Passkeys, or a password with an authenticator app and recovery codes.
  • Internal notes on a post that are never shown publicly, with staff @mentions.
  • Customer context beside a voter: company, plan, MRR and customer age, fetched through a connector and cached for an hour.
  • Every setting lives on a screen. Configuration files hold shipped defaults only, and a test in the suite fails if a setting an operator would want ever moves into one.
Deciding what to build

Admin, reports and getting the data out

A list sorted by raw votes tells you what the loudest people want. These are the tools for working out what the people paying you want, and for taking the whole lot elsewhere if you ever decide to.

  • A prioritisation view sorted by votes, weighted votes, the MRR behind a post, the number of paying voters, trend or effort, with an optional RICE score.
  • Saved views, so "agency-tier requests with ten or more votes" is one click rather than four filters.
  • Reports: new posts per month, time to first response, time in review, and the top requests broken down by licence class.
  • CSV export of posts, votes and comments, and CSV import to get an existing board in.
  • A REST API reading public posts, the roadmap and the changelog, and writing posts, votes on behalf and status changes with a staff key. Keys are stored hashed.
  • Sort by trending, top, newest or recently updated, and filter by status, category, my posts and my votes.
  • Full-text search across titles, descriptions and official replies, using the database's own index rather than a separate service.
  • A sitemap and canonical URLs for the public pages, with private boards and held items sending noindex.
Connecting it up

Two seams, and everything is built on them

There is one REST API and one sign-in hand-off. The WordPress plugin uses nothing a licensee could not use, which is the point: whatever you have written can connect the same way.

Signed hand-off

Your app signs a token with a secret from the board's admin screens. Sixty seconds, single use, carrying an email address, a display name, your own customer id and optionally a plan code.

Customer context

The board calls a lookup URL of yours with a member's external id and gets back company, plan, MRR and customer-since. Cached for an hour, shown to staff only.

WordPress plugin

A free plugin that adds a Feedback page to wp-admin: the top open requests, a what's-new count and one-click sign-in for the logged-in user.

GitHub and the widget

Follow a linked issue's state, with the issue always authoritative and nothing ever written back. And an embeddable widget, limited to an origin list you keep.

Privacy and security

Strangers can write to it, so everything they send is treated as hostile

On your install you are the data controller, and we are not a processor at all, because nothing a member writes ever reaches us. These are the controls that come with it.

  • No third-party scripts, fonts or analytics on public board pages, so there is nothing to put in a cookie banner beyond the session cookie.
  • Markdown rendered server-side through a sanitiser with a small allow list. No raw HTML, and links only for trusted members.
  • Images re-encoded to WebP with metadata stripped and a size cap. SVG is never accepted.
  • Every query scoped to one product, with tests that prove a moderator of one cannot reach another's content.
  • Retention you set: rejected and spam items purged, IP addresses kept only as long as abuse handling needs them.
  • Self-service export and account closure for every member, without anybody having to open a ticket.
  • Held, rejected and spam posts return 404 to everyone except their author and staff, rather than a 403 that confirms they exist.
  • Votes are idempotent, so a double click can never count twice, and every form carries a CSRF token.

None of it is an upgrade away

The free licence has the whole moderation system, the roadmap and the changelog. What the paid licences add is scale, the connectors and the things that read your billing.