Customer Feedback & Feature Requests

Category Description

Customer feedback and feature request software gives software teams a structured way to collect, organize, and prioritize input from end users about what to build next. Instead of feedback scattering across support tickets, emails, and chat messages, the software centralizes it into a voteable board where users can submit ideas, upvote existing requests, and discuss priorities. Product teams can then triage, tag, and link this input to their roadmap, close the loop with users when a request ships, and communicate upcoming work through a public changelog. The core value proposition is replacing the "loudest voice wins" dynamic with a signal that reflects actual user demand.

Example Implementations

Canny
UserVoice
Nolt

Target Audience

The primary users of this category are product managers and product teams at B2B SaaS companies, typically ranging from early-stage startups to mid-market businesses. Two distinct roles interact with the software: internal team members (product managers, customer success reps, engineers) who manage and triage feedback, and external end users (customers) who submit and vote on requests. The typical deployment is a public or semi-public portal embedded in or linked from the product, alongside an internal workspace where the team acts on what they've collected.

Core Requirements

Feedback submission: Users must be able to submit a new feedback post containing at minimum a title and a description. Submission must be possible via a public-facing portal (a standalone URL). Internal team members must also be able to submit posts on behalf of users (vote-on-behalf / submit-on-behalf).
Upvoting: Any authenticated user must be able to upvote an existing post. Each user may cast only one vote per post. Vote counts must be visible on the post and on the list view. Team members must be able to add a vote on behalf of a named user or customer.
Post status management: Team members must be able to assign a status to each post (e.g., Under Review, Planned, In Progress, Complete, Declined) and update it over time. Available statuses must be configurable by the team.
Voter notifications: When a post's status changes, all users who have voted on or submitted that post must receive an automated notification (at minimum, via email) informing them of the update.
Feedback boards: The product must support organizing posts into multiple named boards (e.g., one board for feature requests, one for bug reports). Each board must be independently viewable and navigable.
Post detail page: Each post must have a dedicated detail page showing the title, description, current status, vote count, list of comments, and the original submitter's identity (or "Anonymous" if anonymized).
Commenting: Authenticated users must be able to post comments on a feedback post. Team members must be able to post internal-only comments visible only to other team members (not to external users).
Tagging and categorization: Team members must be able to apply one or more tags or labels to a post for organizational and filtering purposes. Tags must be user-defined (not a fixed set).
Post search and filtering: The feedback board must support searching posts by keyword and filtering by status, tag, and date. Results must update in real time or on submission without a full page reload.
Duplicate detection / merging: Team members must be able to manually merge two posts that represent the same underlying request. When posts are merged, votes from both posts must be combined into the surviving post, and voters on the merged post must be associated with the surviving post for future notifications.
Public roadmap: The product must include a view — accessible to external users without login — that displays posts or roadmap items grouped by status (e.g., Planned, In Progress, Shipped). The roadmap must be linkable via a standalone URL.
Changelog / release notes: The product must include a publicly accessible changelog where team members can publish entries announcing completed work. Each entry must support a title, rich-text body, and publication date. Changelog entries must be linkable to one or more feedback posts that prompted the work.
Embeddable widget: The product must provide an embeddable widget (e.g., a script tag or iframe) that can be placed within a third-party web application, allowing users to submit feedback and browse posts without leaving the host application.
User identity and SSO: The product must support single sign-on so that authenticated users of the host application can be passed into the feedback tool without re-authenticating. At minimum, JWT-based identity passing must be supported. Users must appear in the feedback tool with their name and email as provided by the host application.
Admin reporting: Team members must be able to view an activity summary showing, at minimum: number of new posts submitted, number of votes cast, and most-requested posts by vote count, filterable by date range.
Post ownership assignment: Team members must be able to assign a post to a specific internal team member as the owner responsible for following up on it.
User-linked feedback: Team members must be able to view all posts and votes associated with a specific user or customer account, so they can understand a given customer's full list of outstanding requests.
Privacy controls: Team members must be able to configure individual boards as public (visible to anyone), private (visible only to authenticated users of the host application), or internal (visible only to team members). Posts on a private or internal board must not be indexed or accessible without authentication.

Cross-Cutting Requirements

Multi-tenancy: The application must support multiple independent organizations (tenants), each with isolated data.
Authentication: Users must authenticate with email/password at minimum. SSO and OAuth are not required.
Role-based authorization: The application must support at least three roles — administrator, manager, and standard user — with distinct permission levels appropriate to the category.
Data persistence: All user data must be persisted across sessions in a database.
Web application: The application must be accessible via a web browser. Native desktop or mobile applications are not required.
Concurrent users: The application must support multiple users within the same tenant using the application simultaneously without data corruption or loss.
Responsive design: The web application must be usable on both desktop and mobile browsers. A native mobile app is not required.

Scope Boundaries

AI-assisted feedback capture (Autopilot-style) is not required. Automatically ingesting feedback from Intercom, Zendesk, Zoom call transcripts, or Gong and converting it to posts is a premium feature not offered by all products in this category.
AI-generated summaries and impact reports are not required. Summarizing a post's comments or producing an AI-generated "impact report" for a feature request is a premium add-on.
Project management integrations (Jira, Linear, Asana, ClickUp, GitHub Issues) are not required. The ability to push a feedback post to an external issue tracker as a linked task is a paid-tier feature on most products in this category.
CRM integrations (Salesforce, HubSpot) are not required. Syncing user or account data from a CRM into the feedback tool is an enterprise-tier feature.
Revenue-weighted prioritization is not required. Weighting votes by MRR, ARR, or customer tier requires integration with billing or CRM data and is not a standard feature.
Custom scoring frameworks (RICE, ICE, MoSCoW) are not required. Structured prioritization scoring beyond vote count is an advanced feature found in higher-tier or adjacent products.
User segmentation is not required. The ability to filter feedback by user attributes such as plan type, company size, or custom properties is a paid-tier feature.
NPS or CSAT surveys are not required. Satisfaction scoring surveys are a distinct category of feature not universally offered in feedback/feature request tools.
Zapier / Make / automation integrations are not required. Workflow automation hooks beyond native integrations are not table stakes.
White-label / remove branding is not required. The ability to remove the tool's own branding from the portal is an enterprise upsell on all products in this category.
Custom domain is not required for base functionality. Hosting the feedback portal at the customer's own subdomain (e.g., feedback.acme.com) is a paid feature on most products.
Anonymous voting (without login) is not required. Most products in the category require users to authenticate before voting; anonymous voting is an optional board-level setting.
Downvoting is not required. The ability to vote against a post is optional and disabled by default in most products.
Native mobile app is not required. All products in this category are web-first.
Audit log / activity history is not required. A full log of admin actions for compliance purposes is an enterprise feature.
Invoicing or payment by invoice is not required. This is an enterprise billing feature, not a product feature.
Multi-language / localization of the user-facing portal is not required. Translating the portal UI into non-English languages is not universally supported.
API access is not required for the core spec. A developer-accessible REST or GraphQL API for programmatic management of posts and users is a paid-tier feature on most products.

Spec Metadata

Version: 1.0
Created: 2026-03-15
Last Updated: 2026-03-15
Status: Draft