# Quackback

> Quackback is an open-source, self-hostable customer feedback platform. Collect feature requests, build a public roadmap, publish changelogs, and let AI agents triage feedback via MCP.

- License: AGPL-3.0 (source-available)
- Self-hostable with Docker or manual install
- Free to use, no user limits
- AI-native: built-in MCP server for agent access
- GitHub: https://github.com/QuackbackIO/quackback

## Documentation

### Getting Started

- [Core Concepts](https://quackback.io/docs/getting-started/concepts): Understand workspaces, boards, posts, statuses, and user roles.

# Core Concepts

Here's how the pieces fit together. Understanding these five concepts is enough to get started.

## Workspaces

A **workspace** is your Quackback instance: the container for all your boards, posts, team members, and settings. Each self-hosted deployment is a single workspace.

## Boards

**Boards** keep different types of feedback organized. Common examples: "Feature Requests", "Bug Reports", "Integrations".

Each board has a name, URL slug (e.g., `/b/feature-requests`), and a public/private visibility toggle.

[Learn more about boards](/docs/admin/boards)

## Posts

A **post** is a single piece of feedback: an idea, request, or bug report. Posts belong to a board and include a title, description, status, tags, votes, and comments.

Posts move through your workflow as your team triages them:

```
Open → Under Review → Planned → In Progress → Complete
  │
  └──→ Closed
```

When a post's status changes, subscribed users are notified automatically.

## Statuses

**Statuses** show users what's happening with their feedback. They're organized into three categories:

| Category | Default Statuses | Purpose |
|----------|-----------------|---------|
| **Active** | Open, Under Review, Planned, In Progress | Posts that need attention or are being worked on |
| **Complete** | Complete | Posts that have been addressed |
| **Closed** | Closed | Posts that won't be implemented |

You can [create custom statuses](/docs/admin/statuses) like "In Design", "In Beta", or "Blocked" to match your workflow.

## Users & Roles

Quackback has two types of accounts with three roles:

| Capability | Portal User | Member | Admin |
|------------|:-----------:|:------:|:-----:|
| Submit feedback, vote, comment | ✓ | ✓ | ✓ |
| View admin dashboard | | ✓ | ✓ |
| Manage feedback & statuses | | ✓ | ✓ |
| Workspace settings & integrations | | | ✓ |

**Portal users** are your customers. They sign up through the public portal. **Team members** are invited by admins and access the admin dashboard.

## More to Explore

Once you're up and running, these features help you get more out of Quackback:

- **[Tags](/docs/admin/tags)**: Label posts across boards by platform, priority, or team
- **[Roadmaps](/docs/admin/roadmap)**: Show users what's planned, in progress, and shipped
- **[Voting](/docs/users/voting)**: Let users prioritize what matters most
- **[Comments](/docs/users/comments)**: Threaded discussions with official team responses
- **[Changelog](/docs/getting-started/introduction#changelog)**: Announce shipped features and close the feedback loop
- **[API & Webhooks](/docs/api/introduction)**: Automate workflows and build custom integrations
- **[Integrations](/docs/integrations/overview)**: Connect to Slack, Linear, and more

## Next Steps

- [Quick Start](/docs/getting-started/quick-start): Get Quackback running
- [Organize feedback with boards](/docs/admin/boards): Set up your first boards
- [Deploy with Docker](/docs/self-hosting/docker): Production deployment

- [Introduction](https://quackback.io/docs/getting-started/introduction): Collect, organize, and act on user feedback with Quackback, the open-source feedback platform you can self-host.

# Introduction

Stop losing feedback across emails, Slack, and support tickets.

Quackback brings user requests, votes, and discussions into one place so you can see what users actually want and show them what you're building.

And it's open source. Run it on your own servers, own your data, and customize everything.

## Why Quackback?

Feedback is everywhere: support tickets, emails, tweets, Slack messages, spreadsheets. Your team wastes time hunting for it, and good ideas slip through the cracks.

Quackback gives you a single source of truth. Users submit feedback through a clean portal. Your team triages it in one place. Everyone sees what's planned and what's shipped.

**For your users:**
- Submit feedback through a branded portal
- Vote on ideas they care about
- Track progress on the public roadmap
- Get notified when their requests ship

**For your team:**
- Triage feedback in a unified inbox
- Organize with boards, tags, and statuses
- Plan releases with drag-and-drop roadmaps
- Automate workflows with webhooks and the REST API
- Connect to Slack and other tools

## Key Features

### Feedback Boards

Keep feature requests separate from bug reports. Create boards for different types of feedback. Each can be public or private.

### Voting & Prioritization

Let users vote on what matters most. Sort by popularity, trending, or recency to see what's in demand.

### Custom Statuses

Your workflow isn't one-size-fits-all. Create statuses like "In Design", "In Beta", or "Blocked" to match how your team actually works.

### Public Roadmap

Show users what's coming. They can see what's planned, in progress, and shipped, and follow updates on features they voted for.

### Changelog

Announce what you've shipped. Link changelog entries to the posts that inspired them so users can see their feedback turned into features.

### REST API & API Keys

Automate your feedback workflow with a full [REST API](/docs/api/introduction). Create API keys to authenticate external integrations, then build custom workflows, sync data to your issue tracker, or power internal dashboards.

### Webhooks

Get real-time HTTP notifications when things happen - new posts, status changes, comments. Filter by board, verify with HMAC-SHA256 signatures, and connect to any system.

### AI Agent Support (MCP)

Quackback includes a [Model Context Protocol](https://modelcontextprotocol.io) (MCP) server, so AI coding agents like Claude Code can search feedback, triage posts, update statuses, and create changelog entries directly.

### Help Center

Build a searchable knowledge base on its own subdomain or custom domain. Organize articles by category, publish when ready, and let users find answers with AI-powered semantic search. Available as an [experimental feature](/docs/help-center/setup).

### Embeddable Widget

Collect feedback without users leaving your app. Drop a script tag into your site and a feedback button appears — users can browse, search, vote, and submit posts from an in-app panel.

### Integrations

Connect Quackback to your existing tools. [Integrations](/docs/integrations/overview) are available out of the box:

| Category | Integrations |
|----------|-------------|
| **Notifications** | Slack, Discord, Email, Microsoft Teams |
| **Issue Trackers** | Linear, GitHub, Jira, GitLab, Asana, ClickUp, Monday, Trello, Notion, Shortcut, Azure DevOps |
| **CRM & Enrichment** | HubSpot, Intercom, Zendesk, Salesforce, Freshdesk, Stripe, Segment |
| **Automation** | Zapier, Make, n8n, Webhooks |
| **AI Agents** | REST API, MCP Server |

### Self-Hosted

Run Quackback on your own infrastructure. Your data stays with you. No third-party access, no vendor lock-in.

## How It's Built

Quackback uses modern, open-source technologies:

| Layer | Technology |
|-------|------------|
| Framework | TanStack Start + TanStack Router |
| Database | PostgreSQL + Drizzle ORM |
| Auth | Better Auth with email OTP + OAuth |
| Runtime | Bun |
| Styling | Tailwind CSS + shadcn/ui |
| IDs | TypeIDs (branded, sortable UUIDs) |

## License

Quackback is licensed under [AGPL-3.0](https://www.gnu.org/licenses/agpl-3.0.html). You can use it freely, self-host it, and modify it. If you distribute a modified version, you must share your changes under the same license.

## Next Steps

- [Quick Start](/docs/getting-started/quick-start) - Get Quackback running in 5 minutes
- [Core Concepts](/docs/getting-started/concepts) - Understand boards, posts, and statuses
- [Self-Hosting Guide](/docs/self-hosting/docker) - Deploy on your own infrastructure

- [Quick Start](https://quackback.io/docs/getting-started/quick-start): Get Quackback running in under 5 minutes with Docker.

# Quick Start

Ready to try Quackback? You'll have it running in under 5 minutes.

## Prerequisites

- [Bun](https://bun.sh) (v1.3.7+) and Docker with Docker Compose installed
- A domain or subdomain (for production)

## One-Command Setup

```bash
# Clone the repository
git clone https://github.com/quackbackio/quackback.git
cd quackback

# Run setup (starts Docker services, installs deps, runs migrations)
bun run setup

# (Optional) Seed demo data (~500 posts, sample boards, statuses)
bun run db:seed
```

Then start the dev server:

```bash
bun run dev
```

Quackback is now running at [http://localhost:3000](http://localhost:3000).

## First-Time Setup

1. **Open the app** - Navigate to `http://localhost:3000`
2. **Complete onboarding** - Follow the setup wizard to create your account (name, email, password), configure your workspace name, and create your first board
3. **Sign in** - If you ran `bun run db:seed`, use `demo@example.com` with password `password`
4. **Explore** - If seeded, the demo data includes sample boards, posts, and statuses

## Environment Configuration

Edit `.env` with your settings:

```bash
# Required
DATABASE_URL="postgresql://postgres:password@localhost:5432/quackback"
SECRET_KEY=""
BASE_URL="http://localhost:3000"
REDIS_URL="redis://localhost:6379"

# Email (optional - emails print to console if not configured)
EMAIL_SMTP_HOST="smtp.example.com"
EMAIL_SMTP_PORT="587"
EMAIL_SMTP_USER="your-smtp-user"
EMAIL_SMTP_PASS="your-smtp-password"
```

Generate a secure secret (note: `bun run setup` auto-generates this for you):

```bash
openssl rand -base64 32
```

## What's Next?

### Configure for Production

For production deployments, you'll need to:

1. Set up a proper domain with HTTPS
2. Configure email delivery (SMTP or Resend)
3. Set a strong `SECRET_KEY`
4. Use a managed PostgreSQL database

See the [Docker Deployment Guide](/docs/self-hosting/docker) for complete instructions.

### Explore the Platform

- **Create a board** - Go to Admin → Settings → Boards
- **Invite your team** - Go to Admin → Settings → Team
- **Customize branding** - Go to Admin → Settings → Branding
- **Connect Slack** - Go to Admin → Settings → Integrations

### Import Existing Feedback

Migrating from another platform? Quackback supports CSV import:

1. Go to Admin → Settings → Boards
2. Select a board
3. Click "Import from CSV"

See [Import & Export](/docs/admin/import-export) for format details.

## Troubleshooting

### Port 3000 already in use

```bash
# Find and kill the process
lsof -i :3000
kill -9 
```

### Database connection failed

Ensure PostgreSQL is running:

```bash
docker compose ps
# Should show postgres container as "healthy"
```

### Emails not sending

## Getting Help

- [GitHub Issues](https://github.com/quackbackio/quackback/issues) - Bug reports and feature requests
- [GitHub Discussions](https://github.com/quackbackio/quackback/discussions) - Questions and community support


### Self Hosting

- [Declarative configuration](https://quackback.io/docs/self-hosting/config-file): Manage workspace settings as code with a config file and lock them from UI edits.

# Declarative configuration

Keep workspace settings in version control instead of clicking through the dashboard. Quackback reads an optional config file on startup and whenever it changes, reconciles its values into your workspace, and locks those fields from in-app edits.

## How it works

Quackback watches `/etc/quackback/config.yaml`. When the file is present:

- Every value it declares is **reconciled** into the workspace settings.
- Those fields become **read-only in the dashboard** — the UI shows them with a "Managed" badge and rejects writes.
- Any field the file *doesn't* declare stays freely editable.

Edit the file and Quackback re-reconciles automatically. Remove a field and that setting becomes editable again.

## File format

The file is a Kubernetes-style manifest:

```yaml
apiVersion: quackback.io/v1
kind: QuackbackConfig
metadata:
  source: ops-repo            # optional, free-form label
spec:
  workspace:
    name: Acme Feedback
    slug: acme
    useCase: saas             # saas | consumer | marketplace | internal
  state: active               # active | suspended | deleting
  auth:
    openSignup: false
    oauth:
      password: true
      google: true
      github: false
    ssoOidc:
      enabled: true
      discoveryUrl: https://your-org.okta.com/.well-known/openid-configuration
      clientId: 0oa1example
      autoCreateUsers: true
  features:
    helpCenter: true
  tierLimits:
    maxBoards: 10
    maxPosts: null            # null means unlimited
    features:
      webhooks: true
      customCss: false
```

`apiVersion`, `kind`, and `spec` are required. Everything inside `spec` is optional — declare only what you want to manage.

## Schema reference

### `spec.workspace`

| Field | Type | Notes |
|-------|------|-------|
| `name` | string | Workspace display name. |
| `slug` | string | Lowercase letters, digits, and hyphens. |
| `useCase` | enum | `saas`, `consumer`, `marketplace`, or `internal`. |

### `spec.state`

| Value | Effect |
|-------|--------|
| `active` | Normal operation (the default when omitted). |
| `suspended` | The workspace is read-blocked until the state changes. |
| `deleting` | The workspace is being torn down and rejects writes. |

### `spec.auth`

| Field | Type | Notes |
|-------|------|-------|
| `openSignup` | boolean | Allow new users to self-register. |
| `oauth.password` | boolean | Password sign-in. |
| `oauth.google` | boolean | Google sign-in (client secret set in the dashboard). |
| `oauth.github` | boolean | GitHub sign-in (client secret set in the dashboard). |
| `ssoOidc.enabled` | boolean | Turn the SSO connection on. |
| `ssoOidc.discoveryUrl` | https URL | The IdP's `/.well-known/openid-configuration`. |
| `ssoOidc.clientId` | string | The OIDC client ID. |
| `ssoOidc.autoCreateUsers` | boolean | Just-in-time provisioning on first SSO sign-in. Defaults to `true`. |

### `spec.features`

A map of feature-flag names to booleans. Each key locks one flag while leaving the others UI-toggleable.

### `spec.tierLimits`

Numeric limits — `null` means unlimited. Partial objects are allowed; the file only needs the limits it wants to lock.

| Field | Type |
|-------|------|
| `maxBoards`, `maxPosts`, `maxTeamSeats` | integer or `null` |
| `aiTokensPerMonth` | integer or `null` |
| `apiRequestsPerMonth`, `apiRequestsPerMinute` | integer or `null` |
| `features` | map of capability flags to booleans (`webhooks`, `mcpServer`, `customDomain`, `customCss`, and others) |

## Mount the file

With Docker, mount your config into the container:

```yaml
services:
  quackback:
    volumes:
      - ./quackback-config.yaml:/etc/quackback/config.yaml:ro
```

For a manual install, place the file at `/etc/quackback/config.yaml` and make sure the Quackback process can read it.

## Next steps

- [Deploy with Docker](/docs/self-hosting/docker) — Docker Compose setup
- [Environment variables](/docs/reference/environment-variables) — runtime configuration
- [Set up single sign-on](/docs/auth/sso) — the SSO connection this file can manage

- [Deploy with Docker](https://quackback.io/docs/self-hosting/docker): Deploy Quackback with Docker and Docker Compose.

# Deploy with Docker

The fastest way to get Quackback into production. Docker handles dependencies, database setup, and migrations automatically.

## Prerequisites

- Docker Engine 20.10+
- Docker Compose v2+
- 1 GB RAM minimum (2 GB recommended)
- PostgreSQL 18+ (included in the compose stack, or bring your own)

## Quick Deploy

### Use Docker Compose (recommended)

`docker-compose.prod.yml` is a self-contained, single-host stack: the Quackback app plus PostgreSQL, Dragonfly (Redis), and MinIO (S3-compatible storage). The app is the only service with a published port; the datastores stay on the internal network and the upload bucket is private.

```bash
# Clone the repository (the Postgres image is built locally for pg_cron + pgvector)
git clone https://github.com/QuackbackIO/quackback.git
cd quackback

# Create your environment file and fill in every value
cp .env.prod.example .env
# Generate secrets with: openssl rand -base64 32

# Start the stack
docker compose -f docker-compose.prod.yml up -d
```

Open `http://localhost:3000` (or your `BASE_URL` behind a reverse proxy).

### Use Docker Run (bring your own datastores)

If you already run managed PostgreSQL, Redis, and S3, run the app container on its own:

```bash
docker run -d \
  --name quackback \
  -p 3000:3000 \
  -e DATABASE_URL="postgresql://user:pass@host:5432/quackback" \
  -e REDIS_URL="redis://your-redis-host:6379" \
  -e SECRET_KEY="your-32-char-secret" \
  -e BASE_URL="https://feedback.yourcompany.com" \
  ghcr.io/quackbackio/quackback:latest
```

## How the Docker Image Works

The Quackback Docker image uses a multi-stage build:

- **Builder stage** compiles the application and installs dependencies
- **Production stage** runs as a non-root `quackback` user for security
- **Entrypoint** (`docker-entrypoint.sh`) runs database migrations automatically on every startup, then starts the server
- **Optional seeding** with `SEED_DATABASE=true` to populate demo data
- **Health endpoint** at `/api/health`

## Configuration

With the compose stack you set everything in `.env` (copied from `.env.prod.example`). The compose file derives the internal connection strings (`DATABASE_URL`, `REDIS_URL`, `S3_*`) from your secrets and wires them to the bundled services automatically — so you only provide the secrets, not the URLs.

### Required

```bash
# Public URL (must match your domain)
BASE_URL=https://feedback.yourcompany.com

# Auth/encryption key — generate with: openssl rand -base64 32
SECRET_KEY=

# Bundled PostgreSQL
POSTGRES_USER=quackback
POSTGRES_PASSWORD=
POSTGRES_DB=quackback

# Bundled MinIO (also used as the S3 access key / secret)
MINIO_ROOT_USER=quackback
MINIO_ROOT_PASSWORD=
S3_BUCKET=quackback
S3_REGION=us-east-1

# Image tag to run (pin to a release in production)
QUACKBACK_TAG=latest
```

### Email

**SMTP (recommended)**
```bash
EMAIL_SMTP_HOST=smtp.example.com
EMAIL_SMTP_PORT=587
EMAIL_SMTP_USER=your-username
EMAIL_SMTP_PASS=your-password
EMAIL_FROM=Quackback <feedback@yourcompany.com>
```

**Resend**
```bash
EMAIL_RESEND_API_KEY=re_xxxxxxxxxxxx
EMAIL_FROM=Quackback <feedback@yourcompany.com>
```

### OAuth providers & integrations (optional)

OAuth providers (GitHub, Google, Discord, etc.) and integrations (Slack, etc.) are configured in the admin UI under **Settings → Authentication / Integrations**. See the [Environment Variables Reference](/docs/reference/environment-variables) for the full list.

## Object Storage

The bundled MinIO has no public port, so uploads are served through the app's `/api/storage` proxy (`S3_PROXY=true` is set for you in the compose file). To use an external S3 provider (AWS S3, Cloudflare R2, Backblaze B2) instead, point `S3_*` at your provider and remove the `minio` and `minio-init` services from the compose file.

## Database

### Use the bundled PostgreSQL

The compose stack builds a PostgreSQL 18 image with the required extensions (`pgvector`, `pg_cron`) and runs migrations automatically on startup.

### Use an external database

For managed databases (AWS RDS, Supabase, etc.):

1. Create a PostgreSQL 18+ database
2. Enable the `pgvector` extension (and `pg_cron` if you want scheduled analytics refreshes)
3. Point `DATABASE_URL` at it (via the Docker Run path, or by editing the compose file)

Migrations run automatically when the container starts. To run them manually:

```bash
docker run --rm \
  -e DATABASE_URL="your-external-db-url" \
  ghcr.io/quackbackio/quackback:latest \
  bun /app/migrate.mjs
```

## Reverse Proxy

In production, place a reverse proxy in front of Quackback for HTTPS. See the [Reverse Proxy Configuration](/docs/self-hosting/reverse-proxy) guide for Caddy, Nginx, and Traefik examples.

## Upgrade

```bash
# 1. Back up your database
docker compose -f docker-compose.prod.yml exec postgres \
  pg_dump -Fc -U "$POSTGRES_USER" "$POSTGRES_DB" > backup-$(date +%Y%m%d).dump

# 2. Pull the latest source + image (bump QUACKBACK_TAG in .env to pin a version)
git pull
docker compose -f docker-compose.prod.yml pull

# 3. Restart (migrations run automatically)
docker compose -f docker-compose.prod.yml up -d
```

Drizzle migrations are sequential and safe to re-run, so the container handles schema updates on startup without any manual steps.

### Rollback

```bash
# Stop containers
docker compose -f docker-compose.prod.yml down

# Restore the backup
docker compose -f docker-compose.prod.yml up -d postgres
docker compose -f docker-compose.prod.yml exec -T postgres \
  pg_restore -U "$POSTGRES_USER" -d "$POSTGRES_DB" --clean < backup-YYYYMMDD.dump

# Start the previous image (set QUACKBACK_TAG to the old version in .env first)
docker compose -f docker-compose.prod.yml up -d
```

## Health Checks

```bash
# Application health
curl http://localhost:3000/api/health
```

## Troubleshooting

### Containers start but the app isn't reachable

Make sure you used `docker-compose.prod.yml`. A bare `docker compose up -d` uses the root `docker-compose.yml`, which only starts the dev datastores and **no app**:

```bash
docker compose -f docker-compose.prod.yml ps
docker compose -f docker-compose.prod.yml logs app
```

### `ERR_INVALID_URL` on startup

A quoted value in an `--env-file` `.env` (e.g. `DATABASE_URL="postgres://..."`). Remove the quotes — Docker keeps them literally. See the Tip under [Use Docker Run](#use-docker-run-bring-your-own-datastores).

### Database connection failed

1. Verify PostgreSQL is healthy:
   ```bash
   docker compose -f docker-compose.prod.yml ps
   ```
2. Test the connection:
   ```bash
   docker compose -f docker-compose.prod.yml exec postgres psql -U "$POSTGRES_USER" -c "SELECT 1"
   ```

### Port already in use

Change the published port via `APP_PORT` in your `.env` (the container always listens on 3000 internally):

```bash
APP_PORT=8080
```

## Security

1. **Use strong secrets** — generate with `openssl rand -base64 32`
2. **Enable HTTPS** — always use TLS in production (via a reverse proxy)
3. **Don't expose datastores** — the prod compose keeps Postgres/Dragonfly/MinIO off public ports; keep it that way
4. **Pin the image** — set `QUACKBACK_TAG` to a specific version rather than `latest`
5. **Back up regularly** — automate database (and object-storage) backups
6. **Keep updated** — pull latest images regularly

## Next Steps

- [Configuration Reference](/docs/reference/environment-variables) - All environment variables
- [Reverse Proxy Setup](/docs/self-hosting/reverse-proxy) - SSL/TLS and proxy configurations
- [Troubleshooting](/docs/self-hosting/troubleshooting) - Common issues and solutions

- [Install without Docker](https://quackback.io/docs/self-hosting/manual): Install Quackback with Bun and a direct PostgreSQL connection.

# Install without Docker

Install Quackback without Docker using Bun and a direct PostgreSQL connection.

## Prerequisites

### Bun

**Version**: 1.3.7 or higher

```bash
# Install Bun
curl -fsSL https://bun.sh/install | bash

# Verify installation
bun --version
```

### PostgreSQL

**Version**: 18 or higher

**Required Extensions**:
- `pgvector` - Vector similarity search (for AI features)
- `pg_cron` - Scheduled jobs (optional)

### Redis or Dragonfly

Required for background job processing (BullMQ).

- [Redis](https://redis.io/) 7+ or [Dragonfly](https://www.dragonflydb.io/) as a Redis-compatible alternative
- Dragonfly must be started with `--cluster_mode=emulated --lock_on_hashtags` for BullMQ compatibility

### Other Tools

- Git
- OpenSSL (for generating secrets)

## Installation Steps

### 1. Clone the Repository

```bash
git clone https://github.com/quackbackio/quackback.git
cd quackback
```

### 2. Install Dependencies

```bash
bun install
```

### 3. Configure Environment

Copy the example environment file:

```bash
cp .env.example .env
```

Generate a secure auth secret:

```bash
# Generate a 32-byte secret
openssl rand -base64 32
```

Edit `.env` with your settings:

```bash
# Required settings
DATABASE_URL="postgresql://quackback:your_password@localhost:5432/quackback"
REDIS_URL="redis://localhost:6379"
SECRET_KEY="your-generated-secret-key-at-least-32-characters"
BASE_URL="https://feedback.yourcompany.com"
```

See [Environment Variables](/docs/reference/environment-variables) for all options.

### 4. Set Up PostgreSQL

#### Install PostgreSQL 18

**Ubuntu/Debian**:

```bash
# Add PostgreSQL APT repository
sudo sh -c 'echo "deb https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

# Install PostgreSQL 18
sudo apt update
sudo apt install postgresql-18 postgresql-18-pgvector postgresql-18-cron
```

**macOS (Homebrew)**:

```bash
brew install postgresql@18
brew services start postgresql@18

# Install pgvector
brew install pgvector
```

**RHEL/CentOS/Fedora**:

```bash
# Install PostgreSQL 18 repo
sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

# Install PostgreSQL and extensions
sudo dnf install -y postgresql18-server postgresql18-contrib postgresql18-pgvector postgresql18-pg_cron
```

#### Create Database and User

```bash
# Switch to postgres user
sudo -u postgres psql
```

```sql
-- Create user
CREATE USER quackback WITH PASSWORD 'your_secure_password';

-- Create database
CREATE DATABASE quackback OWNER quackback;

-- Connect to database
\c quackback

-- Enable required extensions
CREATE EXTENSION IF NOT EXISTS pgvector;

-- Optional: Enable pg_cron (for scheduled jobs)
-- Note: pg_cron must be loaded in postgresql.conf first
CREATE EXTENSION IF NOT EXISTS pg_cron;

-- Grant permissions
GRANT ALL PRIVILEGES ON DATABASE quackback TO quackback;
GRANT ALL ON SCHEMA public TO quackback;
```

#### Configure pg_cron (Optional)

Edit `postgresql.conf`:

```ini
# Add to postgresql.conf
shared_preload_libraries = 'pg_cron'
cron.database_name = 'quackback'
```

Restart PostgreSQL:

```bash
sudo systemctl restart postgresql
```

### 5. Run Migrations

```bash
bun run db:migrate
```

This creates all required tables and indexes.

### 6. Build the Application

```bash
bun run build
```

This creates an optimized production build in `apps/web/.output/`.

### 7. Start the Server

```bash
bun run --cwd apps/web start
```

The server starts on port 3000 by default.

## Process Management

### systemd (Recommended)

Create `/etc/systemd/system/quackback.service`:

```ini
[Unit]
Description=Quackback Feedback Platform
After=network.target postgresql.service
Requires=postgresql.service

[Service]
Type=simple
User=quackback
Group=quackback
WorkingDirectory=/opt/quackback
Environment=NODE_ENV=production
EnvironmentFile=/opt/quackback/.env
ExecStart=/home/quackback/.bun/bin/bun run --cwd apps/web start
Restart=always
RestartSec=10

# Security hardening
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/opt/quackback

# Logging
StandardOutput=journal
StandardError=journal
SyslogIdentifier=quackback

[Install]
WantedBy=multi-user.target
```

Enable and start:

```bash
# Reload systemd
sudo systemctl daemon-reload

# Enable on boot
sudo systemctl enable quackback

# Start service
sudo systemctl start quackback

# Check status
sudo systemctl status quackback

# View logs
journalctl -u quackback -f
```

### PM2 (Alternative)

```bash
# Install PM2
bun install -g pm2

# Create ecosystem file
cat > ecosystem.config.js << 'EOF'
module.exports = {
  apps: [{
    name: 'quackback',
    cwd: '/opt/quackback/apps/web',
    script: '.output/server/index.mjs',
    interpreter: 'bun',
    env: {
      NODE_ENV: 'production',
      PORT: 3000
    },
    instances: 1,
    autorestart: true,
    watch: false,
    max_memory_restart: '1G'
  }]
}
EOF

# Start with PM2
pm2 start ecosystem.config.js

# Save configuration
pm2 save

# Enable startup script
pm2 startup
```

## Directory Structure

Recommended production layout:

```
/opt/quackback/
├── .env                    # Environment configuration
├── apps/
│   └── web/
│       └── .output/        # Built application
├── packages/               # Internal packages
├── node_modules/           # Dependencies
├── package.json
└── bun.lock
```

## Security Considerations

### File Permissions

```bash
# Create dedicated user
sudo useradd -r -s /bin/false quackback

# Set ownership
sudo chown -R quackback:quackback /opt/quackback

# Restrict .env file
sudo chmod 600 /opt/quackback/.env
```

### Firewall

```bash
# UFW example
sudo ufw allow 22/tcp      # SSH
sudo ufw allow 80/tcp      # HTTP (for redirect)
sudo ufw allow 443/tcp     # HTTPS
sudo ufw enable
```

## Update Quackback

### 1. Stop the Service

```bash
sudo systemctl stop quackback
```

### 2. Backup Database

```bash
pg_dump -Fc quackback > quackback_backup_$(date +%Y%m%d).dump
```

### 3. Pull Updates

```bash
cd /opt/quackback
git pull origin main
```

### 4. Install Dependencies

```bash
bun install
```

### 5. Run Migrations

```bash
bun run db:migrate
```

### 6. Rebuild

```bash
bun run build
```

### 7. Restart Service

```bash
sudo systemctl start quackback
```

### Update Script

```bash
#!/bin/bash
set -e

cd /opt/quackback

echo "Stopping service..."
sudo systemctl stop quackback

echo "Creating backup..."
pg_dump -Fc quackback > /var/backups/quackback/quackback_$(date +%Y%m%d_%H%M%S).dump

echo "Pulling updates..."
git pull origin main

echo "Installing dependencies..."
bun install

echo "Running migrations..."
bun run db:migrate

echo "Building..."
bun run build

echo "Starting service..."
sudo systemctl start quackback

echo "Update complete!"
```

## Health Checks

### Application Health

```bash
curl http://localhost:3000/
```

### Database Connection

```bash
psql $DATABASE_URL -c "SELECT 1"
```

### Service Status

```bash
sudo systemctl status quackback
```

## Troubleshooting

### Port Already in Use

```bash
# Find what's using port 3000
sudo lsof -i :3000

# Kill the process or change PORT in .env
```

### Database Connection Failed

Check connection string format:
```
postgresql://user:password@host:port/database
```

Test connection:
```bash
psql "postgresql://quackback:password@localhost:5432/quackback" -c "SELECT 1"
```

### Permission Denied

Ensure the quackback user owns all files:
```bash
sudo chown -R quackback:quackback /opt/quackback
```

### Build Fails

Clear cache and reinstall:
```bash
rm -rf node_modules
rm -rf apps/web/.output
bun install
bun run build
```

### Migrations Fail

Check database user permissions:
```sql
GRANT ALL PRIVILEGES ON DATABASE quackback TO quackback;
GRANT ALL ON SCHEMA public TO quackback;
```

## Next Steps

- [Reverse Proxy Configuration](/docs/self-hosting/reverse-proxy) - Set up Nginx, Caddy, or Traefik
- [Environment Variables](/docs/reference/environment-variables) - Configure email, OAuth, and integrations
- [Troubleshooting](/docs/self-hosting/troubleshooting) - Common issues and solutions

- [Self-host Quackback](https://quackback.io/docs/self-hosting/overview): Run Quackback on your own infrastructure.

# Self-Hosting

Quackback is designed to be self-hosted. Pick the deployment method that fits your setup.

## Choose your path

| Method | Best for | Time |
|--------|----------|------|
| [Railway](/docs/self-hosting/railway) | Fastest start, no server needed | 2 min |
| [Docker](/docs/self-hosting/docker) | Most deployments | 10 min |
| [Manual](/docs/self-hosting/manual) | Full control, no containers | 30 min |

## Before you start

Check the [system requirements](/docs/self-hosting/requirements). You need PostgreSQL 18+, Redis or Dragonfly, and about 1 GB of RAM.

## What's in this section

- [Deploy with Docker](/docs/self-hosting/docker): Docker Compose setup, configuration, upgrades
- [Install without Docker](/docs/self-hosting/manual): Bun, systemd, process management
- [System Requirements](/docs/self-hosting/requirements): Hardware, software, cloud providers
- [Reverse Proxy](/docs/self-hosting/reverse-proxy): Caddy, Nginx, Traefik configs for HTTPS
- [Declarative Configuration](/docs/self-hosting/config-file): Manage workspace settings as code
- [Troubleshooting](/docs/self-hosting/troubleshooting): Common issues and solutions

- [Deploy to Railway](https://quackback.io/docs/self-hosting/railway): Deploy Quackback to Railway with one click. No server to manage, automatic SSL, and built-in PostgreSQL and Redis.

# Deploy to Railway

Railway handles infrastructure so you can focus on collecting feedback. One click gives you Quackback, PostgreSQL, and Redis with automatic SSL, deployments on push, and no server management.

## Prerequisites

- A [Railway](https://railway.app) account (free tier available)
- A domain or subdomain for your instance (e.g., `feedback.yourcompany.com`)

## One-Click Deploy

Click the button below to deploy Quackback to Railway:

[![Deploy on Railway](https://railway.app/button.svg)](https://railway.com/deploy/quackback)

The template provisions three services:

| Service | Purpose |
|---------|---------|
| **Quackback** | The application server |
| **PostgreSQL** | Database with `pgvector` extension |
| **Redis** | Background job queue (BullMQ) |

## Manual Setup

If you prefer to configure each service yourself:

### 1. Create a New Project

1. Go to [railway.app/new](https://railway.app/new)
2. Click **Empty Project**

### 2. Add PostgreSQL

1. Click **+ New** → **Database** → **PostgreSQL**
2. Railway provisions a PostgreSQL instance automatically

### 3. Add Redis

1. Click **+ New** → **Database** → **Redis**
2. Railway provisions a Redis instance automatically

### 4. Deploy Quackback

1. Click **+ New** → **GitHub Repo**
2. Connect the `quackbackio/quackback` repository (or your fork)
3. Railway detects the Dockerfile and builds automatically

### 5. Configure Environment Variables

In the Quackback service settings, add these variables:

```bash
# Railway injects DATABASE_URL and REDIS_URL automatically if you link the services.
# If not linked, set them manually:
DATABASE_URL=${{Postgres.DATABASE_URL}}
REDIS_URL=${{Redis.REDIS_URL}}

# Authentication (generate with: openssl rand -base64 32)
SECRET_KEY="your-32-character-minimum-secret-key"

# Public URL (set after assigning a domain)
BASE_URL="https://feedback.yourcompany.com"
```

### 6. Link Services

1. Go to the Quackback service → **Variables**
2. Click **Add Reference** to link `DATABASE_URL` from the PostgreSQL service
3. Click **Add Reference** to link `REDIS_URL` from the Redis service

### 7. Add a Domain

1. Go to the Quackback service → **Settings** → **Networking**
2. Click **Generate Domain** for a Railway subdomain, or **Custom Domain** for your own
3. If using a custom domain, add a CNAME record pointing to Railway
4. Update `BASE_URL` to match

## Email Configuration

Without email, OTP codes are printed to Railway logs. For production, configure SMTP or Resend:

```bash
# SMTP
EMAIL_SMTP_HOST="smtp.example.com"
EMAIL_SMTP_PORT="587"
EMAIL_SMTP_USER="your-username"
EMAIL_SMTP_PASS="your-password"
EMAIL_FROM="feedback@yourcompany.com"

# Or Resend
EMAIL_RESEND_API_KEY="re_xxxxxxxxxxxx"
EMAIL_FROM="feedback@yourcompany.com"
```

## File Storage

For image uploads, configure S3-compatible storage:

```bash
S3_ENDPOINT="https://your-s3-endpoint"
S3_BUCKET="quackback-uploads"
S3_ACCESS_KEY="your-access-key"
S3_SECRET_KEY="your-secret-key"
S3_REGION="us-east-1"
```

## Upgrades

Railway rebuilds and redeploys automatically when you push to the connected branch. Migrations run on every startup, so schema changes are applied automatically.

To upgrade a template deployment:

1. Fork the Quackback repository if you haven't already
2. Pull the latest changes from upstream
3. Push to your fork — Railway redeploys automatically

## Monitoring

### Logs

View real-time logs in the Railway dashboard:

1. Go to your Quackback service
2. Click **Deployments** → select the active deployment
3. Click **View Logs**

### Health Check

Railway can restart the service if it becomes unhealthy:

1. Go to **Settings** → **Deploy**
2. Set the health check path to `/api/health`

## Cost

Railway bills based on usage. A typical Quackback instance costs $5–20/month depending on traffic:

| Resource | Estimate |
|----------|----------|
| Quackback (512 MB RAM) | ~$5/mo |
| PostgreSQL | ~$5/mo |
| Redis | ~$2/mo |

## Troubleshooting

### Build Fails

Check the build logs for errors. Common causes:
- Missing environment variables — ensure `DATABASE_URL` and `SECRET_KEY` are set
- Docker build issues — Railway uses the repository's Dockerfile

### Database Connection Failed

1. Verify the PostgreSQL service is running
2. Check that `DATABASE_URL` references the correct service
3. Try restarting the Quackback service

### "Port Already in Use"

Railway assigns a port via the `PORT` environment variable. Quackback reads this automatically. Do not hardcode a port.

## Next Steps

- [Configuration Reference](/docs/reference/environment-variables) - All environment variables
- [Reverse Proxy](/docs/self-hosting/reverse-proxy) - Custom proxy configurations
- [Docker Deployment](/docs/self-hosting/docker) - Alternative deployment with Docker

- [System Requirements](https://quackback.io/docs/self-hosting/requirements): Hardware and software requirements for self-hosting Quackback.

# System Requirements

Hardware, software, and infrastructure requirements for self-hosting Quackback.

## Minimum Requirements

| Resource | Minimum | Recommended |
|----------|---------|-------------|
| CPU | 1 core | 2+ cores |
| RAM | 1 GB | 2+ GB |
| Storage | 10 GB | 20+ GB |
| PostgreSQL | 18+ | 18+ |

## Software Requirements

### PostgreSQL

**Version**: 18 or higher (required)

**Required Extensions**:
- `pgvector` - Vector similarity search
- `pg_cron` - Scheduled jobs (optional)

### Redis or Dragonfly

Required for background job processing (BullMQ).

| Component | Version |
|-----------|---------|
| Redis | 7+ |
| Dragonfly (alternative) | 1.x+ |

### Docker (Recommended)

| Component | Version |
|-----------|---------|
| Docker Engine | 20.10+ |
| Docker Compose | v2+ |

The published image is multi-arch (`linux/amd64` and `linux/arm64`), so it runs natively on both x86-64 and ARM hosts (Apple Silicon, AWS Graviton, Ampere, Raspberry Pi).

### Bun (Alternative)

If running without Docker:

| Component | Version |
|-----------|---------|
| Bun | 1.3.7+ |

## Network Requirements

### Ports

| Port | Purpose | Required |
|------|---------|----------|
| 3000 | Application (default) | Yes |
| 5432 | PostgreSQL | Internal only |
| 6379 | Redis/Dragonfly | Internal only |
| 443 | HTTPS (via proxy) | Production |
| 80 | HTTP redirect | Optional |

### Domains

You need:
- A domain or subdomain (e.g., `feedback.yourcompany.com`)
- SSL certificate (Let's Encrypt works great)

### Outbound Connections

Quackback needs to reach:
- Email provider (SMTP or Resend API)
- OAuth providers (GitHub, Google, etc.)
- Integration services (Slack, etc.)

## Database Requirements

### PostgreSQL Configuration

Recommended settings for production:

```ini
# Memory
shared_buffers = 256MB
work_mem = 16MB
maintenance_work_mem = 128MB

# Connections
max_connections = 100

# WAL
wal_level = replica
```

### Storage

Estimate storage needs:

| Data | Size Estimate |
|------|---------------|
| 1,000 posts | ~50 MB |
| 10,000 posts | ~500 MB |
| 100,000 posts | ~5 GB |

Add headroom for:
- Attachments (if enabled)
- Vector embeddings (for AI features)
- Logs and backups

### Backups

- Daily full backups
- Point-in-time recovery (recommended)
- Off-site backup storage

## Cloud Provider Options

### AWS

| Service | Use |
|---------|-----|
| EC2 | Application server |
| RDS | Managed PostgreSQL |
| ElastiCache | Optional caching |
| ALB | Load balancing |

Minimum instance: `t3.small`

### Google Cloud

| Service | Use |
|---------|-----|
| Compute Engine | Application server |
| Cloud SQL | Managed PostgreSQL |
| Cloud Load Balancing | Load balancing |

Minimum machine: `e2-small`

### DigitalOcean

| Service | Use |
|---------|-----|
| Droplet | Application server |
| Managed Database | PostgreSQL |
| Load Balancer | Optional |

Minimum droplet: 2GB RAM

### Railway / Render / Fly.io

All support Quackback with managed databases.

## VPS Providers

Budget-friendly options:

| Provider | Minimum Plan |
|----------|--------------|
| Hetzner | CX21 (2GB RAM) |
| Vultr | 2GB plan |
| Linode | Nanode 2GB |
| DigitalOcean | Basic 2GB |

## Security Requirements

### TLS/SSL

- Required for production
- Use Let's Encrypt (free) or commercial cert
- Minimum TLS 1.2

### Firewall

Allow only:
- 443 (HTTPS)
- 80 (HTTP, redirect to HTTPS)
- 22 (SSH, restricted IPs)

Block:
- Direct database access
- Application port from public

### Secrets

## Plan for scaling

### Single Server

Suitable for:
- Up to 10,000 users
- Moderate traffic

### Scale horizontally

For higher loads:
- Multiple application instances
- Load balancer
- Shared PostgreSQL
- Session storage (database-backed)

### Scale the database

Options:
- Vertical scaling (bigger instance)
- Read replicas (for read-heavy loads)
- Connection pooling (PgBouncer)

## Set up monitoring

### Application

- Health check endpoint
- Error tracking (Sentry, etc.)
- Request latency

### Database

- Connection count
- Query performance
- Disk usage

### Infrastructure

- CPU utilization
- Memory usage
- Disk I/O
- Network throughput

## Next Steps

- [Docker Deployment](/docs/self-hosting/docker) - Quick start with Docker
- [Manual Installation](/docs/self-hosting/manual) - Install with Bun
- [Configuration](/docs/reference/environment-variables) - Environment variables

- [Set up a reverse proxy](https://quackback.io/docs/self-hosting/reverse-proxy): Serve Quackback securely with Nginx, Caddy, or Traefik.

# Set up a reverse proxy

A reverse proxy sits between clients and Quackback, handling SSL/TLS termination, compression, and security headers. Always use one in production.

## Required Headers

Your reverse proxy must pass these headers to Quackback:

| Header | Purpose |
|--------|---------|
| `Host` | Original hostname |
| `X-Real-IP` | Client IP address |
| `X-Forwarded-For` | Proxy chain |
| `X-Forwarded-Proto` | Protocol (http/https) |
| `Upgrade` | WebSocket support |
| `Connection` | Keep-alive handling |

## Caddy

Create `/etc/caddy/Caddyfile`:

```
feedback.yourcompany.com {
    reverse_proxy localhost:3000
    encode gzip zstd
}
```

Start Caddy:

```bash
sudo systemctl enable caddy
sudo systemctl start caddy
```

That's it. Caddy handles HTTPS, certificate renewal, and compression automatically.

## Nginx

Create `/etc/nginx/sites-available/quackback`:

```nginx
server {
    listen 80;
    server_name feedback.yourcompany.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name feedback.yourcompany.com;

    ssl_certificate /etc/letsencrypt/live/feedback.yourcompany.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/feedback.yourcompany.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    gzip on;
    gzip_types text/plain text/css application/json application/javascript image/svg+xml;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
```

Enable the site and obtain a certificate:

```bash
sudo ln -s /etc/nginx/sites-available/quackback /etc/nginx/sites-enabled/
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d feedback.yourcompany.com
sudo nginx -t && sudo systemctl reload nginx
```

## Traefik

Add labels to your Quackback service in `docker-compose.yml`:

```yaml
labels:
  - "traefik.enable=true"
  - "traefik.http.routers.quackback.rule=Host(`feedback.yourcompany.com`)"
  - "traefik.http.routers.quackback.tls.certresolver=letsencrypt"
  - "traefik.http.services.quackback.loadbalancer.server.port=3000"
```

See the [Traefik documentation](https://doc.traefik.io/traefik/) for full configuration including the certificate resolver setup.

## Apache

See the [Apache reverse proxy documentation](https://httpd.apache.org/docs/current/howto/reverse_proxy.html) for setup with `mod_proxy`. You need `mod_proxy`, `mod_proxy_http`, `mod_proxy_wstunnel`, `mod_ssl`, and `mod_headers` enabled.

## Troubleshooting

### 502 Bad Gateway

- Verify Quackback is running: `curl http://localhost:3000`
- Check that the `proxy_pass` address and port match your Quackback instance

### WebSocket Connection Failed

Make sure your proxy passes WebSocket upgrade headers:

```nginx
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
```

### Mixed Content Warnings

Ensure the `X-Forwarded-Proto: https` header is passed and `BASE_URL` in your `.env` uses `https://`.

### Redirect Loops

Check that `BASE_URL` in `.env` uses `https://`.

## Next Steps

- [Environment Variables](/docs/reference/environment-variables) - Configure email, OAuth, and integrations
- [Docker Deployment](/docs/self-hosting/docker) - Container-based deployment
- [Troubleshooting](/docs/self-hosting/troubleshooting) - Common issues and solutions

- [Troubleshoot common issues](https://quackback.io/docs/self-hosting/troubleshooting): Fix common issues with self-hosted Quackback deployments.

# Troubleshooting

Common issues and solutions for self-hosted Quackback deployments.

## Application Won't Start

### "Database connection failed"

**Symptoms**: Application fails to start with connection errors.

**Solutions**:

1. **Verify PostgreSQL is running**
   ```bash
   docker compose ps
   # or
   systemctl status postgresql
   ```

2. **Test connection**
   ```bash
   psql "$DATABASE_URL" -c "SELECT 1"
   ```

3. **Check connection string format**
   ```
   postgresql://user:password@host:5432/database
   ```

4. **For Docker networking**
   - Use container name, not `localhost`
   - Ensure containers are on same network

### "Missing environment variable"

**Symptoms**: Startup error about missing configuration.

**Solutions**:

1. **Check required variables**
   ```bash
   # Must be set:
   DATABASE_URL
   REDIS_URL
   SECRET_KEY
   BASE_URL
   ```

2. **Verify .env is loaded**
   ```bash
   docker compose config  # Shows resolved values
   ```

3. **Check for typos**
   - Variable names are case-sensitive
   - No spaces around `=`

### "Port already in use"

**Symptoms**: Bind error on startup.

**Solutions**:

```bash
# Find process using port 3000
lsof -i :3000

# Kill it
kill -9 

# Or use different port
PORT=8080 bun run start
```

## Database Issues

### "Migration failed"

**Symptoms**: Database migrations don't complete.

**Solutions**:

1. **Check migration status**
   ```bash
   bun run db:migrate 2>&1 | head -50
   ```

2. **Ensure database user has permissions**
   ```sql
   GRANT ALL PRIVILEGES ON DATABASE quackback TO your_user;
   GRANT ALL PRIVILEGES ON SCHEMA public TO your_user;
   ```

3. **Reset and retry** (development only)
   ```bash
   bun run db:reset
   bun run db:migrate
   ```

### "Extension pgvector not found"

**Symptoms**: Vector-related queries fail.

**Solutions**:

1. **Install extension**
   ```sql
   CREATE EXTENSION IF NOT EXISTS vector;
   ```

2. **Use pgvector image for Docker**
   ```yaml
   services:
     postgres:
       image: pgvector/pgvector:pg18
   ```

## Authentication Problems

### "Invalid session" after login

**Symptoms**: Users get logged out immediately or can't stay logged in.

**Solutions**:

1. **Check BASE_URL**
   - Must match exact domain users access
   - Include protocol: `https://feedback.example.com`

2. **Check cookies**
   - Cookies require HTTPS in production
   - Verify domain settings

3. **Clear browser data**
   - Delete cookies for the domain
   - Try incognito mode

### OTP codes not received

**Symptoms**: Users don't receive magic link emails.

**Solutions**:

1. **Check console** (development)
   - OTP codes print to console if no email configured

2. **Verify email configuration**
   ```bash
   # Check SMTP settings
   EMAIL_SMTP_HOST
   EMAIL_SMTP_PORT
   EMAIL_SMTP_USER
   EMAIL_SMTP_PASS
   ```

3. **Check spam folder**

4. **Test email delivery**
   ```bash
   # Many SMTP providers have test tools
   swaks --to test@example.com --server smtp.example.com
   ```

### OAuth redirect errors

**Symptoms**: "Redirect URI mismatch" or similar OAuth errors.

**Solutions**:

1. **Verify callback URL**
   ```
   https://your-domain.com/api/auth/callback/github
   ```

2. **Check for trailing slashes**
   - Must match exactly in provider settings

3. **Verify client ID/secret**
   - Re-copy from provider dashboard
   - Check for whitespace

## Performance Issues

### Slow page loads

**Symptoms**: Pages take several seconds to load.

**Solutions**:

1. **Check database performance**
   ```sql
   -- Find slow queries
   SELECT query, calls, mean_time
   FROM pg_stat_statements
   ORDER BY mean_time DESC
   LIMIT 10;
   ```

2. **Add database indexes**
   - Check for missing indexes on filtered columns

3. **Increase resources**
   - More RAM for PostgreSQL
   - More CPU for application

### High memory usage

**Symptoms**: Application or database using excessive memory.

**Solutions**:

1. **Check for memory leaks**
   ```bash
   # Monitor over time
   docker stats
   ```

2. **Tune PostgreSQL**
   ```ini
   shared_buffers = 256MB  # ~25% of RAM
   work_mem = 16MB
   ```

3. **Restart periodically**
   - Set up health checks and auto-restart

## Integration Issues

### Slack notifications not sending

**Symptoms**: Connected but no messages appear.

**Solutions**:

1. **Check integration status**
   - Admin → Settings → Integrations → Slack
   - Look for error messages

2. **Verify channel access**
   - App must be invited to private channels
   - Channel may have been deleted

3. **Check event mappings**
   - Ensure events are configured
   - Verify correct channel selected

4. **Reconnect integration**
   - Click "Reconnect"
   - Re-authorize in Slack

### Webhook deliveries failing

**Symptoms**: Webhooks show failed status.

**Solutions**:

1. **Check endpoint availability**
   ```bash
   curl -X POST https://your-endpoint.com/webhook \
     -H "Content-Type: application/json" \
     -d '{"test": true}'
   ```

2. **Verify HTTPS**
   - Webhooks require HTTPS endpoints
   - Check certificate validity

3. **Check response codes**
   - Endpoint must return 2xx
   - 4xx errors don't retry (except 429)

## Docker Issues

### App isn't reachable / no app container

**Symptoms**: `docker compose up -d` starts the datastores but Quackback itself never runs.

**Solution**: Use the production compose file. A bare `docker compose up -d` uses the repo's root `docker-compose.yml`, which is **development infrastructure only** (Postgres, Dragonfly, MinIO — no app service). Self-host with:

```bash
cp .env.prod.example .env   # fill in your values
docker compose -f docker-compose.prod.yml up -d
docker compose -f docker-compose.prod.yml logs app
```

### `ERR_INVALID_URL` at startup (with `--env-file`)

**Symptoms**: The container exits immediately with `ERR_INVALID_URL`, often on `DATABASE_URL`.

**Solution**: Remove quotes from your `.env`. Docker's `--env-file` does **not** strip quotes or inline `# comments` — it reads everything after `=` literally, so `DATABASE_URL="postgresql://..."` is passed with the quotes attached. Use plain `KEY=value`.

### Container keeps restarting

**Symptoms**: Container in restart loop.

**Solutions**:

1. **Check logs**
   ```bash
   docker compose logs app --tail 100
   ```

2. **Check health**
   ```bash
   docker compose ps
   ```

3. **Verify environment**
   ```bash
   docker compose config
   ```

### Database volume issues

**Symptoms**: Data not persisting or permission errors.

**Solutions**:

1. **Check volume mount**
   ```yaml
   volumes:
     - postgres_data:/var/lib/postgresql
   ```

2. **Fix permissions**
   ```bash
   sudo chown -R 999:999 /path/to/volume
   ```

### Out of disk space

**Symptoms**: Write errors, container failures.

**Solutions**:

1. **Clean up Docker**
   ```bash
   docker system prune -a
   ```

2. **Check disk usage**
   ```bash
   df -h
   docker system df
   ```

## Getting Help

### Collect Diagnostic Info

Before asking for help, gather:

1. **Error messages** (exact text)
2. **Logs**
   ```bash
   docker compose logs app --tail 200 > app-logs.txt
   ```
3. **Environment** (redact secrets)
4. **Steps to reproduce**

### Support Channels

- [GitHub Issues](https://github.com/quackbackio/quackback/issues)
- [GitHub Discussions](https://github.com/quackbackio/quackback/discussions)

### Issue Template

```markdown
**Environment**
- Quackback version:
- Deployment method: Docker / Bun
- PostgreSQL version:
- OS:

**Problem**
[Describe the issue]

**Steps to Reproduce**
1.
2.
3.

**Expected Behavior**
[What should happen]

**Actual Behavior**
[What actually happens]

**Logs**
```
[Relevant log output]
```
```

## Next Steps

- [Docker Deployment](/docs/self-hosting/docker) - Standard setup
- [Configuration](/docs/reference/environment-variables) - All options
- [Requirements](/docs/self-hosting/requirements) - System requirements


### Users

- [Manage your account](https://quackback.io/docs/users/account): Update your profile, notification preferences, and privacy settings.

# Manage your account

Manage your profile, preferences, and account settings.

## Access settings

1. Click your **profile picture** or avatar in the header
2. Select **Settings**

## Profile

### Display Name

Your name shown on posts and comments:

1. Go to **Profile** settings
2. Edit your **Name**
3. Click **Save**

### Profile Picture

Upload a custom avatar:

1. Go to **Settings** > **Profile**
2. Click **Change avatar**
3. Select an image file
4. Crop to fit
5. The avatar uploads automatically

**Requirements**:
- Max size: 5 MB
- Formats: JPEG, PNG, GIF, WebP

### Email Address

Your email is used for:
- Sign-in (via one-time codes)
- Notifications
- Account identification

## Notification Preferences

Control how you receive updates in **Settings** > **Preferences**:

### Email Notifications

| Setting | Description |
|---------|-------------|
| Status updates | When posts you're subscribed to change status |
| New comments | When someone comments on posts you're subscribed to |

Toggle each setting on or off based on your preferences.

### In-App Notifications

In-app notifications are always available. Access them via the bell icon in the header.

## Privacy

### Activity Visibility

Some workspaces show:
- Your votes on posts
- Your comments
- Your submitted feedback

Check with your workspace admin for specific privacy settings.

### Data Requests

To request your data or deletion:
1. Contact workspace administrators
2. Or email the support address

## Authentication

Quackback uses passwordless authentication. When you sign in:

1. Enter your email address
2. Check your email for a 6-digit code
3. Enter the code to complete sign-in

## Subscription Management

### Manage subscriptions

You're automatically subscribed to posts when you vote, comment, or create them. To manage subscriptions:

1. Open a post you're subscribed to
2. Click the **bell icon**
3. Choose your subscription level or select **Unsubscribe**

### Email Unsubscribe

Every notification email includes an unsubscribe link to stop receiving updates for that specific post.

## Account Deletion

To delete your account:

1. Contact workspace administrators
2. Request account deletion
3. Your data will be removed or anonymized

## Troubleshooting

### Can't sign in

1. Check your email address is correct
2. Look in spam folder for the sign-in code email
3. Request a new code if it expired (codes are valid for 10 minutes)
4. Contact workspace admin if issues persist

### Not receiving emails

1. Check spam/promotions folder
2. Verify email address in your profile
3. Check notification preferences in Settings > Preferences
4. Contact workspace admin

### Profile picture not updating

1. Clear browser cache
2. Try a different image format (JPEG, PNG, GIF, or WebP)
3. Ensure image is under 5 MB
4. Try a different browser

## Next Steps

- [Notifications](/docs/users/notifications) - Detailed notification settings
- [Voting](/docs/users/voting) - Manage your votes
- [Submitting Feedback](/docs/users/submitting-feedback) - Share ideas

- [Comment on posts](https://quackback.io/docs/users/comments): Discuss feedback with threaded comments and reactions.

# Comment on posts

Join the discussion on feedback posts with comments.

## Add comments

### On a Post

1. Open any post
2. Scroll to the comment section
3. Type your comment in the rich text editor
4. Click **Comment** (or **Reply** for replies)

The comment editor supports headings, bold, italic, lists, links, inline code, fenced code blocks, and emoji (via the picker or shortcodes like `:tada:`). Markdown shortcuts (e.g. `**bold**`, `# Heading`) are recognized as you type. Older comments stored as plain markdown keep rendering as before.

### Reply to comments

Create threaded discussions:

1. Find the comment you want to reply to
2. Click **Reply**
3. Type your response
4. Submit

Replies appear nested under the original comment.

## Reactions

React to comments with emoji:

1. Find a comment
2. Click the smiley icon below the comment
3. Select an emoji from the picker

Available reactions: thumbs up, heart, celebration, smile, thinking, and eyes.

## Pinned Comments

Team members can **pin** a comment to highlight it at the top of the comment thread. Pinned comments are marked with a "Pinned" badge.

Pinned comments typically:
- Acknowledge the feedback
- Provide status updates
- Explain decisions
- Ask clarifying questions

## Status Changes in Comments

When a team member changes a post's status while leaving a comment, a status change indicator appears inline in the comment thread. For example, if a team member moves a post from "Under Review" to "Planned" while commenting, the thread shows:

- The status transition (e.g. Under Review → Planned) as a badge on the comment
- The team member's comment explaining the decision

This gives readers full context about why a status changed and what the team's reasoning was, without needing to check a separate activity log.

## Private Comments

Team members can post private comments that are only visible to other team members. Use private comments for internal discussion - coordinate responses, share context, or discuss priorities without the conversation being visible to portal users.

### Post a private comment

1. Open any post
2. Click the **Private** button next to the submit button (lock icon)
3. Type your internal note
4. Click **Comment**

The button turns amber when private mode is active. Private comments display an amber left border and an "Internal note" badge to distinguish them from public comments.

### Reply to a private comment

Replies to private comments are always private. When you reply to an internal note, the private toggle is automatically enabled and locked - you don't need to toggle it manually.

### Restrictions

- Only team members (admins and members) can post private comments
- Private comments can't be pinned as the official response
- Portal users and anonymous visitors never see private comments

## Comment Locking

Team members can lock comments on a post to prevent further discussion. When comments are locked:

- Portal users see a lock icon and a message explaining that comments are disabled
- Team members can still comment on locked posts

## Edit and delete comments

You can edit and delete comments you've posted yourself:

1. Hover or focus your own comment
2. Click **Edit** to revise it, or **Delete** to remove it
3. Edits keep the comment in place; deletions leave a placeholder so threaded replies stay attached

Team members can also delete comments that violate guidelines.

## Comment Notifications

Get notified about comment activity:

| Event | Notification |
|-------|--------------|
| Comment on posts you're subscribed to | Email/in-app |

Configure in [notification settings](/docs/users/notifications).

## Comment Guidelines

### Be Constructive

- Focus on the topic
- Provide helpful information
- Suggest solutions

### Be Respectful

- Disagree politely
- Avoid personal attacks
- Remember the human

### Stay On Topic

- Keep comments relevant to the post
- Start a new post for different ideas
- Use replies for sub-discussions

### Add Value

Good comments include:
- Additional use cases
- Workarounds you've found
- Clarifying questions
- Relevant context

## What to Avoid

## Report comments

If you see inappropriate content, contact the workspace administrators directly through the feedback portal or other support channels.

## Common Questions

### Why can't I comment?

You may need to:
- Sign in to your account
- Verify your email
- Have your comment approved by a team member (if comments are moderated on that board)
- Check if comments are locked on that post (a lock icon will be visible)

### Can I comment anonymously?

This depends on workspace settings. Most require authentication.

### Are comments moderated?

Sometimes. Based on the workspace and per-board settings, comments from people outside the team can be held for a team member to review. Once they [approve it](/docs/admin/moderation), your comment appears publicly. You can see your own pending comment on the post's detail page, but other readers can't until it's approved.

Team members' comments are always published right away. Approved comments count toward the post's public comment total; held or rejected comments don't.

### Can the team delete my comment?

Yes. Comments that violate guidelines may be removed.

## Next Steps

- [Voting](/docs/users/voting) - Support ideas you agree with
- [Submitting Feedback](/docs/users/submitting-feedback) - Share new ideas
- [Notifications](/docs/users/notifications) - Manage your alerts

- [Manage your notifications](https://quackback.io/docs/users/notifications): Control which updates you receive via email and in-app alerts.

# Manage your notifications

Stay informed about feedback you care about with notifications.

## Notification Types

### Email Notifications

Delivered to your email address (when enabled in Preferences):
- Status changes on posts you're subscribed to
- New comments on posts you're subscribed to

### In-App Notifications

Available in the notification center (bell icon in header):
- Status changes on subscribed posts
- New comments on subscribed posts
- Grouped by time period (Today, Yesterday, Earlier)

## Notification Center

Access your notifications:

1. Click the **bell icon** in the header
2. View recent notifications
3. Click any notification to open the related post

### Mark as Read

- Click a notification to open the related post and mark it as read
- Click **"Mark all read"** to clear all unread notifications

## Subscribe to posts

### Automatic Subscriptions

You're automatically subscribed when you:
- Create a post
- Vote on a post
- Comment on a post

### Manual Subscription

To subscribe to any post:

1. Open the post
2. Click the **bell icon** in the sidebar
3. Choose your subscription level:
   - **All activity** - Get notified about comments and status changes
   - **Status changes** - Only get notified when the status is updated

### Unsubscribe

To stop receiving updates:

1. Open the post
2. Click the **bell icon**
3. Select **Unsubscribe**

Or use the **unsubscribe link** in notification emails.

## Notification Settings

Configure your preferences:

1. Click your **profile** avatar in the header
2. Select **Settings**
3. Go to **Preferences**

### Available Options

| Setting | Description |
|---------|-------------|
| Status updates | Get notified when posts you're subscribed to change status |
| New comments | Get notified when someone comments on posts you're subscribed to |

## Manage notification volume

### Too Many Notifications?

If you're overwhelmed:

1. **Disable email notifications** - Turn off status updates and/or new comments in Preferences
2. **Unsubscribe from posts** - Use the bell icon on posts to unsubscribe
3. **Be selective with votes** - Vote only on high-priority items
4. **Use in-app notifications** - Check the Notifications page instead of email

### Not Enough?

If you're missing updates:

1. Check **spam/promotions** folders
2. Verify your **email address** is correct
3. Ensure notifications are **enabled** in Preferences
4. **Subscribe** to posts manually using the bell icon

## Unsubscribe Links

Every notification email includes an unsubscribe link at the bottom:

- **Unsubscribe from this post** - Stop updates for one post
- **Unsubscribe from all** - Stop all email notifications

## Common Questions

### Why am I not receiving emails?

Check these:
1. **Spam folder** - Notifications may be filtered
2. **Email address** - Verify it's correct in your profile
3. **Notification settings** - Ensure email notifications are enabled in Preferences

### Can I get mobile push notifications?

Currently, notifications are delivered via:
- Email
- In-app notification center (accessible via the bell icon in the header)

### How do I completely disable email notifications?

1. Go to Settings > Preferences
2. Toggle off **Status updates**
3. Toggle off **New comments**

You'll still see in-app notifications when logged in.

### Do admins see my notification preferences?

No. Your notification preferences are private.

## Best Practices

### Curate Your Subscriptions

- Regularly review what you're subscribed to
- Unsubscribe from completed/closed posts using the bell icon
- Focus on active items you truly care about

### Check the Portal

The notification center (bell icon in the header) shows all your notifications in one place, even if you've disabled email notifications.

## Next Steps

- [Account Settings](/docs/users/account) - Manage your profile
- [Voting](/docs/users/voting) - Control what you're subscribed to
- [Comments](/docs/users/comments) - Engage with the community

- [Submit feedback](https://quackback.io/docs/users/submitting-feedback): Share ideas, report bugs, and request features through the portal.

# Submit feedback

Share your ideas, report bugs, and request features through the feedback portal.

## Find the feedback portal

Your organization's feedback portal is typically at:
- `feedback.yourcompany.com`
- `yourcompany.quackback.io`

Look for a "Feedback" or "Feature Request" link in the product you're using.

## Browse existing feedback

Before submitting new feedback, check if someone else has already requested it:

1. **Search** - Use the search bar to find related posts
2. **Browse boards** - Look through relevant boards
3. **Filter by status or tags** - Use the filter dropdowns to narrow results by status (e.g. Planned, In Progress) or tags
4. **Check the roadmap** - See what's already planned

## Create a new post

### 1. Choose a Board

Select the appropriate board for your feedback:
- **Feature Requests** - New functionality you'd like to see
- **Bug Reports** - Issues you've encountered
- **Integrations** - Connections with other tools
- **Documentation** - Improvements to guides and help

### 2. Write a Clear Title

Your title should be:
- **Concise** - One sentence summarizing your request
- **Specific** - Include key details
- **Searchable** - Use common terms others might search for

**Good titles:**
- "Add dark mode support"
- "Export reports to PDF"
- "Slow loading on dashboard with 1000+ items"

**Avoid:**
- "Feature request" (too vague)
- "This is broken!!!" (not descriptive)
- "I think it would be really great if..." (unnecessary preamble)

### 3. Describe Your Feedback

In the description, include:

**For feature requests:**
- What you want to accomplish
- Why it's important to you
- How you currently work around it (if applicable)

**For bug reports:**
- Steps to reproduce
- Expected behavior
- Actual behavior
- Browser/device information

**For all feedback:**
- Context about your use case
- Examples if helpful
- Screenshots or recordings (if supported)

### 4. Submit

Click **Submit** or **Post** to publish your feedback.

## Write your feedback

The post description uses a rich text editor. You can format with headings, bold, italic, lists, links, inline code, fenced code blocks, and emoji. Markdown shortcuts (e.g. `**bold**`, `# Heading`) are recognized as you type.

### Mention a teammate or another user

Type `@` while writing to mention a team member or another portal user. A typeahead picker appears as soon as you type the character; keep typing to filter by name, then pick from the list with the arrow keys and Enter, or click.

Mentioned users get an in-app notification and an email (if their workspace settings allow). The mention renders as a chip with the person's current display name, and hovering a chip shows their avatar and join date.

### Embed images and code

- Paste or drop images directly into the editor. They're uploaded and re-hosted to your workspace.
- Use the slash menu (`/`) to insert headings, lists, code blocks, tables, and dividers.
- Type three backticks followed by a language hint (e.g. ` ```ts`) to start a fenced code block with syntax highlighting.

## After Submitting

### Track Your Post

Your post is now visible to:
- The product team
- Other users (on public boards)

You'll receive updates when:
- The team responds
- Status changes (planned, shipped, etc.)
- Others comment

### If your post is pending review

Depending on the board and workspace settings, posts from non-team members may be held for approval before they go public. A held post is visible only to you until a team member approves it. You'll get a notification when it's approved or rejected.

### Vote for Your Own Post

Your vote is automatically added when you submit.

### Edit Your Post

To edit a post you submitted:
1. Open your post
2. Click the **three-dot menu** (if available)
3. Select **Edit**
4. Make changes and save

### Delete Your Post

To delete a post you submitted:
1. Open your post
2. Click the **three-dot menu** (if available)
3. Select **Delete**
4. Confirm deletion

## Notifications

Control how you're notified:

1. Click your profile avatar and go to **Settings**
2. Navigate to **Preferences**
3. Toggle email notifications for:
   - Status updates
   - New comments

### Unsubscribe from a Post

To stop receiving updates for a specific post:
1. Open the post
2. Click the **bell icon**
3. Select **Unsubscribe**

Or use the unsubscribe link in notification emails.

## Tips

### Be Constructive

Frame feedback positively:
- Focus on the problem, not blame
- Suggest solutions if you have ideas
- Remember there's a team reading this

### Provide Context

Help the team understand:
- Your role (developer, designer, user)
- Your use case
- How often you encounter this issue

### Check Back

Look for responses from the team:
- They may ask clarifying questions
- Share status updates
- Explain decisions

### Engage with Others

Support the community:
- Vote on posts you agree with
- Add helpful comments
- Share your workarounds

## Common Questions

### Why can't I see my post?

Your post may be:
- On a private or restricted board
- **Held for review** - Some boards or workspaces hold posts from non-team members for approval. A held post is hidden from other users, but you (the author) can still see it on the post detail. You're notified when a team member approves or rejects it.
- In a different board than expected

### Why do I need to sign in?

Authentication helps:
- Notify you of updates
- Track your votes
- Prevent spam

### Can I submit anonymously?

It depends on two layers of settings:

- **Workspace level** - Your admin can require sign-in for all submissions by turning off the **Allow anonymous interaction** setting. When it's off, voting, commenting, and submitting require an account everywhere.
- **Board level** - Each board sets its own submission rule: anyone, signed-in users only, specific segments, or team members only.

Viewing, voting, commenting, and submitting are gated independently per board, so a board you can view may still require sign-in to submit. If you see **Sign in to submit on this board** or **Only team members can submit on this board**, that board restricts who can post.

## Next Steps

- [Voting](/docs/users/voting) - Support ideas you care about
- [Comments](/docs/users/comments) - Join the discussion
- [Notifications](/docs/users/notifications) - Manage your alerts

- [Vote on feedback](https://quackback.io/docs/users/voting): Vote on ideas to help teams prioritize what to build.

# Vote on feedback

Show your support for feedback you care about by voting.

## How votes work

Each user gets **one vote per post**. Votes help the team:
- Prioritize popular requests
- Understand user demand
- Make data-driven decisions

## Vote without an account

You can vote without signing in when two things line up: your workspace allows anonymous interaction, and the board's Vote permission allows it. When both apply, click the vote button on any post and your vote is counted immediately - no account required.

Some boards require sign-in to vote (or restrict voting to specific groups or team members) even when your workspace allows anonymous interaction. Voting is set per board, separate from who can view.

Your votes are tracked per browser session. If you clear your cookies, your anonymous votes can't be recovered.

### When a board requires sign-in to vote

Each board independently sets who can vote - **Anyone**, **Signed-in** users, specific audience **Segments**, or **Team only** - and this is separate from who can view the board. So a board you can read may still require sign-in to vote.

If you can't vote, you'll see a message explaining why:
- "Sign in to vote on this board"
- "Only specific groups can vote on this board"
- "Only team members can vote on this board"

## Vote on posts

### From the List

1. Browse the feedback list
2. Click the **vote button** (upvote arrow icon) on any post
3. The vote count increases

### From the Post Detail

1. Open a post
2. Click the **vote button**
3. Your vote is registered

## Remove your vote

Changed your mind? Remove your vote:

1. Find the post you voted on
2. Click the vote button again
3. Your vote is removed

## Find posts to vote on

### Sort by Votes

Use the sort dropdown to find:
- **Top** - Most voted posts overall
- **Trending** - Recently popular posts
- **New** - Latest submissions

### Filter by Board

Focus on areas you care about:
- Feature Requests
- Integrations
- Your specific product area

### Filter by Status or Tags

Narrow down the list further using the filter dropdowns:
- **Status** - Show only posts in a specific workflow stage (e.g. Planned, In Progress)
- **Tags** - Filter by topic or category labels

### Search

Look for specific topics using the search bar.

## Your Voted Posts

Your votes are tracked automatically. Posts you've voted on display a highlighted vote button so you can easily see which items you've supported.

## Vote Notifications

Stay informed about posts you've voted on:

| Event | Notification |
|-------|--------------|
| Status change | "Feature X is now In Progress" |
| Shipped | "Feature X has shipped!" |
| Team comment | "Team replied to Feature X" |

Configure notifications in your [account settings](/docs/users/notifications).

## Voting Best Practices

### Vote Selectively

Your votes are a signal. Use them for items that truly matter to you.

### Look for Similar Posts

Before voting, check for duplicates. Vote for the existing post with the most engagement.

### Add Comments

If you have additional context, add a comment explaining your use case:
- Why this matters to you
- How you'd use it
- Your current workaround

### Avoid Vote Manipulation

## How Teams Use Votes

Votes are one factor in prioritization:

| Factor | Description |
|--------|-------------|
| Vote count | How many users want this |
| User segments | Which customers are asking |
| Strategic fit | Alignment with product vision |
| Effort | Development complexity |
| Dependencies | Technical requirements |

## Common Questions

### Why do I need to sign in to vote?

Some workspaces require sign-in for voting to prevent manipulation and keep the signal accurate. Individual boards can also restrict voting to signed-in users, specific segments, or team members, regardless of the workspace setting.

Admins control the workspace setting at **Admin → Settings → Moderation** ("Allow anonymous interaction"). See [Moderation](/docs/admin/moderation#allow-anonymous-interaction) for details.

### Can I vote on my own posts?

Yes! Your vote is automatically added when you submit feedback.

### Do votes expire?

No. Votes persist unless you remove them.

### Can I see who voted?

This depends on workspace settings. Some organizations show voter counts only; others show voter names.

### Can admins vote on my behalf?

Yes. Workspace admins can add votes on behalf of users — for example, when a customer requests a feature through a support channel. These proxy votes count toward the total vote count and you receive the same status update notifications as if you voted yourself. Proxy votes aren't subject to a board's Vote permission, so admins can add votes on any board.

### Can admins remove my vote?

Yes. Admins can remove any vote (including your direct vote or a proxy vote) from the voters list on a post. This is typically used to clean up accidental proxy votes or remove votes from deactivated accounts. You won't be notified when a vote is removed.

## Next steps

- [Submitting Feedback](/docs/users/submitting-feedback) - Share your ideas
- [Comments](/docs/users/comments) - Add context to your votes
- [Notifications](/docs/users/notifications) - Track your votes


### Admin

- [Use AI-powered features](https://quackback.io/docs/admin/ai-features): Configure and use AI summaries, duplicate detection, and suggestions.

# Use AI-powered features

Let AI handle the repetitive work. Quackback uses large language models and vector embeddings to summarize feedback, detect duplicates, and triage incoming posts so your team can focus on decisions.

## Overview

Quackback includes four AI capabilities:

| Feature | What it does |
|---------|-------------|
| **Post summaries** | Generates a short summary of user comments on a post |
| **Duplicate detection** | Finds existing posts that match new feedback using vector similarity, full-text search, and LLM verification |
| **AI suggestions** | Turns integration feedback (Slack, API) into actionable suggestions: merge, vote, or create |
| **Embeddings** | Vector representations of post content, used for similarity search |

## Configure AI

All features are off until you configure an endpoint and models. Without configuration, AI features stay inactive and the UI elements don't appear.

To enable AI, set four [environment variables](/docs/reference/environment-variables): an API key, an endpoint, and a model for each of the two roles.

```bash
OPENAI_API_KEY="sk-..."
OPENAI_BASE_URL="https://api.openai.com/v1"
AI_CHAT_MODEL="gpt-4o-mini"
AI_EMBEDDING_MODEL="text-embedding-3-small"
```

Quackback works with any OpenAI-compatible endpoint but never assumes one. Point `OPENAI_BASE_URL` at OpenAI directly (`https://api.openai.com/v1`), OpenRouter (`https://openrouter.ai/api/v1`), a gateway like Cloudflare AI Gateway, or a local server. Use model ids your endpoint accepts -- gateways typically want provider-prefixed ids like `google/gemini-3.1-flash-lite-preview`.

The two model roles cover everything:

- **`AI_CHAT_MODEL`** -- powers summaries, duplicate verification, and the suggestion pipeline
- **`AI_EMBEDDING_MODEL`** -- powers duplicate detection and help center semantic search; must produce 1536-dimensional vectors (like `text-embedding-3-small`)

### Per-feature model overrides

You can give an individual feature its own chat model, or switch one feature off while keeping the rest:

```bash
AI_SUMMARY_MODEL="off"     # disable post summaries only
AI_MERGE_MODEL="gpt-4o"    # use a stronger model for merge verification
```

Available overrides: `AI_SUMMARY_MODEL`, `AI_SENTIMENT_MODEL`, `AI_EXTRACTION_MODEL`, `AI_QUALITY_GATE_MODEL`, `AI_INTERPRETATION_MODEL`, and `AI_MERGE_MODEL`. Each falls back to `AI_CHAT_MODEL` when unset. A value of `off` disables just that feature.

## Post summaries

Posts with comments display an AI-generated summary card on the detail page. Summaries help you understand what users are asking for without reading every comment.

Each summary includes:

- **Overview** -- 1-3 sentences capturing the core user need
- **Key quotes** -- Notable comments from users (not team replies)
- **Next steps** -- Suggested actions like "Investigate...", "Reproduce...", or "Respond to..."

### Staleness detection

Summaries detect when new comments arrive after the last generation. A **Stale** badge appears next to the timestamp, and the summary refreshes automatically in the background.

## Duplicate detection

When new feedback arrives, Quackback searches for existing posts that cover the same topic. The detection pipeline works in three stages:

1. **Vector similarity** -- Compares embeddings of the new content against all existing post embeddings
2. **Full-text search** -- Runs a keyword search to catch matches that embeddings might miss
3. **LLM verification** -- Sends candidate pairs to the model to filter false positives and explain why posts are similar

High-confidence matches appear as [merge suggestions](/docs/admin/suggestions) in the triage view. You also see similar posts in the **Merge** section of any post detail page, with similarity scores and one-click merge.

## AI suggestions

Feedback from integration sources like Slack is analyzed and turned into actionable suggestions. Quackback runs each message through a quality gate, extracts themes, and matches them against existing posts.

You get three types of suggestions:

- **Merge posts** -- Two existing posts that appear to be duplicates
- **Vote on post** -- Incoming feedback that matches an existing post
- **Create post** -- Feedback that doesn't match anything, with an AI-generated title

Review suggestions from **Admin → Feedback → Incoming**. Accept or dismiss each one with a single click.

See [Triage AI suggestions](/docs/admin/suggestions) for the full guide on reviewing, filtering, and managing suggestions.

## Backfill embeddings

Existing posts created before AI was enabled don't have embeddings. Run the backfill command to generate them:

```bash
bun run ai:backfill
```

This processes all posts that lack embeddings and generates vector representations for each one. The command is safe to run multiple times -- it skips posts that already have embeddings.

## Privacy considerations

On [Quackback Cloud](/docs/cloud/ai-operations), requests go to Quackback's AI provider. No user emails, names, or account metadata are included.

When AI features are enabled, Quackback sends the following data to your configured AI provider:

- **Post titles and descriptions** -- used for embedding generation and duplicate detection
- **Comment text** -- used for summary generation (only user comments, not team replies)
- **Candidate post pairs** -- sent for LLM verification during duplicate detection

No user emails, names, or account metadata are included in AI requests. All requests go to the endpoint you set in `OPENAI_BASE_URL` -- Quackback never sends data to an endpoint you didn't configure.

To disable AI features entirely, remove the `OPENAI_API_KEY` variable from your environment and restart Quackback. To disable a single feature, set its model override to `off` (for example, `AI_SUMMARY_MODEL=off`).

## Next steps

- [Triage AI suggestions](/docs/admin/suggestions) -- Review and act on AI-generated suggestions
- [Triage feedback in the inbox](/docs/admin/inbox) -- Filter and respond to feedback
- [Environment variables](/docs/reference/environment-variables) -- Full configuration reference

- [Measure feedback with analytics](https://quackback.io/docs/admin/analytics): Track feedback volume, engagement, and response times to make data-driven product decisions.

# Measure feedback with analytics

Stop guessing what's working. The analytics dashboard shows you how feedback flows through your workspace, where users engage most, and how quickly your team responds.

## Overview

Access analytics from **Admin > Analytics** in the sidebar. The dashboard has a left sidebar for switching between sections and a top bar for selecting the time period.

### Sections

| Section | What it shows |
|---------|---------------|
| Overview | Summary cards with key metrics, activity chart |
| Feedback | Volume over time, breakdown by board and status |
| Changelog | Changelog entry performance |
| Users | Top contributors, active voters |

### Time periods

Select a preset range from the top bar:

| Preset | Period |
|--------|--------|
| 7 days | Previous week |
| 30 days | Previous month |
| 90 days | Previous quarter |
| 12 months | Previous year |

Click a metric card to see its trend in the main chart area.

## Feedback volume

The volume chart shows how many posts your workspace receives over time. Toggle between daily, weekly, and monthly views to spot trends.

### Volume by board

Break down volume by [board](/docs/admin/boards) to see which areas of your product generate the most feedback. A proportional bar list shows each board's share of total volume.

### Volume by status

A donut chart shows how posts are distributed across statuses. Hover over segments to see exact counts and percentages.

## User engagement

Understand who's participating and how actively.

### Active voters

Track the number of unique users who voted in the selected period. A rising voter count indicates growing community involvement.

### Top contributors

A ranked list of users by total activity — posts submitted, votes cast, and comments left. Use this to identify your most engaged users.

### Comment activity

See comment volume over time, split by:

- **User comments** — feedback from portal users
- **Team replies** — responses from your team members
- **Internal notes** — private comments between team members

## Response time

Measure how quickly your team engages with feedback.

| Metric | Definition |
|--------|------------|
| Time to first response | Duration from post creation to the first team comment |
| Time to resolution | Duration from post creation to "Complete" or "Closed" status |
| Median response time | The midpoint response time (less skewed by outliers than average) |

Response times are displayed as median values by default. You can toggle to show averages.

## Filter analytics

Narrow your analytics view using the filter bar at the top of the dashboard.

### Date range

Select a preset range or define a custom one:

| Preset | Period |
|--------|--------|
| Last 7 days | Previous week |
| Last 30 days | Previous month |
| Last 90 days | Previous quarter |
| Last 12 months | Previous year |
| Custom | Pick start and end dates |

### Board filter

Select one or more [boards](/docs/admin/boards) to scope all metrics to feedback in those categories.

### Segment filter

Choose a [user segment](/docs/admin/segments) to see analytics for a specific customer group. Compare how enterprise customers engage versus free-tier users, or see response times for your highest-value accounts.

## Next steps

- [Inbox](/docs/admin/inbox) — Triage and respond to feedback
- [Segments](/docs/admin/segments) — Create user groups for filtered analytics
- [Roadmap](/docs/admin/roadmap) — Turn analytics insights into a public plan

- [Organize feedback with boards](https://quackback.io/docs/admin/boards): Organize feedback into categories so users know where to post.

# Organize feedback with boards

Keep feature requests separate from bug reports. Boards let you organize feedback the way that makes sense for your product.

## Why Use Multiple Boards?

Without boards, everything piles up in one place. Your team wastes time sorting through noise, and users don't know where to post.

Common board setups:
- **Feature Requests** + **Bug Reports** - Simple and effective
- **Feature Requests** + **Bug Reports** + **Integrations** - When you have lots of integration requests
- **Mobile** + **Web** + **API** - Separate by platform

## Create a board

1. Go to **Admin → Settings → Boards**
2. Click **"New board"**
3. Fill in the details:

| Field | What it does |
|-------|--------------|
| Board name | Display name (e.g., "Feature Requests") |
| Description | Optional text shown on the board page |

4. Click **Create board**

New boards default to the **Public** preset: anyone can view, and sign-in is required to vote, comment, and submit. The create dialog shows two preset tiles:

- **Public** — "Anyone can view. Sign-in for vote, comment, submit."
- **Private** — "Workspace members only. Hidden from the portal."

Below the tiles, the **Customize access after create** checkbox ("open the Access tab to fine-tune.") controls where you land. Leave it unchecked to return to the board list. Check it to open the new board's [Access tab](#access-tab), where you can adjust per-action tiers and segments right away.

## Board Settings

Select a board to see its settings. Each board has five tabs, in order: **General**, **Access**, **Moderation**, **Import Data**, and **Export Data**.

### General Tab

Edit the board's basic information:
- **Board name** - The display name
- **Description** - Optional description

The Danger Zone at the bottom lets you delete the board.

### Access tab

Who can do what on this board is set in a per-action permissions matrix. Changing board access is admin-only — the update is enforced on the server, and every change is recorded in the [audit log](/docs/admin/security#audit-log).

The matrix is a permanent 4×4 grid. The rows are four independent actions:

- **View** — see posts and discussion
- **Vote** — upvote posts to signal interest
- **Comment** — reply on existing posts
- **Submit posts** — create new feedback

The columns are four tiers, from most open to most restrictive:

- **Anyone** — public, no sign-in
- **Signed-in** — any logged-in user
- **Segments** — specific audience groups
- **Team only** — workspace members

Each action gets its own tier, so access can be asymmetric. A board can let **Anyone** View while only **Signed-in** users Vote, Comment, and Submit posts.

#### Presets

Two presets summarize the common setups:

- **Public** — View: **Anyone**; Vote, Comment, Submit posts: **Signed-in**.
- **Private** — all four actions: **Team only** (hidden from the portal).

Clicking a preset restores all tiers to it. Editing any cell switches the matrix to **Custom** — Custom is derived from the grid, not a button you pick.

#### Choose segments per action

When you set an action to **Segments**, click the cell to open a picker and choose one or more [segments](/docs/admin/segments) — up to 50 per action. Each action keeps its own allowlist. The cell previews the first segment name, a count badge for the rest, and an estimated reach.

If an action is set to **Segments** with no segments chosen, the cell shows a red "Pick segments" warning, and Save is disabled with the message "Some rules use Segments but no segments are selected." Switching an action away from **Segments** clears that action's list.

The Access tab controls **who** can perform each action. Whether non-team posts and comments need approval before publishing is set separately on the Moderation tab — see [Moderation](/docs/admin/moderation).

### Moderation tab

The Moderation tab sets per-board approval rules, separate from access. There are three rules, each a tri-state segmented control:

- **Anonymous posts**
- **Signed-in posts**
- **Comments**

Each rule has three options: **Inherit**, **On**, and **Off**. **Inherit** defers to the workspace moderation default, and the Inherit pill shows the resolved value (for example, "Inherit (On)"). **On** force-holds matching submissions for review. **Off** always publishes them.

A banner reads "Inheriting all workspace defaults" or "This board overrides some workspace defaults", with a link to workspace settings. Held items appear in the [moderation review queue](/docs/admin/moderation#review-queue). Team members' own posts and comments always publish immediately and bypass moderation.

For the full two-level model — workspace defaults plus per-board overrides — see [Moderation](/docs/admin/moderation).

### Import Data Tab

Import posts from a CSV file into this board. See [Import & Export](/docs/admin/import-export) for format details.

### Export Data Tab

Download all posts from this board as CSV.

## Edit a board

1. Go to **Admin → Settings → Boards**
2. Select the board from the dropdown
3. Navigate to the **General** tab
4. Update settings
5. Click **Save changes**

## Delete a board

1. Go to **Admin → Settings → Boards**
2. Select the board
3. Go to the **General** tab
4. Scroll to the Danger Zone
5. Click **Delete board** and confirm

## Need to Keep Feedback Internal?

Set each action's tier to fit the use case:

| Use case | How to set it |
|----------|---------------|
| Internal team feedback | View, Vote, Comment, Submit posts all **Team only** (this is the **Private** preset). |
| Beta program | View → **Segments** (your beta-testers segment); Vote, Comment, Submit posts → **Signed-in** or the same segment. |
| Enterprise-only roadmap | View → **Segments** (an enterprise segment); keep Submit posts → **Team only** so only your team posts; Vote and Comment → **Segments**. |
| Hide from search engines but open to signed-in users | View → **Signed-in**; set Vote, Comment, and Submit posts as you like. |

## Migrate from another platform?

If you're moving from Canny, Nolt, or another tool:

1. Export data from the old platform as CSV
2. Format to match Quackback's import format
3. Go to **Admin → Settings → Boards** → select board → **Import Data**
4. Verify vote counts and dates imported correctly

## Next Steps

- [Statuses](/docs/admin/statuses) - Define your workflow stages
- [Tags](/docs/admin/tags) - Add organizational labels
- [Roadmap](/docs/admin/roadmap) - Show public progress

- [Customize your portal](https://quackback.io/docs/admin/branding): Add your logo, colors, and fonts so the portal feels like your product.

# Customize your portal

Make your feedback portal feel like part of your product. Add your logo, colors, and fonts so users never feel like they've left your app.

## Overview

Access branding settings from **Admin → Settings → Branding**. Changes preview in real-time before you save.

## Identity

### Logo

1. Go to **Admin → Settings → Branding**
2. Click on the logo placeholder or existing logo
3. Select an image file
4. Crop the image as needed
5. The logo is uploaded automatically

### Remove Logo

1. Click the **Remove** link below the logo
2. The logo is removed and the workspace initial is shown instead

### Workspace Name

Enter your workspace name in the text field. Changes are saved automatically after a short delay.

## Theme Mode

Control how light/dark mode works for portal visitors:
- **User choice (allow toggle)** - Visitors can switch between light and dark mode
- **Light only** - Portal always displays in light mode
- **Dark only** - Portal always displays in dark mode

## Color Scheme

Quackback offers two branding modes, toggled by the **Simple** / **Advanced** switch:

### Simple Mode

Customize your portal using color pickers and dropdowns:

#### Colors

Set your portal's color palette with the following inputs:

| Color | What it controls |
|-------|-----------------|
| Primary | Buttons, links, active states |
| Secondary | Secondary UI elements |
| Accent | Accent highlights |
| Background | Page background |
| Foreground (Text) | Main text color |

Click the color swatch to open the color picker, or type a hex code directly.

#### Font

Choose a font family from the dropdown. Fonts are organized by category:
- **Sans Serif** - Clean, modern fonts like Inter, Roboto, Open Sans, DM Sans, Geist, and more
- **Serif** - Traditional fonts like Playfair Display, Merriweather, Lora
- **Monospace** - Technical fonts like Fira Code, JetBrains Mono
- **System** - Uses the visitor's system font (System UI)

#### Corner Roundness

Adjust the roundness of buttons and cards using the slider:
- **Sharp** (left) - Square corners
- **Round** (right) - Fully rounded corners

A preview of the corner radius is shown next to the slider.

### Advanced Mode

For full control, use theme presets or write custom CSS:

- **Theme Presets** - Start from curated themes (e.g., Catppuccin, Supabase, Neo Brutalism)
- **Custom CSS** - Write custom CSS with `:root \{\}` and `.dark \{\}` blocks using CSS custom properties. Design your theme at [tweakcn.com](https://tweakcn.com) and paste it in.

## Preview

The right side of the branding page shows a live preview of your portal with the current settings. Use the **Light/Dark** toggle at the top of the preview to see how your branding looks in both modes.

## Save changes

After making changes, click **Save Changes** at the bottom of the controls panel to apply them to your portal. Identity changes (logo and workspace name) save automatically.

## Best Practices

### Consistent Branding

### Accessibility

### Mobile Experience

Preview on mobile viewport:
- Ensure the logo scales properly
- Verify touch targets are large enough
- Test dark mode on mobile

### Minimalism

Less is often more:
- A clean, simple design builds trust
- Avoid overly bright or clashing colors
- Let content be the focus

## Next Steps

- [Boards](/docs/admin/boards) - Organize your feedback
- [Team](/docs/admin/team) - Invite team members
- [Integrations](/docs/integrations/overview) - Connect external tools

- [Share updates with changelog](https://quackback.io/docs/admin/changelog): Announce shipped features and link them back to the feedback that inspired them.

# Share updates with changelog

Close the loop with your users. The changelog lets you announce what you've shipped and connect each update back to the feedback that inspired it.

## Overview

Access the changelog from **Admin → Changelog** in the sidebar. You can:

- Write and publish release notes
- Link changelog entries to feedback posts
- Schedule entries for future publication
- Filter entries by status (draft, scheduled, published)

## Create a changelog entry

1. Click **New Entry** in the top right
2. Enter a title and write your content using the rich text editor
3. Choose a publish state:

| State | Description |
|-------|-------------|
| **Draft** | Saved but not visible to users |
| **Scheduled** | Publishes automatically at the chosen date and time |
| **Published** | Live and visible on the public changelog |

4. Click **Save**

## Link feedback posts

Connect changelog entries to the feedback that drove them. Linked posts appear as metadata on the entry, showing users their voice was heard.

1. Open a changelog entry in the editor
2. In the settings panel, find **Linked Posts**
3. Search and select the posts that shipped in this update

When users view a published changelog entry, they see which feedback posts were addressed.

## Edit and delete entries

Click any entry in the list to open its editor. You can update the title, content, publish state, and linked posts at any time.

To delete an entry, open it and click **Delete**. A confirmation dialog prevents accidental deletion.

## Filter entries

Use the filter buttons at the top of the list to show:

- **All** - every entry regardless of status
- **Draft** - unpublished drafts
- **Scheduled** - entries awaiting their publish date
- **Published** - live entries

## Next steps

- [Inbox](/docs/admin/inbox) - Triage the feedback that inspires your changelog
- [Roadmap](/docs/admin/roadmap) - Show users what's coming next
- [Statuses](/docs/admin/statuses) - Track feedback from idea to shipped

- [Import and export data](https://quackback.io/docs/admin/import-export): Bring existing feedback from other tools or export for backups.

# Import and export data

Bring your existing feedback with you. Whether you're migrating from Canny, UserVoice, or a spreadsheet, import preserves your vote counts, dates, and history. Export anytime for backups or analysis.

## CSV Import

### Supported Data

Import posts into any board:
- Titles and content
- Statuses and tags
- Author information
- Vote counts
- Dates

### Import Process

1. Go to **Admin → Settings → Boards**
2. Select the target board
3. Click the **Import Data** tab
4. Drop a CSV file or click to browse
5. Click **Import Data** to start the import
6. Review the results

### CSV Format

#### Required Columns

| Column | Description |
|--------|-------------|
| `title` | Post title (required) |
| `content` | Post body (required) |

#### Optional Columns

| Column | Description | Format |
|--------|-------------|--------|
| `status` | Status slug | Must match existing status slug |
| `tags` | Tag names | Comma-separated |
| `board` | Board slug | Must match existing board |
| `author_name` | Author display name | Text |
| `author_email` | Author email | Valid email |
| `vote_count` | Number of votes | Integer |
| `created_at` | Creation date | ISO 8601 |

### Example CSV

```csv
title,content,status,tags,board,author_name,author_email,vote_count,created_at
"Add dark mode support","It would be great to have a dark mode option for the app.","open","feature,ui","","John Doe","john@example.com","5","2024-01-15T10:30:00Z"
"Fix login timeout","Users are being logged out too quickly.","under_review","bug","","","","2",""
```

### Import Limits

| Limit | Value |
|-------|-------|
| File size | 10 MB |
| Rows | 10,000 |
| Columns | Unlimited |

### Handle statuses

### Handle tags

Tags are created automatically:
- New tags created on import
- Comma-separated in CSV
- Report shows created tags

### Import Results

After import, you'll see a summary showing:

- Number of posts imported
- Number of rows skipped
- Number of new tags created
- Any row-level errors (expandable to view details)

## CSV Export

### Export Process

1. Go to **Admin → Settings → Boards**
2. Select a board
3. Click the **Export Data** tab
4. Click **Export CSV**
5. Download starts automatically

### Export Format

Exported CSV includes:

| Column | Description |
|--------|-------------|
| `title` | Post title |
| `content` | Post content |
| `status` | Status name |
| `tags` | Comma-separated tags |
| `board` | Board slug |
| `author_name` | Author display name |
| `author_email` | Author email |
| `vote_count` | Number of votes |
| `created_at` | Creation timestamp |

### Export Scope

Export is per-board. Select the board you want to export from the board dropdown, then navigate to the Export Data tab.

### Use Cases

- **Backup** - Regular data exports
- **Analysis** - Import into spreadsheets
- **Migration** - Move to another system
- **Reporting** - Share with stakeholders

## Migrate from Canny

Quackback ships a dedicated Canny importer — a command-line tool that connects to the Canny API and migrates everything automatically. No manual CSV export needed.

### What gets imported

- **Posts** — titles, descriptions, statuses, images, and creation dates
- **Votes** — individual voter attribution preserved (proxy voting per email)
- **Comments** — threaded, with internal comments routed to private notes
- **Tags & categories** — Canny categories imported as tags
- **Changelog entries** — with linked post relationships preserved
- **Merge relationships** — resolved and replayed
- **Users** — collected from all entities, identified by email

### Run the import

The Canny importer is a command-line tool that reads from the Canny API and writes through your Quackback REST API.

1. Create a Quackback API key in **Admin → Settings → API Keys**
2. Create your target boards in the admin UI first — the importer matches Canny boards by name
3. Grab your Canny API key from your Canny settings
4. Validate with a dry run, then run the import:

```bash
# Validate only — no data written
bun scripts/import/cli.ts canny \
  --api-key YOUR_CANNY_API_KEY \
  --quackback-url https://feedback.yourapp.com \
  --quackback-key qb_xxx \
  --dry-run --verbose

# Run it for real
bun scripts/import/cli.ts canny \
  --api-key YOUR_CANNY_API_KEY \
  --quackback-url https://feedback.yourapp.com \
  --quackback-key qb_xxx \
  --verbose
```

The import is additive — existing posts are not deleted, and duplicate votes (same user and post) are skipped.

### CSV import from Canny

If you prefer to use a CSV export instead, you can still import manually. Export from Canny and map the columns:

- `title` → `title`
- `details` → `content`
- `status` → `status`
- `votes` → `vote_count`

## Migrate from other platforms

### From UserVoice

1. Export from UserVoice (CSV format)
2. Map columns:
   - `suggestion_title` → `title`
   - `suggestion_text` → `content`
   - `status` → `status`
   - `vote_count` → `vote_count`

### From Spreadsheet

If you've been tracking feedback in a spreadsheet:

1. Add column headers matching Quackback format
2. Ensure dates are ISO 8601 format
3. Clean up status values to match your status slugs
4. Export as CSV (UTF-8 encoding)

## Best Practices

### Before Import

### Data Cleaning

Common issues to fix:

| Issue | Solution |
|-------|----------|
| Extra whitespace | Trim cells |
| Inconsistent statuses | Normalize names |
| HTML in content | Convert to markdown |
| Date formats | Use ISO 8601 |
| Encoding issues | Save as UTF-8 |

### Large Imports

## Troubleshooting

### "Invalid CSV format"

- Check file encoding (use UTF-8)
- Verify proper quoting for fields with commas
- Ensure consistent column count

### "Status not found"

- Create the status before importing
- Check spelling matches exactly

### "Date parse error"

- Use ISO 8601: `2024-01-15T10:30:00Z`
- Or: `2024-01-15` (date only)

### "Import stuck"

- Large files take time
- Check browser console for errors
- Try smaller batches

## Next Steps

- [Boards](/docs/admin/boards) - Manage import targets
- [Statuses](/docs/admin/statuses) - Set up statuses before import
- [Feedback](/docs/admin/inbox) - View imported posts

- [Triage feedback in the inbox](https://quackback.io/docs/admin/inbox): Filter, triage, and respond to feedback from a single inbox.

# Triage feedback in the inbox

Stop context-switching between tools. The feedback view is your command center. See everything users are asking for, triage quickly, and respond without leaving the page.

## Overview

Access the feedback view from **Admin → Feedback** in the sidebar. You can:

- See all feedback across boards in one place
- Filter by status, board, or tags to focus your work
- Update statuses and respond to users inline
- Add promising ideas to your public roadmap

## Feedback Interface

### List View

The feedback list displays posts in rows with:

| Column | Description |
|--------|-------------|
| Votes | Vote count with upvote indicator |
| Title | Post title with content preview |
| Status | Current workflow status badge |
| Board | Which board the post belongs to |
| Tags | Applied tags (if any) |
| Date | When the post was submitted |

Click any row to navigate to the post detail page.

### Post Detail Page

When you click a post, you're taken to the detail page which shows:

- Complete content with formatting
- Comment thread (including private internal notes visible only to team members)
- Activity timeline showing all post events
- Properties panel (Status, Board, Tags, Roadmaps)
- Author information
- Similar posts (when AI finds related feedback)
- Feedback source details (for posts created from integrations)

## Filtering

Use the filter sidebar to narrow down posts:

### By Status
Filter by workflow status. Click a status to select it, or Ctrl/Cmd+click to select multiple statuses.

### By Board
Select one or more boards to filter by feedback type.

### By Tags
Show posts with specific tags applied. Click tags to toggle them on/off.

### By Segment
Filter feedback by [user segment](/docs/admin/segments). Select a segment to see only posts from users in that group -- useful for understanding what enterprise customers or free-tier users are asking for.

### By Owner
Filter by the team member assigned to a post. Select a name from the "Assigned to" dropdown, or choose "Unassigned" to find posts that haven't been picked up yet.

### By Date Range
Filter posts created within a specific timeframe. Set a start date, end date, or both.

### By Minimum Votes
Set a vote threshold to surface high-demand requests. Posts with fewer votes are hidden.

### By Comment Count
Set a comment threshold to find highly-discussed posts. Choose from presets (1+, 5+, 10+, 25+, 50+) or use "1+ comments" to find any post with at least one comment. This is also useful for finding posts with zero engagement when combined with other filters.

### Search
Use the search bar at the top to search across titles and content.

## Sorting

Sort posts using the dropdown next to the search bar:

| Option | Description |
|--------|-------------|
| Newest | Most recently created first |
| Oldest | Oldest posts first |
| Votes | Highest vote count first |

## Post Actions

### Change Status

From the list view:
1. Hover over a post row
2. Use the quick status dropdown that appears on the right

From the detail page:
1. Click the status in the Properties panel
2. Choose the new status from the dropdown

**While commenting**: Team members can also change a post's status directly from the comment form. A status selector appears next to the comment button, letting you update the status and leave a comment in one action. The status change is displayed inline in the comment thread.

### Private Comments

Team members can post private comments for internal-only discussion. Click the **Private** button (lock icon) next to the submit button to toggle private mode - the button turns amber when active. Private comments display with an amber left border and an "Internal note" badge to distinguish them from public comments.

Private comments are only visible to other team members. Portal users and anonymous visitors never see them, and they don't count toward the public comment count. Replies to private comments are always private automatically.

### Add Tags

1. Open a post in the detail page
2. In the Properties panel, click "Add" next to Tags
3. Select tags from the dropdown

To remove a tag, click the X on the tag badge.

### Add to Roadmap

1. Open a post in the detail page
2. In the Properties panel, find the Roadmaps section
3. Click "Add" and select a roadmap

Posts on roadmaps appear in the public roadmap view.

### Assign an Owner

Assign a team member to take responsibility for a post:

1. Open the post detail page
2. Use the owner dropdown in the properties panel
3. Select a team member, or clear the assignment

Filter the inbox by owner to see your assigned posts or find unassigned work.

### View and Add Voters

The properties panel shows a voter avatar stack — small profile pictures of the first few voters, plus a count of remaining voters.

**View all voters:**
1. Click the avatar stack to open the full voter list
2. The modal shows each voter with their name and how their vote was added
3. Proxy votes show which admin added the vote on the user's behalf

**Add a vote on behalf of a user:**
1. Click **Add voter** next to the avatar stack
2. Search for an existing user by name or email
3. Click the user to add their vote

If the user doesn't exist yet, click **Create new user** at the bottom of the search list to create them and add their vote in one step.

**Remove a vote:**
1. Click the avatar stack to open the voter list
2. Hover over any voter row to reveal the remove button
3. Click the **X** to remove that user's vote

Removing a vote works for any vote type — proxy, integration, or direct. A `vote.removed` activity entry is recorded on the post timeline.

### Merge Duplicate Posts

Combine duplicate feedback to consolidate votes and discussion:

1. Open a post you want to merge
2. In the **Merge** section, search for the other post
3. Choose the merge direction — pick which post to keep as the canonical post and which becomes the duplicate
4. Click **Merge** to confirm

After merging:
- The duplicate shows a banner linking to the canonical post
- Votes are deduplicated and consolidated (unique voters only)
- The canonical post displays a "Merged Feedback" section listing all merged duplicates
- An activity entry is recorded on both posts

To reverse a merge, open the canonical post, find the merged post in the Merged Feedback section, and click **Unmerge**.

### Delete and Restore Posts

Posts can be soft-deleted from the edit dialog or post menu. Deleted posts are hidden from public views but preserved for 30 days.

If the post has linked issues in an [integration](/docs/integrations/overview) like Linear, GitHub, or Jira, you'll see checkboxes to archive or close those issues at the same time. Each integration's default behavior is configurable under **Admin → Settings → Integrations**.

To view deleted posts, enable the **Show deleted** toggle in filters. To restore a deleted post, open it and click **Restore**.

## AI Summaries

Posts with comments display an AI-generated summary card in the post detail view. Summaries help you quickly understand what users are asking for without reading every comment.

Each summary includes:

- **Overview** - 1-3 sentences capturing the core user need
- **Key quotes** - Notable comments from users (not team replies)
- **Next steps** - Suggested actions like "Investigate...", "Reproduce...", or "Respond to..."

### Staleness detection

Summaries automatically detect when new comments have been added since the last generation. A **Stale** badge appears next to the timestamp when the summary is out of date. Stale summaries are refreshed automatically in the background.

## Activity Timeline

Every post has an activity timeline that records key events in its lifecycle. The timeline appears below the comment thread on the post detail page.

| Event | Description |
|-------|-------------|
| Post created | When and how the post was created (direct submission, suggestion, API) |
| Post deleted | Post was soft-deleted |
| Post restored | A deleted post was restored |
| Status changed | Shows old and new status with who made the change |
| Post merged | Another post was merged into this one, with a link to the duplicate |
| Post merged away | This post was merged into another, with a link to the canonical post |
| Post unmerged | A previously merged post was separated |
| Proxy vote | A vote was added on behalf of a user, with attribution |
| Vote removed | A vote was removed from the post |
| Owner assigned | A team member was assigned to the post |
| Owner unassigned | The assigned owner was removed |
| Tags added | Tags were applied to the post |
| Tags removed | Tags were removed from the post |
| Roadmap added | Post was added to a roadmap |
| Roadmap removed | Post was removed from a roadmap |
| Comments locked | Comments were locked on the post |
| Comments unlocked | Comments were unlocked |
| Comment pinned | A comment was pinned to the top |
| Comment unpinned | A pinned comment was unpinned |

The timeline is sorted chronologically with the most recent events at the top. Each entry shows the actor (who performed the action) and a timestamp.

## AI Suggestions

Quackback automatically detects duplicate posts and suggests merges. Feedback from integration sources like Slack is analyzed and turned into actionable suggestions — either voting on an existing post or creating a new one.

See [Triage AI suggestions](/docs/admin/suggestions) for the full guide.

## Keyboard Shortcuts

| Key | Action |
|-----|--------|
| `j` / `ArrowDown` | Navigate to next post |
| `k` / `ArrowUp` | Navigate to previous post |
| `Enter` | Open selected post |
| `Esc` | Clear focus |
| `/` | Focus search input |

## Tips

### Process workflow

### Find duplicates

Quackback [automatically detects duplicate posts](/docs/admin/suggestions) and suggests merges. You can also use the search function to find similar posts manually before changing their status.

### Engage users

## Next steps

- [AI Suggestions](/docs/admin/suggestions) - Triage duplicate detection and merge suggestions
- [Boards](/docs/admin/boards) - Organize feedback into boards
- [Statuses](/docs/admin/statuses) - Customize your workflow
- [Roadmap](/docs/admin/roadmap) - Manage your public roadmaps
- [Segments](/docs/admin/segments) - Group users to filter feedback
- [Changelog](/docs/admin/changelog) - Announce shipped features

- [Moderation](https://quackback.io/docs/admin/moderation): Hold incoming posts and comments for review, and control who can interact anonymously.

# Moderation

Keep low-quality posts and spam out without slowing real users down. Moderation lets you hold non-team posts and comments for review before they go public, and decide whether anonymous visitors can interact at all.

Workspace-wide controls live at **Admin → Settings → Moderation**. Per-board overrides and the review queue are covered below.

## Allow anonymous interaction

Decide whether visitors without an account can interact with your portal at all. The master switch is **Allow anonymous interaction**: "When off, all boards require sign-in for voting, commenting, and submitting posts."

By default this is **on** — new workspaces let anonymous visitors take part. It acts as a ceiling across every board for **Vote**, **Comment**, and **Submit** only. **View** is never gated by it, because anyone being able to view a public board is the definition of public.

When you turn it off:

- The board [Access tab](/docs/admin/boards#access-tab) disables the **Anyone** tier for Vote, Comment, and Submit.
- The server rejects anonymous votes, comments, and submissions.

## Approval rules

Require approval before submissions appear publicly. Two independent toggles set the workspace defaults:

- **Require approval for anonymous posts** — posts from visitors without an account wait for review before they appear.
- **Require approval for signed-in posts** — posts from signed-in portal users wait for review before they appear.

Turn on either one to hold those submissions for review. Leave both off to publish everything immediately. You can hold one group without the other — for example, hold anonymous posts while letting signed-in users post straight through.

These are workspace defaults. Individual boards can override them on the [board Moderation tab](/docs/admin/boards#moderation-tab).

## Per-board overrides

Need a different rule for one board? Each board can override the workspace defaults on three axes — **Anonymous posts**, **Signed-in posts**, and **Comments** — from the [board Moderation tab](/docs/admin/boards#moderation-tab).

Each axis is set to one of three values:

| Value | What it does |
|-------|--------------|
| **Inherit** | Use the workspace default. The pill shows the resolved value, e.g. **Inherit (On)**. |
| **On** | Always hold submissions for review. |
| **Off** | Always publish submissions immediately. |

## Review queue

Approve or reject held items at **Admin → Moderation**, titled **Moderation Queue**. The queue has two sections, **Pending posts** and **Pending comments**. Each item shows the author (or **Anonymous**), the board, and the content, with **Approve** and **Reject** buttons.

- **Approve** publishes the item. A held comment then counts toward the post's public comment total.
- **Reject** removes it from the queue. Rejected items are soft-deleted and can be restored from the admin.

The queue is available to team members — both admins and members.

## Next steps

- [Boards](/docs/admin/boards) — set per-board access and moderation on the Access and Moderation tabs
- [Portal access](/docs/admin/portal-auth) — choose who can view and sign in to your portal
- [Audit log](/docs/admin/security#audit-log) — review every moderation and access change

- [Configure admin notifications](https://quackback.io/docs/admin/notifications): Control which feedback events trigger alerts for your team.

# Configure admin notifications

Never miss what matters. Get notified when users comment on posts you're tracking or when teammates change statuses so you can respond quickly and keep the conversation going.

## Overview

Access Notifications from **Admin → Notifications** in the sidebar. You'll see:

- New comments on posts you're subscribed to
- Status changes from teammates
- Activity that needs your attention

## Notifications Interface

### Header

The notifications header displays:

- **Total count** - Total number of notifications
- **Unread count** - Number of unread notifications (shown as badge)
- **Mark all as read** - Button to clear all unread indicators

### Notification List

Each notification shows:

- Activity type icon
- Post title and description
- Who triggered the notification
- When it happened
- Read/unread indicator

Click a notification to navigate to the relevant post.

## Notification Types

### Status Changes

Receive notifications when a post's status changes:

- Post moved from "Open" to "Planned"
- Post marked as "Complete"
- Post status changed by another team member

### New Comments

Receive notifications when someone comments on a post you're subscribed to:

- Portal users adding feedback
- Team members responding
- Replies to existing comments

## Manage notifications

### Mark as Read

Click a notification to mark it as read and navigate to the post.

### Mark All as Read

Click **Mark all as read** in the header to clear all unread indicators.

## Subscriptions

You automatically receive notifications for:

- Posts you created
- Posts you voted on
- Posts you commented on
- Posts you manually subscribed to

### Subscribe to a post

1. Open a post in the feedback view
2. Click the **Subscribe** button (or look for the bell icon)
3. You'll receive notifications for that post

### Unsubscribing

1. Open a post you're subscribed to
2. Click the **Unsubscribe** button
3. You'll stop receiving notifications for that post

## Notification Behavior

### Real-time Updates

Notifications appear in real-time as activity happens. The unread count in the sidebar updates automatically.

### No Duplicates

You won't receive duplicate notifications for the same event, even if you're subscribed through multiple means (creator + commenter).

### Self-Actions

You won't receive notifications for your own actions (your own comments, status changes you make).

## Best Practices

### Manage Your Subscriptions

### Respond to feedback

When you receive a notification about a new comment:

1. Open the post from the notification
2. Review the comment context
3. Respond or take action as needed
4. The notification is marked as read

### Stay on top of changes

## Access

All team members (Admins and Members) have access to the notifications page. Notifications are personal - you only see notifications for posts you're subscribed to.

## Next Steps

- [Managing Feedback](/docs/admin/inbox) - Work through your feedback queue
- [Team Members](/docs/admin/team) - See who's on your team

- [Control portal access and sign-in](https://quackback.io/docs/admin/portal-auth): Choose who can view your portal and how they sign in.

# Control portal access and sign-in

Pick who can see your feedback portal and which sign-in methods they use. Quackback separates the two concerns: **Portal access** decides who's allowed in, and **Sign-in providers** decides how they authenticate.

Configure both at **Admin → Settings → Security → Authentication**. The page has three tabs:

| Tab | Controls |
|-----|----------|
| **Portal access** | Visibility, allowed domains, email invites, allowed segments, widget sign-in |
| **Team access** | Team-side 2FA and the SSO summary — see [Security](/docs/admin/security) |
| **Sign-in providers** | Password, magic link, social OAuth, and Custom OIDC for both surfaces |

## Portal access

A portal is either **public** or **private**. Public portals are open to everyone, including unsigned visitors. Private portals admit only the visitors you authorize through the channels below.

| Visibility | Who gets in |
|------------|-------------|
| **Public** | Anyone, no sign-in required. Signed-in users can still vote, comment, and post. |
| **Private** | Your team, plus anyone covered by an allow-channel below. |

A private portal evaluates these channels in order. The first match grants access.

1. **Team** — admins and members always have access.
2. **Allowed email domains** — verified-email users on a listed domain.
3. **Email invite** — anyone you've sent and who's accepted a portal invite.
4. **Allowed segments** — members of a [segment](/docs/admin/segments) you've authorized.
5. **Widget sign-in** — visitors who already signed in via your embedded widget.

Visitors who don't match any channel are redirected to sign in. Authenticated visitors who still don't match see a clear "no access" screen with sign-out and account links.

### Allowed email domains

Auto-admit any verified-email user whose address ends with a domain you list. Useful for "all `@acme.com` employees can see the portal" without sending individual invites.

1. Open the **Portal access** tab.
2. Under **Allowed email domains**, type a domain (e.g. `acme.com`) and press Enter.
3. Repeat for additional domains. Domains save automatically.

### Email invites

Invite specific people by email. Each invite is good for a magic link that signs the recipient in and grants portal access automatically.

1. Open the **Portal access** tab (or **Admin → Users → Invitations**).
2. Click **Invite people**.
3. Paste up to 50 email addresses separated by commas, spaces, or newlines.
4. Optionally add a short personal message (up to 500 characters) — it's included in the email.
5. Click **Send invites**.

Each recipient gets a branded email with the personal message and a sign-in link. The link is good for 14 days; pending invites expire automatically after that.

Track invite status from **Admin → Users → Invitations**:

| Status | Meaning |
|--------|---------|
| Pending | Sent, not yet accepted. Resend or revoke from the row. |
| Accepted | Recipient followed the link and now has portal access. |
| Revoked | Admin cancelled the invite. The link no longer works. |
| Expired | Pending past the 14-day window. Send a fresh invite to retry. |

Every send, resend, accept, revoke, link-mint, and expiry is recorded in the audit log.

### Allowed segments

Use [segments](/docs/admin/segments) to grant portal access to a whole cohort at once — for example, "everyone on the Pro plan" or "all users from `@bigcorp.com`".

1. Open the **Portal access** tab.
2. Under **Allowed segments**, pick one or more segments from the multi-select.
3. The selection saves automatically.

Segment access works for any authenticated visitor whose principal is a member of one of the chosen segments **and** has a verified email. The verified-email guard mirrors the domain and invite channels: dynamic segments can predicate on email (e.g. "email ends with @acme.com"), so without verification an attacker could claim someone else's address and walk in.

### Widget sign-in

When your product embeds the [Quackback widget](/docs/widget) and uses [verified identity](/docs/widget/identify-users#verified-identity-with-jwt), you can let those visitors carry their widget identity over to the portal — no password, no second sign-up.

1. Verify your widget runs with **Verified identity only** on (Admin → Settings → Widget).
2. On the Portal access tab, toggle **Widget sign-in** on.

Visitors who open your portal from inside a verified widget session are signed into the portal automatically. Behind the scenes the widget mints a one-time token (OTT) and the portal exchanges it for a session.

## Sign-in providers

The **Sign-in providers** tab controls *how* visitors authenticate. Each method has independent toggles for the **Portal** (your customers) and **Team** (your admins). At least one method per surface always stays enabled.

| Method | Default (Portal) | Default (Team) |
|--------|------------------|----------------|
| Password | On | On |
| [Magic link](/docs/auth/magic-link) | Off | On |
| [Social OAuth](/docs/auth/oauth) (10 providers) | Off (configure first) | GitHub & Google on |
| Custom OIDC button | Off | Use [SSO](/docs/auth/sso) instead |

### Password

Email + password sign-in. 8 to 128 characters. Users request reset links by email.

### Magic link

One-click sign-in link sent by email.

- Default: Off
- Requires: Email delivery configured (SMTP or Resend). The toggle stays locked off until email is set up.

When both Password and Magic link are enabled, users can switch between methods on the sign-in form.

### OAuth providers

Quackback ships with 10 built-in social providers. Configure each one once and enable it for the Portal, Team, or both. Credentials are stored encrypted in the database; no environment variables to set.

A provider's toggle stays locked off until you've saved its Client ID and Client Secret. See [OAuth providers](/docs/auth/oauth) for the per-provider walkthrough.

### Custom OIDC

Bring your own OpenID Connect identity provider for a single button on the portal sign-in form. The configuration form auto-detects common providers (Microsoft Entra ID, Okta, Google Workspace, OneLogin) from the issuer URL and prefills sensible defaults.

- Default: Off
- Availability: Plans with the Custom OIDC feature. Lower tiers see a tier-lock badge.

For full team-wide SSO with verified domains, enforcement, and JIT provisioning, use [Single sign-on](/docs/auth/sso) instead.

## Anonymous interaction

Visitors can vote, comment, and submit feedback without creating an account when the workspace allows it. A single workspace switch, **Allow anonymous interaction**, controls all three. Find it at **Admin → Settings → [Moderation](/docs/admin/moderation)**. It applies to both the portal and the [embeddable widget](/docs/widget).

When it's off, every board requires sign-in to vote, comment, and submit. Viewing is unaffected.

This switch is a ceiling, not a per-board setting. Even when anonymous interaction is allowed, an individual board can still require sign-in or restrict an action to segments or your team on its [Access tab](/docs/admin/boards#access-tab).

When a visitor first interacts anonymously, a browser session is created transparently. Their action registers instantly with no sign-in prompt. If they later create an account, their existing anonymous votes are linked over automatically.

Anonymous sign-in is rate-limited to **50 new anonymous sessions per IP per hour**. Once a visitor has a session, casting or un-casting votes doesn't count against the limit.

## When all sign-in methods are disabled

The Sign-in providers tab refuses to disable the last enabled method, but if you've edited the configuration file or the database directly and turned every portal sign-in method off, the portal degrades gracefully:

- The **Log in** and **Sign up** buttons are hidden from the public portal header.
- **Team members can still sign in** by visiting `/admin/login` directly. The Team and Portal toggles are independent.
- **Portal users on a verified SSO domain** still see the Log in / Sign up buttons. The portal email dispatcher routes matching addresses into the SSO flow even when no other method is enabled. You can run an "SSO-only portal" by turning off every other portal method while keeping [Single sign-on](/docs/auth/sso) configured for your domain.

## Access control

| Role | Can view | Can modify |
|------|----------|------------|
| Admin | Yes | Yes |
| Member | No | No |

Every change to portal access, sign-in providers, or invites is recorded in the [audit log](/docs/admin/security#audit-log).

## Next steps

- [Team Members](/docs/admin/team) — manage your team and their access
- [Magic link sign-in](/docs/auth/magic-link) — passwordless email sign-in
- [OAuth providers](/docs/auth/oauth) — per-provider setup walkthroughs
- [Single sign-on](/docs/auth/sso) — team-wide SSO with verified domains
- [Segments](/docs/admin/segments) — group users for inbox filtering and access

- [Customize the portal home](https://quackback.io/docs/admin/portal): Greet visitors with a customizable welcome card above the post list.

# Customize the portal home

The portal home is the first thing visitors see when they open your feedback portal. The welcome card lets you greet them, set expectations, and point them at the right places to start.

## Overview

Open **Admin → Settings → Portal** to manage the welcome card. The card renders above the post list on the public portal home; the rest of the page (filters, board picker, post list) stays unchanged.

## Welcome card

The welcome card has three parts: a toggle, a title, and a rich text message body.

1. Go to **Admin → Settings → Portal**
2. Edit the **Title** and **Message** to taste
3. Use the live **Preview** to see what visitors will see
4. Toggle **Enable welcome card** on when you're ready
5. Click **Save**

The card is only rendered on the portal home when the toggle is on, so you can stage the next announcement and flip the switch when it's ready to go live.

### Message editor

The message body uses the same rich text editor as posts and comments. You can:

- Format with headings, bold, italic, lists, links, and inline code
- Drop in fenced code blocks for snippets
- Embed images uploaded through the editor (auto-rehosted to workspace storage)
- Insert emoji via the picker or shortcode

### Title length

Titles are capped at 200 characters. The editor enforces the limit as you type.

## Common uses

- **Frame what kind of feedback you want.** "We're looking for feature ideas — please raise bugs through support."
- **Surface the roadmap.** Link to a roadmap board or a public roadmap page so visitors see what's already planned.
- **Point at help docs.** Link to your help center so visitors can self-serve answers before filing a new request.
- **Announce a moderation policy.** Set expectations for tone, duplicates, and response time.

- [Manage privacy and data handling](https://quackback.io/docs/admin/privacy): Control how Quackback stores, encrypts, and processes user data.

# Manage privacy and data handling

Quackback is self-hosted, so your feedback data stays on your infrastructure. You control storage, encryption, and what (if anything) leaves your network.

## Data ownership

You own all data in your Quackback instance. Nothing is sent to external servers by default. Your database, your rules.

The only exception is AI features. When enabled, specific data is sent to OpenAI for processing. See [AI data handling](#ai-data-handling) below.

## What Quackback stores

| Category | Data stored |
|----------|-------------|
| Users | Email address, display name, avatar URL |
| Posts | Title, content, board, status, tags |
| Votes | User ID, post ID, timestamp |
| Comments | Author, content, parent post |
| Sessions | Session token, user ID, expiry |
| Integrations | OAuth tokens, webhook URLs, channel mappings |

## Encryption

### Tokens and secrets

Integration OAuth tokens (Slack, Discord, GitHub, Linear) are encrypted with **AES-256-GCM** using your `ENCRYPTION_KEY` environment variable.

### Passwords

Team member passwords are hashed with bcrypt. Plain-text passwords are never stored or logged.

### Sessions

Session tokens are cryptographically random. Sessions expire after 7 days of inactivity.

## AI data handling

When you enable AI features, Quackback sends data to OpenAI for processing.

### What is sent

| Feature | Data sent to OpenAI |
|---------|---------------------|
| Post summaries | Post title and content |
| Comment summaries | Comment text for the target post |
| Semantic search | Post content for embedding generation |
| Auto-tagging | Post title and content |

### What is not sent

User emails, passwords, session data, and integration tokens are **never** sent to OpenAI.

### Disable AI features

Set the following environment variable to disable all AI functionality:

```bash
DISABLE_AI=true
```

## Telemetry

Quackback collects minimal anonymous telemetry to improve the product: instance ID, version number, and feature usage counts. No user data or feedback content is included.

Disable telemetry with:

```bash
DISABLE_TELEMETRY=true
```

## User data deletion

Delete a user and their associated data. Go to **Admin → Settings → Users** → select the user → **Delete User**.

| Data | Behavior |
|------|----------|
| User record | Permanently deleted |
| Posts | Attributed to "Deleted User" |
| Votes | Removed and counts recalculated |
| Comments | Attributed to "Deleted User" |
| Sessions | Immediately invalidated |

## Data retention

| Data | Retention |
|------|-----------|
| Active posts | Kept until manually deleted |
| Soft-deleted posts | Permanently removed after 30 days |
| Sessions | Expire after 7 days of inactivity |
| Webhook failure logs | Cleared after 7 days |
| Audit logs | Kept indefinitely |

## GDPR considerations

As a self-hosted deployment, you are the **data controller**. Quackback is the software, not a data processor.

Your responsibilities include:

- Maintain a record of processing activities
- Respond to data subject access requests within 30 days
- Notify authorities of breaches within 72 hours
- Provide a lawful basis for processing feedback data

Use the [user deletion flow](#user-data-deletion) to fulfill right-to-erasure requests. For data portability, export feedback via CSV from **Admin → Settings → Boards → Export Data**. See [Import and export data](/docs/admin/import-export) for details.

## Security best practices

Protect your instance and your users' data:

- **Use TLS** — Run Quackback behind a reverse proxy (Nginx, Caddy) with HTTPS enabled
- **Rotate secrets** — Change your `ENCRYPTION_KEY` and `SESSION_SECRET` periodically
- **Back up regularly** — Schedule automated database backups
- **Restrict access** — Limit dashboard access to trusted team members
- **Keep updated** — Pull the latest Docker image for security patches

See [Configure team security](/docs/admin/security) for authentication and sign-in settings.

## Next steps

- [Configure team security](/docs/admin/security) — Set up team authentication and sign-in methods
- [Deploy with Docker](/docs/self-hosting/docker) — Run Quackback on your own infrastructure
- [Import and export data](/docs/admin/import-export) — Back up or migrate your feedback data

- [Build a public roadmap](https://quackback.io/docs/admin/roadmap): Show users what's planned, in progress, and complete.

# Build a public roadmap

Show users what you're building. A public roadmap builds trust. Users can see what's planned, in progress, and complete, and follow updates on features they care about.

## How It Works

The roadmap displays posts grouped by status in a kanban-style layout. Each column represents a status you've marked as "Show on Roadmap" in your status settings.

Users can:
- See what's coming next
- Vote on planned features
- Subscribe to get notified when items ship

## Create a roadmap

You can have multiple roadmaps for different purposes (e.g., "Product Roadmap", "API Roadmap").

1. Go to **Admin → Roadmap**
2. Click the **+** button in the sidebar
3. Fill in the details:
   - **Name** - Display name (e.g., "Product Roadmap")
   - **Description** - Optional description
   - **Public** - Toggle visibility to users
4. Click **Create**

## Add posts to the roadmap

### From a Post's Detail Page

1. Open a post in **Admin → Feedback**
2. In the Properties panel, find the **Roadmaps** section
3. Click **"Add"**
4. Select which roadmap to add the post to

### Using Drag and Drop

Once posts are on a roadmap, you can drag them between columns to change their status:

1. Click and hold a post card
2. Drag to the target status column
3. Release to update

The post's status updates automatically.

## Remove a post from roadmap

1. Open the post in the detail page
2. In the Roadmaps section, click the **X** on the roadmap badge

The post stays in Quackback. It's just not shown on the roadmap anymore.

## Roadmap Visibility

Each roadmap can be public or private:

| Setting | Who can see it |
|---------|----------------|
| **Public** | Everyone visiting your portal |
| **Private** | Only team members (indicated by lock icon) |

## Configure columns

The roadmap columns are determined by which statuses have "Show on Roadmap" enabled.

1. Go to **Admin → Settings → Statuses**
2. Use the toggle next to each status to enable/disable roadmap visibility
3. Changes save automatically

Most teams use: **Planned → In Progress → Complete**

## What Users See

On your public roadmap, users can see:
- Post title
- Vote count
- Status badge
- Brief description preview

Users do **NOT** see:
- Internal notes
- Team comments
- Assignment details

## Best Practices

### Keep It Updated

### Show Meaningful Items Only

Don't clutter the roadmap with minor tasks. Focus on:
- Major features
- Popular requests (high vote count)
- Significant improvements

### Avoid Specific Dates

### Celebrate Completed Items

Keep recently completed items visible temporarily:
- Users see progress happening
- Builds confidence in your team
- Archive old completed items periodically

### Communicate Changes

When plans change (and they will):
- Update the roadmap promptly
- Add comments to affected posts explaining why
- Notify subscribers of significant shifts

## Edit a roadmap

1. Hover over a roadmap in the sidebar
2. Click the **...** menu button
3. Select **Edit**
4. Update name, description, or visibility
5. Click **Save**

## Delete a roadmap

1. Hover over a roadmap in the sidebar
2. Click the **...** menu button
3. Select **Delete**
4. Confirm deletion

## Link from Your Product

Drive engagement by linking to your roadmap from your app:

- Footer links
- Help menu
- Feature request buttons

This turns your roadmap into a living communication channel with users.

## Next Steps

- [Statuses](/docs/admin/statuses) - Configure which statuses appear on roadmaps
- [Inbox](/docs/admin/inbox) - Manage feedback and add posts to roadmaps
- [Integrations](/docs/integrations/overview) - Get notified on status changes

- [Understand roles and permissions](https://quackback.io/docs/admin/roles-permissions): Control who can do what with three distinct account types.

# Understand roles and permissions

Give your team the access they need without exposing settings to everyone. Quackback uses three account types to separate customers from teammates, and teammates from workspace owners.

## Overview

Every person who interacts with your Quackback workspace has one of three roles:

| Role | Who they are | How they get access |
|------|-------------|---------------------|
| **Portal User** | Your customers and end users | Sign up through the [public portal](/docs/admin/portal-auth) |
| **Member** | Your teammates who manage feedback | [Invited by an admin](/docs/admin/team) |
| **Admin** | Workspace owners with full control | [Invited or promoted by an admin](/docs/admin/team) |

## Permission matrix

This table covers every capability in Quackback, grouped by category.

### Feedback

| Capability | Portal User | Member | Admin |
|------------|:-----------:|:------:|:-----:|
| Submit feedback | ✓ | ✓ | ✓ |
| Vote on posts | ✓ | ✓ | ✓ |
| Comment on posts | ✓ | ✓ | ✓ |
| Edit own posts | ✓ | ✓ | ✓ |
| Delete own posts | ✓ | ✓ | ✓ |

### Admin feedback management

| Capability | Portal User | Member | Admin |
|------------|:-----------:|:------:|:-----:|
| View feedback inbox | — | ✓ | ✓ |
| Change post statuses | — | ✓ | ✓ |
| Merge duplicate posts | — | ✓ | ✓ |
| Delete any post | — | ✓ | ✓ |
| Assign post owner | — | ✓ | ✓ |
| Add and remove tags | — | ✓ | ✓ |
| Add posts to roadmap | — | ✓ | ✓ |
| Pin official responses | — | ✓ | ✓ |
| Post private comments | — | ✓ | ✓ |
| Add proxy votes | — | ✓ | ✓ |

### Portal

| Capability | Portal User | Member | Admin |
|------------|:-----------:|:------:|:-----:|
| View public portal | ✓ | ✓ | ✓ |
| View public roadmap | ✓ | ✓ | ✓ |
| View changelog | ✓ | ✓ | ✓ |

### Admin dashboard

| Capability | Portal User | Member | Admin |
|------------|:-----------:|:------:|:-----:|
| Access admin panel | — | ✓ | ✓ |
| View analytics | — | ✓ | ✓ |
| View portal users list | — | ✓ | ✓ |
| Remove portal users | — | — | ✓ |

### Settings

| Capability | Portal User | Member | Admin |
|------------|:-----------:|:------:|:-----:|
| Manage boards | — | ✓ | ✓ |
| Manage statuses and tags | — | ✓ | ✓ |
| Branding and customization | — | — | ✓ |
| Portal authentication | — | — | ✓ |
| Integrations | — | — | ✓ |
| Team management | — | — | ✓ |
| Security settings | — | — | ✓ |
| API keys | — | — | ✓ |
| Import and export data | — | — | ✓ |

### Content

| Capability | Portal User | Member | Admin |
|------------|:-----------:|:------:|:-----:|
| Create changelog entries | — | ✓ | ✓ |
| Manage roadmaps | — | ✓ | ✓ |

## Portal Users

Portal Users are your customers. They interact with Quackback through the public-facing [feedback portal](/docs/admin/portal-auth), not the admin dashboard.

**How they sign up:** Portal Users create an account on your portal using the authentication methods you configure -- email OTP, OAuth, or [SSO](/docs/auth/sso).

**What they can do:**
- Submit feedback and bug reports
- Vote on posts they care about
- Comment on any post
- Edit and delete their own posts
- Browse the public [roadmap](/docs/admin/roadmap) and [changelog](/docs/admin/changelog)

## Team Members

Members are your teammates. They have everything Portal Users have, plus access to the admin dashboard where they triage and manage feedback.

**How they join:** An admin [invites them](/docs/admin/team) by email. They receive a link to join the workspace.

**What they can do beyond Portal Users:**
- Access the admin dashboard and [feedback inbox](/docs/admin/inbox)
- Change post [statuses](/docs/admin/statuses), merge duplicates, and assign owners
- Add [tags](/docs/admin/tags) and manage [roadmap](/docs/admin/roadmap) items
- Post private internal comments
- Create [changelog](/docs/admin/changelog) entries
- Manage [boards](/docs/admin/boards), statuses, and tags

Members cannot change workspace settings, manage integrations, or invite other team members.

## Admins

Admins have unrestricted access to everything in the workspace. They're the only ones who can configure settings that affect the entire workspace.

**Capabilities exclusive to Admins:**
- [Branding](/docs/admin/branding) and portal customization
- [Portal authentication](/docs/admin/portal-auth) configuration
- [Integration](/docs/integrations/overview) setup and management
- [Team management](/docs/admin/team) -- invite, promote, demote, remove
- [Security](/docs/admin/security) settings
- API key management
- Data [import and export](/docs/admin/import-export)
- Removing portal users

## Change roles

Promote or demote team members at any time from the team settings.

1. Go to **Admin → Settings → Team Members**
2. Find the member in the list
3. Click the **...** menu on their row
4. Select **Make admin** or **Make member**

Changes take effect immediately. Demoted Admins lose access to all admin-only settings but keep their dashboard access as a Member.

To convert a team member back to a Portal User, remove them from the team entirely. They keep their portal account and can still submit feedback.

## Next steps

- [Manage your team](/docs/admin/team) -- Invite members and assign roles
- [Configure team security](/docs/admin/security) -- Control sign-in methods
- [Core Concepts](/docs/getting-started/concepts) -- Review how roles fit into the bigger picture

- [Search across feedback](https://quackback.io/docs/admin/search): Find posts quickly using full-text search and filters.

# Search across feedback

Find the exact feedback you need in seconds. Search works everywhere you manage posts, so you spend less time scrolling and more time acting on what matters.

## Overview

Search is available in three places:

- **Admin → Feedback** - Search across all posts in your inbox
- **Admin → Feedback → Incoming** - Search AI suggestions by title or content
- **Portal** - Public search bar for end-users browsing your portal

## Basic search

Type keywords into the search bar at the top of the feedback list. Results update as you type, matching against post titles and content.

1. Navigate to **Admin → Feedback**
2. Click the search bar or press `/` to focus it
3. Type your keywords
4. Results filter in real time

## How search works

Search is powered by PostgreSQL full-text search. When you enter a query, Quackback matches against two fields:

| Field | What it covers |
|-------|----------------|
| Title | The post headline |
| Content | The full post body |

Matches are ranked by relevance. Posts where the query appears in the title rank higher than content-only matches.

## Search tips

- Use nouns and specific terms: "CSV export" instead of "exporting things to CSV"
- Search for exact feature names or error messages when looking for related reports
- Try alternative phrasing if your first search returns too few results

## Combine with filters

Search works alongside every filter in the sidebar. Combine them to narrow results precisely.

| Filter | Example use case |
|--------|-----------------|
| Status | Search "SSO" in posts marked "Planned" |
| Board | Search "billing" within Feature Requests only |
| Tag | Search "timeout" in posts tagged `api` |
| Segment | Search "onboarding" among Enterprise users |
| Date range | Search "mobile" in posts from the last 30 days |
| Vote count | Search "notifications" with 10+ votes |

Apply filters first, then search within the filtered set for the fastest results.

## Portal search

End-users can search your public portal directly. The search bar appears at the top of the portal page.

Portal search:

- Searches post titles and content, just like admin search
- Helps users find existing requests before submitting duplicates
- Reduces duplicate feedback by surfacing relevant posts early

## Next steps

- [Triage feedback in the inbox](/docs/admin/inbox) - Filter, sort, and respond to posts
- [Categorize posts with tags](/docs/admin/tags) - Label posts for better organization

- [Configure team security](https://quackback.io/docs/admin/security): Set team sign-in methods, require 2FA, and review the audit log.

# Configure team security

Control how your team signs in to the admin dashboard. Pick sign-in methods, require two-factor authentication, and review a tamper-evident log of every security-sensitive change.

Everything here lives under **Admin → Settings → Security**, which has a **Team** tab and a **Portal** tab. This page covers the Team tab plus the [Audit log](#audit-log).

## Team sign-in methods

On the **Team** tab, the **Sign-in methods** card controls how team members sign in.

| Method | Description |
|--------|-------------|
| **Password** | Email and password. Can't be turned off while it's the only method, or while Require 2FA is on. |
| **Magic link** | A one-click link emailed to the user. See [magic-link sign-in](/docs/auth/magic-link). |
| **Require 2FA for team members** | Forces a TOTP code on every password sign-in. |
| **Email me when a new device signs in** | Notifies the account owner on sign-in from an unrecognized browser or network. On by default. |

Single sign-on is configured separately on the [SSO page](/docs/auth/sso).

## Two-factor authentication

Two-factor authentication (2FA) adds a 6-digit code from an authenticator app on top of a password. It has no effect on SSO sign-ins — SSO MFA is handled by your identity provider.

### Enroll in 2FA

Each team member enrolls themselves from their **account settings**:

1. Open **Account settings** and find **Two-factor authentication**.
2. Click **Set up authenticator** and confirm your password.
3. Scan the QR code with Google Authenticator, 1Password, Authy, or any TOTP app.
4. Enter the 6-digit code to verify.
5. Save the backup codes shown — each works once if you lose your authenticator.

To turn it off, click **Disable two-factor** and confirm your password.

### Require 2FA for everyone

Turn on **Require 2FA for team members** on the Team tab to enforce it workspace-wide:

- Every admin and member must complete a TOTP challenge on each password sign-in.
- Magic-link sign-in is refused for anyone who has enrolled — they must use the password + TOTP flow.
- Members who haven't enrolled yet are sent to set up 2FA before they can continue.

### Reset a member's 2FA

If a team member loses their authenticator and their backup codes, an admin can clear their enrollment from **Admin → Settings → Members** — open the member's actions and choose **Reset 2FA**. The member re-enrolls on their next sign-in. The reset is recorded in the [audit log](#audit-log).

## Recovery codes

Recovery codes are break-glass passcodes for signing in when SSO is unavailable. They're generated and managed on the [SSO page](/docs/auth/sso#recovery-codes), not here.

## Audit log

The audit log is an append-only record of security-sensitive admin actions. Find it at **Admin → Settings → Audit log**.

It captures:

- **Authentication** — sign-in success and failure, new-device sign-ins, rate-limited attempts, sign-in method toggles (password, magic link).
- **SSO** — connection changes, per-domain enforcement, recovery-code generation and use.
- **Team** — role changes (including those from SSO attribute mapping), 2FA admin resets, bulk session revocations.
- **Portal access** — visibility flips, allowed-domain edits, allowed-segment edits, widget sign-in toggle, and authenticated-but-unauthorized denials at the portal gate.
- **Portal invites** — sends, resends, accepts, revokes, link copies (`portal.invite.link_minted`), and expirations from the daily sweep.
- **Boards** — per-board access matrix changes (View / Vote / Comment / Submit tiers and segment allowlists).
- **Moderation** — workspace moderation default changes, plus approve, reject, and hold actions on individual posts and comments.
- **Widget handshake** — OTT exchanges that succeeded or were rejected. Grouped as **Widget activity** in the filter and hidden by default to keep noise down; turn it on when you're debugging a handoff issue.

Each entry records the actor, their IP, user agent, request id, actor type (user / service / api key / anonymous / system), and the auth method used (`password`, `sso`, `magic_link`, `ott`, `api_key`, `session`). Filter by actor, event type, or time range to investigate a specific change. Export the filtered view as CSV for forensics or compliance.

## Sign-in hardening

Quackback rate-limits password and magic-link sign-in attempts per IP and email address, and tracks devices so it can email the account owner the first time a new device signs in. The new-device email is on by default and can be turned off on the Team tab.

## Next steps

- [Set up single sign-on](/docs/auth/sso) — connect your IdP and require SSO
- [Portal Authentication](/docs/admin/portal-auth) — configure sign-in for customers
- [Team Members](/docs/admin/team) — invite and manage your team

- [Group users with segments](https://quackback.io/docs/admin/segments): Create user segments to filter feedback, scope boards, and gate portal access.

# Group users with segments

Not all feedback is equal. Segments let you group users by plan, country, activity, or any attribute you track, so you can filter feedback by the customers who matter most — and use the same groups to scope which [boards](/docs/admin/boards#access-tab) or [portals](/docs/admin/portal-auth#allowed-segments) they can see.

## Overview

Segments live at **Admin → Settings → People**, alongside [User Attributes](/docs/admin/users). From there you can:

- Create manual segments by hand-picking users
- Create dynamic segments with rule-based auto-membership
- Filter the feedback inbox by segment
- Filter the users list by segment
- Reference segments from per-board access and portal allowlists

The same People page also lets you define the [custom attributes](/docs/widget/identify-users#custom-attributes) your dynamic rules read from.

## Segment types

### Manual segments

Assign users to a segment individually. Use manual segments for curated groups like beta testers, design partners, or key accounts.

1. Click **New Segment**
2. Enter a name and optional description
3. Leave the rules empty to create a manual segment
4. Add users individually from the users list

### Dynamic segments

Define rules and let Quackback auto-populate the segment. Use dynamic segments for attribute-based groups like "Enterprise plan", "Signed up in the last 30 days", or "US-based active accounts".

1. Click **New Segment**
2. Enter a name and optional description
3. Add one or more conditions using the rule builder
4. Choose whether **all** or **any** conditions must match
5. Save the segment

## Built-in attributes

The rule builder ships with attributes grouped by source. You can also reference any [custom attribute](/docs/widget/identify-users#custom-attributes) you've defined.

### Profile

| Attribute | Type | Notes |
|-----------|------|-------|
| **Name** | string | Display name from the user's profile. |
| **Email** | string | Email address. Operators are case-insensitive. |
| **Email Verified** | boolean | Whether the user has verified their email. |
| **Locale** | string | BCP-47 locale from the identity provider (`en`, `en-US`). Only set when SSO or OAuth supplies the claim. |

### Account

| Attribute | Type | Notes |
|-----------|------|-------|
| **Principal Type** | enum | `user` or `anonymous`. Useful for excluding anonymous voters from rules. |
| **Account Age (days)** | number | How many days since the principal was created. |
| **Country** | string | ISO-3166-1 alpha-2 (`US`, `GB`), captured from your CDN's geo header on sign-in. Only populated when a geo-aware proxy is in front of the app. |
| **Last Active (days ago)** | number | Days since the most recent session. The `has ever signed in` / `has never signed in` operators target users with no session at all. |
| **Sign-up Source** | string | The auth provider the user first signed up with (`credential`, `google`, `github`, `sso`, …) or `email` for magic-link / OTP only. |

### Activity

| Attribute | Type | Notes |
|-----------|------|-------|
| **Post Count** | number | Feedback posts the user has submitted. |
| **Vote Count** | number | Votes the user has cast. |
| **Comment Count** | number | Comments the user has made. |

### Custom attributes

Anything you've defined in **Admin → Settings → People → Attributes** is available too. Pass values via the [widget](/docs/widget/identify-users#custom-attributes) or the [API](/docs/api/overview) and reference them by key in the rule builder.

## Operators

Each attribute exposes the operators its data type supports. Numbers add `greater than`, `at least`, `less than`, `at most`. Strings add `contains`, `starts with`, `ends with`. Most attributes also support `is set` and `is not set` — handy for finding users with a missing locale or no `plan` value yet. Principal Type and Sign-up Source are the exceptions: they support only `equals` and `not equals` comparisons.

The value field autosuggests existing values from your workspace as you type, so spelling stays consistent.

You can combine multiple conditions. Choose **all** to require every condition (AND logic), or **any** to match at least one (OR logic).

## Re-evaluate membership

Dynamic segments re-evaluate automatically on an hourly schedule. You can also trigger a manual re-evaluation:

- **Re-evaluate all** — click the button at the top of the segments list to refresh every dynamic segment at once
- **Re-evaluate one** — hover a segment row in the **Admin → Users** sidebar and click the refresh icon

Manual segments aren't affected by re-evaluation.

## Edit and delete segments

Click a segment in the People page (or the Users sidebar) to edit its name, description, or rules. For dynamic segments, you can add, modify, or remove conditions.

Click **Delete** to remove a segment. The confirmation warns that all user memberships are removed.

## Use segments elsewhere

Once a segment exists you can reference it from other admin surfaces:

- **Inbox** — filter posts by who submitted them. See [Inbox](/docs/admin/inbox).
- **Users list** — show only members of a segment via the sidebar on **Admin → Users**.
- **Per-board access** — limit a board to one or more segments. See [Board access](/docs/admin/boards#access-tab).
- **Portal access** — let segment members into a private portal without an individual invite. See [Allowed segments](/docs/admin/portal-auth#allowed-segments).

## Next steps

- [Inbox](/docs/admin/inbox) — filter feedback by segment
- [Users](/docs/admin/users) — view and manage portal users
- [Boards](/docs/admin/boards#access-tab) — scope a board to specific segments
- [Portal access](/docs/admin/portal-auth#allowed-segments) — let segment members into a private portal

- [Track progress with statuses](https://quackback.io/docs/admin/statuses): Define workflow stages so users can track their feedback.

# Track progress with statuses

Keep users in the loop. Statuses show what's happening with their feedback, from "Open" all the way to "Complete".

When you change a status, subscribers get notified automatically. It's the easiest way to close the feedback loop without sending individual emails.

## Default Statuses

Quackback comes with six statuses organized into three categories:

### Active

Statuses for posts that need attention or are being worked on:

| Status | What it means |
|--------|---------------|
| Open | New feedback (default for new posts) |
| Under Review | Feedback being evaluated |
| Planned | Approved and scheduled |
| In Progress | Currently being worked on |

### Complete

For posts that have been successfully addressed:

| Status | What it means |
|--------|---------------|
| Complete | Released to users |

### Closed

For posts that won't be implemented:

| Status | What it means |
|--------|---------------|
| Closed | Won't be implemented |

## Create a status

Your workflow isn't one-size-fits-all. Create custom statuses like "In Design", "In Beta", or "Blocked".

1. Go to **Admin → Settings → Statuses**
2. Find the category you want to add a status to
3. Click **"Add new status"** at the bottom
4. Fill in the details:

| Field | What it does |
|-------|--------------|
| Name | Display name (e.g., "In Beta") |
| Slug | API identifier (auto-generated from name) |
| Color | Status badge color |

5. Click **Create status**

## Show on Roadmap

Use the toggle next to each status to control whether posts with that status appear on the public roadmap.

Most teams show: **Planned → In Progress → Complete**

## Reorder statuses

The order affects dropdown menus and roadmap columns.

1. Go to **Admin → Settings → Statuses**
2. Drag statuses using the grip handle on the left
3. Click **Save changes**

## Edit a status

1. Go to **Admin → Settings → Statuses**
2. Click the color dot to change the color
3. Use the toggle to change roadmap visibility
4. Click **Save changes**

All posts with this status will reflect the changes immediately.

## Delete a status

1. Go to **Admin → Settings → Statuses**
2. Click the trash icon next to the status
3. Confirm deletion

## Communicate status changes

When you update a status, add a comment so users know why. Here are templates you can use:

**Moving to Planned:**
> "Great news! We've added this to our roadmap. Thanks for the suggestion. We'll keep you posted as we make progress."

**Moving to In Progress:**
> "We're actively working on this now. Stay tuned for updates!"

**Moving to Complete:**
> "This is now live! Thanks for suggesting it. Let us know how it works for you."

**Moving to Closed:**
> "After reviewing, we've decided to go a different direction. [Brief reason]. We really appreciate you taking the time to share this idea."

**Reverting to Open:**
> "We're putting this back under review. Priorities shifted, but we haven't forgotten about it."

## Example Workflows

### Simple Workflow

```
Open → Under Review → Planned → In Progress → Complete
                ↓
              Closed
```

### Detailed Workflow (with custom statuses)

```
Open → Under Review → Planned → In Design → In Development → In Beta → Complete
              ↓
            Closed
```

### With Blocking States

```
Open → Under Review → Planned → In Progress → Blocked → In Progress → Complete
              ↓
            Closed
```

## Best Practices

### Keep It Simple

### Use Clear Names

Use action-oriented names that describe the current state:
- "In Progress" not "Development"
- "Complete" not "Done"
- "Open" not "New"

### Roadmap Visibility

Only show meaningful statuses on the roadmap. Users don't need to see:
- Internal review stages
- Closed items
- Duplicates

## Notifications

When a post's status changes:
- Subscribed users receive email notifications (if email is configured)
- Integrations (Slack, etc.) are triggered if you've set up event mappings

## Next Steps

- [Roadmap](/docs/admin/roadmap) - Display status-based roadmaps
- [Inbox](/docs/admin/inbox) - Manage feedback and change statuses
- [Integrations](/docs/integrations/overview) - Get notified on status changes

- [Triage AI suggestions](https://quackback.io/docs/admin/suggestions): Review duplicate detection, vote suggestions, and AI-generated posts.

# Triage AI suggestions

Stop merging duplicates by hand. Quackback automatically detects duplicate posts using vector similarity and full-text search, then verifies matches with an LLM. Feedback from integrations like Slack is analyzed and turned into actionable suggestions. Review everything in a dedicated triage view and accept or dismiss with one click.

## Overview

Access suggestions from **Admin → Feedback → Incoming** in the sidebar. The suggestions page shows three types of AI-generated recommendations:

| Type | Description |
|------|-------------|
| **Merge posts** | Two existing posts that appear to be duplicates. Quackback suggests which to merge into which based on vote count, comments, and age. |
| **Vote on post** | Feedback from an integration source that matches an existing post. Quackback suggests adding a vote instead of creating a duplicate. |
| **Create post** | Feedback from an integration source that doesn't match any existing post. Quackback suggests creating a new post with an AI-generated title. |

## How it works

When feedback arrives from an integration source (Slack, API, etc.), Quackback:

1. Runs the content through a quality gate to filter noise
2. Extracts structured themes from the raw feedback
3. Generates vector embeddings for each theme
4. Searches for similar existing posts using hybrid vector + full-text search
5. Verifies potential matches with an LLM to filter false positives
6. Creates a **vote on post** suggestion if a strong match is found, or a **create post** suggestion if no match exists

For duplicate detection between existing posts, a periodic sweep compares newer posts against older ones and creates **merge** suggestions when confidence is high.

## Suggestion grouping

Suggestions from integration sources are grouped by their original feedback item. When a single Slack message or support ticket produces multiple suggestions (for example, a message that mentions both a feature request and a bug), they appear together under a shared source header.

Each group shows:
- **Source icon** and integration name (Slack, API, etc.)
- **Author name** and timestamp
- **Original feedback** as a collapsible quote
- **"Open in" link** to view the original message in the source platform (e.g., "Open in Slack")

## Filter suggestions

### By suggested action

Use the sidebar to filter by suggestion type:

- **All** - Every pending suggestion
- **Merge posts** - Duplicate post pairs to review
- **Vote on post** - Feedback that matches an existing post
- **Create post** - New posts suggested from feedback sources

### By source

Filter by the integration source that generated the feedback. Each source shows a count of pending suggestions. Merge suggestions appear under the "Quackback" source.

### Search

Use the search bar to find suggestions by title or content.

## Sort suggestions

| Option | Description |
|--------|-------------|
| **Newest** | Most recently created suggestions first (default) |
| **Relevance** | Sorted by similarity score for merges, or relevance ranking for new posts |

## Review merge suggestions

Each merge suggestion shows two post cards side by side:

- **Vote count** and **status** for each post
- **Title** and content preview
- **Board**, creation date, and comment count
- **Similarity score** as a percentage
- **AI reasoning** explaining why the posts are similar

### Accept a merge

Click **Merge** to combine the posts. Votes and subscribers are consolidated into the target post. The source post shows a banner linking to the merged post.

### Swap merge direction

By default, Quackback suggests merging the newer or lower-engagement post into the older or higher-engagement one. If you disagree, click the **swap button** between the two post cards to flip which post gets merged into which, then click **Merge**.

### Dismiss a suggestion

Click **Dismiss** to reject the suggestion. The pair won't be suggested again.

## Review vote suggestions

When feedback matches an existing post, Quackback suggests voting on that post instead of creating a duplicate. Each vote suggestion shows:

- The **existing post** with its current vote count, status, and board
- **Similarity score** as a percentage

### Accept a vote

Click **Vote** to add a vote to the existing post on behalf of the feedback author. The vote is attributed to the original author.

### Create instead

If the feedback is related but distinct enough to warrant its own post, click **Create instead** to open the create post dialog with the feedback pre-filled.

### Dismiss

Click **Dismiss** to reject the suggestion.

## Review create post suggestions

Each create suggestion shows:

- An **AI-suggested title** and description
- The recommended **board** for the new post

### Accept a suggestion

Click **Create post** to open a dialog with the suggested title and content pre-filled. The dialog includes:

- **Title** and **description** fields (editable)
- **Author** selector — defaults to the original feedback author. You can search for existing users or create a new user inline.
- **Board** selector
- **Status** selector — defaults to your workspace's default status

The original feedback is shown as a quote at the top of the dialog with a link to the source.

### Dismiss a suggestion

Click **Dismiss** to reject the suggestion.

## Dismiss and restore

When you dismiss a suggestion, it doesn't disappear immediately. A placeholder appears with an **Undo** button for a few seconds. If you change your mind, click Undo to restore the suggestion before it's permanently dismissed.

To dismiss all suggestions in a source group at once, click **Dismiss all** in the group header.

### View dismissed suggestions

Switch to the **Dismissed** tab to see suggestions you've previously dismissed. You can restore any dismissed suggestion by clicking **Restore**.

## Next steps

- [Triage feedback in the inbox](/docs/admin/inbox) - Filter and respond to feedback
- [Boards](/docs/admin/boards) - Organize feedback into boards
- [Slack](/docs/integrations/slack) - Send feedback from Slack to Quackback

- [Categorize posts with tags](https://quackback.io/docs/admin/tags): Label posts across boards for filtering and organization.

# Categorize posts with tags

Need to track which feedback affects mobile vs web? Or which requests are from enterprise customers? Tags let you slice feedback any way you need, across boards, statuses, and teams.

## Overview

Manage tags from **Admin > Settings > Tags**. Each tag has a name, color, and optional description. Tags appear as colored badges throughout the app — in the inbox, post cards, and the portal.

Tags differ from other organization methods:

| Feature | Tags | Boards | Statuses |
|---------|------|--------|----------|
| Multiple per post | Yes | No | No |
| User-facing category | Yes | Yes | Yes |
| Workflow stage | No | No | Yes |
| Content type | No | Yes | No |

## Manage tags

Go to **Admin > Settings > Tags** to create, edit, and delete tags.

### Create a tag

1. Click **New tag**
2. Enter a name and optional description
3. Pick a color from the preset palette or enter a custom hex code
4. Click **Create tag**

Tags appear as colored badges using the color you choose. The color shows at 10% opacity as a background tint with the full color as text.

### Edit a tag

Click any tag in the list to open the edit dialog. You can change the name, description, and color. Changes apply immediately across all posts using that tag.

### Delete a tag

Click the three-dot menu on a tag row and select **Delete**. This removes the tag from all posts. Deleted tags are soft-deleted and won't appear in the tag list.

## Apply tags

### From Post Detail

1. Navigate to a post in **Admin → Feedback**
2. Click the post to open the detail page
3. In the Properties panel on the left, find the Tags section
4. Click **"Add"** to see available tags
5. Select a tag to apply it

### Remove tags

1. Open a post in the detail page
2. In the Properties panel, click the X on any tag badge to remove it

## Filter by tags

### In the Feedback View

1. In the filter sidebar, find the **Tags** section
2. Click tags to toggle them on/off
3. View matching posts

### Combine filters

Tags combine with other filters:
- Board + Tag
- Status + Tag
- Search + Tag

## Use Cases

### By Platform

```
mobile
web
desktop
api
ios
android
```

### By Customer Segment

```
enterprise
startup
free-tier
beta-users
```

### By Priority

```
high-priority
quick-win
blocking
nice-to-have
```

### By Feature Area

```
auth
billing
dashboard
reports
integrations
```

### By Team

```
eng-backend
eng-frontend
design
product
```

## Best Practices

### Start Simple

### Consistent Naming

Use a naming convention:
- Lowercase
- Hyphenated
- Short and clear

### Avoid Overlap

Don't duplicate information:
- Use boards for content type (features vs bugs)
- Use statuses for workflow stage
- Use tags for cross-cutting concerns

## Next Steps

- [Managing Feedback](/docs/admin/inbox) - Use tags to filter feedback
- [Statuses](/docs/admin/statuses) - Workflow stages
- [Boards](/docs/admin/boards) - Content categories

- [Manage your team](https://quackback.io/docs/admin/team): Invite teammates and assign roles to manage feedback together.

# Manage your team

Don't manage feedback alone. Invite teammates to help triage requests, respond to users, and keep your roadmap updated. Control who can do what with simple role-based permissions.

## Overview

Access team settings from **Admin → Settings → Team Members**.

## Roles

Quackback has two team member roles:

| Role | Capabilities |
|------|--------------|
| **Admin** | Full access to all settings, team management, integrations |
| **Member** | Manage feedback, respond to posts, update statuses |

### Role Comparison

| Capability | Member | Admin |
|------------|:------:|:-----:|
| View admin dashboard | ✓ | ✓ |
| Manage posts & comments | ✓ | ✓ |
| Change post statuses | ✓ | ✓ |
| Manage boards | ✓ | ✓ |
| Manage statuses & tags | ✓ | ✓ |
| Pin official responses | ✓ | ✓ |
| Branding & customization | | ✓ |
| Portal authentication | | ✓ |
| Team management | | ✓ |
| Import/export data | | ✓ |

## Invite team members

1. Go to **Admin → Settings → Team Members**
2. Click **"Invite member"**
3. Enter their email address
4. Select a role (Admin or Member)
5. Click **Send invite**

The invitee receives an email with a link to join your workspace.

### Pending Invitations

Pending invitations are shown at the top of the Team Members page. From there you can:
- View who has been invited
- Resend invitations
- Cancel pending invitations

## Manage members

### View Team Members

The team page shows:
- Member name and email
- Role badge (Admin/Member)

The member count is displayed at the top of the list.

### Change Role

1. Find the member in the list
2. Click the **...** menu button on the right
3. Select **Make admin** or **Make member**
4. Confirm the change

Changes take effect immediately.

### Remove Member

1. Find the member in the list
2. Click the **...** menu button
3. Select **Remove from team**
4. Confirm removal

Removed members:
- Are converted to a portal user
- Lose access to the admin dashboard
- Can still interact with the public feedback portal
- Their comments and activity history remain

## Authentication

By default, team members sign in with a password or a [magic link](/docs/auth/magic-link). You can also enable GitHub and Google sign-in, require [two-factor authentication](/docs/admin/security#two-factor-authentication), or connect [single sign-on](/docs/auth/sso).

See [Configure team security](/docs/admin/security) for the full set of options.

## Best Practices

### Start Small

### Clear Ownership

Assign specific team members to monitor certain boards or topics.

### Regular Reviews

Periodically review team access:
- Remove members who no longer need access
- Audit admin permissions
- Check for unused invitations

### Use Member Role Appropriately

## Next Steps

- [Branding](/docs/admin/branding) - Customize your workspace appearance
- [Security](/docs/admin/security) - Configure authentication options
- [Integrations](/docs/integrations/overview) - Connect external tools

- [Manage portal users](https://quackback.io/docs/admin/users): See who's giving feedback and spot your most engaged users.

# Manage portal users

Know your users. See who's signed up, who's most active, and who's giving you the best feedback. Spot trends in your user base and identify your power users.

## Overview

Access Portal Users from **Admin → Users** in the sidebar. You can:

- See all users who've signed up to give feedback
- Find your most active contributors
- Filter by [segment](/docs/admin/segments), verification status, or sign-up date
- Search by name or email
- Send and manage [portal invites](#invitations)

## Users Interface

### List View

The user list displays accounts in rows with:

| Column | Description |
|--------|-------------|
| Avatar | User's profile picture or initials |
| Name | Display name |
| Email | Email address (may be blank for users created via integrations) |
| Status | Verified/Unverified badge |
| Date | When they signed up |

Click any row to view user details in the side panel.

### User Detail Panel

When you select a user, the detail panel shows:

- Profile information (name, email, avatar)
- Account status (verified/unverified)
- Sign-up date
- Activity summary

## Filtering

Use the filter sidebar to narrow down users:

### By Verification Status

Filter users by their email verification status:

- **All** - Show all users
- **Verified** - Only email-verified users
- **Unverified** - Users who haven't verified their email

### By Date Range

Filter by when users signed up:

1. Click the date filter
2. Select a start date
3. Optionally select an end date

### By Segment

Filter users by [segment](/docs/admin/segments). Select a segment from the filter sidebar to view only users in that group.

### Search

Use the search bar to find users by name or email.

## Sorting

Sort users using the dropdown:

| Option | Description |
|--------|-------------|
| Newest | Most recently signed up first |
| Oldest | Oldest accounts first |
| Most Active | Users with most posts/votes first |
| Name | Alphabetical by name |

## User Actions

### View User Activity

1. Select a user from the list
2. View their posts and votes in the detail panel

### Edit User

Update a user's name or email:

1. Select the user from the list
2. Click the **Edit** button in the detail panel
3. Update the name or email
4. Save changes

### Create Users Inline

You can create portal users directly from several admin workflows without visiting the Users page:

- **Add voter** — When adding a proxy vote on a post, click "Create new user" in the voter search popover
- **Create post from suggestion** — The author selector lets you create a new user when the feedback author doesn't have an account yet

Inline-created users appear in the Portal Users list like any other user.

### Remove User

1. Select the user
2. Click the **Remove** button in the detail panel
3. Confirm the removal

## Best Practices

### User Engagement

### Manage spam

If you notice spam accounts:

1. Filter by "Unverified" status
2. Review recent sign-ups
3. Remove suspicious accounts

## Invitations

The **Invitations** entry in the sidebar opens a dedicated view for portal email invites. Use it when you want to bring specific people into a private portal without configuring an allowlist by domain or segment.

To send invites:

1. Click **Invite people** in the top right.
2. Paste up to 50 email addresses, separated by commas, spaces, or newlines.
3. Optionally add a personal message (up to 500 characters) — it's included in the email.
4. Click **Send invites**.

Pending invites appear in the list with status, expiry, and per-row actions:

| Action | What it does |
|--------|--------------|
| Copy link | Copies the same magic link from the email so you can share it directly. |
| Resend | Sends a fresh email with the same link. |
| Revoke | Cancels the invite immediately. The link stops working. |

Each invite is valid for 14 days. Past that, the daily sweep marks it **Expired** and emits a `portal.invite.expired` event to the [audit log](/docs/admin/security#audit-log).

For setup guidance on the portal-side controls (visibility, segments, widget sign-in), see [Control portal access](/docs/admin/portal-auth#portal-access).

## Access Control

| Role | Can View Users | Can Remove Users | Can Invite |
|------|----------------|------------------|------------|
| Admin | Yes | Yes | Yes |
| Member | Yes | No | No |

## Next steps

- [Segments](/docs/admin/segments) - Group users for targeted feedback analysis
- [Team Members](/docs/admin/team) - Manage your internal team
- [Security](/docs/admin/security) - Configure team authentication
- [Portal Authentication](/docs/admin/portal-auth) - Configure how portal users sign in


### Auth

- [Set up magic-link sign-in](https://quackback.io/docs/auth/magic-link): Let users sign in with a one-click link emailed to them, no password required.

# Set up magic-link sign-in

Skip the password. Users enter their email, click the link Quackback sends them, and they're in. No password to remember, no reset flows.

## How it works

1. The user enters their email on the sign-in page.
2. Quackback emails them a one-click sign-in link (valid for 10 minutes).
3. They click the link and a session is created.

The same link is used for team invitations and [recovery-code](/docs/auth/sso#recovery-codes) sign-in, so those flows keep working even when magic link is turned off on the sign-in form.

## Turn it on

Magic link is configured separately for each audience.

### Portal users

1. Go to **Admin → Settings → Security**, then the **Portal** tab.
2. Toggle **Magic link** on.

### Team members

1. Go to **Admin → Settings → Security**, then the **Team** tab.
2. Toggle **Magic link** on or off under **Sign-in methods**.

## Email delivery

Magic link needs a way to send email. Without one, the link is logged to the server console (useful in development only).

Configure SMTP or Resend with the `EMAIL_*` environment variables — see [Email delivery](/docs/integrations/email) for provider setup.

## Sign-in hardening

Magic-link requests are rate-limited per IP and email address, and Quackback emails the account owner when a sign-in happens from a new device. Team admins can turn the new-device email off under **Admin → Settings → Security → Team**.

## Next steps

- [OAuth providers](/docs/auth/oauth) — social login with GitHub, Google, and more
- [Set up custom OIDC](/docs/auth/sso) — enterprise single sign-on
- [Authentication overview](/docs/auth/overview) — all sign-in options

- [Set up OAuth providers](https://quackback.io/docs/auth/oauth): Let users sign in with GitHub, Google, and 8 more social providers.

# Set up OAuth providers

One-click sign-in. Let users authenticate with social accounts instead of managing another set of credentials. Works for both portal users (customers) and team members (your employees).

## Overview

OAuth lets users sign in with accounts they already have. No new passwords, no verification emails. Just a quick popup to authorize access and they're in.

### Supported Providers

| Provider | Configuration | Notes |
|----------|---------------|-------|
| Apple | Client ID, Client Secret, App Bundle Identifier (optional) | Bundle ID only needed for native apps |
| Discord | Client ID, Client Secret | |
| Facebook | Client ID, Client Secret | |
| GitHub | Client ID, Client Secret | |
| GitLab | Client ID, Client Secret, Issuer URL (optional) | Issuer URL for self-hosted GitLab |
| Google | Client ID, Client Secret | |
| LinkedIn | Client ID, Client Secret | |
| Microsoft | Client ID, Client Secret, Tenant ID (optional) | Defaults to "common" for multi-tenant |
| Reddit | Client ID, Client Secret | |
| Twitter / X | Client ID, Client Secret | |

All providers work for both portal users and team members. Toggle them per-surface on the **Sign-in providers** tab of the Authentication page.

For team-wide single sign-on with verified domains and enforcement, see [Single sign-on](/docs/auth/sso). For a single custom OIDC button on the portal sign-in form, enable **Custom OIDC** on the Sign-in providers tab (requires the Custom OIDC feature on your plan).

### How It Works

1. User clicks "Continue with [Provider]"
2. A popup window opens to the provider's login page
3. User authenticates and grants permission
4. Provider redirects back to Quackback with authorization code
5. Quackback exchanges the code for user information
6. User session is created

## GitHub Setup

### Step 1: Create OAuth Application

**[GitHub]**

1. Go to [GitHub Developer Settings](https://github.com/settings/developers)
2. Click **OAuth Apps** > **New OAuth App**
3. Fill in the application details:

| Field | Value |
|-------|-------|
| Application name | `Quackback` (or your custom name) |
| Homepage URL | `https://feedback.yourcompany.com` |
| Authorization callback URL | `https://feedback.yourcompany.com/api/auth/callback/github` |

4. Click **Register application**
5. Note the **Client ID**
6. Click **Generate a new client secret** and save it securely

### Step 2: Add credentials in Quackback

1. Go to **Admin → Settings → Security → Authentication** in Quackback.
2. Switch to the **Sign-in providers** tab.
3. Find GitHub in the Social sign-in grid and click **Configure**.
4. Paste the Client ID and Client Secret. Save.
5. Toggle GitHub on for the surface(s) you want.

Credentials are stored encrypted in the database, not in environment variables.

### Callback URL format

```
https://YOUR_DOMAIN/api/auth/callback/github
```

For local development:
```
http://localhost:3000/api/auth/callback/github
```

## Google Setup

### Step 1: Create OAuth Credentials

**[Google Cloud Console]**

1. Go to [Google Cloud Console](https://console.cloud.google.com/)
2. Create a new project or select an existing one
3. Navigate to **APIs & Services** > **Credentials**
4. Click **Create Credentials** > **OAuth client ID**
5. If prompted, configure the OAuth consent screen first:
   - User Type: **External** (or Internal for Workspace)
   - App name: `Quackback`
   - User support email: Your email
   - Authorized domains: `yourcompany.com`

### Step 2: Configure OAuth Client

**[Google Cloud Console]**

1. Application type: **Web application**
2. Name: `Quackback`
3. Authorized JavaScript origins:
   ```
   https://feedback.yourcompany.com
   ```
4. Authorized redirect URIs:
   ```
   https://feedback.yourcompany.com/api/auth/callback/google
   ```
5. Click **Create**
6. Note the **Client ID** and **Client Secret**

### Step 3: Add credentials in Quackback

1. Go to **Admin → Settings → Security → Authentication** in Quackback.
2. Switch to the **Sign-in providers** tab.
3. Find Google in the Social sign-in grid and click **Configure**.
4. Paste the Client ID and Client Secret. Save.
5. Toggle Google on for the surface(s) you want.

### Callback URL format

```
https://YOUR_DOMAIN/api/auth/callback/google
```

## Enable OAuth in Quackback

Every provider is configured once and can be enabled per surface (Portal, Team). Credentials are stored encrypted in the platform credentials table.

1. Go to **Admin → Settings → Security → Authentication**.
2. Switch to the **Portal** or **Team** tab.
3. Click **Configure** on the provider tile, paste Client ID and Client Secret, save.
4. Toggle the provider on for that surface. The same credentials power both surfaces; configure once, enable independently.

Providers only appear on the sign-in page when credentials are saved and the toggle is on.

## Other Providers

All providers follow the same pattern:

1. Create an OAuth application in the provider's developer console
2. Set the callback URL to `https://YOUR_DOMAIN/api/auth/callback/PROVIDER_ID`
3. Enter the Client ID and Client Secret in Quackback's admin settings

| Provider | Developer Console | Callback URL |
|----------|-------------------|--------------|
| Apple | [Apple Developer](https://developer.apple.com/account/resources/identifiers/list) | `/api/auth/callback/apple` |
| Discord | [Discord Developer Portal](https://discord.com/developers/applications) | `/api/auth/callback/discord` |
| Facebook | [Meta for Developers](https://developers.facebook.com/apps/) | `/api/auth/callback/facebook` |
| GitLab | [GitLab Applications](https://gitlab.com/-/user_settings/applications) | `/api/auth/callback/gitlab` |
| LinkedIn | [LinkedIn Developers](https://www.linkedin.com/developers/apps) | `/api/auth/callback/linkedin` |
| Microsoft | [Azure App Registrations](https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade) | `/api/auth/callback/microsoft` |
| Reddit | [Reddit Apps](https://www.reddit.com/prefs/apps) | `/api/auth/callback/reddit` |
| Twitter / X | [X Developer Portal](https://developer.x.com/en/portal/projects-and-apps) | `/api/auth/callback/twitter` |

## Common Issues

### "OAuth callback URL mismatch"

The callback URL in your OAuth app configuration must match exactly:

**Check these common issues:**
- Protocol mismatch (`http` vs `https`)
- Trailing slash differences
- Port number missing or incorrect
- Domain/subdomain mismatch

**Example correct callback URLs:**
```
# Production
https://feedback.yourcompany.com/api/auth/callback/github

# Local development
http://localhost:3000/api/auth/callback/github
```

### "Invalid client_id or client_secret"

1. Verify the credentials are copied correctly (no extra spaces)
2. Ensure the OAuth app is not deleted or disabled
3. For Google, check if the OAuth consent screen is in testing mode

### "Popup blocked"

Quackback uses popup windows for OAuth. If blocked:

1. Click the browser's popup blocked notification
2. Allow popups for your Quackback domain
3. Try the sign-in again

### "Access denied" or "Application not authorized"

**GitHub:**
- Verify the OAuth app is not suspended
- Check organization access policies

**Google:**
- If consent screen is in testing mode, add test users
- Submit app for verification for production use
- Check if domain restrictions apply

### "Unable to get email from provider"

Some providers don't return email by default:

**GitHub:**
- User must have a public email or grant email permission
- Quackback fetches from `/user/emails` as fallback

**Google:**
- Email scope is always requested
- User must have a Google account with email

### CORS Errors

If you see CORS errors in the browser console:

1. Verify `BASE_URL` matches your actual domain
2. Check `BASE_URL` is correctly set
3. Ensure your reverse proxy passes the correct headers

## Security Best Practices

### Protect client secrets

- Quackback stores OAuth credentials encrypted in the platform credentials table; you don't need to manage them in environment variables.
- Rotate client secrets periodically and update them in **Configure** for each provider.
- Use separate OAuth apps for development and production so leaking one set doesn't expose the other.

### Verify Callback URLs

- Use HTTPS in production
- Don't use wildcard callback URLs
- Restrict to your exact domain

### Review OAuth Permissions

Each provider requests minimal scopes:
- Basic profile information
- Email address (for account identification)

No write access or sensitive permissions are requested.

### Monitor OAuth Activity

- Review sign-in logs regularly
- Set up alerts for unusual patterns
- Disable unused OAuth providers

## Test OAuth locally

**[Browser]**

### Local Development Setup

1. Use `localhost:3000` in your callback URL
2. Most providers allow `http://localhost` for development
3. For Google, add `http://localhost:3000` to authorized origins

### Test checklist

- [ ] OAuth app created with correct callback URL
- [ ] Credentials entered in admin settings
- [ ] Browser allows popups from your domain
- [ ] Test user exists (for testing-mode apps)

## Next steps

- [Custom OIDC](/docs/auth/sso) - Enterprise identity providers (Okta, Auth0, Keycloak)
- [Magic link](/docs/auth/magic-link) - Passwordless email sign-in
- [Authentication Overview](/docs/auth/overview) - All auth options

- [Authentication](https://quackback.io/docs/auth/overview): Understand Quackback's sign-in methods for portal users and team members.

# Authentication

Quackback splits authentication into two concerns: **who's allowed in** and **how they sign in**. Both live on **Admin → Settings → Security → Authentication**, which has three tabs:

| Tab | Controls | Doc |
|-----|----------|-----|
| **Portal access** | Visibility, allowed domains, email invites, allowed segments, widget sign-in | [Control portal access and sign-in](/docs/admin/portal-auth#portal-access) |
| **Team access** | Team-side 2FA and the SSO summary | [Configure team security](/docs/admin/security) |
| **Sign-in providers** | Password, magic link, social OAuth, Custom OIDC — per-surface toggles | [Sign-in providers](/docs/admin/portal-auth#sign-in-providers) |

## Two audiences

| Audience | Who they are |
|----------|--------------|
| **Portal users** | Customers who submit and vote on feedback. |
| **Team members** | Admins and members who manage feedback. |

A team member can also use the public portal like any other user.

## Portal access channels

A private portal admits visitors through these channels, evaluated in order:

| Channel | Who it lets in | Requires |
|---------|----------------|----------|
| Team | Admins and members | Real authenticated session |
| Allowed domain | Anyone whose verified email matches a listed domain | Email verified |
| Email invite | A specific person you invited | Email verified |
| Allowed segment | Any member of a permitted segment | Email verified |
| Widget sign-in | A visitor signed into your embedded widget | Verified-identity widget + admin opt-in |

See [Control portal access](/docs/admin/portal-auth#portal-access) for the full setup walkthrough.

## Sign-in methods

| Method | Portal users | Team members |
|--------|--------------|--------------|
| **Password** | Yes (on by default) | Yes (on by default) |
| **[Magic link](/docs/auth/magic-link)** | Optional (off by default) | Yes (on by default) |
| **[OAuth social](/docs/auth/oauth)** | 10 providers (Apple, Discord, Facebook, GitHub, GitLab, Google, LinkedIn, Microsoft, Reddit, Twitter / X) | Same 10 providers - GitHub and Google on by default |
| **Custom OIDC (portal button)** | One OIDC button on the portal sign-in form, tier-gated | Use full team [SSO](/docs/auth/sso) instead |
| **[Single sign-on](/docs/auth/sso)** | Routes via verified-domain dispatch | Verified domains, optional enforcement, JIT provisioning |

Each method is a toggle. Turn on the combination that fits your users. At least one method always stays enabled per surface.

## Team security

The [Security page](/docs/admin/security) adds protections specific to the team:

- **[Two-factor authentication](/docs/admin/security#two-factor-authentication)**: TOTP codes on top of a password, optionally required workspace-wide.
- **[Single sign-on](/docs/auth/sso)**: connect an OIDC provider, verify your domains, and require SSO so company emails can only sign in through your IdP.
- **[Recovery codes](/docs/auth/sso#recovery-codes)**: break-glass sign-in when SSO is unavailable.
- **[Audit log](/docs/admin/security#audit-log)**: an append-only record of every security-sensitive change.

## Sign-in hardening

Quackback rate-limits password and magic-link sign-in attempts per IP and email address, tracks devices, and emails the account owner the first time an account signs in from a new device. The new-device email is on by default and configurable on the Team tab.

## Sessions

- Sessions last 7 days and refresh every 24 hours on activity.
- Signing out invalidates the session immediately.
- Sessions are stored in PostgreSQL and expired ones are cleaned up automatically.

## Roles

| Role | Capabilities |
|------|--------------|
| **User** | Submit, vote, and comment on the public portal. |
| **Member** | Everything a user can do, plus access the admin dashboard and manage feedback. |
| **Admin** | Everything a member can do, plus workspace settings, team management, and integrations. |

See [Roles & permissions](/docs/admin/roles-permissions) for the full breakdown.

## Next steps

- [Set up magic-link sign-in](/docs/auth/magic-link): passwordless email sign-in
- [Set up OAuth providers](/docs/auth/oauth): social login
- [Set up single sign-on](/docs/auth/sso): enterprise SSO with domain enforcement
- [Configure team security](/docs/admin/security): 2FA and the audit log

- [Set up single sign-on](https://quackback.io/docs/auth/sso): Connect an OIDC provider, verify your domains, and require SSO for your team.

# Set up single sign-on

One less password for your team. Connect any OpenID Connect provider — Okta, Entra ID, Auth0, Keycloak — and let admins and members sign in with their existing work accounts. Verify your domains and you can require SSO so company emails can *only* sign in through your IdP.

## What you get

- **Connection** — link your OIDC provider once.
- **Test sign-in** — a real end-to-end handshake that proves the connection works before you turn anything on.
- **Verified domains** — prove you own a domain so its emails route to SSO.
- **Require SSO** — hard-bind a verified domain so its users can only sign in through your IdP.
- **Recovery codes** — break-glass sign-in for when your IdP is unreachable.
- **Attribute mapping** — assign Quackback roles from a claim on the IdP token.

Everything lives under **Admin → Settings → Security**, on the **Single sign-on** page.

## Step 1: Register Quackback in your IdP

Create an OIDC application in your identity provider:

| Field | Value |
|-------|-------|
| Application type | Web application |
| Redirect URI | `https://YOUR_DOMAIN/api/auth/oauth2/callback/sso` |
| Scopes | `openid email profile` |

Note the **Client ID** and **Client Secret**, and your provider's **discovery URL** (the `/.well-known/openid-configuration` endpoint).

## Step 2: Add the connection

1. Go to **Admin → Settings → Security → Single sign-on**.
2. Enter the **Discovery URL**, **Client ID**, and **Client Secret**.
3. Save.

The client secret is encrypted at rest. Changing the discovery URL, client ID, or secret invalidates any previous test sign-in — you'll need to test again before enabling.

## Step 3: Run a test sign-in

Before you can enable SSO or enforce it on a domain, Quackback makes you prove the connection works.

1. Click **Test sign-in** on the SSO page.
2. A popup opens your IdP. Sign in.
3. Quackback runs the full OIDC handshake — discovery, token exchange, signature verification, claim checks — and reports exactly which step failed if any.

A passing test unlocks the **Enabled** toggle and the per-domain **Require SSO** switches.

## Step 4: Enable SSO

Toggle **Enabled** on. The SSO sign-in option now appears on the team sign-in page. At this point SSO is *available* — it doesn't replace other methods yet.

## Verify your domains

A verified domain tells Quackback that you own an email domain, so emails at that domain route to SSO by default.

1. On the SSO page, under **Verified domains**, add a domain (for example `acme.com`).
2. Quackback shows a DNS TXT record to publish:

   | Name | Value |
   |------|-------|
   | `_quackback-verify.acme.com` | `qb-domain-verify=<token>` |

3. Add the record at your DNS registrar, wait for it to propagate, then click **Verify**.

You can verify up to 10 domains. Once verified, `*@acme.com` users see "Continue with SSO" as the default option on sign-in.

## Require SSO for a domain

Turn on the **Require SSO** switch next to a verified domain to hard-bind it: `*@acme.com` emails can then **only** sign in through your IdP. Password, magic link, and other OAuth providers are refused for those addresses.

Enabling enforcement has two preconditions:

- A passing **test sign-in** since the last connection change.
- **Email delivery** configured — magic link is the break-glass path for the rest of the workspace.

A confirmation dialog spells out the impact before you commit. Enforcement takes effect immediately.

Enforcement **fails open**: if SSO stops being viable at runtime - the client secret is removed, or the connection is disabled - Quackback suspends enforcement so the team isn't locked out. Re-enable it once SSO is healthy again.

When a user at a verified domain tries to sign in but SSO isn't actually live (the connection is off, the secret is missing, or the feature isn't on your plan), they see: *"Single sign-on is configured for your domain but is not currently available. Contact your administrator."* This shows up instead of a broken redirect so the user knows to reach out rather than retry blindly.

## Recovery codes

Recovery codes are single-use passcodes that get an admin in when SSO is unavailable.

1. On the SSO page, under **Recovery codes**, click **Generate new codes**.
2. Quackback shows 10 codes **once**. Copy, download, or print them and store them somewhere safe.
3. Generating a new batch invalidates the previous one.

To use a code, go to `/auth/recovery`, enter your email and a code. Each code works once. Quackback warns you when fewer than three codes remain.

## Auto-provision users

By default, the first time someone signs in through SSO with an email at a verified domain, Quackback creates their account automatically (just-in-time provisioning) with the **member** role.

You can change the default role, or turn auto-provisioning off entirely, in the SSO connection settings. With it off, a user must already exist in Quackback before they can sign in through SSO.

## Map roles from IdP claims

Instead of giving every provisioned user the same role, you can source their role from a claim on the IdP's ID token.

Under **Attribute mapping** on the SSO page:

1. Turn on **Attribute mapping**.
2. Set the **Claim path** — a dotted path (`realm_access.roles`) or a URL-shaped claim (`https://acme.com/roles`). Copy it from your IdP's docs.
3. Add **rules** — first-match-wins. Each rule maps a value the claim contains to a role, for example `platform-admins → admin`.
4. Set a **Default role** for users no rule matches.
5. Optionally turn on **Sync on every sign-in** to re-apply the role on each login. This *demotes* a team member if their IdP group changes.

Role changes from mapping are written to the [audit log](/docs/admin/security#audit-log).

## Provider examples

### Okta

| Field | Value |
|-------|-------|
| Discovery URL | `https://your-org.okta.com/.well-known/openid-configuration` |
| Redirect URI | `https://YOUR_DOMAIN/api/auth/oauth2/callback/sso` |

### Microsoft Entra ID

| Field | Value |
|-------|-------|
| Discovery URL | `https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration` |
| Redirect URI | `https://YOUR_DOMAIN/api/auth/oauth2/callback/sso` |

### Auth0

| Field | Value |
|-------|-------|
| Discovery URL | `https://your-tenant.auth0.com/.well-known/openid-configuration` |
| Redirect URI | `https://YOUR_DOMAIN/api/auth/oauth2/callback/sso` |

### Keycloak

| Field | Value |
|-------|-------|
| Discovery URL | `https://keycloak.example.com/realms/<realm>/.well-known/openid-configuration` |
| Redirect URI | `https://YOUR_DOMAIN/api/auth/oauth2/callback/sso` |

## How it works

1. A user clicks **Continue with SSO** (or is auto-redirected if their email is at a verified domain).
2. Quackback redirects to your IdP's authorization endpoint.
3. The user authenticates with their existing work credentials.
4. The IdP redirects back with an authorization code.
5. Quackback exchanges the code, verifies the ID token signature, and reads the `email` claim.
6. If the account exists it's linked; otherwise it's provisioned per your settings.

Quackback requires an `email` claim from your IdP. If your provider doesn't release it by default, add it to the application's claim mapping.

## Troubleshooting

### Test sign-in fails at "token exchange"

Usually a wrong client secret or a redirect URI mismatch. The test report names the failing step — check the exact value against your IdP application.

### Test sign-in fails at "claim check"

The ID token is missing `email` or `sub`. Configure your IdP to release the `email` claim (Okta: client scopes; Entra: API permissions; Keycloak: client scopes).

### "Verified domain requires SSO"

The email is at an enforced domain and tried a non-SSO method. Sign in through the IdP, or use a [recovery code](#recovery-codes).

### Domain verification won't pass

DNS changes can take time to propagate. Confirm the TXT record with `dig +short TXT _quackback-verify.YOUR_DOMAIN` before clicking Verify again.

## Next steps

- [Configure team security](/docs/admin/security) — 2FA, audit log, and sign-in methods
- [Authentication overview](/docs/auth/overview) — all sign-in options
- [Declarative config](/docs/self-hosting/config-file) — manage the SSO connection from a config file


### Integrations

- [Asana](https://quackback.io/docs/integrations/asana): Create Asana tasks from feedback and keep status in sync.

# Asana

Turn feedback into tasks. Automatically create Asana tasks when feedback is submitted, and keep statuses synchronized between Quackback and Asana. When a task moves between sections in your Asana project, the linked feedback post updates too.

## Overview

The Asana integration enables:

- **Create Asana tasks from feedback posts** -- automatically create a task when new feedback is submitted
- **Link posts to tasks** -- link feedback posts to Asana tasks for traceability
- **Status sync** -- keep feedback status in sync with Asana task sections via inbound webhooks

## Prerequisites

- Admin access to your Quackback workspace
- An Asana account with access to the target workspace
- An Asana OAuth application (created at [Asana Developer Console](https://developers.asana.com/docs/oauth))

## Setup

### 1. Create an Asana OAuth Application

1. Go to [Asana Developer Console](https://developers.asana.com/docs/oauth)
2. Create a new OAuth application
3. Copy the **Client ID** and **Client Secret**

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → Asana**
2. Enter the following credentials:
   - **Client ID** from your Asana OAuth application
   - **Client Secret** from your Asana OAuth application

### 3. Connect Your Workspace

1. Click **Connect to Asana**
2. You'll be redirected to Asana to authorize the application
3. Review the permissions and click **Allow**

After authorization, Quackback automatically detects your Asana workspace.

### 4. Select a Project

Back in Quackback:

1. Choose the Asana project where tasks should be created
2. Only active (non-archived) projects are shown

### 5. Configure Status Mappings

Map Asana sections to Quackback statuses:

1. Go to the Asana integration settings
2. Configure status mappings between Asana section names and Quackback statuses
3. Each Asana section name can be mapped to a corresponding Quackback status, or set to ignore

Status sync works via Asana webhooks. When a linked Asana task is moved to a different section, the corresponding Quackback post status updates automatically.

### 6. Configure Events

Choose which events trigger Asana actions:

| Event | Action |
|-------|--------|
| New post | Create an Asana task with the feedback details |

### 7. Save and Test

1. Click **Save**
2. Submit test feedback to verify a task is created in Asana

## Task Format

When a new feedback post triggers task creation, the Asana task includes:

- **Name**: The feedback post title
- **Notes** (HTML): The post content, followed by metadata including the author, board, vote count, and a link back to the post in Quackback

The task is created in the selected project within your connected Asana workspace.

## Status Sync

When status sync is configured, Quackback registers a webhook with Asana to receive task change events. Asana uses sections within a project as status indicators. When a linked task is moved to a different section:

1. Asana sends a compact webhook event to Quackback
2. Quackback fetches the task details via the Asana API to determine the current section
3. If a status mapping exists for that section name, the linked feedback post's status is updated

The webhook uses Asana's handshake protocol -- the initial setup request includes an `X-Hook-Secret` header that Quackback echoes back. Subsequent events are verified using HMAC-SHA256 via the `X-Hook-Signature` header.

The webhook is filtered to only receive task change events related to section membership, keeping traffic minimal.

## On post delete

When you delete a feedback post with a linked Asana task, you can complete the task at the same time. The delete dialog shows a checkbox for each linked task.

To pre-check this by default, enable the **On post delete** toggle in the Asana integration settings. You can always override the default per-delete.

## Manage the integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → Asana**
2. Toggle **Enabled** off
3. Task creation and status sync pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in Asana
3. Tokens are automatically refreshed when they expire (Asana access tokens last approximately one hour)

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Asana**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Tasks Not Being Created

1. **Check integration status** -- look for errors in settings
2. **Verify project selection** -- ensure an Asana project is selected
3. **Check event mappings** -- confirm `post.created` is mapped
4. **Workspace access** -- the connected Asana account must have access to the selected project

### Status Sync Not Working

1. **Check status mappings** -- ensure Asana section names are mapped to Quackback statuses
2. **Verify webhook** -- the Asana webhook may need to be re-registered
3. **Section-based status** -- Asana uses sections (not custom fields) as the status indicator for sync

### "Authentication Failed" Error

Asana OAuth access tokens expire after approximately one hour and are automatically refreshed. If refresh fails:

1. Click **Reconnect**
2. Re-authorize the app in Asana

## Next Steps

- [Linear](/docs/integrations/linear) - Linear issue sync integration
- [Webhooks](/docs/integrations/webhooks) - Build custom integrations
- [Integrations Overview](/docs/integrations/overview) - All integrations

- [Azure DevOps](https://quackback.io/docs/integrations/azure-devops): Create and link Azure DevOps work items from feedback posts.

# Azure DevOps

Route feedback into your Azure DevOps boards. Automatically create work items when feedback is submitted, choose the project and work item type, and link them back to the original feedback post. Inbound webhooks keep your feedback post statuses in sync when work items move through your workflow.

## Overview

The Azure DevOps integration enables:

- **Create work items from feedback posts** -- automatically create an Azure DevOps work item when new feedback is submitted
- **Link posts to work items** -- link feedback posts to Azure DevOps work items for traceability
- **Status sync** -- update feedback status when work item state changes via inbound webhooks

## Prerequisites

- Admin access to your Quackback workspace
- An Azure DevOps organization
- A Personal Access Token (PAT) with **Work Items (Read & Write)** scope

## Setup

### 1. Create a Personal Access Token

1. Go to your Azure DevOps organization
2. Click your profile icon and select **Personal access tokens**
3. Click **New Token**
4. Configure the token:
   - **Name**: Quackback Integration
   - **Organization**: Select your organization
   - **Expiration**: Choose an appropriate duration
   - **Scopes**: Select **Work Items** > **Read & Write**
5. Copy the generated token

### 2. Connect Azure DevOps

1. Go to **Admin → Settings → Integrations → Azure DevOps**
2. Enter your **Organization URL** in one of these formats:
   - `https://dev.azure.com/\{your-org\}` (modern format)
   - `https://\{your-org\}.visualstudio.com` (legacy format)
3. Enter the **Personal Access Token** you created
4. Click **Connect**

Quackback validates the connection by listing your projects. If the credentials are invalid, you will see an error.

### 3. Select a Project and Work Item Type

After connecting:

1. Choose the Azure DevOps project where work items should be created
2. Select the work item type (e.g., User Story, Bug, Task, Feature) -- the list is fetched from the selected project

The target is stored as a combination of project name and work item type.

### 4. Configure Status Mappings

Map Azure DevOps work item states to Quackback statuses:

1. Go to the Azure DevOps integration settings
2. Configure status mappings between work item states and Quackback statuses
3. Azure DevOps states are project-specific (e.g., New, Active, Resolved, Closed) -- map each to the corresponding Quackback status, or set it to ignore

### 5. Set Up the Service Hook

Status sync needs an Azure DevOps service hook so work item changes reach Quackback:

1. In Quackback, enable **Status sync** in the Azure DevOps integration settings
2. Copy the **Webhook URL** and **Signing secret** shown below the toggle
3. In Azure DevOps, go to **Project Settings → Service hooks** and create a **Web Hooks** subscription for the **Work item updated** event
4. Paste the webhook URL as the subscription URL and the signing secret as the **Basic authentication password** (leave the username empty)

Quackback verifies each delivery against the signing secret and rejects requests that don't match.

### 6. Configure Events

Choose which events trigger Azure DevOps actions:

| Event | Action |
|-------|--------|
| New post | Create a work item with the feedback details |

### 7. Save and Test

1. Click **Save**
2. Submit test feedback to verify a work item is created in the selected project

## Work Item Format

When a new feedback post triggers work item creation, the work item includes:

- **Title** (System.Title): The feedback post title
- **Description** (System.Description): The post content in HTML, followed by metadata including the author, board, vote count, and a link back to the post in Quackback

The description uses HTML formatting, which Azure DevOps renders natively in the work item detail view.

## Status Sync

When status sync is configured, Quackback receives inbound webhooks from Azure DevOps when work items are updated. When a linked work item's state changes:

1. Azure DevOps sends a `workitem.updated` webhook to Quackback
2. Quackback verifies the request using Basic Authentication -- the password must match the signing secret from your integration settings
3. Quackback checks for a `System.State` field change in the payload
4. If a status mapping exists for the new state, the linked feedback post's status is updated

## On post delete

When you delete a feedback post with a linked Azure DevOps work item, you can close the work item at the same time. The delete dialog shows a checkbox for each linked work item.

To pre-check this by default, enable the **On post delete** toggle in the Azure DevOps integration settings. You can always override the default per-delete.

## Manage the integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → Azure DevOps**
2. Toggle **Enabled** off
3. Work item creation and status sync pause, but the connection remains

### Reconnect

If your PAT expires or is revoked:

1. Create a new Personal Access Token in Azure DevOps
2. Update the token in **Admin → Settings → Integrations → Azure DevOps**

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Azure DevOps**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Work Items Not Being Created

1. **Check integration status** -- look for errors in settings
2. **Verify project selection** -- ensure a project and work item type are selected
3. **Check event mappings** -- confirm `post.created` is mapped
4. **PAT permissions** -- the token must have Work Items Read & Write scope
5. **PAT expiration** -- check that the token has not expired

### Status Sync Not Working

1. **Check status mappings** -- ensure Azure DevOps states are mapped to Quackback statuses
2. **Verify service hook** -- confirm the Azure DevOps service hook is configured and pointing to the correct callback URL
3. **Check authentication** -- the Basic authentication password in the service hook must match the signing secret shown in Quackback

### "Authentication Failed" or "Forbidden" Error

The Personal Access Token may be expired or revoked:

1. Check the token status in Azure DevOps
2. Create a new token if needed
3. Update the token in Quackback integration settings

### "Organization Not Found" Error

Verify the organization URL format:
- Modern: `https://dev.azure.com/\{your-org\}`
- Legacy: `https://\{your-org\}.visualstudio.com`

Ensure the PAT has access to the specified organization.

## Next Steps

- [GitHub](/docs/integrations/github) - GitHub issue integration
- [Jira](/docs/integrations/jira) - Jira issue integration
- [Integrations Overview](/docs/integrations/overview) - All integrations

- [ClickUp](https://quackback.io/docs/integrations/clickup): Turn feedback into ClickUp tasks and track progress.

# ClickUp

Turn feedback into tasks. Automatically create ClickUp tasks when feedback is submitted, and keep statuses synchronized between Quackback and ClickUp. When a task's status changes in ClickUp, the linked feedback post updates too.

## Overview

The ClickUp integration enables:

- **Create ClickUp tasks from feedback posts** -- automatically create a task when new feedback is submitted
- **Link posts to tasks** -- link feedback posts to ClickUp tasks for traceability
- **Status sync** -- keep feedback post status and ClickUp task status in sync via inbound webhooks

## Prerequisites

- Admin access to your Quackback workspace
- A ClickUp workspace
- A ClickUp OAuth application (created at [ClickUp Integrations](https://clickup.com/integrations))

## Setup

### 1. Create a ClickUp OAuth Application

1. Go to [ClickUp Integrations](https://clickup.com/integrations)
2. Create a new application
3. Copy the **Client ID** and **Client Secret**

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → ClickUp**
2. Enter the following credentials:
   - **Client ID** from your ClickUp application
   - **Client Secret** from your ClickUp application

### 3. Connect Your Workspace

1. Click **Connect to ClickUp**
2. You'll be redirected to ClickUp to authorize the application
3. Review the permissions and click **Allow**

After authorization, Quackback automatically detects your ClickUp team (workspace).

### 4. Select a Space and List

Back in Quackback:

1. Choose the ClickUp space that contains your target list
2. Then choose the specific list where tasks should be created
3. Tasks will be created in this list when new feedback is submitted

### 5. Configure Status Mappings

Map ClickUp task statuses to Quackback statuses:

1. Go to the ClickUp integration settings
2. Configure status mappings between ClickUp statuses and Quackback statuses
3. Each ClickUp status can be mapped to a corresponding Quackback status, or set to ignore

Status sync works via ClickUp webhooks. When a linked ClickUp task's status changes, the corresponding Quackback post status updates automatically.

### 6. Configure Events

Choose which events trigger ClickUp actions:

| Event | Action |
|-------|--------|
| New post | Create a ClickUp task with the feedback details |

### 7. Save and Test

1. Click **Save**
2. Submit test feedback to verify a task is created in ClickUp

## Task Format

When a new feedback post triggers task creation, the ClickUp task includes:

- **Name**: The feedback post title
- **Description** (Markdown): The post content, followed by metadata including the author, board, vote count, and a link back to the post in Quackback

The task is created in the selected list within your connected ClickUp workspace.

## Status Sync

When status sync is configured, Quackback registers a webhook with ClickUp to receive `taskStatusUpdated` events. When a linked ClickUp task's status changes:

1. ClickUp sends a webhook event to Quackback
2. Quackback extracts the new status from the event's history items
3. If a status mapping exists for that status name, the linked feedback post's status is updated

The webhook signature is verified using HMAC-SHA256 via the `X-Signature` header.

## On post delete

When you delete a feedback post with a linked ClickUp task, you can close the task at the same time. The delete dialog shows a checkbox for each linked task.

To pre-check this by default, enable the **On post delete** toggle in the ClickUp integration settings. You can always override the default per-delete.

## Manage the integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → ClickUp**
2. Toggle **Enabled** off
3. Task creation and status sync pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in ClickUp

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → ClickUp**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Tasks Not Being Created

1. **Check integration status** -- look for errors in settings
2. **Verify list selection** -- ensure a ClickUp space and list are selected
3. **Check event mappings** -- confirm `post.created` is mapped
4. **Workspace access** -- the connected ClickUp account must have access to the selected list

### Status Sync Not Working

1. **Check status mappings** -- ensure ClickUp statuses are mapped to Quackback statuses
2. **Verify webhook** -- the ClickUp webhook may need to be re-registered
3. **Check permissions** -- the connected account needs access to manage webhooks

### "Authentication Failed" Error

ClickUp access tokens do not expire. If you see this error:

1. The token may have been manually revoked in ClickUp
2. Click **Reconnect** and re-authorize the app

## Next Steps

- [Asana](/docs/integrations/asana) - Asana task sync integration
- [Webhooks](/docs/integrations/webhooks) - Build custom integrations
- [Integrations Overview](/docs/integrations/overview) - All integrations

- [Discord](https://quackback.io/docs/integrations/discord): Get feedback notifications in your Discord server.

# Discord

Feedback where your community lives. Get notified in Discord channels when new feedback arrives, statuses change, or users comment. Messages use rich embeds with post details and direct links back to your portal.

## Overview

The Discord integration sends notifications to channels when:
- New feedback is submitted
- Post status changes
- New comments are posted

## Prerequisites

- Admin access to your Quackback workspace
- A Discord application with a bot user (created at [Discord Developer Portal](https://discord.com/developers/applications))
- Permission to add bots to your Discord server

## Setup

### 1. Create a Discord Application

1. Go to the [Discord Developer Portal](https://discord.com/developers/applications)
2. Click **New Application** and give it a name
3. Go to the **Bot** tab and create a bot user
4. Copy the **Bot Token**

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → Discord**
2. Enter the following credentials:
   - **Client ID** from your Discord application's General Information page
   - **Client Secret** from your Discord application's General Information page
   - **Bot Token** from your Discord application's Bot page

### 3. Connect Your Server

1. Click **Connect to Discord**
2. You'll be redirected to Discord to authorize the bot
3. Select the server you want to add the bot to
4. Click **Authorize**

The bot requests these permissions:
- **Send Messages** (2048) -- post notifications to channels
- **Embed Links** (16384) -- format messages with rich embeds

### 4. Select a Channel

Back in Quackback:

1. Choose a channel for notifications
2. Select from text channels available in the connected server

### 5. Configure Events

Choose which events trigger Discord notifications:

| Event | Description |
|-------|-------------|
| New post | Someone submits new feedback |
| Status change | Post status is updated |
| New comment | Comment added to a post |

### 6. Save and Test

1. Click **Save**
2. Click **Send Test** to verify the connection
3. Check your Discord channel for the test message

## Notification Format

Discord notifications use rich embeds with color-coded status indicators.

**New post:**
```
[Embed]
Author: New feedback from jane@example.com
Title: Add dark mode support (linked to post)
Description: It would be great to have a dark mode...
Footer: Board: feature-requests
Color: Blue (#5865F2)
```

**Status change:**
```
[Embed]
Author: Status changed by admin@example.com
Title: Add dark mode support (linked to post)
Description: Under Review > **Planned**
Color: Status-dependent (green for Complete, yellow for In Progress, etc.)
```

**New comment:**
```
[Embed]
Author: New comment from jane@example.com
Title: Add dark mode support (linked to post)
Description: Great idea! We're considering this for Q2.
Color: Blue (#5865F2)
```

All notifications include clickable links to the post.

## Event Mapping

Send different events to different channels:

1. Go to the Discord integration settings
2. Click **Add Event Mapping**
3. Configure:
   - **Event type**: post.created, post.status_changed, etc.
   - **Channel**: Target Discord channel
   - **Filters** (optional): Board, status, or other conditions

## Manage the integration

### Pause Notifications

Temporarily stop notifications:

1. Go to **Admin → Settings → Integrations → Discord**
2. Toggle **Enabled** off
3. Notifications pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in Discord
3. Reconfigure channels if needed

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Discord**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Notifications Not Appearing

1. **Check integration status** -- look for errors in settings
2. **Verify channel** -- ensure the channel still exists and the bot has access
3. **Check event mappings** -- confirm events are configured
4. **Bot permissions** -- verify the bot has Send Messages and Embed Links permissions in the channel

### "Authentication Failed" Error

The bot token may be invalid or the bot was removed from the server:

1. Check the bot token in your Discord Developer Portal
2. Re-authorize the bot in your server
3. Reconnect in Quackback

## Next Steps

- [Slack](/docs/integrations/slack) - Slack notification integration
- [Webhooks](/docs/integrations/webhooks) - Build custom integrations
- [Integrations Overview](/docs/integrations/overview) - All integrations

- [Email Notifications](https://quackback.io/docs/integrations/email): Notify users and teams by email when feedback is submitted, statuses change, or comments are posted. Configure SMTP or Resend.

# Email Notifications

Quackback sends email notifications to keep users and admins informed. Voters are notified when their requested features ship. Admins get alerts when new feedback arrives. No third-party notification service required — configure SMTP or Resend and emails send automatically.

## Overview

Email notifications cover two audiences:

**For end users (voters and authors):**
- Status change notifications when a post they voted on or authored changes status
- Comment notifications when someone replies to their post
- Subscription updates for posts they're watching

**For admins and team members:**
- New feedback alerts when a post is submitted
- Daily or weekly digest of new feedback activity
- Mentions when tagged in a comment

## Prerequisites

- Admin access to your Quackback workspace
- An SMTP server or Resend API key

## Setup

### Option 1: SMTP (Recommended)

SMTP works with any email provider: Gmail, SendGrid, Postmark, Mailgun, Amazon SES, or your own mail server.

Set these environment variables:

```bash
EMAIL_SMTP_HOST="smtp.example.com"
EMAIL_SMTP_PORT="587"
EMAIL_SMTP_USER="your-username"
EMAIL_SMTP_PASS="your-password"
EMAIL_FROM="feedback@yourcompany.com"
```

Common provider settings:

| Provider | Host | Port |
|----------|------|------|
| SendGrid | `smtp.sendgrid.net` | 587 |
| Postmark | `smtp.postmarkapp.com` | 587 |
| Mailgun | `smtp.mailgun.org` | 587 |
| Amazon SES | `email-smtp.{region}.amazonaws.com` | 587 |
| Gmail | `smtp.gmail.com` | 587 |

### Option 2: Resend

[Resend](https://resend.com) provides a developer-focused email API. Set one environment variable:

```bash
EMAIL_RESEND_API_KEY="re_xxxxxxxxxxxx"
EMAIL_FROM="feedback@yourcompany.com"
```

## How Notifications Work

### User Notifications

Users receive email when events occur on posts they're connected to:

| Event | Who gets notified |
|-------|-------------------|
| Status change (e.g., "Planned" → "Shipped") | All voters and the post author |
| New comment on a post | Post author and users watching the post |
| Admin reply to a post | Post author |

Users can unsubscribe from individual posts or all notifications from their account settings.

### Admin Notifications

Admins receive email for workspace-level events:

| Event | Who gets notified |
|-------|-------------------|
| New post submitted | Admins with new-post alerts enabled |
| Daily/weekly digest | Admins who opted into digest emails |
| @mention in a comment | The mentioned admin |

Configure admin notification preferences in **Admin → Settings → Notifications**.

### Authentication Emails

Quackback uses email for passwordless authentication:

- **OTP codes** — six-digit codes sent when a user signs in with email
- **Magic links** — one-click sign-in links (when enabled)

These are sent regardless of notification preferences.

## Configuration

### Sender Identity

The `EMAIL_FROM` address appears in the "From" field of all emails. Use a domain you own and have configured with SPF, DKIM, and DMARC records. This improves deliverability and prevents emails from landing in spam.

### Custom Branding

Emails automatically use your workspace branding:

- **Logo** — displayed in the email header
- **Workspace name** — used in email subjects and footers
- **Accent color** — applied to buttons and links

Configure branding in **Admin → Settings → Branding**.

### Digest Emails

Digest emails summarize feedback activity over a period:

1. Go to **Admin → Settings → Notifications**
2. Enable **Digest emails**
3. Choose frequency: **Daily** or **Weekly**
4. Select which boards to include

Digests include:
- New posts submitted since the last digest
- Top posts by vote count
- Status changes

## Testing

After configuring email, verify it works:

1. Go to **Admin → Settings → Email**
2. Click **Send Test Email**
3. Check your inbox for the test message

If the test email doesn't arrive:
- Check the server logs for SMTP errors
- Verify your SMTP credentials
- Ensure the `EMAIL_FROM` domain has valid DNS records

## Deliverability

To ensure emails reach inboxes:

1. **Set up SPF** — add your email provider to your domain's SPF record
2. **Enable DKIM** — sign outgoing emails with your domain's DKIM key
3. **Configure DMARC** — set a DMARC policy for your sending domain
4. **Use a dedicated sending domain** — avoid sharing reputation with marketing emails

## Troubleshooting

### Emails Not Sending

1. Check that `EMAIL_SMTP_HOST` or `EMAIL_RESEND_API_KEY` is set
2. Review server logs for connection errors
3. Verify the SMTP port is not blocked by your hosting provider

### Emails Going to Spam

1. Verify SPF, DKIM, and DMARC records for your sending domain
2. Avoid using free email providers (gmail.com, outlook.com) as the `EMAIL_FROM` address
3. Check your sender reputation with [mail-tester.com](https://www.mail-tester.com)

### Users Not Receiving Notifications

1. Check the user's notification preferences in their account settings
2. Verify they haven't unsubscribed from the post
3. Check the admin inbox for delivery errors

## Next Steps

- [Slack Integration](/docs/integrations/slack) - Real-time Slack notifications
- [Discord Integration](/docs/integrations/discord) - Discord channel notifications
- [Webhooks](/docs/integrations/webhooks) - Build custom notification pipelines

- [Freshdesk](https://quackback.io/docs/integrations/freshdesk): Enrich feedback with support ticket data from Freshdesk.

# Freshdesk

See the support story behind every request. Automatically match feedback authors to Freshdesk contacts and surface their support history, open tickets, and satisfaction scores alongside their feedback.

## Overview

The Freshdesk integration enables:

- **Ticket enrichment** -- automatically match feedback authors to Freshdesk contacts and display their support history
- **Contact lookup** -- look up contacts by email to see open tickets, satisfaction scores, and account details

## Prerequisites

- Admin access to your Quackback workspace
- A Freshdesk account with API access
- Your Freshdesk subdomain and an API key

## Setup

### 1. Get Your Freshdesk API Key

1. Log in to your Freshdesk account
2. Click your profile icon in the top-right
3. Go to **Profile Settings**
4. Copy the **API Key** from the right sidebar

### 2. Connect to Freshdesk

1. Go to **Admin → Settings → Integrations → Freshdesk**
2. Click **Connect to Freshdesk**
3. Enter your **Freshdesk subdomain** (e.g., `yourcompany` from `yourcompany.freshdesk.com`)
4. Enter your **API key**
5. Click **Connect**

### 3. Save and Test

1. Click **Save**
2. Submit test feedback with an email address that matches a Freshdesk contact
3. The feedback post will be enriched with the contact's data

## How Enrichment Works

When new feedback is submitted, Quackback:

1. Looks up the author's email in Freshdesk via the Contacts API
2. If a match is found, links the feedback post to the Freshdesk contact
3. Displays the contact's support context alongside the feedback

This gives your team immediate visibility into whether a feedback author has open support tickets, their satisfaction history, and account details.

## Manage the Integration

### Pause

Temporarily stop enrichment:

1. Go to **Admin → Settings → Integrations → Freshdesk**
2. Toggle **Enabled** off
3. Enrichment pauses, but the connection remains

### Reconnect

If you see connection errors:

1. Verify your API key is still valid in Freshdesk
2. Update the credentials in Quackback if needed

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Freshdesk**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Contacts Not Being Matched

1. **Check email addresses** -- the feedback author's email must exactly match a Freshdesk contact
2. **Verify API key** -- ensure the key has permission to read contacts
3. **Check integration status** -- look for errors in settings

### "Authentication Failed" Error

Your API key may have been revoked or expired:

1. Generate a new API key in Freshdesk
2. Update the key in Quackback's integration settings

## Next Steps

- [Zendesk](/docs/integrations/zendesk) -- Zendesk support integration
- [Intercom](/docs/integrations/intercom) -- Intercom support integration
- [Integrations Overview](/docs/integrations/overview) -- All integrations

- [GitHub](https://quackback.io/docs/integrations/github): Create GitHub issues from feedback and sync status updates.

# GitHub

Turn feedback into trackable issues. Automatically create GitHub issues when feedback is submitted, and keep statuses synchronized between Quackback and GitHub. When an issue is closed or reopened in GitHub, the linked feedback post updates too.

## Overview

The GitHub integration enables:

- **Create issues from feedback posts** -- automatically create a GitHub issue when new feedback is submitted
- **Link posts to issues** -- link feedback posts to GitHub issues for traceability
- **Status sync** -- update feedback status when GitHub issues are closed or reopened via inbound webhooks

## Prerequisites

- Admin access to your Quackback workspace
- A GitHub account with access to the target repositories
- A GitHub OAuth application (created at [GitHub Developer Settings](https://github.com/settings/developers))

## Setup

### 1. Create a GitHub OAuth Application

1. Go to [GitHub Developer Settings](https://github.com/settings/developers)
2. Click **New OAuth App**
3. Fill in the application details (set the callback URL to your Quackback instance)
4. Copy the **Client ID** and **Client Secret**

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → GitHub**
2. Enter the following credentials:
   - **Client ID** from your GitHub OAuth application
   - **Client Secret** from your GitHub OAuth application

### 3. Connect Your Account

1. Click **Connect to GitHub**
2. You'll be redirected to GitHub to authorize the application
3. Review the permissions and click **Authorize**

The app requests the `repo` OAuth scope, which grants read and write access to repositories (needed to create issues and register webhooks).

### 4. Select a Repository

Back in Quackback:

1. Choose the GitHub repository where issues should be created
2. The repository list shows up to 100 repositories you have access to, sorted by most recently updated

### 5. Configure Status Mappings

Map GitHub issue states to Quackback statuses:

1. Go to the GitHub integration settings
2. Configure status mappings between GitHub states and Quackback statuses
3. GitHub uses two states: **Open** and **Closed** -- map each to the corresponding Quackback status, or set it to ignore

Status sync works via GitHub webhooks. When a linked GitHub issue is closed or reopened, the corresponding Quackback post status updates automatically.

### 6. Configure Events

Choose which events trigger GitHub actions:

| Event | Action |
|-------|--------|
| New post | Create a GitHub issue with the feedback details |

### 7. Save and Test

1. Click **Save**
2. Submit test feedback to verify an issue is created in the selected repository

## Issue Format

When a new feedback post triggers issue creation, the GitHub issue includes:

- **Title**: The feedback post title
- **Body**: The post content in Markdown, followed by metadata including the author, board, vote count, and a link back to the post in Quackback

## Status Sync

When status sync is configured, Quackback registers a webhook with GitHub to receive issue events. When a linked GitHub issue is closed or reopened:

1. GitHub sends a webhook to Quackback
2. Quackback verifies the signature using HMAC-SHA256 via the `X-Hub-Signature-256` header
3. Quackback looks up the status mapping for the new state (Open or Closed)
4. If a mapping exists, the linked feedback post's status is updated

The webhook listens for the `issues` event and handles the `closed` and `reopened` actions.

## On post delete

When you delete a feedback post with a linked GitHub issue, you can close the issue at the same time. The delete dialog shows a checkbox for each linked issue.

To pre-check this by default, enable the **On post delete** toggle in the GitHub integration settings. You can always override the default per-delete.

## Manage the integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → GitHub**
2. Toggle **Enabled** off
3. Issue creation and status sync pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in GitHub

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → GitHub**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Issues Not Being Created

1. **Check integration status** -- look for errors in settings
2. **Verify repository** -- ensure a repository is selected and accessible
3. **Check event mappings** -- confirm `post.created` is mapped
4. **Repository permissions** -- the connected GitHub account must have write access to the repository

### Status Sync Not Working

1. **Check status mappings** -- ensure GitHub states are mapped to Quackback statuses
2. **Verify webhook** -- the GitHub webhook may need to be re-registered
3. **Repository access** -- the connected account needs admin access to register webhooks

### "Authentication Failed" Error

GitHub OAuth tokens do not expire, but they can be revoked:

1. Click **Reconnect**
2. Re-authorize the app in GitHub

### "Repository Not Found" Error

The repository may have been:
- Deleted or renamed
- Made private (if the connected account lost access)
- Transferred to a different owner

## Next Steps

- [Jira](/docs/integrations/jira) - Jira issue integration
- [Webhooks](/docs/integrations/webhooks) - Build custom integrations
- [Integrations Overview](/docs/integrations/overview) - All integrations

- [GitLab](https://quackback.io/docs/integrations/gitlab): Create issues in GitLab from feedback and sync statuses.

# GitLab

Turn feedback into tracked issues. Automatically create GitLab issues when feedback arrives, and keep statuses synchronized -- when an issue is closed or reopened in GitLab, the linked feedback post updates too.

## Overview

The GitLab integration enables:

- **Create issues from feedback** -- automatically create a GitLab issue when new feedback is submitted
- **Two-way status sync** -- closing or reopening issues in GitLab updates the feedback status in Quackback via webhooks
- **Rich descriptions** -- issues include feedback details, author info, and direct links back to your portal

## Prerequisites

- Admin access to your Quackback workspace
- A GitLab account with access to the target project
- A GitLab OAuth application (created at [User Settings > Applications](https://gitlab.com/-/user_settings/applications))

## Setup

### 1. Create a GitLab OAuth Application

1. Go to [GitLab User Settings > Applications](https://gitlab.com/-/user_settings/applications)
2. Create a new application
3. Set the **Redirect URI** to your Quackback callback URL
4. Select the `api` scope
5. Copy the **Application ID** and **Secret**

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → GitLab**
2. Enter the following credentials:
   - **Application ID** from your GitLab OAuth application
   - **Secret** from your GitLab OAuth application

### 3. Connect Your Account

1. Click **Connect to GitLab**
2. You'll be redirected to GitLab to authorize the application
3. Review the permissions and click **Authorize**

### 4. Select a Project

Back in Quackback:

1. Choose the GitLab project where issues should be created
2. Issues will be created in this project when new feedback is submitted

### 5. Configure Status Mappings

Map GitLab issue states to Quackback statuses:

| GitLab State | Default Mapping |
|--------------|-----------------|
| `opened` | Open |
| `closed` | Closed |

You can customize these mappings to match your workflow.

### 6. Save and Test

1. Click **Save**
2. Submit test feedback to verify an issue is created in GitLab

## Issue Format

When feedback triggers issue creation, the GitLab issue includes:

- **Title**: The feedback post title
- **Description**: The post content, author details, board name, vote count, and a link back to the post in Quackback

## Status Sync

Quackback registers a webhook with GitLab to receive issue updates. When a linked issue's state changes:

1. GitLab sends a webhook to Quackback
2. The webhook signature is verified via the `X-Gitlab-Token` header
3. If the issue state changed (opened, closed, or reopened), the linked feedback post's status is updated

## On post delete

When you delete a feedback post with a linked GitLab issue, you can close the issue at the same time. The delete dialog shows a checkbox for each linked issue.

To pre-check this by default, enable the **On post delete** toggle in the GitLab integration settings. You can always override the default per-delete.

## Manage the Integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → GitLab**
2. Toggle **Enabled** off
3. Issue creation and status sync pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in GitLab

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → GitLab**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Issues Not Being Created

1. **Check integration status** -- look for errors in settings
2. **Verify project selection** -- ensure a GitLab project is selected
3. **Check permissions** -- the connected account needs write access to the project

### Status Sync Not Working

1. **Check status mappings** -- ensure GitLab states are mapped to Quackback statuses
2. **Verify webhook** -- the GitLab webhook may need to be re-registered
3. **Check project permissions** -- the connected account needs admin access to manage webhooks

### "Authentication Failed" Error

1. Click **Reconnect**
2. Re-authorize the app in GitLab

## Next Steps

- [GitHub](/docs/integrations/github) -- GitHub issue integration
- [Webhooks](/docs/integrations/webhooks) -- Build custom integrations
- [Integrations Overview](/docs/integrations/overview) -- All integrations

- [HubSpot](https://quackback.io/docs/integrations/hubspot): Enrich feedback with HubSpot contact data and deal value.

# HubSpot

See the revenue behind every feature request. Connect HubSpot to enrich feedback posts with contact data, company information, lifecycle stage, and deal pipeline value -- so you can prioritize what matters most to your bottom line.

## Overview

The HubSpot integration provides:

- **Customer context** -- enrich feedback with HubSpot contact data like company, deal value, and lifecycle stage
- **Revenue insights** -- see the revenue impact of feature requests by linking feedback to deal pipeline data

## Prerequisites

- Admin access to your Quackback workspace
- A HubSpot account with API access
- A HubSpot OAuth application (created in the [HubSpot Developer Portal](https://developers.hubspot.com/))

## Setup

### 1. Create a HubSpot OAuth Application

1. Go to the [HubSpot Developer Portal](https://developers.hubspot.com/)
2. Create a new app or use an existing one
3. Under the **Auth** tab, copy the **Client ID** and **Client Secret**
4. Add your Quackback OAuth callback URL as a redirect URI

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → HubSpot**
2. Enter the following credentials:
   - **Client ID** from your HubSpot application
   - **Client Secret** from your HubSpot application

### 3. Connect Your Account

1. Click **Connect to HubSpot**
2. You'll be redirected to HubSpot to authorize the application
3. Select the HubSpot account you want to connect
4. Review the permissions and click **Grant access**

The app requests these OAuth scopes:

| Scope | Purpose |
|-------|---------|
| `crm.objects.contacts.read` | Look up contacts by email |
| `crm.objects.companies.read` | Read company information |
| `crm.objects.deals.read` | Read deal pipeline data and amounts |
| `oauth` | Token management |

### 4. Verify the Connection

Once connected, Quackback stores your HubSpot portal ID and domain. You can verify the connection is active in the integration settings.

## How It Works

### Contact Lookup

When you view a feedback post, Quackback can look up the author's email in HubSpot and display:

- **Name** -- first and last name from the contact record
- **Company** -- the associated company name
- **Lifecycle stage** -- where the contact is in your pipeline (subscriber, lead, customer, etc.)

### Deal Enrichment

Beyond basic contact data, the integration fetches associated deals (up to 5 per contact) and shows:

- **Deal name** and current **stage**
- **Deal amount** for each associated deal
- **Total deal value** -- the combined value across all associated deals

This lets you see at a glance whether a feature request comes from a prospect with a \$500 deal or an enterprise customer with \$500,000 in pipeline.

### Token Refresh

HubSpot access tokens expire after 30 minutes. Quackback automatically refreshes tokens using the stored refresh token when they expire, so the connection stays active without manual intervention.

## Manage the Integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → HubSpot**
2. Toggle **Enabled** off
3. Contact lookups pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in HubSpot
3. Tokens are automatically refreshed when they expire

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → HubSpot**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Contact Not Found

1. **Check the email** -- the lookup matches on exact email address
2. **Verify the contact exists** -- confirm the contact is in your HubSpot CRM
3. **Check permissions** -- the connected HubSpot account must have access to the contact

### Deal Data Missing

1. **Check deal associations** -- the contact must be associated with deals in HubSpot
2. **Verify deal properties** -- deals need `dealname`, `dealstage`, and `amount` properties populated
3. **Limit** -- only the first 5 associated deals are fetched

### "Authentication Failed" Error

HubSpot tokens are short-lived (30 minutes) and auto-refresh. If refresh fails:

1. Click **Reconnect**
2. Re-authorize the app in HubSpot
3. If the issue persists, verify your Client ID and Client Secret are still valid in the HubSpot Developer Portal

## Next Steps

- [Intercom](/docs/integrations/intercom) -- Enrich feedback with Intercom contact data
- [Zendesk](/docs/integrations/zendesk) -- Enrich feedback with Zendesk user data
- [Integrations Overview](/docs/integrations/overview) -- All integrations

- [Intercom](https://quackback.io/docs/integrations/intercom): Push feedback from Intercom conversations and sync customer data.

# Intercom

Know your customers behind every request. Connect Intercom to enrich feedback posts with contact data, company information, custom attributes, and tags -- so you can understand who is asking for what and why.

## Overview

The Intercom integration provides:

- **Capture feedback** -- turn Intercom conversations into feedback posts without leaving your inbox
- **Customer context** -- enrich feedback with Intercom contact data like plan, company, and conversation history

## Prerequisites

- Admin access to your Quackback workspace
- An Intercom workspace with admin access
- An Intercom OAuth application (created in the [Intercom Developer Hub](https://developers.intercom.com/))

## Setup

### 1. Create an Intercom OAuth Application

1. Go to the [Intercom Developer Hub](https://developers.intercom.com/)
2. Create a new app
3. Copy the **Client ID** and **Client Secret**
4. Add your Quackback OAuth callback URL as a redirect URI

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → Intercom**
2. Enter the following credentials:
   - **Client ID** from your Intercom application
   - **Client Secret** from your Intercom application

### 3. Connect Your Workspace

1. Click **Connect to Intercom**
2. You'll be redirected to Intercom to authorize the application
3. Review the permissions and click **Authorize**

After authorization, Quackback stores your Intercom app ID and workspace name.

### 4. Verify the Connection

Once connected, verify the integration shows as active in **Admin → Settings → Integrations → Intercom**.

## How It Works

### Contact Lookup

When you view a feedback post, Quackback can look up the author's email in Intercom and display:

- **Name** -- the contact's full name
- **Email** -- the contact's email address
- **Company** -- the associated company name and ID
- **Custom attributes** -- any custom data fields you have on the contact (e.g., plan name, account tier, MRR)
- **Tags** -- all tags applied to the contact in Intercom

### No Token Expiration

Unlike some OAuth providers, Intercom access tokens do not expire. Once connected, the integration stays active without requiring token refreshes.

## Manage the Integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → Intercom**
2. Toggle **Enabled** off
3. Contact lookups pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in Intercom

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Intercom**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Contact Not Found

1. **Check the email** -- the lookup matches on exact email address
2. **Verify the contact exists** -- confirm the contact is in your Intercom workspace
3. **Check contact type** -- both leads and users are searchable

### Custom Attributes Missing

1. **Verify the attribute exists** -- check that the custom attribute is defined in Intercom
2. **Check the contact record** -- the attribute must have a value set on the specific contact

### "Authentication Failed" Error

1. Verify your Client ID and Client Secret are correct
2. Click **Reconnect** and re-authorize the app
3. Check that the app has not been revoked in the Intercom Developer Hub

## Next Steps

- [HubSpot](/docs/integrations/hubspot) -- Enrich feedback with HubSpot contact and deal data
- [Zendesk](/docs/integrations/zendesk) -- Enrich feedback with Zendesk user data
- [Integrations Overview](/docs/integrations/overview) -- All integrations

- [Jira](https://quackback.io/docs/integrations/jira): Create and sync Jira issues from feedback posts.

# Jira

Push feedback into your Jira workflow. Automatically create Jira issues when feedback is submitted, choose the project and issue type, and keep statuses synchronized between Quackback and Jira. When an issue transitions through your Jira workflow, the linked feedback post updates too.

## Overview

The Jira integration enables:

- **Create issues from feedback posts** -- automatically create a Jira issue with a configurable project and issue type when new feedback is submitted
- **Link posts to issues** -- link feedback posts to Jira issues for traceability
- **Status sync** -- map Jira workflow statuses to feedback post statuses and keep them in sync via inbound webhooks

## Prerequisites

- Admin access to your Quackback workspace
- A Jira Cloud site with admin access
- An Atlassian OAuth application (created at [Atlassian Developer Console](https://developer.atlassian.com/console/myapps/))

## Setup

### 1. Create an Atlassian OAuth Application

1. Go to [Atlassian Developer Console](https://developer.atlassian.com/console/myapps/)
2. Create a new OAuth 2.0 (3LO) application
3. Configure the callback URL to point to your Quackback instance
4. Copy the **Client ID** and **Client Secret**

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → Jira**
2. Enter the following credentials:
   - **Client ID** from your Atlassian OAuth application
   - **Client Secret** from your Atlassian OAuth application

### 3. Connect Your Site

1. Click **Connect to Jira**
2. You'll be redirected to Atlassian to authorize the application
3. Select the Jira site to connect
4. Review the permissions and click **Accept**

The app requests these OAuth scopes: `read:jira-work`, `write:jira-work`, `offline_access`.

- `read:jira-work` -- read projects, issues, and workflow states
- `write:jira-work` -- create and update issues
- `offline_access` -- refresh the access token when it expires

### 4. Select a Project

Back in Quackback:

1. Choose the Jira project where issues should be created
2. Select the issue type (e.g., Task, Story, Bug) -- the list is fetched from the selected project

### 5. Configure Status Mappings

Map Jira workflow states to Quackback statuses:

1. Go to the Jira integration settings
2. Configure status mappings between Jira states and Quackback statuses
3. Mappings are configurable per workspace -- map each Jira state name to the corresponding Quackback status, or set it to ignore

Status sync works via Jira webhooks. When a linked Jira issue changes workflow state, the corresponding Quackback post status updates automatically.

### 6. Configure Events

Choose which events trigger Jira actions:

| Event | Action |
|-------|--------|
| New post | Create a Jira issue with the feedback details |

### 7. Save and Test

1. Click **Save**
2. Submit test feedback to verify an issue is created in the selected Jira project

## Issue Format

When a new feedback post triggers issue creation, the Jira issue includes:

- **Summary**: The feedback post title
- **Description**: The post content in Atlassian Document Format (ADF), followed by metadata including the author, board, vote count, and a link back to the post in Quackback

The description is formatted using Jira's native rich text format, so it renders correctly in the Jira UI.

## Status Sync

When status sync is configured, Quackback registers a webhook with Jira to receive issue update events. When a linked Jira issue's workflow state changes:

1. Jira sends a `jira:issue_updated` webhook to Quackback
2. Quackback verifies the signature using HMAC-SHA256 via the `X-Hub-Signature` header
3. Quackback checks the changelog for a status field change
4. If a status mapping exists for the new state, the linked feedback post's status is updated

## On post delete

When you delete a feedback post with a linked Jira issue, you can close the issue at the same time. The delete dialog shows a checkbox for each linked issue.

To pre-check this by default, enable the **On post delete** toggle in the Jira integration settings. You can always override the default per-delete.

## Manage the integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → Jira**
2. Toggle **Enabled** off
3. Issue creation and status sync pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in Jira
3. Tokens are automatically refreshed when they expire (within 5 minutes of expiry)

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Jira**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Issues Not Being Created

1. **Check integration status** -- look for errors in settings
2. **Verify project selection** -- ensure a Jira project is selected
3. **Check issue type** -- confirm a valid issue type is configured
4. **Check event mappings** -- confirm `post.created` is mapped
5. **Admin permissions** -- the connected Jira account must have permission to create issues in the selected project

### Status Sync Not Working

1. **Check status mappings** -- ensure Jira workflow states are mapped to Quackback statuses
2. **Verify webhook** -- the Jira webhook may need to be re-registered (webhooks expire after 30 days)
3. **Check permissions** -- the connected account needs access to the project's issues

### "Authentication Failed" Error

Jira OAuth tokens expire and are automatically refreshed. If refresh fails:

1. Click **Reconnect**
2. Re-authorize the app in Jira

### "Cloud ID Not Found" Error

This usually means the Atlassian site was not properly selected during authorization:

1. Click **Reconnect**
2. Ensure you select a Jira site when authorizing

## Next Steps

- [GitHub](/docs/integrations/github) - GitHub issue integration
- [Webhooks](/docs/integrations/webhooks) - Build custom integrations
- [Integrations Overview](/docs/integrations/overview) - All integrations

- [Linear](https://quackback.io/docs/integrations/linear): Create Linear issues from feedback and keep statuses in sync.

# Linear

Turn feedback into action. Automatically create Linear issues when feedback is submitted, and keep statuses synchronized between Quackback and Linear. When an issue moves through your Linear workflow, the linked feedback post updates too.

## Overview

The Linear integration enables:

- **Create Linear issues from feedback posts** -- automatically create an issue when new feedback is submitted
- **Link posts to issues** -- link feedback posts to Linear issues for traceability
- **Status sync** -- keep feedback status in sync with Linear issue workflow states via inbound webhooks

## Prerequisites

- Admin access to your Quackback workspace
- A Linear workspace with admin access
- A Linear OAuth application (created at [Linear Settings > API](https://linear.app/settings/api))

## Setup

### 1. Create a Linear OAuth Application

1. Go to [Linear Settings > API](https://linear.app/settings/api)
2. Create a new OAuth application
3. Copy the **Client ID** and **Client Secret**

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → Linear**
2. Enter the following credentials:
   - **Client ID** from your Linear OAuth application
   - **Client Secret** from your Linear OAuth application

### 3. Connect Your Workspace

1. Click **Connect to Linear**
2. You'll be redirected to Linear to authorize the application
3. Review the permissions and click **Authorize**

The app requests these OAuth scopes: `read`, `write`, `issues:create`, `admin`.

### 4. Select a Team

Back in Quackback:

1. Choose the Linear team where issues should be created
2. Issues will be created in this team when new feedback is submitted

### 5. Configure Status Mappings

Map Linear workflow states to Quackback statuses:

1. Go to the Linear integration settings
2. Configure status mappings between Linear states and Quackback statuses
3. Mappings are configurable per workspace -- map each Linear state name to the corresponding Quackback status, or set it to ignore

Status sync works bidirectionally via Linear webhooks. When a linked Linear issue changes state, the corresponding Quackback post status updates automatically.

### 6. Configure Events

Choose which events trigger Linear actions:

| Event | Action |
|-------|--------|
| New post | Create a Linear issue with the feedback details |

### 7. Save and Test

1. Click **Save**
2. Submit test feedback to verify an issue is created in Linear

## Issue Format

When a new feedback post triggers issue creation, the Linear issue includes:

- **Title**: The feedback post title
- **Description**: The post content, followed by metadata including the author, board, vote count, and a link back to the post in Quackback

## Status Sync

When status sync is configured, Quackback registers a webhook with Linear to receive issue updates. When a linked Linear issue's workflow state changes:

1. Linear sends a webhook to Quackback
2. Quackback looks up the status mapping for the new Linear state
3. If a mapping exists, the linked feedback post's status is updated

The webhook signature is verified using HMAC-SHA256 via the `Linear-Signature` header.

## On post delete

When you delete a feedback post with a linked Linear issue, you can archive the issue at the same time. The delete dialog shows a checkbox for each linked issue.

To pre-check this by default, enable the **On post delete** toggle in the Linear integration settings. You can always override the default per-delete.

## Manage the integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → Linear**
2. Toggle **Enabled** off
3. Issue creation and status sync pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in Linear
3. Tokens are automatically refreshed when they expire

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Linear**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Issues Not Being Created

1. **Check integration status** -- look for errors in settings
2. **Verify team selection** -- ensure a Linear team is selected
3. **Check event mappings** -- confirm `post.created` is mapped
4. **Admin permissions** -- the connected Linear account must have admin permissions to create webhooks

### Status Sync Not Working

1. **Check status mappings** -- ensure Linear states are mapped to Quackback statuses
2. **Verify webhook** -- the Linear webhook may need to be re-registered
3. **Check Linear permissions** -- the connected account needs admin access

### "Authentication Failed" Error

Linear OAuth tokens expire and are automatically refreshed. If refresh fails:

1. Click **Reconnect**
2. Re-authorize the app in Linear

## Next Steps

- [Slack](/docs/integrations/slack) - Slack notification integration
- [Webhooks](/docs/integrations/webhooks) - Build custom integrations
- [Integrations Overview](/docs/integrations/overview) - All integrations

- [Make](https://quackback.io/docs/integrations/make): Connect Quackback to Make (formerly Integromat) automation scenarios.

# Make

Automate your feedback workflow. Connect Quackback to Make (formerly Integromat) to trigger visual automation scenarios when feedback is submitted, statuses change, or comments are added. Route feedback data to 1,500+ apps without writing code.

## Overview

The Make integration enables:

- **Trigger scenarios** -- trigger Make scenarios when feedback is submitted, statuses change, or comments are added
- **Visual automation** -- build visual automation flows connecting feedback to 1,500+ apps in Make

## Prerequisites

- Admin access to your Quackback workspace
- A [Make](https://www.make.com) account

## Setup

### 1. Create a Webhook in Make

1. Log in to Make and create a new scenario
2. Add a **Webhooks > Custom webhook** module as the trigger
3. Click **Add** to create a new webhook
4. Copy the **webhook URL** (it will look like `https://hook.make.com/...`)

### 2. Connect in Quackback

1. Go to **Admin → Settings → Integrations → Make**
2. Click **Connect**
3. Paste the Make webhook URL
4. Click **Save**

### 3. Configure Events

Choose which events trigger your Make scenario:

| Event | Description |
|-------|-------------|
| New post | Someone submits new feedback |
| Status change | Post status is updated |
| New comment | Comment added to a post |

### 4. Test the Connection

1. Go back to Make and click **Run once** on your scenario
2. Submit test feedback in Quackback
3. Make should receive the webhook payload and display the data structure
4. Use this to configure the rest of your scenario

## Payload Format

Quackback sends a JSON payload to your Make webhook. The payload includes event details, post data, author information, and board context. Use Make's data mapping to route fields to downstream modules.

## Example Scenarios

### Send Feedback to Google Sheets

1. **Trigger**: Quackback webhook (new post)
2. **Action**: Google Sheets > Add a Row
3. Map fields: title, description, author email, board name

### Create Jira Tickets from High-Priority Feedback

1. **Trigger**: Quackback webhook (new post)
2. **Filter**: Check if board equals "Bug Reports"
3. **Action**: Jira > Create an Issue

### Notify a Slack Channel for Status Changes

1. **Trigger**: Quackback webhook (status change)
2. **Action**: Slack > Send a Message
3. Map fields: post title, old status, new status

## Manage the Integration

### Pause

Temporarily stop sending events:

1. Go to **Admin → Settings → Integrations → Make**
2. Toggle **Enabled** off
3. Events stop, but the webhook URL is preserved

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Make**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Events Not Arriving in Make

1. **Check integration status** -- look for errors in Quackback settings
2. **Verify webhook URL** -- ensure the URL is a valid `make.com` or `integromat.com` address
3. **Check Make scenario** -- ensure the scenario is active (not paused)
4. **Review Make execution history** -- check for errors in the scenario log

### Invalid Webhook URL

The webhook URL must be an HTTPS URL on a `make.com` or `integromat.com` domain. Custom domains are not supported.

## Next Steps

- [Zapier](/docs/integrations/zapier) -- Zapier automation integration
- [n8n](/docs/integrations/n8n) -- Self-hosted automation with n8n
- [Webhooks](/docs/integrations/webhooks) -- Build custom integrations

- [Microsoft Teams](https://quackback.io/docs/integrations/microsoft-teams): Post adaptive cards to your Teams channels when events occur.

# Microsoft Teams

Feedback in your Teams workspace. Get notified with rich Adaptive Cards in Microsoft Teams channels when new feedback arrives, statuses change, or users comment. Cards include post details and direct links back to your feedback portal.

## Overview

The Microsoft Teams integration sends Adaptive Card notifications to channels when:
- New feedback is submitted
- Post status changes
- New comments are posted

## Prerequisites

- Admin access to your Quackback workspace
- An Azure AD application registered in the [Azure Portal](https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps)
- Permission to grant OAuth consent in your Microsoft 365 tenant

## Setup

### 1. Register an Azure AD Application

1. Go to the [Azure Portal App Registrations](https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps)
2. Click **New registration**
3. Enter a name (e.g., "Quackback")
4. Under **Supported account types**, select **Accounts in any organizational directory**
5. Add a redirect URI (provided in your Quackback integration settings)
6. Click **Register**
7. Copy the **Application (client) ID**
8. Go to **Certificates & secrets**, create a new client secret, and copy the value

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → Teams**
2. Enter the following credentials:
   - **Client ID** from your Azure AD application
   - **Client Secret** from your Azure AD application

### 3. Connect Your Organization

1. Click **Connect to Teams**
2. You'll be redirected to Microsoft to authorize the application
3. Review the permissions and click **Accept**

The app requests these OAuth scopes:
- `ChannelMessage.Send` -- post messages to channels
- `Team.ReadBasic.All` -- list your teams
- `Channel.ReadBasic.All` -- list channels within teams
- `offline_access` -- refresh tokens automatically

### 4. Select a Team and Channel

Back in Quackback:

1. Choose the team you want to post to
2. Select a channel within that team for notifications
3. Both standard and private channels are listed

### 5. Configure Events

Choose which events trigger Teams notifications:

| Event | Description |
|-------|-------------|
| New post | Someone submits new feedback |
| Status change | Post status is updated |
| New comment | Comment added to a post |

### 6. Save and Test

1. Click **Save**
2. Click **Send Test** to verify the connection
3. Check your Teams channel for the test message

## Notification Format

Teams notifications use Adaptive Cards for rich, structured messages.

**New post:**
```
Adaptive Card
Header: New feedback from jane@example.com
Title: Add dark mode support
Body: It would be great to have a dark mode...
Footer: Board: feature-requests
Action: [View in Portal] (links to post)
```

**Status change:**
```
Adaptive Card
Header: Status changed by admin@example.com
Title: Add dark mode support
Body: Under Review -> Planned
Action: [View in Portal] (links to post)
```

**New comment:**
```
Adaptive Card
Header: New comment from jane@example.com
Title: Add dark mode support
Body: Great idea! We're considering this for Q2.
Action: [View in Portal] (links to post)
```

All cards include a "View in Portal" button that links directly to the post.

## Event Mapping

Send different events to different channels:

1. Go to the Teams integration settings
2. Click **Add Event Mapping**
3. Configure:
   - **Event type**: post.created, post.status\_changed, etc.
   - **Team**: Target team
   - **Channel**: Target channel within the team
   - **Filters** (optional): Board, status, or other conditions

## Manage the integration

### Pause Notifications

Temporarily stop notifications:

1. Go to **Admin → Settings → Integrations → Teams**
2. Toggle **Enabled** off
3. Notifications pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in Microsoft
3. Reconfigure teams and channels if needed

Tokens are automatically refreshed when they expire. If a refresh fails, you will need to reconnect.

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Teams**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Notifications Not Appearing

1. **Check integration status** -- look for errors in settings
2. **Verify channel** -- ensure the team and channel still exist
3. **Check event mappings** -- confirm events are configured
4. **App permissions** -- verify the app has been granted consent in your tenant

### "Team ID Not Configured" Error

The integration requires both a team and channel to be selected:

1. Go to the Teams integration settings
2. Select a team from the list
3. Select a channel within that team

### "Authentication Failed" Error

1. Click **Reconnect**
2. Re-authorize the app with Microsoft
3. Test the connection

### Rate Limiting

Microsoft Graph API enforces rate limits. If you see rate-limit errors, notifications are automatically retried. Reduce notification volume by filtering events if this occurs frequently.

## Permissions

The Azure AD application requires:

| Permission | Purpose |
|------------|---------|
| `ChannelMessage.Send` | Post Adaptive Cards to channels |
| `Team.ReadBasic.All` | List teams you're a member of |
| `Channel.ReadBasic.All` | List channels within a team |
| `offline_access` | Refresh access tokens automatically |

## Next Steps

- [Slack](/docs/integrations/slack) - Slack notification integration
- [Webhooks](/docs/integrations/webhooks) - Build custom integrations
- [Integrations Overview](/docs/integrations/overview) - All integrations

- [Monday.com](https://quackback.io/docs/integrations/monday): Create items in Monday.com from feedback and sync statuses.

# Monday.com

Feedback straight to your board. Automatically create Monday.com items when feedback is submitted, and keep statuses synchronized between Quackback and Monday.com. Select which board and group to use, with rich descriptions that include all the context your team needs.

## Overview

The Monday.com integration enables:

- **Create items from feedback** -- automatically create a Monday.com item when new feedback is submitted
- **Two-way status sync** -- status changes in Monday.com update the feedback status in Quackback and vice versa
- **Board integration** -- select which board and group to create items in, with rich descriptions

## Prerequisites

- Admin access to your Quackback workspace
- A Monday.com account with admin access
- A Monday.com app (created at [Monday Developer Portal](https://developer.monday.com/apps/manage))

## Setup

### 1. Create a Monday.com App

1. Go to the [Monday Developer Portal](https://developer.monday.com/apps/manage)
2. Create a new app
3. Copy the **Client ID** and **Client Secret**

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → Monday.com**
2. Enter the following credentials:
   - **Client ID** from your Monday.com app
   - **Client Secret** from your Monday.com app

### 3. Connect Your Workspace

1. Click **Connect to Monday.com**
2. You'll be redirected to Monday.com to authorize the application
3. Review the permissions and click **Authorize**

### 4. Select a Board and Group

Back in Quackback:

1. Choose the Monday.com board where items should be created
2. Optionally select a specific group within the board
3. Items will be created in this location when new feedback is submitted

### 5. Configure Status Mappings

Map Monday.com statuses to Quackback statuses. Status sync works bidirectionally -- changes in either platform update the other.

### 6. Save and Test

1. Click **Save**
2. Submit test feedback to verify an item is created in Monday.com

## Item Format

When feedback triggers item creation, the Monday.com item includes:

- **Item name**: The feedback post title
- **Update (comment)**: The post content with feedback details, author info, and a link back to the post in Quackback

## On post delete

When you delete a feedback post with a linked Monday item, you can archive the item at the same time. The delete dialog shows a checkbox for each linked item.

To pre-check this by default, enable the **On post delete** toggle in the Monday integration settings. You can always override the default per-delete.

## Manage the Integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → Monday.com**
2. Toggle **Enabled** off
3. Item creation pauses, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in Monday.com

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Monday.com**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Items Not Being Created

1. **Check integration status** -- look for errors in settings
2. **Verify board selection** -- ensure a Monday.com board is selected
3. **Check permissions** -- the connected account needs write access to the board

### "Authentication Failed" Error

1. Click **Reconnect**
2. Re-authorize the app in Monday.com

## Next Steps

- [Linear](/docs/integrations/linear) -- Linear issue integration
- [Webhooks](/docs/integrations/webhooks) -- Build custom integrations
- [Integrations Overview](/docs/integrations/overview) -- All integrations

- [n8n](https://quackback.io/docs/integrations/n8n): Connect Quackback to your self-hosted n8n automation workflows.

# n8n

Automate on your terms. Connect Quackback to your self-hosted n8n instance to trigger workflows when feedback is submitted, statuses change, or comments are added. Keep your automation pipelines on your own infrastructure with full control.

## Overview

The n8n integration enables:

- **Trigger workflows** -- trigger n8n workflows when feedback is submitted, statuses change, or comments are added
- **Self-hosted automation** -- keep your automation pipelines on your own infrastructure with full control

## Prerequisites

- Admin access to your Quackback workspace
- An [n8n](https://n8n.io) instance (self-hosted or cloud)
- A webhook node set up in n8n

## Setup

### 1. Create a Webhook in n8n

1. Open n8n and create a new workflow
2. Add a **Webhook** node as the trigger
3. Set the HTTP method to **POST**
4. Copy the **webhook URL** (production URL, not the test URL)

### 2. Connect in Quackback

1. Go to **Admin → Settings → Integrations → n8n**
2. Click **Connect**
3. Paste the n8n webhook URL
4. Click **Save**

### 3. Configure Events

Choose which events trigger your n8n workflow:

| Event | Description |
|-------|-------------|
| New post | Someone submits new feedback |
| Status change | Post status is updated |
| New comment | Comment added to a post |

### 4. Test the Connection

1. Activate your n8n workflow
2. Submit test feedback in Quackback
3. Check the n8n execution history to verify the webhook was received
4. Use the received data to configure the rest of your workflow

## Payload Format

Quackback sends a JSON payload to your n8n webhook. The payload includes event details, post data, author information, and board context. Use n8n's expression editor to map fields to downstream nodes.

## Example Workflows

### Feedback to Database

1. **Trigger**: Quackback webhook (new post)
2. **Action**: Postgres/MySQL node > Insert row
3. Map fields: title, description, author email, board name

### Slack Alert for Bug Reports

1. **Trigger**: Quackback webhook (new post)
2. **Filter**: IF node checking board name equals "Bug Reports"
3. **Action**: Slack node > Send message

### Sync to Airtable

1. **Trigger**: Quackback webhook (all events)
2. **Action**: Airtable node > Create/Update record
3. Map fields and use the event type to determine the action

## Manage the Integration

### Pause

Temporarily stop sending events:

1. Go to **Admin → Settings → Integrations → n8n**
2. Toggle **Enabled** off
3. Events stop, but the webhook URL is preserved

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → n8n**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Events Not Arriving in n8n

1. **Check integration status** -- look for errors in Quackback settings
2. **Verify webhook URL** -- ensure the URL is HTTPS
3. **Check workflow status** -- ensure the n8n workflow is active (not just saved)
4. **Check n8n logs** -- review execution history for errors

### Using a Test URL

If you pasted the n8n **test URL** (contains `/webhook-test/`), events will only arrive when n8n is in listening mode. Switch to the **production URL** (contains `/webhook/`) for reliable delivery.

### Self-Hosted n8n Not Reachable

Your n8n instance must be accessible from the internet for Quackback to send webhooks. If self-hosting behind a firewall, ensure the webhook endpoint is exposed via a reverse proxy or tunnel.

## Next Steps

- [Make](/docs/integrations/make) -- Make automation integration
- [Zapier](/docs/integrations/zapier) -- Zapier automation integration
- [Webhooks](/docs/integrations/webhooks) -- Build custom integrations

- [Notion](https://quackback.io/docs/integrations/notion): Create database items in Notion from feedback and sync statuses.

# Notion

Feedback in your workspace. Automatically create pages in a Notion database when feedback is submitted. Each page includes rich content with feedback details, author info, and direct links back to your portal.

## Overview

The Notion integration enables:

- **Create database items from feedback** -- automatically create a page in a Notion database when new feedback is submitted
- **Two-way status sync** -- keep feedback statuses in sync between Notion and Quackback
- **Rich content** -- feedback details, author info, and direct links are included in the Notion page

## Prerequisites

- Admin access to your Quackback workspace
- A Notion workspace with admin access
- A Notion integration (created at [Notion Developers](https://developers.notion.com/docs/create-a-notion-integration))

## Setup

### 1. Create a Notion Integration

1. Go to [Notion Developers](https://developers.notion.com/docs/create-a-notion-integration)
2. Create a new integration
3. Copy the **OAuth Client ID** and **OAuth Client Secret**

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → Notion**
2. Enter the following credentials:
   - **OAuth Client ID** from your Notion integration
   - **OAuth Client Secret** from your Notion integration

### 3. Connect Your Workspace

1. Click **Connect to Notion**
2. You'll be redirected to Notion to authorize the integration
3. Select which pages and databases to share with Quackback
4. Click **Allow access**

### 4. Select a Database

Back in Quackback:

1. Choose the Notion database where pages should be created
2. Pages will be created in this database when new feedback is submitted

### 5. Configure Status Mappings

Map Notion status properties to Quackback statuses. Status sync works bidirectionally -- changes in either platform update the other.

### 6. Save and Test

1. Click **Save**
2. Submit test feedback to verify a page is created in your Notion database

## Page Format

When feedback triggers page creation, the Notion page includes:

- **Title**: The feedback post title
- **Content blocks**: The post content, author details, board name, vote count, and a link back to the post in Quackback

## On post delete

When you delete a feedback post with a linked Notion page, you can archive the page at the same time. The delete dialog shows a checkbox for each linked page.

To pre-check this by default, enable the **On post delete** toggle in the Notion integration settings. You can always override the default per-delete.

## Manage the Integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → Notion**
2. Toggle **Enabled** off
3. Page creation pauses, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in Notion
3. Reselect the pages and databases to share

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Notion**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Pages Not Being Created

1. **Check integration status** -- look for errors in settings
2. **Verify database selection** -- ensure a Notion database is selected
3. **Check access** -- the integration must have access to the selected database (granted during OAuth authorization)

### "Authentication Failed" Error

1. Click **Reconnect**
2. Re-authorize the integration in Notion

### Database Not Appearing

The database must be shared with the integration during the OAuth authorization step. Reconnect and select the database when prompted.

## Next Steps

- [Linear](/docs/integrations/linear) -- Linear issue integration
- [Webhooks](/docs/integrations/webhooks) -- Build custom integrations
- [Integrations Overview](/docs/integrations/overview) -- All integrations

- [ntfy](https://quackback.io/docs/integrations/ntfy): Send push notifications to any device when feedback arrives, statuses change, or comments are posted — using ntfy.sh or your own server.

# ntfy

Push notifications without the platform lock-in. ntfy delivers real-time alerts to your phone, desktop, or any device by publishing to a topic you control — using ntfy.sh or a self-hosted server, no account required.

## Overview

The ntfy integration enables:

- **Real-time alerts** -- get notified the moment feedback is submitted, a status changes, or a comment is posted
- **Any device** -- receive notifications on iOS, Android, or desktop via the ntfy app or the ntfy.sh web interface
- **Your infrastructure** -- use the free ntfy.sh service or a self-hosted ntfy server you control

## Prerequisites

- Admin access to your Quackback workspace
- The [ntfy app](https://ntfy.sh) installed on your device, or ntfy.sh open in a browser

## Setup

### 1. Create or choose a topic

Topics are the delivery channel for ntfy notifications. A topic is identified by a URL:

```
https://ntfy.sh/<your-topic-name>
```

1. Choose a topic name — for example, `quackback-alerts`
2. Open the ntfy app and subscribe to the topic, or visit `https://ntfy.sh/<your-topic-name>` in a browser
3. You don't need to register — subscribing is instant

### 2. Connect in Quackback

1. Go to **Admin → Settings → Integrations → ntfy**
2. Paste the full topic URL (for example, `https://ntfy.sh/quackback-mfx9k2p7`)
3. If your topic requires authentication, paste an access token in the **Access token** field (see [Access token](#access-token) below)
4. Click **Save**

A test notification is sent to the topic immediately so you can confirm delivery before enabling events.

### 3. Configure events

Choose which events trigger a notification:

| Event | Description |
|-------|-------------|
| New post | Someone submits new feedback |
| Status change | Post status is updated |
| New comment | Comment added to a post |

## Access token

If your ntfy topic is protected or your server requires authentication, create a token with **publish** permission and paste it into Quackback.

**For ntfy.sh:**

1. Sign in at [ntfy.sh](https://ntfy.sh)
2. Go to **Account → Access tokens**
3. Click **Add token** and set a description
4. Grant **Publish** permission for the topic
5. Copy the token and paste it into Quackback

**For a self-hosted server**, follow your server's token management docs.

Leave the **Access token** field blank if your topic is open and unrestricted.

## Manage the integration

### Pause

Temporarily stop sending notifications:

1. Go to **Admin → Settings → Integrations → ntfy**
2. Toggle **Enabled** off
3. Notifications pause, but the topic URL and token are preserved

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → ntfy**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Test notification not received

1. **Check the topic URL** -- ensure it is the full URL including `https://` and matches what you subscribed to in the ntfy app
2. **Verify your subscription** -- open the ntfy app or ntfy.sh in a browser and confirm you are subscribed to the exact topic
3. **Check the access token** -- if your topic requires authentication, ensure the token has publish permission and has not expired
4. **Private server** -- if using a self-hosted server, confirm the server is publicly reachable over HTTPS

### Notifications stopped arriving

1. Go to **Admin → Settings → Integrations → ntfy** and check for error messages
2. If an access token is in use, verify it has not expired or been revoked
3. Re-save the integration to send another test notification

## Next Steps

- [Slack](/docs/integrations/slack) - Slack notification integration
- [Discord](/docs/integrations/discord) - Discord notification integration
- [Webhooks](/docs/integrations/webhooks) - Build custom integrations

- [Integrations](https://quackback.io/docs/integrations/overview): Connect Quackback to Slack, webhooks, and other tools.

# Integrations

Don't check another dashboard. Send feedback notifications where your team already works. Get notified about new feedback, status changes, and comments without leaving your workflow.

## Available Integrations

### Notifications

### Issue Tracking

### Support & CRM

### Automation

### Developer Tools

## How Integrations Work

Quackback uses an **event-driven** integration system:

```
Event Occurs → Event Dispatched → Integration Triggered → Notification Sent
```

### Events

Integrations can respond to these events:

| Event | Description |
|-------|-------------|
| `post.created` | New feedback post submitted |
| `post.status_changed` | Post status updated (e.g., Planned → Shipped) |
| `post.updated` | Post title or content edited |
| `post.deleted` | Post soft-deleted |
| `post.restored` | Deleted post restored |
| `post.merged` | Post merged into another post |
| `comment.created` | New comment on a post |
| `comment.updated` | Comment edited |
| `comment.deleted` | Comment deleted |

### Event Mappings

Configure which events trigger which integrations:

1. Go to **Admin → Settings → Integrations**
2. Select an integration
3. Configure **Event Mappings**
4. Choose which events to send

For example, only send to Slack when a post becomes "Planned".

## Set up integrations

### General Flow

1. Navigate to **Admin → Settings → Integrations**
2. Click on the integration you want to set up
3. Follow the connection flow (usually OAuth)
4. Configure notification settings
5. Test the connection
6. Enable the integration

### Permissions Required

## Integration Status

Each integration shows its current status:

| Status | Meaning |
|--------|---------|
| **Connected** | Working normally |
| **Paused** | Temporarily disabled |
| **Error** | Connection issue, needs attention |
| **Not Connected** | Not yet set up |

### Pause integrations

Temporarily disable an integration without disconnecting:

1. Go to the integration settings
2. Toggle **Enabled** off
3. The integration pauses but credentials are preserved

### Reconnect

If an integration shows errors:

1. Check the error message
2. Re-authenticate if tokens expired
3. Verify the connected service is working

## Security

### OAuth Tokens

Integration OAuth tokens are:
- Encrypted at rest using AES-256-GCM with purpose-specific keys derived via HKDF
- Scoped to minimum required permissions
- Revocable from both Quackback and the connected service

### Webhook Signing

Webhook deliveries are signed with HMAC-SHA256 so you can verify they came from Quackback. See [Webhooks](/docs/integrations/webhooks) for details.

## On post delete

When you delete a feedback post that has linked issues in an issue tracker (Linear, GitHub, Jira, etc.), you can archive or close those issues at the same time. The delete dialog shows a checkbox for each linked issue.

### Configure the default

Each integration has an **On post delete** toggle in its settings page. When enabled, the checkbox for that integration's linked issues is pre-checked in the delete dialog. You can always override per-delete.

### What happens

- The post is soft-deleted first -- this always succeeds
- Selected linked issues are archived or closed in parallel
- If an external API call fails, you'll see a warning toast -- the post is still deleted
- The link's status is updated to `archived`, `closed`, or `error` in the database

## Best Practices

### Start Simple

### Map Relevant Events

Don't send every event to every channel. Be selective:
- New feedback > general notification
- Status changes > specific channels
- Comments > maybe skip or use digest

### Monitor for Errors

Regularly check integration status. Failed notifications can mean:
- Expired tokens
- Removed channels
- Service outages

## Troubleshooting

### Notifications Not Sending

1. Check integration status for errors
2. Verify event mappings are configured
3. Check the target channel/endpoint exists
4. Review recent activity logs

### Duplicate Notifications

1. Check for multiple event mappings
2. Verify you don't have duplicate integrations
3. Review webhook retry settings

### Connection Lost

1. Tokens may have expired
2. Re-authenticate the integration
3. Check the third-party service status

## Next Steps

- [Slack](/docs/integrations/slack) - Set up Slack notifications
- [Webhooks](/docs/integrations/webhooks) - Send events to any HTTP endpoint
- [API Overview](/docs/api/introduction) - Full REST API documentation

- [Salesforce](https://quackback.io/docs/integrations/salesforce): Enrich feedback with CRM data and create cases from Salesforce.

# Salesforce

Know who's asking. Automatically match feedback authors to Salesforce contacts and surface account names, opportunity stages, and deal values alongside their requests. Prioritize feedback from your most valuable customers.

## Overview

The Salesforce integration enables:

- **Account enrichment** -- see account name, opportunity stage, and deal value alongside feedback
- **Contact lookup** -- automatically match feedback authors to Salesforce contacts by email address
- **Case creation** -- create Salesforce cases from feedback posts for tracking in your CRM

## Prerequisites

- Admin access to your Quackback workspace
- A Salesforce account with API access
- A Salesforce Connected App (see [Create a Connected App](https://help.salesforce.com/s/articleView?id=sf.connected_app_create.htm))

## Setup

### 1. Create a Salesforce Connected App

1. Go to **Setup > App Manager** in Salesforce
2. Click **New Connected App**
3. Enable OAuth Settings
4. Add these OAuth scopes:
   - `api` -- Access and manage your data
   - `refresh_token` -- Perform requests at any time
5. Set the **Callback URL** to your Quackback OAuth callback URL
6. Save and copy the **Consumer Key** and **Consumer Secret**

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → Salesforce**
2. Enter the following credentials:
   - **Consumer Key** from your Connected App
   - **Consumer Secret** from your Connected App

### 3. Connect Your Account

1. Click **Connect to Salesforce**
2. You'll be redirected to Salesforce to authorize the application
3. Log in and click **Allow**

### 4. Save and Test

1. Click **Save**
2. Submit test feedback with an email address that matches a Salesforce contact
3. The feedback post will be enriched with the contact's account data

## How Enrichment Works

When new feedback is submitted, Quackback:

1. Queries Salesforce for a Contact matching the author's email
2. If found, retrieves the Contact's Account name and details
3. Links the feedback post to the Salesforce contact with a direct link to the Lightning contact view

This helps your team see the revenue impact of feature requests and prioritize feedback from key accounts.

## Manage the Integration

### Pause

Temporarily stop enrichment:

1. Go to **Admin → Settings → Integrations → Salesforce**
2. Toggle **Enabled** off
3. Enrichment pauses, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in Salesforce
3. Tokens are automatically refreshed when they expire

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Salesforce**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Contacts Not Being Matched

1. **Check email addresses** -- the feedback author's email must exactly match a Salesforce Contact's email field
2. **Verify permissions** -- the connected account needs read access to Contacts and Accounts
3. **Check integration status** -- look for errors in settings

### "Authentication Failed" Error

Salesforce OAuth tokens expire and are automatically refreshed. If refresh fails:

1. Click **Reconnect**
2. Re-authorize the app in Salesforce

### Connected App Not Working

1. Verify the Connected App is active (can take up to 10 minutes after creation)
2. Check that the OAuth scopes include `api` and `refresh_token`
3. Confirm the callback URL matches your Quackback instance

## Next Steps

- [HubSpot](/docs/integrations/hubspot) -- HubSpot CRM integration
- [Stripe](/docs/integrations/stripe) -- Stripe revenue integration
- [Integrations Overview](/docs/integrations/overview) -- All integrations

- [Set up Segment](https://quackback.io/docs/integrations/segment): Sync user data and segment membership between Segment and Quackback.

# Set up Segment

Enrich feedback with customer data from your CDP. The Segment integration supports bidirectional sync: receive user attributes from Segment identify events, and push segment membership changes back to Segment for use in downstream tools.

## What you get

| Direction | Description |
|-----------|-------------|
| **Inbound** | Receive Segment `identify` events to sync user attributes (plan, company, role, etc.) into Quackback |
| **Outbound** | Push [segment](/docs/admin/segments) membership changes back to Segment as user traits |

## Prerequisites

- A Segment workspace with a configured source
- A Segment write key (for outbound sync)

## Set up inbound sync

Inbound sync receives `identify` events from Segment and writes user attributes to matching Quackback users.

### Step 1: Create a destination in Segment

**[Segment]**

1. Go to **Connections > Destinations**
2. Add a **Webhook** destination (or use a **Source Function**)
3. Set the webhook URL to:

```
https://YOUR_DOMAIN/api/integrations/segment/webhook
```

### Step 2: Configure the shared secret

**[Dashboard]**

1. Go to **Admin → Settings → Integrations → Segment**
2. Enter a **Shared Secret** - this must match the signing secret configured in Segment
3. Save

Quackback verifies inbound webhooks using HMAC-SHA1 signatures. The `x-signature` header on each request is validated against your shared secret.

### How it works

When Segment sends an `identify` event:

1. Quackback verifies the HMAC-SHA1 signature
2. Extracts the user's email from `traits.email` or `context.traits.email`
3. Matches the email to an existing Quackback user
4. Merges all traits as user attributes

Non-identify events (track, page, etc.) are ignored and return `200 OK`.

## Set up outbound sync

Outbound sync pushes segment membership changes from Quackback back to Segment as user traits.

### Step 1: Get your Segment write key

**[Segment]**

1. Go to **Connections > Sources**
2. Select or create a source for Quackback data
3. Copy the **Write Key**

### Step 2: Configure outbound sync

**[Dashboard]**

1. Go to **Admin → Settings → Integrations → Segment**
2. Enter the **Write Key**
3. Enable **Outbound Sync**
4. Save

### How it works

When a user's segment membership changes in Quackback (e.g. they join or leave a dynamic segment), Quackback sends an `identify` call to Segment's HTTP Tracking API with a boolean trait indicating membership.

For example, if a user joins the "Enterprise" segment, Segment receives:

```json
{
  "type": "identify",
  "userId": "user@example.com",
  "traits": {
    "enterprise": true
  }
}
```

Segment names are converted to snake_case trait keys. Use these traits in Segment to trigger downstream workflows in tools like Braze, Iterable, or Customer.io.

## Troubleshooting

### Inbound events not syncing

1. Verify the shared secret matches between Segment and Quackback
2. Check that Segment is sending `identify` events (not just `track`)
3. Ensure the user's email in Segment traits matches an existing Quackback user

### Outbound sync not working

1. Verify the write key is correct
2. Check that **Outbound Sync** is toggled on
3. Confirm the Segment source is active and receiving data

### "401 Unauthorized" on webhook

The HMAC-SHA1 signature didn't match. Verify your shared secret is identical in both Segment and Quackback.

## Next steps

- [Segments](/docs/admin/segments) - Create user segments in Quackback
- [Integrations Overview](/docs/integrations/overview) - See all available integrations

- [Shortcut](https://quackback.io/docs/integrations/shortcut): Create Shortcut stories from feedback and sync status changes.

# Shortcut

Turn feedback into stories. Automatically create Shortcut stories when feedback is submitted, and keep statuses synchronized between Quackback and Shortcut. When a story's workflow state changes in Shortcut, the linked feedback post updates too.

## Overview

The Shortcut integration enables:

- **Create Shortcut stories from feedback posts** -- automatically create a story when new feedback is submitted
- **Link posts to stories** -- link feedback posts to Shortcut stories for traceability
- **Status sync** -- keep feedback post status and Shortcut story workflow state in sync via inbound webhooks

## Prerequisites

- Admin access to your Quackback workspace
- A Shortcut workspace
- A Shortcut API token (generated at [Shortcut Settings > API Tokens](https://app.shortcut.com/settings/account/api-tokens))

## Setup

### 1. Generate a Shortcut API Token

1. Go to [Shortcut Settings > API Tokens](https://app.shortcut.com/settings/account/api-tokens)
2. Generate a new API token
3. Copy the token

### 2. Connect Your Workspace

1. Go to **Admin → Settings → Integrations → Shortcut**
2. Enter your **API Token**
3. Click **Save**

Quackback validates the token by checking it against the Shortcut API and automatically detects your workspace name.

### 3. Select a Project

Back in Quackback:

1. Choose the Shortcut project where stories should be created
2. Stories will be created in this project when new feedback is submitted

### 4. Configure Status Mappings

Map Shortcut workflow states to Quackback statuses:

1. Go to the Shortcut integration settings
2. Configure status mappings between Shortcut workflow state names and Quackback statuses
3. Each Shortcut workflow state can be mapped to a corresponding Quackback status, or set to ignore

Shortcut uses workflow state IDs internally. Quackback resolves the ID to a state name from the webhook payload itself before looking up your mapping, so renaming or adding workflow states in Shortcut doesn't break the sync.

### 5. Set Up the Inbound Webhook

Status sync needs a webhook in Shortcut so story changes reach Quackback:

1. In Quackback, enable **Status sync** in the Shortcut integration settings
2. Copy the **Webhook URL** and **Signing secret** shown below the toggle
3. In Shortcut, go to **Settings → Integrations → Webhooks** and add a new outgoing webhook
4. Paste the webhook URL as the payload URL and the signing secret as the secret

Quackback verifies each delivery against the signing secret and rejects requests that don't match.

### 6. Configure Events

Choose which events trigger Shortcut actions:

| Event | Action |
|-------|--------|
| New post | Create a Shortcut story with the feedback details |

### 7. Save and Test

1. Click **Save**
2. Submit test feedback to verify a story is created in Shortcut

## Story Format

When a new feedback post triggers story creation, the Shortcut story includes:

- **Name**: The feedback post title (truncated to 512 characters if needed)
- **Description** (Markdown): The post content, followed by metadata including the author, board, vote count, and a link back to the post in Quackback
- **Story type**: Feature
- **Project**: The selected Shortcut project

## Status Sync

When status sync is configured, Quackback receives webhook events from Shortcut. When a linked story's workflow state changes:

1. Shortcut sends a webhook event to Quackback
2. Quackback looks for story update actions with `workflow_state_id` changes
3. The new workflow state ID is resolved to a state name using the workflow-state references included in the payload
4. If a status mapping exists for that state name, the linked feedback post's status is updated

The webhook signature is verified using HMAC-SHA256 via the `Payload-Signature` header, using the signing secret from your integration settings.

## On post delete

When you delete a feedback post with a linked Shortcut story, you can archive the story at the same time. The delete dialog shows a checkbox for each linked story.

To pre-check this by default, enable the **On post delete** toggle in the Shortcut integration settings. You can always override the default per-delete.

## Manage the integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → Shortcut**
2. Toggle **Enabled** off
3. Story creation and status sync pause, but the connection remains

### Reconnect

If you see connection errors:

1. Generate a new API token in Shortcut
2. Update the token in **Admin → Settings → Integrations → Shortcut**

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Shortcut**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Stories Not Being Created

1. **Check integration status** -- look for errors in settings
2. **Verify project selection** -- ensure a Shortcut project is selected
3. **Check event mappings** -- confirm `post.created` is mapped
4. **Validate API token** -- ensure the token has not been revoked in Shortcut

### Status Sync Not Working

1. **Check status mappings** -- ensure Shortcut workflow states are mapped to Quackback statuses
2. **Check the webhook** -- confirm the webhook exists in Shortcut and its payload URL matches the webhook URL in your integration settings
3. **Check the secret** -- the secret in Shortcut must match the signing secret shown in Quackback; deliveries with a wrong or missing signature are rejected

### "Authentication Failed" Error

Shortcut API tokens do not expire automatically but can be revoked. If you see this error:

1. Verify the token is still valid in Shortcut settings
2. Generate a new token if needed
3. Update the token in Quackback

## Next Steps

- [Linear](/docs/integrations/linear) - Linear issue sync integration
- [Webhooks](/docs/integrations/webhooks) - Build custom integrations
- [Integrations Overview](/docs/integrations/overview) - All integrations

- [Slack](https://quackback.io/docs/integrations/slack): Send feedback from Slack and get alerts when it arrives.

# Slack

Feedback where you work. Send messages to Quackback directly from Slack, monitor channels for feedback automatically, and get notified when new feedback arrives, statuses change, or users comment.

## Overview

The Slack integration works in both directions:

**Slack to Quackback:**
- Send any message to Quackback with the "Send to Quackback" shortcut
- Automatically ingest feedback from monitored channels

**Quackback to Slack:**
- New feedback notifications
- Post status change alerts
- New comment notifications

## Prerequisites

- Admin access to your Quackback workspace
- Permission to install apps in your Slack workspace

## Setup

### 1. Start the Connection

1. Go to **Admin → Settings → Integrations**
2. Click **Slack**
3. Click **Connect to Slack**

### 2. Authorize the App

You'll be redirected to Slack:

1. Select your Slack workspace
2. Review the permissions requested
3. Click **Allow**

### 3. Select a Channel

Back in Quackback:

1. Choose a default channel for notifications
2. Select from public channels or private channels the app was added to

### 4. Configure Events

Choose which events trigger Slack notifications:

| Event | Description |
|-------|-------------|
| New post | Someone submits new feedback |
| Status change | Post status is updated |
| New comment | Comment added to a post |

### 5. Save and Test

1. Click **Save**
2. Click **Send Test** to verify the connection
3. Check your Slack channel for the test message

## Send feedback from Slack

### "Send to Quackback" shortcut

Turn any Slack message into feedback without leaving the conversation. The message shortcut lets team members or users forward messages directly into your Quackback workspace.

**How to use it:**

1. Hover over any message in Slack
2. Click the **More actions** menu (three dots)
3. Select **Send to Quackback**
4. A modal opens with the message content pre-filled
5. Optionally add context or select a board
6. Click **Submit**

The message is sent to your Quackback feedback pipeline. AI processes it, suggests a title, detects duplicates, and creates a triage suggestion in your [AI suggestions inbox](/docs/admin/suggestions).

### Channel monitoring

Automatically collect feedback from entire Slack channels. When enabled, Quackback monitors selected channels and ingests new messages as raw feedback for AI processing.

**Set up channel monitoring:**

1. Go to **Admin → Settings → Integrations → Slack**
2. Scroll to **Channel Monitoring**
3. Click **Add Channel**
4. Select the channel to monitor
5. Save

Messages posted in monitored channels are automatically sent through the feedback pipeline. AI extracts themes, detects duplicates against existing posts, and creates triage suggestions.

## Notification Format

Slack notifications use Block Kit formatting for rich messages.

**New post:**
```
📬 New feedback from jane@example.com

> "Add dark mode support"
> It would be great to have a dark mode...

in feature-requests
```

**Status change:**
```
🔄 Status changed by admin@example.com

> "Add dark mode support"
> Under Review → Planned
```

**New comment:**
```
💬 New comment from jane@example.com

> "Add dark mode support"
> Great idea! We're considering this for Q2.
```

All notifications include clickable links to the post.

## Event Mapping

Send different events to different channels:

1. Go to the Slack integration settings
2. Click **Add Event Mapping**
3. Configure:
   - **Event type**: post.created, post.status_changed, etc.
   - **Channel**: Target Slack channel
   - **Filters** (optional): Board, status, or other conditions

### Example Configurations

**All new feedback to #product-feedback:**
- Event: post.created
- Channel: #product-feedback

**Only "Shipped" items to #shipped:**
- Event: post.status_changed
- Channel: #shipped
- Filter: Status = "Shipped"

**Bug reports to #bugs:**
- Event: post.created
- Channel: #bugs
- Filter: Board = "Bug Reports"

## Private Channels

To post to private channels:

1. In Slack, open the private channel
2. Type `/invite @Quackback` or use channel settings
3. The channel now appears in Quackback's channel selector

## Manage the integration

### Pause Notifications

Temporarily stop notifications:

1. Go to **Admin → Settings → Integrations → Slack**
2. Toggle **Enabled** off
3. Notifications pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in Slack
3. Reconfigure channels if needed

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Slack**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Notifications Not Appearing

1. **Check integration status** - Look for errors in settings
2. **Verify channel** - Ensure the channel still exists
3. **Check event mappings** - Confirm events are configured
4. **App permissions** - Verify the app is in the channel

### "Channel Not Found" Error

The channel may have been:
- Deleted
- Made private (app needs re-invitation)
- Renamed (select it again in settings)

### "Token Expired" Error

1. Click **Reconnect**
2. Re-authorize the app in Slack
3. Test the connection

### Duplicate Notifications

Check for:
- Multiple event mappings for the same event
- Multiple Slack integrations connected

## Permissions

The Slack app requests:

| Permission | Purpose |
|------------|---------|
| `channels:read` | List public channels |
| `channels:history` | Read messages in monitored public channels |
| `groups:read` | List private channels (when invited) |
| `groups:history` | Read messages in monitored private channels |
| `channels:join` | Auto-join public channels for posting |
| `chat:write` | Post notifications |
| `chat:write.public` | Post to public channels without joining |
| `commands` | Register the "Send to Quackback" shortcut |
| `team:read` | Get workspace info |
| `users:read` | Resolve Slack user profiles for feedback attribution |

## Best Practices

### Dedicated Channel

### Smart Filtering

Don't send everything to one channel. Instead:
- Route by board (bugs vs features)
- Filter by status (only shipped items)
- Use separate channels for high-priority items

### React to Notifications

Use Slack's reaction emojis:
- 👀 to indicate you've seen it
- ✅ when handled
- 📌 for important items

### Link to Posts

Slack notifications include links back to Quackback. Click through to:
- Add comments
- Change status
- See full context

## Next Steps

- [Triage AI suggestions](/docs/admin/suggestions) - Review feedback sent from Slack
- [Webhooks](/docs/integrations/webhooks) - Build custom integrations
- [Event Mappings](/docs/integrations/overview#event-mappings) - Advanced configuration
- [Admin Guide](/docs/admin/inbox) - Managing feedback

- [Stripe](https://quackback.io/docs/integrations/stripe): Enrich feedback with customer revenue and subscription data.

# Stripe

Prioritize by revenue. Automatically match feedback authors to Stripe customers and see MRR, plan tier, and subscription status alongside their requests. Know which feature requests come from your highest-value customers.

## Overview

The Stripe integration enables:

- **Revenue enrichment** -- see MRR, plan tier, and billing status alongside feedback to prioritize high-value customers
- **Customer lookup** -- automatically match feedback authors to Stripe customers by email address
- **Subscription context** -- view subscription status, plan name, and lifetime value for each feedback author

## Prerequisites

- Admin access to your Quackback workspace
- A Stripe account
- A Stripe API key with read access to customers

## Setup

### 1. Get Your Stripe API Key

1. Go to the [Stripe Dashboard > API Keys](https://dashboard.stripe.com/apikeys)
2. Copy your **Secret key** (starts with `sk_live_` or `sk_test_`)

### 2. Connect to Stripe

1. Go to **Admin → Settings → Integrations → Stripe**
2. Click **Connect to Stripe**
3. Enter your **Stripe API key**
4. Click **Connect**

### 3. Save and Test

1. Click **Save**
2. Submit test feedback with an email address that matches a Stripe customer
3. The feedback post will be enriched with the customer's revenue data

## How Enrichment Works

When new feedback is submitted, Quackback:

1. Searches Stripe for a customer matching the author's email
2. If found, retrieves subscription and revenue data
3. Links the feedback post to the Stripe customer with a direct link to their dashboard profile

This helps your team prioritize feature requests from paying customers and understand the revenue impact of feedback.

## Manage the Integration

### Pause

Temporarily stop enrichment:

1. Go to **Admin → Settings → Integrations → Stripe**
2. Toggle **Enabled** off
3. Enrichment pauses, but the connection remains

### Reconnect

If you see connection errors:

1. Verify your API key is still valid in the Stripe Dashboard
2. Update the key in Quackback if needed

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Stripe**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Customers Not Being Matched

1. **Check email addresses** -- the feedback author's email must match a Stripe customer's email
2. **Verify API key** -- ensure the key has permission to read customers
3. **Check integration status** -- look for errors in settings

### "Authentication Failed" Error

Your API key may have been revoked or rotated:

1. Get a new API key from the Stripe Dashboard
2. Update the key in Quackback's integration settings

### Test vs. Live Mode

Stripe test keys (`sk_test_`) only match test customers. Use a live key (`sk_live_`) to match real customers.

## Next Steps

- [Salesforce](/docs/integrations/salesforce) -- Salesforce CRM integration
- [HubSpot](/docs/integrations/hubspot) -- HubSpot CRM integration
- [Integrations Overview](/docs/integrations/overview) -- All integrations

- [Trello](https://quackback.io/docs/integrations/trello): Create cards in Trello from feedback and sync statuses.

# Trello

Feedback on your board. Automatically create Trello cards when feedback is submitted, and keep statuses synchronized -- when cards move between lists in Trello, the linked feedback post updates too.

## Overview

The Trello integration enables:

- **Create cards from feedback** -- automatically create a Trello card when new feedback is submitted
- **Two-way status sync** -- moving cards between lists in Trello updates the feedback status in Quackback
- **Rich descriptions** -- cards include feedback details, author info, and direct links back to your portal

## Prerequisites

- Admin access to your Quackback workspace
- A Trello account
- A Trello Power-Up (created at [Trello Power-Ups Admin](https://trello.com/power-ups/admin))

## Setup

### 1. Create a Trello Power-Up

1. Go to the [Trello Power-Ups Admin](https://trello.com/power-ups/admin)
2. Create a new Power-Up
3. Copy the **API Key** and **API Secret**

### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → Trello**
2. Enter the following credentials:
   - **API Key** from your Trello Power-Up
   - **API Secret** from your Trello Power-Up

### 3. Connect Your Account

1. Click **Connect to Trello**
2. You'll be redirected to Trello to authorize the application
3. The app requests `read` and `write` permissions with no expiration
4. Click **Allow**

### 4. Select a Board and List

Back in Quackback:

1. Choose the Trello board where cards should be created
2. Select the list within the board (e.g., "Incoming" or "To Do")
3. New cards appear at the top of the selected list

### 5. Configure Status Mappings

Map Trello lists to Quackback statuses. When a card moves to a different list, the linked feedback post's status updates to match.

### 6. Save and Test

1. Click **Save**
2. Submit test feedback to verify a card is created in Trello

## Card Format

When feedback triggers card creation, the Trello card includes:

- **Name**: The feedback post title
- **Description**: The post content, author details, board name, vote count, and a link back to the post in Quackback

Cards are created at the top of the selected list.

## Status Sync

Quackback registers a webhook with Trello to receive card updates. When a linked card moves between lists:

1. Trello sends a webhook to Quackback
2. The webhook signature is verified using HMAC-SHA1
3. The destination list name is mapped to a Quackback status
4. The linked feedback post's status is updated

## On post delete

When you delete a feedback post with a linked Trello card, you can archive the card at the same time. The delete dialog shows a checkbox for each linked card.

To pre-check this by default, enable the **On post delete** toggle in the Trello integration settings. You can always override the default per-delete.

## Manage the Integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → Trello**
2. Toggle **Enabled** off
3. Card creation and status sync pause, but the connection remains

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-authorize in Trello

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Trello**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Cards Not Being Created

1. **Check integration status** -- look for errors in settings
2. **Verify board and list selection** -- ensure both are selected
3. **Check permissions** -- the connected account needs write access to the board

### Status Sync Not Working

1. **Check status mappings** -- ensure Trello lists are mapped to Quackback statuses
2. **Verify webhook** -- the Trello webhook may need to be re-registered
3. **Check board access** -- the connected account needs access to the board

### "Authentication Failed" Error

1. Click **Reconnect**
2. Re-authorize the app in Trello

## Next Steps

- [Asana](/docs/integrations/asana) -- Asana task integration
- [Webhooks](/docs/integrations/webhooks) -- Build custom integrations
- [Integrations Overview](/docs/integrations/overview) -- All integrations

- [Webhooks](https://quackback.io/docs/integrations/webhooks): Send real-time event notifications to any HTTP endpoint.

# Webhooks

Build any integration you need. Webhooks send real-time HTTP notifications to any endpoint when events occur in Quackback. Connect to Zapier, your data warehouse, custom bots, or internal tools.

## Overview

Webhooks are managed entirely through the [REST API](/docs/api/introduction). Each webhook specifies:

- A **URL** to receive POST requests
- Which **events** to listen for
- Optional **board filtering** to scope events to specific boards
- A **signing secret** for verifying authenticity (HMAC-SHA256)

## Create a webhook

**[Your App]** Create a webhook via the API:

```bash
curl -X POST https://feedback.example.com/api/v1/webhooks \
  -H "Authorization: Bearer qb_your_admin_key" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-server.com/webhook",
    "events": ["post.created", "post.status_changed"],
    "boardIds": ["board_01h455vb4pex5vsknk084sn02q"]
  }'
```

The response includes the signing secret, which is only shown once:

```json
{
  "data": {
    "id": "webhook_01h455vb4pex5vsknk084sn02q",
    "url": "https://your-server.com/webhook",
    "secret": "whsec_...",
    "events": ["post.created", "post.status_changed"],
    "boardIds": ["board_01h455vb4pex5vsknk084sn02q"],
    "status": "active",
    "createdAt": "2025-01-15T10:30:00.000Z"
  }
}
```

## Event Types

| Event | Description |
|-------|-------------|
| `post.created` | New feedback post submitted |
| `post.status_changed` | Post status updated |
| `comment.created` | New comment added to a post |
| `conversation.created` | A visitor starts a new conversation |
| `conversation.status_changed` | A conversation moves between open, pending, and closed |
| `conversation.assigned` | A conversation is assigned to or unassigned from an agent (includes auto-routing) |
| `conversation.priority_changed` | A conversation's priority changes |
| `conversation.csat_submitted` | A visitor submits a satisfaction rating |
| `message.created` | A visitor or agent sends a public message |
| `message.note_created` | An agent adds an internal note (private — subscribe only if your endpoint should receive it) |
| `message.deleted` | A public message is deleted |

## Request Headers

Each webhook delivery includes these headers:

| Header | Description |
|--------|-------------|
| `Content-Type` | `application/json` |
| `User-Agent` | `Quackback-Webhook/1.0` |
| `X-Quackback-Event` | Event type (e.g., `post.created`) |
| `X-Quackback-Signature` | HMAC-SHA256 signature for verification |
| `X-Quackback-Timestamp` | Unix timestamp of the request |

## Payload Format

Every webhook delivery sends a JSON body with this structure:

```json
{
  "id": "evt_a1b2c3d4e5f6...",
  "type": "post.created",
  "createdAt": "2025-01-15T10:30:00.000Z",
  "data": {
    "post": {
      "id": "post_01h455vb4pex5vsknk084sn02q",
      "title": "Add dark mode support",
      "content": "It would be great to have a dark mode...",
      "boardId": "board_01h455vb4pex5vsknk084sn02q",
      "boardSlug": "feature-requests",
      "authorEmail": "jane@example.com",
      "voteCount": 12
    }
  }
}
```

| Field | Description |
|-------|-------------|
| `id` | Unique event ID (prefixed with `evt_`) |
| `type` | Event type (e.g., `post.created`) |
| `createdAt` | ISO 8601 timestamp of when the event occurred |
| `data` | Event-specific payload (varies by event type) |

## Signature Verification

**[Your Server]** Every webhook delivery is signed with HMAC-SHA256. Always verify the signature to confirm the request came from Quackback.

The signature is computed over `\{timestamp\}.\{json_body\}`:

```javascript

function verifyWebhook(payload, signature, timestamp, secret) {
  const signaturePayload = `${timestamp}.${payload}`;
  const expected = crypto
    .createHmac('sha256', secret)
    .update(signaturePayload)
    .digest('hex');

  return `sha256=${expected}` === signature;
}

// In your handler
app.post('/webhook', (req, res) => {
  const signature = req.headers['x-quackback-signature'];
  const timestamp = req.headers['x-quackback-timestamp'];
  const payload = JSON.stringify(req.body);

  if (!verifyWebhook(payload, signature, timestamp, WEBHOOK_SECRET)) {
    return res.status(401).send('Invalid signature');
  }

  // Process the event
  console.log('Event:', req.body.type);
  res.status(200).send('OK');
});
```

## Board Filtering

Pass `boardIds` when creating a webhook to only receive events from specific boards. If omitted, the webhook receives events from all boards.

```bash
# Only events from a specific board
curl -X POST https://feedback.example.com/api/v1/webhooks \
  -H "Authorization: Bearer qb_your_admin_key" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-server.com/webhook",
    "events": ["post.created"],
    "boardIds": ["board_01h455vb4pex5vsknk084sn02q"]
  }'
```

## Manage webhooks

### List webhooks

```bash
curl https://feedback.example.com/api/v1/webhooks \
  -H "Authorization: Bearer qb_your_admin_key"
```

### Update a webhook

```bash
curl -X PATCH https://feedback.example.com/api/v1/webhooks/webhook_01h4... \
  -H "Authorization: Bearer qb_your_admin_key" \
  -H "Content-Type: application/json" \
  -d '{ "events": ["post.created", "comment.created"] }'
```

### Rotate the signing secret

If a secret is compromised, rotate it:

```bash
curl -X POST https://feedback.example.com/api/v1/webhooks/webhook_01h4.../rotate \
  -H "Authorization: Bearer qb_your_admin_key"
```

The response contains the new secret. Update your server immediately.

### Delete a webhook

```bash
curl -X DELETE https://feedback.example.com/api/v1/webhooks/webhook_01h4... \
  -H "Authorization: Bearer qb_your_admin_key"
```

## Use Cases

### Custom Slack Bot

Build a Slack bot with more control than the built-in integration:

```javascript
app.post('/webhook', async (req, res) => {
  const { type, data } = req.body;

  if (type === 'post.created') {
    await slack.chat.postMessage({
      channel: '#feedback',
      text: `New feedback: ${data.post.title}`,
    });
  }

  res.sendStatus(200);
});
```

### Zapier / n8n Integration

1. **[Zapier / n8n]** Create a Zap or n8n workflow with a webhook trigger
2. Copy the webhook URL
3. **[Your App]** Create a Quackback webhook pointing to that URL
4. **[Zapier / n8n]** Map fields in your automation tool

### Data Warehouse Sync

Log events to your analytics platform:

```javascript
app.post('/webhook', async (req, res) => {
  const { type, createdAt, data } = req.body;

  await db.insert('feedback_events', {
    event_type: type,
    event_time: createdAt,
    post_id: data.post?.id,
    raw_payload: JSON.stringify(data),
  });

  res.sendStatus(200);
});
```

## Retry Behavior

Failed webhook deliveries are retried automatically:

- **Attempts**: Up to 3 delivery attempts per event
- **Backoff**: Exponential backoff starting at 1 second
- **Retryable errors**: Server errors (5xx), rate limits (429), and network timeouts
- **Non-retryable errors**: Client errors (4xx except 429) are not retried
- **Timeout**: Each delivery attempt has a 5-second timeout
- **Auto-disable**: After 50 consecutive permanent failures, the webhook is automatically disabled. The failure counter resets on each successful delivery.

## Security Best Practices

1. **Always verify signatures** - reject unverified requests
2. **Use HTTPS** - never use HTTP endpoints for webhook receivers
3. **Check timestamps** - reject requests older than 5 minutes
4. **Rotate secrets periodically** - use the rotate endpoint
5. **Respond quickly** - return a `200` status within a few seconds; process asynchronously if needed

## Next Steps

- [API Overview](/docs/api/introduction) - Full REST API documentation
- [Integrations Overview](/docs/integrations/overview) - All available integrations
- [Slack](/docs/integrations/slack) - Built-in Slack notification integration

- [Zapier](https://quackback.io/docs/integrations/zapier): Connect Quackback to 6,000+ apps with Zapier automations.

# Zapier

Automate your feedback workflow. Connect Quackback to 6,000+ apps through Zapier, triggering Zaps when new feedback arrives, statuses change, or users comment. Push feedback data to spreadsheets, CRMs, project management tools, and more.

## Overview

The Zapier integration triggers webhooks when:
- New feedback is submitted
- Post status changes
- New comments are posted

Unlike other integrations, Zapier uses webhook URLs instead of OAuth. You create a Zap in Zapier, copy the webhook URL, and paste it into Quackback.

## Prerequisites

- Admin access to your Quackback workspace
- A [Zapier](https://zapier.com) account (free or paid)

## Setup

### 1. Create a Zap in Zapier

1. Log in to [Zapier](https://zapier.com)
2. Click **Create Zap**
3. For the trigger, choose **Webhooks by Zapier**
4. Select **Catch Hook** as the trigger event
5. Zapier provides a webhook URL (starting with `https://hooks.zapier.com/...`)
6. Copy this URL

### 2. Connect in Quackback

1. Go to **Admin → Settings → Integrations → Zapier**
2. Paste the webhook URL from Zapier
3. Click **Save**

Quackback sends a test ping to the webhook URL to verify it is reachable. If the test fails, check that the URL is correct and that the Zap is active.

### 3. Configure Your Zap

Back in Zapier:

1. Click **Test trigger** to receive the test event from Quackback
2. Add an action step (e.g., create a Google Sheets row, send an email, create a Jira ticket)
3. Map the fields from the Quackback payload to your action
4. Turn on the Zap

## Webhook Payload

Quackback sends a structured JSON payload to the Zapier webhook. The payload format depends on the event type.

**All payloads include:**

| Field | Description |
|-------|-------------|
| `event` | Event type (`post.created`, `post.status_changed`, `comment.created`) |
| `timestamp` | ISO 8601 timestamp |
| `portal_url` | Your Quackback portal URL |
| `post` | Post details (always present) |

### post.created

```json
{
  "event": "post.created",
  "timestamp": "2025-01-15T10:30:00Z",
  "portal_url": "https://feedback.example.com",
  "post": {
    "id": "post_abc123",
    "title": "Add dark mode support",
    "content": "It would be great to have a dark mode...",
    "board": "feature-requests",
    "url": "https://feedback.example.com/b/feature-requests/posts/post_abc123",
    "author_name": "Jane Smith",
    "author_email": "jane@example.com",
    "vote_count": 1
  }
}
```

### post.status\_changed

```json
{
  "event": "post.status_changed",
  "timestamp": "2025-01-15T10:30:00Z",
  "portal_url": "https://feedback.example.com",
  "post": {
    "id": "post_abc123",
    "title": "Add dark mode support",
    "board": "feature-requests",
    "url": "https://feedback.example.com/b/feature-requests/posts/post_abc123"
  },
  "status_change": {
    "previous": "Under Review",
    "new": "Planned"
  }
}
```

### comment.created

```json
{
  "event": "comment.created",
  "timestamp": "2025-01-15T10:30:00Z",
  "portal_url": "https://feedback.example.com",
  "post": {
    "id": "post_abc123",
    "title": "Add dark mode support",
    "board": "feature-requests",
    "url": "https://feedback.example.com/b/feature-requests/posts/post_abc123"
  },
  "comment": {
    "id": "comment_xyz789",
    "content": "Great idea! We are considering this for Q2.",
    "author_name": "Admin",
    "author_email": "admin@example.com"
  }
}
```

## Example Zaps

### New feedback to Google Sheets

1. **Trigger**: Webhooks by Zapier > Catch Hook
2. **Action**: Google Sheets > Create Spreadsheet Row
3. Map: title, content, author\_email, board, url

### Status change to Slack message

1. **Trigger**: Webhooks by Zapier > Catch Hook
2. **Filter**: Only continue if `event` equals `post.status_changed`
3. **Action**: Slack > Send Channel Message

### New post to Jira issue

1. **Trigger**: Webhooks by Zapier > Catch Hook
2. **Filter**: Only continue if `event` equals `post.created`
3. **Action**: Jira > Create Issue
4. Map: title to Summary, content to Description

## Manage the integration

### Update Webhook URL

If you need to point to a different Zap:

1. Go to **Admin → Settings → Integrations → Zapier**
2. Enter the new webhook URL
3. Click **Save**

### Disconnect

To remove the Zapier integration:

1. Go to **Admin → Settings → Integrations → Zapier**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Zap Not Triggering

1. **Check Zap status** -- ensure the Zap is turned on in Zapier
2. **Verify webhook URL** -- confirm the URL starts with `https://hooks.zapier.com/`
3. **Check integration status** -- look for errors in Quackback settings
4. **Test the connection** -- resave the webhook URL to send a new test ping

### "Zap is No Longer Active" Error

The Zap may have been paused or deleted in Zapier:

1. Log in to Zapier and check the Zap status
2. Re-enable the Zap or create a new one
3. Update the webhook URL in Quackback if needed

### Webhook Delivery Failures

If webhook deliveries fail with 5xx errors or timeouts, Quackback automatically retries the delivery. If failures persist, check the Zap's webhook configuration in Zapier.

## Security

Quackback only sends webhooks to `hooks.zapier.com` URLs. Webhook URLs pointing to any other domain are rejected to prevent data exfiltration.

## Next Steps

- [Webhooks](/docs/integrations/webhooks) - Build custom integrations with generic webhooks
- [Slack](/docs/integrations/slack) - Direct Slack notification integration
- [Integrations Overview](/docs/integrations/overview) - All integrations

- [Zendesk](https://quackback.io/docs/integrations/zendesk): Link Zendesk tickets to feedback posts and surface customer context.

# Zendesk

Connect support data to product decisions. The Zendesk integration lets your support agents capture feedback directly from tickets and enriches feedback posts with customer context -- so you can see who is asking for what and why.

## Overview

The Zendesk integration provides:

- **Capture feedback** -- turn Zendesk tickets into feedback posts directly from the agent interface using the sidebar app
- **Link tickets to posts** -- connect Zendesk tickets to existing feedback posts so you can track how many support conversations relate to a feature request
- **AI suggestions** -- automatically surface relevant existing posts based on the ticket subject
- **Customer context** -- enrich feedback with Zendesk user data like organization, tags, and role
- **Vote on behalf** -- let agents upvote posts on behalf of the ticket requester when creating or linking

## Prerequisites

- Admin access to your Quackback workspace
- A Zendesk account with admin access
- A Zendesk OAuth application (created in [Zendesk Admin Center](https://developer.zendesk.com/))
- Your Zendesk subdomain (the `your-company` part of `your-company.zendesk.com`)
- A Quackback API key (for the sidebar app)

## Setup

There are two parts to setting up the Zendesk integration: connecting your Zendesk account via OAuth, and installing the sidebar app for your support agents.

### Part 1: Connect Zendesk to Quackback

#### 1. Create a Zendesk OAuth Application

1. Go to [Zendesk Admin Center > Apps and Integrations > APIs > OAuth Clients](https://developer.zendesk.com/)
2. Create a new OAuth client
3. Copy the **Client ID** and **Client Secret**
4. Add your Quackback OAuth callback URL as a redirect URI:
   ```
   https://your-quackback-instance.com/oauth/zendesk/callback
   ```

#### 2. Configure Platform Credentials

1. Go to **Admin → Settings → Integrations → Zendesk** in Quackback
2. Click **Configure credentials**
3. Enter the following:
   - **Client ID** from your Zendesk OAuth client
   - **Client Secret** from your Zendesk OAuth client

#### 3. Enter Your Subdomain

You'll be prompted to enter your **Zendesk subdomain**. This is the subdomain part of your Zendesk URL:

```
https://your-company.zendesk.com
         ^^^^^^^^^^^^
         This is your subdomain
```

The subdomain must be lowercase alphanumeric characters and hyphens only (e.g., `acme-corp`).

#### 4. Connect Your Account

1. Click **Connect to Zendesk**
2. You'll be redirected to your Zendesk instance to authorize the application
3. Review the permissions and click **Allow**

The app requests these OAuth scopes:

| Scope | Purpose |
|-------|---------|
| `read` | Search users and read organization data |
| `write` | Required for full API access |

#### 5. Verify the Connection

Once connected, Quackback stores your Zendesk subdomain and account name. Verify the integration shows as active in the settings.

### Part 2: Install the Sidebar App

The sidebar app lets your Zendesk agents search, link, and create feedback posts without leaving the ticket view.

#### 1. Generate an API Key

1. Go to **Admin → Settings → Developers** in Quackback
2. Create a new API key
3. Copy the key immediately -- it starts with `qb_` and is only shown once

#### 2. Download the Zendesk App

Download the Quackback Zendesk app package from your Quackback instance. The app is a private Zendesk app that embeds a sidebar in the ticket view.

#### 3. Upload the App to Zendesk

1. Go to **Zendesk Admin Center > Apps and Integrations > Apps > Zendesk Support Apps**
2. Click **Upload private app**
3. Upload the Quackback app package
4. Configure the app settings:
   - **Quackback URL** -- your Quackback instance URL (e.g., `https://feedback.yourcompany.com`)
   - **API Key** -- the API key you generated in step 1 (starts with `qb_`)
5. Click **Install**

#### 4. Enable the App

Once installed, the Quackback sidebar appears in the ticket view for all agents. You can restrict access to specific agent groups in the Zendesk app settings if needed.

## How It Works

### Sidebar App

When an agent opens a ticket in Zendesk, the Quackback sidebar loads automatically and shows:

#### Suggested Matches

The sidebar uses the ticket subject to find relevant existing posts using AI-powered similarity matching. Up to 5 suggestions are shown, ranked by relevance. Agents can link a suggestion to the current ticket with one click.

#### Linked Posts

Any posts already linked to the current ticket are shown at the top of the sidebar. Each linked post shows its title, board, and vote count. Agents can unlink a post if it was linked by mistake.

#### Search

Agents can search for posts by typing in the search bar. Results update as you type (with a 300ms debounce). If no results match, agents can create a new post directly from the search query.

#### Create New Post

Agents can create a new feedback post directly from the sidebar:

1. Click **+ Create new post** (or use the search-to-create flow)
2. Select a **board** from the dropdown (lists all public boards)
3. Enter a **title** (required, max 200 characters)
4. Add an optional **description** (max 10,000 characters)
5. **Link to ticket** -- checked by default, links the new post to the current Zendesk ticket
6. **Vote on behalf of requester** -- checked by default, casts an upvote attributed to the ticket requester's email

### Customer Context

When you view a feedback post in Quackback, the integration can look up the author's email in Zendesk and display:

- **Name** -- the user's full name
- **Email** -- the user's email address
- **Role** -- the user's Zendesk role (end-user, agent, admin)
- **Organization** -- the associated organization name and ID
- **Tags** -- all tags applied to the user in Zendesk

### Organization Enrichment

When a Zendesk user has an associated organization, Quackback automatically fetches the organization details. This lets you see which company a requester belongs to, even if the feedback was submitted with a personal email.

### Ticket Linking

Linking a Zendesk ticket to a feedback post creates a bidirectional reference:

- In Quackback, the post shows how many support tickets are linked to it
- Linked tickets are tracked by integration type and external ID, so the same ticket cannot be linked to the same post twice

### No Token Expiration

Zendesk OAuth tokens do not expire. Once connected, the integration stays active without requiring token refreshes.

## Manage the Integration

### Pause

Temporarily stop the integration:

1. Go to **Admin → Settings → Integrations → Zendesk**
2. Toggle **Enabled** off
3. User lookups pause, but the connection remains
4. The sidebar app continues to work independently (it uses its own API key)

### Reconnect

If you see connection errors:

1. Click **Reconnect**
2. Re-enter your subdomain if prompted
3. Re-authorize in Zendesk

### Disconnect

To fully remove the integration:

1. Go to **Admin → Settings → Integrations → Zendesk**
2. Click **Disconnect**
3. Confirm the action

## Troubleshooting

### Sidebar App Not Loading

1. **Check the Quackback URL** -- verify the URL in the Zendesk app settings matches your Quackback instance (no trailing slash)
2. **Check the API key** -- ensure the API key starts with `qb_` and has not been revoked
3. **Check browser console** -- look for CORS or network errors in the browser developer tools
4. **Verify the app is installed** -- confirm the Quackback app appears in Zendesk Admin Center

### No Suggestions Showing

1. **Check the ticket subject** -- suggestions are based on the ticket subject line. Very short or generic subjects may not produce matches
2. **Verify posts exist** -- the workspace needs existing feedback posts for suggestions to work
3. **Check the API key permissions** -- the API key must belong to an admin account

### User Not Found

1. **Check the email** -- the lookup matches by searching for the email address
2. **Verify the user exists** -- confirm the user is in your Zendesk instance
3. **Check permissions** -- the connected Zendesk account must have access to search users

### Organization Data Missing

1. **Check user association** -- the user must be associated with an organization in Zendesk
2. **Verify organization exists** -- confirm the organization has not been deleted

### "Subdomain Not Configured" Error

The Zendesk subdomain is stored during the initial connection. If it is missing:

1. Disconnect the integration
2. Reconnect and enter your subdomain when prompted

### "Authentication Failed" Error

1. Verify your Client ID and Client Secret are correct
2. Click **Reconnect** and re-authorize the app
3. Check that the OAuth client has not been revoked in Zendesk Admin Center

### "Quackback URL Not Configured" in Sidebar

This means the Zendesk app settings are missing the Quackback URL:

1. Go to **Zendesk Admin Center > Apps > Manage**
2. Find the Quackback app and click the gear icon
3. Enter your Quackback instance URL in the **Quackback URL** field

## Next Steps

- [HubSpot](/docs/integrations/hubspot) -- Enrich feedback with HubSpot contact and deal data
- [Intercom](/docs/integrations/intercom) -- Enrich feedback with Intercom contact data
- [Integrations Overview](/docs/integrations/overview) -- All integrations


### API

- [API Reference](https://quackback.io/docs/api/introduction): Complete reference for the Quackback REST API. Authentication, pagination, and all available endpoints.
- [GET /posts - List posts](https://quackback.io/docs/api/list-posts): Returns a paginated list of posts with optional filtering
- [POST /posts - Create a post](https://quackback.io/docs/api/create-a-post): Create a new feedback post. The post is created on behalf of the authenticated API key holder.
- [GET /posts/{postId} - Get a post](https://quackback.io/docs/api/get-a-post): Get a single post by ID with full details
- [PATCH /posts/{postId} - Update a post](https://quackback.io/docs/api/update-a-post): Update an existing post
- [DELETE /posts/{postId} - Delete a post](https://quackback.io/docs/api/delete-a-post): Delete a post by ID
- [GET /boards - List boards](https://quackback.io/docs/api/list-boards): Returns all boards in the workspace
- [POST /boards - Create a board](https://quackback.io/docs/api/create-a-board): Create a new feedback board
- [GET /boards/{boardId} - Get a board](https://quackback.io/docs/api/get-a-board): Get a single board by ID
- [PATCH /boards/{boardId} - Update a board](https://quackback.io/docs/api/update-a-board): Update an existing board
- [DELETE /boards/{boardId} - Delete a board](https://quackback.io/docs/api/delete-a-board): Delete a board by ID
- [GET /posts/{postId}/comments - List comments on a post](https://quackback.io/docs/api/list-comments-on-a-post): Returns all comments on a post as a threaded tree with nested replies
- [POST /posts/{postId}/comments - Add a comment to a post](https://quackback.io/docs/api/add-a-comment-to-a-post): Create a new comment on a post. The comment is attributed to the authenticated API key holder.
- [GET /comments/{commentId} - Get a comment](https://quackback.io/docs/api/get-a-comment): Get a single comment by ID
- [PATCH /comments/{commentId} - Update a comment](https://quackback.io/docs/api/update-a-comment): Update an existing comment
- [DELETE /comments/{commentId} - Delete a comment](https://quackback.io/docs/api/delete-a-comment): Delete a comment by ID
- [POST /posts/{postId}/vote - Toggle vote on a post](https://quackback.io/docs/api/toggle-vote-on-a-post): Vote or unvote on a post (toggle)
- [POST /posts/{postId}/vote/proxy - Add a proxy vote](https://quackback.io/docs/api/add-a-proxy-vote): Add a vote on behalf of another user (insert-only, never toggles). Requires team role.
- [DELETE /posts/{postId}/vote/proxy - Remove a vote](https://quackback.io/docs/api/remove-a-vote): Remove any vote (proxy, integration, or direct) for a user. Requires team role.
- [GET /tags - List tags](https://quackback.io/docs/api/list-tags): Returns all tags in the workspace
- [POST /tags - Create a tag](https://quackback.io/docs/api/create-a-tag): Create a new tag
- [GET /tags/{tagId} - Get a tag](https://quackback.io/docs/api/get-a-tag): Get a single tag by ID
- [PATCH /tags/{tagId} - Update a tag](https://quackback.io/docs/api/update-a-tag): Update an existing tag
- [DELETE /tags/{tagId} - Delete a tag](https://quackback.io/docs/api/delete-a-tag): Delete a tag by ID
- [GET /statuses - List statuses](https://quackback.io/docs/api/list-statuses): Returns all statuses in the workspace, ordered by category and position
- [POST /statuses - Create a status](https://quackback.io/docs/api/create-a-status): Create a new post status
- [GET /statuses/{statusId} - Get a status](https://quackback.io/docs/api/get-a-status): Get a single status by ID
- [PATCH /statuses/{statusId} - Update a status](https://quackback.io/docs/api/update-a-status): Update an existing status. Note: slug, category, and position cannot be changed via this endpoint.
- [DELETE /statuses/{statusId} - Delete a status](https://quackback.io/docs/api/delete-a-status): Delete a status by ID. Cannot delete the default status or a status with assigned posts.
- [GET /members - List team members](https://quackback.io/docs/api/list-team-members): Returns all team members (admin and member roles) in the workspace
- [GET /members/{principalId} - Get a team member](https://quackback.io/docs/api/get-a-team-member): Get a single team member by ID
- [PATCH /members/{principalId} - Update a team member](https://quackback.io/docs/api/update-a-team-member): Update a team member's role. Cannot modify your own role.
- [DELETE /members/{principalId} - Remove a team member](https://quackback.io/docs/api/remove-a-team-member): Remove a team member from the workspace (converts them to a portal user). Cannot remove yourself or the last admin.
- [GET /roadmaps - List roadmaps](https://quackback.io/docs/api/list-roadmaps): Returns all roadmaps in the workspace
- [POST /roadmaps - Create a roadmap](https://quackback.io/docs/api/create-a-roadmap): Create a new roadmap
- [GET /roadmaps/{roadmapId} - Get a roadmap](https://quackback.io/docs/api/get-a-roadmap): Get a single roadmap by ID
- [PATCH /roadmaps/{roadmapId} - Update a roadmap](https://quackback.io/docs/api/update-a-roadmap): Update an existing roadmap
- [DELETE /roadmaps/{roadmapId} - Delete a roadmap](https://quackback.io/docs/api/delete-a-roadmap): Delete a roadmap by ID
- [GET /roadmaps/{roadmapId}/posts - List posts in a roadmap](https://quackback.io/docs/api/list-posts-in-a-roadmap): Returns posts assigned to a roadmap
- [POST /roadmaps/{roadmapId}/posts - Add a post to a roadmap](https://quackback.io/docs/api/add-a-post-to-a-roadmap): Add an existing post to a roadmap
- [DELETE /roadmaps/{roadmapId}/posts/{postId} - Remove a post from a roadmap](https://quackback.io/docs/api/remove-a-post-from-a-roadmap): Remove a post from a roadmap
- [GET /changelog - List changelog entries](https://quackback.io/docs/api/list-changelog-entries): Returns changelog entries with optional filtering by published status
- [POST /changelog - Create a changelog entry](https://quackback.io/docs/api/create-a-changelog-entry): Create a new changelog entry
- [GET /changelog/{entryId} - Get a changelog entry](https://quackback.io/docs/api/get-a-changelog-entry): Get a single changelog entry by ID
- [PATCH /changelog/{entryId} - Update a changelog entry](https://quackback.io/docs/api/update-a-changelog-entry): Update an existing changelog entry
- [DELETE /changelog/{entryId} - Delete a changelog entry](https://quackback.io/docs/api/delete-a-changelog-entry): Delete a changelog entry by ID
- [GET /conversations - List conversations](https://quackback.io/docs/api/list-conversations): Returns a paginated list of support conversations. Requires a team-role API key.
- [GET /conversations/{conversationId} - Get a conversation](https://quackback.io/docs/api/get-a-conversation): Get a single conversation by ID. Requires a team-role API key.
- [GET /conversations/{conversationId}/messages - List messages in a conversation](https://quackback.io/docs/api/list-messages-in-a-conversation): Returns a paginated list of messages in a conversation. Internal agent notes are excluded by default. Requires a team-role API key.

### MCP

- [MCP Server](https://quackback.io/docs/mcp): Connect AI agents to your feedback. Quackback's MCP server gives agents full access to search, triage, create, and respond to feedback.

# MCP Server

Quackback includes an MCP server that gives AI agents direct access to your feedback data. Agents connect over HTTP, authenticate with an API key or OAuth, and call tools to search, triage, and respond to feedback.

## What agents can do

- **Search and filter** feedback across boards, statuses, and tags
- **Triage posts**: update status, assign owners, and tag
- **Review AI suggestions**: list, accept, dismiss, and restore AI-generated feedback suggestions
- **Create, update, and delete** posts and changelog entries
- **Comment, vote, and react** on feedback
- **Merge duplicates** and manage roadmap assignments
- **Work the support inbox**: list and read conversations, reply to visitors, and open or close conversations (when the support inbox is enabled)
- **View activity logs**: see status changes, merges, and other events on a post
- **Read resources**: boards, statuses, tags, roadmaps, and team members
- **Manage help center**: create, update, publish, and delete articles and categories (when help center is enabled)

See the [MCP Reference](/docs/mcp/reference) for the full tool and resource documentation.

## Setup

### 1. Enable MCP

Navigate to **Admin → Settings → MCP Server** and toggle the server on.

### 2. Create an API key

Navigate to **Admin → Settings → Developers**. Create a key with a descriptive name (e.g., "Claude Code"). The key starts with `qb_` and is only shown once. Copy it immediately.

### 3. Connect your agent

Choose your client below. Replace `feedback.example.com` with your instance URL.

#### Claude Code

Add to `.mcp.json` in your project root. Set the `QUACKBACK_API_KEY` environment variable to your API key.

```json
{
  "mcpServers": {
    "quackback": {
      "type": "http",
      "url": "https://feedback.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${QUACKBACK_API_KEY}"
      }
    }
  }
}
```

Or use the CLI:

```bash
claude mcp add --transport http quackback https://feedback.example.com/mcp \
  --header "Authorization: Bearer $QUACKBACK_API_KEY"
```

#### Cursor

Add to `.cursor/mcp.json` in your project root. Set the `QUACKBACK_API_KEY` environment variable to your API key.

```json
{
  "mcpServers": {
    "quackback": {
      "url": "https://feedback.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:QUACKBACK_API_KEY}"
      }
    }
  }
}
```

#### VS Code

Add to `.vscode/mcp.json` in your project root. VS Code will prompt you for the API key on first use and store it securely.

```json
{
  "inputs": [
    {
      "type": "promptString",
      "id": "quackback-api-key",
      "description": "Quackback API Key (qb_...)",
      "password": true
    }
  ],
  "servers": {
    "quackback": {
      "type": "http",
      "url": "https://feedback.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${input:quackback-api-key}"
      }
    }
  }
}
```

#### Windsurf

Add to `~/.codeium/windsurf/mcp_config.json`. Set the `QUACKBACK_API_KEY` environment variable to your API key.

```json
{
  "mcpServers": {
    "quackback": {
      "serverUrl": "https://feedback.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:QUACKBACK_API_KEY}"
      }
    }
  }
}
```

#### Claude Desktop

Claude Desktop doesn't support custom HTTP headers natively. Use `mcp-remote` as a bridge. Add to `claude_desktop_config.json`:

```json
{
  "mcpServers": {
    "quackback": {
      "command": "npx",
      "args": [
        "mcp-remote@latest",
        "--http",
        "https://feedback.example.com/mcp",
        "--header",
        "Authorization: Bearer qb_YOUR_API_KEY"
      ]
    }
  }
}
```

Replace `qb_YOUR_API_KEY` with your actual API key. Requires Node.js.

## Authentication

Two authentication methods are supported:

- **API keys** (`qb_` prefix): Full access to all scopes. Available to team members (admin or member role). Create them in **Admin → Settings → Developers**.
- **OAuth 2.1**: Scoped access. Supports MCP OAuth discovery so clients like Claude Code can authenticate automatically without manual key setup.

## Scopes

| Scope | Grants |
|-------|--------|
| `read:feedback` | Search posts and changelogs, get details, read resources |
| `write:feedback` | Create posts, vote, comment, triage |
| `write:changelog` | Create changelog entries |
| `read:help-center` | Search and read help center articles and categories |
| `write:help-center` | Create, update, publish, and delete articles and categories |
| `read:chat` | List and read support-inbox conversations and messages |
| `write:chat` | Reply to conversations and change their status |

API keys get all seven scopes. OAuth tokens get only the scopes the user approved.

## Service principals

Every API key gets its own identity. When an agent triages a post, the audit trail shows which key did it. Create descriptive key names like "GitHub Actions" or "Claude Code" to keep attribution clear.

## Next steps

- [MCP Reference](/docs/mcp/reference): Full tool and resource documentation
- [API Overview](/docs/api/introduction): REST API for programmatic integrations
- [Webhooks](/docs/integrations/webhooks): Receive real-time event notifications

- [MCP Reference](https://quackback.io/docs/mcp/reference): Complete reference for Quackback's MCP tools and resources. Parameters, return values, and examples for all 27 tools and 5 resources.

# MCP Reference

Quackback's MCP server exposes 27 tools and 5 resources. Tools perform actions (search, create, update, delete). Resources provide lookup data (boards, statuses, tags) that tools reference by ID.

## Tools

### search

Search feedback posts or changelog entries. Returns paginated results with a cursor for the next page.

| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| `entity` | `"posts"` \| `"changelogs"` \| `"articles"` | `"posts"` | Entity type to search |
| `query` | string | - | Text search across titles and content |
| `boardId` | string | - | Filter posts by board TypeID (ignored for changelogs) |
| `status` | string | - | Filter by status slug. Posts: `"open"`, `"in_progress"`, etc. Changelogs: `"draft"`, `"published"`, `"scheduled"`, `"all"` |
| `tagIds` | string[] | - | Filter posts by tag TypeIDs (ignored for changelogs) |
| `sort` | `"newest"` \| `"oldest"` \| `"votes"` | `"newest"` | Sort order. `"votes"` only applies to posts |
| `showDeleted` | boolean | `false` | Show soft-deleted posts (team only, last 30 days) |
| `dateFrom` | string | - | ISO 8601 date. Filter posts created on or after this date |
| `dateTo` | string | - | ISO 8601 date. Filter posts created on or before this date |
| `limit` | number (1-100) | `20` | Max results per page |
| `cursor` | string | - | Pagination cursor from a previous response |

**Scope:** `read:feedback`

```
search({ query: "dark mode", sort: "votes", limit: 10 })
search({ entity: "changelogs", status: "published" })
search({ entity: "articles", query: "getting started", status: "published" })
search({ boardId: "board_01abc...", status: "open" })
search({ dateFrom: "2026-01-01", dateTo: "2026-02-01" })
search({ showDeleted: true })
```

---

### get_details

Get full details for any entity by TypeID. The entity type is auto-detected from the ID prefix. No need to specify whether it's a post or changelog.

| Parameter | Type | Description |
|-----------|------|-------------|
| `id` | string | TypeID of the entity (e.g., `post_01abc...`, `changelog_01xyz...`) |

**Scope:** `read:feedback`

Returns all fields including comments (for posts), linked posts (for changelogs), tags, official response, and timestamps. Also supports `helpcenter_article_*` and `helpcenter_category_*` IDs.

```
get_details({ id: "post_01abc..." })
get_details({ id: "changelog_01xyz..." })
get_details({ id: "helpcenter_article_01abc..." })
get_details({ id: "helpcenter_category_01abc..." })
```

---

### triage_post

Update a post's status, tags, or owner. All fields except `postId` are optional. Only provided fields are updated.

| Parameter | Type | Description |
|-----------|------|-------------|
| `postId` | string | Post TypeID to update |
| `statusId` | string | New status TypeID |
| `tagIds` | string[] | Replace all tags with these TypeIDs |
| `ownerPrincipalId` | string \| null | Assign to a team member TypeID, or `null` to unassign |

**Scope:** `write:feedback` + team role (admin or member)

```
triage_post({ postId: "post_01abc...", statusId: "status_01xyz..." })
triage_post({ postId: "post_01abc...", ownerPrincipalId: "principal_01xyz..." })
triage_post({ postId: "post_01abc...", tagIds: ["tag_01a...", "tag_01b..."] })
```

---

### vote_post

Toggle a vote on a feedback post. Call once to vote, call again to unvote.

| Parameter | Type | Description |
|-----------|------|-------------|
| `postId` | string | Post TypeID to vote on |

**Scope:** `write:feedback`

Returns the current vote state and total vote count.

```
vote_post({ postId: "post_01abc..." })
```

---

### proxy_vote

Add or remove a vote on behalf of another user. Use this to record votes from external channels (support tickets, Slack messages, sales calls) with source attribution for traceability.

| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| `action` | `"add"` \| `"remove"` | `"add"` | Whether to add or remove the proxy vote |
| `postId` | string | - | Post TypeID to vote on |
| `voterPrincipalId` | string | - | Principal TypeID of the user to vote on behalf of |
| `sourceType` | string | - | Attribution source type (e.g. `"zendesk"`, `"slack"`, `"intercom"`) |
| `sourceExternalUrl` | string | - | URL linking to the originating record |

**Scope:** `write:feedback` + team role (admin or member)

Adding a vote is idempotent — calling it twice for the same user has no effect. Removing a vote works for any vote type (proxy, integration, or direct).

```
proxy_vote({ postId: "post_01abc...", voterPrincipalId: "principal_01xyz..." })
proxy_vote({
  postId: "post_01abc...",
  voterPrincipalId: "principal_01xyz...",
  sourceType: "zendesk",
  sourceExternalUrl: "https://support.example.com/tickets/1234"
})
proxy_vote({ action: "remove", postId: "post_01abc...", voterPrincipalId: "principal_01xyz..." })
```

---

### add_comment

Post a comment on a feedback post. Supports threaded replies via `parentId`.

| Parameter | Type | Description |
|-----------|------|-------------|
| `postId` | string | Post TypeID to comment on |
| `content` | string | Comment text (max 5,000 characters) |
| `parentId` | string | Parent comment TypeID for a threaded reply |

**Scope:** `write:feedback`

```
add_comment({ postId: "post_01abc...", content: "Thanks for the feedback!" })
add_comment({
  postId: "post_01abc...",
  content: "Good point.",
  parentId: "comment_01xyz..."
})
```

---

### update_comment

Edit a comment's content. Team members can edit any comment. Authors can edit their own.

| Parameter | Type | Description |
|-----------|------|-------------|
| `commentId` | string | Comment TypeID to edit |
| `content` | string | New comment text (max 5,000 characters) |

**Scope:** `write:feedback`

```
update_comment({ commentId: "comment_01abc...", content: "Updated response." })
```

---

### delete_comment

Hard-delete a comment and all its replies. This cannot be undone. Authors can delete their own comments. Team members can delete any comment.

| Parameter | Type | Description |
|-----------|------|-------------|
| `commentId` | string | Comment TypeID to delete |

**Scope:** `write:feedback`

```
delete_comment({ commentId: "comment_01abc..." })
```

---

### react_to_comment

Add or remove an emoji reaction on a comment.

| Parameter | Type | Description |
|-----------|------|-------------|
| `action` | `"add"` \| `"remove"` | Whether to add or remove the reaction |
| `commentId` | string | Comment TypeID to react to |
| `emoji` | string | Emoji character (e.g., `"👍"`, `"❤️"`, `"🎉"`) |

**Scope:** `write:feedback`

```
react_to_comment({ action: "add", commentId: "comment_01abc...", emoji: "👍" })
react_to_comment({ action: "remove", commentId: "comment_01abc...", emoji: "👍" })
```

---

### create_post

Submit new feedback on a board. Requires a board ID and title. Content, status, and tags are optional.

| Parameter | Type | Description |
|-----------|------|-------------|
| `boardId` | string | Board TypeID (use `quackback://boards` resource to find IDs) |
| `title` | string | Post title (max 200 characters) |
| `content` | string | Post body (max 10,000 characters) |
| `statusId` | string | Initial status TypeID (defaults to board default) |
| `tagIds` | string[] | Tag TypeIDs to apply |

**Scope:** `write:feedback`

```
create_post({ boardId: "board_01abc...", title: "Add dark mode" })
create_post({
  boardId: "board_01abc...",
  title: "Add dark mode",
  content: "Would love a dark theme option.",
  statusId: "status_01xyz...",
  tagIds: ["tag_01a..."]
})
```

---

### delete_post

Soft-delete a feedback post. The post is hidden from public views but can be restored within 30 days.

| Parameter | Type | Description |
|-----------|------|-------------|
| `postId` | string | Post TypeID to delete |

**Scope:** `write:feedback` + team role (admin or member)

```
delete_post({ postId: "post_01abc..." })
```

---

### restore_post

Restore a soft-deleted post. Posts can only be restored within 30 days of deletion.

| Parameter | Type | Description |
|-----------|------|-------------|
| `postId` | string | Post TypeID to restore |

**Scope:** `write:feedback` + team role (admin or member)

```
restore_post({ postId: "post_01abc..." })
```

---

### merge_post

Merge a duplicate post into a canonical post. Votes are combined. Reversible via `unmerge_post`.

| Parameter | Type | Description |
|-----------|------|-------------|
| `duplicatePostId` | string | Post TypeID of the duplicate to merge away |
| `canonicalPostId` | string | Post TypeID of the canonical post to merge into |

**Scope:** `write:feedback` + team role (admin or member)

```
merge_post({
  duplicatePostId: "post_01abc...",
  canonicalPostId: "post_01xyz..."
})
```

---

### unmerge_post

Restore a merged post to independent state. Recalculates vote counts for both posts.

| Parameter | Type | Description |
|-----------|------|-------------|
| `postId` | string | Post TypeID of the merged post to restore |

**Scope:** `write:feedback` + team role (admin or member)

```
unmerge_post({ postId: "post_01abc..." })
```

---

### manage_roadmap_post

Add or remove a post from a roadmap.

| Parameter | Type | Description |
|-----------|------|-------------|
| `action` | `"add"` \| `"remove"` | Whether to add or remove the post |
| `roadmapId` | string | Roadmap TypeID |
| `postId` | string | Post TypeID |

**Scope:** `write:feedback` + team role (admin or member)

```
manage_roadmap_post({ action: "add", roadmapId: "roadmap_01abc...", postId: "post_01xyz..." })
manage_roadmap_post({ action: "remove", roadmapId: "roadmap_01abc...", postId: "post_01xyz..." })
```

---

### create_changelog

Create a changelog entry. Saves as a draft by default. Set `publish: true` to publish immediately.

| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| `title` | string | - | Changelog entry title (max 200 characters) |
| `content` | string | - | Changelog content, markdown supported (max 50,000 characters) |
| `publish` | boolean | `false` | Set to `true` to publish immediately |

**Scope:** `write:changelog` + team role (admin or member)

```
create_changelog({ title: "v2.1 Release", content: "## New features\n- Dark mode..." })
create_changelog({ title: "v2.1 Release", content: "...", publish: true })
```

---

### update_changelog

Update an existing changelog entry's title, content, publish state, or linked posts.

| Parameter | Type | Description |
|-----------|------|-------------|
| `changelogId` | string | Changelog TypeID to update |
| `title` | string | New title (max 200 characters) |
| `content` | string | New content, markdown supported (max 50,000 characters) |
| `publish` | boolean | `true` to publish, `false` to revert to draft |
| `linkedPostIds` | string[] | Replace linked posts with these post TypeIDs |

**Scope:** `write:changelog` + team role (admin or member)

```
update_changelog({ changelogId: "changelog_01abc...", title: "v2.1.1 Patch" })
update_changelog({
  changelogId: "changelog_01abc...",
  publish: true,
  linkedPostIds: ["post_01a...", "post_01b..."]
})
```

---

### delete_changelog

Soft-delete a changelog entry.

| Parameter | Type | Description |
|-----------|------|-------------|
| `changelogId` | string | Changelog TypeID to delete |

**Scope:** `write:changelog` + team role (admin or member)

```
delete_changelog({ changelogId: "changelog_01abc..." })
```

### list_suggestions

List AI-generated feedback suggestions. Suggestions are created when feedback is ingested from external sources (Slack, email, API) and processed by the AI pipeline.

Three suggestion types:
- `create_post` - AI extracted new feedback and suggests creating a post
- `vote_on_post` - AI matched feedback to an existing post and suggests adding a vote
- `duplicate_post` - AI detected two existing posts that may be duplicates

| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| `status` | `"pending"` \| `"dismissed"` | `"pending"` | Filter by suggestion status |
| `suggestionType` | `"create_post"` \| `"vote_on_post"` \| `"duplicate_post"` | - | Filter by type |
| `sort` | `"newest"` \| `"relevance"` | `"newest"` | Sort order |
| `limit` | number (1-100) | `20` | Max results per page |
| `cursor` | string | - | Pagination cursor from a previous response |

**Scope:** `read:feedback` + team role (admin or member)

Each suggestion includes the original raw feedback item, matched post (if applicable), AI signal data (summary, evidence, confidence), and source metadata.

```
list_suggestions()
list_suggestions({ suggestionType: "create_post" })
list_suggestions({ status: "dismissed", sort: "relevance" })
```

---

### accept_suggestion

Accept an AI-generated suggestion. The result depends on the suggestion type:

- **create_post**: Creates a new post from the extracted feedback. Optional edits override the suggested title, body, or board.
- **vote_on_post**: Adds a proxy vote to the matched existing post.
- **duplicate_post**: Merges the source post into the target post. Use `swapDirection` to reverse which post is kept.

| Parameter | Type | Description |
|-----------|------|-------------|
| `id` | string | Suggestion TypeID (`feedback_suggestion_xxx` or `merge_sug_xxx`) |
| `edits` | object | Optional. Override `title`, `body`, `boardId`, or `statusId` before accepting (create_post only) |
| `swapDirection` | boolean | Optional. Reverse merge direction (duplicate_post only) |

**Scope:** `write:feedback` + team role (admin or member)

```
accept_suggestion({ id: "feedback_suggestion_01abc..." })
accept_suggestion({
  id: "feedback_suggestion_01abc...",
  edits: { title: "Better title" }
})
accept_suggestion({ id: "merge_sug_01abc...", swapDirection: true })
```

---

### dismiss_suggestion

Dismiss an AI-generated suggestion. The suggestion can be restored later via `restore_suggestion`.

| Parameter | Type | Description |
|-----------|------|-------------|
| `id` | string | Suggestion TypeID (`feedback_suggestion_xxx` or `merge_sug_xxx`) |

**Scope:** `write:feedback` + team role (admin or member)

```
dismiss_suggestion({ id: "feedback_suggestion_01abc..." })
dismiss_suggestion({ id: "merge_sug_01abc..." })
```

---

### restore_suggestion

Restore a dismissed suggestion back to pending status.

| Parameter | Type | Description |
|-----------|------|-------------|
| `id` | string | Suggestion TypeID (`feedback_suggestion_xxx` or `merge_sug_xxx`) |

**Scope:** `write:feedback` + team role (admin or member)

```
restore_suggestion({ id: "feedback_suggestion_01abc..." })
```

---

### get_post_activity

Get the activity log for a post. Shows status changes, merges, tag changes, owner assignments, proxy votes, comment pins, and other events in reverse chronological order (limited to the 200 most recent).

| Parameter | Type | Description |
|-----------|------|-------------|
| `postId` | string | Post TypeID |

**Scope:** `read:feedback` + team role (admin or member)

Each activity entry includes the event type, actor name, metadata (e.g., old/new status), and timestamp.

```
get_post_activity({ postId: "post_01abc..." })
```

---

## Help Center Tools

### create_article

Create a new help center article as a draft.

| Parameter | Type | Description |
|-----------|------|-------------|
| `categoryId` | string | Category TypeID to place the article in |
| `title` | string | Article title (max 200 characters) |
| `slug` | string | URL slug (lowercase, hyphens only) |
| `content` | string | Article body in Markdown |
| `description` | string | Short description for search results and SEO |

**Scope:** `write:help-center` + team role

Articles are created as drafts. Use `update_article` with `publish: true` to publish.

---

### update_article

Update an existing help center article. Publish or unpublish by setting the `publish` parameter.

| Parameter | Type | Description |
|-----------|------|-------------|
| `articleId` | string | Article TypeID to update |
| `title` | string | New title |
| `content` | string | New content in Markdown |
| `description` | string | New description |
| `slug` | string | New URL slug |
| `categoryId` | string | Move to a different category |
| `publish` | boolean | `true` to publish, `false` to unpublish |

**Scope:** `write:help-center` + team role

All fields except `articleId` are optional. Only provided fields are updated.

---

### delete_article

Soft-delete a help center article.

| Parameter | Type | Description |
|-----------|------|-------------|
| `articleId` | string | Article TypeID to delete |

**Scope:** `write:help-center` + team role

---

### manage_category

Create, update, or delete a help center category.

| Parameter | Type | Description |
|-----------|------|-------------|
| `action` | `"create"` \| `"update"` \| `"delete"` | Operation to perform |
| `categoryId` | string | Category TypeID (required for update/delete) |
| `name` | string | Category name (required for create) |
| `slug` | string | URL slug (required for create) |
| `description` | string | Category description |
| `icon` | string | Icon identifier |
| `parentId` | string | Parent category TypeID for nesting |

**Scope:** `write:help-center` + team role

---

## Conversation Tools

Work the support inbox programmatically: list and read conversations, reply to visitors, and change conversation status. All conversation tools require a team role (admin or member) and the support inbox to be enabled.

### list_conversations

List support-inbox conversations, newest activity first. Returns a compact, paginated list.

| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| `status` | `"open"` \| `"pending"` \| `"closed"` | - | Filter by conversation status |
| `priority` | `"none"` \| `"low"` \| `"medium"` \| `"high"` \| `"urgent"` | - | Filter by priority |
| `assignedAgentPrincipalId` | string | - | Filter to a specific assigned agent (principal TypeID) |
| `limit` | number (1-100) | `20` | Max results per page |
| `cursor` | string | - | Pagination cursor from a previous response |

**Scope:** `read:chat` + team role (admin or member)

```
list_conversations({ status: "open" })
list_conversations({ assignedAgentPrincipalId: "principal_01xyz...", priority: "high" })
```

---

### get_conversation

Get a conversation and its most recent messages.

| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| `conversationId` | string | - | Conversation TypeID |
| `includeInternal` | boolean | `false` | Include agent-only internal notes |
| `cursor` | string | - | Cursor from a previous response to fetch older messages |

**Scope:** `read:chat` + team role (admin or member)

Internal notes are excluded unless `includeInternal` is `true`. Anonymous visitors' synthetic emails are never returned.

```
get_conversation({ conversationId: "conversation_01abc..." })
get_conversation({ conversationId: "conversation_01abc...", includeInternal: true })
```

---

### reply_to_conversation

Send an agent reply in a conversation (visible to the visitor). Auto-assigns the conversation to the calling agent if it's unassigned.

| Parameter | Type | Description |
|-----------|------|-------------|
| `conversationId` | string | Conversation TypeID |
| `content` | string | Reply text sent to the visitor (max 4000 characters) |

**Scope:** `write:chat` + team role (admin or member)

```
reply_to_conversation({ conversationId: "conversation_01abc...", content: "Thanks for reaching out — we're on it." })
```

---

### set_conversation_status

Change a conversation's status. Closing stamps the resolution time; a later visitor reply reopens it.

| Parameter | Type | Description |
|-----------|------|-------------|
| `conversationId` | string | Conversation TypeID |
| `status` | `"open"` \| `"pending"` \| `"closed"` | New status |

**Scope:** `write:chat` + team role (admin or member)

```
set_conversation_status({ conversationId: "conversation_01abc...", status: "closed" })
```

---

## Resources

Resources provide lookup data for boards, statuses, tags, roadmaps, and team members. Use them to find IDs before calling tools like `triage_post` or `create_post`.

All resources require the `read:feedback` scope.

| URI | Returns | Fields |
|-----|---------|--------|
| `quackback://boards` | All boards | `id`, `name`, `slug` |
| `quackback://statuses` | All statuses | `id`, `name`, `slug`, `color` |
| `quackback://tags` | All tags | `id`, `name`, `color` |
| `quackback://roadmaps` | All roadmaps | `id`, `name`, `slug` |
| `quackback://members` | Team members | `id`, `name`, `role` |


### Developers

- [Add a new feature](https://quackback.io/docs/developers/adding-features): Build features from database to UI using existing patterns.

# Add a new feature

Build features that fit. This guide walks you through adding new functionality to Quackback, from database schema to UI components, using patterns that already exist in the codebase. Follow these conventions and your code will feel native.

## Plan a feature

Before writing code, understand where each piece goes:

| Layer | Location | Purpose |
|-------|----------|---------|
| Schema | `packages/db/src/schema/` | Database tables and relations |
| Service | `apps/web/src/lib/server/domains/\{feature\}/` | Business logic and validation |
| Server Functions | `apps/web/src/lib/server/functions/` | API endpoints (RPC) |
| Queries | `apps/web/src/lib/client/queries/` | TanStack Query factories |
| Hooks | `apps/web/src/lib/client/hooks/` | React hooks for mutations |
| Mutations | `apps/web/src/lib/client/mutations/` | TanStack mutation hooks |
| Components | `apps/web/src/components/` | UI components |
| Routes | `apps/web/src/routes/` | Page components with loaders |

### Naming Conventions

- **Files**: kebab-case (`user-profile.tsx`)
- **Components**: PascalCase (`UserProfile`)
- **Functions**: camelCase (`getUserProfile`)
- **Database**: snake_case (`post_tags`)
- **TypeIDs**: lowercase singular prefix (`post_01h455vb...`)

## Database Changes

### Add a new table

1. Create or edit a schema file in `packages/db/src/schema/`:

```typescript
// packages/db/src/schema/reactions.ts

  pgTable,
  text,
  timestamp,
  index,
  uniqueIndex,
} from 'drizzle-orm/pg-core'

  'reactions',
  {
    // Primary key with auto-generated TypeID
    id: typeIdWithDefault('reaction')('id').primaryKey(),

    // Foreign keys using TypeID columns
    postId: typeIdColumn('post')('post_id')
      .notNull()
      .references(() => posts.id, { onDelete: 'cascade' }),

    memberId: typeIdColumn('member')('member_id')
      .notNull()
      .references(() => member.id, { onDelete: 'cascade' }),

    emoji: text('emoji').notNull(),

    // Timestamps
    createdAt: timestamp('created_at', { withTimezone: true })
      .defaultNow()
      .notNull(),
  },
  (table) => [
    // Indexes for query performance
    index('reactions_post_id_idx').on(table.postId),
    index('reactions_member_id_idx').on(table.memberId),

    // Unique constraint: one reaction per member per post per emoji
    uniqueIndex('reactions_unique_idx').on(
      table.postId,
      table.memberId,
      table.emoji
    ),
  ]
)

// Define relations for Drizzle query builder

  post: one(posts, {
    fields: [reactions.postId],
    references: [posts.id],
  }),
  member: one(member, {
    fields: [reactions.memberId],
    references: [member.id],
  }),
}))
```

2. Export from the schema index:

```typescript
// packages/db/src/schema/index.ts

```

3. Add the TypeID prefix (if new entity type):

```typescript
// packages/ids/src/prefixes.ts

  // ... existing prefixes
  reaction: 'reaction',
} as const
```

### Generate migrations

After modifying schema files:

```bash
# Generate migration from schema changes
bun run db:generate

# Review the generated SQL in packages/db/drizzle/
# Then apply it
bun run db:migrate
```

### Migration Best Practices

- Migrations should be **idempotent** (safe to run multiple times)
- Use `IF NOT EXISTS` / `IF EXISTS` for safety
- For data migrations, handle NULL values gracefully
- Add indexes after data is populated for better performance

Example migration structure:

```sql
-- packages/db/drizzle/0014_add_reactions.sql

-- Step 1: Create table
CREATE TABLE IF NOT EXISTS "reactions" (
  "id" uuid PRIMARY KEY,
  "post_id" uuid NOT NULL REFERENCES "posts"("id") ON DELETE CASCADE,
  "member_id" uuid NOT NULL REFERENCES "member"("id") ON DELETE CASCADE,
  "emoji" text NOT NULL,
  "created_at" timestamptz DEFAULT NOW() NOT NULL
);

-- Step 2: Add indexes
CREATE INDEX IF NOT EXISTS "reactions_post_id_idx"
  ON "reactions" USING btree ("post_id");
CREATE INDEX IF NOT EXISTS "reactions_member_id_idx"
  ON "reactions" USING btree ("member_id");
CREATE UNIQUE INDEX IF NOT EXISTS "reactions_unique_idx"
  ON "reactions" USING btree ("post_id", "member_id", "emoji");
```

## Service Layer

Services contain business logic, validation, and database operations. They throw typed errors that map to HTTP status codes.

### Create a service

```typescript
// apps/web/src/lib/server/domains/reactions/reaction.service.ts

/**
 * Add a reaction to a post
 */

  input: CreateReactionInput,
  actor: { memberId: MemberId }
): Promise {
  // Validate emoji
  const validEmojis = ['👍', '❤️', '🎉', '🤔', '👀']
  if (!validEmojis.includes(input.emoji)) {
    throw new ValidationError(
      'INVALID_EMOJI',
      `Emoji must be one of: ${validEmojis.join(', ')}`
    )
  }

  // Verify post exists
  const post = await db.query.posts.findFirst({
    where: eq(posts.id, input.postId),
  })
  if (!post) {
    throw new NotFoundError(
      'POST_NOT_FOUND',
      `Post with ID ${input.postId} not found`
    )
  }

  // Check for existing reaction
  const existing = await db.query.reactions.findFirst({
    where: and(
      eq(reactions.postId, input.postId),
      eq(reactions.memberId, actor.memberId),
      eq(reactions.emoji, input.emoji)
    ),
  })
  if (existing) {
    throw new ConflictError(
      'REACTION_EXISTS',
      'You have already reacted with this emoji'
    )
  }

  // Create reaction
  const [reaction] = await db
    .insert(reactions)
    .values({
      postId: input.postId,
      memberId: actor.memberId,
      emoji: input.emoji,
    })
    .returning()

  return reaction
}

/**
 * Remove a reaction from a post
 */

  postId: PostId,
  emoji: string,
  actor: { memberId: MemberId }
): Promise<void> {
  const result = await db
    .delete(reactions)
    .where(
      and(
        eq(reactions.postId, postId),
        eq(reactions.memberId, actor.memberId),
        eq(reactions.emoji, emoji)
      )
    )
    .returning()

  if (result.length === 0) {
    throw new NotFoundError(
      'REACTION_NOT_FOUND',
      'Reaction not found'
    )
  }
}
```

### Error Types

Use the appropriate error class based on the HTTP status code:

```typescript
// apps/web/src/lib/shared/errors.ts

// 404 - Resource not found
throw new NotFoundError('POST_NOT_FOUND', 'Post not found')

// 400 - Validation/bad request
throw new ValidationError('INVALID_INPUT', 'Title is required')

// 403 - Forbidden/authorization
throw new ForbiddenError('ACCESS_DENIED', 'Admin access required')

// 409 - Conflict (duplicate, already exists)
throw new ConflictError('DUPLICATE_ENTRY', 'Entry already exists')

// 500 - Internal error
throw new InternalError('DATABASE_ERROR', 'Database operation failed')
```

### Types File

Define types in a separate file:

```typescript
// apps/web/src/lib/server/domains/reactions/reaction.types.ts

  postId: PostId
  emoji: string
}

  id: string
  postId: PostId
  memberId: MemberId
  emoji: string
  createdAt: Date
}
```

## Server Functions

Server functions provide the API layer using TanStack Start's `createServerFn`. They handle validation, authentication, and call service functions.

### Create server functions

```typescript
// apps/web/src/lib/server/functions/reactions.ts

  addReaction,
  removeReaction,
  getReactionsForPost,
} from '@/lib/server/domains/reactions/reaction.service'

// ============================================
// Schemas
// ============================================

const addReactionSchema = z.object({
  postId: z.string(),
  emoji: z.string().min(1).max(10),
})

const removeReactionSchema = z.object({
  postId: z.string(),
  emoji: z.string(),
})

const getReactionsSchema = z.object({
  postId: z.string(),
})

// ============================================
// Type Exports
// ============================================

// ============================================
// Server Functions
// ============================================

/**
 * Add a reaction to a post (requires authentication)
 */

  .inputValidator(addReactionSchema)
  .handler(async ({ data }) => {
    // Require any authenticated user
    const auth = await requireAuth()

    const result = await addReaction(
      {
        postId: data.postId as PostId,
        emoji: data.emoji,
      },
      { memberId: auth.member.id }
    )

    return {
      ...result,
      createdAt: result.createdAt.toISOString(),
    }
  })

/**
 * Remove a reaction from a post
 */

  .inputValidator(removeReactionSchema)
  .handler(async ({ data }) => {
    const auth = await requireAuth()

    await removeReaction(
      data.postId as PostId,
      data.emoji,
      { memberId: auth.member.id }
    )

    return { success: true }
  })

/**
 * Get reactions for a post (public, but shows user's reactions if logged in)
 */

  .inputValidator(getReactionsSchema)
  .handler(async ({ data }) => {
    const auth = await getOptionalAuth()

    const reactions = await getReactionsForPost(
      data.postId as PostId,
      auth?.member.id
    )

    return reactions
  })
```

### Authentication Patterns

```typescript
// Require team member (admin or member role)
const auth = await requireAuth({ roles: ['admin', 'member'] })

// Require admin only
const auth = await requireAuth({ roles: ['admin'] })

// Any authenticated user (including portal users)
const auth = await requireAuth()

// Optional auth (returns null if not logged in)
const auth = await getOptionalAuth()

// Access auth context
auth.user.id      // UserId
auth.user.email   // string
auth.user.name    // string
auth.member.id    // MemberId
auth.member.role  // 'admin' | 'member' | 'user'
auth.settings.id  // WorkspaceId
```

## Query Factories

Use TanStack Query factories for consistent caching:

```typescript
// apps/web/src/lib/client/queries/reactions.ts

  /**
   * Get reactions for a post
   */
  forPost: (postId: PostId) =>
    queryOptions({
      queryKey: ['reactions', postId],
      queryFn: () => getReactionsFn({ data: { postId } }),
      staleTime: 30 * 1000, // 30 seconds
    }),
}
```

## React Hooks

Create mutation hooks with optimistic updates:

```typescript
// apps/web/src/lib/client/hooks/use-reactions.ts

  forPost: (postId: PostId) => ['reactions', postId] as const,
}

  const queryClient = useQueryClient()

  return useMutation({
    mutationFn: addReactionFn,
    onSuccess: (_data, variables) => {
      // Invalidate reactions for this post
      queryClient.invalidateQueries({
        queryKey: reactionKeys.forPost(variables.data.postId as PostId),
      })
    },
  })
}

  const queryClient = useQueryClient()

  return useMutation({
    mutationFn: removeReactionFn,
    onSuccess: (_data, variables) => {
      queryClient.invalidateQueries({
        queryKey: reactionKeys.forPost(variables.data.postId as PostId),
      })
    },
  })
}
```

## UI Components

### Component Structure

Components are organized by feature area:

```
apps/web/src/components/
  admin/                    # Admin dashboard components
    feedback/               # Inbox, post detail
    settings/               # Settings pages
    users/                  # User management
  public/                   # Portal components
    feedback/               # Public feedback views
    post-detail/            # Post detail page
  ui/                       # Shared UI primitives (shadcn/ui)
  settings/                 # User settings
  notifications/            # Notification components
```

### Client vs Server Components

- Use **Server Components** by default (no directive needed)
- Add `'use client'` only when you need:
  - React hooks (`useState`, `useEffect`)
  - Event handlers
  - Browser APIs

```typescript
// Server Component (default) - can fetch data directly

  // This runs on the server
  return <div>...</div>
}

// Client Component - for interactivity
'use client'

  const [isOpen, setIsOpen] = useState(false)

  return (
    <button onClick={() => setIsOpen(true)}>
      Add reaction
    </button>
  )
}
```

### Use shadcn/ui components

Import from `@/components/ui/`:

```typescript
'use client'

  Dialog,
  DialogContent,
  DialogDescription,
  DialogFooter,
  DialogHeader,
  DialogTitle,
  DialogTrigger,
} from '@/components/ui/dialog'

  Form,
  FormControl,
  FormField,
  FormItem,
  FormLabel,
  FormMessage,
} from '@/components/ui/form'
```

### Form Example with Validation

```typescript
'use client'

  Dialog,
  DialogContent,
  DialogHeader,
  DialogTitle,
  DialogTrigger,
} from '@/components/ui/dialog'

  Form,
  FormControl,
  FormField,
  FormItem,
  FormLabel,
  FormMessage,
} from '@/components/ui/form'

const createBoardSchema = z.object({
  name: z.string().min(1, 'Board name is required').max(100),
  description: z.string().max(500).optional(),
})

type FormData = z.infer<typeof createBoardSchema>

  const [open, setOpen] = useState(false)
  const mutation = useCreateBoard()

  const form = useForm({
    resolver: standardSchemaResolver(createBoardSchema),
    defaultValues: {
      name: '',
      description: '',
    },
  })

  function onSubmit(data: FormData) {
    mutation.mutate(
      { data },
      {
        onSuccess: () => {
          setOpen(false)
          form.reset()
        },
      }
    )
  }

  return (
    
  )
}
```

## Routes

TanStack Router uses file-based routing. Routes are in `apps/web/src/routes/`.

### Route Groups

| Directory | Purpose |
|-----------|---------|
| `_portal/` | Public feedback portal |
| `admin/` | Admin dashboard |
| `auth.*` | Portal user auth |
| `admin.login/signup` | Team member auth |
| `api/` | API routes |

### Create a route

```typescript
// apps/web/src/routes/admin/reactions.tsx

  // Loader runs on server, prefetches data
  loader: async ({ context }) => {
    const { queryClient } = context

    // Prefetch data for instant page load
    await queryClient.ensureQueryData(reactionQueries.all())

    return {}
  },

  // Component renders with prefetched data
  component: ReactionsPage,
})

function ReactionsPage() {
  // Data is already cached from loader
  const { data: reactions } = useSuspenseQuery(reactionQueries.all())

  return (
    <div className="space-y-6">
      <h1 className="text-xl font-semibold">Reactions</h1>
      
    </div>
  )
}
```

### Route with Parameters

```typescript
// apps/web/src/routes/admin/posts.$postId.tsx

  loader: async ({ params, context }) => {
    const { postId } = params
    const { queryClient } = context

    // Validate TypeID format
    let validatedPostId: PostId
    try {
      validatedPostId = ensureTypeId(postId, 'post')
    } catch {
      throw new Error('Invalid post ID format')
    }

    await queryClient.ensureQueryData(
      adminQueries.postDetail(validatedPostId)
    )

    return { postId: validatedPostId }
  },

  component: PostDetailPage,
})
```

### Route with Search Params

```typescript
// apps/web/src/routes/admin/settings.boards.index.tsx

const searchSchema = z.object({
  board: z.string().optional(),
  tab: z.enum(['general', 'access', 'import', 'export']).optional(),
})

  validateSearch: searchSchema,

  loader: async ({ context }) => {
    // ...
  },

  component: BoardsSettingsPage,
})

function BoardsSettingsPage() {
  const { board, tab } = Route.useSearch()
  // ...
}
```

## Complete example: Add a "Bookmarks" feature

Let's walk through adding a complete feature - allowing users to bookmark posts.

### 1. Add TypeID Prefix

```typescript
// packages/ids/src/prefixes.ts

  // ... existing
  bookmark: 'bookmark',
} as const
```

### 2. Create Database Schema

```typescript
// packages/db/src/schema/bookmarks.ts

  'bookmarks',
  {
    id: typeIdWithDefault('bookmark')('id').primaryKey(),
    postId: typeIdColumn('post')('post_id')
      .notNull()
      .references(() => posts.id, { onDelete: 'cascade' }),
    memberId: typeIdColumn('member')('member_id')
      .notNull()
      .references(() => member.id, { onDelete: 'cascade' }),
    createdAt: timestamp('created_at', { withTimezone: true })
      .defaultNow()
      .notNull(),
  },
  (table) => [
    uniqueIndex('bookmarks_unique_idx').on(table.postId, table.memberId),
    index('bookmarks_member_id_idx').on(table.memberId),
    index('bookmarks_created_at_idx').on(table.memberId, table.createdAt),
  ]
)

  post: one(posts, {
    fields: [bookmarks.postId],
    references: [posts.id],
  }),
}))
```

### 3. Export Schema and Generate Migration

```typescript
// packages/db/src/schema/index.ts

```

```bash
bun run db:generate
bun run db:migrate
```

### 4. Create Service Layer

```typescript
// apps/web/src/lib/server/domains/bookmarks/bookmark.service.ts

  postId: PostId,
  memberId: MemberId
): Promise<{ id: BookmarkId }> {
  // Verify post exists
  const post = await db.query.posts.findFirst({
    where: eq(posts.id, postId),
  })
  if (!post) {
    throw new NotFoundError('POST_NOT_FOUND', 'Post not found')
  }

  // Check if already bookmarked
  const existing = await db.query.bookmarks.findFirst({
    where: and(
      eq(bookmarks.postId, postId),
      eq(bookmarks.memberId, memberId)
    ),
  })
  if (existing) {
    throw new ConflictError('ALREADY_BOOKMARKED', 'Post already bookmarked')
  }

  const [bookmark] = await db
    .insert(bookmarks)
    .values({ postId, memberId })
    .returning()

  return { id: bookmark.id }
}

  postId: PostId,
  memberId: MemberId
): Promise<void> {
  const result = await db
    .delete(bookmarks)
    .where(
      and(eq(bookmarks.postId, postId), eq(bookmarks.memberId, memberId))
    )
    .returning()

  if (result.length === 0) {
    throw new NotFoundError('BOOKMARK_NOT_FOUND', 'Bookmark not found')
  }
}

  return db.query.bookmarks.findMany({
    where: eq(bookmarks.memberId, memberId),
    with: {
      post: {
        with: { board: true },
      },
    },
    orderBy: desc(bookmarks.createdAt),
  })
}

  postId: PostId,
  memberId: MemberId
): Promise<boolean> {
  const bookmark = await db.query.bookmarks.findFirst({
    where: and(
      eq(bookmarks.postId, postId),
      eq(bookmarks.memberId, memberId)
    ),
  })
  return !!bookmark
}
```

### 5. Create Server Functions

```typescript
// apps/web/src/lib/server/functions/bookmarks.ts

  addBookmark,
  removeBookmark,
  listBookmarks,
  isBookmarked,
} from '@/lib/server/domains/bookmarks/bookmark.service'

const postIdSchema = z.object({ postId: z.string() })

  .inputValidator(postIdSchema)
  .handler(async ({ data }) => {
    const auth = await requireAuth()
    return addBookmark(data.postId as PostId, auth.member.id)
  })

  .inputValidator(postIdSchema)
  .handler(async ({ data }) => {
    const auth = await requireAuth()
    await removeBookmark(data.postId as PostId, auth.member.id)
    return { success: true }
  })

  .handler(async () => {
    const auth = await requireAuth()
    const bookmarks = await listBookmarks(auth.member.id)
    return bookmarks.map((b) => ({
      ...b,
      createdAt: b.createdAt.toISOString(),
    }))
  })

  .inputValidator(postIdSchema)
  .handler(async ({ data }) => {
    const auth = await requireAuth()
    return { bookmarked: await isBookmarked(data.postId as PostId, auth.member.id) }
  })
```

### 6. Create React Hook

```typescript
// apps/web/src/lib/client/hooks/use-bookmarks.ts

  addBookmarkFn,
  removeBookmarkFn,
  listBookmarksFn,
  isBookmarkedFn,
} from '@/lib/server/functions/bookmarks'

  all: ['bookmarks'] as const,
  list: () => [...bookmarkKeys.all, 'list'] as const,
  status: (postId: PostId) => [...bookmarkKeys.all, 'status', postId] as const,
}

  return useQuery({
    queryKey: bookmarkKeys.list(),
    queryFn: () => listBookmarksFn(),
  })
}

  return useQuery({
    queryKey: bookmarkKeys.status(postId),
    queryFn: () => isBookmarkedFn({ data: { postId } }),
  })
}

  const queryClient = useQueryClient()

  return useMutation({
    mutationFn: async ({
      postId,
      isCurrentlyBookmarked,
    }: {
      postId: PostId
      isCurrentlyBookmarked: boolean
    }) => {
      if (isCurrentlyBookmarked) {
        return removeBookmarkFn({ data: { postId } })
      }
      return addBookmarkFn({ data: { postId } })
    },
    onSuccess: (_data, { postId }) => {
      queryClient.invalidateQueries({ queryKey: bookmarkKeys.status(postId) })
      queryClient.invalidateQueries({ queryKey: bookmarkKeys.list() })
    },
  })
}
```

### 7. Create UI Component

```typescript
// apps/web/src/components/public/bookmark-button.tsx
'use client'

interface BookmarkButtonProps {
  postId: PostId
}

  const { data, isLoading } = useBookmarkStatus(postId)
  const toggleMutation = useToggleBookmark()

  const isBookmarked = data?.bookmarked ?? false

  function handleClick() {
    toggleMutation.mutate({
      postId,
      isCurrentlyBookmarked: isBookmarked,
    })
  }

  return (
    
  )
}
```

### 8. Add Route for Bookmarks Page

```typescript
// apps/web/src/routes/_portal/bookmarks.tsx

const bookmarksQuery = queryOptions({
  queryKey: ['bookmarks', 'list'],
  queryFn: () => listBookmarksFn(),
})

  loader: async ({ context }) => {
    await context.queryClient.ensureQueryData(bookmarksQuery)
    return {}
  },
  component: BookmarksPage,
})

function BookmarksPage() {
  const { data: bookmarks } = useSuspenseQuery(bookmarksQuery)

  if (bookmarks.length === 0) {
    return (
      <div className="text-center py-12">
        <h2 className="text-lg font-medium">No bookmarks yet</h2>
        <p className="text-muted-foreground mt-1">
          Save posts to find them easily later
        </p>
      </div>
    )
  }

  return (
    <div className="space-y-4">
      <h1 className="text-xl font-semibold">Saved Posts</h1>
      <div className="space-y-3">
        {bookmarks.map((bookmark) => (
          
        ))}
      </div>
    </div>
  )
}
```

## Summary

When adding a feature to Quackback:

1. **Plan**: Identify which layers need changes
2. **Schema**: Add tables in `packages/db/src/schema/`
3. **TypeID**: Add prefix in `packages/ids/src/prefixes.ts`
4. **Migrate**: Run `bun run db:generate && bun run db:migrate`
5. **Service**: Add business logic in `apps/web/src/lib/server/domains/\{feature\}/`
6. **Server Functions**: Add API in `apps/web/src/lib/server/functions/`
7. **Hooks**: Add React hooks in `apps/web/src/lib/client/hooks/`
8. **Components**: Build UI in `apps/web/src/components/`
9. **Routes**: Add pages in `apps/web/src/routes/`
10. **Test**: Run `bun run test` and `bun run typecheck`

Follow existing patterns in the codebase and maintain consistency with naming conventions.

- [Architecture](https://quackback.io/docs/developers/architecture): Understand how Quackback's layers fit together.

# Architecture

Know where everything lives. This overview shows how Quackback's layers fit together: routes, server functions, services, and database. Navigate confidently and make changes in the right places.

## High-Level Architecture

```
┌─────────────────────────────────────────────────────────┐
│                     Browser/Client                       │
│                                                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐   │
│  │  Public      │  │  Admin       │  │  Auth        │   │
│  │  Portal      │  │  Dashboard   │  │  Pages       │   │
│  └──────────────┘  └──────────────┘  └──────────────┘   │
└────────────────────────────┬────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────┐
│                  TanStack Start Server                   │
│                                                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐   │
│  │  Routes      │  │  Server      │  │  API         │   │
│  │  (SSR)       │  │  Functions   │  │  Routes      │   │
│  └──────────────┘  └──────────────┘  └──────────────┘   │
│                             │                            │
│  ┌──────────────┐  ┌────────┴───────┐  ┌─────────────┐  │
│  │  Services    │  │  Auth          │  │  Events     │  │
│  │  Layer       │  │  (Better Auth) │  │  System     │  │
│  └──────────────┘  └────────────────┘  └─────────────┘  │
└────────────────────────────┬────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────┐
│                     PostgreSQL                           │
│                                                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐   │
│  │  Drizzle ORM │  │  pgvector    │  │  pg_cron     │   │
│  └──────────────┘  └──────────────┘  └──────────────┘   │
└─────────────────────────────────────────────────────────┘
```

## Tech Stack

| Layer | Technology | Purpose |
|-------|------------|---------|
| Framework | TanStack Start | Full-stack React framework |
| Routing | TanStack Router | File-based routing, type-safe |
| Database | PostgreSQL 18+ | Primary data store |
| ORM | Drizzle | Type-safe queries |
| Auth | Better Auth | Authentication library |
| Styling | Tailwind CSS v4 | Utility-first CSS |
| Components | shadcn/ui | UI component library |
| Validation | Zod | Runtime type validation |
| State | TanStack Query | Server state management |
| Runtime | Bun | JavaScript runtime |

## Directory Structure

### apps/web/

The main application:

```
apps/web/src/
├── routes/                    # File-based routing
│   ├── __root.tsx             # Root layout
│   ├── _portal/               # Public portal routes
│   ├── admin/                 # Admin dashboard
│   ├── auth.*/                # Portal auth
│   ├── admin.login/           # Team auth
│   ├── onboarding/            # Setup wizard
│   └── api/                   # API routes
│
├── components/                # React components
│   ├── admin/                 # Admin-specific
│   ├── public/                # Portal components
│   ├── settings/              # Settings UI
│   └── ui/                    # shadcn/ui primitives
│
├── lib/                       # Business logic
│   ├── server/                # Server-side code
│   │   ├── functions/         # RPC endpoints (server functions)
│   │   ├── domains/           # Service layers by feature
│   │   │   ├── posts/         # Post service
│   │   │   ├── boards/        # Board service
│   │   │   ├── comments/      # Comment service
│   │   │   ├── statuses/      # Status service
│   │   │   ├── tags/          # Tag service
│   │   │   ├── members/       # Member service
│   │   │   ├── users/         # User service
│   │   │   ├── notifications/ # Notification service
│   │   │   ├── subscriptions/ # Subscription service
│   │   │   ├── ai/            # AI integrations
│   │   │   ├── sentiment/     # Sentiment analysis
│   │   │   ├── embeddings/    # Vector embeddings
│   │   │   ├── summary/       # AI post summaries
│   │   │   ├── merge-suggestions/ # AI duplicate detection
│   │   │   ├── changelog/     # Changelog entries
│   │   │   ├── roadmaps/      # Roadmap management
│   │   │   ├── api-keys/      # API key management
│   │   │   └── webhooks/      # Webhook management
│   │   ├── auth/              # Auth configuration
│   │   ├── events/            # Event dispatch & handlers
│   │   ├── integrations/      # Integration handlers
│   │   ├── storage/           # File storage
│   │   └── db.ts              # Database proxy (lazy singleton)
│   │
│   ├── client/                # Client-side code
│   │   ├── hooks/             # React hooks
│   │   ├── queries/           # TanStack Query factories
│   │   ├── mutations/         # TanStack mutation hooks
│   │   ├── stores/            # Zustand stores
│   │   └── query/             # Query client setup
│   │
│   └── shared/                # Utilities & errors
│
└── router.tsx                 # Router configuration
```

### packages/

Shared code:

```
packages/
├── db/                        # Database layer
│   ├── src/
│   │   ├── schema/            # Drizzle table definitions
│   │   ├── client.ts          # Connection factory
│   │   ├── seed.ts            # Demo data seeding
│   │   └── migrate.ts         # Migration runner
│   └── drizzle/               # Migration SQL files
│
├── ids/                       # TypeID system
│   └── src/
│       ├── index.ts           # ID generation & exports
│       ├── core.ts            # Core ID functions
│       ├── prefixes.ts        # Entity type prefixes
│       ├── types.ts           # Branded type definitions
│       ├── zod.ts             # Validation helpers
│       └── drizzle.ts         # DB column types
│
├── email/                     # Email service
│   └── src/
│       ├── index.ts           # Send functions
│       └── templates/         # React Email templates
│
├── core/                      # Shared core utilities
│
└── integrations/              # Integration connectors
```

## Key Patterns

### Server Functions

Type-safe RPC between client and server:

```typescript
// lib/server/functions/posts.ts

  .inputValidator(z.object({
    title: z.string().min(1),
    content: z.string(),
    boardId: boardIdSchema,
  }))
  .handler(async ({ data }) => {
    const auth = await requireAuth()
    return createPost(data, auth.member)
  })
```

Usage in components:
```typescript
const mutation = useMutation({
  mutationFn: createPostFn,
})
```

### Service Layer

Business logic separate from transport:

```typescript
// lib/server/domains/posts/post.service.ts

  input: CreatePostInput,
  author: Author
): Promise {
  // Validation
  if (!input.title?.trim()) {
    throw new ValidationError('VALIDATION_ERROR', 'Title required')
  }

  // Business logic
  const post = await db.insert(posts).values({
    id: createId('post'),
    ...input,
    authorId: author.id,
  }).returning()

  // Side effects
  await dispatchPostCreated(post, author)

  return post
}
```

### Database Access

```typescript
// ✅ Correct - use the proxy

// ❌ Wrong - bypasses tenant context

```

The proxy handles singleton connection initialization with lazy loading.

### TypeIDs

Branded UUIDs for type safety:

```typescript

// Create new ID
const postId: PostId = createId('post')
// => "post_01h455vb4pex5vsknk084sn02q"

// Type-safe function parameters
function getPost(id: PostId): Promise {
  // Can't accidentally pass a BoardId here
}
```

### Event System

Fire-and-forget event dispatch:

```typescript
// lib/server/events/dispatch.ts

  post: Post,
  actor: EventActor
) {
  await processEvent({
    type: 'post.created',
    data: { post },
    actor,
  })
}

// lib/server/events/process.ts

  const targets = await getHookTargets(event.type)

  await Promise.allSettled(
    targets.map(target => target.handler.run(event, target))
  )
}
```

### Hook Handlers

Extensible integration points:

```typescript
// lib/server/events/handlers/webhook.ts (or similar handler file)

  async run(event, target, config) {
    const message = formatSlackMessage(event)
    await slack.chat.postMessage({
      channel: config.channelId,
      ...message,
    })
    return { success: true }
  },
}
```

## Route Groups

### Public Portal (`_portal/`)

User-facing feedback portal:
- Board listing
- Post detail with comments
- Voting interface
- Public roadmap

### Admin Dashboard (`admin/`)

Team management interface:
- Feedback inbox
- Roadmap management
- Settings configuration

### Authentication

Two separate auth flows:
- `auth.*` - Portal users (password, email OTP, OAuth, OIDC)
- `admin.login` - Team members (password, email OTP, OAuth, OIDC)

## Data Flow

### Create Post Flow

```
User clicks "Submit" in portal
        │
        ▼
Component calls createPostFn()
        │
        ▼
Server function validates input with Zod
        │
        ▼
requireAuth() checks session
        │
        ▼
createPost() service function
        │
        ▼
Insert into database via Drizzle
        │
        ▼
dispatchPostCreated() event
        │
        ▼
processEvent() runs hooks (async)
        │
        ├──▶ Slack notification
        ├──▶ Email to subscribers
        └──▶ AI sentiment analysis
        │
        ▼
Return post to client
        │
        ▼
React Query updates cache
```

## Deployment

Quackback runs as a single workspace per deployment:
- `DATABASE_URL` environment variable
- Singleton database connection
- No tenant resolution needed

## Next Steps

- [Server Functions](/docs/developers/server-functions) - Deep dive into RPC patterns
- [Database](/docs/developers/database) - Schema and migrations
- [Adding Features](/docs/developers/adding-features) - Build new functionality

- [Contribute to Quackback](https://quackback.io/docs/developers/contributing): Submit bug reports, features, and code to the project.

# Contribute to Quackback

Help us build something great. Whether you're fixing a bug, adding a feature, or improving docs, this guide shows you how to contribute effectively and get your changes merged.

## Ways to Contribute

- **Bug reports** - Found a bug? Open an issue
- **Feature requests** - Have an idea? Start a discussion
- **Code contributions** - Fix bugs or add features
- **Documentation** - Improve guides and API docs
- **Translations** - Help localize the platform

## Get started

### 1. Fork the Repository

Click "Fork" on GitHub to create your own copy.

### 2. Clone Your Fork

```bash
git clone https://github.com/YOUR_USERNAME/quackback.git
cd quackback
```

### 3. Set Up Development Environment

```bash
bun run setup
bun run dev
```

See [Development Setup](/docs/developers/setup) for detailed instructions.

### 4. Create a Branch

```bash
git checkout -b feature/your-feature-name
# or
git checkout -b fix/issue-description
```

## Make changes

### Code Style

We use:
- **ESLint** for code linting
- **Prettier** for formatting
- **TypeScript** for type safety

Run checks before committing:

```bash
bun run lint
```

For type checking (in apps/web):
```bash
cd apps/web && bun run typecheck
```

### Naming Conventions

| Type | Convention | Example |
|------|------------|---------|
| Files | kebab-case | `user-profile.tsx` |
| Components | PascalCase | `UserProfile` |
| Functions | camelCase | `getUserProfile` |
| Database | snake_case | `post_tags` |

### Component Guidelines

- Use React Server Components by default
- Add `'use client'` only when needed (hooks, browser APIs)
- Keep components focused and small
- Extract complex logic to hooks or utilities

### Database Changes

When modifying the schema:

1. Edit files in `packages/db/src/schema/`
2. Generate migration: `bun run db:generate`
3. Test migration: `bun run db:migrate`
4. Verify with Drizzle Studio: `bun run db:studio`

## Testing

### Run Tests

```bash
# Unit tests
bun run test

# E2E tests
bun run test:e2e

# Specific test file
bun run test path/to/test.ts
```

### Write tests

Unit tests go in `__tests__` directories next to the code they test:
```
packages/ids/src/
├── core.ts
└── __tests__/
    └── core.test.ts
```

E2E tests are in `apps/web/e2e/`.

### Test Coverage

Aim for meaningful test coverage:
- Critical business logic
- Edge cases
- Error handling

## Submit changes

### 1. Commit Your Changes

Write clear commit messages:

```bash
# Good
git commit -m "fix: prevent duplicate votes on same post"
git commit -m "feat: add CSV export for posts"

# Bad
git commit -m "fixed stuff"
git commit -m "wip"
```

Follow conventional commits:
- `feat:` - New feature
- `fix:` - Bug fix
- `docs:` - Documentation
- `refactor:` - Code refactoring
- `test:` - Adding tests
- `chore:` - Maintenance

### 2. Push to Your Fork

```bash
git push origin feature/your-feature-name
```

### 3. Create a Pull Request

1. Go to the main Quackback repository
2. Click "Compare & pull request"
3. Fill in the PR template:
   - Description of changes
   - Related issues
   - Screenshots (if UI changes)
   - Testing done

### PR Guidelines

- Keep PRs focused on a single change
- Include tests for new functionality
- Update documentation if needed
- Respond to review feedback promptly

## Review Process

1. **Automated checks** - CI runs tests and linting
2. **Code review** - Maintainers review your code
3. **Feedback** - Address any requested changes
4. **Merge** - Once approved, your PR is merged

### What Reviewers Look For

- Code quality and readability
- Test coverage
- Performance implications
- Security considerations
- Documentation updates

## Contributor License Agreement

By contributing, you agree that your contributions will be licensed under the project's AGPL-3.0 license.

For substantial contributions, you may be asked to sign a CLA (Contributor License Agreement).

## Community Guidelines

### Be Respectful

- Treat everyone with respect
- Be constructive in feedback
- Welcome newcomers
- Assume good intentions

### Communication

- **GitHub Issues** - Bug reports and feature requests
- **GitHub Discussions** - Questions and ideas
- **Pull Requests** - Code contributions

### Getting Help

Stuck on something?

1. Check existing documentation
2. Search closed issues and PRs
3. Ask in GitHub Discussions
4. Open an issue with details

## License

Quackback is licensed under **AGPL-3.0**. Contributions go under the same license.

## Recognition

Contributors are recognized in:
- CONTRIBUTORS file
- Release notes for significant contributions
- Project documentation

Thank you for contributing to Quackback!

## Next Steps

- [Development Setup](/docs/developers/setup) - Get your environment ready
- [Architecture](/docs/developers/architecture) - Understand the codebase
- [Adding Features](/docs/developers/adding-features) - Build something new

- [Database](https://quackback.io/docs/developers/database): Work with PostgreSQL, Drizzle ORM, and TypeIDs.

# Database

Master the data layer. This guide covers how Quackback uses PostgreSQL with Drizzle ORM, from querying data to creating migrations to understanding TypeIDs.

## Overview

Quackback uses:
- **PostgreSQL 18+** as the database
- **Drizzle ORM** for type-safe queries
- **TypeIDs** for branded identifiers
- **pgvector** for semantic search
- **pg_cron** for scheduled jobs

## Schema Location

Database schema is defined in `packages/db/src/schema/`:

```
packages/db/src/schema/
├── index.ts              # Barrel export
├── auth.ts               # Users, sessions, members, OAuth
├── posts.ts              # Posts, comments, votes, tags
├── boards.ts             # Boards, roadmaps, tags
├── statuses.ts           # Post statuses
├── integrations.ts       # Integration configs
├── notifications.ts      # Notifications, subscriptions
├── sentiment.ts          # AI sentiment data
├── merge-suggestions.ts  # AI duplicate detection
├── feedback.ts           # Feedback pipeline (sources, signals)
├── segments.ts           # User segments
├── user-attributes.ts    # Custom user attributes
├── changelog.ts          # Changelog entries
├── api-keys.ts           # API key management
├── webhooks.ts           # Webhook configurations
└── external-links.ts     # External link tracking
```

## Core Tables

### Users & Authentication

```typescript
// users - Portal users
users: {
  id: UserId,
  email: string,
  name: string | null,
  image: string | null,
  createdAt: timestamp,
}

// members - Team members (admins, staff)
members: {
  id: MemberId,
  userId: UserId,
  workspaceId: WorkspaceId,
  role: 'admin' | 'member',
  createdAt: timestamp,
}
```

### Posts & Feedback

```typescript
// posts - User feedback
posts: {
  id: PostId,
  title: string,
  content: string | null,
  contentJson: jsonb | null,      // Tiptap rich text
  boardId: BoardId,
  statusId: StatusId,
  authorId: UserId | null,
  authorMemberId: MemberId | null,
  voteCount: integer,
  commentCount: integer,
  searchVector: tsvector,          // Full-text search
  createdAt: timestamp,
  updatedAt: timestamp,
  deletedAt: timestamp | null,
}

// votes
votes: {
  id: VoteId,
  postId: PostId,
  userId: UserId,
  createdAt: timestamp,
}

// comments
comments: {
  id: CommentId,
  postId: PostId,
  parentId: CommentId | null,      // Nested comments
  content: string,
  authorId: UserId | null,
  authorMemberId: MemberId | null,
  isPinned: boolean,               // Official response
  createdAt: timestamp,
  deletedAt: timestamp | null,
}
```

### Organization

```typescript
// boards
boards: {
  id: BoardId,
  name: string,
  slug: string,
  description: string | null,
  access: BoardAccess,  // per-action permissions matrix, see below
  createdAt: timestamp,
  deletedAt: timestamp | null,
}

// BoardAccess (jsonb column)
// Each action has its own tier; per-action segment allowlists apply
// wherever a tier is 'segments'. Moderation is tri-state per board.
type AccessTier = 'anonymous' | 'authenticated' | 'segments' | 'team'
type ModerationRule = 'inherit' | 'on' | 'off'

interface BoardAccess {
  view: AccessTier
  vote: AccessTier
  comment: AccessTier
  submit: AccessTier
  segments: {
    view: SegmentId[]
    vote: SegmentId[]
    comment: SegmentId[]
    submit: SegmentId[]
  }
  moderation: {
    anonPosts: ModerationRule
    signedPosts: ModerationRule
    comments: ModerationRule
  }
}

// statuses
statuses: {
  id: StatusId,
  name: string,
  slug: string,
  color: string,
  showOnRoadmap: boolean,
  order: integer,
}

// tags
tags: {
  id: TagId,
  name: string,
  color: string,
}

// post_tags (junction table)
postTags: {
  postId: PostId,
  tagId: TagId,
}
```

## Database Access

### Importing

```typescript
// ✅ Correct

// ❌ Wrong - bypasses tenant context

```

### Basic Queries

```typescript
// Select with conditions
const post = await db.query.posts.findFirst({
  where: eq(posts.id, postId),
})

// Select with relations
const postWithBoard = await db.query.posts.findFirst({
  where: eq(posts.id, postId),
  with: {
    board: true,
    status: true,
    tags: true,
  },
})

// List with filtering
const feedbackPosts = await db.query.posts.findMany({
  where: and(
    eq(posts.boardId, boardId),
    eq(posts.statusId, statusId),
    isNull(posts.deletedAt),
  ),
  orderBy: desc(posts.createdAt),
  limit: 20,
})
```

### Insert

```typescript

const [newPost] = await db.insert(posts).values({
  id: createId('post'),
  title: input.title,
  content: input.content,
  boardId: input.boardId,
  statusId: defaultStatusId,
  authorId: user.id,
}).returning()
```

### Update

```typescript
await db.update(posts)
  .set({
    statusId: newStatusId,
    updatedAt: new Date(),
  })
  .where(eq(posts.id, postId))
```

### Delete (Soft Delete)

```typescript
// Soft delete - preserve data
await db.update(posts)
  .set({ deletedAt: new Date() })
  .where(eq(posts.id, postId))

// Hard delete - remove permanently
await db.delete(votes)
  .where(eq(votes.postId, postId))
```

## TypeIDs

All entities use branded TypeIDs:

```typescript

// Generate new ID
const id: PostId = createId('post')
// => "post_01h455vb4pex5vsknk084sn02q"

// Column definition in schema

  // Primary key with auto-generated TypeID
  id: typeIdWithDefault('post')('id').primaryKey(),
  // Foreign key column
  boardId: typeIdColumn('board')('board_id').references(() => boards.id),
})
```

Benefits:
- Type safety (can't mix PostId with BoardId)
- Self-describing (prefix shows entity type)
- Sortable (timestamp-based UUIDs)

## Migrations

### Generate Migration

After changing schema files:

```bash
bun run db:generate
```

Creates a migration in `packages/db/drizzle/`.

### Run Migrations

```bash
bun run db:migrate
```

Migrations run automatically on deployment.

### Migration Best Practices

1. **One change per migration** - Easier to debug
2. **Test rollback** - Ensure reversibility
3. **Non-breaking changes** - Add columns as nullable first
4. **Data migrations** - Handle existing data carefully

## Full-Text Search

Posts support full-text search via `tsvector`:

```typescript
// Schema includes search vector

  // ...
  searchVector: tsvector('search_vector'),
})

// Search query
const results = await db.query.posts.findMany({
  where: sql`search_vector @@ plainto_tsquery(${searchTerm})`,
})
```

The search vector is updated automatically via database trigger.

## Vector Search (pgvector)

Semantic search using embeddings:

```typescript
// Store embedding
await db.update(postEmbeddings)
  .set({ embedding: vector })
  .where(eq(postEmbeddings.postId, postId))

// Find similar posts
const similar = await db.execute(sql`
  SELECT id, title, 1 - (embedding <=> ${queryVector}) as similarity
  FROM post_embeddings
  ORDER BY embedding <=> ${queryVector}
  LIMIT 5
`)
```

## Transactions

For atomic operations:

```typescript
await db.transaction(async (tx) => {
  // All operations use `tx` instead of `db`
  await tx.insert(posts).values(postData)
  await tx.insert(postTags).values(tagData)

  // If any fails, all are rolled back
})
```

## Relations

Define relations in schema:

```typescript

  board: one(boards, {
    fields: [posts.boardId],
    references: [boards.id],
  }),
  status: one(statuses, {
    fields: [posts.statusId],
    references: [statuses.id],
  }),
  comments: many(comments),
  votes: many(votes),
  tags: many(postTags),
}))
```

Query with relations:

```typescript
const post = await db.query.posts.findFirst({
  where: eq(posts.id, postId),
  with: {
    board: true,
    status: true,
    comments: {
      where: isNull(comments.deletedAt),
      orderBy: desc(comments.createdAt),
    },
  },
})
```

## Drizzle Studio

Visual database browser:

```bash
bun run db:studio
```

Features:
- Browse tables
- Edit data
- Run queries
- View relations

## Seeding

Demo data for development:

```bash
bun run db:seed
```

Seed file: `packages/db/src/seed.ts`

Creates:
- Demo workspace
- Sample boards and statuses
- Example posts and comments
- Demo user accounts

## Best Practices

### Query Optimization

```typescript
// ✅ Select only needed columns
const titles = await db
  .select({ id: posts.id, title: posts.title })
  .from(posts)

// ❌ Avoid selecting everything
const allData = await db.select().from(posts)
```

### Indexes

Add indexes for frequently queried columns:

```typescript

  .on(posts.statusId)

  .on(posts.createdAt)
```

### Soft Deletes

Always check for `deletedAt`:

```typescript
const activePosts = await db.query.posts.findMany({
  where: isNull(posts.deletedAt),
})
```

## Next Steps

- [Architecture](/docs/developers/architecture) - System overview
- [Server Functions](/docs/developers/server-functions) - API patterns
- [Adding Features](/docs/developers/adding-features) - Build new functionality

- [Server Functions](https://quackback.io/docs/developers/server-functions): Type-safe RPC endpoints. The bridge between your React components and backend logic.

# Server Functions

Type-safe from frontend to backend. Server functions let you call backend logic from React components with full TypeScript support, automatic validation, and built-in authentication checks.

## Overview

Quackback uses [TanStack Start's server functions](https://tanstack.com/start/latest/docs/framework/react/start/server-functions) to create backend endpoints. Server functions are:

- **Type-safe**: Input and output types are inferred and enforced at compile time
- **Co-located**: Define backend logic alongside the components that use it
- **Validated**: Built-in support for Zod schema validation
- **Secure**: Authentication and authorization checks are easy to implement

## Create a server function

Server functions are located in `apps/web/src/lib/server/functions/`. Each file typically groups related operations (e.g., `posts.ts`, `boards.ts`, `comments.ts`).

### Basic Structure

```typescript

// 1. Define the input schema with Zod
const createPostSchema = z.object({
  title: z.string().min(1, 'Title is required').max(200),
  content: z.string().min(1, 'Description is required').max(10000),
  boardId: z.string(),
})

// 2. Export the type for use in components

// 3. Create the server function

  .inputValidator(createPostSchema)
  .handler(async ({ data }) => {
    // 4. Check authentication
    const auth = await requireAuth({ roles: ['admin', 'member'] })

    // 5. Implement business logic
    const result = await createPost(data, auth.member)

    // 6. Return the result
    return result
  })
```

### GET vs POST Methods

Use `GET` for read operations and `POST` for write operations:

```typescript
// Read operation - GET method

  .handler(async () => {
    await requireAuth({ roles: ['admin', 'member'] })
    return await listBoards()
  })

// Write operation - POST method

  .inputValidator(deleteBoardSchema)
  .handler(async ({ data }) => {
    await requireAuth({ roles: ['admin', 'member'] })
    await deleteBoard(data.id as BoardId)
    return { id: data.id }
  })
```

## Validation with Zod

All server function inputs should be validated using Zod schemas. This provides:

- Runtime validation of incoming data
- Type inference for TypeScript
- Automatic error messages for invalid input

### Schema Patterns

```typescript
// Simple schema
const getBoardSchema = z.object({
  id: z.string(),
})

// Schema with validation rules. Note: board access (the per-action
// View/Vote/Comment/Submit tier matrix) is set separately via
// `updateBoardAccessFn` after creation — see
// apps/web/src/lib/server/functions/boards.ts.
const createBoardSchema = z.object({
  name: z
    .string()
    .min(1, 'Board name is required')
    .max(100, 'Board name must be 100 characters or less'),
  description: z.string().max(500).optional(),
  preset: z.enum(['public', 'private']).default('public'),  // seeds the access matrix
})

// Schema with complex types
const listPostsSchema = z.object({
  boardIds: z.array(z.string()).optional(),
  statusIds: z.array(z.string()).optional(),
  search: z.string().optional(),
  sort: z.enum(['newest', 'oldest', 'votes']).optional().default('newest'),
  page: z.number().int().min(1).optional().default(1),
  limit: z.number().int().min(1).max(100).optional().default(20),
})

// Schema with nullable fields
const updatePostSchema = z.object({
  id: z.string(),
  title: z.string().min(1).max(200).optional(),
  content: z.string().max(10000).optional(),
  ownerId: z.string().nullable().optional(),
})
```

### Use inputValidator

The `inputValidator` method validates input before the handler runs:

```typescript

  .inputValidator(updateBoardSchema)
  .handler(async ({ data }) => {
    // data is fully typed and validated
    // TypeScript knows data.id is string, data.name is string | undefined, etc.
  })
```

## Authentication with requireAuth

The `requireAuth` helper in `server/functions/auth-helpers.ts` handles authentication and authorization:

### Require any team member

```typescript
// Require authentication (any role)
const auth = await requireAuth()
```

### Require specific roles

```typescript
// Require admin or member role
const auth = await requireAuth({ roles: ['admin', 'member'] })

// Require admin only
const auth = await requireAuth({ roles: ['admin'] })

// Allow all authenticated users including portal users
const auth = await requireAuth({ roles: ['admin', 'member', 'user'] })
```

### AuthContext Structure

The `requireAuth` function returns an `AuthContext` object:

```typescript
interface AuthContext {
  settings: {
    id: WorkspaceId
    slug: string
    name: string
  }
  user: {
    id: UserId
    email: string
    name: string
    image: string | null
  }
  member: {
    id: MemberId
    role: Role  // 'admin' | 'member' | 'user'
  }
}
```

### Optional Authentication

For public endpoints that behave differently for logged-in users, use `getOptionalAuth`:

```typescript

  .inputValidator(getCommentPermissionsSchema)
  .handler(async ({ data }) => {
    // Early bailout: no session cookie = no permissions
    if (!hasSessionCookie()) {
      return { canEdit: false, canDelete: false }
    }

    const ctx = await getOptionalAuth()
    if (!ctx?.member) {
      return { canEdit: false, canDelete: false }
    }

    // Check permissions for authenticated user
    return await checkPermissions(data.commentId, ctx.member)
  })
```

## Error Handling

Server functions use typed domain exceptions for error handling. Import these from `@/lib/shared/errors`:

```typescript

  const post = await db.query.posts.findFirst({
    where: eq(posts.id, id),
  })

  if (!post) {
    throw new NotFoundError('POST_NOT_FOUND', 'Post not found')
  }

  return post
}

  if (actor.role !== 'admin') {
    throw new ForbiddenError('NOT_ALLOWED', 'Only admins can delete posts')
  }

  await db.delete(posts).where(eq(posts.id, id))
}
```

### Error Classes

| Class | HTTP Status | Use Case |
|-------|-------------|----------|
| `NotFoundError` | 404 | Resource not found |
| `ValidationError` | 400 | Invalid input data |
| `ForbiddenError` | 403 | Permission denied |
| `ConflictError` | 409 | Duplicate resource, already exists |
| `InternalError` | 500 | Database or unexpected errors |

### Log errors

Add logging to track errors in production:

```typescript

  .inputValidator(createPostSchema)
  .handler(async ({ data }) => {
    console.log(`[fn:posts] createPostFn: boardId=${data.boardId}`)
    try {
      const auth = await requireAuth({ roles: ['admin', 'member'] })
      const result = await createPost(data, auth.member)
      console.log(`[fn:posts] createPostFn: id=${result.id}`)
      return result
    } catch (error) {
      console.error(`[fn:posts] createPostFn failed:`, error)
      throw error
    }
  })
```

## Client-Side Usage

Server functions are called from React components using TanStack Query for data fetching and caching.

### Queries (Reading Data)

```typescript

  return useQuery({
    queryKey: ['boards'],
    queryFn: () => fetchBoards(),
    staleTime: 30 * 1000, // Cache for 30 seconds
  })
}
```

### Mutations (Writing Data)

```typescript

  const queryClient = useQueryClient()

  return useMutation({
    mutationFn: (input: CreateBoardInput) => createBoardFn({ data: input }),
    onSuccess: () => {
      // Invalidate cache to refetch boards
      queryClient.invalidateQueries({ queryKey: ['boards'] })
    },
  })
}
```

### Use in components

```typescript
function BoardList() {
  const { data: boards, isLoading } = useBoardsQuery()
  const createBoard = useCreateBoard()

  if (isLoading) return <div>Loading...</div>

  return (
    <div>
      {boards?.map((board) => (
        
      ))}
      <button
        onClick={() => createBoard.mutate({ name: 'New Board' })}
        disabled={createBoard.isPending}
      >
        {createBoard.isPending ? 'Creating...' : 'Create Board'}
      </button>
    </div>
  )
}
```

### Query Hook Patterns

Quackback organizes query/mutation hooks in `apps/web/src/lib/client/hooks/` and mutations in `apps/web/src/lib/client/mutations/`. Here's a typical pattern:

```typescript
// apps/web/src/lib/client/mutations/portal-post-actions.ts

// Query key factory for consistent cache invalidation

  all: ['post-actions'] as const,
  permissions: () => [...postActionKeys.all, 'permissions'] as const,
  permission: (postId: PostId) => [...postActionKeys.permissions(), postId] as const,
}

// Query hook

  return useQuery({
    queryKey: postActionKeys.permission(postId),
    queryFn: async () => {
      try {
        return await getPostPermissionsFn({ data: { postId } })
      } catch {
        return { canEdit: false, canDelete: false }
      }
    },
    enabled,
    staleTime: 30 * 1000,
  })
}

// Mutation hook

  const queryClient = useQueryClient()
  const navigate = useNavigate()

  const editMutation = useMutation({
    mutationFn: (input: EditPostInput) =>
      userEditPostFn({ data: { postId, ...input } }),
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: postActionKeys.permission(postId) })
      onEditSuccess?.()
    },
  })

  const deleteMutation = useMutation({
    mutationFn: () => userDeletePostFn({ data: { postId } }),
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ['portal', 'posts'] })
      navigate({ to: '/', search: { board: boardSlug } })
      onDeleteSuccess?.()
    },
  })

  return {
    editPost: editMutation.mutate,
    deletePost: deleteMutation.mutate,
    isEditing: editMutation.isPending,
    isDeleting: deleteMutation.isPending,
    editError: editMutation.error,
    deleteError: deleteMutation.error,
  }
}
```

## Date Serialization

When returning dates from server functions, serialize them to ISO strings. This ensures consistent behavior across different database drivers:

```typescript
function toIsoString(value: Date | string): string {
  if (typeof value === 'string') {
    return value // Already an ISO string
  }
  return value.toISOString()
}

function toIsoStringOrNull(value: Date | string | null | undefined): string | null {
  if (value == null) return null
  return toIsoString(value)
}

// Use in handler

  .inputValidator(getPostSchema)
  .handler(async ({ data }) => {
    const post = await getPost(data.id as PostId)
    return {
      ...post,
      createdAt: toIsoString(post.createdAt),
      updatedAt: toIsoString(post.updatedAt),
      deletedAt: toIsoStringOrNull(post.deletedAt),
    }
  })
```

## File Organization

Server functions are organized by domain in `apps/web/src/lib/server/functions/`:

```
server/functions/
  auth.ts              # Authentication functions
  auth-helpers.ts      # requireAuth, getOptionalAuth helpers
  boards.ts            # Board CRUD operations
  posts.ts             # Post CRUD operations (admin)
  public-posts.ts      # Post operations (public portal)
  comments.ts          # Comment operations
  statuses.ts          # Status management
  tags.ts              # Tag management
  settings.ts          # Workspace settings
  workspace.ts         # Workspace utilities
  notifications.ts     # Notification operations
  subscriptions.ts     # Post subscription operations
  integrations.ts      # Integration management
  roadmaps.ts          # Roadmap operations
  user.ts              # User profile operations
  api-keys.ts          # API key management
  changelog.ts         # Changelog operations
  webhooks.ts          # Webhook management
  uploads.ts           # File upload operations
  onboarding.ts        # Setup wizard
  invitations.ts       # Team invitations
```

## Best Practices

1. **Always validate input** - Use Zod schemas for all server function inputs
2. **Check authentication first** - Call `requireAuth()` at the start of handlers that need auth
3. **Use appropriate HTTP methods** - GET for reads, POST for writes
4. **Log operations** - Add console.log statements for debugging
5. **Handle errors gracefully** - Wrap handlers in try/catch when needed
6. **Serialize dates** - Convert Date objects to ISO strings for responses
7. **Export types** - Export input types for use in components
8. **Keep handlers thin** - Delegate complex logic to service functions in `@/lib/server/domains/\{feature\}/`

## Related Documentation

- [Architecture Overview](./architecture.md) - System architecture and design patterns
- [Database](./database.md) - Database schema and Drizzle ORM usage
- [Testing](./testing.md) - Testing server functions and E2E tests

- [Set up local development](https://quackback.io/docs/developers/setup): Get Quackback running locally for development.

# Set up local development

Start building in minutes. One command sets up everything: installs dependencies, configures the database, and runs migrations. Then you're ready to develop.

## Prerequisites

| Requirement | Version | Purpose |
|-------------|---------|---------|
| Bun | 1.3.7+ | Runtime and package manager |
| Docker | 20.10+ | PostgreSQL 18+ database |
| Git | 2.30+ | Version control |
| Node.js | 20+ | Optional, for some tooling |

### Install Bun

```bash
# macOS/Linux
curl -fsSL https://bun.sh/install | bash

# Windows (WSL)
curl -fsSL https://bun.sh/install | bash
```

### Install Docker

- **macOS**: [Docker Desktop for Mac](https://docs.docker.com/desktop/install/mac-install/)
- **Linux**: [Docker Engine](https://docs.docker.com/engine/install/)
- **Windows**: [Docker Desktop with WSL 2](https://docs.docker.com/desktop/install/windows-install/)

## Quick Setup

The fastest way to get started:

```bash
# Clone the repository
git clone https://github.com/quackbackio/quackback.git
cd quackback

# Run automated setup
bun run setup
```

The setup script:
1. Checks for Bun and Docker
2. Installs dependencies
3. Creates `.env` from template
4. Generates auth secret
5. Starts PostgreSQL container
6. Runs database migrations

## Manual Setup

If you prefer manual setup:

### 1. Install Dependencies

```bash
bun install
```

### 2. Configure Environment

```bash
cp .env.example .env
```

Generate a secret:
```bash
openssl rand -base64 32
```

Edit `.env`:
```bash
DATABASE_URL="postgresql://postgres:password@localhost:5432/quackback"
SECRET_KEY="your-generated-secret-here"
BASE_URL="http://localhost:3000"
REDIS_URL="redis://localhost:6379"
```

### 3. Start PostgreSQL

```bash
docker compose up -d postgres
```

Wait for it to be healthy:
```bash
docker compose ps  # Should show "healthy"
```

### 4. Run Migrations

```bash
bun run db:migrate
```

### 5. Seed Demo Data (Optional)

```bash
bun run db:seed
```

This creates a demo workspace with sample data.

## Start Development Server

```bash
bun run dev
```

Open [http://localhost:3000](http://localhost:3000).

### Demo Login

## Project Structure

```
quackback/
├── apps/web/                 # Main TanStack Start application
│   ├── src/
│   │   ├── routes/           # File-based routing
│   │   ├── components/       # React components
│   │   └── lib/              # Business logic & utilities
│   ├── e2e/                  # Playwright E2E tests
│   └── public/               # Static assets
│
├── packages/                 # Shared packages
│   ├── db/                   # Database schema & migrations
│   ├── ids/                  # TypeID system
│   ├── email/                # Email service & templates
│   ├── core/                 # Shared core utilities
│   └── integrations/         # Integration connectors
│
├── deploy/                   # Deployment configurations
├── scripts/                  # Utility scripts
└── docker-compose.yml        # Local development services
```

## Common Commands

```bash
# Development
bun run dev              # Start dev server
bun run build            # Production build

# Database
bun run db:generate      # Generate migration from schema changes
bun run db:migrate       # Run pending migrations
bun run db:studio        # Open Drizzle Studio (DB GUI)
bun run db:seed          # Seed demo data
bun run db:reset         # Reset database (destructive!)

# Code Quality
bun run lint             # ESLint + Prettier check

# Testing
bun run test             # Run Vitest tests
bun run test <file>      # Run single test file
bun run test:e2e         # Playwright E2E tests
cd apps/web && bun run test:e2e:ui   # E2E with interactive UI
```

## IDE Setup

### VS Code

Recommended extensions:
- ESLint
- Prettier
- Tailwind CSS IntelliSense

Settings (`.vscode/settings.json`):
```json
{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}
```

### Other IDEs

The project uses:
- ESLint for linting
- Prettier for formatting
- TypeScript for type checking

Configure your IDE to use these tools.

## Database Management

### Drizzle Studio

Visual database browser:

```bash
bun run db:studio
```

Opens at [https://local.drizzle.studio](https://local.drizzle.studio).

### Direct Access

Connect via psql:

```bash
docker compose exec postgres psql -U postgres quackback
```

Or use any PostgreSQL client with:
- Host: `localhost`
- Port: `5432`
- User: `postgres`
- Password: `password`
- Database: `quackback`

### Reset Database

Wipe everything and start fresh:

```bash
bun run db:reset
```

## Troubleshooting

### Port Already in Use

```bash
# Find process on port 3000
lsof -i :3000

# Kill it
kill -9 

# Or use a different port
PORT=3001 bun run dev
```

### Database Connection Failed

```bash
# Check if PostgreSQL is running
docker compose ps

# Restart it
docker compose restart postgres

# Check logs
docker compose logs postgres
```

### Migrations Failed

```bash
# See detailed error
bun run db:migrate 2>&1

# Reset and retry
bun run db:reset
bun run db:migrate
```

### Dependencies Issues

```bash
# Clear and reinstall
rm -rf node_modules bun.lock
bun install
```

## Next Steps

- [Architecture](/docs/developers/architecture) - Understand the system design
- [Server Functions](/docs/developers/server-functions) - API development patterns
- [Testing](/docs/developers/testing) - Write and run tests
- [Contributing](/docs/developers/contributing) - Contribution guidelines

- [Write and run tests](https://quackback.io/docs/developers/testing): Write tests that catch bugs. Unit tests with Vitest, E2E tests with Playwright.

# Testing

Ship with confidence. Write unit tests to verify your logic works correctly, and E2E tests to ensure complete user flows don't break. Quackback uses Vitest and Playwright.

## Test Commands

Run tests using these commands from the project root:

```bash
# Unit tests (Vitest)
bun run test              # Run all unit tests
bun run test <file>       # Run a specific test file
bun run test --watch      # Watch mode for development

# E2E tests (Playwright)
bun run test:e2e          # Run all E2E tests (headless)
bun run test:e2e:ui       # Run with Playwright's interactive UI
bun run test:e2e:headed   # Run in headed browser mode
```

---

## Test with Vitest

Unit tests verify individual functions, modules, and utilities in isolation.

### Test File Locations

Unit tests are placed alongside the code they test or in `__tests__` directories:

```
packages/
  ids/
    src/
      __tests__/
        core.test.ts     # Tests for packages/ids/src/core.ts
        zod.test.ts      # Tests for packages/ids/src/zod.ts
```

### Vitest Configuration

The root `vitest.config.ts` configures the test environment:

```typescript

  test: {
    globals: true,              // Use global describe, it, expect
    environment: 'node',        // Node.js environment
    include: ['**/*.test.ts'],  // Test file pattern
    exclude: ['**/node_modules/**', '**/.next/**'],
    env: {
      DATABASE_URL: 'postgresql://postgres:password@localhost:5432/quackback_test',
    },
  },
  resolve: {
    alias: {
      '@quackback/db/client': path.resolve(__dirname, './packages/db/src/client.ts'),
      '@quackback/db/schema': path.resolve(__dirname, './packages/db/src/schema/index.ts'),
      '@quackback/db/catalog': path.resolve(__dirname, './packages/db/src/catalog/index.ts'),
      '@quackback/db/tenant': path.resolve(__dirname, './packages/db/src/tenant/index.ts'),
      '@quackback/db/types': path.resolve(__dirname, './packages/db/src/types.ts'),
      '@quackback/db': path.resolve(__dirname, './packages/db/index.ts'),
      '@': path.resolve(__dirname, './apps/web/src'),
    },
  },
})
```

### Write unit tests

Basic test structure:

```typescript

describe('TypeID Core', () => {
  describe('generateId', () => {
    it('generates a valid TypeID with the correct prefix', () => {
      const id = generateId('post')
      expect(id).toMatch(/^post_[0-7][0-9a-hjkmnp-tv-z]{25}$/)
    })

    it('generates unique IDs on each call', () => {
      const ids = new Set<string>()
      for (let i = 0; i < 1000; i++) {
        ids.add(generateId('post'))
      }
      expect(ids.size).toBe(1000)
    })
  })

  describe('round-trip conversion', () => {
    it('preserves ID through UUID round-trip', () => {
      const original = generateId('post')
      const uuid = toUuid(original)
      const restored = fromUuid('post', uuid)
      expect(restored).toBe(original)
    })
  })
})
```

### Test error cases

```typescript
describe('toUuid', () => {
  it('throws on invalid TypeID format', () => {
    expect(() => toUuid('invalid')).toThrow()
    expect(() => toUuid('post_invalid')).toThrow()
    expect(() => toUuid('')).toThrow()
  })
})

describe('fromUuid', () => {
  it('throws on invalid UUID format', () => {
    expect(() => fromUuid('post', 'invalid')).toThrow('Invalid UUID format')
    expect(() => fromUuid('post', '01893d8c-7e80-7000')).toThrow()
  })
})
```

---

## Test with Playwright

E2E tests verify complete user flows through the browser.

### Test File Structure

E2E tests are in `apps/web/e2e/`:

```
apps/web/e2e/
  tests/
    admin/                    # Tests requiring admin authentication
      boards.spec.ts          # Board management tests
      post-management.spec.ts # Admin post operations
      statuses.spec.ts        # Status configuration tests
      users.spec.ts           # User management tests
    auth/                     # Authentication flow tests
      admin-login.spec.ts     # Admin login tests
    public/                   # Public portal tests (no auth needed)
      comments.spec.ts        # Comment functionality
      post-list.spec.ts       # Post listing and filtering
      post-submission.spec.ts # Creating new posts
      voting.spec.ts          # Voting functionality
  fixtures/
    auth.ts                   # Test fixtures and credentials
  utils/
    helpers.ts                # Reusable test utilities
    db-helpers.ts             # Database utilities for tests
  scripts/
    get-otp.ts                # Script to fetch OTP codes
    ensure-role.ts            # Script to ensure user roles
  global-setup.ts             # Runs before all tests
  global-teardown.ts          # Runs after all tests
```

### Playwright Configuration

`apps/web/playwright.config.ts` configures test projects:

```typescript

  testDir: './e2e',
  fullyParallel: true,
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 1 : undefined,

  use: {
    baseURL: 'http://acme.localhost:3000',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
  },

  projects: [
    // Setup project - authenticates and saves state
    {
      name: 'setup',
      testMatch: /global-setup\.ts/,
      teardown: 'cleanup',
    },
    {
      name: 'cleanup',
      testMatch: /global-teardown\.ts/,
    },

    // Admin tests - uses saved auth state
    {
      name: 'chromium',
      use: {
        ...devices['Desktop Chrome'],
        viewport: { width: 1920, height: 1080 },
        storageState: 'e2e/.auth/admin.json',
      },
      dependencies: ['setup'],
      testMatch: /tests\/admin\/.+\.spec\.ts/,
    },

    // Auth tests - no stored state
    {
      name: 'chromium-auth',
      use: { ...devices['Desktop Chrome'] },
      testMatch: /tests\/auth\/.+\.spec\.ts/,
    },

    // Public tests - no authentication needed
    {
      name: 'chromium-public',
      use: { ...devices['Desktop Chrome'] },
      testMatch: /tests\/public\/.+\.spec\.ts/,
    },
  ],

  webServer: {
    command: 'bun run dev',
    url: 'http://acme.localhost:3000',
    reuseExistingServer: !process.env.CI,
    timeout: 120 * 1000,
  },

  timeout: 30 * 1000,
  expect: { timeout: 5 * 1000 },
})
```

### Authentication in Tests

#### Global Setup

The `global-setup.ts` authenticates once and saves the session:

```typescript

const ADMIN_EMAIL = 'demo@example.com'
const AUTH_FILE = 'e2e/.auth/admin.json'
const TEST_HOST = 'acme.localhost:3000'

setup('authenticate as admin', async ({ page }) => {
  const request = page.request

  // Request OTP code via Better-auth
  await request.post('/api/auth/email-otp/send-verification-otp', {
    data: { email: ADMIN_EMAIL, type: 'sign-in' },
  })

  // Get OTP from database
  const code = await getOtpCode(ADMIN_EMAIL, TEST_HOST)

  // Verify OTP and sign in
  await request.post('/api/auth/sign-in/email-otp', {
    data: { email: ADMIN_EMAIL, otp: code },
  })

  // Ensure admin role
  ensureTestUserHasRole(ADMIN_EMAIL, 'admin')

  // Navigate and verify
  await page.goto('/admin')
  await expect(page).toHaveURL(/\/admin/, { timeout: 10000 })

  // Save auth state
  await page.context().storageState({ path: AUTH_FILE })
})
```

#### Test-Level Authentication

For tests that need their own auth context:

```typescript

const TEST_EMAIL = 'demo@example.com'
const TEST_HOST = 'acme.localhost:3000'

test.describe.configure({ mode: 'serial' })

async function loginWithOTP(page: Page) {
  const context = page.context()

  // Request OTP
  await context.request.post('/api/auth/email-otp/send-verification-otp', {
    data: { email: TEST_EMAIL, type: 'sign-in' },
  })

  // Get and verify OTP
  const code = await getOtpCode(TEST_EMAIL, TEST_HOST)
  await context.request.post('/api/auth/sign-in/email-otp', {
    data: { email: TEST_EMAIL, otp: code },
  })

  // Navigate to verify
  await page.goto('/')
  await page.waitForLoadState('networkidle')
}

let globalContext: BrowserContext
let globalPage: Page

test.beforeAll(async ({ browser }) => {
  globalContext = await browser.newContext()
  globalPage = await globalContext.newPage()
  await loginWithOTP(globalPage)
})

test.afterAll(async () => {
  await globalPage.close()
  await globalContext.close()
})
```

### Write E2E tests

#### Basic Test Structure

```typescript

test.describe('Admin Board Management', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('/admin/settings/boards')
    await page.waitForLoadState('networkidle')
  })

  test('displays board settings page', async ({ page }) => {
    await expect(page.getByText('General Settings')).toBeVisible({ timeout: 10000 })
  })

  test('can edit board name', async ({ page }) => {
    const nameInput = page.getByRole('textbox', { name: 'Board name', exact: true })
    await nameInput.clear()
    await nameInput.fill('Test Board Name')

    const saveButton = page.getByRole('button', { name: 'Save changes' })
    await saveButton.click()
    await page.waitForLoadState('networkidle')
  })
})
```

#### Test forms

```typescript
test('can create a new board', async ({ page }) => {
  // Open dialog
  await page.getByRole('button', { name: 'New board' }).click()
  const dialog = page.getByRole('dialog')
  await expect(dialog).toBeVisible()

  // Fill form (scope selectors to dialog)
  const testBoardName = `E2E Test Board ${Date.now()}`
  await dialog.getByLabel('Board name').fill(testBoardName)
  await dialog.getByLabel('Description').fill('Board created by Playwright test')

  // Verify default state
  const publicSwitch = dialog.getByRole('switch', { name: 'Public board' })
  await expect(publicSwitch).toBeChecked()

  // Submit
  await dialog.getByRole('button', { name: 'Create board' }).click()
  await expect(dialog).toBeHidden({ timeout: 10000 })

  // Verify result
  await page.waitForLoadState('networkidle')
  await expect(page.getByTestId('board-switcher')).toContainText(testBoardName)
})
```

#### Test rich text editors (TipTap)

```typescript
test('can type in TipTap editor', async ({ page }) => {
  const editor = page.locator('.tiptap')
  await editor.click()
  await page.keyboard.type('This is plain text content')
  await expect(editor).toContainText('This is plain text content')
})

test('can format text as bold', async ({ page }) => {
  const editor = page.locator('.tiptap')
  await editor.click()
  await page.keyboard.type('bold text')

  // Select all and apply bold
  await editor.click({ clickCount: 3 })
  const boldButton = page.locator('button:has(svg.lucide-bold)')
  await boldButton.click()

  await expect(editor.locator('strong')).toContainText('bold text')
})
```

#### Serial Test Execution

For tests that must run in order or modify shared state:

```typescript
test.describe('Board Deletion Flow', () => {
  test.describe.configure({ mode: 'serial' })

  test('can delete a board after typing confirmation', async ({ page }) => {
    // Create board first
    await page.goto('/admin/settings/boards')
    const testBoardName = `Test Delete Board ${Date.now()}`
    // ... create board ...

    // Delete it
    const deleteButton = page.getByRole('button', { name: 'Delete board', exact: true })
    const confirmInput = page.getByPlaceholder(testBoardName)
    await confirmInput.fill(testBoardName)
    await deleteButton.click()

    await expect(page).toHaveURL(/\/admin\/settings\/boards/)
  })
})
```

### Test Utilities

#### Helper Functions (`utils/helpers.ts`)

```typescript

// Wait for toast notifications

  const toast = page.locator('[data-sonner-toast]').filter({ hasText: text })
  await expect(toast).toBeVisible({ timeout: 5000 })
  return toast
}

// Select from Radix Select component

  await page.getByRole('combobox', { name: triggerLabel }).click()
  await page.getByRole('option', { name: optionText }).click()
}

// Fill TipTap rich text editor

  const editor = page.locator('.ProseMirror[contenteditable="true"]')
  await editor.click()
  await editor.fill(content)
}

// Open and close dialogs

  await page.getByRole('button', { name: triggerText }).click()
  await expect(page.getByRole('dialog')).toBeVisible()
}

  await page.keyboard.press('Escape')
  await expect(page.getByRole('dialog')).toBeHidden()
}
```

#### Database Helpers (`utils/db-helpers.ts`)

```typescript

// Get OTP code for a user

  const scriptPath = resolve(__dirname, '../scripts/get-otp.ts')
  const result = execSync(
    `dotenv -e ../../.env -- bun "${scriptPath}" "${email}" "${host}"`,
    { encoding: 'utf-8', cwd: resolve(__dirname, '../..') }
  )
  return result.trim()
}

// Ensure user has the required role

  const scriptPath = resolve(__dirname, '../scripts/ensure-role.ts')
  execSync(
    `dotenv -e ../../.env -- bun "${scriptPath}" "${email}" "${role}"`,
    { encoding: 'utf-8', cwd: resolve(__dirname, '../..') }
  )
}
```

### Best Practices

#### Locator Strategies

```typescript
// Prefer role-based selectors
page.getByRole('button', { name: 'Save changes' })
page.getByRole('textbox', { name: 'Board name' })
page.getByRole('dialog')

// Use labels for form fields
page.getByLabel('Board name')
page.getByLabel('Description')

// Use placeholder for inputs
page.getByPlaceholder("What's your idea?")

// Use text content
page.getByText('General Settings')

// Use test IDs for complex cases
page.getByTestId('board-switcher')

// Scope to parent for disambiguation
const dialog = page.getByRole('dialog')
await dialog.getByLabel('Board name').fill('test')
```

#### Waiting Strategies

```typescript
// Wait for network to settle
await page.waitForLoadState('networkidle')

// Wait for elements
await expect(page.getByText('Success')).toBeVisible({ timeout: 10000 })

// Wait for URL changes
await expect(page).toHaveURL(/\/admin/, { timeout: 10000 })

// Wait for dialogs to close
await expect(page.getByRole('dialog')).toBeHidden({ timeout: 10000 })

// Wait for loading states
await expect(page.getByRole('button', { name: 'Saving...' })).toBeVisible()
await expect(page.getByRole('button', { name: 'Save changes' })).toBeVisible()
```

#### Unique Test Data

```typescript
// Use timestamps for unique names
const uniqueTitle = `E2E Test Post ${Date.now()}`
const testBoardName = `Test Board ${Date.now()}`
```

### Run tests

```bash
# All E2E tests
bun run test:e2e

# Specific test file
bunx playwright test e2e/tests/admin/boards.spec.ts

# Specific test
bunx playwright test -g "can create a new board"

# With UI mode (recommended for debugging)
bun run test:e2e:ui

# Headed mode (see browser)
bun run test:e2e:headed

# Debug mode
bunx playwright test --debug
```

### Debug tests

1. **Use UI mode**: `bun run test:e2e:ui` for interactive debugging
2. **Add screenshots**: Automatic on failure, or `await page.screenshot({ path: 'debug.png' })`
3. **Use traces**: `await page.context().tracing.start({ screenshots: true })`
4. **Console logs**: `console.log` in tests appears in terminal
5. **Slow down**: `slowMo: 100` in config for visual debugging

---

## Related Documentation

- [Server Functions](./server-functions.md) - Testing server function logic
- [Architecture](./architecture.md) - Understanding the codebase structure
- [Setup](./setup.md) - Setting up the development environment

- [CLI Reference](https://quackback.io/docs/reference/cli): Command reference for Quackback development and operations

# CLI Reference

Command reference for Quackback development and operations.

## Development Commands

### Start Development Server

```bash
bun run dev
```

Starts the development server at `http://localhost:3000`.

Options:
- Hot reloading enabled
- Source maps enabled
- OTP codes printed to console

### Build for Production

```bash
bun run build
```

Creates optimized production build in `.output/`.

### Preview Production Build

```bash
bun run preview
```

Preview the production build locally. Run from `apps/web/` directory.

### Start Production Server

```bash
bun run start
```

Starts the production server. Requires `bun run build` first. Run from `apps/web/` directory.

## Database Commands

### Run Migrations

```bash
bun run db:migrate
```

Applies pending database migrations. Safe to run multiple times.

### Generate Migration

```bash
bun run db:generate
```

Creates a new migration from schema changes. Run after modifying files in `packages/db/src/schema/`.

### Open Drizzle Studio

```bash
bun run db:studio
```

Opens visual database browser at `https://local.drizzle.studio`.

### Seed Demo Data

```bash
bun run db:seed
```

Populates database with demo workspace and sample data.

### Reset Database

```bash
bun run db:reset
```

## Code Quality

### Lint Code

```bash
bun run lint
```

Runs ESLint checks. Exits with error if issues found.

### Type Check

```bash
cd apps/web && bun run typecheck
```

Runs TypeScript compiler in check mode. No output if successful. Must be run from `apps/web/` directory.

### Generate Routes

```bash
cd apps/web && bun run generate:routes
```

Generates TanStack Router route definitions. Automatically run as part of typecheck.

## Testing

### Run Unit Tests

```bash
bun run test
```

Runs Vitest unit tests. By default runs in watch mode.

### Run Specific Test

```bash
bun run test path/to/test.ts
```

Runs a specific test file.

### E2E Tests

```bash
bun run test:e2e
```

Runs Playwright end-to-end tests in headless mode.

### E2E with UI

```bash
cd apps/web && bun run test:e2e:ui
```

Opens Playwright's interactive test UI. Must be run from `apps/web/` directory.

### E2E Headed

```bash
cd apps/web && bun run test:e2e:headed
```

Runs E2E tests in visible browser windows. Must be run from `apps/web/` directory.

## Setup & Utilities

### Initial Setup

```bash
bun run setup
```

One-time setup script:
1. Checks prerequisites
2. Installs dependencies
3. Creates `.env` from template
4. Generates auth secret
5. Starts PostgreSQL
6. Runs migrations

### Install Dependencies

```bash
bun install
```

Installs all project dependencies.

## Docker Commands

### Start Services

```bash
docker compose up -d
```

Starts PostgreSQL and application in background.

### View Logs

```bash
docker compose logs -f
```

Follow logs from all services.

```bash
docker compose logs app --tail 100
```

View last 100 lines from app service.

### Stop Services

```bash
docker compose down
```

Stops and removes containers (preserves volumes).

### Reset Everything

```bash
docker compose down -v
```

### Rebuild Images

```bash
docker compose build --no-cache
```

Rebuilds Docker images from scratch.

## Environment Variables

### Example

```bash
# Copy template
cp .env.example .env

# Generate secret
openssl rand -base64 32
```

## Data Import

### Import Data

```bash
bun run import
```

CLI tool for importing data from other feedback platforms.

### Import from UserVoice

```bash
bun run import:uservoice
```

Import data from UserVoice exports.

### Generate Sample CSV

```bash
bun run db:generate-csv
```

Generates sample CSV data for testing imports.

## AI Features

### Backfill AI Data

```bash
bun run ai:backfill
```

Backfill AI-generated data (embeddings, sentiment) for existing posts.

## Quick Reference

| Command | Description |
|---------|-------------|
| `bun run dev` | Start dev server |
| `bun run build` | Production build |
| `bun run db:migrate` | Run migrations |
| `bun run db:studio` | Database browser |
| `bun run db:seed` | Seed demo data |
| `bun run db:reset` | Reset database |
| `bun run lint` | Check code quality |
| `bun run test` | Run unit tests |
| `bun run test:e2e` | Run E2E tests |
| `bun run setup` | Initial setup |
| `bun run import` | Import data CLI |

## Troubleshooting

### Command Not Found

```bash
# Ensure Bun is installed
curl -fsSL https://bun.sh/install | bash

# Restart shell or source profile
source ~/.bashrc
```

### Permission Denied

```bash
# Fix script permissions
chmod +x scripts/*.sh
```

### Port in Use

```bash
# Find process
lsof -i :3000

# Kill it
kill -9 
```

## Next Steps

- [Development Setup](/docs/developers/setup) - Full setup guide
- [Environment Variables](/docs/reference/environment-variables) - Configuration
- [Docker Deployment](/docs/self-hosting/docker) - Production deployment

- [Database Schema](https://quackback.io/docs/reference/database-schema): Tables, columns, and relationships in the Quackback database.

# Database Schema

This document provides a comprehensive reference for the Quackback database schema. All tables use PostgreSQL with Drizzle ORM for type-safe database access.

## Overview

Quackback uses a PostgreSQL database with the following characteristics:

- **TypeIDs**: All primary keys use TypeID format (UUID storage with type-prefixed strings in the application layer, e.g., `post_01h455vb4pex5vsknk084sn02q`)
- **Timestamps**: All timestamp columns use `timestamp with time zone`
- **Soft deletes**: Most entity tables support soft deletion via `deleted_at` columns
- **Full-text search**: Posts have a generated `search_vector` column for PostgreSQL full-text search
- **Relational queries**: Drizzle relations enable type-safe joins and nested queries

## Table Categories

| Category | Tables |
|----------|--------|
| [Authentication](#authentication-tables) | user, session, account, verification, one_time_token, member, invitation, settings |
| [Content](#content-tables) | boards, posts, comments, votes, tags, post_tags, roadmaps, post_roadmaps |
| [Status & Workflow](#status--workflow-tables) | post_statuses |
| [History & Notes](#history--notes-tables) | post_edit_history, comment_edit_history, post_notes, comment_reactions |
| [Integrations](#integration-tables) | integrations, integration_platform_credentials, integration_event_mappings, post_external_links |
| [Notifications](#notification-tables) | in_app_notifications, post_subscriptions, notification_preferences, unsubscribe_tokens |
| [Changelog](#changelog-tables) | changelog_entries, changelog_entry_posts |
| [AI Features](#ai-feature-tables) | post_sentiment, merge_suggestions |
| [Feedback Pipeline](#feedback-pipeline-tables) | feedback_sources, raw_feedback_items, feedback_signals, feedback_suggestions, feedback_signal_corrections, external_user_mappings |
| [Segments](#segment-tables) | segments, user_segments, user_attribute_definitions |
| [API](#api-tables) | api_keys, webhooks |

---

## Authentication Tables

### user

User identities for the application. Managed by Better Auth with custom extensions.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (user) | PRIMARY KEY | Unique user identifier |
| `name` | text | NOT NULL | Display name |
| `email` | text | NOT NULL, UNIQUE | Email address |
| `email_verified` | boolean | NOT NULL, DEFAULT false | Email verification status |
| `image` | text | | Profile image URL |
| `image_key` | text | | S3 storage key for profile image |
| `metadata` | text | | General user metadata (JSON) |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

**Indexes:**
- `user_email_idx` (unique) on `email`

**Relations:**
- Has many: sessions, accounts, members, invitations

---

### session

User authentication sessions.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | text | PRIMARY KEY | Session identifier (Better Auth generated) |
| `expires_at` | timestamptz | NOT NULL | Session expiration time |
| `token` | text | NOT NULL, UNIQUE | Session token |
| `ip_address` | text | | Client IP address |
| `user_agent` | text | | Client user agent |
| `user_id` | TypeID (user) | NOT NULL, FK -> user.id ON DELETE CASCADE | Associated user |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL | Last update timestamp |

**Indexes:**
- `session_userId_idx` on `user_id`

**Relations:**
- Belongs to: user

---

### account

OAuth and authentication provider accounts.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (account) | PRIMARY KEY | Account identifier |
| `account_id` | text | NOT NULL | External account ID |
| `provider_id` | text | NOT NULL | Auth provider (google, github, etc.) |
| `user_id` | TypeID (user) | NOT NULL, FK -> user.id ON DELETE CASCADE | Associated user |
| `access_token` | text | | OAuth access token |
| `refresh_token` | text | | OAuth refresh token |
| `id_token` | text | | OAuth ID token |
| `access_token_expires_at` | timestamptz | | Access token expiration |
| `refresh_token_expires_at` | timestamptz | | Refresh token expiration |
| `scope` | text | | OAuth scopes |
| `password` | text | | Hashed password (for password auth) |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL | Last update timestamp |

**Indexes:**
- `account_userId_idx` on `user_id`

**Relations:**
- Belongs to: user

---

### verification

Email and other verification tokens.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | text | PRIMARY KEY | Verification identifier |
| `identifier` | text | NOT NULL | Target identifier (email, etc.) |
| `value` | text | NOT NULL | Verification code/token |
| `expires_at` | timestamptz | NOT NULL | Expiration time |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

**Indexes:**
- `verification_identifier_idx` on `identifier`

---

### one_time_token

Secure cross-domain session transfer tokens (used during workspace provisioning).

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | text | PRIMARY KEY | Token identifier |
| `token` | text | NOT NULL | One-time token value |
| `user_id` | TypeID (user) | NOT NULL, FK -> user.id ON DELETE CASCADE | Associated user |
| `expires_at` | timestamptz | NOT NULL | Expiration time |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |

**Relations:**
- Belongs to: user

---

### member

Unified membership records linking users to workspace roles.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (member) | PRIMARY KEY | Member identifier |
| `user_id` | TypeID (user) | NOT NULL, FK -> user.id ON DELETE CASCADE, UNIQUE | Associated user |
| `role` | text | NOT NULL, DEFAULT 'member' | Role: 'admin', 'member', or 'user' |
| `created_at` | timestamptz | NOT NULL | Creation timestamp |

**Role Descriptions:**
- `admin`: Full administrative access, can manage settings and team
- `member`: Team member access, can manage feedback
- `user`: Portal user access only, can vote/comment on public portal

**Indexes:**
- `member_user_idx` (unique) on `user_id`
- `member_role_idx` on `role`

**Relations:**
- Belongs to: user
- Has many: posts (as author), posts (as owner), comments, votes, post_subscriptions

---

### invitation

Team member invitations.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (invite) | PRIMARY KEY | Invitation identifier |
| `email` | text | NOT NULL | Invitee email address |
| `name` | text | | Invitee name |
| `role` | text | | Assigned role on acceptance |
| `status` | text | NOT NULL, DEFAULT 'pending' | Status: pending, accepted, expired |
| `expires_at` | timestamptz | NOT NULL | Expiration time |
| `last_sent_at` | timestamptz | | Last email sent timestamp |
| `inviter_id` | TypeID (user) | NOT NULL, FK -> user.id ON DELETE CASCADE | User who sent invitation |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |

**Indexes:**
- `invitation_email_idx` on `email`
- `invitation_email_status_idx` on `(email, status)`

**Relations:**
- Belongs to: user (inviter)

---

### settings

Application settings and branding configuration. Single row in self-hosted deployments.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (workspace) | PRIMARY KEY | Settings identifier |
| `name` | text | NOT NULL | Workspace/application name |
| `slug` | text | NOT NULL, UNIQUE | URL-safe identifier |
| `logo_key` | text | | S3 storage key for logo image |
| `favicon_key` | text | | S3 storage key for favicon |
| `header_logo_key` | text | | S3 storage key for header logo (horizontal wordmark) |
| `header_display_mode` | text | DEFAULT 'logo_and_name' | Header style: 'logo_and_name', 'logo_only', 'custom_logo' |
| `header_display_name` | text | | Custom header display name |
| `auth_config` | text | | Team auth settings (JSON) |
| `portal_config` | text | | Portal feature settings (JSON) |
| `branding_config` | text | | Theme/branding settings (JSON) |
| `custom_css` | text | | Custom CSS for portal |
| `developer_config` | text | | Developer settings (JSON), e.g. MCP config |
| `setup_state` | text | | Onboarding state tracking (JSON) |
| `metadata` | text | | Additional metadata (JSON) |
| `created_at` | timestamptz | NOT NULL | Creation timestamp |

**JSON Column Schemas:**

`auth_config`:
```json
{
  "oauth": { "google": boolean, "github": boolean, "microsoft": boolean },
  "ssoRequired": boolean,
  "openSignup": boolean
}
```

`portal_config`:
```json
{
  "oauth": { "password": boolean, "email": boolean, "google": boolean, "github": boolean },
  "features": { "publicView": boolean, "submissions": boolean, "comments": boolean, "voting": boolean }
}
```

`branding_config`:
```json
{
  "preset": string,
  "light": { /* ThemeColors */ },
  "dark": { /* ThemeColors */ }
}
```

`setup_state`:
```json
{
  "version": number,
  "steps": { "core": boolean, "workspace": boolean, "boards": boolean },
  "completedAt": "ISO timestamp",
  "source": "cloud" | "self-hosted",
  "useCase": "saas" | "consumer" | "marketplace" | "internal"
}
```

---

## Content Tables

### boards

Feedback boards for organizing posts by topic or product area.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (board) | PRIMARY KEY | Board identifier |
| `slug` | text | NOT NULL, UNIQUE | URL-safe identifier |
| `name` | text | NOT NULL | Display name |
| `description` | text | | Board description |
| `is_public` | boolean | NOT NULL, DEFAULT true | Public visibility |
| `settings` | jsonb | NOT NULL, DEFAULT \{\} | Board-specific settings |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |
| `deleted_at` | timestamptz | | Soft delete timestamp |

**Indexes:**
- Unique constraint on `slug`
- `boards_is_public_idx` on `is_public`
- `boards_deleted_at_idx` on `deleted_at`

**Settings Schema:**
```json
{
  "roadmapStatusIds": ["status_xxx", "status_yyy"]
}
```

**Relations:**
- Has many: posts

---

### posts

Feedback posts submitted by users or team members.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (post) | PRIMARY KEY | Post identifier |
| `board_id` | TypeID (board) | NOT NULL, FK -> boards.id ON DELETE CASCADE | Parent board |
| `title` | text | NOT NULL | Post title |
| `content` | text | NOT NULL | Plain text content |
| `content_json` | jsonb | | Rich content (TipTap JSON) |
| `member_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE RESTRICT | Author member |
| `status_id` | TypeID (status) | FK -> post_statuses.id ON DELETE SET NULL | Current status |
| `owner_member_id` | TypeID (member) | FK -> member.id ON DELETE SET NULL | Assigned team member |
| `vote_count` | integer | NOT NULL, DEFAULT 0, CHECK >= 0 | Cached vote count |
| `comment_count` | integer | NOT NULL, DEFAULT 0, CHECK >= 0 | Cached comment count |
| `official_response` | text | | Team response text |
| `official_response_member_id` | TypeID (member) | FK -> member.id ON DELETE SET NULL | Response author |
| `official_response_at` | timestamptz | | Response timestamp |
| `pinned_comment_id` | TypeID (comment) | | Pinned comment as official response |
| `is_comments_locked` | boolean | NOT NULL, DEFAULT false | Prevent portal users from commenting (team members bypass) |
| `moderation_state` | text | NOT NULL, DEFAULT 'published' | State: published, pending, spam, archived, closed, deleted |
| `canonical_post_id` | TypeID (post) | | Canonical post this was merged into |
| `merged_at` | timestamptz | | When this post was merged |
| `merged_by_member_id` | TypeID (member) | FK -> member.id ON DELETE SET NULL | Who performed the merge |
| `search_vector` | tsvector | GENERATED | Full-text search vector |
| `embedding` | vector(1536) | | Semantic embedding (AI) |
| `embedding_model` | text | | Model used for embedding |
| `embedding_updated_at` | timestamptz | | Embedding generation time |
| `summary_json` | jsonb | | AI-generated summary (structured) |
| `summary_model` | text | | Model used for summary generation |
| `summary_updated_at` | timestamptz | | Summary generation timestamp |
| `summary_comment_count` | integer | | Comment count when summary was last generated |
| `merge_checked_at` | timestamptz | | Last merge suggestion check timestamp |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |
| `deleted_at` | timestamptz | | Soft delete timestamp |
| `deleted_by_member_id` | TypeID (member) | FK -> member.id ON DELETE SET NULL | Who deleted |

**Indexes:**
- `posts_board_id_idx` on `board_id`
- `posts_status_id_idx` on `status_id`
- `posts_member_id_idx` on `member_id`
- `posts_owner_member_id_idx` on `owner_member_id`
- `posts_created_at_idx` on `created_at`
- `posts_vote_count_idx` on `vote_count`
- `posts_board_vote_idx` on `(board_id, vote_count)`
- `posts_board_created_at_idx` on `(board_id, created_at)`
- `posts_board_status_idx` on `(board_id, status_id)`
- `posts_member_created_at_idx` on `(member_id, created_at)`
- `posts_with_status_idx` partial on `(status_id, vote_count)` WHERE `status_id IS NOT NULL`
- `posts_search_vector_idx` (GIN) on `search_vector`
- `posts_deleted_at_idx` on `deleted_at`
- `posts_board_deleted_at_idx` on `(board_id, deleted_at)`
- `posts_moderation_state_idx` on `moderation_state`
- `posts_pinned_comment_id_idx` on `pinned_comment_id`
- `posts_canonical_post_id_idx` on `canonical_post_id`

**Relations:**
- Belongs to: board, post_status, member (author), member (owner), post (canonical, for merges)
- Has many: votes, comments, post_tags, post_roadmaps, post_notes, post_external_links, merged posts

---

### comments

Comments on feedback posts, supporting nested replies.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (comment) | PRIMARY KEY | Comment identifier |
| `post_id` | TypeID (post) | NOT NULL, FK -> posts.id ON DELETE CASCADE | Parent post |
| `parent_id` | TypeID (comment) | | Parent comment (for replies) |
| `member_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE RESTRICT | Author member |
| `content` | text | NOT NULL | Comment text |
| `is_team_member` | boolean | NOT NULL, DEFAULT false | Team member flag |
| `is_private` | boolean | NOT NULL, DEFAULT false | Private internal note (visible only to team) |
| `status_change_from_id` | TypeID (status) | FK -> post_statuses.id ON DELETE SET NULL | Previous status (for status changes recorded with comments) |
| `status_change_to_id` | TypeID (status) | FK -> post_statuses.id ON DELETE SET NULL | New status (for status changes recorded with comments) |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `deleted_at` | timestamptz | | Soft delete timestamp |

**Indexes:**
- `comments_post_id_idx` on `post_id`
- `comments_parent_id_idx` on `parent_id`
- `comments_member_id_idx` on `member_id`
- `comments_created_at_idx` on `created_at`
- `comments_post_created_at_idx` on `(post_id, created_at)`

**Relations:**
- Belongs to: post, member (author), comment (parent), post_status (statusChangeFrom), post_status (statusChangeTo)
- Has many: comments (replies), comment_reactions

---

### votes

User votes on posts. Each member can vote once per post.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (vote) | PRIMARY KEY | Vote identifier |
| `post_id` | TypeID (post) | NOT NULL, FK -> posts.id ON DELETE CASCADE | Voted post |
| `member_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE CASCADE | Voting member |
| `source_type` | text | | Integration source that created the vote |
| `source_external_url` | text | | URL to the source ticket/conversation |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Vote timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

**Indexes:**
- `votes_post_id_idx` on `post_id`
- `votes_member_post_idx` (unique) on `(post_id, member_id)`
- `votes_member_id_idx` on `member_id`
- `votes_member_created_at_idx` on `(member_id, created_at)`

**Relations:**
- Belongs to: post, member

---

### tags

Labels for categorizing posts.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (tag) | PRIMARY KEY | Tag identifier |
| `name` | text | NOT NULL, UNIQUE | Tag name |
| `color` | text | NOT NULL, DEFAULT '#6b7280' | Hex color code |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `deleted_at` | timestamptz | | Soft delete timestamp |

**Indexes:**
- Unique constraint on `name`
- `tags_deleted_at_idx` on `deleted_at`

**Relations:**
- Has many: post_tags

---

### post_tags

Junction table linking posts to tags (many-to-many).

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `post_id` | TypeID (post) | NOT NULL, FK -> posts.id ON DELETE CASCADE | Post reference |
| `tag_id` | TypeID (tag) | NOT NULL, FK -> tags.id ON DELETE CASCADE | Tag reference |

**Indexes:**
- `post_tags_pk` (unique) on `(post_id, tag_id)` - composite primary key
- `post_tags_post_id_idx` on `post_id`
- `post_tags_tag_id_idx` on `tag_id`

**Relations:**
- Belongs to: post, tag

---

### roadmaps

Public roadmap views for displaying planned work.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (roadmap) | PRIMARY KEY | Roadmap identifier |
| `slug` | text | NOT NULL, UNIQUE | URL-safe identifier |
| `name` | text | NOT NULL | Display name |
| `description` | text | | Roadmap description |
| `is_public` | boolean | NOT NULL, DEFAULT true | Public visibility |
| `position` | integer | NOT NULL, DEFAULT 0 | Display order |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |
| `deleted_at` | timestamptz | | Soft delete timestamp |

**Indexes:**
- Unique constraint on `slug`
- `roadmaps_position_idx` on `position`
- `roadmaps_is_public_idx` on `is_public`
- `roadmaps_deleted_at_idx` on `deleted_at`

**Relations:**
- Has many: post_roadmaps

---

### post_roadmaps

Junction table linking posts to roadmaps (many-to-many).

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `post_id` | TypeID (post) | NOT NULL, FK -> posts.id ON DELETE CASCADE | Post reference |
| `roadmap_id` | TypeID (roadmap) | NOT NULL, FK -> roadmaps.id ON DELETE CASCADE | Roadmap reference |
| `position` | integer | NOT NULL, DEFAULT 0 | Position within roadmap |

**Indexes:**
- `post_roadmaps_pk` (unique) on `(post_id, roadmap_id)` - composite primary key
- `post_roadmaps_post_id_idx` on `post_id`
- `post_roadmaps_roadmap_id_idx` on `roadmap_id`
- `post_roadmaps_position_idx` on `(roadmap_id, position)`

**Relations:**
- Belongs to: post, roadmap

---

## Status & Workflow Tables

### post_statuses

Customizable status definitions for tracking post lifecycle.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (status) | PRIMARY KEY | Status identifier |
| `name` | text | NOT NULL | Display name |
| `slug` | text | NOT NULL, UNIQUE | URL-safe identifier |
| `color` | text | NOT NULL, DEFAULT '#6b7280' | Hex color code |
| `category` | text | NOT NULL, DEFAULT 'active' | Category: 'active', 'complete', 'closed' |
| `position` | integer | NOT NULL, DEFAULT 0 | Display order within category |
| `show_on_roadmap` | boolean | NOT NULL, DEFAULT false | Show on public roadmap |
| `is_default` | boolean | NOT NULL, DEFAULT false | Default for new posts |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `deleted_at` | timestamptz | | Soft delete timestamp |

**Status Categories:**
- `active`: Posts currently being worked on (Open, Under Review, Planned, In Progress)
- `complete`: Successfully delivered posts (Complete)
- `closed`: Posts that won't be implemented (Closed)

**Indexes:**
- Unique constraint on `slug`
- `post_statuses_position_idx` on `(category, position)`
- `post_statuses_deleted_at_idx` on `deleted_at`

**Relations:**
- Has many: posts

**Default Statuses:**
| Name | Slug | Color | Category | Show on Roadmap |
|------|------|-------|----------|-----------------|
| Open | open | #3b82f6 | active | No |
| Under Review | under_review | #eab308 | active | No |
| Planned | planned | #a855f7 | active | Yes |
| In Progress | in_progress | #f97316 | active | Yes |
| Complete | complete | #22c55e | complete | Yes |
| Closed | closed | #6b7280 | closed | No |

---

## History & Notes Tables

### post_edit_history

Audit trail for post edits.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (post_edit) | PRIMARY KEY | Edit record identifier |
| `post_id` | TypeID (post) | NOT NULL, FK -> posts.id ON DELETE CASCADE | Edited post |
| `editor_member_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE SET NULL | Editor |
| `previous_title` | text | NOT NULL | Title before edit |
| `previous_content` | text | NOT NULL | Content before edit |
| `previous_content_json` | jsonb | | Rich content before edit |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Edit timestamp |

**Indexes:**
- `post_edit_history_post_id_idx` on `post_id`
- `post_edit_history_created_at_idx` on `created_at`

**Relations:**
- Belongs to: post, member (editor)

---

### comment_edit_history

Audit trail for comment edits.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (comment_edit) | PRIMARY KEY | Edit record identifier |
| `comment_id` | TypeID (comment) | NOT NULL, FK -> comments.id ON DELETE CASCADE | Edited comment |
| `editor_member_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE SET NULL | Editor |
| `previous_content` | text | NOT NULL | Content before edit |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Edit timestamp |

**Indexes:**
- `comment_edit_history_comment_id_idx` on `comment_id`
- `comment_edit_history_created_at_idx` on `created_at`

**Relations:**
- Belongs to: comment, member (editor)

---

### post_notes

Internal staff notes on posts (not visible to public users).

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (note) | PRIMARY KEY | Note identifier |
| `post_id` | TypeID (post) | NOT NULL, FK -> posts.id ON DELETE CASCADE | Associated post |
| `member_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE RESTRICT | Note author |
| `content` | text | NOT NULL | Note content |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |

**Indexes:**
- `post_notes_post_id_idx` on `post_id`
- `post_notes_member_id_idx` on `member_id`
- `post_notes_created_at_idx` on `created_at`

**Relations:**
- Belongs to: post, member (author)

---

### comment_reactions

Emoji reactions on comments.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (reaction) | PRIMARY KEY | Reaction identifier |
| `comment_id` | TypeID (comment) | NOT NULL, FK -> comments.id ON DELETE CASCADE | Reacted comment |
| `member_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE CASCADE | Reacting member |
| `emoji` | text | NOT NULL | Emoji character |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Reaction timestamp |

**Supported Emojis:**
- Thumbs up, Heart, Party, Smile, Thinking, Eyes

**Indexes:**
- `comment_reactions_comment_id_idx` on `comment_id`
- `comment_reactions_member_id_idx` on `member_id`
- `comment_reactions_unique_idx` (unique) on `(comment_id, member_id, emoji)`

**Relations:**
- Belongs to: comment, member

---

## Integration Tables

### integrations

Third-party integration configurations (Slack, Discord, etc.).

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (integration) | PRIMARY KEY | Integration identifier |
| `integration_type` | varchar(50) | NOT NULL, UNIQUE | Type: slack, discord, linear, etc. |
| `status` | varchar(20) | NOT NULL, DEFAULT 'pending' | Status: pending, active, error |
| `secrets` | text | | Encrypted secrets blob (AES-256-GCM JSON) |
| `config` | jsonb | NOT NULL, DEFAULT \{\} | Integration-specific config |
| `connected_by_member_id` | TypeID (member) | FK -> member.id | Who connected |
| `connected_at` | timestamptz | | Connection timestamp |
| `last_sync_at` | timestamptz | | Last sync timestamp |
| `last_error` | text | | Last error message |
| `last_error_at` | timestamptz | | Last error timestamp |
| `error_count` | integer | NOT NULL, DEFAULT 0, CHECK >= 0 | Consecutive error count |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

**Indexes:**
- `integration_type_unique` (unique) on `integration_type`
- `idx_integrations_type_status` on `(integration_type, status)`

**Relations:**
- Belongs to: member (connected_by)
- Has many: integration_event_mappings, post_external_links

---

### integration_event_mappings

Event-to-action mappings for integrations.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (event_mapping) | PRIMARY KEY | Mapping identifier |
| `integration_id` | TypeID (integration) | NOT NULL, FK -> integrations.id ON DELETE CASCADE | Parent integration |
| `event_type` | varchar(100) | NOT NULL | Event: post.created, status.changed, etc. |
| `action_type` | varchar(50) | NOT NULL | Action: send_message, create_issue, etc. |
| `action_config` | jsonb | NOT NULL, DEFAULT \{\} | Action configuration |
| `filters` | jsonb | | Event filters |
| `enabled` | boolean | NOT NULL, DEFAULT true | Mapping enabled |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

**Action Config Schema:**
```json
{
  "templateId": "tpl_xxx",
  "message": "New feedback: {{title}}"
}
```

**Filters Schema:**
```json
{
  "boardIds": ["board_xxx", "board_yyy"],
  "statusIds": ["status_xxx"]
}
```

**Indexes:**
- `mapping_unique` (unique) on `(integration_id, event_type, action_type)`
- `idx_event_mappings_lookup` on `(integration_id, event_type, enabled)`

**Relations:**
- Belongs to: integration

---

### integration_platform_credentials

Platform-level OAuth app credentials for integrations. One row per provider. Secrets are AES-256-GCM encrypted.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (platform_cred) | PRIMARY KEY | Credential identifier |
| `integration_type` | varchar(50) | NOT NULL, UNIQUE | Provider type: slack, teams, linear, etc. |
| `secrets` | text | NOT NULL | Encrypted platform credentials (AES-256-GCM) |
| `configured_by_member_id` | TypeID (member) | FK -> member.id ON DELETE SET NULL | Who configured |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

**Indexes:**
- `platform_cred_type_unique` (unique) on `integration_type`

**Relations:**
- Belongs to: member (configured_by)

---

### post_external_links

External links between posts and external platform issues (e.g., Linear issues, GitHub issues).

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (linked_entity) | PRIMARY KEY | Link identifier |
| `post_id` | TypeID (post) | NOT NULL, FK -> posts.id ON DELETE CASCADE | Associated post |
| `integration_id` | TypeID (integration) | NOT NULL, FK -> integrations.id ON DELETE CASCADE | Associated integration |
| `integration_type` | varchar(50) | NOT NULL | Integration type |
| `external_id` | text | NOT NULL | External issue/item ID |
| `external_url` | text | | URL to external item |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |

**Indexes:**
- `post_external_links_type_external_id` (unique) on `(integration_type, external_id)`
- `post_external_links_post_id_idx` on `post_id`
- `post_external_links_type_external_id_idx` on `(integration_type, external_id)`

**Relations:**
- Belongs to: post, integration

---

## Notification Tables

### in_app_notifications

In-app notifications displayed in the UI.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (notification) | PRIMARY KEY | Notification identifier |
| `member_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE CASCADE | Recipient member |
| `type` | varchar(50) | NOT NULL | Type: post_status_changed, comment_created |
| `title` | varchar(255) | NOT NULL | Notification title |
| `body` | text | | Notification body |
| `post_id` | TypeID (post) | FK -> posts.id ON DELETE CASCADE | Related post |
| `comment_id` | TypeID (comment) | FK -> comments.id ON DELETE CASCADE | Related comment |
| `metadata` | jsonb | | Additional data |
| `read_at` | timestamptz | | When marked as read |
| `archived_at` | timestamptz | | When archived |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |

**Indexes:**
- `in_app_notifications_member_created_idx` on `(member_id, created_at)`
- `in_app_notifications_member_unread_idx` partial on `member_id` WHERE `read_at IS NULL AND archived_at IS NULL`
- `in_app_notifications_post_idx` on `post_id`

**Relations:**
- Belongs to: member, post, comment

---

### post_subscriptions

Tracks which members are subscribed to which posts for notifications.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (post_sub) | PRIMARY KEY | Subscription identifier |
| `post_id` | TypeID (post) | NOT NULL, FK -> posts.id ON DELETE CASCADE | Subscribed post |
| `member_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE CASCADE | Subscribed member |
| `reason` | varchar(20) | NOT NULL | Reason: author, vote, comment, manual |
| `notify_comments` | boolean | NOT NULL, DEFAULT true | Receive comment notifications |
| `notify_status_changes` | boolean | NOT NULL, DEFAULT true | Receive status change notifications |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

**Notification Levels:**
- All activity: `notify_comments=true`, `notify_status_changes=true`
- Status changes only: `notify_comments=false`, `notify_status_changes=true`
- Unsubscribed: Row deleted

**Indexes:**
- `post_subscriptions_unique` (unique) on `(post_id, member_id)`
- `post_subscriptions_member_idx` on `member_id`
- `post_subscriptions_post_idx` on `post_id`
- `post_subscriptions_post_comments_idx` partial on `post_id` WHERE `notify_comments = true`
- `post_subscriptions_post_status_idx` partial on `post_id` WHERE `notify_status_changes = true`

**Relations:**
- Belongs to: post, member

---

### notification_preferences

Per-member email notification settings.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (notif_pref) | PRIMARY KEY | Preference identifier |
| `member_id` | TypeID (member) | NOT NULL, UNIQUE, FK -> member.id ON DELETE CASCADE | Member |
| `email_status_change` | boolean | NOT NULL, DEFAULT true | Email on status changes |
| `email_new_comment` | boolean | NOT NULL, DEFAULT true | Email on new comments |
| `email_muted` | boolean | NOT NULL, DEFAULT false | Mute all emails |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

**Indexes:**
- Unique constraint on `member_id`

**Relations:**
- Belongs to: member

---

### unsubscribe_tokens

One-time tokens for email unsubscribe links.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (unsub_token) | PRIMARY KEY | Token identifier |
| `token` | text | NOT NULL, UNIQUE | Token value |
| `member_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE CASCADE | Member |
| `post_id` | TypeID (post) | FK -> posts.id ON DELETE CASCADE | Related post (null = global) |
| `action` | varchar(30) | NOT NULL | Action: unsubscribe_post, unsubscribe_all, mute_post |
| `expires_at` | timestamptz | NOT NULL | Expiration time |
| `used_at` | timestamptz | | When token was used |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |

**Indexes:**
- Unique constraint on `token`
- `unsubscribe_tokens_member_idx` on `member_id`

**Relations:**
- Belongs to: member, post

---

## Changelog Tables

### changelog_entries

Public changelog/release notes entries.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (changelog) | PRIMARY KEY | Entry identifier |
| `title` | text | NOT NULL | Entry title |
| `content` | text | NOT NULL | Plain text content |
| `content_json` | jsonb | | Rich content (TipTap JSON) |
| `member_id` | TypeID (member) | FK -> member.id ON DELETE SET NULL | Author member |
| `published_at` | timestamptz | | Publication timestamp |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |
| `deleted_at` | timestamptz | | Soft delete timestamp |

**Indexes:**
- `changelog_published_at_idx` on `published_at`
- `changelog_member_id_idx` on `member_id`
- `changelog_deleted_at_idx` on `deleted_at`

**Relations:**
- Belongs to: member (author)
- Has many: changelog_entry_posts

---

### changelog_entry_posts

Junction table linking changelog entries to shipped posts (many-to-many).

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `changelog_entry_id` | TypeID (changelog) | NOT NULL, FK -> changelog_entries.id ON DELETE CASCADE | Changelog entry |
| `post_id` | TypeID (post) | NOT NULL, FK -> posts.id ON DELETE CASCADE | Linked post |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |

**Indexes:**
- `changelog_entry_posts_pk` (unique) on `(changelog_entry_id, post_id)` - composite primary key
- `changelog_entry_posts_changelog_id_idx` on `changelog_entry_id`
- `changelog_entry_posts_post_id_idx` on `post_id`

**Relations:**
- Belongs to: changelog_entry, post

---

## AI Feature Tables

### post_sentiment

AI-generated sentiment analysis results for posts (one-to-one with posts).

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (sentiment) | PRIMARY KEY | Sentiment record identifier |
| `post_id` | TypeID (post) | NOT NULL, UNIQUE, FK -> posts.id ON DELETE CASCADE | Analyzed post |
| `sentiment` | text | NOT NULL | Result: positive, neutral, negative |
| `confidence` | real | NOT NULL | Confidence score (0-1) |
| `model` | text | NOT NULL | AI model used |
| `processed_at` | timestamptz | NOT NULL, DEFAULT now() | Analysis timestamp |
| `input_tokens` | integer | | Input token count |
| `output_tokens` | integer | | Output token count |

**Indexes:**
- `post_sentiment_processed_at_idx` on `processed_at`
- `post_sentiment_sentiment_idx` on `sentiment`

**Relations:**
- Belongs to: post

---

## API Tables

### api_keys

API keys for public REST API authentication.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (api_key) | PRIMARY KEY | API key identifier |
| `name` | varchar(255) | NOT NULL | Human-readable key name |
| `key_hash` | varchar(64) | NOT NULL, UNIQUE | SHA-256 hash of the API key |
| `key_prefix` | varchar(12) | NOT NULL | First 12 chars for identification |
| `created_by_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE CASCADE | Member who created the key |
| `last_used_at` | timestamptz | | Last authentication timestamp |
| `expires_at` | timestamptz | | Optional expiration date |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `revoked_at` | timestamptz | | Soft delete / revocation timestamp |

**Indexes:**
- Unique constraint on `key_hash`
- `api_keys_created_by_id_idx` on `created_by_id`
- `api_keys_revoked_at_idx` on `revoked_at`

**Relations:**
- Belongs to: member (created_by)

---

### webhooks

Webhook configurations for external event notifications.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (webhook) | PRIMARY KEY | Webhook identifier |
| `created_by_id` | TypeID (member) | NOT NULL, FK -> member.id ON DELETE CASCADE | Member who created the webhook |
| `url` | text | NOT NULL | HTTPS endpoint URL |
| `secret` | text | NOT NULL | Encrypted HMAC-SHA256 signing secret |
| `events` | text[] | NOT NULL | Event types to trigger |
| `board_ids` | text[] | | Optional board filter |
| `status` | text | NOT NULL, DEFAULT 'active' | Status: active, disabled |
| `failure_count` | integer | NOT NULL, DEFAULT 0 | Consecutive delivery failures |
| `last_error` | text | | Last error message |
| `last_triggered_at` | timestamptz | | Last trigger timestamp |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |
| `deleted_at` | timestamptz | | Soft delete timestamp |

**Indexes:**
- `webhooks_status_idx` on `status`
- `webhooks_created_by_id_idx` on `created_by_id`
- `webhooks_deleted_at_idx` on `deleted_at`

**Relations:**
- Belongs to: member (created_by)

---

### merge_suggestions

AI-generated merge suggestions for duplicate posts.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (merge_sug) | PRIMARY KEY | Suggestion identifier |
| `source_post_id` | TypeID (post) | NOT NULL, FK -> posts.id ON DELETE CASCADE | Post suggested as duplicate |
| `target_post_id` | TypeID (post) | NOT NULL, FK -> posts.id ON DELETE CASCADE | Canonical post to merge into |
| `status` | text | NOT NULL, DEFAULT 'pending' | Status: pending, accepted, dismissed |
| `vector_score` | real | | Vector similarity score |
| `fts_score` | real | | Full-text search score |
| `hybrid_score` | real | | Combined hybrid score |
| `llm_confidence` | real | | LLM verification confidence |
| `llm_reasoning` | text | | LLM explanation for the match |
| `llm_model` | text | | LLM model used for verification |
| `resolved_at` | timestamptz | | When accepted or dismissed |
| `resolved_by_principal_id` | TypeID (member) | FK -> member.id ON DELETE SET NULL | Who resolved |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

**Relations:**
- Belongs to: post (source), post (target), member (resolved_by)

---

## Feedback Pipeline Tables

### feedback_sources

External feedback source configurations for the ingest pipeline.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (fb_source) | PRIMARY KEY | Source identifier |
| `source_type` | text | NOT NULL | Source type (e.g. integration name) |
| `delivery_mode` | text | NOT NULL | How feedback is delivered |
| `name` | text | NOT NULL | Display name |
| `integration_id` | TypeID (integration) | FK -> integrations.id | Linked integration |
| `enabled` | boolean | NOT NULL, DEFAULT true | Active flag |
| `config` | jsonb | NOT NULL, DEFAULT \{\} | Source configuration |
| `secrets` | text | | Encrypted secrets |
| `cursor` | text | | Pagination cursor for polling |
| `last_synced_at` | timestamptz | | Last sync timestamp |
| `last_success_at` | timestamptz | | Last successful sync |
| `last_error` | text | | Most recent error |
| `error_count` | integer | NOT NULL, DEFAULT 0 | Consecutive errors |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

---

### raw_feedback_items

Unprocessed feedback items from external sources, queued for AI extraction.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (raw_fb) | PRIMARY KEY | Item identifier |
| `source_id` | TypeID (fb_source) | NOT NULL, FK -> feedback_sources.id | Parent source |
| `source_type` | text | NOT NULL | Source type |
| `external_id` | text | | External item ID |
| `dedupe_key` | text | | Deduplication key |
| `external_url` | text | | Link back to source |
| `source_created_at` | timestamptz | | When created in source system |
| `author` | jsonb | | Author information |
| `content` | text | NOT NULL | Raw feedback content |
| `context_envelope` | jsonb | | Additional context metadata |
| `processing_state` | text | NOT NULL, DEFAULT 'pending' | State: pending, processing, done, failed |
| `attempt_count` | integer | NOT NULL, DEFAULT 0 | Processing attempts |
| `last_error` | text | | Last processing error |
| `processed_at` | timestamptz | | When processing completed |
| `principal_id` | TypeID (member) | | Matched user principal |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

---

### feedback_signals

AI-extracted signals from raw feedback items.

---

### feedback_suggestions

Suggestions generated from AI analysis of feedback signals (e.g. create a new post, merge with existing).

---

### feedback_signal_corrections

User corrections and feedback on AI signal extraction accuracy.

---

### external_user_mappings

Maps external user identifiers to internal Quackback principals for cross-system identity resolution.

---

## Segment Tables

### segments

User segments for filtering and analytics. Supports manual and dynamic (rule-based) membership.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (segment) | PRIMARY KEY | Segment identifier |
| `name` | text | NOT NULL | Display name |
| `description` | text | | Segment description |
| `type` | text | NOT NULL | Type: manual, dynamic |
| `color` | text | | Display color |
| `rules` | jsonb | | Dynamic segment rules |
| `evaluation_schedule` | text | | Cron schedule for re-evaluation |
| `weight_config` | jsonb | | Weighting configuration |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |
| `deleted_at` | timestamptz | | Soft delete timestamp |

---

### user_segments

Junction table for user-to-segment membership.

---

### user_attribute_definitions

Admin-defined custom user attributes for enrichment.

| Column | Type | Constraints | Description |
|--------|------|-------------|-------------|
| `id` | TypeID (user_attr) | PRIMARY KEY | Attribute identifier |
| `key` | text | NOT NULL, UNIQUE | Attribute key |
| `label` | text | NOT NULL | Display label |
| `description` | text | | Attribute description |
| `type` | text | NOT NULL | Data type: text, number, boolean, date, currency |
| `currency_code` | text | | Currency code (for currency type) |
| `external_key` | text | | Mapping key for integration sync |
| `created_at` | timestamptz | NOT NULL, DEFAULT now() | Creation timestamp |
| `updated_at` | timestamptz | NOT NULL, DEFAULT now() | Last update timestamp |

---

## Database Triggers

### comment_count

The `comment_count` column on posts is maintained in application code (not a database trigger). It's updated whenever comments are created or deleted.

---

## TypeID Format

All entity IDs use the TypeID format, which combines a type prefix with a UUID:

```
{type}_{uuid_base32}
```

Examples:
- `post_01h455vb4pex5vsknk084sn02q`
- `board_01h455vb4pex5vsknk084sn03r`
- `member_01h455vb4pex5vsknk084sn04s`

Type prefixes used:
- `user`, `session`, `account`, `member`, `invite`, `workspace`, `verification`, `domain`, `transfer_token`
- `board`, `post`, `comment`, `vote`, `tag`, `status`, `roadmap`
- `integration`, `platform_cred`, `event_mapping`, `linked_entity`, `sync_log`
- `notification`, `post_sub`, `notif_pref`, `unsub_token`
- `changelog`, `sentiment`, `note`, `reaction`
- `post_edit`, `comment_edit`
- `api_key`, `webhook`
- `subscription`, `invoice` (billing)

---

## Schema Files

The schema is defined in Drizzle ORM format in these files:

| File | Tables |
|------|--------|
| `packages/db/src/schema/auth.ts` | user, session, account, verification, one_time_token, settings, member, invitation, jwks, oauth_client, oauth_access_token, oauth_refresh_token, oauth_consent |
| `packages/db/src/schema/boards.ts` | boards, roadmaps, tags |
| `packages/db/src/schema/posts.ts` | posts, post_tags, post_roadmaps, votes, comments, comment_reactions, post_edit_history, comment_edit_history, post_notes |
| `packages/db/src/schema/statuses.ts` | post_statuses |
| `packages/db/src/schema/integrations.ts` | integrations, integration_platform_credentials, integration_event_mappings |
| `packages/db/src/schema/notifications.ts` | in_app_notifications, post_subscriptions, notification_preferences, unsubscribe_tokens |
| `packages/db/src/schema/changelog.ts` | changelog_entries, changelog_entry_posts |
| `packages/db/src/schema/sentiment.ts` | post_sentiment |
| `packages/db/src/schema/merge-suggestions.ts` | merge_suggestions |
| `packages/db/src/schema/feedback.ts` | feedback_sources, raw_feedback_items, feedback_signals, feedback_suggestions, feedback_signal_corrections, external_user_mappings |
| `packages/db/src/schema/segments.ts` | segments, user_segments |
| `packages/db/src/schema/user-attributes.ts` | user_attribute_definitions |
| `packages/db/src/schema/api-keys.ts` | api_keys |
| `packages/db/src/schema/webhooks.ts` | webhooks |
| `packages/db/src/schema/external-links.ts` | post_external_links |

Migrations are located in `packages/db/drizzle/`.

- [Environment Variables](https://quackback.io/docs/reference/environment-variables): Complete reference for all Quackback configuration options.

# Environment Variables

Complete reference for all Quackback configuration options. Copy `.env.example` to `.env` and fill in your values.

## Required Variables

| Variable | Description | Example |
|----------|-------------|---------|
| `DATABASE_URL` | PostgreSQL connection string | `postgresql://postgres:password@localhost:5432/quackback` |
| `SECRET_KEY` | Secret key for authentication and encryption (32+ chars). Used for session signing and deriving encryption keys. | `openssl rand -base64 32` |
| `BASE_URL` | Public URL for your instance (used for auth, emails, and OAuth callbacks) | `https://feedback.example.com` |
| `REDIS_URL` | Redis/Dragonfly connection for background job queue (BullMQ). Dragonfly is included in docker-compose. | `redis://localhost:6379` |

## Email Configuration

Configure email delivery for OTP codes, notifications, and invitations.

Priority order: SMTP (if configured) > Resend (if configured) > Console logging.

### SMTP

| Variable | Description | Example |
|----------|-------------|---------|
| `EMAIL_SMTP_HOST` | SMTP server hostname | `smtp.sendgrid.net` |
| `EMAIL_SMTP_PORT` | SMTP port | `587` |
| `EMAIL_SMTP_USER` | SMTP username | `apikey` |
| `EMAIL_SMTP_PASS` | SMTP password | `SG.xxxx` |
| `EMAIL_SMTP_SECURE` | Use TLS (for port 465) | `true` |
| `EMAIL_FROM` | Sender email address | `Quackback <feedback@example.com>` |

### Resend

| Variable | Description | Example |
|----------|-------------|---------|
| `EMAIL_RESEND_API_KEY` | Resend API key | `re_xxxxxxxxxxxx` |
| `EMAIL_FROM` | Sender email address | `Quackback <feedback@example.com>` |

## OAuth Providers

Enable social login for portal users and team members.

### GitHub

| Variable | Description |
|----------|-------------|
| `GITHUB_CLIENT_ID` | GitHub OAuth App client ID |
| `GITHUB_CLIENT_SECRET` | GitHub OAuth App client secret |

Create at: [GitHub Developer Settings](https://github.com/settings/developers)

Callback URL: `https://your-domain.com/api/auth/callback/github`

### Google

| Variable | Description |
|----------|-------------|
| `GOOGLE_CLIENT_ID` | Google OAuth client ID |
| `GOOGLE_CLIENT_SECRET` | Google OAuth client secret |

Create at: [Google Cloud Console](https://console.cloud.google.com/apis/credentials)

Callback URL: `https://your-domain.com/api/auth/callback/google`

## AI

Enable AI features: post summaries, duplicate detection, feedback extraction, and help center semantic search. AI is off unless you set the key, the endpoint, and a model for each role -- Quackback works with any OpenAI-compatible endpoint but never assumes one.

| Variable | Description | Example |
|----------|-------------|---------|
| `OPENAI_API_KEY` | API key for your AI endpoint | `sk-...` |
| `OPENAI_BASE_URL` | OpenAI-compatible endpoint. Required -- there is no default | `https://api.openai.com/v1` |
| `AI_CHAT_MODEL` | Default model for chat features (summaries, suggestions, merge verification) | `gpt-4o-mini` |
| `AI_EMBEDDING_MODEL` | Model for embeddings (duplicate detection, semantic search) | `text-embedding-3-small` |
| `AI_SUMMARY_MODEL` | Per-feature override of `AI_CHAT_MODEL` for post summaries | `off` |
| `AI_SENTIMENT_MODEL` | Per-feature override for sentiment analysis | `gpt-4o-mini` |
| `AI_EXTRACTION_MODEL` | Per-feature override for suggestion extraction | `gpt-4o-mini` |
| `AI_QUALITY_GATE_MODEL` | Per-feature override for the suggestion quality gate | `gpt-4o-mini` |
| `AI_INTERPRETATION_MODEL` | Per-feature override for feedback interpretation | `gpt-4o-mini` |
| `AI_MERGE_MODEL` | Per-feature override for merge verification | `gpt-4o` |

Per-feature overrides fall back to `AI_CHAT_MODEL` when unset. Set an override to `off` to disable just that feature. Use model ids your endpoint accepts -- gateways typically want provider-prefixed ids like `google/gemini-3.1-flash-lite-preview`.

## File Storage

S3-compatible storage for image uploads in changelogs and rich text content. Supports AWS S3, Cloudflare R2, Backblaze B2, MinIO, and other S3-compatible services.

| Variable | Description | Example |
|----------|-------------|---------|
| `S3_ENDPOINT` | S3 endpoint URL (leave empty for AWS S3) | `http://localhost:9000` |
| `S3_BUCKET` | S3 bucket name | `quackback` |
| `S3_REGION` | S3 region | `us-east-1` |
| `S3_ACCESS_KEY_ID` | S3 access key | `minioadmin` |
| `S3_SECRET_ACCESS_KEY` | S3 secret key | `minioadmin` |
| `S3_FORCE_PATH_STYLE` | Use path-style URLs (required for MinIO, R2) | `true` |
| `S3_PUBLIC_URL` | Public URL for uploaded files (optional) | `https://cdn.example.com` |

## Telemetry

Anonymous usage statistics help improve Quackback. Telemetry is enabled by default and can be disabled via environment variable.

| Variable | Description | Example |
|----------|-------------|---------|
| `DISABLE_TELEMETRY` | Set to `"true"` to disable anonymous usage statistics | `true` |

## Complete Example

```bash
# ===================
# Required
# ===================
DATABASE_URL="postgresql://postgres:password@localhost:5432/quackback"
SECRET_KEY="your-32-character-minimum-secret-key-here"
BASE_URL="https://feedback.yourcompany.com"
REDIS_URL="redis://localhost:6379"

# ===================
# Email (choose one)
# ===================
# SMTP
EMAIL_SMTP_HOST="smtp.sendgrid.net"
EMAIL_SMTP_PORT="587"
EMAIL_SMTP_USER="apikey"
EMAIL_SMTP_PASS="SG.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
EMAIL_FROM="Quackback <feedback@yourcompany.com>"

# Or Resend
# EMAIL_RESEND_API_KEY="re_xxxxxxxxxxxx"
# EMAIL_FROM="Quackback <feedback@yourcompany.com>"

# ===================
# OAuth (optional)
# ===================
GITHUB_CLIENT_ID="your-github-client-id"
GITHUB_CLIENT_SECRET="your-github-client-secret"

GOOGLE_CLIENT_ID="your-google-client-id"
GOOGLE_CLIENT_SECRET="your-google-client-secret"

# ===================
# Telemetry (optional)
# ===================
# DISABLE_TELEMETRY="true"

```

## Validation


### Documentation

- [Untitled](https://quackback.io/docs/CLAUDE)

# CLAUDE.md

Documentation source for Quackback. Pure MDX content repo — no build tooling. Fetched by `QuackbackIO/website` at build time via GitHub API.

**Published at**: https://quackback.io/docs

## Structure

```
├── getting-started/       admin/            auth/
├── self-hosting/          integrations/     api/
├── users/                 developers/       mcp/
├── reference/             snippets/
├── docs.json              # Tab navigation manifest
├── STYLE_GUIDE.md         # Writing guide
```

## Frontmatter

```yaml
```

## MDX Components

``, ``, ``, `` — place at point of decision, not page end. API docs use multi-language code blocks (curl > JS > Python).

## Writing Style

See `STYLE_GUIDE.md`. Short sentences, direct address ("you"), present tense, no passive voice, no superlatives, no hedging. Imperative titles for guides, nouns for reference. Link concepts inline when first mentioned.

## Conventions

- Files: kebab-case. Links: absolute paths without extension (`/admin/boards`).
- Never add co-author trailers to commits


## Integrations

- [Slack Integration](https://quackback.io/integrations/slack): Get feedback notifications in Slack
- [Discord Integration](https://quackback.io/integrations/discord): Sync feedback updates to Discord
- [Microsoft Teams Integration](https://quackback.io/integrations/microsoft-teams): Bring feedback into Microsoft Teams
- [Email Integration](https://quackback.io/integrations/email): Email notifications for feedback activity
- [ntfy Integration](https://quackback.io/integrations/ntfy): Push notifications for feedback, on any device
- [Linear Integration](https://quackback.io/integrations/linear): Create Linear issues from feedback
- [Jira Integration](https://quackback.io/integrations/jira): Link feedback to Jira issues
- [GitHub Integration](https://quackback.io/integrations/github): Sync feedback with GitHub Issues
- [GitLab Integration](https://quackback.io/integrations/gitlab): Connect feedback to GitLab Issues
- [Asana Integration](https://quackback.io/integrations/asana): Turn feedback into Asana tasks
- [ClickUp Integration](https://quackback.io/integrations/clickup): Create ClickUp tasks from feedback
- [Shortcut Integration](https://quackback.io/integrations/shortcut): Link feedback to Shortcut stories
- [Notion Integration](https://quackback.io/integrations/notion): Send feedback to Notion databases
- [Trello Integration](https://quackback.io/integrations/trello): Add feedback to Trello boards
- [Intercom Integration](https://quackback.io/integrations/intercom): Capture feedback from Intercom conversations
- [Zendesk Integration](https://quackback.io/integrations/zendesk): Bridge Zendesk tickets and feedback
- [HubSpot Integration](https://quackback.io/integrations/hubspot): Enrich HubSpot contacts with feedback data
- [Salesforce Integration](https://quackback.io/integrations/salesforce): Connect feedback to Salesforce records
- [Webhooks Integration](https://quackback.io/integrations/webhooks): Build custom integrations with webhooks
- [Zapier Integration](https://quackback.io/integrations/zapier): Automate feedback workflows with Zapier
- [Make Integration](https://quackback.io/integrations/make): Build visual automations with Make
- [REST API Integration](https://quackback.io/integrations/api): Full programmatic access to your feedback data
- [MCP Server Integration](https://quackback.io/integrations/mcp): Bring customer feedback into your AI-assisted workflows

## Comparisons

- [Quackback vs Canny](https://quackback.io/compare/quackback-vs-canny): Compare Quackback and Canny for customer feedback management.
- [Quackback vs UserVoice](https://quackback.io/compare/quackback-vs-uservoice): Compare Quackback and UserVoice for feedback management.
- [Quackback vs Fider](https://quackback.io/compare/quackback-vs-fider): Compare Quackback and Fider, two open source feedback tools.
- [Quackback vs Productboard](https://quackback.io/compare/quackback-vs-productboard): Compare Quackback and Productboard for product feedback.
- [Quackback vs Nolt](https://quackback.io/compare/quackback-vs-nolt): Compare Quackback and Nolt for user feedback management.
- [Quackback vs Featurebase](https://quackback.io/compare/quackback-vs-featurebase): Compare Quackback and Featurebase for feedback management.
- [Quackback vs Upvoty](https://quackback.io/compare/quackback-vs-upvoty): Compare Quackback and Upvoty for feature voting.
- [Quackback vs Sleekplan](https://quackback.io/compare/quackback-vs-sleekplan): Compare Quackback and Sleekplan for feedback collection.
- [Quackback vs Aha!](https://quackback.io/compare/quackback-vs-aha): Compare Quackback and Aha! for feedback and roadmapping.
- [Quackback vs Pendo](https://quackback.io/compare/quackback-vs-pendo): Compare Quackback and Pendo for user feedback.

## Use Cases

- [Feature Request Tracking](https://quackback.io/use-cases/feature-requests): Collect, track, and prioritize every feature request in one place
- [Idea Management](https://quackback.io/use-cases/idea-management): Capture, organize, and prioritize ideas from users and stakeholders
- [In-App Feedback](https://quackback.io/use-cases/in-app-feedback): Collect feedback where users experience your product
- [Bug Tracking](https://quackback.io/use-cases/bug-tracking): Capture bug reports from users and sync them to your issue tracker
- [Feedback Management](https://quackback.io/use-cases/feedback-management): One system to collect, prioritize, and act on customer feedback
- [Product Feedback](https://quackback.io/use-cases/product-management): The feedback and prioritization layer of your product management stack
- [Voice of the Customer](https://quackback.io/use-cases/voice-of-customer): Collect, analyze, and act on customer feedback across every channel
- [Feedback Analysis](https://quackback.io/use-cases/feedback-analysis): AI sentiment analysis, duplicate detection, and demand signals from voting
- [Innovation Management](https://quackback.io/use-cases/innovation-management): Capture ideas from users and stakeholders, evaluate with voting, and ship

## Blog

- [The State of Product Feedback 2026](https://quackback.io/blog/state-of-product-feedback-2026): A data-backed report on how product teams collect, prioritize, and act on customer feedback in 2026. Verified stats from Gartner, McKinsey, Bain, Pendo and more.

Published: 2026-05-28

Most product teams agree that customer feedback should drive what they build. Far fewer have a process that actually makes it happen. The gap between intention and practice is where this report lives. The figures below are drawn entirely from published industry research, not from Quackback, and they tell a consistent story: feedback is the second-strongest influence on strategy, yet the systems for collecting and acting on it remain inconsistent, and most of what gets shipped goes unused.

![Illustration of customer feedback flowing through collection, prioritization, and roadmap stages](/blog/state-of-product-feedback-2026/hero.webp)

> **TLDR:** Customer needs are the second-largest influence on product strategy ([54.9%](https://www.productledalliance.com/product-management-statistics/)), just behind leadership direction, yet only **34% of teams** run a continuous feedback process and [80% of shipped features](https://www.pendo.io/resources/the-2019-feature-adoption-report/) are rarely or never used. AI is now near-universal in product work ([100% of teams](https://www.productboard.com/blog/ai-in-product-management-report/) use it), making feedback the input most worth getting right.

## Key findings

- **Customer feedback is the second-largest influence on product strategy.** [54.9% of product professionals](https://www.productledalliance.com/product-management-statistics/) cite customer needs and user insights, narrowly behind leadership direction at 57.8%.
- **Only a third of teams collect feedback continuously.** Just **34%** regularly collect insights to guide prioritization; the rest work ad-hoc or have no consistent process.
- **Most of what gets built goes unused.** [80% of features](https://www.pendo.io/resources/the-2019-feature-adoption-report/) in the average software product are rarely or never used, and for every 100 features launched, only [6.4 drive 80% of click volume](https://www.pendo.io/pendo-blog/product-benchmarks/).
- **The customer-experience payoff is large and measured.** Companies that excel at customer experience grow revenue [4% to 8% above their market](https://www.bain.com/insights/the-five-disciplines-of-customer-experience-leaders/).
- **AI is now standard in product work.** [100% of product teams](https://www.productboard.com/blog/ai-in-product-management-report/) use AI tools and **94% of professionals** use AI daily or often.
- **Customers do not trust the loop.** Only [16% of customers](https://www.customerexperiencedive.com/news/surveys-what-customers-want-behavior/753866/) strongly believe their feedback drives actual change.
- **SaaS spend keeps climbing while seats go unused.** SaaS spend averages [$4,830 per employee](https://zylo.com/news/2025-saas-management-index), up 21.9% year over year, and companies use only [49% of provisioned licenses](https://zylo.com/news/2024-saas-management-index/).

## Collection and channels

Feedback weighs heavily on strategy, but the systems for gathering it are uneven. In the State of Product Management Report 2026, [54.9% of product professionals](https://www.productledalliance.com/product-management-statistics/) named customer needs and user insights as a top influence on product strategy. That is the second-largest force in the ranking, just behind leadership direction and internal priorities at 57.8%, and well ahead of sales or customer escalation requests at **30.7%**. Customer voice matters more than the loudest internal request, but not more than the executive in the room.

The collection process does not match that importance. Only **34% of teams** regularly collect insights and use them to guide prioritization. The rest are improvising: **19.3%** rely mostly on ad-hoc customer requests or escalations, and **12.3%** have no consistent research or feedback process at all. A continuous loop is still the minority practice. A persistent [feedback board](/features/feedback) that captures input as it arrives, rather than during a quarterly scramble, is what separates the third that run a process from the two-thirds that do not.

Where you ask matters as much as whether you ask. Across 8,391 surveys from 1,087 companies, the median response rate was [29.05%](https://survicate.com/reports/survey-response-rate-benchmarks/), but the channel swung results by an order of magnitude: on-page contextual surveys hit **55.07%** while widget surveys managed 7.64% and Intercom surveys 5.41%. In-app surveys perform well overall, averaging [27.52%](https://refiner.io/blog/in-app-survey-response-rates/), with mobile apps at 36.14% outperforming web apps at 26.48%. The in-app advantage is long-standing: companies see [2x to 10x higher](https://www.pendo.io/pendo-blog/app-nps-surveys-best-delivery-method/) response rates when they move NPS surveys in-app rather than to email.

![Bar chart of survey response rates by delivery channel](/blog/state-of-product-feedback-2026/response-rates.webp)

Two structural challenges shape collection. B2B teams get materially lower response rates than B2C, with a median of **21.88% for B2B** versus 36.67% for B2C across the same dataset. And maturity compounds: in older Pendo research, [70% of advanced organizations](https://www.pendo.io/pendo-blog/new-pendo-survey-shows-that-combining-product-data-with-in-app-feedback-can-increase-product-revenue-by-over-100/) solicited feedback more than monthly and 65% used NPS surveys, against just 14% NPS adoption among less-developed programs. The teams already collecting well tend to collect even more.

## Prioritization and the backlog

Collecting feedback is the easy half. Deciding what to do with it is where most teams come undone. Only [13.5% of product professionals](https://www.productledalliance.com/product-management-statistics/) consistently use a formal scoring or prioritization framework such as RICE, MoSCoW, or Kano. The rest prioritize by instinct, negotiation, or whoever escalated last. And priorities do not hold once set: **60.2% of product managers** cite leadership escalations or new directives as the primary reason priorities shift after they have been agreed.

The cost of ad-hoc prioritization shows up in adoption. [80% of features](https://www.pendo.io/resources/the-2019-feature-adoption-report/) in the average software product are rarely or never used. The concentration is stark: for every 100 features built and launched, only [6.4 drive 80%](https://www.pendo.io/pendo-blog/product-benchmarks/) of click volume, and even for best-in-class products, feature adoption reaches only **15.6%**. This is not a new finding. A long-cited Standish Group benchmark from 2002 put it at [64% of features](https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used) rarely or never used, though that figure came from only four internal applications and has largely been superseded by Pendo's broader data.

Teams sense the disconnect. [69% of teams](https://www.productboard.com/ebook/2021-product-excellence-report/) say the products and features they release are not consistently well-received by customers, and [65% say](https://www.productboard.com/ebook/2024-product-excellence-report/) their product initiatives regularly fail to meet deadlines. Building the wrong thing, late, is the default outcome when prioritization runs on escalation rather than evidence. A ranked, transparent [voting board](/features/voting) gives demand a number, which is harder to override than a hunch. For the full method, see [customer feedback analysis](/blog/customer-feedback-analysis) and [feedback management](/blog/feedback-management).

## Business impact

The case for acting on feedback is not soft. Companies that excel at customer experience grow revenue [4% to 8% above](https://www.bain.com/insights/the-five-disciplines-of-customer-experience-leaders/) their market. McKinsey found that experience-led growth strategies which raise customer satisfaction by at least 20% lift [cross-sell rates 15% to 25%](https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/experience-led-growth-a-new-way-to-create-value), share of wallet 5% to 10%, and customer satisfaction and engagement 20% to 30%.

The retention math is even sharper. Acquiring a new customer is [five to 25 times](https://hbr.org/2014/10/the-value-of-keeping-the-right-customers) more expensive than retaining an existing one, and increasing retention by 5% increases profits by 25% to 95%, per Frederick Reichheld of Bain. Keeping the customers you have is the cheapest growth available, and listening to them is how you keep them.

The downside is measured in trillions. Qualtrics estimates [$3.8 trillion](https://www.qualtrics.com/articles/customer-experience/trillion-sales-at-risk-2025/) of global sales is at risk in 2025 from bad customer experiences, because **53% of consumers** say they will cut spending after a poor one. The growth gap between leaders and laggards is visible in the market: Forrester found CX leader AT&T U-Verse grew at a [35% CAGR](https://www.forrester.com/press-newsroom/customer-experience-leaders-crush-laggards-on-revenue-growth/) from 2010 to 2014 versus Comcast's 6%, and Amazon's four-year US revenue CAGR ran 16 times Wal-Mart's, 31% to 2%.

## Metrics and benchmarks

Satisfaction metrics give teams a shared yardstick, but the right band depends on industry. In Qualtrics' 2024 consumer benchmark of 354 companies across 22 industries, grocery stores earned the highest average NPS at [34.3](https://www.qualtrics.com/articles/customer-experience/xmi-nps-benchmark-2024/) while car rental companies earned the lowest at 15.8. The same pattern holds on overall experience ratings, where grocery scored [71%](https://www.qualtrics.com/articles/customer-experience/xmi-overall-benchmark-2024/) and car rental 52%. For CSAT specifically, industry guidance puts a good score in the [70% to 85%](https://www.surveymonkey.com/learn/customer-feedback/what-is-good-csat-score/) range. For the full breakdown, see [customer satisfaction metrics](/blog/customer-satisfaction-metrics).

The benchmarks are moving in the wrong direction. Forrester's 2024 US Customer Experience Index found CX quality at an all-time low after a [third straight year](https://www.forrester.com/press-newsroom/forrester-2024-us-customer-experience-index/) of decline, with 39% of brands significantly declining versus 17% in 2023, and only 3% of companies qualifying as customer-obsessed. The earlier reading was no better: [51% of consumers](https://www.qualtrics.com/articles/news/trillion-sales-at-risk-2024/) reduced or stopped spending after a poor experience, putting roughly $3.7 trillion in 2024 sales at risk.

The dominant metric itself is contested. NPS is deeply embedded: at least [two-thirds of the Fortune 1000](https://fortune.com/longform/net-promoter-score-fortune-500-customer-satisfaction-metric/) use it, and [58% of customer service leaders](https://www.gartner.com/en/newsroom/press-releases/2021-05-27-gartner-predicts-more-than-75--of-organizations-will-) were required by leadership to measure it. Yet Gartner predicted **more than 75%** of organizations would abandon NPS as a customer-service success measure by 2025. The reason traces back to foundational research: a study of more than 75,000 customers found [96% of high-effort](https://hbr.org/2010/07/stop-trying-to-delight-your-customers) service interactions produced disloyalty versus only 9% of low-effort ones, suggesting effort, not enthusiasm, is what to measure. For more, see [customer effort score](/blog/customer-effort-score).

## AI in feedback

AI has moved from experiment to default in a single cycle. In Productboard's 2025 research, [100% of product teams](https://www.productboard.com/blog/ai-in-product-management-report/) reported using AI tools and 96% use it consistently. At the individual level, **94% of product professionals** use AI daily or often. It is reshaping org charts, not just workflows: **98% of teams** have changed or plan to change team structures because of AI, while reporting roughly four hours saved per task and about 33 hours across core functions.

![Stat cards summarizing AI adoption among product teams and organizations](/blog/state-of-product-feedback-2026/ai-adoption.webp)

The stickiness is real. Across a 1,750-person survey, [83.6% named](https://www.lennysnewsletter.com/p/ai-tools-are-overdelivering-results) at least one AI tool they would be very disappointed to lose, and 63% of product managers say AI saves them four or more hours a week. The organizational base keeps widening too: [88% of organizations](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) now report regular AI use in at least one business function, up from 78% a year earlier, with generative AI use at 79%.

The next wave is agentic. Gartner predicts [40% of enterprise apps](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025) will feature task-specific AI agents by 2026, up from less than 5% in 2025, and that agentic AI will autonomously resolve [80% of common](https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290) customer service issues by 2029, cutting operational costs 30%. That matters for feedback because [85% of customer service leaders](https://www.gartner.com/en/newsroom/press-releases/2024-12-09-gartner-survey-reveals-85-percent-of-customer-service-leaders-will-explore-or-pilot-customer-facing-conversational-genai-in-2025) will explore or pilot customer-facing conversational generative AI in 2025, and that channel is where much product feedback originates. An [MCP server](/features/mcp) lets those agents read and triage your feedback directly, and AI duplicate detection and summaries collapse a thousand raw items into a handful of decisions. For the practical side, see [AI customer feedback analysis](/blog/ai-customer-feedback-analysis) and [connecting a feedback tool to AI via MCP](/blog/connect-feedback-tool-to-ai-via-mcp).

## Closing the loop and roadmaps

Collecting and prioritizing feedback is wasted if customers never see it return. Most do not. Only [16% of customers](https://www.customerexperiencedive.com/news/surveys-what-customers-want-behavior/753866/) strongly believe their feedback drives actual change, a trust gap that public roadmaps and visible loop-closing exist to fix. When the loop stays open, customers leave: [80% of customers](https://www.qualtrics.com/articles/customer-experience/qualtrics-servicenow-customer-service-research/) say they have switched brands because of a poor experience, and [49% of customers](https://www.zendesk.com/blog/cx-trends-2023-immersive-cx/) who left a brand they had been loyal to cite poor experience as the reason.

Closing it pays. In CustomerGauge's vendor research, closing the loop at every level reduced churn by at least [2.3% per year](https://customergauge.com/blog/close-the-loop) while failing to close it raised churn by at least 2.1%. Speed compounds the effect: closing the loop within 48 hours increased retention by **12%** and lifted NPS by an average of six points, and businesses that closed the loop after an NPS survey had **3x the promoters** in their next cycle. Customers also reward the gesture itself: [77% of consumers](https://info.microsoft.com/rs/157-GQE-382/images/2018StateofGlobalCustomerServiceReport.pdf) view brands more favorably when those brands proactively invite and act on feedback.

The alternative is expensive building. Pendo found [80% of features](https://www.pendo.io/resources/the-2019-feature-adoption-report/) in the average product are rarely or never used, and that publicly-traded cloud companies collectively invested up to **$29.5 billion** building features that may never be touched. A public [roadmap](/features/roadmap) and a regular [changelog](/features/changelog) turn that one-way spend into a two-way loop: customers see what is coming, vote on it, and watch it ship. For the discipline behind it, see [the customer feedback loop](/blog/customer-feedback-loop).

## Tooling and spend

The money flowing into software keeps the stakes high. Gartner forecasts worldwide public-cloud end-user spending at [$723.4 billion](https://www.gartner.com/en/newsroom/press-releases/2024-11-19-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-total-723-billion-dollars-in-2025) in 2025, up 21.5% year over year, with SaaS the largest single segment at roughly [$300 billion](https://www.ciodive.com/news/cloud-spend-growth-forecast-2025-gartner/733401/) in 2025, up from about $250 billion in 2024.

Much of that spend is wasted. Organizations waste an average of [$21 million annually](https://zylo.com/news/2025-saas-management-index) on unused SaaS licenses, a 14.2% year-over-year increase, and use only [49% of provisioned](https://zylo.com/news/2024-saas-management-index/) licenses. Per-head cost is rising fast: SaaS spend now averages **$4,830 per employee**, up 21.9% year over year, across an average portfolio of [342 applications](https://productiv.com/blog/saas-statistics-that-every-it-manager-should-see/).

This is where per-seat pricing on feedback tools quietly hurts. When half your provisioned seats sit idle, paying per seat for a feedback platform taxes the exact people you want contributing. Cost pressure is also pushing teams toward open source: [95% of organizations](https://www.perforce.com/press-releases/openlogic-perforce-release-2024-state-of-open-source-report) increased or maintained their open-source usage, 33% increased it significantly, and cost reduction was the top reason cited. Quackback fits that pattern: it is open source, self-hosted, and free, with no feature gates tied to pricing tiers. AI is built in. See the [pricing page](/pricing) and the [docs](/docs) to deploy.

## Methodology and sources

This report is compiled entirely from published industry research. None of the figures come from Quackback's own data. Each source is linked inline near its data; where one source supports several nearby figures, only the first carries the link, to keep the report readable. The full source list appears below. Figures are reported as the source published them, with corrections applied where a source's framing or sample size differed from how a figure is commonly repeated. Survey-based figures carry the sample sizes and years their publishers stated; some benchmarks are older and are flagged as such in context. Vendor research, where used, is identified as vendor research rather than independent study.

Sources cited in this report:

- **Product-Led Alliance and ProductPlan**, State of Product Management Report 2026 (Q4 2025 survey, ~250 product professionals)
- **Survicate**, Survey Response Rate Benchmarks 2025
- **Refiner**, In-App Survey Response Rates Benchmark Report 2025
- **Pendo**, In-App NPS Surveys (2017), Combining Product Data with In-App Feedback (2016), The 2019 Feature Adoption Report, and 2024 Software Benchmarks with Mind the Product
- **Productboard**, 2021 Product Excellence Report, 2024 State of Product Excellence Report, and The New Reality of AI in Product Management (2025, with UserEvidence)
- **Mountain Goat Software** citing Standish Group / Jim Johnson (XP 2002)
- **Bain & Company**, The Five Disciplines of Customer Experience Leaders (2015)
- **McKinsey & Company**, Experience-led growth (2023) and The State of AI in 2025
- **Harvard Business Review**, The Value of Keeping the Right Customers (2014) and Stop Trying to Delight Your Customers (2010)
- **Qualtrics XM Institute**, sales-at-risk reports (2024, 2025) and 2024 XMI Customer Ratings; Qualtrics and ServiceNow customer service research (2021)
- **Forrester**, CX Leaders Crush Laggards on Revenue Growth (2015) and 2024 US Customer Experience Index
- **Gartner**, NPS prediction (2021), conversational GenAI survey (2024), task-specific agents and agentic AI predictions (2025), public-cloud spending forecast (2024), and feedback-trust figure via Customer Experience Dive (2025)
- **Fortune**, Net Promoter Score reporting (2020)
- **SurveyMonkey**, What Is a Good CSAT Score?
- **Lenny's Newsletter** (Rachitsky and Segal), AI productivity survey (2025, n=1,750)
- **CustomerGauge**, Closed Loop Feedback research (vendor data)
- **Zendesk** CX Trends Report 2023 (citing Emplifi)
- **Microsoft**, 2018 State of Global Customer Service Report
- **Zylo**, 2024 and 2025 SaaS Management Index
- **OpenLogic by Perforce**, 2024 State of Open Source Report
- **Productiv**, 2024 SaaS statistics

## Frequently asked questions

### How many product teams collect feedback continuously?

Only [34% of product teams](https://www.productledalliance.com/product-management-statistics/) regularly collect insights and use them to guide prioritization, per the State of Product Management Report 2026. The rest work ad-hoc or have no consistent feedback process, despite customer needs ranking as the second-largest influence on product strategy.

### What percentage of software features actually get used?

[80% of features](https://www.pendo.io/resources/the-2019-feature-adoption-report/) in the average software product are rarely or never used, according to Pendo's 2019 Feature Adoption Report. For every 100 features launched, only [6.4 drive 80%](https://www.pendo.io/pendo-blog/product-benchmarks/) of click volume, and even best-in-class products see just 15.6% adoption.

### How much does customer experience affect revenue?

Companies that excel at customer experience grow revenue [4% to 8% above](https://www.bain.com/insights/the-five-disciplines-of-customer-experience-leaders/) their market, per Bain. Increasing retention by 5% raises profits 25% to 95%, while bad experiences put an estimated [$3.8 trillion](https://www.qualtrics.com/articles/customer-experience/trillion-sales-at-risk-2025/) in global sales at risk in 2025.

### How widely do product teams use AI in 2026?

AI use is near-universal. [100% of product teams](https://www.productboard.com/blog/ai-in-product-management-report/) use AI tools and 94% of professionals use it daily or often, per Productboard's 2025 research. Gartner predicts [40% of enterprise apps](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025) will feature task-specific AI agents by 2026.

### Does closing the feedback loop reduce churn?

Yes. Closing the loop at every level reduced churn by at least [2.3% per year](https://customergauge.com/blog/close-the-loop) in CustomerGauge's vendor research, and doing it within 48 hours raised retention 12%. Yet only [16% of customers](https://www.customerexperiencedive.com/news/surveys-what-customers-want-behavior/753866/) strongly believe their feedback drives actual change.

- [How to Migrate from Featurebase: A Step-by-Step Guide (2026)](https://quackback.io/blog/migrate-from-featurebase): A practical guide to migrating from Featurebase. What to export, how to map posts, votes, and statuses, and how to rebuild your roadmap and changelog.

Published: 2026-05-23

You have decided to leave Featurebase. Maybe per-seat pricing is no longer working as your team grows. Maybe you want self-hosting and full data ownership. Maybe you are paying for a bundled support inbox and help center you never use. Whatever the reason, the migration itself should not be the hard part.

![Migrating feedback data from Featurebase to a new tool](/blog/migrate-from-featurebase/hero.webp)

A feedback tool migration is simpler than migrating a database, a CRM, or an auth provider. Your core data is posts, votes, comments, users, and statuses. The process takes a few hours of preparation, an export, an import, and a week of communication.

This guide walks through the full process: what Featurebase lets you export, how to map your data, how to rebuild your roadmap and changelog, and how to communicate the switch to your users.

> **To migrate from Featurebase, export your feedback posts as CSV from Settings → Imports & Exports, then import them into your new tool.** Posts, upvote counts, statuses, tags, and author emails come across cleanly. Voter lists export per post as names and emails. Rebuild your roadmap, changelog, and integrations in the new tool, then point your custom domain at it. Most teams finish in three to five days.

## When it is time to leave Featurebase

Not every frustration justifies a migration. Switching tools has real costs — team retraining, user communication, and a brief period where your feedback workflow is disrupted. But some signals are clear.

**Per-seat pricing is scaling against you.** Featurebase uses per-seat pricing on every paid plan: **Growth** at $29/seat/mo, **Professional** at $59/seat/mo, and **Enterprise** at $99/seat/mo, all billed yearly. Every product manager, designer, engineer, and support agent who needs admin access adds to the bill. A ten-person team on Professional pays $590 per month before any AI usage. If your team is growing faster than your feedback volume, the pricing model is working against you. *Pricing last verified May 2026. Vendors may change plans without notice.*

**You are paying for scope you do not use.** Featurebase started as a feedback board and expanded into a support inbox, a help center, and an AI agent called Fibi that charges $0.49 per resolution. The breadth is real, but if you only want feedback collection, voting, roadmaps, and changelogs, you are subscribing to a support platform to get a feedback board. A focused tool costs less and stays out of your way.

**You need self-hosting or data ownership.** Featurebase is a closed-source SaaS product with no self-hosting option. If your security team requires data to stay on your infrastructure, or your compliance framework mandates it, Featurebase is not an option regardless of features.

**SSO is locked behind Enterprise.** Admin single sign-on is only available on Featurebase's $99/seat/mo Enterprise tier. If your organization requires SSO, that requirement alone can triple your per-seat cost.

If you are still weighing the decision, our [Quackback vs Featurebase comparison](/compare/quackback-vs-featurebase) lays out the feature and pricing differences side by side.

## What you can export from Featurebase

Featurebase provides data export through the admin dashboard, with richer migrations available through their API.

### Dashboard CSV export

From **Settings → Imports & Exports**, you can download your feedback posts as a CSV file. The export typically completes in under a minute and includes roughly 14 standard fields per post:

- **Post title and content**
- **Upvote count** (the aggregate number, not the individual voter list)
- **Creation date**
- **Author details** — name, email, user ID, and picture URL
- **Tags**
- **Board name**
- **Status**
- **ETA** and associated **MRR**
- **Custom field values**
- **Linked issue IDs and URLs** if you have connected an issue tracker like Jira

This is the easiest path for most migrations. No code required.

### Exporting voters

The post CSV gives you the upvote count, but not who voted. To capture voter lists, open a post, select **View upvoters** in the right panel, and use **Copy data** to copy each post's upvoters as names and emails. This is a per-post operation, so for a board with many posts you will either script around it or rely on an API-based import that pulls voters automatically.

### API migration

For complete migrations, Featurebase's own documentation describes an API-based import that captures posts, comments, voters, user data, and changelogs. Featurebase offers this as a paid-plan, support-assisted service when teams move *to* Featurebase. The same principle applies when you move *away*: an API export gives you the richest data, including:

- Full comment threads
- Per-post voter records (who voted, not just how many)
- Changelog entries
- Custom fields and metadata

If your destination tool exposes an API, scripting against the Featurebase API is the path that preserves the most signal. Quackback does not ship a Featurebase-specific adapter, so this route means writing a script that reads the Featurebase API and creates records through Quackback's API.

### What you cannot easily take with you

Some data does not migrate as a feedback record:

- **Support inbox conversations** — if you used Featurebase's help desk, those tickets stay behind
- **Help center articles** — knowledge base content is a separate export and may not map to a feedback tool at all
- **Fibi AI resolution history** — support automation logs stay in Featurebase
- **Analytics and engagement metrics** — page views and funnel data do not come across
- **Integration and webhook configurations** — these need to be recreated in your new tool

## Migration checklist

### Step 1: Audit your current data

Before exporting anything, understand what you have.

- **How many posts?** Hundreds are trivial. Thousands may justify the API route.
- **How many active voters?** These are the people you need to communicate with.
- **What statuses do you use?** Document your Featurebase statuses (Open, Under Review, Planned, In Progress, Complete, and any custom ones) so you can map them.
- **What boards, categories, and tags exist?** List them. You will recreate or map each.
- **Are you using the support inbox or help center?** Decide what happens to that content separately — it does not belong in a feedback migration.

### Step 2: Set up your new tool

Create your account or deploy your instance, then configure the basics before importing data:

- Create boards that match your Featurebase board structure, or take the opportunity to restructure
- Set up statuses that map to your Featurebase statuses
- Recreate categories and tags
- Add your team members and set permissions
- Configure your [feedback widget](/features/widget) or portal so it is ready for users after the switch

### Step 3: Export from Featurebase

Run your CSV export from **Settings → Imports & Exports**. If you need voters or comment threads, also export upvoter lists per post or use the API. Verify the data before proceeding:

- Spot-check that post counts match what you see in Featurebase
- Confirm that upvote counts look correct on your most popular posts
- Check that author emails are included — email is the join key for re-associating identities
- Note your status names exactly as they appear

### Step 4: Import into your new tool

How this works depends on your destination.

**Importing into Quackback:** Quackback's [CSV import](/features/import-export) reads a standard set of columns — title, content, status, tags, board, author name, author email, vote count, and creation date — and matches posts and votes to users by email. There is no dedicated Featurebase adapter, so you map your Featurebase export columns to those fields once, then import posts in a single pass. Pay attention to:

- **Vote mapping** — Featurebase exports an aggregate "upvote count" column. Map it to Quackback's `vote_count` field. Individual voter records need the per-post upvoter export or an API-based import.
- **Status mapping** — names differ between tools. Map "Under Review" or "Planned" to their equivalents.
- **User matching** — email is the join key for attributing posts and votes to people.
- **Date formats** — keep creation dates so historical context is preserved.

**If your new tool only has an API:** Write a migration script that reads your export and creates records through the destination API. More work, but the most control over how voters and comments map.

### Step 5: Verify the import

After importing, check:

- **Post count** — does it match your Featurebase export?
- **Vote counts** — pick five popular posts and verify the totals match
- **Statuses** — confirm Featurebase statuses landed on the correct new statuses
- **Comments** — if you imported them, check threading and authors
- **User profiles** — spot-check that emails and names came through

### Step 6: Rebuild your roadmap and changelog

Featurebase ties your roadmap and changelog to its post statuses. Your new tool does the same, but the structure needs to be rebuilt rather than imported.

- **Roadmap:** Once your posts carry the right statuses, your [public roadmap](/features/roadmap) populates from them. Verify that Planned and In Progress items appear in the columns you expect.
- **Changelog:** Featurebase changelog entries can export through the API. Recreate your most recent and most-visited entries in your new tool's [changelog](/features/changelog) so users who relied on it still find a history. Older entries can be archived rather than recreated one by one.

### Step 7: Update your integrations

If you had Featurebase connected to other tools, recreate those connections:

- **Slack** — reconnect to your feedback channels. See [collecting feedback in Slack](/blog/collect-feedback-in-slack).
- **Jira or Linear** — re-link issue tracking. If your CSV included linked issue IDs, use them to re-establish the connections.
- **Webhooks** — point any custom webhooks at your new tool's endpoints.
- **Widget embed** — replace the Featurebase widget script in your product with your new tool's widget.

### Step 8: Communicate the switch

This is the step most teams skip, and it causes the most friction.

**For your team:** Send a brief message explaining what changed, where the new feedback tool lives, and how the workflow differs. Do this before the switch, not after.

**For your users:** If you have a public-facing feedback portal, your users need to know where to go. Options:

- Email active feedback contributors — anyone who posted or voted in the last 90 days
- Post a changelog entry announcing the new feedback portal
- Update links in your product, help docs, and website

Keep the message simple: "We moved our feedback board. Your existing posts and votes have been migrated. Here is where to submit new feedback."

## URL redirects

Featurebase boards usually live at a subdomain or a custom domain you control. If you used a **custom domain** like `feedback.yourcompany.com` with a CNAME to Featurebase, you can repoint that DNS record to your new tool. Users keep the same URL and never notice the backend change. If your board was on a Featurebase subdomain you do not control, update all internal links in your product, docs, and website, and add a redirect page at any old URL you do control.

## Timeline

A realistic migration timeline for a team with under 5,000 posts:

| Day | Action |
|---|---|
| **Day 1** | Audit data, set up new tool, configure boards and statuses |
| **Day 2** | Export from Featurebase, import into new tool, verify data |
| **Day 3** | Rebuild roadmap and changelog, update integrations, replace widget embed |
| **Day 4** | Communicate to team and users, point custom domain, go live |
| **Day 5-7** | Monitor for issues, answer questions, verify nothing was missed |

For larger datasets or heavy use of comments and voter lists, add a day or two. But this is not a month-long project. Most teams complete the migration in under a week.

## After the migration

**Keep your Featurebase account active for 30 days.** Do not cancel immediately. You may need to reference historical data, re-export something that did not map cleanly, or handle a user who missed the announcement.

**Monitor your new feedback volume.** A temporary dip in submissions is normal after any tool switch. If volume does not recover within two weeks, check that your widget is working, your portal is discoverable, and your communication reached active users.

**Clean up stale data.** A migration is a good opportunity to close old posts that are no longer relevant. If a feature request has been open for two years with three votes, archive it to keep your board focused.

---
> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)
---

## Frequently asked questions

### Can I export my data from Featurebase?

Yes. Featurebase exports feedback posts as a CSV from Settings → Imports & Exports, including titles, content, upvote counts, statuses, tags, boards, and author emails. Voter lists export per post as names and emails. Comments and changelogs are available through the API.

### Will I lose votes if I migrate from Featurebase?

No. Featurebase's CSV export includes an aggregate upvote count per post, which maps directly to your new tool's vote field. If you need individual voter records, export upvoters per post or use the API. Votes re-associate to users by email.

### How long does a Featurebase migration take?

Most teams finish in three to five days, including communication. The actual export and import takes a few hours. The rest is configuring boards and statuses, rebuilding your roadmap and changelog, updating integrations, and notifying users.

### Does migrating from Featurebase include my support inbox and help center?

No. A feedback migration covers posts, votes, comments, and statuses. Featurebase's support inbox conversations and help center articles are separate products and stay behind. Export those independently if you need them, or move them to a dedicated support tool.

### Can I migrate from Featurebase for free?

Yes. Featurebase's CSV export is available without extra fees, and the cost of migration is mainly your team's time. Destination tools like [Quackback](/blog/open-source-feedback-tools) are open source and free to self-host, so you pay nothing for the software itself.

- [Featurebase vs Productboard: Which Is Right for You? (2026)](https://quackback.io/blog/featurebase-vs-productboard): A neutral comparison of Featurebase and Productboard in 2026. Features, pricing, pros and cons, and when an open-source alternative like Quackback fits better.

Published: 2026-05-18

Featurebase and Productboard both help product teams handle customer feedback, but they solve different problems. Featurebase bundles feedback, a changelog, a roadmap, and a support inbox into one tool aimed at SaaS teams. Productboard is an enterprise product management platform where feedback feeds a deeper prioritization and strategy workflow.

![Featurebase vs Productboard comparison with Quackback as an open-source alternative](/blog/featurebase-vs-productboard/hero.webp)

> **TLDR:** Featurebase is a feedback, changelog, and support tool for SaaS teams, priced per seat from $29/seat/mo (annual) with a free single-seat plan. Productboard is an enterprise product management platform priced per maker from $15/maker/mo (annual), built for prioritization and strategy. If you want an open-source option, [Quackback](https://quackback.io) is free to self-host and also runs as a managed cloud.

*Pricing last verified May 2026. Vendors may change plans without notice. Check each vendor's pricing page for the latest figures.*

If you're comparing both tools in 2026, the right choice depends on what you actually need to ship. A team that wants to collect feature requests, run a support inbox, and publish a changelog has different requirements than a product organization that needs to score features against objectives and align several teams on a roadmap.

This guide breaks down what each tool does well, where each falls short, how they compare on features and pricing, and when an open-source alternative is the better path. For a deeper look at one side, see the [Productboard pricing analysis](/blog/productboard-pricing).

## Featurebase overview

Featurebase is an all-in-one feedback and support platform that combines feedback boards, voting, a changelog, a help center, and a customer support inbox in a single product. It targets SaaS teams that want to collect feature requests and handle support conversations without stitching together separate tools.

The product covers the full public-facing loop: users submit feedback, vote on requests, and read changelog announcements when you ship. On top of that, Featurebase added a support suite with a unified inbox, live chat, a help center, and an AI agent named **Fibi** that can resolve support conversations automatically. The pitch is consolidation: feedback and support in one workspace rather than two subscriptions.

### Pricing

Featurebase uses per-seat pricing, with an AI charge layered on top. A seat is a full team member who manages feedback, support, or the workspace.

- **Free:** $0/mo for 1 seat. Includes the feedback board, roadmaps, changelog, a help center (up to 50 articles), live chat, unified inbox, and surveys. No AI.
- **Growth:** $29/seat/mo (billed annually). Adds the Fibi AI agent, AI Copilot, AI replies and macros, custom domains, basic analytics, and integrations.
- **Professional:** $59/seat/mo (billed annually). Adds workflows and automations, SLAs, user segmentation, multilingual support, API/MCP/webhooks, and 20 free Lite seats.
- **Enterprise:** $99/seat/mo (billed annually). Adds multi-brand workspaces, custom admin roles, admin SSO login, advanced HubSpot, Azure DevOps and AD integrations, and 50 free Lite seats.

AI resolutions cost an additional **$0.49 per resolution** on every paid plan, on top of the per-seat fee. Lite seats on Professional and Enterprise let you give limited read and comment access to teammates without paying full seat prices.

### Strengths

- **All-in-one workspace.** Feedback, changelog, roadmap, help center, and a support inbox in one tool. For teams that want fewer subscriptions, the consolidation is real.
- **Free single-seat plan.** A solo founder or indie hacker can run a feedback board, roadmap, and changelog at no cost.
- **AI support agent.** Fibi can resolve support conversations and draft replies, which helps teams handling a high ticket volume.
- **Modern, polished interface.** The product feels current and is straightforward to set up for the core feedback and changelog workflow.

### Weaknesses

- **Per-seat pricing adds up.** Every full team member is a seat. A support team plus a product team can grow the seat count quickly, and AI resolutions bill separately at $0.49 each.
- **SSO requires Enterprise.** Admin SSO login is gated to the $99/seat/mo Enterprise plan.
- **AI starts on paid plans.** The free plan has no AI. You need Growth or higher before Fibi, Copilot, or AI replies are available.
- **No self-hosting.** Featurebase is hosted SaaS only. No way to run it on your own infrastructure or audit the source.
- **Light on strategy tooling.** Featurebase covers the feedback-and-support loop well, but it doesn't offer the custom prioritization scoring or objectives alignment that Productboard provides.

For a head-to-head, see the [Quackback vs Featurebase comparison](/compare/quackback-vs-featurebase) and the [best customer feedback tools in 2026](/blog/best-customer-feedback-tools-2026).

## Productboard overview

Productboard is a product management platform built for mid-size and enterprise product organizations. Feedback collection is one capability inside a larger system that includes prioritization frameworks, opportunity mapping, driver-based roadmaps, and strategic alignment tools.

The feedback side works through a portal where users submit ideas and vote, plus an insights system that pulls feedback from support tickets, sales calls, surveys, email, and manual notes. What sets Productboard apart is what happens after feedback arrives: product managers link insights to features, score features using custom prioritization criteria, map them to objectives, and build roadmaps that reflect company priorities rather than raw vote counts.

### Pricing

Productboard revamped its pricing in 2026 around a single plan called **Spark**. The old Essentials, Pro, Scale, and Enterprise tiers are no longer listed. Pricing is per maker, where a maker is anyone who creates or edits features, roadmaps, or insights. Contributors who only view roadmaps and submit feedback are free.

- **Spark:** $15/maker/mo (billed annually) or $19/maker/mo (monthly). Includes the feedback portal, insights, feature prioritization, roadmaps, and AI via credits, with 250 credits per maker per month.
- **Enterprise:** Custom pricing for SSO/SAML, advanced security, custom roles, dedicated support, and custom credit limits.

AI is no longer a separate add-on. It runs on a credits system: 250 credits per maker per month, pooled across the workspace. New signups get a one-time allocation of 150 free credits to trial AI. Extra credits sell in bundles ($5 per 50 credits monthly, or $60/year for 50/month on annual plans). For a detailed cost analysis, see [Productboard pricing in 2026](/blog/productboard-pricing).

### Strengths

- **Product strategy tools.** Prioritization matrices, opportunity scoring, objectives alignment, and driver-based roadmaps. No feedback-first tool offers this depth.
- **Insights from everywhere.** Capture feedback from support tickets, sales calls, surveys, email, CRM, and manual notes, all flowing into one repository.
- **Multi-team alignment.** Several product teams can share insights, align on objectives, and coordinate roadmaps that roll up to a company view.
- **Enterprise integrations.** Deep CRM and issue-tracker integrations let revenue data weight feature requests by customer value.

### Weaknesses

- **Costs grow with team size.** A 10-maker team on Spark pays $150/mo (annual) or $190/mo (monthly). Enterprise contracts with SSO cost more.
- **AI credits can run out.** The 250 credits per maker per month power all AI interactions. Heavy users may exhaust them before the month ends.
- **Steep learning curve.** The interface is complex. Onboarding a team takes weeks, not days.
- **No native changelog.** Productboard focuses on the upstream process. It doesn't include a changelog to announce what you shipped.
- **No self-hosting.** Hosted SaaS only, like Featurebase.

For alternatives, see [best Productboard alternatives in 2026](/blog/best-productboard-alternatives).

## Feature comparison

Here's how Featurebase, Productboard, and Quackback compare across the features that matter for feedback management and product planning.

| Feature | Featurebase | Productboard | Quackback |
|---|---|---|---|
| **Feedback boards** | Yes | Yes (portal + insights) | Yes |
| **Voting** | Yes | Yes | Yes |
| **Public roadmap** | Yes | Yes (portal roadmap) | Yes |
| **Changelog** | Yes | No | Yes |
| **Support inbox** | Yes | No | Yes (inbox) |
| **AI features** | Fibi ($0.49/resolution) | Included via credits (250/maker/mo) | Included |
| **MCP server** | Yes (Professional+) | No | Yes |
| **Integrations** | On paid plans | 20+ on Spark | 20+ included |
| **API** | REST API (Professional+) | REST API | REST API |
| **SSO** | Enterprise ($99/seat/mo) | Enterprise (custom pricing) | Free self-hosted · Enterprise on Cloud |
| **Self-hosting** | No | No | Yes (Docker) |
| **Open source** | No | No | Yes (AGPL-3.0) |
| **Starting price** | Free (1 seat) | $15/maker/mo (annual) | Free self-hosted / $29/mo Cloud |
| **Prioritization framework** | Community voting | Advanced (custom scoring, drivers) | Community voting + AI insights |
| **Duplicate detection** | Basic | Manual | AI-powered |

The three tools cover different ground. Featurebase leans into the feedback-plus-support loop, Productboard into strategy and prioritization, and Quackback into an open-source feedback platform you own. Featurebase and Productboard gate some features (SSO, advanced AI, multi-brand) behind higher tiers, which is standard for SaaS. Quackback includes everything on every self-hosted installation, but you manage your own infrastructure.

## Pricing comparison

What each tool costs depends on your team size and how AI usage scales. Here's a side-by-side estimate at different scales.

### Small team (3 product/support people)

| | Featurebase | Productboard | Quackback |
|---|---|---|---|
| **Plan needed** | Growth | Spark | Self-host or Cloud Pro |
| **Monthly cost** | $87/mo (3 seats x $29 annual) | $45/mo (3 makers x $15 annual) | Self-host ~$10 · Cloud $29/mo Pro (5 seats) |
| **Annual cost** | $1,044 | $540 | Self-host ~$120 · Cloud $348 |
| **AI cost** | $0.49 per resolution on top | Included (750 credits/mo) | Self-host: your LLM bill. Cloud: included Quinn usage, then $10 top-up packs. |

### Mid-size team (8 product/support people)

| | Featurebase | Productboard | Quackback |
|---|---|---|---|
| **Plan needed** | Professional | Spark | Self-host or Cloud Business |
| **Monthly cost** | $472/mo (8 seats x $59 annual) | $120/mo (8 makers x $15 annual) | Self-host ~$20 · Cloud $59/mo Business (20 seats) |
| **Annual cost** | $5,664 | $1,440 | Self-host ~$240 · Cloud $708 |
| **AI cost** | $0.49 per resolution on top | Included (2,000 credits/mo) | Self-host: your LLM bill. Cloud: included Quinn usage, then $10 top-up packs. |
| **SSO** | Enterprise only ($99/seat/mo) | Enterprise only (custom) | Free self-hosted · Enterprise on Cloud |

### Larger team (20 product/support people)

| | Featurebase | Productboard | Quackback |
|---|---|---|---|
| **Plan needed** | Enterprise (for SSO) | Enterprise | Self-host or Cloud Enterprise |
| **Monthly cost** | $1,980/mo (20 seats x $99 annual) | $300/mo (20 makers x $15 annual) + enterprise features | Self-host infra · Cloud $99/mo Enterprise |
| **Annual cost** | $23,760 | $3,600+ (enterprise with SSO likely higher) | Self-host infra · Cloud $1,188 |

Each pricing model scales differently. Featurebase charges per seat plus $0.49 per AI resolution, so a combined support-and-product team grows costs on two axes. Productboard's per-maker billing keeps viewers and contributors free but charges every maker. Quackback Cloud is a flat workspace price from $29/mo billed annually (Free plan, 1 seat), with portal users free. Self-host is $0 software plus infrastructure and your own LLM usage. The right model depends on which dimension you expect to grow fastest.

*Pricing last verified May 2026. Vendors may change plans without notice.*

## When to choose Featurebase

Featurebase is the right fit when you want feedback and customer support in one workspace and the per-seat model matches your team size.

**Choose Featurebase if:**

- You want feedback and support together. The combined feedback board, changelog, help center, and support inbox is the core pitch. If you'd otherwise pay for a separate support tool, the consolidation saves a subscription.
- You're a solo founder or small team. The free single-seat plan covers the feedback board, roadmap, and changelog at no cost, which is generous for getting started.
- You handle a high support volume. Fibi, the AI support agent, and AI replies help teams resolve tickets faster, though each resolution bills at $0.49.
- Your seat count stays small. Per-seat pricing stays reasonable when only a handful of people manage the workspace. Lite seats extend limited access without full seat fees.

Where Featurebase struggles: large teams where per-seat costs climb fast, organizations that need SSO without the $99/seat Enterprise tier, teams that want strategic prioritization tooling, and anyone who needs to self-host or audit the source.

## When to choose Productboard

Productboard is the right fit for product organizations that need more than feedback collection: teams that connect customer insights to strategy, prioritize with data, and align multiple stakeholders.

**Choose Productboard if:**

- You need strategic product management tools. Opportunity scoring, prioritization frameworks, objectives alignment, and driver-based roadmaps are Productboard's core strength. If your team debates priorities in spreadsheets and wants a structured process, Productboard provides it.
- Your product org has multiple teams. Productboard handles the coordination problem: shared insights, team-level roadmaps that roll up to a company view, and cross-team visibility into what's being built and why.
- You need deep CRM integration. Tying feature requests to customer revenue data lets product managers see which features affect the most ARR. This matters for enterprise SaaS.
- You have budget for it. Productboard is a significant investment. If your organization budgets for product tooling at the enterprise level, the cost is justifiable. For a bootstrapped startup, it's not.

Where Productboard struggles: small teams that just need a voting board, budget-conscious organizations, teams that want fast setup, and anyone who needs a changelog or self-hosting.

## Consider Quackback if...

Neither Featurebase nor Productboard is the only path. If the trade-offs of both don't sit well with you, [Quackback](https://quackback.io) takes a fundamentally different approach.

**You want to avoid vendor lock-in.** Quackback is open source under AGPL-3.0. The code is available, auditable, and forkable. You're not dependent on a vendor's pricing decisions, feature roadmap, or continued existence. If Quackback the company disappeared tomorrow, the software keeps running on your server.

**You want everything in one installation.** No feature gates by tier. One installation gives you everything: [feedback boards](/features/feedback), [voting](/features/voting), a public [roadmap](/features/roadmap), a [changelog](/features/changelog), a support [inbox](/features/inbox), 25 integrations, [SSO](/features/sso), custom branding, and [REST API](/features/api) access.

**You want AI analysis built in.** Quackback includes duplicate detection, theme summaries, and feedback ingestion from Slack and email on every self-hosted installation. Productboard caps AI at 250 credits per maker each month. Featurebase bills $0.49 per AI resolution. Quackback Cloud includes Quinn on paid plans and no per-resolution fee.

**You want an MCP server.** Quackback's [MCP server](/features/mcp) implements the Model Context Protocol, the standard supported by Claude, Cursor, and Windsurf. Connect an AI agent and it gets full access to your feedback data: search posts, triage requests, write responses, create changelog entries, and merge duplicates.

**You want to self-host.** Deploy with Docker. Your data lives in your own PostgreSQL database on your infrastructure. Full control over backups, access, and compliance. This matters for teams with data residency requirements or organizations that can't send customer feedback to a third-party SaaS platform. If you'd rather not run servers, the managed Quackback Cloud is live.

**The trade-off:** with self-hosting you manage your own infrastructure instead of paying a SaaS vendor. For teams with DevOps capacity, a $10–20/mo VPS runs the full platform. For teams that want it managed, Quackback Cloud handles hosting for you.

For detailed head-to-head comparisons, see [Quackback vs Featurebase](/compare/quackback-vs-featurebase) and [Quackback vs Productboard](/compare/quackback-vs-productboard). For a broader look at the open-source landscape, see [open-source feedback tools](/blog/open-source-feedback-tools).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Is Featurebase or Productboard better for a small SaaS team?

Featurebase fits most small SaaS teams better. It bundles feedback, changelog, roadmap, and a support inbox in one tool, and its free single-seat plan covers the basics at no cost. Productboard's strength is strategic prioritization, which small teams rarely need yet. For a free option, [Quackback](https://quackback.io) self-hosts at no cost.

### How much do Featurebase and Productboard cost?

Featurebase starts free for one seat, then $29/seat/mo (Growth), $59/seat/mo (Professional), and $99/seat/mo (Enterprise), all billed annually with $0.49 per AI resolution. Productboard's Spark plan is $15/maker/mo annual or $19/mo monthly, with 250 AI credits per maker. *Pricing last verified May 2026.*

### Do Featurebase or Productboard offer self-hosting?

No. Both are hosted SaaS products with no self-hosting option. Your feedback data lives on their infrastructure, and you're subject to their pricing changes. If self-hosting, data ownership, or open-source licensing matters, [Quackback](/compare/quackback-vs-productboard) is the primary alternative: AGPL-3.0 licensed, deployed with Docker, storing everything in your own PostgreSQL database.

### Can I use Productboard just for feedback collection?

You can, but it's not a good use of the tool. Productboard's value is prioritization, opportunity scoring, and strategic alignment after feedback arrives. If you only need a portal and voting board, you pay for capabilities you won't use. Featurebase or [Quackback](https://quackback.io) serve the feedback-only use case more affordably.

### Which tool has the better free plan?

Featurebase has a usable free plan with one seat covering feedback boards, roadmap, and changelog. Productboard has no free plan, only a one-time 150 AI credits to trial Spark. [Quackback](/compare/quackback-vs-featurebase) is free to self-host with all features included.

- [How to Sync Customer Feedback to Linear, Jira, and GitHub (Two-Way) in 2026](https://quackback.io/blog/sync-feedback-to-issue-tracker): Connect your feedback board to Linear, Jira, GitHub, and more with genuine two-way sync. Carry vote counts and user context, and auto-notify requesters on ship.

Published: 2026-05-14

Your feedback lives in one tool. Your engineers live in another. Every time a request becomes real work, someone copies it across by hand, strips out the context, and forgets to tell the person who asked. The request gets built. The customer never finds out.

![Feedback syncing two ways between a feedback board and an issue tracker](/blog/sync-feedback-to-issue-tracker/hero.webp)

That broken handoff is where most feedback dies. Not at collection, where teams invest heavily, but at the seam between the feedback board and the issue tracker. This guide covers how to close that seam: one-way push versus genuine two-way sync, how to connect Linear, Jira, and GitHub without losing user context, how to map feedback statuses to tracker workflows, and how to notify the requester automatically when their feature ships.

> **Two-way sync** keeps a feedback post and its linked issue in lockstep across both directions: the issue inherits the vote count and user context from the feedback, and when an engineer closes the issue, the feedback post updates and every voter is notified automatically. One-way push only sends data into the tracker, so the loop never closes. Quackback offers genuine two-way sync across Linear, Jira, GitHub, GitLab, Asana, ClickUp, and Shortcut.

## Why connect feedback to your issue tracker at all

Feedback that lives only on a feedback board is half a system. The product team can see what users want, but engineers plan and build in Linear, Jira, or GitHub. If those two worlds never connect, three things break.

**Engineers lose the "why."** A ticket that reads "add bulk export" tells a developer nothing about who asked, how many people care, or what problem it solves. The demand signal stays trapped on the feedback board while the work happens somewhere it cannot see.

**Product managers maintain two systems by hand.** Without a connection, a PM updates the feedback post when planning starts, updates the tracker when work begins, and updates the post again when it ships. Most of the time the second and third updates never happen, so the board drifts out of date and stops being trustworthy.

**Customers never hear back.** The request gets built, the issue closes, and the person who asked finds out by accident months later, if at all. That silence is the single biggest reason users stop giving feedback. Closing the [customer feedback loop](/blog/customer-feedback-loop) is what turns a one-time request into a retained, engaged user.

Connecting your tracker fixes all three at once. The demand context travels with the work, the systems stay in sync without manual effort, and the requester gets told when it ships.

## One-way push vs two-way sync

Most feedback tools advertise an "integration" with your issue tracker. Read the fine print, because there are two very different things hiding behind that word.

**One-way push** sends data in a single direction. You click a button on a feedback post and a new issue appears in your tracker. That is the end of the relationship. If an engineer later closes the issue, nothing happens on the feedback board. The PM still has to notice, update the post by hand, and tell the voters. One-way push saves you the copy-paste at creation time, but the loop stays open.

**Two-way sync** keeps both records aligned continuously. Creating the issue carries the feedback context into the tracker. Then, when the issue's status changes in either system, the change propagates to the other. Move a Linear issue to Done and the linked feedback post flips to Shipped on its own. Mark a feedback post as Planned and the connected issue can reflect that too. The two records describe the same work from two angles, and neither goes stale.

| | One-way push | Two-way sync |
|---|---|---|
| **Creates issue with context** | Yes | Yes |
| **Issue close updates the post** | No | Yes |
| **Voters notified on ship** | Manual | Automatic |
| **Board stays accurate** | No | Yes |
| **Manual PM upkeep** | High | None |

The difference matters most at the moment a feature ships, because that is when you have a reason to re-engage every person who asked for it. One-way push wastes that moment. Two-way sync captures it automatically.

## How to sync feedback to Linear

Linear organizes work into issues that move through workflow states, and every state belongs to one of five types: backlog, unstarted, started, completed, and canceled. That structure maps cleanly onto a feedback lifecycle, which is what makes the sync reliable.

To connect the two with [Quackback's Linear integration](/integrations/linear):

1. **Authorize Linear over OAuth.** Connect your Linear workspace from the integrations page. There are no API keys to rotate or store.
2. **Map teams and projects.** Choose a default Linear team, project, and labels for each feedback board, so new issues land in the right backlog already categorized.
3. **Create an issue from a feedback post.** One click pre-fills the Linear issue with the post title, description, and vote count, and lets you set team, project, and cycle before submitting.

From there the sync runs on its own. When an engineer moves the issue from In Progress to Done, the linked feedback post transitions to Shipped, and every voter receives an email. The PM never touches the board. The demand context, including how many people requested the feature, sits on the Linear issue where the engineer planning the cycle can actually see it.

## How to push to Jira without losing user context

The usual complaint about Jira integrations is that the ticket arrives naked. A title, maybe a description, and nothing about who asked or why it matters. That happens because most integrations push only the text and drop everything else.

The fix is field mapping. Jira sorts every status into one of three categories, To Do, In Progress, and Done, and lets you map external data onto issue fields. The [Quackback Jira integration](/integrations/jira) uses that to carry the full demand signal across:

- **Vote count** maps to a custom field, so you can sort your Jira backlog by how many users requested each item.
- **Tags** map to Jira labels, so feedback arrives categorized.
- **Board** maps to a Jira project, so requests route to the right team automatically.
- **A backlink** to the original feedback post lets anyone in Jira jump to the user comments and discussion.

The payoff shows up in sprint planning. Instead of guessing which candidate tickets users actually want, the team sorts by vote count and prioritizes on evidence. And because Jira transitions are one-way links between statuses, the integration listens for the transition into a Done-category status and uses that as the signal to update the feedback post and notify the requester. Connect your Jira Cloud site over OAuth, map the fields once, and the context flows on every issue you create.

## GitHub Issues as a user-facing roadmap

GitHub is home for developer tools and open-source projects, but it is a hostile front door for non-technical users. Filing a well-formed issue with the right labels and a reproducible example is a skill most of your users do not have, so they stay silent and you lose the signal.

A feedback board solves the front-door problem. Users submit and vote in a friendly interface, and you promote the most-wanted requests into [GitHub Issues](/integrations/github) when you decide to act. The issue is created with the post content, mapped labels and milestones, and a backlink to the board. When a maintainer or contributor closes the issue, the feedback post flips to Shipped and voters are notified.

This split lets your public [roadmap](/features/roadmap) do double duty. Contributors see exactly which user requests each open issue addresses, complete with vote counts and milestones, while users follow progress on a board they can actually navigate. You keep engineering work in GitHub, where it belongs, without forcing every user to learn the GitHub Issues workflow first. Private repositories work the same way once you authorize access during setup.

## Mapping feedback statuses to tracker workflows

Two-way sync only works if the two systems agree on what each status means. A feedback post has its own lifecycle, usually something like Open, Under Review, Planned, In Progress, and Shipped. Each tracker has its own vocabulary. The job of the integration is to map between them so a status change in one is unambiguous in the other.

Here is how Quackback maps a typical feedback lifecycle onto each tracker's native states:

| Feedback status | Linear | Jira | GitHub |
|---|---|---|---|
| **Planned** | Backlog / Todo | To Do category | Open + milestone |
| **In Progress** | In Progress (started) | In Progress category | Open + assignee |
| **Shipped** | Done (completed) | Done category | Closed |

The key design choice is to map on status *category*, not on a specific named state. Linear teams rename "Done" to anything they like, Jira admins create custom statuses, and GitHub only has open and closed. By keying on the underlying category, the sync keeps working even when a team customizes its workflow. You define the mapping once during setup, and from then on a transition into any completed-category state counts as "shipped." This is the same principle that keeps the sync reliable across [every supported tracker](/integrations), from ClickUp custom statuses to Asana task completion.

## Auto-notifying the requester on ship

The whole point of two-way sync is the last step, and it is the one teams skip most often without it: telling the person who asked.

When a linked issue closes in your tracker, the status change propagates to the feedback post, and Quackback emails every voter and subscriber a branded notification that their requested feature shipped. No PM has to remember. No one writes the email. The action that engineers take anyway, closing the issue, becomes the trigger for a customer touchpoint.

That single automated email does real work. A user who requested a feature six months ago and forgot about it gets a reason to come back and try the product again. A prospect who was told "it's on the roadmap" gets proof you delivered. Teams that close this loop see feedback volume go *up*, because users learn that submitting a request actually leads somewhere. The same notification fires for feedback captured anywhere upstream, including requests that started life in [a Slack channel](/blog/collect-feedback-in-slack) and flowed through to a shipped Linear issue.

## Where Quackback fits

If you have evaluated feedback tools, you have probably found that "issue tracker sync" usually means one-way push to a single tool. Quackback's difference is genuine two-way sync across a wide set of trackers, with the demand signal carried on the issue and the requester notified on close.

- **Seven trackers, one model.** Linear, Jira, GitHub, GitLab, Asana, ClickUp, and Shortcut all sync both ways, with the same vote-count-and-context behavior on every one.
- **Context travels with the work.** Every created issue carries the vote count, user comments, and a backlink, so engineers plan with real demand data in front of them.
- **Self-hosted or managed.** Quackback is open source under AGPL-3.0. Self-host it free or use the managed Cloud.
- **AI and a roadmap built in.** Duplicate detection keeps your board clean before issues are ever created, and the public roadmap and changelog close the loop for users who do not get the email.

---
> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)
---

## Frequently asked questions

### What is the difference between one-way push and two-way sync?

One-way push creates an issue in your tracker from a feedback post and stops there. Two-way sync keeps both records aligned continuously, so closing the issue updates the feedback post and notifies voters automatically. Only two-way sync closes the feedback loop without manual work.

### Does Quackback support two-way sync with Linear, Jira, and GitHub?

Yes. Quackback offers genuine two-way sync with Linear, Jira, GitHub, GitLab, Asana, ClickUp, and Shortcut. Issues carry the vote count and user context, and closing a synced issue updates the linked feedback post and notifies every voter by email.

### How do feedback statuses map to issue tracker workflows?

Quackback maps on status category rather than a specific named state. A feedback "Shipped" status corresponds to Linear's completed type, Jira's Done category, or a closed GitHub issue. Keying on category keeps the sync working even when a team customizes its workflow.

### Can I keep user context on the issue when I push to Jira?

Yes. The Jira integration maps vote count to a custom field, tags to labels, and the board to a project, and adds a backlink to the original post. Your Jira backlog carries the demand signal so the team can prioritize by how many users requested each item.

### Will the person who requested a feature know when it ships?

Yes. When a linked issue closes in your tracker, the feedback post transitions to Shipped and every voter and subscriber receives a branded email automatically. The engineer closing the issue is the only action required to trigger the notification.

- [Feature Voting: How to Let Users Prioritize Without a Popularity Contest](https://quackback.io/blog/feature-voting): Feature voting turns user requests into ranked demand data. Learn single vs weighted voting, how to stop gaming and vote fragmentation, and how to act on votes.

Published: 2026-05-09

Most teams add a voting board, watch the upvotes pile up, and then realize the rankings tell them what their loudest users want, not what their business needs. Feature voting is supposed to replace guesswork with evidence. Done badly, it just replaces one bias with another. This guide shows you how to run voting so it informs real decisions instead of staging a popularity contest.

![A ranked feature voting board with vote tallies surfacing the most-requested ideas](/blog/feature-voting/hero.webp)

> Feature voting is a system that lets users upvote product requests so demand becomes a ranked, quantified signal instead of a pile of anecdotes. It beats raw request counts because one consolidated post with 200 votes is clearer than 200 scattered tickets. To avoid a popularity contest, weight votes by customer value, prevent duplicate fragmentation, and treat votes as input to prioritization rather than a binding poll.

## What is feature voting?

Feature voting is a mechanism that lets users upvote feature requests to signal demand, producing a ranked list of what your user base wants most. Instead of reading a hundred support tickets and guessing which need is widespread, you see exactly how many people asked for each capability and who they are.

The mechanics are simple. Users submit ideas to a [feedback board](/features/feedback), browse what others have posted, and click to upvote the requests they care about. Each post accumulates votes in real time. Sort by votes and the most-wanted features rise to the top. Quackback adds [one-click voting](/features/voting) for both anonymous and authenticated users, so the friction between wanting a feature and registering that want is a single tap.

Voting is not the same as a poll. A poll asks users to choose from options you defined, which limits you to needs you already anticipated. Voting lets users propose their own ideas and rank each other's, surfacing demand you never thought to ask about. That is the difference between confirming your assumptions and discovering what you missed.

## Why votes beat raw request counts

A raw request count tells you how many times something was mentioned. A vote count tells you how many distinct people want it. Those are different numbers, and the gap matters.

Without voting, the same feature shows up as five support tickets, three sales notes, and a Slack thread. You count six mentions and treat it as moderate demand. With a voting board, those signals consolidate into one post that 240 people upvoted. The request did not get more popular. You finally measured it accurately.

Votes also give you defensible prioritization. Product managers are constantly asked to justify why one thing shipped before another. "I think users want this" loses every argument. "247 users voted for this, and here are their comments" wins. Voting converts opinion into evidence your stakeholders can audit. For the framework side of turning that evidence into a sequence, see [how to track and prioritize feature requests](/blog/feature-request-tracking) and the [RICE scoring framework](/blog/rice-framework-explained).

There is one catch. Raw vote counts favor whatever your largest segment wants, which is usually your free tier. That is where voting tips into a popularity contest, and where the next few sections matter most.

## Single voting vs weighted voting

The default everywhere is **single voting**: every user gets one vote per post, and all votes count equally. It is simple, transparent, and resistant to obvious manipulation. It is also blind to who is voting.

**Weighted voting** (sometimes called value voting) assigns different weight to votes based on the voter. Ten upvotes from enterprise accounts paying $50,000 a year are not the same business signal as ten from free-trial users who may churn next week. Weighting lets you reflect that.

You can weight along a few axes:

- **Revenue or plan tier.** Surface what paying customers want above what the free tier wants.
- **Company size or segment.** See which features matter to the accounts you are trying to land or retain.
- **Account health or strategic fit.** Give weight to the customers whose renewal you most need to protect.

The trade-off is honesty. Weighting is the right call for most B2B products, where a handful of accounts drive most of the revenue. But it can quietly bury what your broad user base needs, and an opaque weighting scheme erodes trust if users notice that their votes do not move the board. Keep the public board showing real vote counts, and apply weighting in your internal prioritization view rather than rewriting the numbers users see.

In practice, segmentation gets you most of the value without the downsides. Rather than baking weights into the tally, filter and sort the same vote data by plan, revenue, or company. Quackback and [Featurebase](/compare/quackback-vs-featurebase) both let you slice votes by customer attributes, though Featurebase places user segmentation on its Professional plan at $59 per seat per month. *Pricing last verified May 2026. Vendors may change plans without notice.*

## Preventing gaming and vote fragmentation

Two problems quietly corrupt vote data. One is gaming. The other is fragmentation. Fragmentation is the more common and the more damaging.

### Vote fragmentation

**Vote fragmentation** happens when the same underlying request exists as several separate posts, splitting the votes across all of them. "Dark mode," "night theme," and "darker UI option" might each collect 40 votes. Your real top request has 120 votes and looks like three mediocre ones. You build the wrong thing because the data lied to you.

The fix is deduplication and merging. The strongest version catches duplicates at submission time, before they fragment anything. Quackback uses AI [duplicate detection](/features/voting) to flag when a new post matches an existing one, then suggests a merge that consolidates the votes and the comments into a single thread. The 120 votes stay together where you can see them. Tools without this require you to manually review new posts every week and merge by hand, which works until your board gets busy and then quietly stops working.

### Gaming and vote integrity

Gaming is when someone inflates a count, usually by voting repeatedly. The defense is vote integrity: one vote per user per post. Authenticated voting ties each vote to an account, which makes manipulation hard and gives you accurate per-account data. Anonymous voting lowers friction but needs a guard such as browser fingerprinting to stop trivial repeat votes. Quackback enforces one vote per user, supports both anonymous and authenticated voting, and gives admins override tools to clean up bad votes without policing the board manually.

A quieter form of gaming is internal: a single sales rep filing twenty separate requests on behalf of one account to make it look like broad demand. The answer is the same as fragmentation. Consolidate to the account, and let one customer count as one customer.

## Voting on behalf of customers

Not everyone who wants a feature will visit your board. Enterprise buyers mention requests on calls. Support agents hear the same ask ten times a day. If those signals never reach the board, your vote data systematically under-counts your most valuable customers, which is exactly backward.

**Vote-on-behalf** lets your team record a vote for a customer who told you about a need through another channel. The agent on the support call adds the customer's vote to the existing post instead of asking them to go log in and click. The board now reflects real demand, including the demand that arrives through humans rather than the widget.

This is where several tools differ. [Featurebase](/compare/quackback-vs-featurebase)'s Fibi AI agent can submit votes on behalf of customers during support conversations. [Canny](/compare/quackback-vs-canny) discovers requests inside connected support tools and attributes them, though its tracked-user pricing means every voter you add is a billable user, and revenue-weighted prioritization sits on its Growth plan. *Pricing last verified May 2026. Vendors may change plans without notice.* Quackback lets your team vote on behalf of a customer and attribute it to their account, so a single agent recording a real customer ask strengthens the signal instead of inflating it. Because votes consolidate through dedup and merge, those on-behalf votes land on the right post rather than spawning a new fragment.

## Turning votes into decisions

A voting board is not a vending machine where the top item ships automatically. Votes are an input to prioritization, not a verdict. Treating them as binding is how teams build for their noisiest users and neglect strategy. Here is how to act on votes without surrendering judgment:

1. **Read the comments, not just the count.** Two posts with 100 votes can describe very different urgency. The comments tell you the why. A request with 100 votes and detailed workflow descriptions is a stronger signal than 100 silent upvotes.
2. **Cross-reference with a framework.** Run your top-voted items through [RICE](/blog/rice-framework-explained) or a similar method. Reach is what votes measure well. Impact, confidence, and effort still need your input.
3. **Segment before you rank.** Look at who voted. Filter by plan or revenue so a feature wanted by ten enterprise accounts is not buried under one wanted by a thousand free users who will not pay for it.
4. **Reserve room for strategy.** Some of the most important work has few votes because users cannot vote for what they cannot imagine. Protect roadmap space for bets that move the product forward even when the board is quiet on them.
5. **Close the loop.** When you ship a voted feature, notify the voters. When you decline one, say why. Quackback notifies voters automatically through status changes and the [changelog](/features/changelog), which keeps people voting because they see that voting leads to action.

The teams that get the most from feature voting treat it as a continuous demand signal feeding a deliberate prioritization process, not as a leaderboard that dictates the sprint. For a deeper comparison of the platforms that support this workflow, see our [ranked guide to the best feature voting tools](/blog/best-feature-voting-tools). For the underlying concept of the [feedback board](/glossary/feedback-board) that hosts the votes, see the glossary.

## Why Quackback handles voting differently

Quackback is built so vote data stays accurate as your board scales. AI duplicate detection and one-click merge keep votes consolidated, so your top request never hides behind three half-counted clones. Vote-on-behalf lets your team capture demand from support and sales calls and attribute it to the right account. Voter segmentation lets you weight by customer value in your internal view without distorting the public count. An [MCP server](/features/mcp) lets AI assistants query and triage vote data directly.

---
> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)
---

## Frequently asked questions

### What is the difference between single and weighted feature voting?

Single voting gives every user one equal vote per request, which is simple and transparent. Weighted voting assigns more value to votes from certain users, such as high-revenue accounts. Most B2B teams keep public counts unweighted and apply weighting through segmentation in an internal prioritization view.

### How do I stop duplicate posts from splitting my vote counts?

Use a tool with AI duplicate detection that flags matching requests at submission time and suggests a merge. Merging consolidates votes and comments into one post, so your most-requested feature shows its true total. Without it, review new submissions weekly and merge related posts by hand.

### Can my team vote on behalf of customers?

Yes, with tools that support vote-on-behalf. When a customer mentions a request on a call or in support, an agent records the vote against the existing post and attributes it to that account. Quackback supports this, so demand arriving through humans still reaches your board accurately.

### Does the most-voted feature have to be built next?

No. Votes are an input to prioritization, not a binding poll. Read the comments behind the count, segment by customer value, run items through a framework like RICE, and reserve roadmap space for strategic work that users cannot vote for because they cannot yet imagine it.

### Is feature voting better than counting support requests?

Yes. Raw request counts measure how often something is mentioned, often duplicating the same need. Votes measure how many distinct people want it, consolidated into one ranked post. Voting also gives you defensible, auditable demand data that stakeholders can verify rather than scattered anecdotes.

- [How to Migrate from Productboard: A Step-by-Step Guide (2026)](https://quackback.io/blog/migrate-from-productboard): A step-by-step guide to migrating from Productboard. What to export, how to map insights and features to a board and roadmap, and how to time the switch.

Published: 2026-05-04

You have decided to leave Productboard. Maybe your maker count crept past the product team and the bill grew with it. Maybe AI credits ran out mid-month. Maybe you only ever used it to collect feedback and show a roadmap, and the strategy layer was dead weight. Whatever the reason, the migration itself should not be the hard part.

![Migrating feedback data from Productboard to a new tool](/blog/migrate-from-productboard/hero.webp)

Productboard carries more data structure than a simple voting tool. You have notes, insights, features, components, objectives, and a customer portal. That sounds like a lot to move. In practice, most of what matters to your users is the feedback and the roadmap, and both export cleanly. The strategy scaffolding mostly stays behind by choice, not by accident.

This guide walks through the full process: what Productboard lets you export, how to map its data model to a feedback board and roadmap, what to keep versus drop, how to move your Jira, Slack, and Intercom connections, and how to time the switch around your per-maker renewal.

> **To migrate from Productboard**, export your notes, features, and insights to CSV (or pull them through the REST API), then map features to feedback posts, insight counts to votes, and your release timeline to a public roadmap. Notes from Slack, Intercom, and Zendesk are not included in exports, so capture those separately. Time the cancellation 30+ days before your annual renewal to avoid an auto-renew, and recreate the customer portal as a public roadmap plus changelog. [Quackback](https://quackback.io) is open source with no per-maker pricing and imports feedback data so you keep your history.
>
> *Pricing and export details last verified May 2026. Vendors may change plans and pricing without notice. Check Productboard's pricing and support pages for the latest.*

## When it is time to leave Productboard

Switching tools has real costs: team retraining, user communication, and a brief window where your workflow is disrupted. Not every frustration justifies it. But some signals are clear.

**Your maker count keeps growing.** Productboard bills per maker at $15/maker/month annual or $19/maker/month monthly. The maker role is broadly defined: anyone who creates or edits content counts, so designers, support leads, and engineering leads tend to get pulled in over time. The bill grows with adoption, not just with your product team. Our [Productboard pricing breakdown](/blog/productboard-pricing) walks through the cost at 5, 10, 25, and 50 makers.

**You are hitting AI credit limits.** Spark includes 250 AI credits per maker per month, pooled across the workspace. Analyzing 100 insights costs a few credits; generating a full requirements document can burn 85 to 95. Teams that lean on AI for feedback analysis exhaust the pool and have to buy top-ups (50 credits for $5 monthly, or 600 credits for $60 a year).

**You only use it for feedback collection.** Productboard's value is its strategy and prioritization layer: objectives, drivers, weighted scoring, portfolio roadmaps. If you never set those up and just use notes, features, and the portal, you are paying for a product management suite to run a feedback board.

**You need self-hosting or source access.** Productboard is hosted SaaS with no self-hosting option. If your compliance framework requires data on your own infrastructure, or you want to audit and own the code, that is not on the table.

If you are still weighing the decision, our [best Productboard alternatives](/blog/best-productboard-alternatives) guide compares seven options with honest trade-offs.

## What you can export from Productboard

Productboard provides data export through CSV downloads and its public REST API. There are three practical paths.

### CSV exports

You must be a **maker or admin** to run a CSV export. Three methods exist:

- **URL-based exports** — paste a special export URL into your browser, and Productboard emails you a link to download the CSV. This is the path for bulk note and feature exports.
- **Board UI exports** — export the features and columns visible on a given board grid. Useful when you want a subset, or when you want to exclude components and subfeatures.
- **API-backed exports** — the CSV tools use Productboard's API under the hood, but require no API knowledge.

The data you can export by item type includes products, components, features, subfeatures, objectives, key results, initiatives, release groups, releases, companies, and users. You cannot export every type in a single file, so plan a few separate runs.

**Insights exports** are worth a dedicated pass. An insights CSV can include the content of the insights themselves plus the names, email addresses, and company data of the customers who submitted feedback linked to a given feature. That customer data is what lets you re-associate identities and reconstruct vote-like signal in your new tool.

### API export

For larger workspaces or full control over mapping, use the [Productboard REST API](https://developer.productboard.com/reference/introduction). The current v2 API exposes endpoints for Notes, Features, the product hierarchy (components and subfeatures), Companies & Users, Objectives, Key Results, Initiatives, and Releases.

A few constraints to plan around:

- **Rate limit:** 50 requests per second per token. Exceeding it returns `429 Too Many Requests` with a `Retry-After` header your script must respect.
- **Pagination:** list endpoints use cursor-based pagination via `pageCursor`, with a maximum page size of 100. A workspace with thousands of notes means many paginated calls — build in backoff.
- **User management:** the public API focuses on product data. Direct member-management endpoints are limited; provisioning is handled through SCIM, not the export API.

The Notes API is the one that matters most for migration. It can pull all notes, components, features, and subfeatures, which is the bulk of your portable feedback history.

### What you cannot export

Some data does not come with you:

- **Notes ingested from integrations.** The content of notes created through Slack, Intercom, and Zendesk connections is excluded from exports. If a large share of your feedback arrived through those channels, capture it separately before you cancel, or re-ingest it in your new tool.
- **Prioritization scores and driver weights.** Custom scoring, objective alignment, and driver mappings are Productboard-specific constructs. There is no equivalent field in a feedback tool, so they do not transfer.
- **Feature-forward relationship views.** Exports are notes-forward. You can get notes with their linked features, but not a clean feature-by-feature roll-up of every insight in one file.
- **Analytics and engagement metrics.** Portal traffic, contributor activity, and funnel data stay in Productboard.
- **Portal and integration configuration.** Your customer portal layout, webhook setup, and integration connections need to be recreated in the new tool.

## Mapping the Productboard data model

This is where a Productboard migration differs from a Canny or Nolt switch. Productboard has more object types, so you decide what maps to what. Here is the mapping that keeps your user-facing signal intact.

| Productboard object | Maps to | Notes |
|---|---|---|
| **Feature** | Feedback post | The core unit. Title, description, and status carry over directly. |
| **Note / insight** | Comment or linked feedback | A note is a piece of customer feedback. Attach it to the matching post, or import it as its own post. |
| **Insight count on a feature** | Vote count | The number of customers who asked for a feature is your demand signal. Reconstruct it as votes from the insights CSV. |
| **Company / user** | User record | Email is the join key. Preserve it so demand signal re-associates correctly. |
| **Release / release group** | Roadmap item | A planned release maps to a roadmap column or status. |
| **Status (Idea, Planned, In progress, Done)** | Board status | Map names to your new tool's status model. |
| **Objective / driver / score** | Drop or capture as a tag | No equivalent in a feedback tool. Most teams let these go. |

The practical insight: **features become posts, insights become the votes and comments on those posts, and releases become your roadmap.** Everything users actually see in the portal has a clean home. The strategy layer is the part you choose whether to carry, and most teams migrating away from Productboard are leaving precisely because they do not need it.

For the destination side, map features to [feedback posts](/features/feedback), insight-derived demand to [voting](/features/voting), and your release timeline to a [public roadmap](/features/roadmap). Quackback has no Productboard-specific adapter, so the practical path is its [CSV import](/features/import-export): you map your Productboard export columns to Quackback's post fields (title, content, status, tags, board, author name and email, vote count, creation date) once, and posts and votes attach to users by email on import.

## Keep versus lose: what to bring

A migration is a good moment to decide what is signal and what is clutter. Here is a clean split.

**Keep:**

- **Open and planned features** — these are your live backlog and the things users are waiting on.
- **Insight counts and the customers behind them** — months or years of accumulated demand signal. Do not throw this away.
- **User and company records** — the email addresses that let votes and notifications find the right people.
- **The release timeline** — what you have committed to and roughly when.
- **Recently shipped items** — seed your changelog with the last few releases so the new portal does not launch empty.

**Lose (or archive):**

- **Prioritization scores and driver weights** — Productboard-specific, no destination field, and you are likely leaving because you did not use them.
- **Stale features** — anything open two-plus years with a handful of insights. Archive after migration to keep the board focused.
- **Internal-only strategy notes** — objectives docs and planning artifacts belong in your wiki, not your public feedback board.
- **Duplicate or merged-source notes** — clean these up rather than carrying redundancy into the new tool.

## Migrating Jira, Slack, and Intercom

Productboard's integrations need to be recreated in your new tool. They do not transfer with the data, so list them before you start.

**Jira (and Linear).** Productboard links features to Jira issues for two-way status sync. In your new tool, reconnect the issue tracker and re-link posts to issues. [Quackback's integrations](/integrations/jira) offer two-way sync with [Jira](/integrations/jira), [Linear](/integrations/linear), [GitHub](/integrations/github), and [GitLab](/integrations/gitlab), so a post status updates when the linked issue moves and vice versa. Re-link the active backlog items; closed historical ones rarely need re-linking.

**Slack.** Productboard's Slack connection pushed notifications and pulled feedback into notes. Reconnect [Slack](/integrations/slack) in the new tool to route new feedback and status updates to your channels. Remember the caveat from the export section: feedback that arrived through Slack as notes is not in your CSV export, so if Slack was a major intake channel, plan to re-ingest or rebuild that history.

**Intercom and Zendesk.** Same story. These were intake channels feeding notes, and that note content is excluded from exports. Reconnect [Intercom](/integrations/intercom) and [Zendesk](/integrations/zendesk) so support conversations keep flowing into feedback, then accept that the historical Intercom and Zendesk notes start fresh in the new tool unless you export them from those source systems directly.

The pattern across all four: **reconnect the integration for future flow, and source any history you care about from the original system, not from the Productboard export.**

## Recreating the customer portal

Productboard's customer portal is where users submit ideas, vote, and see what is planned. To replace it, you split that single surface into two complementary ones.

**Public roadmap.** The "what is planned and in progress" half of the portal becomes a [public roadmap](/features/roadmap). Import your releases as roadmap items, set statuses, and your users get the same forward visibility they had in the portal. Voters can follow items and get notified when status changes.

**Changelog.** Productboard's release-notes capability lives inside the portal rather than as a standalone changelog feed, so the "what just shipped" story often ended up in a separate tool or got skipped. This is a chance to consolidate it. Seed a [changelog](/features/changelog) with your last few releases and announce shipped work going forward. Voters on a feature get notified automatically when it ships, which closes the loop.

**Submission widget.** The portal's submission form becomes an embeddable [feedback widget](/features/widget) you drop into your product, plus the public board itself. Replace the Productboard portal link everywhere it appears: in-app, help docs, email footers, and your website.

Splitting one portal into a roadmap plus a changelog plus a widget is not more work to run; it is the same surface area expressed in pieces you control. And the changelog is net new value Productboard did not give you.

## Timing the switch around your renewal

Productboard's per-maker plans bill on annual or multi-year terms, and the renewal mechanics matter for both cost and stress.

**Give notice 30+ days before renewal.** Annual and multi-year subscriptions require that you notify Productboard of your intent not to renew at least 30 days before the subscription ends. Miss that window and you can auto-renew into another full year. Put the date on a calendar the moment you decide to migrate, and work backward from it.

**You are paying through the term regardless.** Because you have already committed to the annual term, there is no rush to rip the tool out the day you decide to leave. Use the paid time you already own. Run the migration calmly, verify everything, and keep Productboard live in parallel until you are confident.

**Mind mid-cycle maker changes.** If you add makers mid-term you are charged a prorated amount, and removing makers does not refund the committed seats. During a migration, freeze your maker count. Do not add seats to Productboard for people who are about to move to the new tool.

**Plan the cutover before the renewal date, not on it.** Aim to have the new tool live and communicated a few weeks ahead of renewal. That gives you a buffer to catch anything that did not import correctly while you still have read access to the source data.

![Timing a Productboard migration around the annual renewal and 30-day notice window](/blog/migrate-from-productboard/renewal-timing.webp)

## Migration checklist

### Step 1: Audit your data

- **How many features and notes?** Hundreds are trivial. Thousands mean the API route with pagination and backoff.
- **Where did your feedback come from?** If much of it arrived via Slack, Intercom, or Zendesk, flag it now — that note content is excluded from exports.
- **What statuses do you use?** Map Productboard statuses to your new tool's model.
- **Which features have the most insights?** These are your highest-demand items. Verify their counts after import first.
- **What is your renewal date?** Set the 30-day notice deadline before anything else.

### Step 2: Set up the new tool

- Create boards that match your Productboard structure, or restructure if the old layout grew messy.
- Set up statuses that map to your Productboard statuses.
- Configure team members and permissions.
- Prepare your widget and public board so they are ready the moment you go live.

### Step 3: Export from Productboard

- Run the notes/features CSV export (URL-based or board UI).
- Run a separate insights export to capture customer emails, companies, and insight content.
- For large or complex workspaces, pull through the REST API and respect the 50 req/sec limit.
- Spot-check that feature counts match what you see in Productboard.

### Step 4: Import into the new tool

- **If it accepts CSV**, map your columns: feature title and description to post fields, insight customer emails to user records, status names to the new status model. [Quackback's CSV import](/features/import-export) reads a fixed set of columns and matches posts and votes to users by email, so prepare one mapped CSV and import in a single pass.
- **If it is API-only**, write a script that reads the export and creates records through the destination API.

### Step 5: Verify the import

- **Feature/post count** — does it match the export?
- **Demand signal** — pick five high-insight features and confirm the vote counts came across.
- **Users** — spot-check that customer emails and companies imported.
- **Statuses** — verify Productboard statuses mapped correctly.
- **Roadmap** — confirm releases landed in the right columns.

### Step 6: Reconnect integrations

- Reconnect [Jira](/integrations/jira) or [Linear](/integrations/linear) and re-link active backlog items.
- Reconnect [Slack](/integrations/slack) for notifications and intake.
- Reconnect [Intercom](/integrations/intercom) and [Zendesk](/integrations/zendesk) for support-driven feedback.
- Replace the Productboard portal link in-app, in docs, and on your site.

### Step 7: Communicate the switch

**For your team:** Send a short message before the switch explaining what changed, where the new tool lives, and how the workflow differs.

**For your users:** Email active feedback contributors, post a changelog entry announcing the new portal, and update every link that pointed to the old Productboard portal. Keep it simple: "We moved our feedback and roadmap to [new URL]. Your requests and history came with us. Here is where to submit new ideas."

## Timeline

A realistic timeline for a workspace with under a few thousand features and notes:

| Day | Action |
|---|---|
| **Day 1** | Audit data, set renewal-notice deadline, set up new tool, configure boards and statuses |
| **Day 2** | Export features, notes, and insights from Productboard; import into new tool; verify |
| **Day 3** | Reconnect Jira/Slack/Intercom/Zendesk, build roadmap and changelog, test end to end |
| **Day 4** | Communicate to team and users, go live |
| **Day 5-7** | Monitor, answer questions, confirm nothing was missed |

For larger workspaces or heavy integration history, add a day or two. This is not a month-long project. Most teams finish in under a week, well inside the buffer before an annual renewal.

## After the migration

**Keep Productboard active through your paid term.** You have already committed to the annual period, so use it. Keep read access until you are confident the import is complete and correct, then give your non-renewal notice 30+ days before the end date.

**Watch your feedback volume.** A temporary dip after any tool switch is normal. If it does not recover within two weeks, check that your widget works, your board is discoverable, and your communication reached active users.

**Clean up stale data.** Archive features that sat open for years with minimal demand. A migration is the right moment to focus the board on what is live.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Can you export your data from Productboard?

Yes. Makers and admins can export notes, features, components, subfeatures, insights, objectives, and users as CSV files, or pull them through the REST API. One caveat: note content ingested through Slack, Intercom, and Zendesk integrations is excluded from exports, so capture that from the source systems separately.

### Does Productboard have an API export limit?

Productboard's REST API allows 50 requests per second per token; exceeding it returns a 429 response with a Retry-After header. List endpoints use cursor-based pagination with a maximum page size of 100. For workspaces with thousands of notes, build pagination and backoff into your export script.

### Will I lose my insight counts when migrating from Productboard?

No, if you export the insights CSV. It includes the customers tied to each feature, so you can reconstruct demand signal as votes in your new tool. Email is the join key. Prioritization scores and driver weights, however, are Productboard-specific and do not transfer to a feedback tool.

### How do I time a Productboard migration around the renewal?

Productboard's annual and multi-year plans require 30+ days notice of non-renewal before the term ends. Set that deadline first, then migrate inside the paid time you already own. Go live a few weeks before renewal for a buffer to fix anything that did not import.

### What is the best tool to migrate from Productboard to?

For teams that used Productboard mainly for feedback and roadmaps, [Quackback](https://quackback.io) is the most cost-effective target: open source, no per-maker pricing, with [feedback boards](/features/feedback), [voting](/features/voting), a [public roadmap](/features/roadmap), and a built-in changelog. See the [full Quackback vs Productboard comparison](/compare/quackback-vs-productboard) and [best Productboard alternatives](/blog/best-productboard-alternatives).

- [Canny vs Featurebase: Which Feedback Tool Is Right for You?](https://quackback.io/blog/canny-vs-featurebase): A neutral comparison of Canny and Featurebase in 2026. Features, pricing, pros and cons, and when to consider an open-source alternative like Quackback.

Published: 2026-04-29

Canny and Featurebase both help you collect customer feedback, run a public roadmap, and ship a changelog. They diverge on pricing model and scope. Canny bills by tracked users and stays focused on feedback. Featurebase bills per seat and bundles a support inbox and live chat alongside the feedback toolkit.

![Canny vs Featurebase comparison with Quackback as alternative](/blog/canny-vs-featurebase/hero.webp)

> **Canny is a focused feedback tool billed by tracked users, with AI Autopilot included on every plan. Featurebase is a feedback-plus-support platform billed per seat, with its Fibi AI agent charged separately at $0.49 per resolution.** Pick Canny if you want feedback only and an engaged community in the hundreds. Pick Featurebase if you want feedback and support in one tool. If you want an open-source option, [Quackback](https://quackback.io) is free to self-host.

*Pricing last verified May 2026. Vendors may change plans without notice. Check each vendor's pricing page for the latest figures.*

If you're evaluating both tools in 2026, the right choice comes down to how you want to be billed and how wide a net you want to cast. A team that needs a clean feedback board and a public roadmap has different requirements than a team that wants feedback, a help center, and live chat under one login.

This guide breaks down what each tool does well, where each falls short, how they compare on features and pricing, and when an open-source alternative might be the better path. For a deeper look at Canny's costs, see the [Canny pricing breakdown](/blog/canny-pricing).

## Canny overview

Canny is a focused feedback management tool that has been in the market since 2017. It covers the core loop most SaaS teams need: users submit feature requests, vote on the ideas they care about, and get notified when you ship.

The product includes feedback boards, voting, a public roadmap, a changelog, and an AI feature called Autopilot that discovers feedback inside support conversations from tools like Intercom, Zendesk, Freshdesk, Gong, and Zoom. Autopilot attributes that feedback to users and creates posts on your behalf, so your team doesn't comb through tickets by hand.

### Pricing

Canny overhauled its pricing in May 2025, moving from per-admin billing to tiered pricing based on tracked users. A tracked user is anyone who has a post, vote, or comment attributed to them in your workspace.

- **Free:** $0/mo for 25 tracked users, 5 managers, Autopilot AI included
- **Core:** $19/mo (billed annually) for 100 tracked users, 5 managers, custom domains, content translations
- **Pro:** $79/mo (billed annually) for 100 tracked users, 10 managers, PM integrations (Jira, ClickUp, Linear)
- **Business:** Custom pricing for 5,000+ tracked users, SSO/SAML, CRM integrations, white-label

Costs climb as you cross tracked-user thresholds. Core runs $19/mo at 100 tracked users, then roughly $49 at 200, $125 at 500, and $249 at 1,000. Pro runs $79/mo at 100, then about $129 at 200, $279 at 500, and $529 at 1,000. Canny auto-upgrades you to the next tier if you exceed your limit, though you can set spend caps. For a full cost breakdown at different scales, see [Canny pricing in 2026](/blog/canny-pricing).

### Strengths

- **Focused product.** Canny does one thing and does it well. The interface is clean and easy to learn. Most teams are running within a day.
- **Autopilot AI on every plan.** Feedback discovery from support conversations is included even on the free tier. You don't pay extra for AI.
- **Mature integrations.** Slack, Jira, Linear, GitHub, Intercom, Zendesk, and Salesforce (Business only). The integrations are stable and well-maintained.
- **Established product.** Nine years in market and thousands of customers. The product is reliable and unlikely to disappear.

### Weaknesses

- **Tracked-user pricing climbs with engagement.** A viral feature request or a support-tool integration pushes you across thresholds quickly. You can set spend caps, but plan for cost growth tied to user activity.
- **SSO requires the Business plan.** If your organization needs SAML SSO for compliance, you need the Business plan with custom pricing.
- **No self-hosting.** Canny is hosted SaaS only. There's no way to run it on your own infrastructure or audit the source code.
- **PM integrations require Pro.** Jira, ClickUp, and Linear are locked to the Pro plan at $79/mo.

For alternatives to Canny, see [best Canny alternatives in 2026](/blog/best-canny-alternatives).

## Featurebase overview

Featurebase is a combined feedback and customer support platform that bundles feedback boards, a roadmap, and a changelog with a help center and live chat in a single tool. It targets teams that want to collect feature requests and answer support questions without running two separate products.

The feedback side covers the familiar workflow: users submit ideas, vote, and comment, while you organize requests into boards and publish a roadmap and changelog. The support side adds a shared inbox, a help center, and Fibi, an AI support agent that resolves customer questions. AI Copilot assists human agents inside conversations. This breadth is Featurebase's defining trait: it reaches beyond feedback into the support tooling that companies like Intercom occupy.

### Pricing

Featurebase uses per-seat pricing across four tiers. A seat is a team member with admin access to your workspace.

- **Free:** $0/mo for 1 seat, 1 board, 1 roadmap, unlimited posts, changelog (no AI, no custom domain)
- **Growth:** $29/seat/month (billed annually) for the Fibi AI agent, AI Copilot, custom domains, integrations, basic analytics
- **Professional:** $59/seat/month (billed annually) with 20 free Lite seats, workflows, SLAs, user segmentation, API and webhooks
- **Enterprise:** $99/seat/month (billed annually) with 50 free Lite seats, multi-brand workspace, custom admin roles, and SSO login

The Fibi AI support agent is billed separately at **$0.49 per resolution** on every paid plan, on top of your seat cost. AI features are not available on the free plan. SSO login is gated to the Enterprise tier. For the feedback-only use case, the free plan covers a single board and roadmap, but you stay on a featurebase.app subdomain until you upgrade.

### Strengths

- **Feedback plus support in one tool.** A shared inbox, a help center, and live chat live alongside your feedback boards. One login, one vendor.
- **Genuinely useful free plan.** Unlimited posts, one board, one roadmap, and a changelog at no cost. Good enough for an early-stage product collecting its first feedback.
- **Outcome-based AI pricing.** Fibi charges $0.49 per resolution rather than a flat AI subscription, so you pay for results when the agent actually resolves a ticket.
- **Lite seats on higher tiers.** Professional and Enterprise include 20 and 50 free Lite seats, which helps when many teammates only need read or light access.

### Weaknesses

- **Per-seat costs add up.** Every admin needs a paid seat. A five-person team on Growth pays $145/mo (annual), and Professional doubles the per-seat rate.
- **AI billed on top of seats.** Fibi's $0.49 per resolution is separate from your seat cost. High support volume means the AI line item grows independently of headcount.
- **SSO requires Enterprise.** SAML SSO sits on the most expensive tier at $99/seat/month.
- **No self-hosting.** Featurebase is hosted SaaS only. No on-premises deployment and no source code to audit.
- **Broader than some teams need.** If you only want a feedback board and roadmap, the support inbox and live chat add surface area you won't use.

For a head-to-head, see [Quackback vs Featurebase](/compare/quackback-vs-featurebase).

## Feature comparison

Here's how Canny, Featurebase, and Quackback compare across the features that matter for feedback management.

| Feature | Canny | Featurebase | Quackback |
|---|---|---|---|
| **Feedback boards** | Yes | Yes | Yes |
| **Voting** | Yes | Yes | Yes |
| **Public roadmap** | Yes | Yes | Yes |
| **Changelog** | Yes | Yes | Yes |
| **Support inbox / live chat** | No | Yes | No (feedback inbox only) |
| **AI features** | Autopilot (all plans) | Fibi ($0.49/resolution) | Included |
| **MCP server** | No | No | Yes |
| **Integrations** | PM integrations on Pro ($79/mo) | Full suite on Growth+ | 20+ included |
| **API** | REST API | REST API (Professional+) | REST API |
| **SSO** | Business plan (custom pricing) | Enterprise ($99/seat/mo) | Free self-hosted · Enterprise on Cloud |
| **Self-hosting** | No | No | Yes (Docker) |
| **Open source** | No | No | Yes (AGPL-3.0) |
| **Starting price** | Free (25 tracked users) | Free (1 seat) | Free self-hosted / $29/mo Cloud |
| **Pricing model** | Tiered by tracked users | Per seat | Workspace (Cloud) or free self-hosted |
| **Duplicate detection** | Autopilot dedup | Basic | AI-powered |

The three tools cover overlapping ground with different boundaries. Canny stays tight on feedback. Featurebase reaches into support. Both gate features (SSO, full AI, PM integrations) behind higher tiers, which is standard for SaaS. Quackback includes all features on every self-hosted installation but requires you to manage your own infrastructure.

## Pricing comparison

What each tool costs depends on your team size and how many users interact with your feedback system. Canny scales with tracked users. Featurebase scales with admin seats. Here's a side-by-side estimate at different scales.

### Small team (3 admins, 500 feedback users)

| | Canny | Featurebase | Quackback |
|---|---|---|---|
| **Plan needed** | Pro (for PM integrations) | Growth | Self-host or Cloud Pro |
| **Monthly cost** | ~$279/mo (Pro at 500 tracked users) | $87/mo (3 seats x $29 annual) | Self-host ~$10 · Cloud $29/mo Pro (5 seats) |
| **Annual cost** | ~$3,348 | $1,044 | Self-host ~$120 · Cloud $348 |
| **AI cost** | Included on all plans | Fibi billed at $0.49/resolution | Self-host: your LLM bill. Cloud: included Quinn usage, then $10 top-up packs. |

### Mid-size team (8 admins, 2,000 feedback users)

| | Canny | Featurebase | Quackback |
|---|---|---|---|
| **Plan needed** | Pro or Business | Professional | Self-host or Cloud Business |
| **Monthly cost** | $529+/mo (Pro at 1,000+ tracked users) | $472/mo (8 seats x $59 annual) | Self-host ~$20 · Cloud $59/mo Business (20 seats) |
| **Annual cost** | $6,348+ | $5,664 | Self-host ~$240 · Cloud $708 |
| **AI cost** | Included | Fibi billed at $0.49/resolution | Self-host: your LLM bill. Cloud: included Quinn usage, then $10 top-up packs. |
| **SSO** | Business plan (custom pricing) | Enterprise only ($99/seat/mo) | Free self-hosted · Enterprise on Cloud |

### Larger team (20 admins, 10,000+ feedback users)

| | Canny | Featurebase | Quackback |
|---|---|---|---|
| **Plan needed** | Business | Enterprise | Self-host or Cloud Enterprise |
| **Monthly cost** | Contact sales (5,000+ tracked users) | $1,980/mo (20 seats x $99 annual) | Self-host infra · Cloud $99/mo Enterprise |
| **Annual cost** | Likely $15,000–30,000+ | $23,760+ | Self-host infra · Cloud $1,188 |

Each pricing model scales on a different axis. Canny's tiered tracked-user pricing means costs increase as engagement grows, regardless of team size. Featurebase's per-seat billing means costs grow with the number of admins, plus a separate $0.49-per-resolution charge for Fibi AI. Quackback Cloud is a flat workspace price from $29/mo billed annually (Free plan, 1 seat), with portal users free. Self-host is $0 software plus infrastructure and your own LLM usage. The right model depends on which dimension you expect to grow fastest.

## When to choose Canny

Canny is the right fit when your primary goal is focused feedback management and you don't want a support inbox bundled in.

**Choose Canny if:**

- You want a dedicated feedback tool. Boards, voting, roadmap, and changelog, without a help center or live chat layered on top. Your team learns it quickly and users find it intuitive.
- Your engaged feedback community is in the hundreds. Tracked-user pricing stays reasonable when your active voters number in the low hundreds. A smaller, engaged base gets good value from Core or Pro.
- You rely on support-conversation mining. Canny's Autopilot pulls insights out of Intercom, Zendesk, and Freshdesk conversations and is included on every plan, including free.
- You want a mature, established product. Canny has been in market since 2017. The integrations are well-tested and the company isn't going anywhere.

Where Canny struggles: large feedback communities (tracked-user costs become unpredictable), teams that need SSO without Business-tier custom pricing, and organizations that want to own their data or self-host.

## When to choose Featurebase

Featurebase is the right fit for teams that want to handle feedback and customer support in one place rather than buying two separate tools.

**Choose Featurebase if:**

- You want feedback and support together. A shared inbox, help center, live chat, and an AI support agent sit alongside your feedback boards. One vendor handles both jobs.
- You're starting out and want a real free plan. The free tier gives you a board, a roadmap, a changelog, and unlimited posts at no cost, which is enough to validate the workflow before you pay.
- You prefer outcome-based AI billing. Fibi charges $0.49 per resolution rather than a flat AI fee, so the AI cost tracks the value it delivers.
- Your admin count is small and stable. Per-seat pricing rewards lean teams. A two or three person team on Growth keeps the bill modest.

Where Featurebase struggles: teams with many admins (per-seat costs climb fast), organizations that need SSO without the Enterprise tier, teams that only want feedback and don't need the support side, and anyone who wants to self-host.

## Consider Quackback if...

Neither Canny nor Featurebase is the only path. If the trade-offs of both tools don't sit well with you, [Quackback](https://quackback.io) takes a fundamentally different approach.

**You want to avoid vendor lock-in.** Quackback is open source under AGPL-3.0. The code is available, auditable, and forkable. You're not dependent on a vendor's pricing decisions, feature roadmap, or continued existence. If Quackback the company disappeared tomorrow, the software keeps running on your server.

**You want everything on one installation.** No feature gates based on plan tiers. One installation gives you [feedback boards](/features/feedback), [voting](/features/voting), a public [roadmap](/features/roadmap), a [changelog](/features/changelog), 25 integrations, [SSO/OIDC](/features/sso), custom branding, and [REST API](/features/api) access.

**You want AI built in.** Quackback includes duplicate detection, merge suggestions, theme summaries, and feedback ingestion from Slack and email on every self-hosted installation. There is no $0.49-per-resolution charge like Featurebase's Fibi. Quackback Cloud includes Quinn on paid plans, with $10 top-up packs if you need more. No tier-dependent Autopilot access like Canny.

**You want an MCP server.** Quackback's [MCP server](/features/mcp) implements the Model Context Protocol, the standard supported by Claude, Cursor, and Windsurf. Connect an AI agent and it gets full access to your feedback data: search posts, triage requests, write responses, create changelog entries, and merge duplicates. Neither Canny nor Featurebase offers this.

**You want to self-host.** Deploy with Docker or on Railway. Your data lives in your PostgreSQL database on your infrastructure. Full control over backups, access, and compliance. This matters for teams with data residency requirements or organizations that can't send customer feedback to a third-party SaaS platform.

**The trade-off:** you manage your own infrastructure instead of paying a SaaS vendor. For teams with DevOps capacity, a $10–20/mo VPS runs the full platform. For teams that want managed hosting, [Quackback Cloud](/pricing) is live.

For detailed head-to-head comparisons, see [Quackback vs Canny](/compare/quackback-vs-canny) and [Quackback vs Featurebase](/compare/quackback-vs-featurebase). For a broader look at the landscape, see [best Canny alternatives in 2026](/blog/best-canny-alternatives).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Is Canny or Featurebase cheaper?

It depends on your shape. Canny bills by tracked users, so an engaged community in the thousands gets expensive fast. Featurebase bills per seat, so a small team with many feedback users stays cheaper, but per-seat costs climb with admins plus a separate $0.49-per-resolution AI fee.

### Does Featurebase include customer support tools?

Yes. Featurebase bundles a shared support inbox, a help center, live chat, and the Fibi AI agent alongside its feedback boards, roadmap, and changelog. Canny stays focused on feedback only. Choose Featurebase for feedback and support in one tool; choose Canny if you only need feedback.

### Do Canny or Featurebase offer self-hosting?

No. Both are hosted SaaS products with no self-hosting option. Your feedback data lives on their infrastructure, and you're subject to their pricing changes over time. If self-hosting, data ownership, or open-source licensing matters, [Quackback](/compare/quackback-vs-canny) is the primary alternative. It's open source (AGPL-3.0) and deploys with Docker.

### How does AI pricing differ between Canny and Featurebase?

Canny includes Autopilot AI on every plan, including the free tier, at no extra cost. Featurebase charges its Fibi agent separately at $0.49 per resolution on top of your seat cost, and AI is unavailable on its free plan. Self-hosted Quackback includes AI and you pay only your own LLM usage. Quackback Cloud includes Quinn on paid plans, with $10 top-up packs if you need more.

### Which feedback tool has a better free plan?

Both offer one. Canny's free tier allows 25 tracked users, 5 managers, and Autopilot AI. Featurebase's free tier allows 1 seat, 1 board, 1 roadmap, unlimited posts, and a changelog, but no AI. For a free option, [Quackback](https://quackback.io) is open source and self-hosted.

- [How to Prioritize Feature Requests: A Practical Framework (2026)](https://quackback.io/blog/how-to-prioritize-feature-requests): Learn how to prioritize feature requests with a repeatable framework: gather signal, score with RICE or MoSCoW, weight by customer value, and build a roadmap.

Published: 2026-04-25

Every product team has more feature requests than it can build. The hard part is not collecting them. The hard part is deciding which ones matter, in what order, and being able to explain why. Most teams default to whoever argues loudest or whichever request arrived most recently. There is a better way.

![Feature requests funneled into a ranked, ordered list using votes, value, and effort signals](/blog/how-to-prioritize-feature-requests/hero.webp)

This guide walks through a complete, repeatable process: how to gather the right signal, why raw vote counts mislead, how to apply scoring frameworks like RICE and MoSCoW, how to weight requests by customer value and revenue, and how to turn a ranked list into an actual roadmap.

> Prioritizing feature requests well means scoring each request on a consistent set of inputs — demand, customer value, effort, and strategy fit — rather than reacting to raw volume or the loudest complaints. Gather signal from votes and comments, weight it by revenue and segment, score with a framework like RICE or MoSCoW, plot value against effort, then sequence the survivors into a roadmap.

## Why raw vote counts mislead

Vote counts are the most visible signal on any feedback board, which is exactly why they are dangerous to use alone. A high vote count tells you a request is popular. It does not tell you whether the people voting matter to your business, whether the request aligns with where the product is going, or whether building it would move a metric you care about.

Three failure modes show up repeatedly:

**The loud minority.** Twenty engaged users who check your board weekly can out-vote a silent majority who never visit it. The request with the most votes is often the one your most online users want, not the one your most valuable customers need.

**Survivorship bias.** Only users who are still around vote. The customers who churned because a critical capability was missing never registered an opinion. Their absence skews the board toward incremental polish for existing users and away from the gaps that cost you new revenue.

**Equal weighting.** A free-tier hobbyist and an enterprise account on a six-figure contract each cast one vote. If those votes count the same, your prioritization optimizes for headcount, not value.

Vote counts are a useful starting input. They are a terrible final answer. The rest of this guide is about turning that raw signal into a defensible ranking.

## Gather the right signal

Before you score anything, collect the inputs that actually predict good prioritization decisions. Four signals do most of the work.

**Demand.** How many people want this, and how often are they asking? Vote counts on your [feedback board](/features/feedback) are the headline number, but request frequency over time matters as much. A feature that gains ten new votes every week for six months has sustained demand. A feature that spiked to 100 votes once and went quiet may be less urgent than the raw total suggests.

**Customer value.** Who is asking? A request from fifty enterprise accounts on annual contracts can outweigh three hundred requests from free-tier users, depending on your business model. Tie requests to revenue, plan tier, and account health wherever you can.

**Effort.** What will it cost to build, in total — design, engineering, QA, documentation, and launch — not just backend code. Get this estimate from the people who will do the work, not from the person excited to ship it.

**Strategy fit.** Does this support where the product is going? A request with five hundred votes that pulls against your current direction should score lower than its popularity implies. A request that advances your roadmap goals can earn priority even with modest demand.

The qualitative layer matters too. Vote counts tell you how many. User comments tell you why. "I have to export to a spreadsheet and reformat it manually every week" is a different level of value than "it would be nice if the colors matched our brand." Read the comments before you score.

## Apply a scoring framework

Once you have signal, a framework turns it into a comparable ranking. No single framework is correct for every situation — they answer different questions. Here is when to reach for each.

### RICE: score the full backlog

The [RICE framework](/blog/rice-framework-explained) was developed by Intercom's product team. It scores each request on four factors and produces a single number you sort by:

**RICE Score = (Reach × Impact × Confidence) ÷ Effort**

Reach is how many users a request affects in a given period. Impact is how much it moves the needle for each one, on a coarse scale. Confidence discounts the score when you are guessing rather than working from data. Effort is total person-months. RICE shines when you need a defensible numeric ranking across a large, mixed backlog and you have enough data to estimate the inputs. The [RICE scoring calculator](/tools/rice-scoring-calculator) runs the math for you during planning. For the full method, scales, and a worked example, see the [complete RICE guide](/blog/rice-framework-explained).

### MoSCoW: scope a release

[MoSCoW prioritization](/blog/moscow-prioritization) sorts requests into four buckets: Must have, Should have, Could have, and Won't have. It was created by Dai Clegg at Oracle in 1994 and later formalized in the DSDM agile framework. MoSCoW is a scoping tool, not a ranking tool. It answers "what goes into this release?" rather than "in what order do we build it?" Its most valuable category is the one teams skip: an explicit Won't-have list prevents scope creep and sets expectations with stakeholders. Use MoSCoW to agree on scope, then use RICE to sequence within it.

### Kano: understand how requests affect satisfaction

The [Kano model](/blog/kano-model) classifies features by how they affect customer satisfaction: basic expectations whose absence causes dissatisfaction, performance features where more is better, and delighters that produce outsized satisfaction when present but cause none when absent. Kano answers "what do customers actually value?" and is best used during discovery. A request can have hundreds of votes and still be a basic expectation customers will not thank you for — or a low-vote delighter worth building for differentiation. Feed Kano classifications into your RICE Impact scores.

The frameworks are complementary. A common sequence: use Kano during discovery to understand what matters, MoSCoW to scope a release with stakeholders, and RICE to sequence the build order within it.

## The value vs effort matrix

![Value versus effort matrix with Quick Wins, Major Projects, Fill-Ins, and Avoid quadrants](/blog/how-to-prioritize-feature-requests/value-effort-matrix.webp)

When you need a fast visual triage rather than a precise score, plot each request on a value vs effort matrix. Rate every request high or low on value and on effort, then place it in one of four quadrants:

- **Quick Wins** (high value, low effort): build these first. The return is highest here.
- **Major Projects** (high value, high effort): worth doing, but they need scoping and sequencing. Don't let them crowd out Quick Wins.
- **Fill-Ins** (low value, low effort): do these if you have spare capacity.
- **Avoid** (low value, high effort): say no, explicitly. Putting a request in the Avoid quadrant is more useful than leaving it ambiguous in the backlog.

The matrix surfaces trade-offs that are easy to miss when you evaluate requests one at a time. A request that seems essential in isolation often looks like poor value next to three alternatives that deliver comparable benefit for a fraction of the effort. When too many requests cluster in the same quadrant, the 2x2 has run out of resolution — that is your signal to move to weighted scoring or RICE. The [prioritization matrix template](/blog/prioritization-matrix-template) covers both the 2x2 and the weighted version in detail.

## Weight by customer value and revenue

This is the step that separates prioritization that grows the business from prioritization that merely keeps the loudest users busy. Two requests with identical vote counts can have wildly different value depending on who is behind the votes.

Three adjustments matter most:

**Revenue and plan tier.** Attach a dollar figure to each request wherever you can. If a request is blocking renewal for two accounts worth $80,000 a year combined, that belongs in your value estimate even if only two people voted. Conversely, a request with three hundred free-tier votes and no path to revenue should be weighted down, not up.

**Segment and strategic fit.** A startup chasing acquisition might weight requests from prospects and trial users heavily. A product optimizing retention weights existing-customer requests. The right weighting reflects what your team is trying to accomplish this quarter, not a universal formula.

**Account health.** A request from a healthy, expanding account is different from the same request attached to an account that is one frustration away from churning. Competitive necessity is a special case here: some requests don't create value, they prevent the loss of it. If a competitor ships something your customers expect you to match, the cost of inaction is churn, not missed growth.

The hard part has never been the math — it is getting reliable, revenue-aware inputs. This is where most spreadsheets break down. A vote count in a spreadsheet does not know which votes came from a $50,000 account. Connecting demand signal to customer value is the difference between a prioritized list and a prioritized list that compounds.

### How Quackback surfaces true demand

This is the gap [Quackback](/features/voting) is built to close. Three capabilities work together to surface real demand instead of the loudest demand.

**Vote-on-behalf.** When a customer mentions a request on a sales call, in a support ticket, or over email, your team logs a vote on their behalf and attaches the account. The silent majority — the customers who would never visit a public board — finally show up in the data. That directly counters the loud-minority and survivorship problems above.

**Value-weighting.** Because votes carry account context, you can weight demand by revenue and plan tier rather than treating every vote as equal. A request backed by three enterprise accounts and a request backed by thirty free users no longer look identical in your prioritization.

**AI theme summaries.** Quackback's AI groups related requests, detects duplicates, and summarizes the themes running through hundreds of comments, so a request fragmented across twelve differently-worded posts shows its true combined weight. AI is built in — duplicate detection, theme summaries, and ingestion from Slack and email.

The result: the requests that rise to the top reflect weighted, deduplicated demand from your whole customer base, not the subset that happens to be loud.

## Turn a prioritized list into a roadmap

A ranked list is not a roadmap. The final step is converting your scored, weighted requests into a sequence your team and your customers can act on.

**Group by theme, not just score.** Several individual requests often point at the same underlying need. Build the theme, not each request in isolation. AI theme summaries make these clusters obvious.

**Sequence for dependencies.** Scoring frameworks rank requests independently and ignore dependencies. If a high-scoring request depends on lower-scoring foundational work, the foundational work moves up regardless of its raw score. Resolve this when you build the [roadmap](/features/roadmap), not during scoring.

**Commit to horizons, not dates.** Group work into Now, Next, and Later rather than promising specific dates you will miss. This keeps the roadmap honest as priorities shift.

**Close the loop.** When you ship a prioritized request, tell the people who asked for it. Linking requests to roadmap items and changelog entries turns prioritization into a visible feedback loop — customers see their input lead to shipped work, which drives more and better signal next cycle.

A public [roadmap](/features/roadmap) backed by weighted demand data also reduces a category of work that quietly drains product teams: answering "are you ever going to build X?" The answer is on the board, with its status, for everyone to see.

---
> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)
---

## Frequently asked questions

### How do you prioritize feature requests with limited data?

Start with the strongest signal you have. Without vote data, use support ticket frequency and sales-call mentions as a demand proxy, and log votes on behalf of customers as they surface. Score with a value vs effort matrix first — it tolerates rough estimates better than RICE.

### Should the most-voted feature always be built first?

No. Vote counts measure popularity, not value. The most-voted request often reflects your most online users rather than your most valuable customers, and ignores churned users who never voted. Weight votes by revenue, plan tier, and strategy fit before deciding build order.

### What is the best framework for prioritizing feature requests?

There is no single best framework. Use [RICE](/blog/rice-framework-explained) for a defensible numeric ranking across a large backlog, [MoSCoW](/blog/moscow-prioritization) to scope a specific release with stakeholders, and the [Kano model](/blog/kano-model) during discovery to understand how requests affect satisfaction. Most teams combine them.

### How do you say no to a feature request?

Make the decision explicit and explain the trade-off. An explicit "won't have this release" bucket, as in MoSCoW, communicates the decision clearly. Tell the requester what you prioritized instead and why. A documented "no" on a public [roadmap](/features/roadmap) is better than silence, which reads as a maybe.

### How often should you re-prioritize feature requests?

Re-prioritize at the start of each planning cycle, typically quarterly. Between cycles, revisit individual requests when significant new signal arrives — a spike in votes, a major account tying a renewal to a request, or a strategic shift in what counts as high value. Avoid re-scoring everything weekly.

- [How to Migrate from UserVoice: Export, Import, and Cut Your Bill](https://quackback.io/blog/migrate-from-uservoice): A practical guide to migrating from UserVoice. What you can export, how to map ideas and supporters, how to preserve SSO, and how to time your contract.

Published: 2026-04-20

You have decided to leave UserVoice. Maybe the $16,000 annual minimum no longer matches what you use. Maybe you need a public roadmap and changelog UserVoice does not offer. Maybe you want to stop renewing a contract you negotiate through sales every year. Whatever the reason, the migration itself should not be the hard part.

![Migrating ideas and supporters from UserVoice](/blog/migrate-from-uservoice/hero.webp)

> Migrating from UserVoice means exporting your ideas and supporters to CSV, mapping them to a feedback board, and rebuilding the pieces UserVoice handles outside the export, like SSO and a public roadmap. The data move takes a few hours. The bigger lever is timing the switch against your annual contract so you do not pay for an empty seat.

The data itself is simple. Your core records are ideas, supporters (votes), comments, statuses, and the users behind them. UserVoice exports most of this to CSV or xlsx. The work that takes planning is everything around the export: preserving supporter identity, reconnecting SSO, communicating the move, and timing it against your auto-renewal so you are not double-paying.

This guide walks through the full process, with the contract timing that matters most for an enterprise tool like UserVoice.

## When it is time to leave UserVoice

Not every frustration justifies a migration. Switching tools has real costs — team retraining, user communication, and a brief period where your feedback workflow is disrupted. But some signals are clear.

**The price no longer matches the use.** UserVoice starts at $16,000 per year (~$1,333/mo) on an annual contract, with pricing scaled to your monthly feedback volume and integrations. There is no monthly option and no self-serve signup. If your team mainly uses voting boards and status updates, you are paying enterprise rates for features you never touch. Our [UserVoice pricing breakdown](/blog/uservoice-pricing) walks through what each commitment level costs.

*Pricing last verified May 2026. Vendors may change plans without notice.*

**You need a public roadmap and changelog.** UserVoice does not let you publish your roadmap on your UserVoice site, and it has no native changelog. Idea statuses are visible to supporters, but roadmap statuses are not public. If you want a single place where users see what is planned and what shipped, you will end up bolting on a second tool.

**You want predictable, self-serve pricing.** Every UserVoice renewal goes through a "Talk to an Expert" conversation. Teams that want to add a board, change plans, or cancel without a sales cycle find the model heavy for what they need.

**You want source code access or self-hosting.** UserVoice is a closed-source hosted SaaS with no on-premises deployment. If your security team requires data to stay on your infrastructure, UserVoice is not an option regardless of features.

If you are still evaluating where to go, our [UserVoice alternatives comparison](/blog/best-uservoice-alternatives) covers seven options with honest pros and cons.

## What you can export from UserVoice

UserVoice provides data export through the admin dashboard. Most of what you need comes out as a structured file.

### Idea export

From the Ideas & Activity area, the **Export Activity** option produces a CSV or xlsx file. You choose between two types:

- **Regular export (Ideas only)** — idea ID, title, body, status, supporter count, comment count, and related fields
- **Analysis export (Ideas & Voters)** — ideas plus the supporters attached to each one, which is what you need to preserve vote-to-user relationships

You can filter by date range: the last 30, 60, 90, or 365 days, or a custom window. For a full migration, export everything rather than a recent slice.

### User export

A separate **Users** export lists your users along with the total number of suggestions and requests each one submitted. Combined with the analysis export, this gives you the email addresses you need to re-associate supporter identity in your new tool.

### What the import format tells you

UserVoice's own import format is a useful map of which fields it stores, because you can export the same shape. Voter and feedback imports key on `user.email_address` (required), `suggestion.title` or `suggestion.id`, `link_suggestion_user.is_subscribed`, and `request.body`. Optional fields include `user.name` and `link_suggestion_user.created_timestamp` in ISO 8601 UTC (`2016-01-01T00:00:00Z`). Email is the join key for supporter identity. Imports cap at 10,000 rows per file, so large accounts come across in batches.

### What you cannot export cleanly

Some data does not travel as one neat file:

- **Users tied to all of their ideas, votes, and comments in a single export** — UserVoice does not offer one combined export, so you reassemble this from the analysis export and the users export
- **Internal notes and admin-only fields** may not appear in standard exports
- **NLP analysis, themes, and engagement metrics** — the derived analytics stay in UserVoice
- **CRM-linked revenue data** — account ARR pulled from Salesforce or HubSpot lives in the integration, not the export
- **SSO and integration configuration** — these are recreated, not exported

## Migration checklist

### Step 1: Audit your current data

Before exporting anything, understand what you have.

- **How many ideas?** Hundreds are trivial. Tens of thousands cross the 10,000-row import cap and need batching.
- **How many supporters?** These are the people you need to communicate with.
- **What statuses do you use?** Map UserVoice idea statuses to your new tool's status model (typically Open, Under Review, Planned, In Progress, Complete, Closed).
- **What categories and forums exist?** Document them. You will recreate or map them.
- **Who authenticates via SSO?** Note your identity provider so you can reconnect it.

### Step 2: Set up your new tool

Create your account and configure the basics before importing data:

- Create boards that match your UserVoice forum structure, or restructure intentionally
- Set up statuses that map to your UserVoice statuses
- Create categories and tags
- Configure team members and permissions
- Set up your widget or portal so it is ready for users after the switch

### Step 3: Export from UserVoice

Run the analysis export (Ideas & Voters) and the users export from the admin dashboard. Verify the data before proceeding:

- Spot-check that idea counts match what you see in UserVoice
- Confirm supporters are attached to the correct ideas
- Check that user email addresses are present, since email is how supporter identity re-associates
- Note the date format so timestamps map correctly

### Step 4: Import into your new tool

How this works depends on your destination tool.

**If your new tool has a UserVoice importer or import guide:** Use it. A purpose-built path handles field mapping, status translation, and user matching for you.

[Quackback's import and export tooling](/features/import-export) maps UserVoice fields directly — ideas become posts, supporters become votes keyed on email, and statuses translate to your board's status model. There is a [step-by-step migration guide](/docs) for the field mapping.

**If your new tool accepts CSV imports:** Map your UserVoice columns to the tool's expected format. Pay attention to:

- Date formats (UserVoice uses ISO 8601 UTC)
- Status mapping (names differ between tools)
- User matching (email is the join key)
- Row limits (split files larger than 10,000 rows)

**If your new tool only has an API:** Write a migration script that reads your UserVoice export and creates records through the destination API. This is more work but gives you full control over how data maps.

### Step 5: Verify the import

After importing, check:

- **Idea count** — does it match your UserVoice export?
- **Vote counts** — pick five popular ideas and verify supporter totals
- **Supporter identity** — spot-check that users matched on email rather than creating duplicates
- **Statuses** — verify UserVoice statuses mapped to the correct new statuses
- **Comments** — check that authors and timestamps came through

### Step 6: Preserve SSO and supporter identity

This is where UserVoice migrations differ from a simple board switch.

UserVoice supports SAML SSO with providers like Okta, Microsoft Entra ID, OneLogin, and ADFS, plus OIDC and token-based JWT sign-in, on plans that include the feature. The attributes it passes are an email (required) and an optional display name and GUID.

Because supporter records key on email, the identity you re-associate in your new tool should use the **same email** your SSO provider asserts. Configure SSO in the new tool against the same identity provider, mapping the email claim consistently. Do this before you invite users back, so a returning supporter signs in and lands on their existing posts and votes rather than a fresh account.

[Quackback supports team SSO via OIDC](/features/sso) with providers like Okta, Microsoft Entra ID, Google Workspace, OneLogin, and Auth0. If your UserVoice SSO ran on one of those, point Quackback at the same OIDC provider and map the email claim consistently so sign-in stays unchanged. UserVoice's SAML-only setups need an OIDC connection at the same identity provider instead.

### Step 7: Reconnect integrations

If you had UserVoice connected to other tools, recreate those connections:

- **Issue trackers** — re-link [Jira](/integrations/jira), [Linear](/integrations/linear), or [GitHub](/integrations/github) so feedback flows to engineering. A tool with two-way sync keeps statuses aligned automatically.
- **Support tools** — reconnect [Intercom](/integrations/intercom) or [Zendesk](/integrations/zendesk)
- **CRM** — if you relied on Salesforce or HubSpot for revenue context, decide whether you still need it; most teams find they do not
- **Slack** — reconnect your [Slack](/integrations/slack) feedback channels
- **Widget embed** — replace the UserVoice widget script in your product with your new tool's widget

### Step 8: Communicate the switch

This is the step most teams skip, and it causes the most friction.

**For your team:** Send a brief message explaining what changed, where to find the new feedback tool, and how the workflow differs. Do this before the switch, not after.

**For your users:** If you have a public-facing portal, your supporters need to know where to go. Options:

- Email active supporters (anyone who posted, voted, or commented in the last 90 days)
- Post a changelog entry announcing the new feedback portal
- Update links in your product, help docs, and website
- Add a notice on your old UserVoice subdomain if you can still edit it

Keep the message simple: "We moved our feedback portal to [new URL]. Your existing ideas and votes have been migrated. Here is where to submit new feedback."

## Timing the switch against your contract

UserVoice is an annual contract, so timing matters more here than with a month-to-month tool.

**Know your renewal date.** Early cancellation is generally not available unless it was negotiated into your agreement. In practice, you wait until the renewal date and give notice. Find that date and the notice period in your contract before you plan anything.

**Give notice early.** Auto-renewal terms vary by contract. Send your non-renewal notice in writing well ahead of the deadline so a renewal does not lock you into another year.

**Run the migration before renewal, not after.** The cleanest plan is to export, import, and verify in the new tool while UserVoice is still live, then switch users over and let the UserVoice contract lapse at renewal. You keep a working fallback during the move and avoid paying for two tools longer than a short overlap.

**Do not delete anything until the term ends.** Keep UserVoice accessible through the end of your paid term. You may need to reference historical data or re-export something that did not map cleanly the first time.

## URL redirects

If your portal lived at `yourcompany.uservoice.com` or a custom domain, plan your links:

- Update all internal links in your product, docs, and website
- If you used a custom domain with a CNAME to UserVoice, repoint that DNS record to your new tool once you are live
- Add a notice or redirect page at the old address if you control it

## Rebuilding the roadmap and changelog

UserVoice does not publish a roadmap on your site and has no native changelog, so this is often an upgrade rather than a like-for-like rebuild.

- **Public roadmap** — group your imported ideas into planned, in progress, and shipped columns. A [public roadmap](/features/roadmap) gives supporters a live view of what you are working on, which UserVoice could not show natively.
- **Changelog** — when you ship something, post it and notify the people who voted. A [changelog with voter notifications](/features/changelog) closes the loop automatically, replacing the manual status updates you sent in UserVoice.

This is the part where most teams find the move was worth it beyond cost: the loop from request to roadmap to shipped announcement becomes one connected flow.

## Timeline

A realistic timeline for a team with under 10,000 ideas:

| Day | Action |
|---|---|
| **Day 1** | Audit data, set up new tool, configure boards and statuses |
| **Day 2** | Export from UserVoice, import into new tool, verify data |
| **Day 3** | Configure SSO against the same identity provider, reconnect integrations, replace widget |
| **Day 4** | Communicate to team and users, go live |
| **Day 5-7** | Monitor for issues, answer questions, verify nothing was missed |

![UserVoice migration timeline from Day 1 through Day 7](/blog/migrate-from-uservoice/migration-timeline.webp)

Larger accounts that cross the 10,000-row import cap add a day or two for batching, and SSO setup can add time if your identity provider needs a security review. But this is not a month-long project. The data move is the fast part. Contract timing is what stretches the calendar, not the migration itself.

## After the migration

**Keep UserVoice live through your contract term.** Do not let access lapse before you have verified everything imported correctly and your users have moved over.

**Monitor your new feedback volume.** A temporary dip in submissions is normal after any tool switch. If volume does not recover within two weeks, check that your widget works, your portal is discoverable, and your communication reached active supporters.

**Clean up stale data.** A migration is a good time to close ideas that are no longer relevant. If a request has sat for two years with three supporters, archive it to keep the board focused.

For the full side-by-side on what changes, see the [Quackback vs UserVoice comparison](/compare/quackback-vs-uservoice).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Can I export my data from UserVoice?

Yes. UserVoice exports ideas and supporters to CSV or xlsx from the admin dashboard. The analysis export includes ideas with their voters, and a separate users export lists users with their submission counts. Derived analytics, NLP themes, and CRM revenue data do not export.

### Will I lose votes when I migrate from UserVoice?

No, if supporters are matched on email. UserVoice keys supporter records to `user.email_address`, so as long as you preserve emails in the import and use the same email in your new tool's SSO, votes re-associate with the correct users instead of creating duplicates.

### How do I keep SSO working after migrating from UserVoice?

Configure SSO in your new tool against the same identity provider UserVoice used. UserVoice supports SAML with Okta, Entra ID, OneLogin, and ADFS, plus OIDC. [Quackback supports team SSO via OIDC](/features/sso), so connecting the same provider over OIDC and mapping the email claim keeps sign-in unchanged for returning supporters.

### When should I cancel my UserVoice contract?

Run the full migration before your renewal date, then let the annual contract lapse. Early cancellation is generally unavailable unless negotiated, so send your non-renewal notice in writing ahead of the deadline and keep UserVoice live through the paid term as a fallback.

### Does UserVoice have a changelog I can migrate?

No. UserVoice has no native changelog and does not publish your roadmap on its site. You rebuild both in your new tool. A [changelog with voter notifications](/features/changelog) and a [public roadmap](/features/roadmap) replace the manual status updates UserVoice relied on, usually as an upgrade.

- [Feedback Boards: What They Are and How to Run One Users Actually Use](https://quackback.io/blog/feedback-boards): A feedback board collects, ranks, and tracks user ideas in one visible space. Learn public vs private boards, structure, moderation, and how to keep one alive.

Published: 2026-04-15

Most product teams already collect feedback. It arrives in support tickets, Slack threads, sales calls, and email. The problem is not collection. The problem is that the feedback never lands anywhere users can see it, vote on it, or watch it move. A feedback board fixes that by giving every idea one home that both your users and your team look at.

This guide covers what a feedback board is, how public and private boards differ, how to structure one, how to handle moderation and duplicates, and how to drive submissions so the board fills itself. It also covers the failure mode every team worries about: the board that turns into a graveyard.

![A feedback board collecting submissions from a widget, email, and chat into one ranked list](/blog/feedback-boards/hero.webp)

> A feedback board is a dedicated space where users submit ideas, vote on each other's requests, and follow their status over time. It replaces scattered tickets and threads with one ranked, visible list of what people want. The board surface itself is simple. What makes it work is keeping submissions flowing in and statuses flowing back out.

## What is a feedback board

A feedback board is an online space where users submit product ideas, feature requests, and bug reports, vote on existing submissions, and track each one through a visible status. Each post shows its title, description, vote count, comments, and current state. Posts are grouped by board or category so the list stays legible as it grows.

The board does three things a form or an inbox cannot. It lets users **see** what others have already asked for, so they vote instead of duplicating. It quantifies demand through **votes**, so the most-wanted ideas rise to the top on their own. And it shows **status**, so a submitter knows whether their idea is under review, planned, or shipped without asking anyone.

That combination is what separates a board from the tools it replaces. A spreadsheet collects. A support inbox routes. A board collects, ranks, and communicates back. For the broader shift away from one-directional collection, see our guide to the [digital suggestion box](/blog/digital-suggestion-box).

## Public vs private boards

The first decision when setting up a board is who can see it. Both models are valid, and many teams run both.

**Public boards** are visible to anyone, logged in or not. They are the default for customer-facing products. A public board does double duty: it collects feedback, and it signals to prospects that you listen. When a potential customer searches for a feature and finds it already requested and marked "planned," that transparency can close the sale. Public boards also reduce support volume, because users discover that an issue is already reported and tracked before they open a ticket.

**Private boards** restrict access to authenticated users or specific segments. They suit internal teams, beta programs, and enterprise products where feedback may reference unreleased plans or sensitive accounts. A private board keeps roadmap discussion out of competitors' view while still giving the right people a place to submit and vote.

You do not have to choose one. A common setup is a public board for general feature requests and a private board for enterprise customers or your internal team. Quackback supports multiple [feedback boards](/features/feedback) per project, each public or private, so you can segment by audience without running separate tools.

| | Public board | Private board |
|---|---|---|
| Who can view | Anyone | Authenticated users or segments |
| Best for | Customer feature requests, prospects | Internal teams, beta, enterprise |
| Doubles as | Trust and sales signal | Controlled feedback channel |
| Reduces support load | Yes | Partially |
| Risk | Competitors see your plans | Lower reach, fewer submissions |

## How to structure a feedback board

A board with no structure becomes as hard to read as the spreadsheet it replaced. Three primitives keep it legible: statuses, categories, and tags.

**Statuses** show where each idea sits in your process. A simple, honest set works best: open, under review, planned, in progress, shipped, and declined. Statuses are the single most important element of a board, because they are what users check. A board where everything sits at "open" forever tells users their input goes nowhere. Statuses are also where the board connects to your [public roadmap](/features/roadmap), the workflow layer downstream of the board surface.

**Categories** (or separate boards) split feedback by product area or audience. Keep the list short. Five to eight categories is usually enough. Too many and users cannot decide where to post, so they post wrong or not at all. Common splits are by feature area (Dashboard, API, Integrations) or by type (Feature requests, Bugs).

**Tags** add a second, flexible dimension on top of categories. A post lives in one category but can carry several tags: "mobile," "enterprise," "quick win." Tags let your team filter the board down to exactly the slice they care about during triage without forcing users to think about them at submission time. In Quackback, tags are colored and support bulk management so the board stays readable past a few hundred posts.

The goal of all three is the same: a stranger should be able to scan the board and understand what people want and what you are doing about it in under a minute.

## Moderation, duplicates, and merging

Every active board accumulates noise. The same request appears under three titles. Spam slips in on public boards. Off-topic posts wander in. Left alone, the noise buries the signal, and your vote counts stop meaning anything.

**Duplicates are the main threat.** When "add dark mode," "dark theme please," and "night mode for the dashboard" exist as three separate posts, your most-wanted feature looks like three middling ones. The fix is merging: combine the posts into one and roll their votes together so the count reflects real demand. Doing this by hand works at low volume and collapses at high volume, because someone has to notice the duplicates first.

This is where AI earns its place on the board. Quackback runs **automatic duplicate detection** at submission time and surfaces merge suggestions with reasoning your team can accept or dismiss in one click. It also generates **theme summaries** that pull recurring requests across many posts into a single readable picture, so a product manager can process a hundred submissions without reading every one. The board stays clean without a person babysitting it.

**Moderation** covers the rest: removing spam, hiding off-topic posts, and setting whether new submissions appear immediately or after review. Public boards usually need light moderation. Private boards rarely need any. Whichever you choose, the rule is to keep it fast. A submission that sits in a moderation queue for a week teaches users not to bother.

It is worth noting that not every tool handles this. Fider, the other AGPL-3.0 open-source board, has no built-in duplicate detection, so similar posts fragment and you merge by hand. Several hosted tools gate merging behind higher paid tiers. If you expect volume, deduplication is the capability to check for first. *Fider feature details last verified May 2026. Vendors may change plans without notice.*

## Driving submissions so the board fills itself

A board only works if feedback reaches it. The most common reason boards die is not that users have nothing to say. It is that asking them to leave your product, find the board, and create an account is too much friction for an idea they had in passing. Remove the friction by bringing the board to where users already are.

**An embeddable widget** is the highest-leverage channel. A [feedback widget](/features/widget) lets users submit an idea or vote without leaving your app. They click a button, type a sentence, and they are done. Quackback's widget posts straight to the right board, supports anonymous or identified submissions, and ships with iOS and Android SDKs. In-app capture consistently produces more feedback than any standalone portal, because it meets users in the moment they have the thought.

**Slack and email ingestion** capture feedback that never starts as a board post. A customer mentions a missing feature in Slack, or someone replies to a product email with a request. Normally that signal evaporates. Quackback ingests from Slack and email and turns those messages into board posts automatically, so the board fills from channels your users already use without anyone copy-pasting.

**Integrations** route feedback from your support and issue tools. Connect [Intercom](/integrations/intercom) or [Zendesk](/integrations/zendesk) so support conversations become board posts, and [Linear](/integrations/linear) or [Jira](/integrations/jira) so accepted ideas become tickets with two-way status sync. The fewer manual steps between a user's words and a tracked post, the more feedback you capture.

Combine these and the board stops being a destination users have to visit. It becomes the place every channel drains into. For customer-facing teams, our [feature requests use case](/use-cases/feature-requests) walks through the full setup.

## Feedback board vs suggestion box vs forum

These three get conflated, but they behave differently, and choosing the wrong one shapes the feedback you get.

A **suggestion box** is one-directional. Users drop ideas in; only the receiving team sees them. There is no voting, no visible status, and no way for a submitter to know what happened. It collects, and that is all. The classic suggestion box reliably goes quiet because users learn their input disappears.

A **forum** is many-directional and open-ended. Users post threads, reply to each other, and discuss freely. Forums are good for community and support, but they do not rank or resolve. A popular thread is not a prioritized request, and a forum has no concept of status, so nothing closes. Threads sprawl and the same topic recurs endlessly.

A **feedback board** sits in between by design. It is structured like a suggestion box (submit an idea) but two-directional like a forum (vote, comment) with one addition neither has: status. Every post moves through a visible lifecycle and the people who submitted or voted get notified when it does. That single addition is what closes the loop.

| | Suggestion box | Forum | Feedback board |
|---|---|---|---|
| Users submit ideas | Yes | Yes | Yes |
| Users see others' ideas | No | Yes | Yes |
| Voting / ranking | No | No | Yes |
| Visible status | No | No | Yes |
| Closes the loop | No | No | Yes |
| Best for | Anonymous intake | Community discussion | Prioritized product feedback |

If you want the prioritized, closeable signal a product team can act on, the board is the right surface.

## Keeping the board from becoming a graveyard

The fear is real and the failure is predictable. A team launches a board with enthusiasm, submissions flow for a month, then statuses stop updating, replies stop coming, and within a quarter the board is a dead page nobody visits. The board did not fail because the format is wrong. It failed because nobody owned it. Four habits keep a board alive.

**Give it an owner.** One person is responsible for triage, not for building everything users ask for, but for making sure every new submission gets acknowledged and routed. A board with no owner becomes a board with no maintenance.

**Set a triage cadence.** Review new posts on a fixed rhythm, weekly or biweekly. Merge duplicates, update statuses, and reply to questions in the same session. Consistency matters more than frequency. Users learn that the board moves.

**Update statuses visibly, including the no.** When you decline a request, change its status and post a one-line reason. "We considered this and decided not to pursue it because X" is more respectful than silence, and it teaches users that the board is honest.

**Close the loop automatically.** When a post moves to planned or shipped, everyone who submitted or voted on it should be notified without you doing it by hand. This converts a board from a collection point into a relationship. A user who requested a feature and gets told it shipped feels heard, and heard users keep coming back. For the full mechanics, see our [customer feedback loop guide](/blog/customer-feedback-loop).

The board's structure does the prioritizing for free once submissions and statuses keep moving. Your job is to keep both in motion.

## Choosing a tool for your board

Most boards rest on one of three foundations. General-purpose forms collect but cannot vote, rank, or show status, so they reproduce the suggestion box problem. Hosted feedback tools like Canny solve the board mechanics well but price on tracked users, so your bill grows as more users submit, and none offer self-hosting. *Canny uses tracked-user pricing with a free plan capped at 25 tracked users; pricing last verified May 2026. Vendors may change plans without notice.* Purpose-built boards designed for the submit-vote-status workflow fit most teams.

Quackback is the open-source option in that group. It is licensed under AGPL-3.0, free to self-host, and offers a managed cloud version. The board ships with voting, threaded comments, custom statuses, categories, and colored tags. AI duplicate detection, theme summaries, and Slack and email ingestion keep the board clean and fill it without manual upkeep. An MCP server lets AI agents search, triage, and merge posts, and integrations with two-way issue-tracker sync route feedback into your development workflow. Because it is open source, your feedback data stays in your own database. For a side-by-side look at the alternatives, see our roundup of the [best feature request tools](/blog/best-feature-request-tools).

---
> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)
---

## Frequently asked questions

### What is a feedback board?

A feedback board is a dedicated space where users submit ideas, vote on each other's requests, and track each one through a visible status. It replaces scattered tickets and threads with one ranked list, so the most-wanted ideas surface on their own and submitters can see what happened to theirs.

### Should a feedback board be public or private?

Use a public board for customer feature requests; it collects feedback and signals to prospects that you listen. Use a private board for internal teams, beta programs, or enterprise feedback that references sensitive plans. Many teams run both. Quackback supports multiple public or private boards per project.

### How do I stop my feedback board from becoming a graveyard?

Give it one owner, set a weekly or biweekly triage cadence, update statuses visibly (including declines), and notify submitters automatically when posts ship. Boards die from neglect, not format. Keeping submissions and status updates in motion is what keeps users contributing.

### What is the difference between a feedback board and a forum?

A forum supports open discussion but cannot rank ideas or track status, so threads sprawl and nothing closes. A feedback board adds voting to surface demand and statuses to show progress, with notifications that close the loop. Use a forum for community, a board for prioritized product feedback.

### How do I get more submissions on my feedback board?

Bring the board to users instead of asking them to find it. An in-app [feedback widget](/features/widget) captures ideas without leaving your product, and Slack and email ingestion turn messages into board posts automatically. Removing friction at the moment of the idea drives far more submissions than a standalone portal.

- [Customer Engagement Tools for Product Teams (Not Marketing)](https://quackback.io/blog/customer-engagement-tools): Most customer engagement tool lists target marketers. Here is the stack product teams actually need — widgets, feedback, changelogs, onboarding, and voting.

Published: 2026-04-14

Search "customer engagement tools" and you will land on lists of CRMs, contact centers, and marketing automation suites. HubSpot. Zendesk. Insider. Zoho. Those tools solve a real problem, but it is not the problem a product team has. They push messages out to segments. You need something that pulls signals in from users and closes the loop on what ships next.

This post is the other list. It covers the product-led engagement stack — the tools marketing teams do not buy for you, because they do not know you need them.

![Four jobs of product-led engagement: capture feedback, show roadmap, onboard users, let users vote](/blog/customer-engagement-tools/hero.webp)

> Customer engagement tools for product teams cover four jobs: capture feedback in-context, show users what is coming, onboard them to new capabilities, and let them influence priorities. That is a different stack from the CRMs, live chat, and marketing automation that dominate most "engagement tool" lists. This guide maps each category, names the products, and shows how to assemble a stack without buying an all-in-one.
>
> *Pricing last verified April 2026.*

## Why product teams need their own engagement stack (not marketing's)

Marketing engagement and product engagement sound like the same thing. They are not. A marketing team engages customers to move them through a funnel — awareness, consideration, purchase, retention. The tools for that job are optimized for sending outbound messages to lists. Email campaigns. Push notifications. SMS. Retargeting. The measurement loop is open rate, click rate, attribution.

A product team has a different job. You are not trying to move users through a funnel. You are trying to figure out what to build, ship it, and make sure users notice. The work flows the other direction. Users tell you what is broken. You tell them what is coming. They decide whether the new feature is worth learning. You learn whether it solved the problem you thought it did.

Those two loops use different tools. A CRM does not capture in-context feedback. A marketing automation platform does not run a public roadmap. Live chat is not a changelog. When someone hands a product team a "customer engagement platform" built for marketers, the team ends up using ten percent of it and paying for the rest.

The product-led engagement stack is smaller, cheaper, and closer to the code. It lives in the app. It connects to your issue tracker. It does four specific jobs.

## The four jobs of product-led engagement

Every category in this post maps to one of four jobs. If a tool does not do one of these jobs well, it is not a product engagement tool. It is something else.

1. **Capture feedback in-context.** Users have opinions while they are using the product, not three days later when a survey arrives. The job is to catch the thought when it is top of mind and tie it to the screen the user was on.
2. **Show users what is coming.** A changelog and a roadmap answer two different questions. What just shipped. What is next. Both are public commitments that give users a reason to keep paying attention.
3. **Onboard users to new capabilities.** A user who cannot find the feature you shipped might as well be using last month's product. Tours, tooltips, and empty states bridge the gap between shipping and adoption.
4. **Let users influence priorities.** Voting and public roadmaps turn passive users into co-designers. The feedback loop is the thing that makes users feel heard — not the individual ticket response, but seeing their idea move from "submitted" to "in progress" to "shipped."

Those four jobs map to four categories of tools. The sections below cover each one, with specific products you can actually pick. Quackback appears in three of the sections as one option among several. This is a category piece, not a pitch.

## In-app feedback and widgets

Of the four jobs, in-context feedback is the one marketing tools miss hardest. A CRM asks you to build a form, put it on a marketing page, and email users a link. By the time a user clicks, the thought is gone. You get back "the thing is slow sometimes" instead of "the export on the invoices page timed out with a 504 at 14:02."

The fix is a widget that lives inside your product. A floating button, a shortcut, or a context-menu item that opens a capture form on the current screen. The form collects what the user wrote plus what the tool can see — URL, browser, session, screen size, maybe a screenshot. It routes that ticket to a place where the product team will actually read it.

The category has four notable entries:

| **Tool** | **What it is best at** | **Pricing shape** |
| --- | --- | --- |
| Quackback | Open source widget with feedback, voting, changelog, roadmap in one stack | Self-hosted free, AGPL-3.0 |
| Canny | Polished voting widget, strong roadmap UI | Per-seat, tiered |
| Usersnap | Visual bug reports with screenshots and annotations | Per-seat, tiered |
| Marker.io | Bug capture wired into Jira and Linear | Per-seat, tiered |

[Quackback's widget](/features/widget) is the one I build, so treat the mention as disclosed. It is AGPL-3.0, embeds in one script tag, and pipes into a full [feedback inbox](/features/feedback). It is one option among several. The other three are mature commercial products. If you want a visual-first experience where the user draws on the screen, Usersnap and Marker are stronger. If you want voting and changelog in the same tool, Canny and Quackback cover that.

The deeper question is not which widget to pick. It is whether you have a widget at all. Most teams do not. They rely on support tickets from a help desk that lives outside the app, and the product signal arrives laundered through a support agent two days later. You can read more on the widget category in [feedback widget tools](/blog/feedback-widget-tools), and the broader comparison in [the best customer feedback tools](/blog/best-customer-feedback-tools-2026). For teams evaluating Canny specifically, [best Canny alternatives](/blog/best-canny-alternatives) and [Quackback vs Canny](/compare/quackback-vs-canny) are the two posts worth reading.

If you want the case for why in-context feedback beats email surveys in almost every scenario, [in-app feedback](/use-cases/in-app-feedback) makes that argument in more detail.

## Onboarding and product tours

Onboarding sits adjacent to engagement. It earns a section because product teams often conflate the two — a tour platform gets bought and assumed to cover "engagement," and then nobody captures a single piece of feedback for eighteen months. Tours are a real job, but they are not the whole job.

The category leaders:

| **Tool** | **What it is best at** | **Pricing shape** |
| --- | --- | --- |
| Appcues | Mature tours, surveys, launchers; no-code | Per-MAU, enterprise-priced |
| Userpilot | Flows, experiments, product analytics overlap | Per-MAU, mid-market |
| Chameleon | Polished UI, strong targeting rules | Per-MAU, premium |
| Userflow | Simple checklist-first onboarding | Per-MAU, mid-market |

The job these tools do is narrow and clear. A user lands on a new feature. They need to reach value before they give up. A tour points at the right button, a tooltip explains the second one, a checklist gives them a sense of progress. When the first session ends successfully, the user comes back.

Two rules of thumb for when a tour helps and when it hurts. Use a tour when the value is locked behind a multi-step flow that is not obvious from the UI — inviting teammates, connecting a data source, running the first report. Do not use a tour when a good empty state, a sample dataset, or a one-line tooltip would do the job without hijacking the screen. Tours interrupt. Every interruption is a tax on the user's attention. Spend the tax on moments that matter.

The failure mode I see most often is teams that bolt a tour onto every new feature because the platform makes it easy. Users learn to dismiss tours without reading them. The tour becomes furniture. If you are going to run onboarding flows, audit them once a quarter and delete half.

Onboarding tools are also where "engagement platform" marketing gets slipperiest. Appcues and Userpilot both pitch themselves as engagement tools, and they both have some in-app messaging features. But they do not replace a feedback widget, a changelog, or a voting system. They do one job well. Treat them that way.

## Announcements and changelogs

A release nobody knows about did not really ship. This is the job of the changelog and the in-app announcement — to turn every release into a reason for users to come back and look.

The distinction matters. A **changelog** is a persistent, public record of what changed, searchable and linkable. An **announcement** is a one-time prompt that surfaces a specific change to a specific user at a specific moment. A good stack does both. The changelog lives at a stable URL. The announcement fires inside the app the next time the user logs in, links to the changelog entry, and disappears once they acknowledge it.

The category:

| **Tool** | **What it is best at** | **Pricing shape** |
| --- | --- | --- |
| Beamer | In-app announcement widget with NPS bolt-on | Per-MAU, mid-market |
| LaunchNotes | Public pages for roadmap and changelog | Per-seat, mid-market |
| Headway | Simple changelog widget with RSS | Per-project, cheap |
| Quackback | [Changelog](/features/changelog) plus roadmap, feedback, voting in one | Self-hosted free |

Beamer is the category default for in-app announcements — if you want a red dot in the corner that opens a slide-out with your last five updates, it is the obvious pick. There is a fuller treatment in [best Beamer alternatives](/blog/best-beamer-alternatives) if you are trying to leave or avoid it. Headway is the simplest option, almost a drop-in widget. LaunchNotes is the polished public-page choice. Quackback folds the changelog into the same stack as the feedback and voting, so the same users who vote on an idea see the entry when it ships.

The principles behind a good changelog do not change with the tool. Write in the user's voice. Lead with the outcome, not the implementation. Ship on a cadence that trains readers to come back. [How to keep a changelog](/blog/keep-a-changelog) covers the writing mechanics, and [product update announcements](/blog/product-update-announcement) covers the launch-day side of the job. Treat those as the reading assignment. The tool is the easy part.

## Feature voting and public roadmaps

The last job is the one that turns engagement into loyalty. Users who see their own ideas move from "submitted" to "planned" to "shipped" stop acting like customers and start acting like collaborators. They defend you in community channels. They bring you better bug reports. They refer new users.

You get there with two tools that usually live in the same product — a **voting board** where users submit and upvote ideas, and a **public roadmap** that shows what you have committed to next.

| **Tool** | **What it is best at** | **Pricing shape** |
| --- | --- | --- |
| Canny | Polished voting UI, roadmap view, integrations | Per-seat, tiered |
| Frill | Clean voting board, simple roadmap, widget | Per-workspace, cheaper |
| Productboard | Voting plus heavy prioritization tooling | Per-seat, enterprise-priced |
| Quackback | [Voting](/features/voting) and [public roadmap](/features/roadmap), open source | Self-hosted free |

The category has more entries than I listed. If you want the full map, [best feature voting tools](/blog/best-feature-voting-tools) and [best public roadmap tools](/blog/best-public-roadmap-tools) cover it in more detail, along with [feature request tracking](/blog/feature-request-tracking) for the workflow inside your team.

The pick comes down to two questions. First, do you want a polished commercial tool with a support team behind it, or an open-source stack you can host and modify? Canny and Productboard are the commercial picks. Quackback and Frill sit on the lighter-weight side. Second, how much prioritization logic do you want the tool to run for you? Productboard goes deepest — scoring models, impact metrics, goal alignment. Quackback and Frill keep it simple and assume your prioritization lives in a meeting or a spreadsheet.

The thing all four tools share is the public feedback loop. When a user submits an idea, sees other users vote, watches it appear on the roadmap, and finally gets an email that it shipped, the loop is closed. That loop is the engagement. [Customer feedback loop](/blog/customer-feedback-loop) argues this in more detail.

One more note on voting boards. They are not a substitute for talking to customers. They surface the ideas of the loudest ten percent of users and miss the silent eighty percent. Use them as one signal alongside interviews, support tickets, and usage data. [Feedback management](/use-cases/feedback-management) covers how to weigh those inputs.

## How to assemble a stack without buying an all-in-one

Most "customer engagement platforms" that pitch an all-in-one are CRMs in disguise. They started life sending marketing email and grew a set of in-app features to compete. The in-app features are rarely as good as a focused tool, but the price is always bigger. Small teams do better with two or three focused tools that integrate than one bloated platform.

Here are three starter stacks, sized to team maturity. Pick the closest one and bend it to your needs.

**Solo product team or early stage**

- One feedback tool that covers widget, inbox, changelog, and voting in a single product. Quackback is the open-source option. Canny is the commercial option.
- That is the whole stack. Do not add onboarding yet. Do not add analytics yet. You will know when you need them, and you will know which job they are doing.

**Growing team with product-market fit**

- Feedback + voting + changelog (one tool, as above)
- Onboarding and tours (Appcues, Userpilot, or Userflow)
- A product analytics tool you already have (PostHog, Mixpanel, Amplitude)

The second tool earns its seat because new features are shipping faster than users are discovering them. The analytics tool is probably already in the stack and I am not counting it as new spend.

**Scaling team with multiple products or regions**

- Feedback stack (as above, possibly with Productboard if prioritization needs heavy tooling)
- Onboarding (Appcues or Chameleon for deeper targeting)
- A public roadmap at a dedicated URL, not just inside the voting tool
- Integrations into Linear, Jira, Slack, and whatever CRM marketing uses so the feedback is visible to the rest of the company

At this size you are not optimizing for cost. You are optimizing for making sure the feedback signal does not get stuck in one team. The value of the stack is the integrations between the pieces. Pick tools that talk to each other.

A note on integrations. Quackback ships [25 integrations](/integrations/slack) covering Linear, Jira, GitHub, Slack, Notion, and the usual suspects. It also ships an [MCP server](/features/mcp) so you can query and triage feedback straight from an AI coding agent — ask Claude or Cursor what users are asking for without leaving the editor. That is the part most category leaders do not have, and if your workflow lives in an AI-assisted editor it matters more than it sounds. Quackback runs self-hosted for free or as a managed [Quackback Cloud](/pricing) if you do not want to run the server. The AI features are built in. Most category leaders cover the same integration set on per-seat plans. Check the specific ones you care about before you commit.

The anti-pattern to avoid is buying an all-in-one platform that does all four jobs at a seven. Four sevens is worse than three nines. Pick the jobs you need now, buy the best tool for each, and add the next one when a specific pain forces the decision.

## Common pitfalls

Five concrete failure modes I have watched teams step into. Each one is avoidable if you know to look for it.

**Over-messaging.** A team ships five features, bolts an announcement tour to each one, sets the changelog to auto-pop on every login, and wonders why engagement drops. Users learn to dismiss interruptions without reading them. Every prompt is a tax on attention. Budget it. If a tour, a tooltip, and a changelog entry all fire on the same session, something has to give.

**Fragmented data.** A feedback widget that does not connect to the voting board. A voting board that does not connect to the changelog. A changelog that does not connect to the issue tracker. When the pieces do not talk, users report the same idea three times in three places, and the team cannot see the pattern. The value of the stack is the links between the pieces, not the pieces themselves.

**Buying an all-in-one that owns none of the jobs well.** The platform pitch is seductive. One contract, one vendor, one UI. The reality is that the feedback features are a bolt-on, the changelog is a bolt-on, and the roadmap is a bolt-on, and none of them match what a focused tool does. You end up paying enterprise prices for mid-tier features in every category.

**Treating engagement as a marketing problem.** This is the framing this whole post rejects. If the only people thinking about customer engagement at your company are in marketing, the product-side jobs will not get done. Users will get more emails and fewer product updates. Ownership of the four jobs has to sit inside the product team, even when the tools overlap with marketing's budget.

**Conflating engagement with retention.** These are related but not the same. Retention is a lagging metric — did users come back. Engagement is a set of behaviors — did they give feedback, read the changelog, vote on the roadmap, open the new feature. Engagement is upstream of retention. If you measure only retention you will not know what to fix when it drops. Measure the engagement signals separately so you can see the problem before it becomes a churn chart.

One last thought. The point of a product-led engagement stack is not to maximize screen time or prompt count. It is to make the feedback loop short enough that users feel heard. Short loops keep users. Long loops do not. Every tool in this post earns its seat by shortening one part of that loop.

Build the stack that does the four jobs. Skip the ones that do not. When a tool pitches you something that does not map to one of the four jobs, ask what problem it is actually solving — and whether that problem belongs to your product team or somebody else's.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is a customer engagement tool for product teams?

A customer engagement tool for product teams is software that does one of four jobs — capture in-context feedback, show users what is coming, onboard them to new capabilities, or let them influence priorities. That is different from a marketing engagement tool, which is usually a CRM or automation platform focused on sending outbound messages.

### Do product teams need a separate customer engagement tool from marketing?

Yes, because the jobs are different. Marketing engagement pushes messages out to segments. Product engagement pulls signals in from users and closes the loop on what ships. A CRM does not capture in-context feedback, and a feedback widget does not run drip campaigns. Trying to force one tool to do both usually means both jobs are done badly.

### What is the difference between customer engagement and customer success tools?

Customer engagement tools help you capture feedback, announce changes, and give users a voice. Customer success tools track account health, usage trends, and churn risk, usually for a CSM team working a list of accounts. There is overlap in usage data, but the workflows and owners are different. A product team wants engagement. A CS team wants success.

### Can one tool handle feedback, changelog, and roadmap?

Yes, and for most small teams that is the right call. Tools like Quackback, Canny, and Frill cover all three jobs in one product, so users submit feedback, vote, and see it ship without switching vendors. Onboarding is the fourth job these tools skip — add a tour tool later.

### What is the cheapest way to build a product-led engagement stack?

The cheapest path is an open-source tool that bundles feedback, voting, changelog, and roadmap in one self-hosted product. Quackback is free under AGPL-3.0 and runs on a small server. Pair it with a free Notion or GitHub onboarding page and you cover three of the four jobs for hosting cost.

### Do I need a customer engagement tool if I have a CRM?

Usually yes. A CRM tracks contacts, deals, and outbound communication. It does not capture in-context product feedback, run a public roadmap, or show users a changelog the next time they log in. Those are different jobs with different interfaces. The CRM and the product engagement stack should share data through integrations, not try to replace each other.

- [Customer Feedback Analysis: 5 Methods That Go Beyond Spreadsheets](https://quackback.io/blog/customer-feedback-analysis): Five customer feedback analysis methods ranked by effort vs insight. From spreadsheets to manual tagging, clustering, AI triage, and MCP agents.

Published: 2026-04-13

Most articles about **customer feedback analysis** start with a definition and end with a screenshot of a $50,000 platform. You are left with a vocabulary lesson and a sales pitch, and no honest answer to the only question that matters: what is the minimum-effort method that will help you decide what to build next?

> **Customer feedback analysis** is the process of sorting raw feedback into categories, themes, and decisions so you can choose what to build next. The five methods, ranked by effort versus insight, are: **spreadsheet and pivot tables**, **manual tagging with a fixed taxonomy**, **thematic clustering**, **AI-assisted analysis**, and **integrated platforms with MCP agents**. Pick the lowest-effort method that answers your actual question, and graduate only when that method breaks.

![Five customer feedback analysis methods ranked from spreadsheet to MCP agents](/blog/customer-feedback-analysis/hero.webp)

## Why most feedback analysis advice is useless

Search "customer feedback analysis" and you find a pattern. Post one defines the term. Post two lists five benefits. Post three pastes a nine-step framework that ends with "and then use our platform to do it for you." None tell you where to start if you have 30 feedback items and one afternoon to figure out what is going on.

Analysis is a function of volume. At 30 items a week, you do not need a platform. You need a sorting shelf. At 3,000 items a week, a sorting shelf will bury you. The right method depends on how much feedback you have, how much time you can spend reading it, and what decision the output needs to support.

This post walks up the ladder. Five methods, ordered by effort. Each one is honest about where it works and where it breaks. You pick the lowest rung that answers your question, and you only graduate when you have to. For the wider discipline, see the [user feedback guide](/blog/user-feedback-guide). For the qualitative-versus-quantitative split, see [qualitative vs quantitative feedback](/blog/qualitative-vs-quantitative-feedback). If you are still sourcing the raw input, start with [collect customer feedback](/blog/collect-customer-feedback).

## Method 1: Spreadsheet and pivot tables (honest baseline)

A spreadsheet is not a joke. It is the method every team uses at the start, and most teams never admit it in public.

Export your raw feedback to CSV — survey responses, support tickets, sales call notes, or replies to a product update. Paste it into one tab. Add three columns: **category**, **severity**, and **decision**. Category is a short taxonomy you decide up front — six to eight labels, no more. Severity is high, medium, or low. Decision is one of: build, watch, decline.

Read each row. Fill in the three columns. This takes about ten seconds per item once you have your categories. Then build a pivot table: rows are category, columns are decision, values are count. You now have a two-dimensional map of what is coming in and what you intend to do with it.

That map is enough to answer questions like "which category dominates this week" and "are we declining more than we build." It is not enough to surface duplicates, track trends over months, or detect themes you did not anticipate. It is also brittle: once you pass roughly 200 items, the sheet becomes a chore to maintain and people start tagging less carefully to save time.

A clean spreadsheet beats a messy platform. For a concrete template, see [feature request tracking spreadsheet](/blog/feature-request-tracking-spreadsheet). For the upgrade path, see [feature request tracking](/blog/feature-request-tracking).

**When spreadsheets work:** under 200 items a month, one person doing the analysis, a small number of recurring categories.

**When they break:** more than one person tagging, tag drift, volume above 200 items a month, or a need to track the same theme across weeks.

## Method 2: Manual tagging with a fixed taxonomy

Manual tagging is the grown-up cousin of the spreadsheet method. The difference is not the tool. It is the discipline. Everyone tags with the same vocabulary, and the vocabulary does not change without review.

The key move is the **fixed taxonomy**. Decide your tags once. Write them down with one-sentence definitions. Do not let people invent new tags in the moment. If a piece of feedback does not fit, flag it for a weekly review where you decide whether to add a tag or widen an existing one.

The rule that will save you the most pain: **no taxonomy should exceed ten top-level tags.** If you have twenty, nobody can remember them, and tagging becomes a guessing game. Ten is the upper bound where a tagger can hold the full list in their head. Subdivide with sub-tags if you need more granularity, but the top level stays small.

Avoid freeform tagging. A freeform field produces "bug", "Bug", "bugs", "defect", "broken", and "crash" as six different categories. That is noise masquerading as data. If your tool supports a fixed dropdown, use it. Quackback's [feedback management](/features/feedback) supports exactly this: fixed categories, structured status, and a consistent tag vocabulary across the inbox.

Manual tagging scales to around 500 items a month per tagger. Above that, the tagger cuts corners and quality degrades silently. For the broader operational picture, see [feedback management](/blog/feedback-management).

**When manual tagging works:** a PM or support lead with up to a few hundred items a month, a stable product area, a taxonomy that does not need to evolve weekly.

**When it breaks:** multiple taggers without weekly calibration, fast-moving product areas, or volume above 500 items a month.

## Method 3: Thematic clustering (when volume breaks tagging)

Thematic clustering is what you do when you have too much feedback to pre-classify but still need to find the patterns. Instead of deciding categories in advance and forcing every item into one, you read a sample, extract the themes that emerge, and then tag the rest against those themes.

The practical workflow. Take a random sample of fifty items. Read them slowly. Note any phrase or topic that repeats. By the end, you will have eight to fifteen candidate themes. Some will be obvious. Some will surprise you. The surprises are the point. Group those themes into a shorter working list of six to ten clusters, and tag the remaining items against that list. This is different from Method 2 because the taxonomy came from the data, not from your assumptions.

The word you will hear for the automated version is **embedding**. An embedding is a compact numerical summary of a piece of text, arranged so that similar texts end up close to each other. Clustering software uses those summaries to group items automatically. You do not need to understand the math. You do need to know that any machine clustering should be reviewed by a human before it drives a decision — machines happily group things that share vocabulary without sharing meaning.

Thematic clustering is the minimum viable method above roughly 500 items a month. Below that, a fixed taxonomy is faster. Above it, you cannot keep a taxonomy stable enough to be useful. For a deeper take on the qualitative technique, see [voice of customer](/blog/voice-of-customer).

**When clustering works:** volume between 500 and 2,000 items a month, a product area that is still evolving, a team willing to review the cluster labels before acting on them.

**When it breaks:** if you let the clusters run without human review. Unsupervised clustering will confidently group "bug in the billing page" with "I would like to be billed annually" because both mention billing. You still need a human to keep the grouping honest.

## Method 4: AI-assisted analysis (sentiment and topic)

This is where automation starts doing real work. An AI-assisted workflow can do four things well: **deduplicate** similar submissions, **score sentiment**, **suggest tags** from your existing taxonomy, and **summarise** long-form responses. These are first-pass operations. They do not replace your judgment. They make your judgment cheaper to apply.

Duplicate detection is the highest-leverage AI task for most teams. If a feature request has been submitted seventeen times in slightly different words, a human skimming the inbox will see five or six and call it a trend. A language model can match all seventeen and give you a real count. That changes priorities.

Sentiment scoring is more mixed. On clearly-worded feedback, it is accurate enough to filter. On sarcasm, mixed intent ("love the new feature, but it crashes"), and deadpan complaints, sentiment gets fooled. Treat it as a hint, not a verdict. Topic assignment sits in the middle: useful as a first pass, unreliable on edge cases.

AI is one method on the ladder, not the whole ladder. It shines at volume and struggles with nuance. For a deeper walkthrough of exactly what AI can and cannot do, including prompt patterns and failure modes, read [ai customer feedback analysis](/blog/ai-customer-feedback-analysis). That post is the AI deep-dive. This section places AI at its correct rung. For the adjacent case of survey-specific analysis, see [ai survey analysis](/blog/ai-survey-analysis).

Quackback runs AI as an optional layer over structured data. The [inbox](/features/inbox) stores clean rows with fixed fields. AI triages, groups, and summarises on top of that. For how this compares to other tools, see [best customer feedback tools 2026](/blog/best-customer-feedback-tools-2026).

**When AI-assisted analysis works:** volume above 1,000 items a month, a clear taxonomy it can suggest against, and humans still reviewing the output before decisions get made.

**When it breaks:** treating the output as authoritative, running it on ambiguous or sarcastic text without review, or using it to replace the step where a human actually reads the top themes.

## Method 5: Integrated feedback platform with MCP and AI agents

The top of the ladder is not just "AI analysis inside your feedback tool." It is the point where analysis stops being a periodic activity and becomes a continuous background process. The mechanism is a standard called **MCP** — the Model Context Protocol — which lets an AI agent connect to a feedback system and act on it through a defined set of tools.

The difference in practice. With Method 4, you run an analysis. A report comes out. You read it. You make decisions. A week later you run it again. With Method 5, an agent watches the inbox, matches new items against existing threads, merges duplicates, flags urgent items, and updates status. You review the agent's decisions once a day. The analysis never stops.

This is not theoretical. An MCP-compatible feedback system exposes tools like `search_posts`, `merge_duplicates`, `update_status`, and `add_comment`. An agent with those tools can maintain a clean backlog continuously, rather than waiting for a weekly triage session that never quite happens. For the protocol, see [what is an mcp server](/blog/what-is-an-mcp-server). For hooking a feedback tool to a model, see [connect feedback tool to ai via mcp](/blog/connect-feedback-tool-to-ai-via-mcp). For the feedback-management case specifically, see [mcp server feedback management](/blog/mcp-server-feedback-management).

The unit of analysis stops being "last month's feedback" and becomes "the current state of the inbox." The question changes from "what themes showed up this month" to "what is the system's best current picture of the top unresolved themes." That is a qualitative jump, and it removes the bottleneck every other method has: a human sitting down to read.

Quackback has a built-in [MCP server](/features/mcp) that exposes the inbox, posts, comments, and status to a language model, so an agent can do the continuous triage work. It is open source, self-hosted, and free, so "graduating" to Method 5 is not a procurement exercise.

**When MCP agents work:** high volume, a stable taxonomy the agent can learn against, a team that wants the human in the review seat, not the data-entry seat.

**When they break:** no human review at all. An agent left alone will cheerfully merge the wrong tickets and close the wrong threads. The point is to move the human from "reading every item" to "reviewing the agent's decisions."

## How to choose: volume, team size, decision stakes

The opinionated version. Pick the lowest rung that answers your question. Graduate only when the method breaks.

| **Your situation** | **Recommended method** |
| --- | --- |
| Pre-PMF, 20 to 50 items a month | Method 1: spreadsheet |
| PM-of-one, 50 to 200 items a month | Method 2: fixed taxonomy tagging |
| Product team, 500 to 1,500 items a month | Method 3: thematic clustering |
| At scale, 1,500 to 5,000 items a month | Method 4: AI-assisted analysis |
| Continuous triage without a human bottleneck | Method 5: MCP agents |

Three rules for reading this table. Volume is the blunt cut, but decision stakes matter more — if you are deciding what to build for an enterprise customer, do not trust a machine cluster. Team size changes everything: one tagger can be consistent with a spreadsheet, three cannot. And the cost of a wrong answer sets the floor. High-cost decisions need human eyes on the final shortlist no matter what method produced it.

If you are weighing tools rather than methods, the [feedback analysis use case](/use-cases/feedback-analysis) page helps. For why analysis matters inside a product loop, see [customer feedback loop](/blog/customer-feedback-loop).

## Common mistakes that invalidate any method

Four mistakes will invalidate your analysis regardless of the method. Any method done with these mistakes is worse than no method, because it produces a confident answer that is wrong.

**Sampling bias — only looking at loud feedback.** The squeakiest wheel is the first thing you hear, but it is almost never the most important thing. Teams that only read support tickets miss the silent majority who never write in. Teams that only read Twitter miss everyone who is not on Twitter. Fix this by sampling from multiple channels, including low-effort ones like quick in-app widgets, before you start tagging.

**Over-tagging — fifty tags, none useful.** Tag sprawl is the single most common failure. You start with seven categories. A month later you have twenty. Three months later you have forty-eight. Nobody can remember them, tagging becomes inconsistent, and your pivot tables turn into confetti. The fix is to review your taxonomy every month and merge anything under five percent of volume into a larger bucket.

**Skipping the "what decision does this drive" question.** Before you tag a single item, write down the decision you want the analysis to support. "What should we build next quarter" is a decision. "Which category is biggest this month" is a report. Reports are not decisions. If you cannot name the decision, you are doing analysis theater, and you will finish with a pretty chart and no outcome.

**Forgetting to close the loop.** You read the feedback, you run the analysis, you ship something, and you never tell the users who asked for it. This is the mistake that quietly destroys your feedback source. People learn that writing in does not matter, and they stop. Next quarter, your volume drops, and you mistake it for "fewer complaints" when it is really "fewer speakers." The fix is operational: every shipped item should trigger a reply to the users who requested it. Quackback's [feedback](/features/feedback) workflow does this automatically, but the point is broader than the tool — close the loop on every method. The deeper mechanics of this are in [customer feedback loop](/blog/customer-feedback-loop).

---

The right customer feedback analysis method fits your current volume and team, not the screenshots on a landing page. Start at the bottom of the ladder. A disciplined spreadsheet with seven categories beats a neglected platform with twelve dashboards. When the spreadsheet breaks, graduate. When the fixed taxonomy breaks, graduate again. When human reading stops scaling, bring in AI. When periodic analysis stops scaling, bring in agents. For setup across each layer, see the Quackback [docs](/docs).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is the best way to analyze customer feedback?

The best method is the lowest-effort one that answers your actual question. For most teams under 200 items a month, that is a disciplined spreadsheet with six to eight fixed categories and a weekly pivot. Above that, a fixed taxonomy in a structured inbox. Above roughly 1,000 items a month, AI-assisted triage with human review. There is no single best method — there is a best method for your current volume and decision stakes.

### Can AI replace manual customer feedback analysis?

No, not completely. AI is good at first-pass work — deduplication, sentiment scoring, topic suggestions, and summarisation. It is unreliable on sarcasm, mixed intent, and edge cases. Use AI to narrow two thousand items down to the top twenty themes, then read those twenty yourself before making decisions. Treat AI as a filter, not a verdict.

### How many tags should a feedback taxonomy have?

No more than ten top-level tags. That is the upper bound where a human tagger can hold the full list in their head and tag consistently. If you need more granularity, use sub-tags under a stable top level. Review the taxonomy monthly and merge any tag under five percent of volume into a larger bucket.

### When does a spreadsheet stop being enough for feedback analysis?

Around 200 items a month, or as soon as more than one person is tagging, whichever comes first. The failure mode is tag drift — two people use slightly different words, and your pivots start lying. A fixed-taxonomy tool with dropdowns is the next step. See [feedback management](/blog/feedback-management) for the operational details.

### What is thematic analysis of customer feedback?

Thematic analysis is the practice of reading a sample of feedback, extracting the themes that repeat, and then grouping the rest against those themes. It differs from manual tagging because the categories emerge from the data rather than being defined in advance. It is the minimum viable method above about 500 items a month, and it is what AI clustering automates at higher volumes.

### Do you need a feedback platform to analyze customer feedback?

No. You can get real value from a spreadsheet for a long time. You need a platform when one or more of these breaks: volume above 200 items a month, more than one person tagging, or a need to track themes across multiple weeks without losing context. At that point, a structured inbox like [Quackback](/features/inbox) pays for itself by removing tag drift and enabling consistent reporting.

- [Customer Insights Tools: A Framework for Picking the Right One](https://quackback.io/blog/customer-insights-tools): Most customer insights tool roundups are one giant list. Here is a framework to pick by insight type: qualitative feedback, research, behavioral, or VoC.

Published: 2026-04-12

Search for "customer insights tools" and you find the same article twenty times. A flat list of products. Canny next to Mixpanel next to Dovetail next to Qualtrics. Each one pitched as a way to "understand your customers". None of the lists tell you that those products solve entirely different problems and rarely belong in the same shortlist.

This post groups tools instead of ranking them. Four categories, four questions, four jobs. Once you know which question you are trying to answer, picking a tool becomes an afternoon of trials rather than a month of demos.

![Four categories of customer insights tools: qualitative feedback, user research, behavioral analytics, and survey VoC](/blog/customer-insights-tools/hero.webp)

> Customer insights tools fall into four categories that solve different problems: **qualitative feedback** (what users want), **user research** (what users struggle with), **behavioral analytics** (what users do), and **survey / VoC** (how users feel). Pick the category that answers the question you cannot currently answer, not the longest feature list. Most teams should start with qualitative feedback, then add a second category once they feel a specific gap.

## What "customer insights" actually means (and does not)

An **insight** is not a data point. It is an interpretation of data that changes what you do next. "Three hundred users clicked upgrade this week" is data. "Users click upgrade when they hit the export limit, but churn when they discover export is throttled after upgrading" is an insight. Data is the raw material. Insight is the finished thought.

Most products marketed as customer insights tools are, strictly speaking, customer data tools. They collect, store, and visualize. The interpretation is still up to you. That is fine, as long as you know what you are paying for. Trouble starts when a team buys a behavioral analytics platform expecting it to tell them what features to build, then blames the tool when it does not.

The other trap is treating insight as one thing. A churned user telling you they left because onboarding was confusing is a different kind of insight than a funnel chart showing a forty percent drop at step three. Both are useful. Neither is a substitute for the other. Picking a tool means picking which kind of insight you need first.

So the first decision is not "which tool". It is "which question". You have four honest options.

## Four categories of insights tools

Here is the framework the rest of the post uses. Four categories. Four questions. Every tool worth considering slots into one of these boxes, and the boxes rarely overlap cleanly.

| **Category** | Typical tool | Primary question it answers | Data type |
| --- | --- | --- | --- |
| Qualitative feedback | Quackback, Canny, Productboard | What do users want to be different? | Submitted text, votes |
| User research | Dovetail, Maze, UserTesting | What do users struggle with in my product? | Interviews, task tests |
| Behavioral analytics | Hotjar, Mixpanel, Fullstory | What do users actually do? | Events, sessions |
| Survey / VoC | Typeform, Sprig, Qualtrics | How do users feel, and how widely? | Structured responses |

Read the questions carefully. "What users want" comes from people writing to you unprompted. "What users struggle with" comes from watching them try to do a thing. "What users do" comes from counting their clicks. "How users feel" comes from asking them on a scale from one to ten. Each question has a best-fit tool category.

Use qualitative feedback when you need to prioritize a backlog. Use research when you need to redesign a flow. Use behavioral analytics when you need to debug a funnel. Use survey and VoC when you need to measure sentiment or benchmark over time. If you catch yourself using one category to answer a different category's question, stop and revisit the framework.

## Qualitative feedback tools

This is the category most product teams should start with, and the one most often conflated with "analytics". Qualitative feedback platforms collect unsolicited input from your users and help you turn it into prioritized themes. Someone writes "I wish I could bulk edit tags" in a widget, that message lands in an inbox, it gets tagged and grouped with similar messages, and eventually it shows up as a candidate on your roadmap.

The question these tools answer is: **what do users want to be different?** Not what they do. Not what they struggle with. What they wish were true. That distinction matters because the people who take the time to write feedback are self-selecting into a specific signal: intent to see change. If you are early in product development and trying to decide what to build next, that signal is worth more than any funnel chart.

Representative tools in this category include [Quackback](/features/feedback), [Canny](/compare/quackback-vs-canny), and [Productboard](/compare/quackback-vs-productboard). All three share a basic shape: a submission channel (widget, portal, or API), an inbox where feedback lands, voting or prioritization, and a path from feedback to roadmap. Where they differ is in pricing model, extensibility, and how much AI they apply to triage.

Quackback is the open source option in the category. It is AGPL-3.0 licensed, self-hosted, and free to run, which matters when your whole support team wants to read the [feedback inbox](/features/inbox). AI triage is included. It ships with an [MCP server](/features/mcp) so your AI assistant can query feedback directly, which is a reasonably new capability in this space and one that changes how you work with the data. The [embeddable widget](/features/widget) handles in-app collection.

Canny is the default pick for teams that want hosted and simple and do not care about self-hosting. It is focused, well-designed, and has been around long enough that most product people recognize the pattern. The tradeoff is per-seat pricing and a feature set that is intentionally narrow. Productboard sits further upmarket, pulling in prioritization frameworks and roadmap views that overlap with general [product management tools](/blog/product-management-tools). It is more opinionated and more expensive.

If you are trying to pick within this category specifically, the [best customer feedback tools for 2026](/blog/best-customer-feedback-tools-2026) post goes deeper on the tradeoffs. For feature requests specifically, [best feature request tools](/blog/best-feature-request-tools) narrows the lens further. And the [feedback analysis use case](/use-cases/feedback-analysis) page walks through how feedback turns into themes in practice.

One honest warning. Qualitative feedback tools tell you what people who wrote in want. They do not tell you what silent users want. They do not tell you whether the requesters are representative of your whole base. You will always need a second source to sanity check. Usually that second source is either research or a survey.

## User research platforms

User research platforms are designed for a completely different activity: sitting down with users, watching them attempt tasks, and cataloging what they say and do. The question they answer is: **what do users struggle with when they use my product?** It is a question about friction, not desire.

Representative tools here include Dovetail, Maze, and UserTesting. Each serves a slightly different role, which is the first thing to sort out before you pick one.

Dovetail is a **research repository**. You feed it interview recordings, transcripts, and notes, and it helps you tag, cluster, and search across them. It is where you go when you have done thirty interviews over six months and need to remember what anyone said about pricing. Dovetail does not run the research, it stores and analyzes it. AI tagging works well as long as you feed it structured inputs.

Maze is an **unmoderated testing platform**. You upload a prototype or point it at a live URL, write task instructions, bring your own participants, and it runs them through the flow while recording clicks, heatmaps, and open-ended responses. The advantage is speed. You can test a flow with fifty users overnight. The disadvantage is that you lose the ability to ask follow-ups.

UserTesting is a **moderated and unmoderated testing platform** with a large recruited panel. You pay for access to participants matched to your target demographic. It is what you use when you have no existing users to recruit from, or when you want an outsider's view of a mature product. Expensive, but thorough.

Pick research tools when you have a specific design or flow you want to stress test. Skip them when you are at the "what should I build next" stage, because research is most useful when you have a hypothesis to test, not a blank page to fill. The [user interview questions](/blog/user-interview-questions) post has a starter kit of questions to run before you commit to a tool, and [continuous discovery habits](/blog/continuous-discovery-habits) covers the rhythm of running weekly interviews.

A common misstep is buying Dovetail before you are actually doing the research. An empty research repository is an expensive to-do list. Run six interviews first, then see if you wish you had a better way to organize the transcripts.

## Behavioral analytics

Behavioral analytics tools answer a different question entirely: **what do users actually do inside my product?** Not what they say they do. Not what they want to do. What they do. The gap between the three is often embarrassing, and that is usually where the useful insight lives.

Representative tools include Hotjar, Mixpanel, and Fullstory, though Amplitude and Contentsquare cover similar ground. Within the category, there are two sub-types worth knowing.

**Session replay and heatmap tools** like Hotjar and Fullstory record what individual users do on specific pages. You can watch a session back, see where someone hovered, where they rage-clicked, where they left. This is the tool you reach for when you have a specific page you suspect is broken and you want to see why. Heatmaps aggregate many sessions into click density maps, which are useful for landing pages and onboarding flows.

**Event-based product analytics** like Mixpanel and Amplitude track discrete actions across the whole product. You define events (user signed up, user created project, user invited teammate), tag them with properties, and then build funnels, retention charts, and cohort comparisons. This is the tool you reach for when you want to know whether a feature is being used, how often, and by which segment of users. It is the category that scales with your product and gets more valuable as you collect more data.

Behavioral analytics becomes necessary once you cannot see every user anymore. Below a couple of thousand active users, you can usually answer behavioral questions by watching a handful of recordings. Above that, you need aggregation.

What behavioral analytics cannot tell you is why. A funnel drop is a fact. The reason for the drop is an interpretation, and the interpretation usually requires either talking to users who dropped off or reading their feedback submissions. Behavioral analytics works best in combination with one of the other three categories, not on its own. [Qualitative vs quantitative feedback](/blog/qualitative-vs-quantitative-feedback) is a useful companion read.

## Survey and VoC tools

The fourth category is survey and voice of customer tools. The question they answer is: **how do users feel, and how widely is that feeling shared?** Sentiment and scale, in one question.

Representative tools include Typeform, Sprig, SurveyMonkey, and Qualtrics. There is a clean split within the category between **in-product micro-surveys** and **traditional long-form surveys**, and the split matters more than any feature comparison.

Sprig and the micro-survey features built into products like Intercom are designed to fire a one-question or two-question survey inside the product at a specific moment. "How did that onboarding feel?" triggered after a user completes setup. "Would you recommend us?" triggered at day fourteen. The point is that the question arrives while the experience is fresh, and the response rate is much higher than a survey sent by email three weeks later. Sprig has pushed hard on AI analysis of open-ended responses, which turns the micro-survey format into something closer to a continuous VoC stream.

Typeform, SurveyMonkey, and Qualtrics sit at the other end. You build a multi-step questionnaire, distribute a link, and wait for responses. This is the right tool for longer research surveys, post-purchase studies, NPS benchmarking, and anything that needs a controlled sample. Qualtrics is the enterprise-grade option with serious statistical tooling attached. SurveyMonkey is the default pick for general purpose. Typeform trades some rigor for a visual format users are more willing to finish.

Survey tools are where [voice of customer programs](/use-cases/voice-of-customer) often live in practice. The discipline of VoC is less about the tool and more about the cadence: collect regularly, segment ruthlessly, act on the themes that recur. For a deeper treatment of that discipline, the [voice of customer guide](/blog/voice-of-customer) walks through how to set up a program without drowning in spreadsheets. For sentiment specifically, [customer satisfaction metrics](/blog/customer-satisfaction-metrics) covers the scoring frameworks (CSAT, CES, NPS) that survey tools usually capture.

The risk with survey tools is over-reliance on numerical scores. An NPS of 42 is a number. It is not, on its own, an insight. The follow-up comment ("I love the product but hate the mobile app") is the insight. Whatever survey tool you use, make sure the comment field is treated as a first-class input, not an afterthought. [AI customer feedback analysis](/blog/ai-customer-feedback-analysis) covers how to extract themes from survey comments at volume.

## How to pick based on your stage and stack

Here is the opinionated part. The right combination of tools depends on where you are, not what you think looks complete on a shopping list.

| **Stage** | Must have | Nice to have | Skip |
| --- | --- | --- | --- |
| Pre-PMF / solo founder | Qualitative feedback, manual interviews | Lightweight survey | Behavioral analytics, research repo |
| Growing team (1–10k users) | Qualitative feedback, behavioral analytics | In-product micro-surveys | Enterprise VoC |
| Scaling (10k+ users) | Qualitative feedback, behavioral analytics, research platform | VoC surveys | — |
| Enterprise / regulated | All four categories | Dedicated CDP | — |

Pre-PMF means you are still learning what the product should be. Buying a behavioral analytics tool at this stage is premature. You do not have enough users for the charts to be meaningful, and the charts would not tell you what to build anyway. What you need is a channel for users to tell you what is wrong, which means a [feedback collection system](/blog/collect-customer-feedback) and the habit of actually reading it. Add weekly customer interviews. That is the stack. Skip the rest.

Growing means you are past the first product-market fit signals and shipping features to a real base. You start seeing patterns you cannot keep in your head. A funnel tool now earns its keep, because you cannot eyeball engagement from memory anymore. Qualitative feedback is still the primary input for roadmap decisions. Add [in-app feedback](/use-cases/in-app-feedback) collection so you catch users while they are inside the product, not after they have left.

Scaling means research starts to pay off. You have enough users to recruit from, enough designers to justify dedicated research tooling, and enough complexity that you cannot intuit what is breaking. Add a research platform. Run quarterly VoC surveys to benchmark sentiment over time.

Enterprise or regulated means you probably need all four, plus attribution across touchpoints (customer data platforms). The framework still holds: if you cannot name the question a tool answers in one sentence, you do not need it yet.

## Building an insights workflow without buying everything

The surprise for most teams is how far you can get with one tool plus a workflow. Tooling is the cheap part. Habit is the expensive part. Here are three concrete starter stacks for different team sizes.

**Solo founder or seed stage.** One qualitative feedback tool with an inbox, one shared Google Doc of interview notes, and a weekly thirty minute ritual of reading the inbox and tagging themes. That is it. If you pick an [open source feedback tool](/blog/open-source-feedback-tools), monthly spend is your hosting bill. The discipline is doing the reading. A lightweight [customer feedback loop](/blog/customer-feedback-loop) covers how to close the loop with users who wrote in, which is the single most useful action at this stage.

**Growing team of five to twenty.** Same qualitative feedback tool, now with proper tagging and a weekly triage meeting. Add a behavioral analytics tool for funnels and retention. Add one in-product micro-survey that fires at a key moment. That is three tools. A product manager should spend two hours a week in the feedback inbox and one hour a week in the funnel tool. If nobody on the team has those hours blocked, you do not have an insights problem, you have a calendar problem.

**Scaling team of twenty plus.** Add a research repository, a VoC survey tool, and a research ops function to run the interviews. Each category gets a clear owner. Product managers read feedback. Designers run research. Growth reads analytics. A VoC lead runs the surveys. The framework becomes organizational, not individual.

Across all three stacks, the workflow is the same three steps: collect, interpret, act. Collection is the part tools do well. Interpretation is partly tool, partly human. Action is entirely human. If your team is stuck, it is almost never because of missing tooling. It is because the insights are not reaching the people who make the build decisions. The [feedback management discipline](/blog/feedback-management) covers that handoff.

Pick the category that matches the question you cannot currently answer. Use one tool in that category for ninety days. Measure whether your decisions got sharper. If they did, add a second category. If not, the problem was never the tool.

If qualitative feedback is the category you are missing, [Quackback](/features/feedback) is built for it. AI triage is included, and the [MCP server](/features/mcp) lets your AI assistant query feedback directly. Run it self-hosted for free or use [Quackback Cloud](/pricing) if you would rather not manage infrastructure.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is the difference between customer insights tools and customer feedback tools?

Customer feedback tools are a subset of customer insights tools. Feedback tools capture unsolicited input from users, one of four insight categories. The broader insights term also covers user research platforms, behavioral analytics, and survey or VoC tools. Ask which specific question a vendor's tool answers before buying.

### Do I need more than one customer insights tool?

Eventually, yes. Each of the four categories answers a different question, and no single product covers all four well. Most teams start with one tool, usually qualitative feedback, and add a second category once they feel a specific gap. Run one tool for ninety days before adding another.

### What is the best customer insights tool for a startup?

A qualitative feedback tool plus a commitment to run weekly user interviews. At the startup stage, the bottleneck is decisions, not data volume. Collect unsolicited feedback, read it regularly, and turn it into build decisions. Self-hosted [open source options](/blog/open-source-feedback-tools) like Quackback are free to run while you are small.

### What is the difference between qualitative feedback tools and user research platforms?

Qualitative feedback tools collect input users submit unprompted, about things they want changed. User research platforms run structured studies with users you recruit, about specific flows or prototypes. Feedback tools answer "what do users want", research platforms answer "what do users struggle with". Most mature product teams use both.

### Can an open source tool replace a paid insights platform?

In the qualitative feedback category, yes. Self-hosted options cover the core workflow (collection, triage, voting, roadmap), often with AI triage and MCP access. In behavioral analytics and user research, open source options are narrower. A practical pattern is open source for feedback, paid tools for analytics.

### How do you turn customer insights into product decisions?

Three steps. Collect systematically across at least one category. Tag and group incoming data so themes emerge instead of individual requests. Review the top themes on a regular cadence with the people who make roadmap decisions in the room. Most teams fail at the last step, not the first two.

- [Feedback Management: From Scattered Inputs to Clear Priorities](https://quackback.io/blog/feedback-management): Feedback management is not a tool category. It is an operational workflow with four stages that turn scattered inputs into clear, shippable priorities.

Published: 2026-04-11

Most teams do not have a feedback problem. They have a feedback workflow problem. Requests arrive through support tickets, Slack, sales calls, email, and the in-app widget. Volume is not the issue. The issue is that nobody has defined what happens between the moment a user complains and the moment something ships.

![The four-stage feedback management workflow: intake, organize, prioritize, close the loop](/blog/feedback-management/hero.webp)

> Feedback management is not a tool category. It is an operational workflow with four stages — **intake**, **organize**, **prioritize**, and **close the loop**. Most teams treat it as a storage problem ("we need somewhere to put all the feedback"), which is why their feedback piles up and nothing changes. This guide covers the workflow, the frameworks that make each stage work, and what to look for in a system that supports it.

## What feedback management actually is (and why most definitions miss the point)

**Feedback management** is the operational practice of collecting user input, turning it into structured decisions, and communicating the outcome back to the people who sent it. That is the definition. It fits on a sticky note.

The definition is the easy part. Most articles that rank for this topic stop there, pivot to a tool roundup, and call it finished. That is why teams who read those articles still end up drowning in requests two months later. They bought a tool. They did not install a workflow.

Feedback management is not a category of software. It is a sequence of decisions someone on your team has to make, in order, every week, for every piece of feedback that comes in. Software supports that sequence. It does not replace it. Without the workflow, the tool becomes another inbox you avoid opening.

The rest of this guide is the workflow. Four stages, each with its own failure mode. You will recognize at least one as the one your team is stuck in right now.

## The four stages: intake, organize, prioritize, close the loop

Every functioning feedback management system moves each input through four stages. If any stage is missing, the whole system degrades into a graveyard of tickets nobody reads.

**Intake** is the moment feedback enters your system of record. It arrives through a form, a widget, a ticket, an email, or a sales call. The goal is consolidation. One place, one format, one owner.

**Organize** is the moment raw text becomes something you can count. Tags, themes, duplicates merged, noise filtered. The goal is to turn 500 tickets into 40 distinct requests with known volume behind each one.

**Prioritize** is the moment you decide what ships next. This is where RICE, MoSCoW, ICE, and Kano earn their keep. The goal is a ranked list that survives a skeptical question from your CEO.

**Close the loop** is the moment you tell the people who sent the feedback what happened. Shipped, rejected, under consideration, scheduled for Q3. Users only bother writing things down when they believe it matters.

Here is the shape of it at a glance:

| **Stage** | Input | Output | Typical owner |
| --- | --- | --- | --- |
| **Intake** | Raw text from any channel | A single normalized record | Support or product ops |
| **Organize** | Normalized records | Themed, deduplicated requests | Product manager |
| **Prioritize** | Themed requests | Ranked roadmap items | Product manager |
| **Close the loop** | Roadmap items and ship events | Notifications, statuses, changelog | Product or marketing |

Four stages, four owners, four failure modes. We will take them one at a time. For how the loop connects to retention and trust, see our guide to the [customer feedback loop](/blog/customer-feedback-loop).

## Stage 1: Intake without fragmentation

The first stage is where most teams already feel the pain. Feedback arrives from everywhere. Support forwards a ticket. A sales rep drops a Slack message saying "the customer on the call today asked for X again". A founder replies to a user's email and forgets to tell anyone. The marketing team notices a tweet. Nobody has a single place where all of this lives.

The predictable result is five or six partial inboxes. Support queue, sales CRM, Slack, the product manager's private Notion doc, the in-app widget if one exists. None of these talk to each other. None contain the full picture. No decision made from any single one will be correct.

The fix is conceptually simple and operationally hard. **Pick one system of record.** Route everything else into it. The system of record is where prioritization decisions get made. Every other channel is a funnel, not a destination.

Concretely: your support tool forwards or syncs tickets tagged "feedback" into your feedback tool. Your sales team has a one-click way to log a request from a call. Your Slack workspace has a command or emoji that turns a message into a feedback entry. Your product has an in-app widget so users can submit without leaving the thing they are complaining about. Every submission, regardless of origin, lands in the same place with the same schema.

This is the problem the [unified feedback inbox](/features/inbox) is built for. Every channel, one queue, one format, one owner. The [in-app widget](/features/widget) handles the last mile — users submit from inside your product with session context attached, so you do not chase them for screenshots or browser versions. We go deeper in our post on [how to collect customer feedback](/blog/collect-customer-feedback).

Resist the urge to filter at this stage. You are not deciding what is important yet. You are making sure nothing gets lost. Filter too aggressively at intake and you will throw away weak signals that turn out to matter three months later.

## Stage 2: Organizing feedback into themes

Once intake is unified, you hit the second problem. Raw feedback is noise. Five hundred tickets is not five hundred requests. It is maybe forty distinct requests, each mentioned between one and thirty times, wrapped in the language of whichever user happened to write that day. Until you turn the noise into signal, you cannot prioritize anything.

Organizing feedback is three jobs at once. First, **duplicate detection**. When twelve users ask for dark mode in twelve different phrasings, those twelve tickets collapse into one request with a count of twelve. Second, **themes**. A dark mode request, an accessibility audit, and a "too bright" complaint belong to the same theme. Third, **a fixed taxonomy** — a finite list of categories your team agrees on in advance. Not freeform tags that balloon to sixty entries, each used twice.

The fixed-taxonomy point is worth pausing on. Every team that tries freeform tagging finds the same failure mode. People tag inconsistently. "Bug" and "bugs" and "defect" and "broken" show up as separate tags. Within six months you have so many tags that filtering by any single one returns a misleading subset. A fixed taxonomy — ten to twenty categories, maintained by one owner — forces consistency, and the trade is always worth it.

This is also where AI earns its keep. Manual clustering of five hundred tickets is a week of work. An AI pass that groups similar tickets and proposes themes can turn that week into an hour, provided the human still makes the final call. **AI assists, it does not decide.** A product manager who accepts every AI cluster without reviewing will end up with a taxonomy that looks plausible and is subtly wrong. We cover the patterns in our guide to [AI customer feedback analysis](/blog/ai-customer-feedback-analysis).

Tying it back to the stack: the [feedback board](/features/feedback) is where organized requests live after intake, with duplicate detection built in. The [MCP server](/features/mcp) lets AI agents help with clustering while keeping the human in the final decision seat.

One warning. Teams sometimes skip this stage and jump straight to prioritization. They look at the raw inbox, pick the three loudest requests, and build those. The loudest requests are not always the most common, and the most common are not always the most valuable. You need the organize stage to tell the difference between a small group shouting and a large group murmuring.

## Stage 3: Prioritization frameworks that work

Now you have a clean list of distinct, themed, counted requests. Which one do you build next? This is where frameworks help, and where most teams overcomplicate the problem.

There are four frameworks you will run into repeatedly.

**RICE** scores each item by Reach, Impact, Confidence, and Effort. You divide the first three by the last, you get a number, you rank by the number. It works well when you have quantitative inputs and it punishes wishful thinking because low Confidence scores shrink the result. Read our [RICE framework explainer](/blog/rice-framework-explained) for worked examples.

**MoSCoW** sorts items into Must-have, Should-have, Could-have, and Won't-have. It is the right framework when you are working within a fixed deadline and you need to draw a line between what ships and what waits. See our [MoSCoW prioritization guide](/blog/moscow-prioritization) for the full method.

**ICE** is RICE minus Reach. Impact times Confidence divided by Effort. Faster to run than RICE and works well for smaller teams where you do not yet have reliable Reach numbers.

**Kano** classifies features by their effect on user satisfaction — basic expectations, performance features, and delighters. Less a ranking tool than a diagnostic, useful for avoiding the trap of shipping only basics or only delighters.

Here is the mistake almost every team makes. They pick two or three frameworks and run them in parallel. A RICE score, a MoSCoW bucket, and a Kano classification on every item. The output is a spreadsheet nobody can read, because three rankings give you three different "top" items. Frameworks force decisions, they do not defer them. Pick one as your primary. Use the others as spot checks when the primary feels wrong.

The second mistake is applying the framework to too many items. If your inbox has two hundred organized requests, you do not need RICE scores on all two hundred. You need them on the top thirty by volume and strategic fit. Pre-filter, then score.

A good [prioritization-aware roadmap](/features/roadmap) keeps the scored list, the public-facing ordering, and the sequencing in one place. The [voting system](/features/voting) gives you the Reach input directly — you do not have to guess how many users want something when they have voted on it.

This guide is category-generic. For larger organizations ranking across multiple product lines, the problem gets structurally harder because you are ranking portfolios, not features. We cover that in our post on [enterprise feedback management](/blog/enterprise-feedback-management).

## Stage 4: Closing the loop with users

This is the stage everyone skips. It is also the stage that decides whether the first three had any long-term value.

Here is what closing the loop means in practice. A user submitted feedback. Three months later, you shipped something related. Maybe exactly what they asked for. Maybe something adjacent. Maybe you decided not to ship it. In every case, the user needs to hear back. Not because you owe them an answer, but because if you do not tell them, they will conclude you never read the original submission, and they will stop writing things down. They will just leave.

The closed loop has three parts. First, **status updates on the original submission**. When a request moves from "under review" to "planned" to "in progress" to "shipped", the submitter should see it. Second, **direct notification when the feature ships**. Not a marketing blast — a specific notification to the people who voted for or submitted that request. Third, **a public record of what shipped**, which is the job of the changelog.

A [public roadmap](/features/roadmap) lets users see what you are considering. A [changelog](/features/changelog) lets them see what shipped. Voter notifications close the gap between "the feature exists" and "the person who asked knows about it". See our post on [how to keep a changelog](/blog/keep-a-changelog) for the discipline.

The failure mode here is treating the loop as optional. You ship, push the deploy, move on. The original submitter has no idea. Six months later your feedback volume quietly drops, and nobody can figure out why. The answer is always the same: you stopped closing the loop, so users stopped opening it.

## Common failure modes

You can have all four stages on paper and still have the system fall over. The failures are specific and repeatable.

**The silo problem.** Product has a feedback tool. Sales has a CRM. Support has a help desk. None talk to each other. Product ships a feature nobody asked for because it only saw a third of the signal. The fix is not another tool. Pick the product-side tool as the system of record and pipe the other two into it. An imperfect unified view beats a perfect siloed view every time.

**The over-tagging problem.** A product manager starts with ten tags. Six months later there are fifty. "UI", "Design", and "Visual" are three tags for the same thing. Filtering returns misleading subsets. The fix is a quarterly taxonomy cleanup: merge near-duplicates, retire unused tags, cap the total at twenty.

**The "promised a date" problem.** A public roadmap with specific dates is a promise you probably cannot keep. Something slips, the date moves, users feel lied to, nobody believes the next date. Publish horizons ("Now", "Next", "Later") instead of calendar dates. You commit to the direction, not the week.

**The ghost inbox.** Feedback arrives, gets filed, and is never looked at again. The inbox grows linearly forever. Users stop getting responses. Eventually nobody can face opening it. The fix is a weekly triage cadence, owned by one person, with a visible count of untriaged items. If the number grows for two weeks in a row, that is an incident, not a chore.

**The dogpile problem.** Ten customers ask for the same thing in ten different words. Without duplicate detection, each is a separate ticket. The feature looks like a niche request instead of a top-five demand. The fix is the organize stage doing its job — a tool that surfaces duplicates automatically. This is why [feature request tracking](/blog/feature-request-tracking) is a discipline, not a spreadsheet.

Most teams suffer from two or three at once. If you recognize more than two, start with the ghost inbox. Nothing else works if the inbox is a graveyard.

## What to look for in a feedback management system

If the workflow is on paper, the next question is which software supports it without getting in your way. Here is the checklist, split by priority.

**Must have.** Features that make the workflow possible at all.

- **Intake unification.** Every channel funnels into one queue. Email, widget, Slack, CRM, support tickets.
- **Duplicate detection.** Automatic, not manual. Without this, your prioritization inputs are systematically wrong.
- **Public roadmap.** Status visible to the people who submitted. Horizons, not dates.
- **Voter notifications.** When a requested feature ships, the people who voted hear about it automatically. The single most underrated feature in the category.
- **Prioritization tooling.** A place to attach scores and ordering without exporting to a spreadsheet.

**Nice to have.** Features that make the workflow faster once it is running.

- **AI triage.** Automatic clustering, theming, and duplicate suggestions. Human decides, AI does the grunt work.
- **MCP server.** A standardized way for AI agents to read and write to your feedback system. Emerging, not yet table stakes.
- **SSO.** Required for larger organizations.
- **Integrations.** Hooks into your existing stack without bespoke engineering.
- **Import and export.** You should be able to leave at any time with your data intact.

A few tools worth knowing about, in context and without ranking. **Canny** and **Productboard** are the category incumbents and cover most of the must-haves. **HubSpot Service Hub** and **Zendesk** bundle feedback features into larger support suites, useful if you already live in those ecosystems. **Quackback** is the open-source option — AGPL-3.0, self-hosted, AI included, 25 integrations, and the first MCP server in the category. Each makes different trade-offs. The right one depends on where your stack already lives and how much of the workflow you want to own.

The single most important predictor of success is not which tool you pick. It is whether your team runs the four-stage workflow every week. We have seen teams succeed on a spreadsheet and fail on the most expensive tool in the category. The workflow is the job. The tool just shapes it.

For an end-to-end view of the operational side, our [use case page on feedback management](/use-cases/feedback-management) walks through the concrete setup. If you are comparing open-source and hosted options directly, our [Quackback vs Canny comparison](/compare/quackback-vs-canny) covers the trade-offs.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is the difference between feedback management and customer support?

Customer support is reactive: somebody has a problem now and you solve it. Feedback management is the layer above, turning patterns from those conversations into decisions about what to build next. Support says "my export is broken". Feedback management says "fifteen users reported export problems this quarter".

### Do I need a dedicated feedback management tool?

Not always. A small team with fewer than fifty users can run the four-stage workflow on a spreadsheet and a shared inbox, provided somebody owns the weekly triage. The moment you cross about a hundred active users or start receiving feedback through more than two channels, a dedicated tool saves more time than it costs. The trigger is not company size — it is the moment the ghost inbox appears.

### How do you prioritize customer feedback?

Pick one framework and run it consistently. RICE is the default recommendation for product teams with quantitative inputs. MoSCoW works better when you have a fixed deadline. ICE is faster and suits smaller teams. Whatever you choose, the critical rule is to apply it after you have organized and deduplicated the raw feedback, not before. Prioritizing raw tickets gives you the loudest requests, not the most valuable ones.

### What is the best way to close the loop with customers on feedback?

Automate the notification. When a feature ships, the people who voted for or submitted the request should get a direct notification from the system, not a generic marketing email. Keep a public changelog so non-voters can see what changed. Use horizons rather than calendar dates on your public roadmap, so you can communicate intent without making promises you might miss.

### How does AI help with feedback management?

AI is most useful in the organize stage. Duplicate detection, theme clustering, tag suggestions, and sentiment tagging all benefit from a model that can read natural language at scale. Use AI to propose, and use a human to decide. AI that makes unreviewed clustering decisions will produce a taxonomy that looks reasonable and is subtly wrong. We cover the concrete patterns in our [AI feedback analysis guide](/blog/ai-customer-feedback-analysis).

### Can a spreadsheet work for feedback management?

Yes, for a while. A spreadsheet handles intake and organization fine if you stay disciplined about the schema. It breaks down at duplicate detection (no clustering of near-identical records) and at closing the loop (no notification when a request ships). Once either matters, graduate to a tool. See our [spreadsheet-based approach](/blog/feature-request-tracking-spreadsheet) post.

- [The Customer Satisfaction Metrics That Actually Matter (Ranked by Stage)](https://quackback.io/blog/customer-satisfaction-metrics): 12 customer satisfaction metrics that matter — and which to track at each company stage. Opinionated guide with formulas, benchmarks, and what to stop.

Published: 2026-04-10

Most teams track too many customer satisfaction metrics and act on almost none of them. Every listicle treats them as interchangeable, when the right metric depends on your stage and the decision you are trying to make.

![12 customer satisfaction metrics grouped into core, supporting, and advanced tiers](/blog/customer-satisfaction-metrics/hero.webp)

**TLDR:** Most teams track too many customer satisfaction metrics. The four that actually matter are **CSAT**, **NPS**, **CES**, and **churn rate**. Supporting metrics (CLV, retention, response time, resolution rate) and advanced metrics (health score, PQR, time-to-value, detractor recovery) come later, and only if they change a decision you would otherwise get wrong. This guide ranks 12 metrics by company stage, shows how to instrument each without tool sprawl, and identifies which ones to stop tracking.

## The 4 metrics that actually matter

If you run a product with paying customers, you need exactly four numbers. Everything else is optional.

### CSAT (Customer Satisfaction Score)

**CSAT** measures satisfaction with a specific interaction. Ask one question on a 1-to-5 scale: "How satisfied were you with this experience?" Count 4s and 5s as satisfied.

Formula: `(satisfied responses / total responses) × 100`

Start tracking CSAT as soon as you have ten paying customers. It tells you which touchpoint is broken right now. If CSAT on ticket resolution drops from 92% to 78% in a week, you have a support problem you can investigate the same afternoon.

The common mistake is averaging CSAT across every interaction type into a single top-line number. Segment by touchpoint or do not bother. Our [CSAT calculator](/tools/csat-calculator) handles the math; see [how to ask for customer feedback](/blog/how-to-ask-for-customer-feedback) for timing.

### NPS (Net Promoter Score)

**NPS** asks: "How likely are you to recommend us?" on a 0-10 scale. Promoters are 9-10, passives 7-8, detractors 0-6. The score is promoters minus detractors, from -100 to +100.

Formula: `% promoters − % detractors`

Start tracking NPS once you have 100 active customers. With fewer, the sample is noise. NPS is a trend metric, not a snapshot. An eight-point drop quarter over quarter means something shifted.

The common mistake is treating NPS as a universal health score. It correlates weakly with churn in self-serve and strongly in enterprise. Use it as one data point. Our [NPS calculator](/tools/nps-calculator) and [NPS survey template](/blog/nps-survey-template) cover the mechanics.

### CES (Customer Effort Score)

**CES** measures how much work a customer had to do. Ask: "How easy was it to [complete task]?" on a 1-to-7 scale, reverse-coded so higher is better.

Formula: `sum of scores / number of responses`

Start tracking CES when you have self-serve onboarding or a help center. It drives product and documentation decisions. If CES on "find the export feature" is 3.2, your navigation is broken.

CES is the best predictor of repeat purchase in research from CEB (now Gartner). The common mistake is asking CES after every interaction, which trains customers to ignore surveys. Ask on moments that matter: post-onboarding, post-resolution, post-upgrade. Full write-up in [customer effort score](/blog/customer-effort-score).

### Churn rate

**Churn rate** is the percentage of customers who leave in a given period. For subscription businesses, it is the only satisfaction metric that directly ties to revenue. If CSAT is up and churn is up, CSAT is lying.

Formula: `(customers lost in period / customers at start of period) × 100`

Track churn from day one. The decision churn drives is existential: is the business working. Everything else is diagnostic. The common mistake is tracking logo churn and ignoring revenue churn. A 2% logo churn sounds fine until your two largest accounts are in that 2%. Track both. [Customer retention strategies](/blog/customer-retention-strategies) covers what to do when churn climbs.

## 4 supporting metrics

These matter once you have a support team, a success team, or a finance team modeling the business. Before that, they are a distraction.

### CLV (Customer Lifetime Value)

**CLV** estimates the total revenue you will earn from a customer. Simple version: average revenue per account times average lifespan in months.

Formula: `ARPA × average lifespan (months)`

Track CLV when you want to decide how much to spend on acquisition. If CLV is $2,400 and CAC is $800, you have a 3:1 ratio and room to push. The decision it drives is acquisition spend, not product. The common mistake is using CLV to justify every customer-facing hire. Treat it as a budget constraint, not a strategy.

### Retention rate

**Retention rate** is the inverse of churn over a longer window, usually 12 months. It tells you what share of customers stick around.

Formula: `((customers at end − new customers) / customers at start) × 100`

Start tracking retention once you have twelve months of data. Churn tells you how many are leaving now; retention tells you how durable the base is. Monthly churn can look great while 12-month retention is quietly collapsing. The common mistake is tracking retention without cohorting by signup month. Always cohort.

### FRT (First Response Time)

**FRT** is how long a customer waits before a human replies to a ticket. Business hours only.

Formula: `average time from ticket creation to first human response`

FRT matters when support becomes a team, not a side job. The decision it drives is staffing. If FRT creeps from 45 minutes to 4 hours, you need another support person or better automation. The common mistake is optimizing FRT at the expense of resolution quality. A 30-second auto-reply that does not answer the question is worse than a two-hour reply that does.

### Resolution rate

**Resolution rate** is the percentage of tickets closed without being reopened within 7 days. Reopens mean you did not actually solve the problem.

Formula: `(tickets closed and not reopened / total tickets closed) × 100`

Start tracking once you have ten support tickets a week. It is the cleanest signal for support quality and drives training decisions: which agents or ticket types have high reopen rates. The common mistake is measuring tickets closed without the reopen filter. That rewards speed at the expense of correctness.

## 4 advanced metrics

These are for teams past $5-10M ARR with a dedicated CS function. Adopting them too soon is how you end up with a 14-metric dashboard that nobody reads.

### Health score

**Health score** is a composite 0-100 number blending product usage, support tickets, NPS, and billing status into a single account signal. There is no universal formula; you build one from your data.

It is worth the investment when you have a CS team prioritizing outreach across hundreds of accounts. It drives one decision: who does CS call this week. The common mistake is shipping a health score that nobody trusts. If your CSMs override the score every time, the model is wrong. Rebuild it with their input or delete it.

### PQR (Product-Qualified Retention)

**PQR** is the retention rate of customers who have hit a defined activation event. It predicts long-term revenue better than raw retention because it filters out tire-kickers.

Formula: `retention rate of customers who reached [activation event]`

Track PQR when you have a self-serve motion and a clear activation event. If PQR is 90% but overall retention is 60%, your activation funnel is leaking. Fix onboarding, not retention. The common mistake is choosing an activation event that is too easy (logged in twice) instead of one that correlates with real use.

### TTV (Time-to-Value)

**TTV** is the time from signup to the customer's first meaningful outcome. Not first login. First real outcome: first feedback collected, first roadmap published, first integration connected.

Formula: `median days from signup to first value event`

TTV matters when you want to improve trial-to-paid conversion. If median TTV is 11 days and you convert 18% of trials, shaving TTV to 3 days is probably worth more than a new pricing page. The common mistake is tracking mean instead of median. One power user who activates in an hour hides a long tail who never activate.

### Detractor recovery rate

**Detractor recovery rate** is the percentage of NPS detractors who become passives or promoters in the next survey cycle after you follow up.

Formula: `(detractors who improved score / detractors contacted) × 100`

Track this when you have a success team with capacity for at-risk outreach. If recovery rate is 45%, keep doing it. If it is 8%, your follow-up playbook is broken. The common mistake is not measuring this at all and assuming outreach works. Half of detractor follow-up programs do nothing measurable.

## How to choose by company stage

Most teams adopt metrics in the wrong order and end up with dashboards that look sophisticated and drive no decisions.

| **Stage** | Revenue | Metrics to track | Metrics to ignore |
| --- | --- | --- | --- |
| **Pre-PMF** | $0-$100k ARR | Churn, qualitative feedback, CSAT on key interactions | Everything else |
| **Early traction** | $100k-$1M ARR | Churn, CSAT, CES on onboarding, retention | NPS, health score, CLV |
| **Growth** | $1M-$10M ARR | Churn, CSAT, NPS, CES, retention (cohorted), FRT, resolution rate | Health score, PQR, detractor recovery |
| **Scale** | $10M+ ARR | All core + supporting + advanced as needed | None; be deliberate |

Pre-PMF, the only metric that matters is whether people stay or leave, and why. Be on a call with every churned customer. A [voice of customer](/blog/voice-of-customer) practice does more than any dashboard.

Early traction is when CSAT earns its place. Ignore NPS; your sample is too small to mean anything. Track CES on onboarding because activation is the biggest lever you have.

Growth stage is when NPS becomes meaningful and when [customer feedback loops](/blog/customer-feedback-loop) need real structure. You can also justify FRT and resolution rate because support is now a team.

Scale is when you earn the right to advanced metrics. The test is simple: if adopting a metric would not change a decision you are currently getting wrong, do not adopt it.

## How to instrument each without tool sprawl

Most teams over-instrument. Every new metric becomes a new tool, a new integration, a new dashboard. Half get abandoned. Here is the opinionated minimum.

**CSAT**: Ask a single 1-5 question immediately after a ticket resolution or onboarding milestone. Inline in email or in-product. Do not send a separate survey email a day later; response rates collapse. A [feedback widget](/features/widget) embedded in your app captures CSAT at the moment of truth.

**NPS**: Quarterly, in-product, one question. Not monthly. Not via email blast. Rotate which segment sees it so you always have a fresh sample without fatiguing the base. A [feedback platform](/features/feedback) with built-in NPS keeps the survey, responses, tags, and follow-up in one place.

**CES**: One question on the page where the effort happened. Post-onboarding, post-help-article, post-resolution. Same widget as CSAT; only the question and trigger change.

**Churn**: Your billing system is the source of truth. Do not calculate churn from product analytics or CRM data; it will be wrong. Pull cancelled subscriptions from Stripe or Chargebee and cohort by signup month.

**CLV and retention**: Same source, plus ARPA. A spreadsheet or basic BI query, not a new tool.

**FRT and resolution rate**: Your help desk (Zendesk, Freshdesk, Front, Help Scout) already tracks both. Turn on built-in reporting.

**Health score, PQR, TTV, detractor recovery**: You need a customer data warehouse and a BI tool by this point. If you do not have one, you are not ready for these metrics.

The rule: every metric should be collected by the tool that already owns that data surface. Surveys in a feedback tool. Billing in billing. Support in the help desk. See [feedback analysis](/use-cases/feedback-analysis) and [the docs](/docs) for wiring up Quackback.

## Metrics to stop tracking

This is the section every other guide skips. You need to actively stop tracking the wrong metrics, because every vanity number in the dashboard costs weekly meeting time and gives the team permission to ignore the ones that matter.

**Raw ticket volume**. Total tickets per week tells you nothing. It conflates growth (more users, more tickets) with quality (broken product, more tickets). A flat ticket count during a growth phase is a win; a rising count during a flat phase is a disaster. Track tickets per 100 active users or drop it.

**Positive sentiment percentage**. Aggregate sentiment scores look impressive in a board deck and move almost never. A 2-point drop could mean one unhappy power user or a systemic issue; you cannot tell without reading the underlying feedback. Read the feedback. Skip the aggregate.

**NPS without segmentation**. A single company-wide NPS is the worst version of a useful metric. Enterprise and self-serve customers have different baselines. Averaging produces a number that describes no actual segment. Segment by plan, tenure, or use case, or stop reporting it.

**Aggregate CSAT with multiple products**. If you have two products or two personas, an aggregate CSAT is a lie. One product can be 95 and the other 72; you will see 83 on the dashboard and do nothing. Break it apart or delete it.

**Survey response rate as a goal**. Response rate is a diagnostic, not a target. Chasing it leads to badgering customers with repeat surveys, which poisons the data. Aim for signal, not volume. More in [improve survey response rates](/blog/improve-survey-response-rates).

## Turning metrics into decisions

A metric that does not change behavior is a cost, not an asset. The framework is simple: every metric needs an owner, a threshold, and a trigger action.

**Owner**. One person. Not a team, not a committee, not "we". The owner explains why the number moved this week and what they are doing about it. If nobody owns a metric, it dies quietly in a dashboard.

**Threshold**. A specific line that triggers an action, not a direction. CSAT on ticket resolution below 85% triggers a review. NPS drop of more than 5 points quarter over quarter triggers a cohort analysis. CES above 4.5 on any touchpoint triggers a product conversation.

**Trigger action**. What happens when the threshold is crossed. Not "investigate". An actual workflow. Example: CES above 4.5 flags the top-3 friction points from tagged feedback and routes them to the roadmap within 2 weeks.

Without all three, you have a number. With all three, you have a system. A feedback platform helps with the last two: tagged feedback, trend tracking, and roadmap routing are the infrastructure that turns metric movement into product decisions.

## Tooling: what a feedback platform handles vs. what you still need

Here is the honest breakdown.

A feedback platform like Quackback handles:

- NPS, CSAT, and CES surveys (widget-based and email)
- Response collection, tagging, and trend tracking
- Sentiment analysis on free-text responses
- Feedback-to-roadmap linking so detractor responses influence what you build
- Integrations with support and product tools
- An MCP server if you want your AI setup to query customer feedback directly

Quackback is open source under AGPL-3.0 and self-hosted, with AI analysis included. That covers roughly 60% of the customer satisfaction stack for a team under $10M ARR.

What you still need:

- **Product analytics**: Mixpanel, Amplitude, PostHog. Feedback tools do not track event streams, funnels, or feature adoption.
- **Billing and revenue metrics**: Stripe or Chargebee. Churn, revenue retention, and CLV live here.
- **Support metrics**: Zendesk, Freshdesk, Front, or Help Scout. FRT and resolution rate are native to the help desk.
- **BI layer**: Once at scale, a warehouse and a BI tool (Metabase, Looker, Hex) are how advanced metrics get calculated.

The trap is buying a single tool that claims to do all of the above. It will do each job badly. Pick one tool per data surface and keep the stack small. For a deeper comparison, see [best customer feedback tools 2026](/blog/best-customer-feedback-tools-2026) and [collect customer feedback](/blog/collect-customer-feedback).

## Frequently asked questions

### What is the most important customer satisfaction metric?

Churn rate. Everything else is diagnostic; churn is the only metric that directly tells you whether the business is working. If churn is healthy, most other metrics will be healthy too, and if churn is bad, no CSAT number will save you. Track churn from day one and treat it as the primary signal.

### How often should I survey customers for CSAT?

Ask CSAT immediately after a specific interaction, not on a schedule. A support ticket resolution, an onboarding call, a billing change. Never send a standalone "how are we doing" CSAT email. Response rates will be low and the data will be biased toward complainers and superfans.

### What is a good NPS score?

Above 30 is good for SaaS, above 50 is excellent, above 70 is world-class and usually suspicious. The more useful question is whether your NPS is trending up or down quarter over quarter, segmented by customer type. An absolute NPS number without a trend or a segment tells you almost nothing.

### Should a startup track NPS before product-market fit?

No. You do not have enough customers for the sample to be meaningful, and the time you spend running NPS surveys is time you should spend talking directly to every user. Pre-PMF, do qualitative interviews and track churn. NPS earns a place on your dashboard once you pass 100 active customers.

### How do you measure customer effort score?

Ask one question in context: "How easy was it to [complete task]?" on a 1-7 scale, where higher means easier. Ask it at the moment the effort happened, not later. Post-onboarding, post-help-article, post-resolution. Average the numeric responses and tag the free-text ones. See the full writeup in [customer effort score](/blog/customer-effort-score).

### What is the difference between CSAT, NPS, and CES?

CSAT measures satisfaction with a specific interaction. NPS measures overall relationship strength and loyalty. CES measures the effort a customer had to put in to get something done. They answer different questions and should be used together, not as substitutes. CSAT is tactical, NPS is strategic, CES is operational.

- [Product-Led Marketing: Your Changelog, Roadmap, and Widget Are Distribution Channels](https://quackback.io/blog/product-led-marketing): Your public changelog, roadmap, and feedback widget are distribution channels your product already owns. Here is how to use them as PLM surfaces.

Published: 2026-04-09

Most posts about product-led marketing repeat the same definition and the same Slack and Dropbox case studies. This post takes a different angle. Every product already owns three public surfaces that function as distribution channels. Most teams treat them as admin. The teams that win treat them as marketing.

![Three distribution surfaces every product already owns: changelog, roadmap, and feedback widget](/blog/product-led-marketing/hero.webp)

**TLDR:** Product-led growth is about your product driving adoption. Product-led marketing is about your product's public surfaces driving distribution. Three surfaces every product already owns — the **changelog**, the **public roadmap**, and the **feedback widget** — function as content, credibility, and retention channels when you treat them like channels. Most teams ignore them.

## What product-led marketing actually means (and why PLG is not PLM)

**Product-led growth** is a go-to-market model where the product itself drives acquisition and expansion. A free trial that converts without a sales call is PLG. A viral referral loop baked into the product is PLG. The product is the engine.

**Product-led marketing** is related but not the same. PLM is the practice of treating your product's public surfaces — the parts prospects and users can see without logging in, or see while using the product — as marketing channels. PLG asks "how does the product acquire users?" PLM asks "what does the product broadcast to the world?"

The two share DNA. A PLG company benefits from strong PLM because its growth depends on the product's legibility. But you do not need to be a PLG company to do PLM. A sales-led B2B tool with a public changelog and roadmap is doing PLM. A freemium app with a locked changelog and private roadmap is doing PLG without PLM, and leaving distribution on the table.

The distinction matters because the playbook is different. PLG is about onboarding, activation, and pricing. PLM is about what your product says when nobody from your team is in the room.

## The three distribution surfaces every product already owns

Every product that ships has three public surfaces it can choose to publish:

1. **The changelog.** What you shipped and when.
2. **The public roadmap.** What you are building and what is next.
3. **The feedback widget.** Where users tell you what to build.

Call these **the free shipping surface**. You are going to ship the work anyway. Publishing what you ship costs nothing extra. Each surface does a different job. Together they replace a surprising amount of the marketing work most teams pay for elsewhere.

Most teams treat these as internal artifacts. The changelog lives in a Notion page updated once a quarter. The roadmap is a private Linear board. The widget is a support email nobody reads. This is the default state, and it leaves the channels unused.

The teams that do PLM well flip this. They make all three public by default, put them on the marketing site, and treat each one as a content channel with its own cadence and audience.

## Your changelog is a content channel

A changelog is a running log of what shipped. Treated correctly, each entry is a piece of content. Search engines index it. Existing users subscribe to it. Prospects use it to check whether the product is alive. Every entry is a reason for someone to come back to your site.

The mechanics are simple. Publish a dated entry every time you ship something users can see. Write one or two sentences in plain language. Link to screenshots or a short loop if the change is visual. Tag the entry by area so readers can filter.

The [keep a changelog convention](/blog/keep-a-changelog) is a reasonable starting point for format. It solves the hardest part, which is deciding what goes in and what the categories are. You do not have to follow it exactly, but you do have to pick a format and stick with it.

Changelog entries are also raw material for every other content format. A week of entries becomes a [product update announcement](/blog/product-update-announcement) email. A month of entries becomes a recap post. A quarter becomes a release note you send to customers. You are writing atoms once and composing them into molecules later.

A tool like the [Quackback changelog](/features/changelog) publishes entries to a clean route, generates an RSS feed, and lets users subscribe by email. The point is not the tool. The point is that the changelog stops being a Notion page and becomes a place on the internet.

## Your public roadmap is a credibility channel

A [public roadmap](/features/roadmap) does one job no other marketing asset does well. It shows prospects that your product is alive and that you are building toward something.

Evaluation-stage deals die for a specific reason more than any other: the buyer cannot tell if the product will be around in twelve months. A private roadmap gives them nothing to go on. They read the last blog post, see it is from six months ago, and move to the next option. A public roadmap closes that objection without a sales call. The buyer sees items in progress, items shipped last month, and items queued for next quarter. The product is a going concern.

Public roadmaps also reduce support load. Users who want a feature can check the roadmap, upvote it, and see where it is. That is one fewer email to your queue and one more signal to you about what matters.

The objection most teams raise is that a public roadmap forces you to commit to dates. It does not. Use status columns — **Exploring**, **Planned**, **Building**, **Shipped** — and no dates on individual items. You are publishing direction, not deadlines.

A [feature request tracking](/blog/feature-request-tracking) system feeds directly into this. User-submitted requests become roadmap candidates. Upvotes become prioritization signal. The roadmap becomes a living document that reflects actual demand instead of internal opinion.

## Your feedback widget is a retention and referral channel

The third surface is the one most teams miss. A feedback widget embedded in your product turns a silent user into a participating one. Every upvote is a micro-commitment. Every submitted request is a user telling you they care enough to type a sentence. Every fulfilled request is a moment where the user gets something they asked for and attributes it to you.

The [feedback widget](/features/widget) is a retention channel because it creates a conversation with users who would otherwise bounce. A user who hits a missing feature has two options. Option one: close the tab and forget about you. Option two: click a widget, write a sentence, and move on. The first costs you the user forever. The second buys you a chance to close the loop.

The widget is also a referral channel. Users who get a feature they asked for tell other users, tell their team, and post about it. The [customer feedback loop](/blog/customer-feedback-loop) — submit, acknowledge, build, ship, notify — is the mechanism that turns silent usage into advocacy. Each full loop produces at least one user with a story about the product doing something for them.

The widget is the smallest of the three surfaces and the one with the highest leverage. You can add it to a product in a day.

## Metrics: how to tell if your product is marketing itself

PLM is measurable if you know where to look. Here are the signals that matter.

| **Signal** | What it tells you |
| --- | --- |
| Organic traffic to `/changelog`, `/roadmap`, `/feedback` | Your surfaces are ranking and attracting visitors without paid spend |
| Sign-ups with "direct" referral source after visiting those pages | Your surfaces are converting visitors into users |
| Widget opens per session | Your product is inviting conversation rather than ending it |
| Time from first feedback submission to churn | Longer is better — engaged users stick around |
| Upvotes per published roadmap item | Your roadmap reflects demand rather than internal guesses |
| RSS subscribers on the changelog | You are building an owned audience |
| Share of feedback items that ship within 90 days | Your loop is short enough to produce repeat engagement |

None of these require a dedicated analytics pipeline. If you run a [product strategy guide](/blog/product-strategy-guide) review every quarter, these belong in the same dashboard as your usage and revenue metrics.

The signal that matters most is the second one. If visitors to your changelog or roadmap are signing up without being tagged by a paid channel, your product's public surfaces are doing marketing work. That is PLM working.

## What breaks when marketing and product do not share these surfaces

Each surface has a specific failure mode when it is ignored.

**A stale changelog erodes trust.** If the most recent entry is from four months ago, every visitor concludes the product is dying. They are often wrong, but the conclusion has been reached. A stale changelog is worse than no changelog.

**A private roadmap kills evaluation-stage deals.** Prospects who cannot see what you are building assume you are not building anything. They will not ask. They will quietly move to a competitor whose roadmap they can see. You never learn the deal existed.

**A widget without follow-through breeds cynicism.** Asking for feedback and ignoring it is worse than not asking. Users who submit a request and hear nothing conclude you do not care. The fix is not a bigger team. The fix is acknowledgment — an automated reply, a status change, a comment from a real person within a week.

All three failures come from treating these surfaces as internal admin rather than public commitments. The moment you commit publicly, the incentive to maintain the surface aligns with the incentive to do the work.

## Getting started without a PLM team

You do not need a PLM team to do PLM. You need three weeks and a tool that publishes the surfaces for you.

**Week 1: Publish the changelog.** Pick a format. Write entries for the last four things you shipped. Put them at `/changelog` on your marketing site. Add an RSS feed. Commit to one entry per week. A [public changelog tool](/features/changelog) handles this end to end.

**Week 2: Make the [roadmap](/features/roadmap) public.** Move your internal board to a public route or publish a filtered view of it. Use four columns: Exploring, Planned, Building, Shipped. No dates. Seed the columns with whatever is in flight. Link to it from your navigation.

**Week 3: Add the widget.** Drop a feedback widget into your app. One button, one text field, one submit action. Route submissions into the same tool that manages your roadmap so upvotes feed prioritization automatically.

If you want all three surfaces in one system, Quackback ships them as a single product. It is open source under AGPL-3.0, self-hosted, and free. AI triage is included. It has 25 integrations and an MCP server for agent workflows. The [Quackback documentation](/docs) covers setup. If you are comparing options, the [Quackback vs Canny comparison](/compare/quackback-vs-canny) lays out the tradeoffs.

The tool is not the point. The pattern is the point. Three surfaces, published, maintained, treated as channels. That is product-led marketing.

## Frequently asked questions

### What is the difference between product-led growth and product-led marketing?

Product-led growth is a go-to-market model where the product itself drives acquisition and conversion — free trials, self-serve onboarding, viral loops. Product-led marketing is a practice of treating your product's public surfaces as marketing channels. You can do PLM without being a PLG company, and a PLG company benefits from strong PLM. They share DNA but solve different problems.

### Does product-led marketing work for B2B?

Yes, and arguably better than for consumer products. B2B buyers spend weeks in evaluation and look for signals that a product is alive and well-supported. A public changelog and roadmap answer that question directly. They are especially effective for mid-market and enterprise deals where the buyer needs to justify the choice internally.

### How do I measure product-led marketing?

Track organic traffic to your `/changelog`, `/roadmap`, and `/feedback` routes. Track sign-ups with a direct referral source from visitors who saw those pages. Track widget opens per session and the share of feedback items that ship within 90 days. The headline metric is sign-ups from visitors to your public surfaces — that number isolates PLM's contribution.

### What is the cheapest way to start with product-led marketing?

Publish a changelog on a static page and commit to one entry per week. That is the minimum viable surface. It costs nothing and takes an hour to set up. Add a public roadmap next — a filtered view of your existing board is enough. Add a feedback widget third. An open-source tool like Quackback gives you all three for free if you self-host.

### Do I need a dedicated team to run these surfaces?

No. The surfaces work precisely because they piggyback on work you are already doing. The changelog documents shipped work. The roadmap reflects planned work. The widget collects feedback you would receive by email anyway. The overhead is publishing discipline, not new headcount. One person on the product team can own all three surfaces part-time.

- [6 Best Zendesk Alternatives for Customer Support in 2026](https://quackback.io/blog/best-zendesk-alternatives): Zendesk too expensive or too complex? Compare Freshdesk, Help Scout, Intercom, Front, Zoho Desk, and HubSpot Service Hub on pricing, features, and fit.

Published: 2026-04-08

Zendesk Suite starts at $55 per agent per month and climbs to $115 per agent per month for the Professional tier. A ten-agent support team on Suite Professional costs $13,800 a year before a single add-on. Add AI, workforce management, or quality assurance modules and the bill goes up again.

For a lot of teams, that math does not work. Zendesk is still the most comprehensive help desk on the market — nobody disputes the feature depth — but comprehensive has a price, and the market has filled with alternatives that cover most of what most teams actually use for a fraction of the cost.

This article compares the six strongest Zendesk alternatives for customer support in 2026. The goal is to help you work out which one matches your team's workflow, budget, and support volume. At the end, I will also cover an edge case most of these lists skip: what to do if the thing driving you off Zendesk is not the ticket system at all, but the fact that Zendesk cannot do product feedback properly.

![Six decision criteria for choosing a Zendesk alternative, each with a recommended tool](/blog/best-zendesk-alternatives/hero.webp)

> The best Zendesk alternatives for customer support are Freshdesk, Help Scout, Intercom, Front, Zoho Desk, and HubSpot Service Hub. Freshdesk is the most direct feature-for-feature swap and the cheapest credible option for most teams, with a 6-month free tier for 1-2 agents and paid plans from $19 per agent per month. If the real gap is product feedback rather than ticketing, pair your help desk with a dedicated feedback tool instead of switching.
>
> *Pricing last verified April 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

Ranked, the strongest options:

1. **Freshdesk** — The most direct feature-for-feature alternative. Free tier for 1-2 agents (6 months). Paid plans from $19/agent/month.
2. **Help Scout** — Clean, email-first shared inbox. Standard plan $25/user/month. Strong fit for smaller teams.
3. **Intercom** — Conversational support with strong AI (Fin agent). Essential plan $29/seat/month plus $0.99 per AI resolution.
4. **Front** — Collaborative shared inbox that looks and feels like email. Starter $25/seat/month, Professional $65/seat/month.
5. **Zoho Desk** — The cheapest credible option. Free for up to 3 agents. Paid plans from $14/agent/month.
6. **HubSpot Service Hub** — Tightly integrated with HubSpot CRM. Free tier available; Professional at $100/seat/month.

## Why teams switch from Zendesk

Three reasons show up in almost every migration conversation.

- **Per-agent pricing adds up fast.** Zendesk Suite Team is $55/agent/month, Suite Professional is $115/agent/month, billed annually. Every support hire is a budget conversation. Alternatives like Freshdesk and Zoho Desk do the same core job for 20-30% of the cost. For a detailed breakdown, see [Zendesk Pricing in 2026](/blog/zendesk-pricing).
- **Configuration is heavy.** Zendesk covers a lot, but it assumes you have time to configure triggers, automations, macros, views, and routing rules. Teams that want to be live in a week rather than a quarter often find the setup cost (in time, not money) too high.
- **Add-ons multiply the bill.** AI agents, workforce management, quality assurance, and advanced analytics are separately priced add-ons on top of the Suite plan. What starts as $55/agent/month can easily become $150/agent/month once you layer on what Zendesk's marketing implies is included.

There are secondary reasons too: some teams want a more conversational interface for live chat (Intercom's specialty), some want the inbox to feel like email (Front, Help Scout), some want to keep everything inside their existing CRM (HubSpot Service Hub). The options below each take a different slice of the problem.

## 1. Freshdesk

Freshdesk is the most straightforward Freshworks-to-Zendesk swap. The feature set is close to parity — omnichannel ticketing, automation, SLAs, a knowledge base, reporting, and AI via Freddy — but at about a third of the price. It is the first tool most teams evaluate when they decide to leave Zendesk.

The free tier is a starter offer rather than a permanent plan: 1-2 agents for the first 6 months, with email and social ticketing, a knowledge base, and basic ticket dispatch. It is a low-friction way to evaluate Freshdesk. When you outgrow it, Growth is $19/agent/month (annual), Pro is $55/agent/month, and Enterprise is $89/agent/month.

The main tradeoff is that Zendesk still has deeper capabilities in a few areas. Its reporting is more flexible, its marketplace of third-party apps is larger, and its custom object model supports more complex data structures. Freshdesk covers the 90% of use cases most teams actually need.

**Key features:**
- Omnichannel ticketing (email, social, chat, phone)
- Knowledge base with unlimited articles
- Freddy AI for ticket triage, response suggestions, and summaries (higher tiers)
- Automation, SLAs, custom ticket forms
- Marketplace with 1,000+ integrations

**Pricing:** Free (1-2 agents, 6 months). Growth $19/agent/mo (annual). Pro $55/agent/mo. Enterprise $89/agent/mo.

**Pros:**
- Low-friction free starter tier for evaluation
- Direct feature-for-feature Zendesk alternative
- Easier to configure than Zendesk for small teams
- Predictable per-agent pricing

**Cons:**
- Reporting and customization depth still behind Zendesk
- AI features gated to higher tiers
- Some teams find the UI dated compared to newer tools

**Best for:** Small and mid-size teams that want a Zendesk-like feature set at a much lower price, or teams starting from scratch who want to stay free as long as possible.

See the full [Freshdesk pricing breakdown](/blog/freshdesk-pricing) for plan details.

## 2. Help Scout

Help Scout takes a different philosophy from Zendesk. Instead of building a ticket-centric interface with SLAs, priorities, and queues, it builds around the shared email inbox. Conversations feel like normal email — to customers and to agents — which makes it easier for customers to engage and faster for agents to onboard.

For smaller support teams, especially SaaS companies where most tickets come through email, Help Scout is a common landing spot. The Standard plan at $25/user/month includes unlimited mailboxes, saved replies, workflows, and a knowledge base. Plus is $45/user/month and adds advanced permissions, custom fields, and API access. Pro is $75/user/month with dedicated hosting, HIPAA compliance, and advanced security.

AI Answers, Help Scout's chatbot-style automation, is priced separately at $0.75 per resolution — cheaper than Intercom's Fin ($0.99) but more expensive than Featurebase's Fibi ($0.49). New accounts get three months of unlimited AI Answers to test it out.

**Key features:**
- Shared inbox with email-style conversations
- Knowledge base (Docs) and help widget
- Beacon live chat and self-service widget
- Saved replies, workflows, and collision detection
- AI Answers chatbot ($0.75/resolution)

**Pricing:** Free plan available. Standard $25/user/mo. Plus $45/user/mo. Pro $75/user/mo.

**Pros:**
- Clean, simple interface with a low learning curve
- Email-first feel that customers find familiar
- Strong knowledge base and help widget
- Good fit for SaaS and service businesses

**Cons:**
- Less capable for high-volume ticket operations
- AI is a separate add-on
- Fewer channels than Zendesk or Freshdesk (lighter on phone, social)

**Best for:** Small and mid-size teams that want a friendly, conversational support experience and primarily handle email.

## 3. Intercom

Intercom is the closest thing to Zendesk in terms of breadth, but with a different center of gravity. Where Zendesk built out from email ticketing, Intercom built out from in-app messaging. The result is a product that handles support as an ongoing conversation rather than a series of discrete tickets, and that excels when most of your support happens inside your product.

Intercom's Fin AI agent is the most mature AI support tool on this list. It handles first-touch resolution on a meaningful percentage of support volume, pulling answers from your help center, past conversations, and any connected knowledge sources. The trade-off is pricing: Fin charges $0.99 per resolution on top of your base plan. For high-volume teams that can get real deflection rates, the math works. For lower-volume teams, it can look expensive compared to flat-rate alternatives.

Base pricing is $29/seat/month (Essential), $85/seat/month (Advanced), and $132/seat/month (Expert). SSO/SAML is gated to Expert, which is a dealbreaker for security-conscious teams on a budget. See the full [Intercom pricing breakdown](/blog/intercom-pricing) for the details.

**Key features:**
- Live chat via Intercom Messenger
- Shared inbox with AI-powered workflows
- Fin AI agent for automated resolutions ($0.99 each)
- Help center and self-service
- Custom bots and automation

**Pricing:** Essential $29/seat/mo. Advanced $85/seat/mo. Expert $132/seat/mo. Fin AI $0.99/resolution.

**Pros:**
- Live chat and in-app messaging that customers rate highly
- Most mature AI support agent (Fin)
- Strong workflow builder on Advanced tier
- Rich customer profile and behavioral data

**Cons:**
- SSO locked to the $132/seat/mo Expert tier
- Fin AI costs are usage-based and can scale unpredictably
- More expensive than most alternatives at comparable tiers

**Best for:** SaaS and B2C companies where most customer interaction happens inside the product, and teams that can justify Fin AI's per-resolution pricing.

## 4. Front

Front is built for teams that want the shared inbox to look and feel exactly like email. Unlike Zendesk (ticket-centric) or Intercom (chat-centric), Front presents every incoming message — email, SMS, social DMs, chat — as an email-style conversation that multiple team members can assign, comment on, and reply to collaboratively.

This model fits teams whose support and sales conversations overlap, or whose agents already live in email and do not want to learn a ticketing system. Operations, logistics, and professional services teams also land on Front because it handles mixed internal/external communication better than a pure help desk.

Pricing is per-seat: Starter at $25/seat/month (capped at 10 seats), Growth in the $59 range, Professional at $65/seat/month, and Enterprise at $105/seat/month. AI features are largely gated as paid add-ons even on Professional, which can push the real cost closer to $115/seat/month once you turn them on.

**Key features:**
- Unified inbox for email, SMS, chat, and social
- Collaborative email with internal comments and assignments
- Workflow automation and shared drafts
- Analytics and team reporting
- CRM and productivity tool integrations

**Pricing:** Starter $25/seat/mo (up to 10 seats). Professional $65/seat/mo. Enterprise $105/seat/mo.

**Pros:**
- Email-first experience with strong collaboration features
- Handles mixed internal/external communication naturally
- Clean interface with low learning curve
- Strong fit for operations and professional services teams

**Cons:**
- AI features often require paid add-ons on top of base plan
- Starter plan caps at 10 seats
- Not built for high-volume ticketing the way Zendesk is

**Best for:** Teams that already live in email and want collaborative workflows without forcing everyone into a ticketing paradigm.

## 5. Zoho Desk

Zoho Desk is the cheapest credible Zendesk alternative on this list. The Free plan supports up to three agents with basic ticketing. Standard is around $14-20/agent/month, Professional is in the $23 range, and Enterprise tops out around $40/agent/month. For a five-agent team, that is a difference of several hundred dollars a month compared to Zendesk Suite.

The catch is the Zoho ecosystem commitment. Zoho Desk works best when you are already using Zoho CRM, Zoho Books, or other Zoho products — it integrates deeply inside that ecosystem. Outside the Zoho stack, the value is lower. Phone support also requires a separate Zoho Voice subscription (starting around $34/user/month), which can double the real per-agent cost once you add it.

**Key features:**
- Multi-channel ticketing (email, chat, social)
- Zia AI assistant for ticket routing and suggestions
- Automation, SLAs, and workflows on higher tiers
- Tight integration with Zoho CRM and Zoho ecosystem
- Free plan for up to 3 agents

**Pricing:** Free (3 agents). Standard $14-20/agent/mo. Professional $23/agent/mo. Enterprise $40/agent/mo.

**Pros:**
- Most affordable paid plans in the category
- Useful free tier for very small teams
- Deep integration with Zoho CRM and ecosystem
- Surprisingly full feature set at lower tiers

**Cons:**
- Best value requires Zoho ecosystem commitment
- Phone support is a separately-priced Zoho Voice add-on
- UI and UX feel dated compared to newer tools
- Global support coverage varies by region

**Best for:** Budget-conscious teams or anyone already using Zoho CRM or Zoho One.

## 6. HubSpot Service Hub

HubSpot Service Hub is the right answer if you already live inside HubSpot for marketing and sales. The service module sits on the same CRM backbone, which means every support ticket is automatically tied to the same contact record your sales team sees. No separate integration, no data sync, no duplicate customer profiles.

The Free tier gives you ticketing, live chat, and a shared inbox up to a point. Starter adds more capacity and some automation. Professional jumps sharply to $100/seat/month and unlocks knowledge base, customer portal, SLA management, and automation. Enterprise is $150/seat/month with advanced permissions, playbooks, and custom objects.

The jump from Starter to Professional is the main friction point. Teams that outgrow the Free or Starter tiers but do not need the full Professional feature set end up paying for a lot more than they use. If you do not already have a HubSpot commitment for marketing or sales, most teams get better value from Freshdesk or Zoho Desk at similar capability.

**Key features:**
- Ticketing, live chat, and shared inbox
- Tight integration with HubSpot CRM
- Customer portal, knowledge base (Professional+)
- SLA management and automation (Professional+)
- Reporting and dashboards

**Pricing:** Free plan available. Starter $20/seat/mo. Professional $100/seat/mo. Enterprise $150/seat/mo.

**Pros:**
- Unified customer record with sales and marketing
- Useful free tier for small teams already on HubSpot
- Good fit if you already pay for HubSpot Marketing or Sales Hub
- Clean, modern UI

**Cons:**
- Big price jump from Starter to Professional
- Poor value as a standalone support tool
- Core features (knowledge base, automation) gated to $100/seat/mo
- Less support-specific depth than Zendesk, Freshdesk, or Intercom

**Best for:** Teams already committed to HubSpot for marketing and sales that want support in the same CRM.

## Comparison table

Here is how all six stack up against Zendesk Suite on the features most teams care about.

| | Zendesk | Freshdesk | Help Scout | Intercom | Front | Zoho Desk | HubSpot |
|---|---|---|---|---|---|---|---|
| **Starting price** | $55/agent/mo | Free (1-2 agents, 6 mo) | Free | $29/seat/mo | $25/seat/mo | Free (3 agents) | Free |
| **Entry paid tier** | $55/agent/mo | $19/agent/mo | $25/user/mo | $29/seat/mo | $25/seat/mo | $14-20/agent/mo | $20/seat/mo |
| **Professional tier** | $115/agent/mo | $55/agent/mo | $45/user/mo | $85/seat/mo | $65/seat/mo | $23/agent/mo | $100/seat/mo |
| **Free plan** | No | Yes | Yes | No | No | Yes | Yes |
| **Omnichannel** | Yes | Yes | Email-first | Chat-first | Email-first | Yes | Yes |
| **Live chat** | Yes | Yes | Beacon | Yes (in-app) | Yes | Yes | Yes |
| **AI agent** | Yes (add-on) | Freddy (tiers) | $0.75/resolution | Fin ($0.99) | Add-on | Zia (included) | Breeze |
| **Knowledge base** | Yes | Yes | Yes | Yes | Limited | Yes | Yes (Pro+) |
| **CRM integration** | Many | Many | Many | Native | Many | Zoho native | HubSpot native |

## If what you actually need is feedback tooling, not a ticket system

One category of team leaves Zendesk for a reason none of the other comparison articles cover: they do not need a better help desk. They need a different kind of tool entirely.

Here is how this plays out in practice. Your support agents field hundreds of tickets that contain buried feature requests. "Can you add X?" inside a bug report. "We keep asking for Y" in a renewal conversation. Zendesk is good at resolving each of those tickets. It is not good at telling you which feature request has the most votes, which bug is blocking the most customers, or what you should ship next quarter to reduce support load.

Tags and custom fields inside Zendesk do not solve this. They tell you a topic came up. They do not give you a ranked list of what customers most want, tied to the customers who asked for it, with a public roadmap and automatic notifications when features ship.

If that is the real gap driving you off Zendesk, the answer is not another help desk. The answer is a dedicated feedback tool paired with your existing support setup. [Quackback](https://quackback.io) is built for exactly this pattern. It is open source (AGPL-3.0), self-hosted, and free, and it integrates directly with Zendesk. Your support agents keep using Zendesk for tickets. Feature requests captured in those tickets flow into Quackback automatically, where they become structured posts with votes, status, and a public roadmap. When you ship a feature, every customer who voted or requested it gets notified through your changelog.

The AI features matter here. Duplicate detection catches the situation where two customers file the same request through different Zendesk tickets — exactly the problem tags cannot solve. Merge suggestions identify related requests. Sentiment and theme summarization surface the patterns buried in hundreds of posts.

The [MCP server](/features/mcp) is something no help desk or feedback tool on the market offers. It exposes your feedback data to AI agents through the Model Context Protocol, so an agent can search posts, triage requests, write responses, create changelog entries, and merge duplicates with full attribution and audit logs.

---

> **Try Quackback** — open source and self-hosted. Pairs with Zendesk for feedback tracking. Deploy in under five minutes with Docker.
> [Get started free](/docs) | [View on GitHub](https://github.com/quackbackio/quackback) | [Zendesk integration](/integrations/zendesk)

---

Other dedicated feedback tools in the same category include [Canny](/compare/quackback-vs-canny), [Productboard](/compare/quackback-vs-productboard), [UserVoice](/compare/quackback-vs-uservoice), and [Featurebase](/compare/quackback-vs-featurebase). For a full comparison of the category, see [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026).

## How to choose

Start by figuring out what is actually driving the migration. The right answer depends heavily on why Zendesk is not working.

**If the problem is price:** Freshdesk and Zoho Desk are the most direct cost-saving swaps. Freshdesk has the better free tier and a more mainstream feature set. Zoho Desk is cheaper at the paid tiers but assumes some Zoho ecosystem commitment.

**If the problem is complexity:** Help Scout is the easiest tool on this list to onboard. Email-first, small learning curve, minimal configuration. Front is similar for teams that want collaboration on top of email.

**If the problem is in-product chat and AI:** Intercom has the most mature AI agent (Fin) and the best in-product messaging. Budget for the per-resolution pricing.

**If you already use HubSpot for sales and marketing:** HubSpot Service Hub is the obvious answer because of the unified customer record. If you do not have a HubSpot commitment already, the standalone value is weaker than Freshdesk.

**If you are on Zoho CRM or Zoho One:** Zoho Desk is the natural fit. The free tier works for very small teams and the paid tiers are the cheapest in the category.

**If the real gap is customer feedback, not ticketing:** Keep Zendesk (or swap to Freshdesk for cost) and add a dedicated feedback tool. [Quackback](https://quackback.io) integrates directly with Zendesk and is free to self-host. See [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026) for the full category.

For more on Zendesk's own pricing and where it makes sense to stay put, see [Zendesk Pricing in 2026](/blog/zendesk-pricing).

## Frequently asked questions

### Is there a free alternative to Zendesk?

Yes, though most are limited. Zoho Desk has the most useful free help desk plan — up to 3 agents with no time limit. Freshdesk's Free Program covers 1-2 agents for the first 6 months. Help Scout and HubSpot Service Hub both have free tiers with tighter limits. For teams that also need feedback tracking beyond ticketing, [Quackback](https://quackback.io) is free to self-host.

### Which Zendesk alternative is cheapest?

Zoho Desk is the cheapest paid option, starting around $14-20/agent/month for the Standard plan. Freshdesk Growth is $19/agent/month. For truly zero-cost support on a very small team, Zoho Desk's free plan (3 agents, no time limit) is hard to beat, and Freshdesk's Free Program covers 1-2 agents for 6 months.

### Which Zendesk alternative has the best AI?

Intercom's Fin is the most mature AI support agent and has the best track record on deflection rates. The trade-off is per-resolution pricing ($0.99 each), which is more expensive than Help Scout's AI Answers ($0.75) or Featurebase's Fibi ($0.49). Freshdesk's Freddy AI is included in higher tiers. Zoho Desk's Zia is included across plans but less sophisticated than Fin.

### Can I use Zendesk alongside a feedback tool?

Yes. Most teams that leave Zendesk for feedback tracking specifically end up keeping Zendesk (or switching to Freshdesk) for support tickets and pairing it with a dedicated feedback tool. [Quackback](https://quackback.io), Canny, Productboard, UserVoice, and Featurebase all integrate with Zendesk. Support agents work tickets in Zendesk, feature requests flow into the feedback tool, and voters get notified when features ship.

### Is Zendesk worth the premium price?

For large enterprises with complex workflows, custom objects, and mature support operations, Zendesk often still makes sense — the depth, marketplace, and reliability are hard to replicate. For small and mid-size teams running standard ticketing workflows, alternatives like Freshdesk deliver 90% of what you need at 25-30% of the cost. The decision usually comes down to whether you need the top 10% of Zendesk's capabilities enough to justify the price gap. See [Zendesk Pricing in 2026](/blog/zendesk-pricing) for a detailed cost analysis.

- [Feature Request Tracking: The Complete Guide for Product Teams](https://quackback.io/blog/feature-request-tracking): A practical guide to feature request tracking. Components, frameworks, workflows, and how to turn scattered requests into a prioritized roadmap.

Published: 2026-04-08

Most teams treat feature requests as an inbox problem. A Slack channel fills up, a support queue overflows, a spreadsheet grows another tab. The team assumes that if they can just file it all in one place, they will have solved it. They have not. Feature request tracking is a prioritization problem, not a storage problem, and the tool you choose shapes what you can actually see.

![Feature request tracking flow from capture to close the loop](/blog/feature-request-tracking/hero.webp)

The teams that do this well can answer three questions at any moment: what is the total demand for this change, which customer segments want it, and what did we tell the people who asked. This guide covers what feature request tracking is, the components that make it work, the frameworks teams use to prioritize, and the workflows that keep requests moving from capture to closed loop.

## What is feature request tracking

**Feature request tracking** is the structured process of collecting, organizing, prioritizing, and responding to user suggestions about what your product should do next. It turns a pile of unstructured ideas from customers, support agents, salespeople, and internal stakeholders into a ranked, searchable, accountable list that feeds your roadmap.

It is not the same thing as support ticketing, bug tracking, or general feedback collection, even though the tools overlap. The distinction matters because each flow has a different goal, a different success metric, and a different owner.

| | Feature request tracking | Bug tracking | Support ticketing | General feedback |
|---|---|---|---|---|
| **Primary goal** | Inform the roadmap | Fix broken behavior | Unblock a user now | Understand sentiment |
| **Success metric** | Demand aligned to priorities | Time to fix, regression rate | Time to resolution, CSAT | Theme coverage, response rate |
| **Owner** | Product | Engineering | Support | Product + UX |
| **Lifecycle** | Open, planned, shipped, declined | Open, fixed, verified, closed | Open, pending, resolved | Collected, analyzed, reported |
| **Typical tool** | Feedback board, voting system | Jira, Linear, GitHub Issues | Zendesk, Intercom | Survey tool, research repo |
| **Who sees it** | Customers and team, often public | Internal only | Reporter and agent | Researchers and PMs |

A single complaint can touch more than one of these flows. A customer who writes "the CSV export is broken and I wish it included custom fields" has submitted a bug and a feature request in the same sentence. A mature tracking system separates the two without forcing the customer to file twice.

Feature request tracking also differs from the broader practice of [collecting customer feedback](/blog/collect-customer-feedback). Feedback collection is the upstream activity: surveys, support tickets, sales calls. Feature request tracking is what happens once a specific "we should build this" signal emerges from that noise. The collection layer is about hearing. The tracking layer is about deciding.

Here is a concrete example. A product team at a 40-person SaaS company receives 60 pieces of customer input in a typical week: 15 bug reports, 20 how-to questions, 10 general sentiment, and 15 feature suggestions. Without feature request tracking, all 60 end up in the same Slack channel and the 15 suggestions that should inform the roadmap get buried. With feature request tracking, those 15 land on a [feedback board](/features/feedback), get deduplicated, get voted on, and become the raw material for the next planning cycle.

## The components of feature request tracking

A working system has six components. You can bolt them together from several tools or get them in one. What matters is that all six are present — missing any one of them creates a failure mode.

### Intake and capture

Requests need to arrive from every channel where customers talk: a public board, an in-app widget, email, support tickets, sales notes, and direct messages from the CEO. The tracking system must accept all of them without forcing anyone to learn a new workflow.

The most common mistake is requiring customers to file requests in a specific format. They will not. A support agent who sees a feature request in a chat will create the board post themselves if the friction is low enough. For a deeper look at the capture layer, see [collect customer feedback](/blog/collect-customer-feedback) and the [feature request template](/blog/feature-request-template).

### Voting and demand signal

Voting turns qualitative requests into quantitative demand data. One user asking for X is an anecdote. Two hundred users voting on the same post is a signal you can rank. Without [voting](/features/voting), the loudest stakeholder wins every prioritization argument.

Voting works best when it is public and frictionless. A user who has to create an account, confirm an email, and click through three screens to upvote a post will not upvote the post. For a comparison of voting systems across tools, see [best feature voting tools](/blog/best-feature-voting-tools).

### Triage and deduplication

Raw incoming requests are messy. Users describe the same underlying need in five different ways. "CSV export bug," "I can't download my data," and "export is broken" may all point to the same root request. Triage groups these into one canonical post so the vote count aggregates correctly.

Good triage happens daily and takes minutes, not hours. The team merges duplicates, tags by product area, and decides whether each post is a feature request, a bug, or a support question to route elsewhere. AI-assisted triage can cluster similar posts automatically, which is valuable once volume exceeds what one person can manage by hand. See [AI customer feedback analysis](/blog/ai-customer-feedback-analysis).

### Roadmap and status

A request that sits on a board forever is indistinguishable from a request nobody is looking at. Users need to see their input moving through a pipeline: submitted, under review, planned, in progress, shipped, or declined. A [public roadmap](/features/roadmap) is the visible output of this status system — what is happening now, what is coming next, and what is being considered for later. For more, see [what is a product roadmap](/blog/what-is-a-product-roadmap) and [product roadmap examples](/blog/product-roadmap-examples).

### Changelog and close the loop

When a feature ships, the users who asked for it need to be told. A [changelog](/features/changelog) is the mechanism for closing the loop at scale. It lists what shipped, links to the originating requests, and can notify subscribers automatically. A user who votes on ten requests, sees three of them ship with attribution, and hears nothing about the rest will keep voting. A user who votes and never hears anything will stop. For a detailed walkthrough, see the [customer feedback loop guide](/blog/customer-feedback-loop).

### AI triage and MCP access

Once your volume passes a few dozen requests per week, manual triage breaks down. AI triage reads incoming posts, suggests tags, flags likely duplicates, and summarizes long threads. It does not replace human judgment, but it removes the busywork that made teams give up on board hygiene in the first place.

The more interesting layer is AI access to the board via an [MCP server](/features/mcp). A product manager can ask an AI assistant "what are the top five requests from enterprise customers this quarter" and get an answer in seconds. See [MCP server for feedback management](/blog/mcp-server-feedback-management) and [what is an MCP server](/blog/what-is-an-mcp-server).

## How Quackback features shape feature request tracking

Quackback is built around these six components. Here are three concrete examples of how the feature set translates into daily workflow.

**Example 1: A support agent converts a ticket into a tracked request.** A customer emails support asking for CSV exports with voter company names. The support agent reads the message and creates a board post directly from the ticketing integration. The customer is automatically notified that their idea is now a trackable post. Other customers with the same need vote on it rather than filing their own ticket. Within two weeks, the post has 35 votes and the product team has a clear signal. The request went from email to tracked demand in under a minute.

**Example 2: A product manager prioritizes the quarter using voting data.** At planning time, the PM opens the [feedback board](/features/feedback) and sorts by vote count filtered to the last 90 days. The top five requests cluster around a single theme: better filtering on the roadmap view. The PM makes "roadmap filtering" a theme for the quarter. Each bet is tied to a specific board post, so when the work ships, the changelog automatically notifies the users who voted. Planning took 30 minutes instead of two days, because the team was reading demand data instead of arguing about which feature mattered more.

**Example 3: A founder uses an AI assistant via MCP to answer a board question.** A customer on a sales call asks, "Are you working on Jira integration improvements?" The founder asks their AI assistant, which has access to the instance through the [MCP server](/features/mcp). The assistant returns: "Three open requests mention Jira integration. The top one has 47 votes and is marked 'planned' on the Q3 roadmap. The other two are duplicates that can be merged." The founder answers the customer in real time instead of promising to check and following up tomorrow.

Feature request tracking is only useful when it changes what your team does on ordinary days. A board that is tied into your support flow, your planning flow, and your AI assistants is a system your team actually uses.

## Feature request tracking step by step

Here is the full pipeline from a single user saying "I wish the product did X" to a shipped feature with attribution. Each step has a time estimate for a mid-sized team handling 20-50 requests per week.

**1. Capture the request (under 1 minute).** When a user submits an idea through any channel — board, widget, email, support ticket, sales call — a post is created on the central board. No formal format is required at this stage. The goal is to get the signal into the system before it gets lost.

**2. Acknowledge receipt (same day).** Within 24 hours, the user receives confirmation that their post exists. This can be automatic or manual. Users who hear nothing after submitting assume their input was ignored and stop contributing.

**3. Triage and deduplicate (15 minutes per day).** A team member reviews new posts once per day. They tag by product area, merge duplicates, and route bugs or support questions to the correct channel. Daily triage is much easier than weekly triage because the volume stays small and patterns are fresh.

**4. Gather demand signal (ongoing, automatic).** Users vote, comment, and subscribe. This phase is passive from the team's perspective. Votes accumulate over days and weeks. Comments surface additional context.

**5. Prioritize for planning (1-2 hours per quarter).** Sort open requests by vote count, filter by segment, and apply a prioritization framework. [RICE](/blog/rice-framework-explained), [MoSCoW](/blog/moscow-prioritization), or [Kano](/blog/kano-model) all work here. Pick the 3-5 requests that will get committed to the next cycle.

**6. Update status and communicate (10 minutes).** Move the chosen requests to "planned" and add them to the public roadmap. Users who voted see their input landed. The act of changing status is itself a message.

**7. Build the feature.** Engineering and design do the work. The request post stays linked to the development workstream so the connection back to originating users is preserved.

**8. Ship and publish to the changelog (30 minutes).** A [changelog](/features/changelog) entry goes up and links back to the original request post. The system automatically notifies the users who voted, commented, or subscribed. For a template, see [release notes template](/blog/release-notes-template).

**9. Close the loop (5 minutes).** Leave a short closing comment on the original post. Anyone who finds it in the future sees a clear history: requested, voted on, built, and the users who asked were notified.

**10. Review and repeat (30 minutes per month).** Review closed posts, declined posts, and the top of the backlog. Is there a theme emerging? Are there important customer segments who are not voting at all? The review cycle is what keeps the system from drifting.

## Feature request tracking vs bug tracking

This is the most common confusion in the early days of setting up a feedback system. Both flows take in reports from users, both need triage, both need status, and both need to close the loop. They are still different systems with different owners.

| | Feature request tracking | Bug tracking |
|---|---|---|
| **What it represents** | A gap in product capability | Broken behavior in existing product |
| **Prioritized by** | Demand signal (votes, revenue) | Severity, frequency, regression risk |
| **Owner** | Product | Engineering |
| **Success means** | More customers get a feature they asked for | The problem stops happening |
| **Lifecycle** | Open, planned, in progress, shipped, declined | Open, fixed, verified, closed |
| **Visibility** | Often public on a board | Usually internal |
| **Ranking criteria** | RICE, vote count, customer revenue | Severity x frequency |
| **Typical tool** | [Feedback board](/features/feedback) | Linear, Jira, GitHub Issues |
| **Resolution time** | Weeks to quarters | Hours to days |

Conflating them destroys the prioritization signal on both sides. If a bug is mixed into your feature request board, its vote count dominates because bugs generate more complaints than feature requests. If a feature request is mixed into your bug tracker, it will never ship because it does not meet the severity bar engineering uses.

The practical answer is two systems and one handoff rule. Feature requests live on a public board. Bugs live in your engineering tracker. When a user submits a report that is actually a bug, the product team moves it out of the feature board. For teams using a [bug report template](/blog/bug-report-template), this handoff is easier because the format is already standardized.

## Common feature request tracking frameworks

Once you have clean demand data, you need a way to rank requests against each other. A framework is not a substitute for judgment — it structures the judgment so the team can debate it openly. Here are the four most useful ones.

**RICE (Reach, Impact, Confidence, Effort).** Each request gets a score: how many users will this reach per quarter, how big is the impact per user, how confident are you in those estimates, and how much effort will it take. The final score is (Reach x Impact x Confidence) / Effort. RICE is the best all-purpose framework because it forces you to estimate reach explicitly. It works best when you have a feedback board with vote counts feeding into the Reach calculation. See [RICE framework explained](/blog/rice-framework-explained).

**MoSCoW (Must, Should, Could, Won't).** Requests get sorted into four buckets. MoSCoW is coarser than RICE but much faster. It works well for quarterly planning when you need to set expectations across the team without spending two days on scoring. See [MoSCoW prioritization](/blog/moscow-prioritization).

**Kano Model.** Features are classified by how they affect user satisfaction: basic (expected, only noticed when missing), performance (more is better), delighters (unexpected wins), indifferent, and reverse. Kano is useful when you need to explain why a high-demand request might not be the right thing to build. See [Kano model](/blog/kano-model).

**ICE (Impact, Confidence, Ease).** A simpler cousin of RICE. Score each on 1-10, multiply, rank. Faster than RICE but less rigorous because it skips the reach dimension. For a broader set of approaches side by side, see the [prioritization matrix template](/blog/prioritization-matrix-template).

The right framework depends on your context. Use RICE when you have real vote counts and time to score carefully. Use MoSCoW when you need quarterly decisions fast. Pick one, run it for a quarter, and switch if it does not fit.

## Why spreadsheets fail at feature request tracking

Every team starts with a spreadsheet. Spreadsheets are free, flexible, and already installed on every laptop. For the first few weeks, they work. After that, they fail in predictable ways.

**Spreadsheets do not deduplicate.** A user cannot see that their request already exists. The same underlying need shows up as six rows with six different phrasings, and the real demand stays hidden.

**Spreadsheets do not vote.** There is no way for users to signal "me too" on an existing request. Prioritization falls back on whoever is loudest in the room.

**Spreadsheets do not close the loop.** When a feature ships, there is no mechanism to notify the users who asked for it. The team has to maintain a separate list, remember to update it, and manually email everyone. In practice, this never happens.

**Spreadsheets do not support status workflows.** You can add a "status" column, but there is no history of when a status changed and no public view. Status becomes a lie — the column says "in progress" for nine months on a project that was abandoned in month two.

**Spreadsheets do not integrate with your other tools.** Support is in Zendesk. Engineers are in Linear. Sales is in Salesforce. The spreadsheet is in Google Drive. The same request gets logged in four places, none reflecting the others.

**Spreadsheets do not scale past one person.** When three people edit the sheet, the taxonomy breaks — one tags "auth," another "login," a third "sign-in," and filtering is useless.

The team that built the spreadsheet usually knows this. They keep using it because migration feels expensive. The ongoing cost is almost always higher than the cost of moving. For the full breakdown, see [feature request tracking spreadsheet](/blog/feature-request-tracking-spreadsheet). This is also why [idea management software](/blog/idea-management-software) exists — to do what spreadsheets structurally cannot.

## Communicating feature requests

A feature request tracking system has two audiences: the people inside your company who need to know what is being asked for, and the customers outside who want to know what is being built.

**Internally**, different teams care about feature requests for different reasons. Engineering wants to plan architecture. Sales wants to answer objections. Executives want revenue impact. Support wants to know what ticket categories will drop.

| Audience | What they care about | Where to frame it | Cadence |
|---|---|---|---|
| **Engineering** | What is coming next, technical implications | Roadmap, planning meetings | Sprint cycle |
| **Sales** | Top requested features, deal-blocking gaps | Weekly digest, battle cards | Weekly |
| **Executives** | Revenue impact, customer trends | Monthly report with top themes | Monthly |
| **Support** | What will reduce ticket volume, how to answer current questions | Shared board view, tag filters | Daily |
| **Customer success** | What is planned for at-risk accounts | Account-specific filters | Per account review |
| **Design** | User problems behind the top requests | Board comments, interview links | Per design sprint |

The best internal communication strategy is to make the board itself the source of truth and give each team a saved filter. Sales gets "top 20 requests by vote, last 90 days." Engineering gets "posts tagged 'planned' this quarter." Nobody waits for a monthly email because the data is always current.

**Externally**, customers want to see two things: what you are working on, and what happened to their specific request. A [public roadmap](/features/roadmap) handles the first — now, next, later — with a small number of items in each. It does not need to be precise. It needs to be honest. Users accept "later" as an answer if they believe the team is thinking about it. They do not accept silence.

A public [changelog](/features/changelog) handles the second. When you ship a feature, the entry links back to the board post, and the users who voted get notified automatically. A user who receives a "we shipped the thing you asked for" notification is the most engaged user in your base. For a broader comparison, see [best public roadmap tools](/blog/best-public-roadmap-tools).

A good tracking tool like [Quackback](/features/feedback) lets you choose per-post whether a request is public or private, so you can keep sensitive requests internal while running a public board for the rest.

## Frequently asked questions

### Do feature requests need to be public?

Not necessarily, but there are strong reasons to make them public when you can. Public requests let customers find existing posts and vote on them instead of filing duplicates, which gives you cleaner demand data. Public status tells users what is happening without requiring your team to send individual updates. The argument against public posts is usually about sensitive competitive information or enterprise-specific requests — those can be kept private while the rest of the board stays public. If you want a fully self-hosted, open-source tool that handles both public and private boards, see [self-hosted feedback tools](/blog/self-hosted-feedback-tools) and [open-source feedback tools](/blog/open-source-feedback-tools).

### How often should you triage feature requests?

Daily if you can manage it, weekly at a minimum. Daily triage keeps the volume small and the patterns fresh, which makes deduplication and tagging dramatically faster. Weekly triage works if your volume is low (under 20 new posts per week). Monthly triage does not work — by the time you review the backlog, you have lost the context for half of it and duplicates have already accumulated. AI-assisted triage makes daily review possible even at higher volumes. See [AI customer feedback analysis](/blog/ai-customer-feedback-analysis) for how this scales.

### What is the best tool for feature request tracking?

The answer depends on your constraints. If you need a hosted SaaS tool with a large user community, Canny and Productboard are the common choices — see [best Canny alternatives](/blog/best-canny-alternatives) and [best Productboard alternatives](/blog/best-productboard-alternatives) for context on why teams switch. If you need an open-source, self-hosted option with no per-user fees, Quackback is built specifically for this workflow — see [Quackback vs Canny](/compare/quackback-vs-canny) and [Quackback vs Productboard](/compare/quackback-vs-productboard) for side-by-side comparisons. The broader landscape is covered in [best feature request tools](/blog/best-feature-request-tools) and [best customer feedback tools 2026](/blog/best-customer-feedback-tools-2026).

### How do you prevent your board from filling with low-value requests?

Three mechanisms work together. First, aggressive triage — merge duplicates daily, mark out-of-scope requests as "not planned" with a short explanation, and keep the open queue clean. Second, public status — a request marked "declined" or "not planned" stays visible so users can see the decision, but it does not clutter the prioritization view. Third, smart defaults — sort by vote count so low-demand posts sink naturally and the team only sees the top of the backlog during planning. A board that looks overwhelming is usually a triage problem, not a volume problem.

### How do you decide between building what users vote for and what you think they need?

Feature request tracking is an input to prioritization, not the prioritization itself. Vote counts tell you what users are asking for based on what they already know. They do not tell you what users need but have not thought to request. The best product decisions combine demand data from the board, qualitative signal from [user interviews](/blog/user-interview-questions) and [continuous discovery](/blog/continuous-discovery-habits), and strategic judgment about where the product should go. A good rule of thumb: use vote counts to rank requests within a theme you have already committed to, and use discovery work to decide which themes to commit to in the first place. For more on this, see [voice of the customer](/blog/voice-of-customer).

### What happens to requests you decline?

They stay on the board with a status of "not planned" and a short explanation of why. A user who sees their request marked "declined: out of scope because we are focusing on X this year" stays engaged, because they learned something about the product's direction. The "declined" status is also useful to you — when the same request comes back a year later, you can see your previous reasoning. Declining is a form of closing the loop, not an alternative to it.

- [How to Connect Your Feedback Tool to Claude and Cursor via MCP](https://quackback.io/blog/connect-feedback-tool-to-ai-via-mcp): Step-by-step guide to connecting Quackback, Canny, or Productboard to AI assistants via MCP. Set up in under two minutes with Claude Code, Cursor, Claude Desktop, or VS Code.

Published: 2026-04-07

Your feedback tool has hundreds of feature requests, bug reports, and user suggestions. Your AI assistant cannot see any of them. It cannot search your boards, check vote counts, or draft a changelog entry based on what you shipped. The data sits in one system. The AI sits in another. MCP fixes that.

![Connecting a feedback tool to an AI assistant via MCP](/blog/connect-feedback-tool-to-ai-via-mcp/hero.webp)

> To connect a feedback tool to an AI assistant via **MCP** (Model Context Protocol), point your AI host at the tool's MCP server endpoint and authenticate with an API key or OAuth. Once connected, your AI can read feedback, update the roadmap, and draft release notes through natural language. Quackback ships a built-in MCP server that connects to Claude Code, Cursor, Claude Desktop, and VS Code in under two minutes.

MCP is an open standard that lets AI assistants connect to external tools. This guide walks through the setup for four AI hosts: Claude Code, Cursor, Claude Desktop, and VS Code. It covers Quackback's built-in MCP server in detail, with notes on connecting Canny and Productboard.

If you are new to MCP, start with [What Is an MCP Server?](/blog/what-is-an-mcp-server) for background on the protocol and why it matters for product teams.

## What you will need

Before starting, make sure you have:

- **A running Quackback instance.** Use [Quackback Cloud](/pricing) for a managed instance, or self-host via [Docker or Railway](/docs). Either way, Quackback's MCP server is built in — it exposes tools and resources (boards, statuses, tags, roadmaps, members) at the `/api/mcp` endpoint using Streamable HTTP transport.
- **An API key.** Generate one from Settings > Developers in your Quackback admin panel. Keys use a `qb_` prefix followed by 48 hex characters. Quackback also supports OAuth as an alternative.
- **An AI host that supports MCP.** This guide covers Claude Code, Cursor, Claude Desktop, and VS Code. Windsurf also works — the configuration is similar.
- **(Optional) A second feedback tool.** Canny and Productboard have third-party community servers. See the [comparison section](#connecting-other-feedback-tools) below.

That is it. No SDKs to install. No custom code to write. Setup takes under two minutes for each host.

## Setting up Quackback MCP in Claude Code

[Claude Code](https://docs.anthropic.com/en/docs/claude-code) is Anthropic's CLI tool for working with AI in the terminal. It supports MCP natively and is the fastest way to connect.

### Step 1: Add the server

You can use the CLI command or a JSON config file. Both achieve the same result.

**Option A: CLI command**

```bash
claude mcp add --transport http --scope user quackback https://your-quackback-instance/api/mcp
```

That registers the Quackback MCP server at user scope over Streamable HTTP. Claude Code handles the OAuth flow automatically — it opens your browser, you log in to your Quackback instance, and the connection is established. The `--scope user` flag makes the server available across all your projects.

**Option B: JSON config**

Create or edit `.mcp.json` in your project root:

```json
{
  "mcpServers": {
    "quackback": {
      "type": "http",
      "url": "https://your-quackback-instance/api/mcp"
    }
  }
}
```

To authenticate with an API key, add headers:

```json
{
  "mcpServers": {
    "quackback": {
      "type": "http",
      "url": "https://your-quackback-instance/api/mcp",
      "headers": {
        "Authorization": "Bearer ${QUACKBACK_API_KEY}"
      }
    }
  }
}
```

Set the `QUACKBACK_API_KEY` environment variable to your API key (generated from Settings > Developers in the Quackback admin panel).

### Step 2: Verify the connection

Start a new Claude Code session and type:

```
What MCP tools are available?
```

You should see a list of Quackback tools — search, triage, vote, comment, roadmap, changelog, and more. If the list appears, the connection is working.

### Step 3: Run your first query

Try something simple:

```
List my feedback boards
```

Claude will call the Quackback MCP server, retrieve your boards, and display them with post counts and descriptions. If you see your boards listed, setup is complete.

See the [MCP documentation](/docs/mcp) for all available options.

## Setting up Quackback MCP in Cursor

[Cursor](https://cursor.com) is an AI code editor that supports MCP through a JSON configuration file. Technical PMs and product engineers often prefer it because it combines coding and AI in one interface.

### Step 1: Create or edit the MCP config

Open (or create) the file `.cursor/mcp.json` in your project root:

```json
{
  "mcpServers": {
    "quackback": {
      "url": "https://your-quackback-instance/api/mcp",
      "headers": {
        "Authorization": "Bearer ${env:QUACKBACK_API_KEY}"
      }
    }
  }
}
```

Replace `your-quackback-instance` with your Quackback instance URL. Set the `QUACKBACK_API_KEY` environment variable to your API key (generated from Settings > Developers in the Quackback admin panel). Note that Cursor uses `${env:VAR_NAME}` syntax for environment variables, not `${VAR_NAME}`.

### Step 2: Restart Cursor

Close and reopen Cursor, or reload the window. Cursor reads MCP configs on startup.

### Step 3: Verify the connection

Open the Cursor AI chat and ask:

```
What feedback tools are connected?
```

Cursor should recognize the Quackback MCP server and list its available tools. You can then start querying your feedback data directly from the editor.

## Setting up Quackback MCP in Claude Desktop

[Claude Desktop](https://claude.ai/download) is Anthropic's desktop application. It supports MCP through a JSON config file and is the most accessible option for non-technical team members.

### Step 1: Open the config file

The config file location depends on your operating system:

- **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json`
- **Windows:** `%APPDATA%\Claude\claude_desktop_config.json`

Create the file if it does not exist.

### Step 2: Add the Quackback server

Claude Desktop does not support HTTP-based MCP servers natively. You need `mcp-remote`, a lightweight bridge that converts the Streamable HTTP connection into the stdio transport that Claude Desktop expects. It requires Node.js installed on your machine.

Add the following to the config file:

```json
{
  "mcpServers": {
    "quackback": {
      "command": "npx",
      "args": [
        "mcp-remote@latest",
        "--http",
        "https://your-quackback-instance/api/mcp",
        "--header",
        "Authorization: Bearer qb_YOUR_API_KEY"
      ]
    }
  }
}
```

Replace `your-quackback-instance` with your Quackback instance URL and `qb_YOUR_API_KEY` with your actual API key from Settings > Developers.

### Step 3: Restart Claude Desktop

Quit and reopen the app. Claude Desktop loads MCP configs on startup.

### Step 4: Verify the connection

In a new conversation, ask:

```
List my feedback boards from Quackback
```

If you see your boards, the connection is live. Claude Desktop will now have access to your feedback data in every conversation.

Your Quackback admin panel at Settings > Developers > MCP Server also shows ready-to-copy configurations for each host. If you get stuck, start there.

## Setting up Quackback MCP in VS Code

VS Code supports MCP servers through a `.vscode/mcp.json` file in your project root. This works with GitHub Copilot and other VS Code extensions that support the MCP protocol.

### Step 1: Create or edit the MCP config

Create the file `.vscode/mcp.json` in your project root:

```json
{
  "servers": {
    "quackback": {
      "type": "http",
      "url": "https://your-quackback-instance/api/mcp",
      "headers": {
        "Authorization": "Bearer ${input:quackback-api-key}"
      }
    }
  }
}
```

VS Code uses `${input:name}` syntax to prompt you for the API key value when the server first connects. Replace `your-quackback-instance` with your Quackback instance URL.

### Step 2: Reload VS Code

Reload the window or restart VS Code. The MCP server will connect on the next session.

### Step 3: Verify the connection

Ask your AI assistant in VS Code:

```
What MCP tools are available from Quackback?
```

If the tools appear, setup is complete. Note that VS Code uses a `servers` key (not `mcpServers`) and supports the `${input:name}` syntax for secure credential prompting.

## 10 things to try once connected

Once your MCP connection is working, here are ten practical prompts to try. These work in Claude Code, Cursor, Claude Desktop, and VS Code — any host connected to the Quackback MCP server.

### 1. Find the most popular requests

```
What are the most voted feature requests?
```

The AI queries your [feedback boards](/features/feedback), sorts by vote count, and returns a ranked list. Useful before sprint planning or quarterly reviews.

### 2. Summarize recent feedback

```
Summarize feedback from the last 7 days
```

Get a quick overview of what users are asking for, reporting, and discussing. The AI groups feedback by theme and highlights trends.

### 3. Search for a specific topic

```
Which feature requests mention "dark mode"?
```

Faster than manual keyword search because the AI can also catch related terms like "night mode," "dark theme," and "light/dark toggle."

### 4. Update your roadmap

```
Move "API v2" to "in progress" on the roadmap
```

The AI calls the [roadmap](/features/roadmap) management tool and updates the item status. Every linked feedback post gets updated automatically.

### 5. Draft a changelog entry

```
Draft a changelog entry for the features we shipped this sprint
```

The AI reads your recently completed roadmap items, pulls context from linked feedback posts, and writes a [changelog](/features/changelog) entry ready for your review.

### 6. Filter by tag

```
What feedback has the "enterprise" tag?
```

If your team tags feedback by customer segment, the AI can filter and summarize by any tag.

### 7. Create a new feature request

```
Create a new feature request for SSO integration with a description explaining why enterprise customers need it
```

The AI creates the post with a title, description, and appropriate board placement. Saves you from switching context to the feedback tool.

### 8. Check vote counts

```
How many votes does the mobile app request have?
```

Quick data lookup without opening the dashboard.

### 9. Review your roadmap

```
List all roadmap items in the "planned" column
```

Get a snapshot of everything queued up. The AI returns items with vote counts, linked feedback, and status.

### 10. Draft a product update

```
Draft a weekly product update from this week's shipped items
```

The AI reviews what moved to "complete" on your roadmap, summarizes the changes, and drafts an update you can share with your team or users.

Each of these replaces a manual workflow that involves opening your feedback tool, navigating to the right view, reading through data, and writing a summary. With MCP, the AI does the navigation and summarization. You focus on decisions. Because the work runs in your own AI host, you use your own model subscription.

For more on what the Quackback MCP server can do, see the [MCP feature page](/features/mcp) and the [full MCP documentation](/docs/mcp).

## Connecting other feedback tools

Quackback ships with a built-in MCP server, but it is not the only feedback tool with MCP support. Here is the current landscape.

### Canny

A third-party MCP server is available at [opensourceops/canny-mcp-server](https://github.com/opensourceops/canny-mcp-server) on GitHub. As of April 2026 it exposes 37 tools covering boards, posts, votes, comments, and tags. Because it is community-maintained (not built by Canny), it may lag behind Canny's official API when new features launch. For a closer look at the two tools, see [Quackback vs Canny](/compare/quackback-vs-canny).

### Productboard

A community-maintained MCP server exists, exposing 49 tools as of April 2026 covering features, notes, components, and releases. Like the Canny server, it is a third-party wrapper around the Productboard API. Check the MCP server directory for the latest version and compatibility notes. See [Quackback vs Productboard](/compare/quackback-vs-productboard) for a feature comparison.

### UserVoice

No MCP server is available as of April 2026. UserVoice has a REST API, so a community server could be built, but none exists today.

### Nolt and Fider

No MCP servers are available for either tool. Both have limited APIs, which makes community server development harder.

### A note on third-party servers

Third-party MCP servers are useful but come with trade-offs. They may not support every API endpoint. They may break when the vendor changes their API. And they depend on community maintainers to stay current. A built-in MCP server (like Quackback's) stays in sync with every product release because the same team maintains both.

If you are evaluating feedback tools and MCP access matters to your workflow, prioritize tools with official, built-in servers. For a broader comparison of feedback tools, see [Best Customer Feedback Tools](/blog/best-customer-feedback-tools-2026).

## Common issues and troubleshooting

### The AI does not see my MCP tools

This usually means the server did not start or the config file has a syntax error. Check:

- **Claude Code:** Run `claude mcp list` to see registered servers. If Quackback is missing, re-run `claude mcp add --transport http --scope user quackback https://your-quackback-instance/api/mcp` or check your `.mcp.json` file.
- **Cursor:** Confirm `.cursor/mcp.json` is valid JSON. A missing comma or bracket will silently fail. Restart Cursor after editing.
- **Claude Desktop:** Confirm the config file is in the correct location for your OS. Restart the app after any change.

### Authentication errors

If the AI connects but returns permission errors:

- Verify your API key is correct and has not expired. Generate a new one from Settings > Developers if needed.
- Check that the `QUACKBACK_API_KEY` environment variable is set in your shell (for Claude Code) or system environment (for Cursor and Claude Desktop).
- If using OAuth with Claude Code, make sure your browser completed the login flow.

### Slow responses or timeouts

MCP calls go through your Quackback instance. If responses are slow:

- Check your instance health. Self-hosted deployments on underpowered servers may struggle under load.
- Reduce the scope of your query. "Summarize all feedback from the last year" is slower than "Summarize feedback from the last 7 days."
- If you are on a slow network, consider whether the AI host is connecting to a remote instance or a local one.

### Tools appear but do not work

If the tool list loads but individual calls fail, the issue is usually permissions. Your API key may have read-only access when the operation requires write access. Check your key permissions in the Quackback admin panel under Settings > Developers.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How long does it take to set up an MCP server for a feedback tool?

Most setups take under two minutes. Quackback's MCP server requires a CLI command or a few lines of JSON config in Claude Code, Cursor, Claude Desktop, or VS Code. No custom code or API wrappers needed.

### Can I connect multiple MCP servers to the same AI assistant?

Yes. Claude Code, Cursor, and Claude Desktop all support multiple MCP servers simultaneously. You can connect your feedback tool, project tracker, and analytics platform in the same session and query across all of them.

### Do I need to write code to use MCP with my feedback tool?

No. MCP servers install through configuration files or CLI commands. You interact with your [feedback data](/features/feedback) through natural language in your AI assistant. The MCP server handles the API calls in the background.

### Is the Quackback MCP server free?

Yes. The MCP server ships with every Quackback instance, including the free self-hosted version. There are no add-on fees for MCP access. Quackback is open source (AGPL-3.0) and [free to deploy](/docs).

### What if my feedback tool does not have an MCP server?

Some tools like UserVoice, Nolt, and Fider do not have MCP servers yet. Your options are to build a custom MCP server using the [open protocol specification](https://modelcontextprotocol.io), request one from the vendor, or switch to a tool that supports MCP natively. For a comparison of tools with MCP support, see the [connecting other feedback tools](#connecting-other-feedback-tools) section above.

- [Enterprise Feedback Management: What Large Teams Need](https://quackback.io/blog/enterprise-feedback-management): Enterprise feedback management requires SSO, audit trails, multi-product support, and data residency. Here is what to look for and how the landscape compares.

Published: 2026-04-03

At 50 users, a feedback tool is a product decision. At 5,000 users, it is an infrastructure decision.

![Enterprise feedback flowing from multiple teams to a central hub](/blog/enterprise-feedback-management/hero.webp)

> **Enterprise feedback management** is the practice of collecting, routing, and prioritizing feedback across multiple products, distributed teams, and thousands of users under compliance and security constraints. Large teams need SSO/SAML, audit trails, role-based access control, multi-product architecture, data residency control, and AI-assisted triage. The leading tools are UserVoice, Productboard, Aha! Ideas, and Pendo, with open-source options like Quackback for teams that require self-hosting.

Enterprise feedback management is not just "feedback management but bigger." The requirements change fundamentally when your organization has multiple products, distributed teams, compliance obligations, and thousands of users generating feedback across dozens of channels. A tool that works for a 10-person startup will not work for a 500-person enterprise — not because of volume alone, but because of the organizational complexity around that volume.

This guide covers what enterprises actually need from a feedback tool, where the current landscape falls short, and how to evaluate options.

## How enterprise feedback differs

### Multiple products and business units

A startup has one product with one feedback board. An enterprise has five products across three business units, each with its own PM team, its own user base, and its own priorities. Feedback needs to flow to the right team without manual routing.

This requires multi-workspace or multi-board architecture with per-product permissions. A request about Product A should not clutter the backlog of the team building Product B. But cross-product insights — users asking for integrations between Product A and Product B — need to surface to both teams.

### Distributed decision-making

In a startup, one PM reads all the feedback and makes prioritization decisions. In an enterprise, dozens of PMs across multiple teams need access to feedback relevant to their domain, with the ability to triage, categorize, and escalate without stepping on each other.

This means role-based access control with granular permissions. A PM should see their product's feedback. A VP of Product should see all feedback with the ability to filter by product, team, or customer segment. A support agent should be able to submit feedback on behalf of a customer but not change statuses or priorities.

### Compliance and security requirements

Enterprise procurement involves security reviews, compliance questionnaires, and vendor assessments. Your feedback tool will be evaluated on:

**SSO and SAML.** Non-negotiable for most enterprises. Users authenticate through the company's identity provider (Okta, Azure AD, Google Workspace). No separate credentials for the feedback tool.

**Audit trails.** Who changed what, when, and why. Every status change, comment edit, and vote should be logged with a timestamp and user identity. Regulated industries (healthcare, finance) require this for compliance.

**Data residency.** Where does the data live? For enterprises subject to GDPR, CCPA, or industry-specific regulations, the answer matters. Some tools store data only in the US. Others offer EU hosting. Self-hosted tools let you control data residency entirely.

**SOC 2 compliance.** Many enterprise procurement teams require vendors to hold SOC 2 Type II certification. This demonstrates that the vendor follows established security practices for data handling, access control, and incident response.

**Data encryption.** Encryption at rest and in transit. Some enterprises require customer-managed encryption keys for particularly sensitive data.

### Volume and scale

An enterprise with 10,000 active users might receive 500 to 2,000 feature requests per month across all products. The feedback tool needs to handle this volume without performance degradation, and the team needs workflows that prevent this volume from becoming overwhelming.

At enterprise scale, manual triage breaks down. [Zonka Feedback's AI in Feedback Analytics report](https://www.zonkafeedback.com/blog/93-of-cx-leaders-struggle-with-fragmented-feedback-why-centralized-intelligence-is-no-longer-optional) found that 93% of CX leaders struggle with fragmented feedback scattered across multiple systems, and 87% still rely on manual verbatim analysis — combing through spreadsheets while critical issues slip through. AI-powered categorization, duplicate detection, and sentiment analysis become practical necessities rather than nice-to-have features. A PM cannot manually review 500 requests per month and still have time to build product.

## What to look for in an enterprise feedback tool

### Must-have capabilities

**SSO/SAML integration.** Employees sign in with their corporate credentials. This is the first thing enterprise security teams check, and the first reason they reject a tool.

**Role-based access control.** At minimum: admin, PM, contributor, viewer roles with per-product scoping. Better: custom roles with granular permissions for specific actions (triage, comment, change status, export data, manage users).

**Multi-product support.** Separate boards or workspaces per product with cross-product visibility at the leadership level. Each product team operates independently, but executives see the full picture.

**API access.** Enterprises integrate feedback data into their existing toolchain — BI dashboards, data warehouses, CRM systems. A comprehensive API is essential for these workflows.

**Bulk operations.** Merge 50 duplicate requests. Re-categorize 200 posts after a product reorganization. Change the status of everything in a deprecated category. At enterprise scale, one-at-a-time operations are not viable.

### Differentiating capabilities

**AI-powered triage.** Automatic categorization, sentiment analysis, and duplicate detection. Reduces the manual effort of processing high-volume feedback from hours to minutes. See our guide on [AI customer feedback analysis](/blog/ai-customer-feedback-analysis) for how this works in practice.

**Customer segmentation.** Weighting feedback by customer value, plan tier, ARR, or usage level. A request from a $500K/year customer should be surfaced differently than a request from a free trial user. This requires integration with your CRM or billing system.

**Advanced analytics.** Trend analysis over time, feedback volume by product area, sentiment shifts, and executive dashboards. Leadership needs aggregate views, not individual tickets.

**Workflow automation.** Auto-assign feedback based on product area. Auto-notify stakeholders when a high-priority request arrives. Auto-escalate requests that receive a spike in votes. At enterprise scale, manual routing is the bottleneck.

**Self-hosting option.** Some enterprises require feedback data to stay on their own infrastructure for regulatory or security reasons. A self-hosted option eliminates data residency concerns entirely and gives the security team full control over the deployment.

## The enterprise feedback tool landscape

### UserVoice

The longest-standing enterprise feedback tool. UserVoice has served enterprise customers since 2008 and built deep features around enterprise workflows: NPS integration, revenue-linked prioritization, and contributor licensing (only PMs need paid seats, not end users).

**Strengths:** Mature enterprise features, revenue-weighted prioritization, established track record with large organizations.

**Limitations:** Expensive. Pricing starts around $799/month for the Premium plan, and enterprise pricing requires a sales conversation. The UI feels dated compared to newer tools. No self-hosting option.

**Best for:** Large organizations that need revenue-linked prioritization and are comfortable with premium pricing.

For lower-cost options, see [the best UserVoice alternatives](/blog/best-uservoice-alternatives) or our [Quackback vs UserVoice comparison](/compare/quackback-vs-uservoice).

### Productboard

Productboard positions itself as a product management platform rather than a feedback tool. It spans the full workflow from feedback collection to strategy alignment to roadmapping.

**Strengths:** Strategy alignment features (objectives, key results, product hierarchy), Salesforce and CRM integrations, portal for customer-facing feedback.

**Limitations:** Pricing scales per "maker" (PM seats), starting at $20/maker/month for Essentials. Enterprise features like SSO and advanced permissions require the Enterprise plan (custom pricing). The breadth of features creates complexity — teams often use only a fraction of the platform.

**Best for:** Enterprise product organizations that want feedback, roadmapping, and strategy alignment in one platform.

For a full pricing breakdown, see our [Productboard pricing guide](/blog/productboard-pricing) or the [Quackback vs Productboard comparison](/compare/quackback-vs-productboard).

### Aha! Ideas

Aha! Ideas is the feedback component of the Aha! product management suite. It integrates tightly with Aha! Roadmaps and Aha! Develop for a complete product lifecycle tool.

**Strengths:** Deep roadmapping integration, customizable scoring frameworks (RICE, WSJF, custom), proxy voting for sales and CS teams, enterprise-grade permissions.

**Limitations:** The Aha! ecosystem is large and complex. Adopting Aha! Ideas typically means adopting the full Aha! suite to get the most value. Pricing starts at $59/user/month.

**Best for:** Teams already using or willing to adopt the full Aha! product suite.

For details on the tiers, see our [Aha! pricing guide](/blog/aha-pricing) or the [Quackback vs Aha! comparison](/compare/quackback-vs-aha).

### Pendo

Pendo combines product analytics with in-app feedback collection. Its strength is connecting user behavior data (feature usage, session recordings, funnel analytics) with qualitative feedback.

**Strengths:** Behavioral analytics integrated with feedback, in-app guides and tooltips, session replay. Strong for understanding not just what users request, but how they actually use the product.

**Limitations:** Pendo is primarily an analytics tool. Its feedback features are less developed than tools built specifically for feedback management. Pricing is usage-based and can be expensive at scale — custom pricing only, typically five figures annually.

**Best for:** Enterprises that want to correlate product usage data with qualitative feedback.

For more on costs, see our [Pendo pricing guide](/blog/pendo-pricing) or the [Quackback vs Pendo comparison](/compare/quackback-vs-pendo).

### Open-source alternatives

For enterprises that require self-hosting, data sovereignty, or want to avoid vendor lock-in, open-source feedback tools are increasingly viable.

[Quackback](https://quackback.io) is open source (AGPL-3.0) with a managed cloud option. Self-hosting includes SSO/OIDC, role-based access control, [AI-powered feedback analysis](/blog/ai-customer-feedback-analysis), an [MCP server](/features/mcp) for AI agent integrations, 25 integrations, and analytics dashboards, with no feature gates. On [Quackback Cloud](/pricing), those capabilities sit on named plans (SSO and audit log on Enterprise; workflows on Business).

**Consider Quackback if** you need enterprise capabilities (SSO, RBAC, audit trails, multi-board architecture), and you want the choice between self-hosting for full data residency control or a managed cloud for zero operational overhead.

The trade-off with self-hosting is infrastructure responsibility. Your team manages the deployment, updates, and backups, which the [Quackback docs](/docs) walk through in detail. For organizations with DevOps capacity, this is a reasonable trade-off for full data control. For teams that want managed infrastructure, [Quackback Cloud](/pricing) removes that overhead.

For a broader comparison, see our guide to [open-source feedback tools](/blog/open-source-feedback-tools).

![Feedback flowing from Sales, Support, CS, and Product into a central hub](/blog/enterprise-feedback-management/feedback-hub-diagram.webp)

## Common enterprise challenges

### Feedback silos

The most common problem in enterprise feedback management is fragmentation. Customer success logs feedback in Salesforce. Support logs it in Zendesk. Sales logs it in Gong call notes. Product gets feature requests through a feedback portal. Each team has a partial picture, and nobody has the full picture.

Solving this requires either consolidating feedback into a single tool (expensive and politically difficult) or building integrations that surface relevant signals across systems. The integration approach is usually more practical — connect your feedback tool to Slack, Zendesk, Salesforce, and Jira so feedback flows from source systems into a central repository without requiring every team to change their workflow.

### Stakeholder alignment

In an enterprise, feature prioritization involves multiple stakeholders with competing interests. Sales wants features that close deals. Support wants features that reduce ticket volume. Engineering wants features that reduce technical debt. Product needs to balance all of these against the company's strategic direction.

A feedback tool helps by making demand visible and quantifiable. Instead of "sales says customers want X," you have "47 customers representing $2.3M in ARR have requested X, with 12 of those flagged as at-risk renewals." Data does not eliminate politics, but it grounds the conversation.

### Change management

Adopting a new feedback tool in a 500-person organization is a change management exercise, not a software deployment. People need to understand why they should use the new tool, how it fits into their existing workflow, and what happens to the feedback they submit.

Successful rollouts usually start with one product team, prove the value, and expand from there. Company-wide mandates without a pilot phase tend to produce low adoption and resentment.

## Building an enterprise feedback program

### Start with a pilot

Pick one product team with a clear feedback problem. Deploy the tool for that team, configure it for their specific workflow, and measure results over 60 to 90 days. Success metrics: feedback volume, time to triage, duplicate reduction, and user satisfaction with the feedback process.

### Define your taxonomy

Before scaling beyond the pilot, establish a shared taxonomy for categories, statuses, and priority levels. If Product A uses "Enhancement" and Product B uses "Feature Request" for the same thing, cross-product analysis becomes impossible.

### Integrate with existing systems

Connect the feedback tool to the systems your teams already use. The most impactful integrations:

- **Slack** — for incoming feedback from team channels and customer conversations
- **Jira or Linear** — for linking feedback to engineering work
- **CRM (Salesforce, HubSpot)** — for customer context and revenue data
- **Support (Zendesk, Intercom)** — for surfacing feedback from support conversations

### Establish governance

Who can change statuses? Who can merge posts? Who can export data? Who reviews feedback for each product area? Define these roles and document them. In an enterprise, ambiguity about ownership leads to either duplicated effort or neglected feedback.

### Report to leadership

Executives want aggregate metrics, not individual feature requests. Build a reporting cadence that surfaces: total feedback volume and trends, top requested features by customer segment, feedback-to-feature conversion rate, and customer satisfaction with the feedback process.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How much does enterprise feedback management software cost?

Pricing varies widely. UserVoice starts around $799/month. Productboard Enterprise requires custom pricing, typically four to five figures annually. Aha! Ideas starts at $59/user/month. Pendo uses custom pricing. Open-source tools like [Quackback](https://quackback.io) are free to self-host, with costs limited to your own infrastructure.

### Do I need a dedicated feedback tool or can I use Jira?

Jira is a project management tool, not a feedback tool. It lacks public portals, user voting, duplicate detection, and feedback-specific analytics. Use a dedicated feedback tool for collection and prioritization, then sync selected items to Jira for engineering execution.

### How do I handle feedback across multiple products?

Use a tool that supports multi-board or multi-workspace architecture. Each product gets its own board with its own team permissions. Cross-product insights surface through shared tags, executive dashboards, or a unified search that spans all boards.

### What is the difference between a feedback tool and a survey tool?

A feedback tool (Quackback, Canny, UserVoice) captures ongoing, unsolicited feedback such as feature requests and bug reports that users submit anytime. A survey tool (SurveyMonkey, Typeform) sends structured questionnaires at specific moments. Enterprises typically need both for continuous signal collection and targeted research.

### Is self-hosting worth the operational overhead?

For enterprises with strict data residency rules, regulated industries (healthcare, finance, government), or a preference for vendor independence, yes. Self-hosting eliminates data sovereignty concerns and gives the security team full control. Otherwise, a SaaS tool with SOC 2 compliance and managed cloud is usually sufficient.

- [Best MCP Servers for Product Managers in 2026](https://quackback.io/blog/mcp-servers-for-product-managers): The best MCP servers for product managers in 2026. Connect your feedback tool, project tracker, analytics, and chat to AI agents like Claude and Cursor.

Published: 2026-04-03

The average product manager uses somewhere between five and ten tools every day. A feedback board for feature requests. A project tracker for sprint work. An analytics platform for usage data. A communication tool for stakeholder updates. A documentation system for specs and decisions. Each tool holds a piece of the picture you need to make good product decisions, and none of them talk to each other natively.

MCP changes that. It connects all of these tools to your AI assistant through a single protocol, so you can query, analyze, and act across your entire stack from one conversation.

![MCP servers connecting product management tools to an AI assistant](/blog/mcp-servers-for-product-managers/hero.webp)

> **The best MCP servers for product managers** connect your feedback tool, project tracker, analytics, communication, and docs to AI assistants like Claude and Cursor through one protocol. The nine worth installing are Quackback (feedback and roadmaps), Linear, Jira, Slack, PostHog, GitHub, Notion, Supabase/Postgres, and Context7. Each entry below covers what it does, key operations, and how to install it.

## What is MCP

**MCP** stands for **Model Context Protocol**. It is an open standard that lets AI agents connect to external tools and data sources through a universal interface. Instead of writing custom API integrations, you install an MCP server for each tool and your AI assistant discovers its capabilities automatically.

If you want the full explanation, read [What Is an MCP Server? A Guide for Product Teams](/blog/what-is-an-mcp-server). For this guide, what matters is this: MCP servers turn your AI assistant into an operator that can read, write, and act across every tool in your stack.

## The product manager's MCP stack

Product work spans several categories of tooling. The MCP servers worth installing map directly to those categories:

| Category | Tool | What it gives the AI |
|----------|------|---------------------|
| **Feedback and roadmap** | [Quackback](#1-quackback--feedback-feature-requests-roadmaps-changelogs) | Feature requests, votes, roadmap items, changelogs |
| **Project tracking** | [Linear](#2-linear--project-tracking-and-issue-management) | Issues, cycles, projects, team workloads |
| **Enterprise PM** | [Jira](#3-jira--enterprise-project-management) | Epics, stories, sprints, Confluence docs |
| **Communication** | [Slack](#4-slack--team-communication-and-history) | Messages, channels, threads, search |
| **Analytics** | [PostHog](#5-posthog--product-analytics-and-feature-flags) | Events, funnels, feature flags, session replays |
| **Development** | [GitHub](#6-github--issues-prs-and-code-search) | Issues, PRs, code search, project boards |
| **Documentation** | [Notion](#7-notion--docs-databases-and-knowledge-management) | Pages, databases, knowledge base |
| **Database** | [Supabase / Postgres](#8-supabase--postgres--database-access-for-custom-queries) | Direct SQL queries on product data |
| **Library docs** | [Context7](#9-context7--documentation-lookup-for-any-library) | Up-to-date docs for any framework or library |

The rest of this guide covers each one: what it does, what operations it exposes, who it is best for, and how to install it.

## 1. Quackback — feedback, feature requests, roadmaps, changelogs

[Quackback](https://quackback.io) is an open-source feedback management platform. It handles [feedback boards](/features/feedback), [feature request voting](/features/voting), [public roadmaps](/features/roadmap), and [changelogs](/features/changelog). The [Quackback MCP server](/features/mcp) is built directly into the product — not a third-party wrapper — which means it stays current with every release. Unlike closed tools such as [Canny](/compare/quackback-vs-canny) or [Productboard](/compare/quackback-vs-productboard), the MCP layer ships and versions with the app itself.

**What it does as an MCP server:** Gives your AI agent full read-write access to your feedback stack. The agent can search feature requests, check vote counts, triage incoming feedback, update roadmap statuses, draft changelog entries, and detect duplicate posts. It exposes tools and resources across every core feature. The server uses Streamable HTTP and authenticates with an API key (`qb_` prefix) or OAuth.

**Key operations:**
- **Search and filter feedback** — find feature requests by keyword, status, tag, or vote count
- **Triage incoming posts** — categorize, tag, and set status on new feedback
- **Manage roadmap items** — move items between stages (planned, in progress, complete)
- **Draft changelogs** — create changelog entries when features ship
- **Detect and merge duplicates** — identify similar posts and merge them to consolidate votes

**Best for:** Product managers who want their AI assistant to operate across the full feedback lifecycle — from collecting requests to shipping features and closing the loop with users.

**How to install:**

Quackback's MCP server is HTTP-based (Streamable HTTP), built into every instance — whether you self-host or use [Quackback Cloud](/pricing). No npm package to install. In Claude Code, run:

```bash
claude mcp add --transport http --scope user quackback https://your-quackback-instance/api/mcp
```

Claude Code handles OAuth authentication automatically. If you prefer API key auth instead:

```bash
claude mcp add --transport http --scope user -H "Authorization: Bearer qb_YOUR_API_KEY" quackback https://your-quackback-instance/api/mcp
```

For Cursor, add the config to `.cursor/mcp.json` with the URL and auth header.

For a deeper walkthrough of the feedback-specific capabilities, see [MCP Server for Feedback Management](/blog/mcp-server-feedback-management). For full setup documentation, see the [Quackback MCP integration guide](/integrations/mcp).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. Linear — project tracking and issue management

Linear is a project tracker built for speed. Its [official MCP server](https://linear.app/docs/mcp) is a remote server that lets AI agents interact with your issues, cycles, projects, and team data directly.

**What it does as an MCP server:** Gives the AI read and write access to your Linear workspace. Create issues, update statuses, query sprint data, and search across projects.

**Key operations:**
- **Create and update issues** — file bugs or feature work directly from a conversation
- **Query cycles and projects** — pull current sprint scope, completed work, and blockers
- **Search across the workspace** — find issues by keyword, assignee, label, or status

**Best for:** Product managers and technical PMs who use Linear for sprint planning and want to connect sprint data with feedback signals.

**How to install:**

```bash
claude mcp add --transport http linear https://mcp.linear.app/mcp
```

Then run `/mcp` in Claude Code to complete the OAuth flow. See how Quackback connects to Linear: [Quackback Linear integration](/integrations/linear).

## 3. Jira — enterprise project management

Jira is the default project tracker in most enterprises. Atlassian's [official remote MCP server](https://www.atlassian.com/platform/remote-mcp-server) gives AI agents access to issues, epics, sprints, and Confluence pages.

**What it does as an MCP server:** Lets the AI read and create Jira issues, query sprint boards, and search across projects. Some implementations also expose Confluence documentation.

**Key operations:**
- **Search issues with JQL** — use Jira Query Language through natural language
- **Create and update issues** — file tickets with full metadata (priority, labels, story points)
- **Read Confluence pages** — pull specs, PRDs, and decision docs into the conversation

**Best for:** Product managers in enterprise environments where Jira is the system of record for all project work.

**How to install:**

```bash
claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2
```

Then run `/mcp` to authenticate with OAuth. See how Quackback connects to Jira: [Quackback Jira integration](/integrations/jira).

## 4. Slack — team communication and history

Slack is where most product decisions actually get discussed. A Slack MCP server gives your AI agent access to channels, threads, and message history. The original reference server was archived in 2025; Slack now ships an [official MCP server](https://docs.slack.dev/ai/slack-mcp-server/), and maintained community alternatives exist.

**What it does as an MCP server:** Lets the AI search conversation history, read threads, and post messages. Useful for pulling context from past discussions and automating status updates.

**Key operations:**
- **Search message history** — find past conversations about a feature, decision, or customer
- **Read channel and thread content** — pull full discussion context into your prompt
- **Post messages** — send updates to channels when roadmap items change or features ship

**Best for:** PMs who want to automate stakeholder communication and use Slack history as a knowledge source for product decisions.

**How to install:** Slack's official MCP server is managed by your workspace admin, who approves the connection from the Slack admin console. Follow the [Slack MCP server docs](https://docs.slack.dev/ai/slack-mcp-server/) for the current setup. See how Quackback connects to Slack: [Quackback Slack integration](/integrations/slack).

## 5. PostHog — product analytics and feature flags

PostHog is an open-source analytics platform that covers product analytics, session replays, and feature flags. Its [official MCP server](https://posthog.com/docs/model-context-protocol) lets AI agents query usage data directly.

**What it does as an MCP server:** Gives the AI access to event data, funnels, user properties, and feature flag configurations. The AI can answer questions about product usage without you opening the PostHog dashboard.

**Key operations:**
- **Query events and trends** — ask about feature adoption, conversion rates, or usage patterns
- **Check feature flag status** — see which flags are active, their rollout percentages, and targeting rules
- **Analyze user behavior** — pull session data and funnel analysis into product conversations

**Best for:** Data-driven PMs who want to combine quantitative analytics with qualitative feedback data in the same conversation.

**How to install:**

```bash
claude mcp add --transport http posthog https://mcp.posthog.com/mcp
```

Authenticate with a PostHog personal API key.

## 6. GitHub — issues, PRs, and code search

GitHub needs no introduction. Its [official MCP server](https://github.com/github/github-mcp-server) gives AI agents access to repositories, issues, pull requests, and code search.

**What it does as an MCP server:** Lets the AI read issues, check PR status, search code, and interact with project boards. Useful for PMs who work closely with engineering and want visibility into development progress.

**Key operations:**
- **Search issues and PRs** — find open bugs, feature branches, or stale pull requests
- **Read PR details** — check review status, CI results, and linked issues
- **Query project boards** — see what is in progress, in review, or shipped

**Best for:** Technical PMs who want to connect product planning (feedback and roadmap) with engineering execution (issues and PRs).

**How to install:**

The fastest path is GitHub's hosted remote server:

```bash
claude mcp add --transport http github https://api.githubcopilot.com/mcp/
```

You can also run it locally with the official Docker image (`ghcr.io/github/github-mcp-server`). See how Quackback connects to GitHub: [Quackback GitHub integration](/integrations/github).

## 7. Notion — docs, databases, and knowledge management

Notion is where many product teams keep PRDs, meeting notes, decision logs, and research. The [official Notion MCP server](https://developers.notion.com/guides/mcp/get-started-with-mcp) gives AI agents access to your workspace.

**What it does as an MCP server:** Lets the AI search pages, read database entries, and query your knowledge base. Useful for pulling product specs and context into conversations.

**Key operations:**
- **Search across your workspace** — find PRDs, meeting notes, or decision documents by keyword
- **Read page content** — pull full documents into the conversation for analysis or summarization
- **Query databases** — access structured data like feature trackers, OKR tables, or research logs

**Best for:** PMs who use Notion as their source of truth for product documentation and want the AI to reference it directly.

**How to install:**

```bash
claude mcp add --transport http notion https://mcp.notion.com/mcp
```

Then run `/mcp` to authorize with OAuth. See how Quackback connects to Notion: [Quackback Notion integration](/integrations/notion).

## 8. Supabase / Postgres — database access for custom queries

Sometimes the data you need is not in a SaaS tool. It is in your database. The Supabase and Postgres MCP servers give AI agents direct SQL access to your data.

**What it does as an MCP server:** Lets the AI run read-only SQL queries against your database. Useful for ad-hoc analysis, pulling customer data, or checking product metrics that are not surfaced in your analytics tool.

**Key operations:**
- **Run SQL queries** — ask questions about your data in natural language, and the AI writes and executes SQL
- **Explore schema** — the AI can discover tables and columns to answer questions you did not anticipate
- **Pull customer data** — look up specific accounts, usage patterns, or subscription details

**Best for:** PMs at startups and growth-stage companies who need quick data access without waiting for an analyst or building a dashboard.

**How to install:**

```bash
claude mcp add supabase -- npx @supabase/mcp-server-supabase
```

## 9. Context7 — documentation lookup for any library

Context7 is not a product management tool in the traditional sense. It is an MCP server that gives your AI agent access to current documentation for any library, framework, or SDK.

**What it does as an MCP server:** Fetches live documentation for libraries when the AI needs to reference it. This ensures the AI is working with current syntax and APIs rather than relying on potentially outdated training data.

**Key operations:**
- **Resolve library documentation** — look up docs for any framework or tool by name
- **Query specific topics** — find documentation on a specific method, configuration, or concept
- **Stay current** — always pulls the latest published docs rather than relying on stale training data

**Best for:** Technical PMs who write specifications or acceptance criteria that reference specific libraries, and want the AI to validate technical details against current docs.

## How to connect multiple MCP servers

The real value of MCP for product managers is not any single server. It is running multiple servers simultaneously so your AI assistant can operate across your entire stack.

Both **Claude Code** and **Cursor** support multiple MCP servers in the same session. When you connect several servers, the AI can cross-reference data between tools in a single conversation.

In Claude Code, configure all your servers in `.mcp.json`:

```json
{
  "mcpServers": {
    "quackback": {
      "type": "http",
      "url": "https://your-instance.example.com/api/mcp",
      "headers": {
        "Authorization": "Bearer qb_YOUR_API_KEY"
      }
    },
    "linear": {
      "type": "http",
      "url": "https://mcp.linear.app/mcp"
    },
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "notion": {
      "type": "http",
      "url": "https://mcp.notion.com/mcp"
    }
  }
}
```

Most of the major servers are now remote (Streamable HTTP) and authenticate with OAuth, so there is no npm package to install. In Cursor, add servers through the MCP settings panel or `.cursor/mcp.json`. Each server appears as a separate connection, and all are available to the AI simultaneously.

Once connected, you do not need to tell the AI which server to use. Ask a question, and it will determine which tools to call based on context. Ask "What feature requests came in this week that are not on the roadmap?" and the AI will query your feedback tool and your project tracker in the same response.

For a deeper explanation of how MCP clients manage multiple servers, see [What Is an MCP Server?](/blog/what-is-an-mcp-server).

## Building a PM workflow with MCP

Here is a practical example of how multiple MCP servers work together in a single workflow. This scenario uses Quackback, Linear, Slack, and GitHub.

### The scenario: weekly prioritization

Every week you need to review new feedback, decide what to build next, and communicate priorities to the team. Without MCP, this means opening four tools, exporting data, cross-referencing manually, and writing updates by hand.

With MCP, the entire workflow happens in one conversation:

**Step 1: Review feedback.** Ask the AI: "What are the top 10 most-voted feature requests from the last two weeks that are not on the roadmap?"

The AI queries your [Quackback feedback board](/features/feedback), filters by vote count and date, checks each request against your [roadmap](/features/roadmap), and returns a ranked list.

**Step 2: Check engineering capacity.** Ask: "What is the current cycle load in Linear? How many points are unassigned?"

The AI queries Linear for the current cycle, calculates capacity, and tells you how much room there is for new work.

**Step 3: Create work items.** Tell the AI: "Create a Linear issue for the top-voted request. Link it to the feedback post in Quackback and move the roadmap item to planned."

The AI creates the Linear issue, updates the Quackback roadmap status, and links the two together.

**Step 4: Notify the team.** Tell the AI: "Post a summary of this week's prioritization decisions to the #product channel in Slack."

The AI drafts a message based on the decisions you just made and posts it to Slack.

Four tools. One conversation. What used to take an hour of context-switching takes five minutes.

## Frequently asked questions

### Do I need to be a developer to use MCP servers?

No. Most MCP servers install with a single command or config file edit. Product managers use them through AI assistants like Claude Desktop, Cursor, or Claude Code without writing any integration code.

### Can I use multiple MCP servers at the same time?

Yes. AI clients like Claude Code and Cursor support multiple MCP servers simultaneously. You can connect your feedback tool, project tracker, analytics platform, and communication tools in the same session. The AI decides which server to query based on your question.

### Are MCP servers free?

Most MCP servers are open source and free to install. The underlying tools they connect to (Linear, Jira, PostHog) have their own pricing, but the MCP server layer itself is typically free. Quackback is entirely [open source](/docs) — both the product and its MCP server.

### What is the difference between an MCP server and a Zapier integration?

Zapier connects tools through predefined triggers and actions, running automatically when a rule fires. MCP servers give AI agents direct, real-time access so the agent decides what to read and which actions to take based on context. MCP is conversational and adaptive; Zapier is rule-based and static.

### Does Quackback have an MCP server?

Yes. Quackback ships with a built-in [MCP server](/features/mcp) exposing tools and resources for feedback, feature requests, roadmaps, voting, and changelogs. It uses Streamable HTTP with API key or OAuth auth and works with Claude, Cursor, and any [MCP client](/integrations/mcp). Being built in, it stays current with every release.

- [Feature Request Tracking in Excel (and When to Upgrade)](https://quackback.io/blog/feature-request-tracking-spreadsheet): A spreadsheet is a fine starting point for tracking feature requests. Here is a template that works, and how to tell when you have outgrown it.

Published: 2026-04-02

Every product team starts the same way. Someone creates a spreadsheet, names it "Feature Requests," and shares it with the team. It works. For a while.

![Feature request spreadsheet overflowing with data](/blog/feature-request-tracking-spreadsheet/hero.webp)

Spreadsheets are familiar, free, and infinitely flexible. There is no approval process to adopt one, no vendor evaluation, no integration work. You open a new sheet, add some columns, and start tracking. For early-stage products with a small user base and a small team, this is genuinely the right tool.

The problem is not that spreadsheets are bad at tracking feature requests. The problem is that they stop working at a specific scale, and most teams do not recognize the signs until they have already lost signal in the noise.

This guide gives you a spreadsheet template that actually works, the specific signals that tell you it is time to switch, and what to look for when you do.

## A feature request spreadsheet template that works

Most feature request spreadsheets fail because they are either too simple (a list of ideas with no structure) or too complex (20 columns that nobody fills out). Here is a template that balances structure with usability.

### Core columns

| Column | Type | Purpose |
|---|---|---|
| **Request** | Text | One-sentence description of the feature request |
| **Requester** | Text | Who asked for it (name, company, or email) |
| **Source** | Dropdown | Where it came from (support ticket, sales call, Slack, email, interview) |
| **Category** | Dropdown | Product area (onboarding, reporting, integrations, billing, etc.) |
| **Status** | Dropdown | Current state (New, Under Review, Planned, In Progress, Shipped, Declined) |
| **Priority** | Dropdown | How important (P0 Critical, P1 High, P2 Medium, P3 Low) |
| **Votes** | Number | How many users have asked for the same thing |
| **Date added** | Date | When the request was first logged |
| **Notes** | Text | Additional context, links to conversations, or reasons for decisions |

### How to use it

**One row per unique request.** When multiple users ask for the same thing, increment the Votes column and add their name to the Requester field. Do not create a new row for each duplicate — that defeats the purpose of tracking demand.

**Use dropdowns for Status, Priority, Source, and Category.** Free-text fields in these columns guarantee inconsistency. Someone will write "high" while someone else writes "High" while a third person writes "important." Dropdowns enforce consistency without extra effort.

**Update Status when things change.** A spreadsheet only works if it reflects reality. When you start working on a request, move it to In Progress. When you ship it, move it to Shipped. When you decide not to build something, move it to Declined and add a note explaining why. Stale statuses are the fastest way to make a spreadsheet useless.

**Review weekly.** Set a recurring 30-minute meeting to review new requests, update priorities, and clean up duplicates. Without this, the spreadsheet drifts out of date within two weeks.

### Google Sheets formula tips

**Auto-sort by votes:** Use a filtered view sorted by the Votes column descending. Your highest-demand requests stay at the top.

**Conditional formatting:** Color-code the Status column. Green for Shipped, blue for In Progress, yellow for Planned, red for Declined. Visual cues make scanning faster than reading text.

**COUNTIF for category breakdown:** `=COUNTIF(D:D, "Integrations")` gives you a count of requests per category. Useful for spotting which product areas generate the most demand.

**Data validation for dropdowns:** Select the column, go to Data > Data Validation, and enter your allowed values. This prevents free-text entries in columns that should be structured.

## Where spreadsheets break down

A spreadsheet works until it does not. These are the specific failure modes.

### No deduplication

User A emails "we need a Slack integration." User B mentions it in a support ticket. User C brings it up in a sales call. Three team members log it as three separate rows. Without a system that surfaces existing requests when someone adds a new one, duplicates multiply.

At 50 requests, you can eyeball duplicates. At 200, you cannot. At 500, your spreadsheet has become a list of requests where half of them are duplicates of the other half, and your vote counts are meaningless because demand is fragmented across multiple rows.

### No user-facing portal

Your spreadsheet is internal. Users cannot see it, search it, or vote on existing requests. Every feature request requires a user to contact you through some other channel (email, support ticket, Slack) and a team member to manually log it.

This means you only hear from users who care enough to reach out. The silent majority — users who would vote on an existing request if they could see it, but will not take the initiative to email you — never appears in your data.

A public [feedback board](/features/feedback) with [voting](/features/voting) flips this dynamic. Users browse existing requests, vote on what matters to them, and submit new ideas if theirs is not already listed. You hear from a much larger percentage of your user base.

### No notifications

When you ship a feature that users requested, how do you tell them? In a spreadsheet, you have a list of requester names or emails. You could email them manually. In practice, nobody does this consistently. The feedback loop breaks — users do not know their request was heard, so they stop making requests.

### Formula and data errors

Spreadsheets are deceptively fragile. Research by Ray Panko at the University of Hawaii found that 88% of spreadsheets contain errors. A 2024 follow-up study put the figure at 94% for business-critical spreadsheets. One wrong cell reference in your RICE scoring formula silently corrupts every priority ranking in the sheet, and nobody notices until someone asks why a low-value feature got built first.

### Multi-editor conflicts

Google Sheets handles simultaneous editing reasonably well, but it does not handle simultaneous decision-making. When two PMs review the same spreadsheet and update priorities based on different conversations, you get conflicting assessments with no audit trail of who changed what or why.

### No segmentation

A spreadsheet treats every row equally. But a request from your largest enterprise customer should probably carry more weight than a request from a free trial user who signed up yesterday. Without integration to your CRM or billing system, you cannot segment requests by customer value, plan tier, or usage level.

### Reporting is manual

Want to know how many requests you received this quarter versus last quarter? How many shipped? What percentage were declined? You can build these reports with pivot tables and formulas, but it takes time and breaks whenever someone changes the sheet structure. A dedicated tool generates these reports automatically.

## Signs it is time to upgrade

Not every team needs to upgrade. If you have fewer than 100 feature requests total and a team of five or fewer, a spreadsheet is probably fine. But watch for these signals:

**You are spending more than 30 minutes per week on spreadsheet maintenance.** Deduplicating, updating statuses, reconciling conflicting edits, and building reports. When maintenance time exceeds the value of the data, the tool is working against you.

**Users ask about the status of their request and you cannot find it.** If searching your own spreadsheet takes more than 30 seconds, it has grown past the point of usability.

**You have no idea how many people want a specific feature.** Because demand is fragmented across duplicate rows, partial entries, and notes buried in the Notes column. Your vote counts do not reflect reality.

**Your team has stopped logging requests.** The friction of opening the spreadsheet, checking for duplicates, and adding a row is high enough that people skip it. When requests go unlogged, your data becomes incomplete and your prioritization decisions are based on partial information.

**Customers tell you they submitted feedback and nothing happened.** The feedback loop is broken. Requests go in but acknowledgement never comes out.

**You need to present feedback data to leadership.** Showing a messy spreadsheet to your VP of Product is not the same as showing a dashboard with vote counts, trend lines, and status breakdowns. If you need to report on feedback, you need a tool that makes reporting easy.

## What to look for in a dedicated tool

When you outgrow a spreadsheet, you do not need the most feature-rich tool on the market. You need a tool that solves the specific problems your spreadsheet cannot handle.

**Deduplication.** The tool should surface similar existing requests when someone submits a new one. AI-powered duplicate detection is even better — it catches semantic duplicates that keyword matching misses ("Slack integration" and "connect with Slack" are the same request). [AI-powered feedback tools](/blog/ai-customer-feedback-analysis) handle this automatically.

**Public voting.** A user-facing portal where customers can see existing requests, vote, and submit new ones. This is the single biggest upgrade over a spreadsheet — it turns feedback collection from a manual internal process into a self-service external one.

**Status updates and notifications.** When you change a request's status, users who voted on it should be notified automatically. This closes the feedback loop without manual effort.

**Integrations.** Your feedback tool should connect to the tools your team already uses: Slack for incoming feedback, Jira or Linear for issue tracking, and your product for an embedded [widget](/features/widget).

**Data import.** You have an existing spreadsheet full of feature requests. Your new tool should let you import that data so you do not start from zero. Most tools accept CSV imports. Some offer [dedicated migration tools](/blog/migrate-from-canny) for specific platforms.

If you want to avoid vendor lock-in and keep costs predictable, [open-source feedback tools](/blog/open-source-feedback-tools) are worth considering. They are free to self-host, and your data stays on your infrastructure.

## Frequently asked questions

### Is a spreadsheet ever the right choice for feature request tracking?

Yes, for early-stage products with fewer than 100 requests and a team of five or fewer. At that scale, the simplicity and flexibility of a spreadsheet outweigh its limitations. The key is recognizing when you have outgrown it and switching before your data quality degrades.

### How do I migrate from a spreadsheet to a dedicated tool?

Export your spreadsheet as a CSV. Most feedback tools accept CSV imports that map your columns to their data model. Clean up your data first: merge duplicate rows, standardize status values, and remove incomplete entries. The migration itself takes less than an hour for most datasets.

### Should I use Google Sheets or Excel?

Google Sheets for team collaboration (real-time editing, sharing, no file syncing). Excel for complex analysis (better pivot tables, more formula power, works offline). For feature request tracking specifically, Google Sheets is usually the better choice because multiple team members need to add and update requests.

### How do I track votes in a spreadsheet?

Use a Votes column with a number. When a new user requests something that already has a row, increment the number and add the requester's name to a comma-separated list in the Requester field. This is manual and error-prone — it is one of the first things that breaks at scale, because team members forget to check for existing rows before adding new ones.

### What is the best free alternative to a spreadsheet for feature tracking?

[Quackback](https://quackback.io) is open source and free to self-host. It replaces the spreadsheet with a feedback board that has public voting, automatic deduplication, status notifications, and a widget you can embed in your product. If you want the structure of a dedicated tool without a monthly bill, self-hosting an open-source option is the most direct upgrade path.

- [Customer Feedback Form Template: Free Templates for SaaS Teams (2026)](https://quackback.io/blog/feedback-form-template): Most feedback forms ask too many questions and get abandoned. Here are four templates optimized for completion rates, plus guidance on field selection, form length, and distribution.

Published: 2026-04-02

The average feedback form asks too many questions and gets abandoned halfway through. The best ones ask three to five questions and capture more useful signal than a twenty-field survey ever could.

![Short feedback forms with higher completion rates](/blog/feedback-form-template/hero.webp)

A HubSpot analysis of 40,000 landing pages found that forms with three fields convert at roughly 25%. Forms with ten or more fields drop to 15%. Research from Zuko found that multi-step forms with one question per screen convert 86% higher than single-step forms with the same total fields. The design of your form determines how much feedback you actually collect.

This guide covers four feedback form templates for different use cases, the data behind optimal form length, and how to distribute forms for maximum response rates. These are general-purpose feedback forms — for survey-specific templates, see our guides on [NPS surveys](/blog/nps-survey-template), [CSAT surveys](/blog/customer-satisfaction-survey-template), and [feature request templates](/blog/feature-request-template).

## What makes a good feedback form

A good feedback form maximizes the ratio of useful signal to respondent effort. Three principles:

**Ask fewer questions, but the right ones.** Every field you add reduces completion rates. A form with four fields and a 75% completion rate collects more total responses than a form with twelve fields and a 30% completion rate. Only include fields where the answer changes what you do next.

**Lead with structure, follow with open text.** Start with a structured question (rating, category dropdown, or multiple choice) that gives you sortable data. Follow with one open-ended question that gives you context. The structured field tells you what happened; the open text tells you why.

**Make identity optional.** Making email required kills anonymous feedback. Users who are frustrated or who have sensitive feedback will not submit it with their name attached. Include an email field but mark it optional with a note: "Include your email if you would like us to follow up." See our guide on [why anonymous feedback gets more honest responses](/blog/anonymous-feedback).

## Four feedback form templates

### 1. General feedback form (3-4 fields)

Use this as your default catch-all feedback form. It works for any type of input — bugs, ideas, praise, complaints.

**Fields:**

| Field | Type | Required |
|---|---|---|
| **What type of feedback is this?** | Dropdown: Bug, Feature idea, Question, Praise, Complaint | Yes |
| **Tell us more** | Text area (max 500 chars) | Yes |
| **How would you rate your overall experience?** | 1-5 stars or emoji scale | No |
| **Email** | Email field ("Include if you would like follow-up") | No |

**Why it works:** The category dropdown lets you route feedback automatically (bugs to engineering, feature ideas to product). The text area captures context. The rating gives you a trackable metric. The optional email enables follow-up without forcing it.

### 2. Bug report form (4-5 fields)

Use this when a user clicks "Report a bug" or submits from an error page. Structure matters here because engineers need specific information to reproduce the issue.

**Fields:**

| Field | Type | Required |
|---|---|---|
| **What happened?** | Short text (subject line) | Yes |
| **What did you expect to happen?** | Text area | Yes |
| **Steps to reproduce** | Text area | No |
| **How severe is this?** | Dropdown: Blocker, Major, Minor, Cosmetic | Yes |
| **Screenshot or recording** | File upload | No |

**Why it works:** The expected vs. actual framing forces users to articulate the gap, which is the most valuable information for debugging. Severity helps with triage. Steps to reproduce and screenshots are optional because requiring them dramatically reduces submission rates — some signal is better than perfect signal.

### 3. Feature suggestion form (3 fields)

Use this when a user clicks "Suggest a feature" or "Share an idea." The key insight: the "why" is more valuable than the "what."

**Fields:**

| Field | Type | Required |
|---|---|---|
| **What do you need?** | Short text (one-sentence description) | Yes |
| **Why do you need this?** | Text area ("What problem does this solve for you?") | Yes |
| **How are you solving this today?** | Text area ("Current workaround, if any") | No |

**Why it works:** The "why" field prevents solution-shaped requests ("add a Gantt chart") and surfaces the underlying problem ("I need to visualize task dependencies across teams"). The workaround field reveals urgency — if the current workaround is painful, the request is higher priority.

This is the same approach used by [feature request boards](/features/feedback) with [voting](/features/voting). The difference is that a form collects individual submissions, while a board lets users see existing requests and vote instead of duplicating them. For ongoing feature collection, a board is more efficient than a form.

### 4. Post-interaction form (2-3 fields)

Use this immediately after a specific event: support resolution, onboarding completion, feature first-use, or purchase.

**Fields:**

| Field | Type | Required |
|---|---|---|
| **How easy was this experience?** | 1-7 scale (for [CES](/blog/customer-effort-score)) or 1-5 stars (for CSAT) | Yes |
| **What is the main reason for your rating?** | Text area (shown conditionally for low ratings) | No |
| **Anything else you would like to share?** | Text area | No |

**Why it works:** The rating is fast (under five seconds to complete). The follow-up text area only appears for low ratings, which reduces form length for satisfied users while capturing detail from dissatisfied ones. This conditional logic is the single most effective technique for balancing completion rate with data richness.

![Form completion rates drop sharply after 7 fields](/blog/feedback-form-template/completion-rates.webp)

## Optimal form length: what the data says

| Fields | Completion rate | Source |
|---|---|---|
| 1-3 | ~83% | Survicate |
| 3 | ~25% conversion (highest) | HubSpot (40K landing pages) |
| 4-5 | Minimal drop-off | Zuko |
| 7 or fewer | 34% conversion | Formstory |
| 10+ | 15% conversion | Formstory |
| 15+ | ~42% completion | Survicate |

The sweet spot is three to five fields. Below three, you may not capture enough context. Above seven, completion rates decline sharply. If you need more than seven fields, use multi-step forms with one or two questions per screen — they convert 86% higher than single-page forms with the same total questions.

**Field type matters as much as field count.** Zuko's data shows that standard text fields cause minimal drop-off, but large text areas and dropdown select boxes cause measurable abandonment. Use dropdowns sparingly and keep text areas short (limit to 500 characters).

## How to distribute feedback forms

The channel you use to deliver the form affects response rates as much as the form itself.

| Channel | Response rate | Best for |
|---|---|---|
| **In-app widget** | 10-30% | Active users, contextual feedback |
| **In-app survey** | 10-30% | Post-action feedback |
| **Post-support trigger** | 30%+ | Support quality, CES |
| **Email** | 1-5% | Inactive users, reflective feedback |
| **Website embed** | Varies | Visitor feedback, pre-customer |
| **QR code** | Varies | Physical locations, events |

In-app forms get two to four times the response rate of email because you catch users when they are already engaged and the context is fresh. A [feedback widget](/features/widget) embedded in your product is the highest-conversion channel for ongoing feedback collection.

**Smart triggers over broadcast.** Show feedback forms after specific user actions (completed a task, used a feature for the fifth time, resolved a support ticket) rather than showing them to everyone. Contextual timing produces higher quality responses because the experience is fresh.

## Forms vs. feedback boards

Feedback forms and [feedback boards](/features/feedback) serve different purposes:

| | Feedback form | Feedback board |
|---|---|---|
| **Best for** | Structured one-time input | Ongoing feedback and prioritization |
| **User experience** | Fill out and submit | Browse existing ideas, vote, discuss |
| **Deduplication** | None (each submission is separate) | Built-in (users vote on existing items) |
| **Visibility** | Private (only your team sees it) | Public (users see each other's feedback) |
| **Follow-up** | Manual email if you have their address | Automatic status notifications to voters |

For collecting feedback at specific moments (post-support, post-onboarding), forms work well. For ongoing feature request collection and prioritization, a board with voting is more efficient because it aggregates demand automatically instead of creating duplicate submissions.

Many teams use both: a form for structured input at key touchpoints, and a board for ongoing feature discovery. [Quackback](https://quackback.io) combines both approaches — an embedded [widget](/features/widget) that captures feedback in-app, connected to a public board where users can see existing requests, vote, and track status.

## Common form design mistakes

**Asking too many questions.** If your form has more than seven fields, you are collecting less feedback than a shorter form would — the completion rate math works against you.

**Double-barreled questions.** "How was checkout and shipping?" asks two things at once. The respondent has to choose which one to rate, and you cannot tell which they answered.

**Leading questions.** "How much did you love the new feature?" presupposes the answer. Ask "How would you rate the new feature?" instead.

**Making email required.** This kills anonymous feedback and reduces completion rates. Make email optional with a clear reason to share it.

**No conditional logic.** Showing every field to every user wastes their time. Show the severity dropdown only for bug reports. Show the follow-up text area only for low ratings. Conditional logic keeps forms short for most users while capturing detail when needed.

**Wrong timing.** Showing a feedback form during checkout, before a user has experienced the product, or immediately on page load annoys users and produces low-quality responses. Time forms to moments when the user has just completed an interaction and has something to say.

## Frequently asked questions

### How many fields should a feedback form have?

Three to five for most use cases. This balances completion rates with data richness. If you need more detail, use conditional logic to show additional fields only when relevant, or use a multi-step format with one to two questions per screen.

### Should I use open-ended or structured fields?

Both. Lead with one structured question (rating, category, or multiple choice) for sortable data, then follow with one open-ended question for context. Limit open-ended fields to one or two per form — they cause more drop-off than structured fields and are harder to analyze at scale.

### What is better — a form or a feedback widget?

A feedback widget is a form, but better. Widgets are embedded in your product, triggered contextually, and connected to a system that tracks, deduplicates, and prioritizes what comes in. Standalone forms (Google Forms, Typeform) collect submissions into a spreadsheet. A widget collects submissions into a [feedback board](/features/feedback) with voting, status tracking, and notifications. If you are choosing between the two, a widget captures more feedback with less effort for both you and your users.

### How do I analyze open-ended feedback at scale?

Manual analysis works up to about 50 responses per month. Beyond that, use [AI-powered feedback analysis](/blog/ai-customer-feedback-analysis) to detect themes, sentiment patterns, and duplicates automatically. Most feedback tools offer some level of automated categorization. For teams handling hundreds of submissions per month, manual analysis becomes a bottleneck.

### Should feedback forms be anonymous?

Offer anonymous submission as an option, not a requirement. Make email optional with a note explaining why they might want to include it ("so we can follow up with you"). This gives you identified feedback from users who want follow-up and [anonymous feedback](/blog/anonymous-feedback) from users who want honesty. Both are valuable.

- [Product Manager Interview Questions (With Strong Answers)](https://quackback.io/blog/product-manager-interview-questions): 16 PM interview questions by category — product sense, analytical, execution, behavioral, and estimation — with proven frameworks for answering each one.

Published: 2026-04-02

Product manager interviews test how you think, not what you know. The interviewer already knows the answer is not obvious — they want to see your framework, your trade-offs, and whether you can structure ambiguity into a clear decision.

![Five PM interview question categories](/blog/product-manager-interview-questions/hero.webp)

This guide covers 16 questions across five categories, with frameworks for structuring your answers and examples of what strong responses look like. The questions are representative of what companies like Google, Meta, Amazon, Stripe, and growth-stage startups ask.

> **Product manager interview questions fall into five categories: product sense, analytical, execution, behavioral, and estimation.** Product sense questions (design or improve a product) carry the most weight, while analytical and execution questions test how you prioritize and diagnose with data. The strongest answers lead with a framework — clarify the user, define the metric, then reason to a recommendation — rather than jumping straight to a solution.

![Five PM interview categories with relative weighting bars](/blog/product-manager-interview-questions/interview-categories.webp)

## Product sense questions

Product sense questions test your ability to think about users, define problems, and design solutions. They are typically the highest-weighted category in PM interviews.

### 1. "Design a product for elderly people to stay connected with their families."

**What they are testing:** Can you define a target user, identify their needs, and design a product that addresses those needs — not just list features?

**Framework:** Start by clarifying the user (age, tech comfort, living situation). Identify their core pain points (isolation, difficulty with technology, desire for connection). Brainstorm solutions that address those pain points. Evaluate and prioritize. Describe your recommendation with rationale.

**Strong answer structure:** "I would focus on elderly people living alone, aged 75+, with limited smartphone experience. Their primary pain point is feeling disconnected from grandchildren. I would design a simplified video calling device — a single-purpose tablet with one button that calls a pre-configured contact list. I would prioritize this over a general communication app because reducing friction is more important than adding features for this user. The [Kano Model](/blog/kano-model) helps here — video calling is must-be functionality, while a simple hardware form factor is the delighter."

### 2. "How would you improve Instagram Stories?"

**What they are testing:** Can you analyze an existing product, identify opportunities for improvement, and prioritize them?

**Framework:** Clarify which user segment you are focusing on (creators, consumers, or advertisers). Identify current pain points through user behavior analysis. Generate improvement ideas. Evaluate using impact and effort. Recommend one or two changes with clear rationale.

**Strong answer structure:** Define the metric you are optimizing (engagement rate, time spent, creator retention). Identify the specific problem (e.g., creators with under 1,000 followers see low engagement on Stories, which discourages continued creation). Propose a solution (e.g., discovery features for Stories from small creators). Explain why this matters for the business (creator supply drives consumer engagement, which drives ad revenue).

### 3. "You are the PM for Spotify. A feature that lets users collaborate on playlists has been proposed. Would you build it?"

**What they are testing:** Can you evaluate a feature proposal critically instead of defaulting to "yes"?

**Framework:** Clarify the user need (do users actually want collaborative playlists?). Size the opportunity (how many users would use this?). Assess the effort (engineering, design, and maintenance cost). Evaluate against alternatives (what else could the team build with the same effort?). Make a recommendation.

**Strong answer structure:** Consider how you would validate demand before committing to build. "I would first check if this is a real user need by looking at [feedback data](/features/feedback) and support requests. If collaborative playlists are a top-10 request by volume, the signal is strong. I would also analyze user behavior — are users already sharing playlists via links? That workaround pattern suggests unmet demand."

### 4. "Pick a product you use daily. What would you change about it?"

**What they are testing:** Do you think critically about products in your daily life? Can you articulate a problem clearly?

**Framework:** Choose a product you genuinely use and have opinions about. Identify one specific friction point. Explain why it matters. Propose a solution. Explain the trade-off.

**Avoid:** Generic answers about popular products. "I would make Google Search faster" says nothing. "Google Maps shows me restaurant hours but not current wait times — I would add real-time wait estimates using aggregated location data because 40% of my restaurant decisions happen at the moment I arrive" shows actual product thinking.

## Analytical questions

### 5. "A key metric dropped 15% week-over-week. How do you investigate?"

**What they are testing:** Can you diagnose a data problem systematically?

**Framework:** Is it a data issue (tracking broke, reporting changed)? Is it seasonal or external (holiday, competitor launch, news event)? Is it a product issue (bug, UX regression, feature removal)? Is it a specific segment (one country, one device, one user cohort)?

**Strong answer structure:** Start broad, narrow down. "First, I would check if the metric definition or tracking changed. Then I would segment the drop — is it across all users or concentrated in a specific geography, device, or cohort? Then I would look at the product changelog — did anything ship that week? Finally, I would check external factors. The goal is to isolate the cause before proposing a fix."

### 6. "How would you measure the success of a new onboarding flow?"

**What they are testing:** Do you pick the right metrics and avoid vanity metrics?

**Strong answer structure:** "I would track three things. First, activation rate — the percentage of new users who complete the key action that correlates with retention (our [north star metric](/blog/north-star-metric) input). Second, time-to-first-value — how long it takes to reach that action. Third, 30-day retention for the cohort that went through the new flow versus the old one. I would not optimize for onboarding completion rate alone because a user can complete onboarding without actually getting value from the product."

### 7. "What metrics would you track for a feedback tool?"

**What they are testing:** Can you identify metrics that capture both user value and business value?

**Strong answer structure:** "The [north star metric](/blog/north-star-metric) would be monthly active feedback contributors — users who submit, vote, or comment. Input metrics: widget installation rate (breadth), submissions per active user (depth), weekly return rate (frequency), and time from installation to first submission (efficiency). Business metrics: conversion from free to paid, net revenue retention, and support ticket deflection rate. I would avoid vanity metrics like total registered users — what matters is active participation."

## Execution questions

### 8. "You have five feature requests from five different enterprise customers. How do you prioritize?"

**What they are testing:** Can you make a principled prioritization decision under pressure?

**Strong answer structure:** "I would not prioritize by customer size alone. I would use a framework that balances demand breadth, strategic fit, and effort. Specifically, I would apply [RICE scoring](/blog/rice-framework-explained): Reach (how many customers beyond these five would benefit?), Impact (how much does this move our key metric?), Confidence (how sure are we about the impact?), and Effort (engineering weeks). I would also check our [feedback board](/features/feedback) to see if any of these requests have votes from non-enterprise users — broad demand is a stronger signal than concentrated demand."

### 9. "How would you build a product roadmap for the next quarter?"

**What they are testing:** Can you connect strategy to execution?

**Strong answer structure:** "I would start with the team's strategic objectives for the quarter. Then I would inventory inputs: [customer feedback](/features/feedback) data (top-voted requests by segment), technical debt flagged by engineering, competitive gaps, and metrics that need improvement. I would score candidates using [RICE](/blog/rice-framework-explained) or a similar framework, then group them into themes. The [roadmap](/features/roadmap) would have two to three themes with clear outcomes, not a feature list. I would share it publicly so customers can see what is coming and provide early feedback."

### 10. "A stakeholder insists on building a feature you disagree with. What do you do?"

**What they are testing:** Can you navigate conflict without being either a pushover or a blocker?

**Strong answer structure:** "I would start by understanding their reasoning — what data or customer feedback drives their conviction? Often disagreements dissolve when both sides share their evidence. If we still disagree, I would propose a way to test the hypothesis cheaply — a prototype, a survey, or a [Kano analysis](/blog/kano-model) to validate demand. If the data supports their position, I would change my mind. If it supports mine, I would share the data respectfully. The goal is decisions based on evidence, not authority."

## Behavioral questions

### 11. "Tell me about a time you launched a product that failed."

**What they are testing:** Self-awareness, learning from failure, intellectual honesty.

**Strong answer structure:** Describe the product, what went wrong, and what you learned. Be specific about your role in the failure. Do not blame external factors. The best answers show that you identified the failure early, took action to mitigate it, and changed your approach going forward. "We skipped user research and built based on internal assumptions. The feature launched to minimal adoption. I learned to validate demand with [customer feedback](/blog/collect-customer-feedback) before committing engineering resources."

### 12. "Describe a time you had to make a decision with incomplete data."

**What they are testing:** Comfort with ambiguity, decision-making process.

**Strong answer structure:** Describe the decision, what data you had and what was missing, how you assessed the risk of being wrong, and what you did to reduce uncertainty. "I had usage data but no qualitative feedback. I ran five customer interviews in one week to fill the gap, made a decision based on the combined signal, and set a review point at 30 days to check if the decision held up."

### 13. "Tell me about a time you influenced without authority."

**What they are testing:** Collaboration skills, persuasion, cross-functional leadership.

**Strong answer structure:** Set the scene (who needed convincing, why they disagreed). Explain your approach (data, storytelling, prototyping). Describe the outcome. The best answers show that you changed someone's mind through evidence and empathy, not by escalating or going around them.

### 14. "How do you handle competing priorities from different teams?"

**What they are testing:** Stakeholder management, strategic thinking.

**Strong answer structure:** "I make the trade-offs visible. I create a shared view of all requests with their business impact, put them through the same prioritization framework, and let the data make the argument. When two requests have similar scores, I look at dependencies and sequencing — sometimes doing A first makes B easier. When there is no clear winner, I involve the stakeholders in the trade-off conversation directly. Transparency reduces politics."

## Estimation questions

### 15. "How many Slack messages are sent per day globally?"

**What they are testing:** Structured thinking, reasonable assumptions, math under pressure.

**Framework:** Start with what you know. Break the problem into components. Make explicit assumptions. Calculate. Sanity check.

**Strong answer structure:** "Slack has roughly 47 million daily active users. The average knowledge worker probably sends 50-100 messages per day on Slack. Call it 75 as a middle estimate. Heavy users (engineers, support teams) might send 150+, but casual users send fewer. So: 47 million × 75 = roughly 3.5 billion messages per day." (Actual figure: Slack reports approximately 1.5 billion messages per day, so this estimate is in the right order of magnitude.)

### 16. "Estimate the revenue of Uber Eats in the US."

**Framework:** US population → people who use food delivery → order frequency → average order value → Uber Eats market share → take rate.

**Strong answer structure:** Work through each step explicitly. "330M US population. About 30% use food delivery apps, so 100M potential users. Maybe 40% are active monthly: 40M. Average 3 orders/month at $30/order = $90/month per user. 40M × $90 × 12 = $43B in total US food delivery GMV. Uber Eats has roughly 25% market share = ~$10.8B GMV. With a 15-20% take rate, revenue is roughly $1.6-2.2B annually."

## How to prepare

**Build frameworks, not scripts.** Memorizing answers fails because interviewers ask variations. Understanding frameworks (RICE for prioritization, user-centric design for product sense, metric trees for analytics) lets you handle any variation.

**Practice with real products.** Pick three products you use daily. For each, identify one thing you would change, one metric you would track, and one feature you would cut. This builds the product intuition that interviews test.

**Study the company's product.** Use it. Read their [changelog](/features/changelog). Check their [feedback board](/features/feedback) if they have one. Understanding their product shows genuine interest and lets you reference specific features in your answers.

**Prepare two to three strong stories.** Most behavioral questions can be answered with a well-prepared story about a launch, a failure, a conflict, or a data-driven decision. Rehearse these stories until you can tell them in under two minutes.

Several of these questions ask how you would prioritize requests, build a roadmap, or diagnose a metric. The best preparation is doing the work, not just rehearsing answers. Quackback gives you a public [feedback board](/features/feedback) with [voting](/features/voting), a [roadmap](/features/roadmap), and a [changelog](/features/changelog) to practice the full loop. It is open source, so you can stand up your own instance, run AI triage, and reference real artifacts in an interview instead of hypotheticals.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How many rounds are in a PM interview?

Typically three to five: a recruiter screen, a hiring manager conversation, and two to three panel interviews covering product sense, analytical thinking, execution, and behavioral questions. Some companies add a case study or take-home assignment. The total process takes two to four weeks.

### What is the most common PM interview mistake?

Jumping to a solution before defining the problem. In product sense questions, spend at least 30% of your time understanding the user and the problem before proposing solutions. In analytical questions, spend time defining the metric before analyzing the data.

### Do I need a technical background for PM interviews?

Not usually, unless the role is specifically "Technical PM" or the company is engineering-led (Stripe, Linear, Vercel). Most PM interviews test product thinking, analytical reasoning, and communication skills. You should be able to discuss trade-offs with engineers, but you do not need to write code.

### How do I answer "Why this company?"

Be specific. "I love your product" is generic. "I have been using your product for six months and noticed that your roadmap prioritization seems to weight enterprise requests heavily — I would bring a more balanced approach using structured [feedback data](/features/feedback) from all segments" shows you have done your homework and have a point of view.

### How important is the estimation question?

Less important than product sense and execution. Estimation questions test structured thinking and comfort with numbers, not mathematical precision. Being within an order of magnitude and showing a clear decomposition is sufficient. Do not spend disproportionate prep time on estimation at the expense of product sense practice.

- [Best Customer Experience Software in 2026: 10 Tools Compared](https://quackback.io/blog/customer-experience-software): CX software is a broad category spanning feedback, analytics, support, and surveys. Here are 10 tools compared by what they actually do, what they cost, and who they are for.

Published: 2026-04-01

"Customer experience software" can mean almost anything. A feedback tool, an analytics platform, a help desk, a survey tool, and a journey mapping product all claim the CX label. The category is broad enough to be meaningless unless you know which problem you are solving.

![Customer experience software categories](/blog/customer-experience-software/hero.webp)

This guide breaks down the CX landscape into five categories, profiles ten tools across those categories, and helps you choose based on what you actually need — not what vendors want to sell you.

> The best customer experience software depends on which problem you are solving: feedback collection, support, analytics, surveys, or customer success. For structured product feedback, [Quackback](https://quackback.io) leads — open source and free to self-host, with AI-powered analysis and an MCP server. For support, Zendesk and Intercom dominate; for behavioral analytics, Hotjar and FullStory; for enterprise research, Qualtrics and Medallia.
>
> *Pricing last verified April 2026.*

The best CX tools ranked by category:

1. **[Quackback](https://quackback.io)** — Open source feedback collection with voting, AI analysis, and public roadmaps
2. **[Zendesk](/blog/zendesk-pricing)** — Full-stack support platform with help center, chat, and ticketing
3. **[Hotjar](https://hotjar.com)** — Heatmaps, session recordings, and feedback surveys for product teams
4. **[Intercom](/blog/intercom-pricing)** — Messaging-first platform combining support, marketing, and engagement
5. **[Pendo](/blog/pendo-pricing)** — Product analytics with in-app guides and feedback
6. **[Gainsight](https://gainsight.com)** — Customer success platform with health scoring and journey orchestration
7. **[Qualtrics](https://qualtrics.com)** — Enterprise experience management with advanced survey methodology
8. **[Medallia](https://medallia.com)** — Enterprise CX with omnichannel feedback capture and AI analytics
9. **[FullStory](https://fullstory.com)** — Digital experience analytics with session replay and frustration signals
10. **[HubSpot Service Hub](/blog/hubspot-pricing)** — CRM-native service tools for HubSpot-centric teams

## 1. Quackback

[Quackback](https://quackback.io) is open source (AGPL-3.0), self-hosted, and free. It focuses on the feedback layer of customer experience: collecting feature requests, organizing them with voting, analyzing patterns with AI, and communicating progress through a public roadmap and changelog.

Unlike enterprise CX platforms that try to do everything, Quackback does one thing well — structured product feedback. Users submit ideas through an embedded [widget](/features/widget) or public portal, vote on existing requests, and track status changes. The product team gets [AI-powered analysis](/blog/ai-customer-feedback-analysis) that surfaces trends, detects duplicates, and prioritizes by demand.

**Key features:**
- [Feedback boards](/features/feedback) with public voting
- [AI-powered analysis](/blog/ai-customer-feedback-analysis)
- [Public roadmap](/features/roadmap) and [changelog](/features/changelog)
- Embedded [feedback widget](/features/widget) for in-app collection
- [MCP server](/features/mcp) for AI agent integrations
- SSO/OIDC, role-based access, 25 integrations

**Pricing:** Free and open source. Self-host with Docker. No feature gates.

**Best for:** Product teams that want structured feedback collection and prioritization without enterprise CX complexity or SaaS pricing.

---

> **Try Quackback** — open source and self-hosted. Deploy in under five minutes with Docker.
> [Get started free](/docs) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. Zendesk

Zendesk is the most widely deployed support platform, covering ticketing, live chat, help center, and community forums. It is the backbone of customer support for companies from startups to enterprises.

**Key features:** Omnichannel ticketing (email, chat, phone, social), AI-powered agent assist, knowledge base with content cues, community forums, advanced reporting and analytics.

**Pricing:** Suite Team at $55/agent/month, Suite Growth at $89/agent/month, Suite Professional at $115/agent/month. Enterprise pricing is custom. See our [Zendesk pricing breakdown](/blog/zendesk-pricing).

**Strengths:** Mature ecosystem, deep marketplace of integrations, scalable from 5 agents to 5,000.

**Limitations:** Expensive at scale. The pricing jump between tiers gates features that many teams consider essential. The product has become complex — new teams face a significant learning curve.

**Best for:** Teams that need a full-featured support platform and are willing to pay for it.

## 3. Hotjar

Hotjar combines behavioral analytics (heatmaps, session recordings, funnel analysis) with lightweight feedback tools (surveys, feedback widgets). It shows you what users do and lets you ask why.

**Key features:** Heatmaps, session recordings, conversion funnels, feedback polls, surveys, user interviews.

**Pricing:** Basic is free (35 daily sessions). Plus at $32/month (100 daily sessions). Business at $80/month (500 daily sessions). Scale at $171/month (unlimited sessions). See our [Hotjar pricing breakdown](/blog/hotjar-pricing).

**Strengths:** Easy to set up (one script tag), visual analytics that non-technical teams can understand, the combination of quantitative behavior data and qualitative feedback in one tool.

**Limitations:** Not a product analytics replacement (no cohort analysis, no funnel comparisons over time). Feedback features are basic compared to dedicated feedback tools. Session recordings require significant storage.

**Best for:** Product and UX teams that want to understand user behavior visually and collect contextual feedback.

## 4. Intercom

Intercom is a messaging-first customer platform that combines live chat, help desk, chatbot, and proactive messaging. It positions itself as the alternative to separate tools for support, engagement, and marketing.

**Key features:** Live chat and messaging, AI chatbot (Fin), help center, proactive messages, product tours, email campaigns, ticketing.

**Pricing:** Essential at $29/seat/month. Advanced at $85/seat/month. Expert at $132/seat/month. AI features (Fin) charged per resolution at $0.99 each. See our [Intercom pricing breakdown](/blog/intercom-pricing).

**Strengths:** The messaging-first approach creates a modern support experience. Fin (AI chatbot) handles routine queries well. Strong in-app messaging capabilities for onboarding and engagement.

**Limitations:** Costs escalate quickly with AI resolution fees and seat pricing. The all-in-one approach means each individual capability is less deep than a best-of-breed alternative.

**Best for:** SaaS companies that want chat-first support with integrated engagement features.

## 5. Pendo

Pendo combines product analytics with in-app guides and user feedback. It is unique in connecting usage data (what users do) with sentiment data (what users say) in one platform.

**Key features:** Product usage analytics, in-app guides and tooltips, NPS and feedback surveys, session replay, roadmap planning.

**Pricing:** Custom pricing only. Typically $15,900-$47,000+ per year depending on MAU volume. See our [Pendo pricing breakdown](/blog/pendo-pricing).

**Strengths:** The combination of analytics and in-app guidance. You see which features are underused, then create targeted guides to drive adoption. Feedback data tied to usage data enables segment-specific insights.

**Limitations:** Expensive for the analytics-only use case (Mixpanel or Amplitude are cheaper). Feedback capabilities are less developed than dedicated feedback tools. Complex pricing model.

**Best for:** Enterprise product teams that want analytics, guidance, and feedback in one platform.

See how it compares: [Quackback vs Pendo](/compare/quackback-vs-pendo).

## 6. Gainsight

Gainsight is a customer success platform designed for B2B SaaS companies with dedicated CS teams. It focuses on retention, expansion, and customer health.

**Key features:** Customer health scores, journey orchestration, playbooks for at-risk accounts, success plans, NPS and CSAT surveys, revenue forecasting.

**Pricing:** Custom pricing only. Typically $30,000-$100,000+ per year. The platform is designed for companies with at least $10M ARR and a dedicated CS team.

**Strengths:** Deep customer success workflows. Health scoring that aggregates usage, sentiment, and support data. Playbook automation for at-risk accounts.

**Limitations:** Requires significant implementation effort. Expensive. Not appropriate for companies without a dedicated CS function. The product has a steep learning curve.

**Best for:** B2B SaaS companies with $10M+ ARR and a dedicated customer success team.

## 7. Qualtrics

Qualtrics is the enterprise standard for experience management across customers, employees, products, and brand. It offers the most sophisticated survey methodology and analytics in the market.

**Key features:** Advanced survey design with logic branching, experience management across four pillars (customer, employee, product, brand), AI-powered text analysis, predictive modeling, real-time dashboards.

**Pricing:** Starts at approximately $1,500/year for basic. Enterprise pricing is custom, typically $100,000+ per year.

**Strengths:** The most methodologically rigorous survey platform. Handles complex research designs that other tools cannot. Deep analytics and reporting.

**Limitations:** Expensive. Complex. Overkill for teams that need simple feedback collection. The platform requires training to use effectively.

**Best for:** Enterprise research teams that need advanced survey methodology and cross-functional experience management.

## 8. Medallia

Medallia is an enterprise CX platform focused on capturing feedback across every channel — web, mobile, social, in-store, contact center, IoT — and using AI to surface insights.

**Key features:** Omnichannel feedback capture, Athena AI for text and sentiment analysis, real-time alerting, journey analytics, action management workflows.

**Pricing:** Custom pricing only. Typically $100,000+ per year for enterprise deployments.

**Strengths:** Broad omnichannel capture across channels that most tools do not reach (IoT devices, physical locations, voice calls). AI analytics are well-developed for enterprise text and sentiment work.

**Limitations:** Enterprise-only pricing and complexity. Not appropriate for SMB or mid-market. Requires significant implementation investment.

**Best for:** Large enterprises with feedback touchpoints across digital and physical channels.

## 9. FullStory

FullStory is a digital experience analytics platform built around session replay. It captures every user interaction and uses AI to identify frustration signals, errors, and optimization opportunities.

**Key features:** Auto-captured session replay, frustration signals (rage clicks, dead clicks, error clicks), journey mapping, conversion funnels, heatmaps, AI-powered insights.

**Pricing:** Free tier (1,000 sessions/month). Business and Enterprise pricing is custom, typically $10,000-$50,000+ per year.

**Strengths:** Detailed session replay with auto-capture, so no manual event instrumentation is required. Frustration signals surface issues without requiring manual analysis.

**Limitations:** Privacy concerns with session recording (requires careful consent management). Not a replacement for traditional product analytics. Storage costs for high-traffic sites.

**Best for:** Product and UX teams that need detailed behavioral analysis to identify friction points and usability issues.

## 10. HubSpot Service Hub

HubSpot Service Hub is the support module within the HubSpot ecosystem. It works best for teams already using HubSpot CRM, Marketing, or Sales.

**Key features:** Ticketing, knowledge base, live chat, customer portal, NPS and CSAT surveys, team inbox, conversation intelligence.

**Pricing:** Free (basic ticketing). Starter at $20/seat/month. Professional at $100/seat/month. Enterprise at $150/seat/month. See our [HubSpot pricing breakdown](/blog/hubspot-pricing).

**Strengths:** Deep CRM integration. Customer context from marketing and sales is available to support agents. Good reporting that spans the full customer lifecycle.

**Limitations:** Expensive at Professional and Enterprise tiers. Mandatory onboarding fees. Feature gates between tiers. Best value only for teams already invested in the HubSpot ecosystem.

**Best for:** Teams already using HubSpot CRM that want support tools integrated with their existing customer data.

![CX software decision tree by primary need](/blog/customer-experience-software/decision-flowchart.webp)

## How to choose

| If your primary need is... | Start with... |
|---|---|
| Collecting and prioritizing product feedback | [Quackback](https://quackback.io) — open source, self-hosted, with AI-powered analysis |
| Help desk and ticketing | Zendesk or [Freshdesk](/blog/freshdesk-pricing) |
| Understanding user behavior visually | Hotjar or FullStory |
| Chat-first support with engagement | Intercom |
| Customer success and health scoring | Gainsight |
| Enterprise-grade survey research | Qualtrics or Medallia |
| CRM-integrated support | HubSpot Service Hub |

Most teams do not need one tool that does everything. They need two or three tools that each do their specific job well. A common stack: a feedback tool (for product input), a support tool (for customer issues), and an analytics tool (for behavioral data). Trying to consolidate everything into one platform usually means compromising on the capability you need most.

## Frequently asked questions

### What is customer experience software?

CX software is any tool that helps you understand, measure, or improve how customers experience your product or service. The category spans feedback collection, support ticketing, behavioral analytics, surveys, journey mapping, and customer success. Most companies use multiple tools across these subcategories.

### Do I need an enterprise CX platform?

Only if you have multiple products, thousands of customers, and feedback coming through diverse channels (digital, physical, voice). For most SaaS companies under 500 employees, a combination of a feedback tool, a support tool, and an analytics tool provides better coverage at lower cost than an enterprise platform.

### What is the cheapest CX software?

[Quackback](https://quackback.io) is free and open source for feedback. Hotjar has a free tier for basic analytics. Freshdesk has a [free tier](/blog/freshdesk-pricing) for support. Google Analytics 4 is free for web analytics. You can build a functional CX stack at zero cost using free tiers and open-source tools.

### How do I measure customer experience?

Three core metrics: [Customer Effort Score (CES)](/blog/customer-effort-score) for interaction ease, [CSAT](/blog/customer-satisfaction-survey-template) for satisfaction with specific experiences, and [NPS](/blog/nps-survey-template) for overall loyalty. Pair these with behavioral data (feature adoption, support ticket volume, churn rate) for a complete picture.

### Can I use multiple CX tools together?

Yes, and most teams should. A feedback tool collects product input. A support tool handles customer issues. An analytics tool tracks behavior. The key is integration — make sure your tools share data through APIs, webhooks, or native integrations so insights from one tool inform actions in another.

- [How to Improve Survey Response Rates: 9 Tactics That Work (2026)](https://quackback.io/blog/improve-survey-response-rates): Most surveys get a 15–25% response rate. Nine evidence-based tactics — from cutting length to choosing the right channel — consistently move that number up.

Published: 2026-04-01

Most surveys get ignored. The average email survey response rate sits around 20%, and for link-based surveys it drops as low as 6–15%. The gap between a survey that gets completed and one that gets skipped usually comes down to a handful of decisions you make before anyone sees the first question.

These nine tactics are backed by benchmark data and controlled experiments.

![Average survey response rates by channel — SMS and in-app lead, email links trail](/blog/improve-survey-response-rates/hero.webp)

> To improve survey response rates, shorten the survey to under 5 minutes, move it from email links to in-app or SMS, and trigger it at a specific moment such as post-purchase or post-support. These three structural decisions move the number more than any copy or design tweak. Add one or two reminders and close the loop publicly to lift response on every survey that follows.

## 9 ways to improve survey response rates

### 1. Shorten the survey

Survey length has the strongest experimental evidence of any tactic. In a [randomized controlled trial of survey length](https://pmc.ncbi.nlm.nih.gov/articles/PMC6208327/), the ultrashort version achieved a 64% response rate versus 51% for the long version. Across vendor benchmarks, response also drops sharply once a survey exceeds roughly 12 questions or 5 minutes.

Every question you remove is a question more people will answer.

Before sending, audit your question list. Cut anything you do not have a specific plan to act on. If you need detailed data, consider splitting your questionnaire — send different subsets of questions to different user segments and combine the results.

**Best for:** All survey types. The highest-return change for most teams.

### 2. Switch to in-app or SMS

Channel choice has a larger effect than any copy or design change you can make. Benchmarks for 2025–2026:

| **Channel** | **Typical response rate** |
|---|---|
| SMS / text | 30–50% |
| In-app (embedded widget) | 25–35% |
| Email (embedded, one-click) | 15–25% |
| Email (link to external page) | 6–15% |
| Web intercept / pop-up | 8–20% |

If you are sending a link-based email survey and wondering why response is low, the channel itself is a large part of the problem. In-app surveys — shown to users while they are actively using your product — remove the friction of opening a new tab, loading a page, and reconstructing context for an interaction they have already moved on from.

Tools like the [Quackback in-app widget](/features/widget) let you collect NPS, CSAT, and open-ended feedback directly inside your product, where response rates are consistently 2–4× higher than equivalent email link surveys. Because Quackback is [open source](https://github.com/quackbackio/quackback) and free to self-host, you can put the widget in front of every user.

**Best for:** Any team that has flexibility over which channel they use.

### 3. Embed rather than link

Even within email, presentation matters. An embedded one-click NPS (where users click their score directly in the email body) typically gets 15–25% response. A link to an external survey page drops to 6–15%.

Each additional step — click, new tab, page load, possible re-authentication — loses a meaningful share of respondents. For short transactional surveys like NPS or CSAT, embed the first question directly in the email and collect the rest on the confirmation page after the click.

**Best for:** Email-based NPS, CSAT, and CES surveys.

### 4. Send 1–2 well-timed reminders

A single reminder sent 3–5 days after the original invitation typically adds 20–40% more responses. A second reminder at day 7 adds more again. After two reminders, returns diminish sharply.

Reminders increase volume but do not reliably change who responds — so if representativeness matters, they help but are not a complete fix.

Keep reminders short. Do not resend the full original message. Acknowledge you already reached out, state why the response matters in one sentence, and give a direct link.

**Best for:** One-time research surveys, annual NPS programs.

### 5. Mobile-optimize

More than half of survey responses now come from mobile devices. Mobile-optimized surveys show roughly 10% higher completion rates compared to desktop-first designs. Conversational-style mobile surveys — one question at a time, large tap targets, no grid questions — can reach 80–85% completion in well-designed flows.

The practical checklist before sending: test on a real phone, use a single-column layout, remove all matrix/grid questions (they are nearly unusable on small screens), keep text fields optional or short.

**Best for:** Consumer surveys, post-purchase NPS, any survey distributed via SMS or in-app notification.

### 6. Time it to the moment of truth

The highest-converting surveys are triggered by a specific event: completing a purchase, finishing an onboarding flow, resolving a support ticket, reaching a usage milestone. Event-triggered surveys consistently outperform batch campaigns sent to your entire user base on a fixed schedule.

Timing within the event matters too. A post-support survey sent within an hour of ticket closure out-performs one sent the following morning. Users still have the experience in mind and give more accurate, more useful feedback.

The [Quackback feedback widget](/features/feedback) supports event-triggered prompts — you can fire a survey at any point in your product flow without code changes on every release. See the [docs](/docs) for how to wire triggers into your existing events.

**Best for:** Product teams, customer success, post-support workflows.

### 7. Personalize the invitation

[Personalized email subject lines increase open rates by roughly 26%](https://www.campaignmonitor.com/resources/knowledge-base/should-you-personalize-your-subject-lines/), which directly improves how many people see your survey invitation. Beyond the subject line: address recipients by name, reference the specific interaction or product they used, and explain in one sentence what you will do with the results.

Generic subject lines like "Share your feedback" perform significantly worse than "How was your onboarding last Tuesday?" — not because of the name, but because of the specificity. Specificity signals that this is a real request, not an automated blast.

**Best for:** Email-distributed surveys where you have contact data and interaction history.

### 8. Use prepaid incentives for critical research

For surveys where data quality is essential — pricing research, feature prioritization, hard-to-reach segments — monetary incentives can nearly double response rates. The key distinction: **prepaid (unconditional)** incentives outperform post-survey rewards or sweepstakes entries.

A small guaranteed reward outperforms a much larger sweepstakes prize in most experiments. A [meta-analysis of 46 randomized controlled trials](https://journals.plos.org/plosone/article?id=10.1371%2Fjournal.pone.0279128) found prepaid cash incentives substantially outperform both conditional rewards and lotteries. Sweepstakes are low-cost but largely ineffective; small guaranteed rewards reliably shift behavior.

The trade-off: incentives can shift sample composition, changing who responds. If you use them, note this when interpreting results and consider whether the shift matters for your specific question.

**Best for:** B2B surveys, hard-to-reach segments, high-stakes research where completion rate is the priority.

### 9. Close the loop publicly

If users do not believe their feedback leads to anything, they stop participating. Publicly acknowledging what you heard and what you changed is the most durable long-term investment in response rates.

A public [changelog](/features/changelog) that references user feedback — "We added X because users asked for it in our Q1 survey" — signals that participating is worth the effort. Teams that close the loop consistently report higher response rates on subsequent surveys. An [MCP server](/features/mcp) makes this loop easier to run: you can query, triage, and link feedback to shipped work directly from the AI tools you already use, so acting on responses does not depend on manual exports.

This is also the tactic that separates feedback programs from feedback theater. Closing the loop turns a one-way data collection exercise into a conversation.

**Best for:** Product teams running recurring feedback programs, NPS follow-up workflows.

## Which tactics to prioritize

![Survey improvement tactics plotted by impact and implementation effort](/blog/improve-survey-response-rates/tactics-matrix.webp)

Mapped by impact and effort, the nine tactics fall into four quadrants:

- **High impact, low effort (do first):** shorten the survey, add one or two reminders, mobile-optimize.
- **High impact, higher effort:** switch to in-app or SMS, time surveys to a specific event.
- **Lower impact, low effort:** embed rather than link, personalize the invitation.
- **Situational:** prepaid incentives for critical research, close the loop publicly as a long-term investment.

Start with the top-left: shortening your survey, adding a reminder, and mobile-optimizing are all low-effort changes that produce measurable lifts. These are the right first moves for any team.

Then address channel if you have flexibility. Moving from email links to in-app or SMS is the highest-impact structural change most product teams can make.

Incentives are worth considering if you need specific data from a hard-to-reach segment or a one-time critical study. Skip sweepstakes unless you have a specific reason to run one.

## What counts as a good survey response rate

A good survey response rate is roughly 20% or higher for email link surveys, 30% or higher for embedded email, and 40% or higher for in-app or SMS surveys, though the right benchmark depends heavily on channel and audience. Rough benchmarks for 2025–2026:

| **Survey type** | **Typical** | **Strong** |
|---|---|---|
| Email, link-based | 6–15% | 20%+ |
| Email, embedded | 15–25% | 30%+ |
| In-app / SMS | 25–40% | 50%+ |
| B2B relationship survey | 10–15% | 25%+ |
| B2C transactional NPS | 20–35% | 40%+ |

If you are below the typical range for your channel, audit length and timing first — these have bigger effects than question wording or visual design. If you are choosing a feedback tool to run these surveys, our [Quackback vs Canny](/compare/quackback-vs-canny) and [Quackback vs Featurebase](/compare/quackback-vs-featurebase) comparisons cover how in-app collection and pricing differ across the main options.

## Common mistakes that kill response rates

- **Sending too late.** A weekly batch job that sends post-purchase surveys 5–6 days later will consistently underperform a trigger that fires within the hour.
- **Requiring a new login or account.** Every additional authentication step loses a significant share of respondents before they see question one.
- **Asking for more than you will act on.** Users learn quickly when feedback goes nowhere. A 10-question survey where you act on 9 answers beats a 30-question survey where you act on 3.
- **No mobile testing.** Grid questions on mobile are nearly unusable. Test on a real device before you send to thousands of users.
- **Re-surveying too soon.** Survey fatigue is real. Wait at least 90 days before re-contacting the same user unless they have had a distinct new interaction.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is a good survey response rate?

For email link-based surveys, 15–20% is typical and 25%+ is strong. For in-app and SMS surveys, 25–40% is achievable in well-run programs. B2B surveys average 10–15%. Focus on your own trend over time rather than absolute benchmarks — a consistent upward trend matters more than hitting a specific number.

### How many reminder emails should I send?

One or two. The first reminder sent 3–5 days after the original invitation typically adds the most incremental responses. A second at day 7 adds some more. After that, diminishing returns set in quickly and you risk signal from annoyance rather than genuine engagement.

### Does survey length really matter that much?

Yes — it is the tactic with the strongest controlled experimental evidence. Moving from a 15-minute survey to a 5-minute survey can increase response by 10–25 percentage points. Keep surveys to 7–10 questions for transactional contexts, 15–20 for research contexts where respondents have chosen to participate.

### Should I offer a prize to increase responses?

Sweepstakes (one large prize) have weak evidence behind them. Prepaid incentives (small guaranteed rewards given before completion) have strong evidence and can roughly double response rates in some studies. If you are running a critical one-time study, a guaranteed $5–10 reward is more effective than a $500 sweepstakes.

### How much does channel choice affect response rates?

More than any other single factor after survey length. SMS and in-app surveys typically achieve 25–50% response. Email link surveys typically achieve 6–15%. If you are on email links and want to improve response, switching to in-app or embedded email is the highest-impact structural change available.

- [North Star Metric: How to Find and Track Yours in 6 Steps](https://quackback.io/blog/north-star-metric): A North Star Metric is the single number that captures the core value your product delivers. Learn how to find yours and build input metrics around it.

Published: 2026-04-01

If your team cannot name your North Star Metric in one sentence, you do not have one. And if you do not have one, every team is optimizing for something different.

![North Star Metric with four input metric dimensions](/blog/north-star-metric/hero.webp)

> A **North Star Metric (NSM)** is the single metric that best captures the core value your product delivers to customers. To find yours, identify the moment a customer receives value, pick one measurable proxy for it that leads revenue, then surround it with three to five input metrics each team can own. Validate the metric against historical data and revisit it quarterly.

The North Star Metric (NSM) is the single metric that best captures the core value your product delivers to customers. Sean Ellis — the Silicon Valley entrepreneur who coined "growth hacking" after driving breakout growth at Dropbox, LogMeIn, and Eventbrite — developed the concept in the early 2010s. Amplitude later formalized it into the North Star Framework, adding structure around input metrics and team alignment.

The purpose is simple: give every team a shared definition of success so that engineering, marketing, sales, and support are all pulling in the same direction.

## What makes a valid North Star Metric

A good NSM must pass three tests:

**1. It reflects customer value, not company value.** The NSM measures the value you deliver, not the revenue you extract. "Monthly recurring revenue" fails this test — MRR can increase through price hikes that harm customers. "Nights booked" (Airbnb) passes because every night booked represents real value for both guests and hosts.

**2. It correlates with revenue as a leading indicator.** The NSM is not a revenue metric, but it must predict revenue. When your NSM rises and holds, revenue should follow over the months that come after. If it does not, you are measuring the wrong thing. Validate this against your own historical data over a long enough window to see the lag — typically several months to a year.

**3. It is measurable and actionable across teams.** Every team should be able to see how their work connects to the NSM. Engineering ships features that drive it. Marketing acquires users who contribute to it. Support reduces friction that suppresses it. If the metric is too abstract for a team to act on, it is not actionable enough.

![North Star Metrics from six well-known companies](/blog/north-star-metric/company-examples.webp)

## Real company examples

| Company | North Star Metric | Why it works |
|---|---|---|
| **Spotify** | Time spent listening | Measures the value users receive; more listening correlates with subscription retention |
| **Airbnb** | Nights booked | Captures value for both sides of the marketplace |
| **Slack** | Daily messages sent | Signals Slack is the default communication tool; deeper usage correlates with team lock-in |
| **Netflix** | Hours of content watched per week | Engagement depth, not just logins — predicts retention |
| **Uber** | Number of trips | Unites rider and driver sides of the marketplace |
| **HubSpot** | Weekly active teams | Multi-user adoption correlates with retention and expansion |
| **Shopify** | Active merchants | Each active merchant represents ongoing GMV and platform stickiness |

**Patterns by business type:**
- **Marketplaces** (Airbnb, Uber): Transaction volume
- **Media and content** (Spotify, Netflix): Consumption metrics
- **Collaboration SaaS** (Slack, HubSpot): Team-level engagement
- **E-commerce platforms** (Shopify): Active entity counts

## The constellation model: NSM + input metrics

The NSM alone is not enough. You cannot directly move a North Star Metric — it is the result of many factors. What you can move are input metrics: three to five actionable measures that feed into the NSM.

Amplitude's framework uses four dimensions to identify input metrics:

| Dimension | What it measures | Example (Spotify) |
|---|---|---|
| **Breadth** | How many users take the key action | Number of active listeners |
| **Depth** | Extent of their engagement | Hours per listening session |
| **Frequency** | How often they engage | Sessions per week |
| **Efficiency** | How quickly they reach value | Time from signup to first playlist |

**Why input metrics matter:** "If you can move your North Star directly, it is probably not a good North Star." The NSM should be one level removed from direct action, forcing teams to think about the levers that drive it. Input metrics are those levers.

**Example constellation for a feedback tool.** This is the constellation we use to think about Quackback itself:

- **NSM:** Monthly active feedback contributors (users who submit, [vote](/features/voting), or comment)
- **Breadth input:** Number of workspaces with the [feedback widget](/features/widget) installed
- **Depth input:** Average feedback submissions per active user
- **Frequency input:** Weekly return rate of contributors
- **Efficiency input:** Time from widget installation to first feedback submission

Each input metric can be owned by a team. Marketing drives breadth. Product drives depth and efficiency. Customer success drives frequency. A public [roadmap](/features/roadmap) closes the loop — contributors who see their input shape what ships come back, which lifts the frequency input.

## How to find your North Star Metric

### Step 1: Start with customer value

Ask: "When does our customer receive the value they are paying for?" Not "When do we make money?" but "When does the customer's problem get solved?"

Talk to customers. Read [feedback submissions](/features/feedback). Analyze support conversations. The answer often emerges from how customers describe success in their own words.

### Step 2: Brainstorm candidates

Generate three to five candidate metrics based on what you learned. For a project management tool, candidates might be: tasks completed, active projects, team collaboration events, or weekly active users.

### Step 3: Evaluate against the three criteria

For each candidate:
- Does it increase only when customers receive more value?
- Does it correlate with revenue as a leading indicator? (Check historical data)
- Can every team connect their work to moving this number?

### Step 4: Pick one

The whole point is singular focus. If you have three North Stars, you have none. Pick the candidate that best balances all three criteria.

### Step 5: Define input metrics

Use the breadth/depth/frequency/efficiency framework to identify three to five input metrics. Assign ownership of each to a specific team.

### Step 6: Revisit quarterly

Your NSM should be stable, but not permanent. As your product and market evolve, the metric that best captures customer value may shift. Review quarterly and change if the correlation with revenue weakens.

![Example North Star constellation for a feedback tool](/blog/north-star-metric/constellation-example.webp)

## Common mistakes

### Choosing a vanity metric

Downloads, page views, and registered users look impressive in board meetings but do not reflect value delivery. A million downloads means nothing if nobody opens the app twice. Your NSM should measure ongoing value, not one-time events.

### Using revenue as your NSM

Revenue is the result of delivering value, not the measure of it. MRR, ARPU, and ARR are critical business metrics, but they are lagging indicators — by the time they move, the cause is months old. Your NSM should be a leading indicator that predicts revenue, not revenue itself.

### Picking multiple North Stars

Some frameworks argue for separate NSMs for acquisition, retention, and monetization. These are useful as complementary tracking, but they are not North Stars. The NSM is one number that the entire company rallies around. Multiple "North Stars" dilute focus and recreate the alignment problem the framework is supposed to solve.

### No decomposition into input metrics

"We are tracking monthly active users" without defining what drives MAU is a statement, not a strategy. Without input metrics, teams have no line of sight from their daily work to the outcome that matters. The constellation model — NSM plus input metrics with clear ownership — is what makes the framework actionable.

### Gaming the metric

Sending push notifications to inflate "daily active users" or discounting to pump "orders completed" may move the number temporarily but erodes trust and retention. If your NSM can be gamed without delivering more customer value, it is the wrong metric.

### Never evolving the metric

As your product and market change, so should your NSM. Mixpanel draws an analogy: when the Egyptians built the pyramids, Earth had a different North Star — Thuban. It has since drifted out of alignment, just as a metric can. Review your NSM quarterly and change it if it no longer reflects the core value your product delivers.

## How feedback connects to your NSM

Product [feedback](/features/feedback) plays three roles in the North Star framework:

**Finding your NSM.** If you struggle to articulate your NSM, customer interviews and feedback submissions are the starting point. Ask customers what success looks like. Their answers point toward the value your metric should capture.

**Diagnosing movement.** When your NSM dips, quantitative data tells you what changed. Feedback tells you why. A spike in negative feedback about onboarding explains a drop in the efficiency input metric. Without the qualitative signal, you are guessing at root causes. Quackback exposes your feedback through an [MCP server](/features/mcp), so you can ask an AI assistant to summarize what changed and surface themes behind a metric move.

**Preventing gaming.** Qualitative feedback acts as a check on metric gaming. If your NSM is rising but [customer sentiment](/blog/qualitative-vs-quantitative-feedback) is declining, something is wrong. The disconnect between the metric and the feeling is a red flag that the metric is no longer capturing real value.

---

> **Try Quackback** — open source with a managed cloud option. Collect feedback, run [voting](/features/voting), and ship a public [roadmap](/features/roadmap) so the input metrics behind your North Star stay grounded in real customer value.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How is a North Star Metric different from a KPI?

KPIs are departmental performance measures — marketing tracks lead volume, sales tracks conversion rate, support tracks resolution time. The NSM is a company-wide measure of customer value that all departments contribute to. KPIs feed into the NSM; the NSM provides the shared context that connects them.

### Can a small startup use the North Star framework?

Yes, and it is arguably more valuable for small teams. When you have five people, alignment is easy — everyone talks to each other. When you grow to twenty, then fifty, the NSM keeps teams aligned without requiring constant coordination. Start with the NSM early and evolve it as you learn more about your customers.

### How do I know if my NSM is working?

Two signals: First, does the NSM correlate with revenue over a twelve-month lookback? If it rises and revenue follows (with a lag), the metric captures real value. Second, can every team explain how their current work affects the NSM? If teams are confused about the connection, the metric is either wrong or under-communicated.

### What if my product serves multiple customer segments?

Pick the NSM that captures value for your primary segment. If you serve both enterprise and self-serve customers, the NSM should reflect the value delivered to both — which usually means focusing on product engagement rather than revenue (since revenue metrics weight enterprise disproportionately). Segment-specific metrics belong in your input metric constellation, not as competing North Stars.

### How often should I change my North Star Metric?

Rarely. A good NSM is stable for one to three years. Change it when: the correlation with revenue breaks down, your product strategy fundamentally shifts (new market, new positioning), or you discover a better proxy for customer value through [feedback analysis](/blog/ai-customer-feedback-analysis) and data review. Quarterly reviews should confirm the metric, not change it by default.

- [What Is an MCP Server? A Guide for Product Teams](https://quackback.io/blog/what-is-an-mcp-server): MCP servers connect AI agents to your tools. Learn what they are, how they work, and why product teams use them to automate feedback, roadmaps, and sprint planning.

Published: 2026-04-01

Most product managers have heard of MCP by now. The term shows up in release notes, AI tool documentation, and increasingly in conversations about how AI agents interact with the tools teams already use. But the explanations are almost always written for developers, filled with protocol diagrams and code snippets that do not help you understand what MCP means for your workflow.

This guide is different. It explains what an MCP server is, how it works, and why it matters — from the perspective of someone who manages products, not someone who builds protocols.

![What is an MCP server — AI agents connecting to product tools through MCP](/blog/what-is-an-mcp-server/hero.webp)

> An **MCP server** is a small program that connects an AI agent to one of your tools, exposing that tool's data and actions through the Model Context Protocol, an open standard created by Anthropic. It lets an AI assistant like Claude or Cursor read your feedback, roadmaps, and analytics, and take actions across them, without anyone writing custom integration code. Think of it as a USB-C port for AI: one universal connector instead of a custom cable for every tool.

## What is an MCP server

The **Model Context Protocol (MCP)** is an open standard created by Anthropic that defines how AI models connect to external tools and data sources.

An **MCP server** is a small program that sits between your tool (like a feedback board, project tracker, or analytics platform) and an AI agent (like Claude, Cursor, or ChatGPT). It translates your tool's capabilities into a format the AI can understand and use.

Think of it like a USB-C port. Before USB-C, every device had its own connector. You needed a different cable for your phone, your laptop, and your monitor. USB-C created a universal standard. MCP does the same thing for AI integrations. Instead of building a custom connection between every AI tool and every SaaS product, MCP provides a single protocol that works everywhere.

Here is what that looks like in practice. Without MCP, if you wanted Claude to read your feedback board, you would need to write custom code to call your tool's API, parse the response, and format it for the AI. With MCP, your tool exposes a server, Claude connects to it, and the AI can read your data immediately.

## How MCP servers work

An MCP server does three things:

1. **Exposes tools.** It declares a list of actions the AI can take — like "search feedback," "list feature requests," or "update a roadmap item." Each tool has a name, a description, and defined inputs.

2. **Handles requests.** When the AI decides it needs data from your tool, it calls the appropriate MCP tool. The server processes the request, fetches data from your tool's API or database, and returns the result.

3. **Returns structured data.** The AI receives clean, structured information it can reason about, summarize, or use to take further actions.

The AI agent decides *when* to use each tool based on context. If you ask Claude "What are the most requested features this month?" and it has access to your feedback board's MCP server, it will call the search or list tool, read the results, and summarize them for you. You do not tell it which API endpoint to hit. The AI figures that out from the tool descriptions.

### The three roles in an MCP system

| Role | What it does | Example |
|------|-------------|---------|
| **Host** | The application where you interact with the AI | Claude Desktop, Cursor, VS Code |
| **Client** | Manages the connection between host and server | Built into the host application |
| **Server** | Exposes your tool's data and actions to the AI | Quackback MCP server, Linear MCP, Jira MCP |

As a product manager, you interact with the host. The client and server work in the background. You type a question or instruction in Claude, and the MCP infrastructure handles the rest.

## Why product teams care about MCP

MCP is not just a developer tool. It changes how product managers interact with their data across multiple tools. Here is why that matters.

### Your data stays connected without custom code

Product teams typically use five to ten tools daily. A [feedback board](/features/feedback), a project tracker, an analytics platform, a CRM, a support tool. Each contains a slice of the information you need to make decisions. MCP lets an AI agent read from all of them in a single conversation.

Instead of opening five browser tabs and manually cross-referencing data, you ask your AI assistant a question and it pulls the relevant information from each tool.

### AI agents can take action, not just answer questions

MCP servers do not just expose read-only data. They can also expose write operations. An AI agent connected to your feedback tool's MCP server can:

- Search and filter feature requests by status, votes, or tags
- Summarize the top requests for a sprint planning meeting
- Update the status of a roadmap item from "planned" to "in progress"
- Draft a [changelog entry](/features/changelog) when a feature ships
- Link a support ticket to an existing feature request

This turns your AI assistant from a chatbot into a tool that operates across your product stack.

### The feedback loop gets faster

The biggest bottleneck in most product teams is not deciding what to build. It is the time between collecting feedback, organizing it, prioritizing it, building it, and telling users what shipped. MCP compresses that cycle.

When your AI agent can read your [feedback board](/features/feedback), check vote counts, scan your roadmap, and draft release notes — all in one interaction — the feedback loop that used to take days happens in minutes.

## MCP servers for product management

The MCP ecosystem is growing fast. Here are the categories of MCP servers most relevant to product teams:

### Feedback and roadmap tools

These let AI agents read customer feedback, feature requests, voting data, and roadmap status.

[Quackback](/features/mcp) ships with a built-in MCP server that exposes tools covering boards, posts, votes, comments, roadmap items, and changelog entries. Because it is built into the product (not a third-party wrapper), it stays in sync with every release. It works the same whether you run [Quackback Cloud](/pricing) or self-host the open source build, so connecting your whole team is straightforward.

Other feedback tools have third-party MCP servers built by the community. Canny and Productboard both have community-maintained servers on GitHub. The difference is that third-party servers can fall behind the official API, while a built-in server is always current.

For a deeper look at how this works in practice, see [MCP Server for Feedback Management](/blog/mcp-server-feedback-management).

### Project tracking

Linear, Jira, Asana, and ClickUp all have MCP servers. These let AI agents read issues, update statuses, create tickets, and query sprint data. Combined with a feedback tool MCP server, an AI agent can trace a feature request from user submission through your roadmap to the shipped issue in your tracker.

### Analytics and monitoring

PostHog, Amplitude, and other analytics platforms are adding MCP support. This lets AI agents pull usage data, conversion metrics, and behavioral patterns directly into conversations about what to build next.

### Communication

Slack and email MCP servers let AI agents draft messages, search conversation history, and post updates. Useful for automating status updates to stakeholders when roadmap items change.

## How to set up an MCP server

Setting up an MCP server does not require writing code. Most servers install through a configuration file that tells your AI host where to find the server.

### Step 1: Choose your AI host

The most common hosts for product managers are:

- **Claude Desktop** — Anthropic's desktop app, supports MCP natively
- **Claude Code** — Anthropic's CLI tool, ideal if you also write code
- **Cursor** — AI code editor popular with technical PMs

### Step 2: Install the MCP server

Each tool publishes its own installation instructions. For example, Quackback's MCP server is HTTP-based (Streamable HTTP) and runs as part of your self-hosted instance. To connect it to Claude Code, run:

```bash
claude mcp add --transport http --scope user quackback https://your-quackback-instance/api/mcp
```

Claude Code handles the OAuth authentication flow automatically — it opens your browser, you log in to your Quackback instance, and the connection is established. If you prefer API key authentication, add the `--header` flag:

```bash
claude mcp add --transport http --scope user -H "Authorization: Bearer qb_YOUR_API_KEY" quackback https://your-quackback-instance/api/mcp
```

API keys use the `qb_` prefix followed by 48 hex characters. You can generate one from your Quackback settings under Developers. No custom code required.

### Step 3: Start using it

Once connected, you interact with your tools through natural language. Ask Claude:

- "What are the top 10 most-voted feature requests?"
- "Summarize the feedback we received this week"
- "Move the 'dark mode' request to 'in progress' on the roadmap"
- "Draft a changelog entry for the features we shipped this sprint"

The AI reads the tool descriptions from the MCP server, decides which tools to call, and executes the request.

For a step-by-step walkthrough with screenshots, see the [Quackback MCP integration guide](/integrations/mcp).

## Real examples: MCP in a product workflow

Here is how a product manager might use MCP-connected tools in a typical week.

### Monday: Sprint planning

You open Claude and ask: "What are the highest-voted feature requests that are not on the roadmap yet?" The AI queries your [feedback board](/features/feedback) via MCP, cross-references against your [roadmap](/features/roadmap), and returns a prioritized list with vote counts and customer segments.

### Wednesday: Stakeholder update

You ask: "Summarize the feedback trends from the past two weeks and draft a Slack message for the product team." The AI reads recent feedback, identifies patterns, and drafts a concise update you can review and send.

### Friday: Ship and close the loop

A feature ships. You tell the AI: "We just shipped dark mode. Update the roadmap item to 'complete,' draft a changelog entry, and notify the users who requested it." The AI executes three actions across your feedback tool, [roadmap](/features/roadmap), and [changelog](/features/changelog) — tasks that would normally take 15 minutes of switching between tools.

## MCP vs traditional API integrations

| | Traditional API | MCP Server |
|---|---|---|
| **Setup** | Write code for each integration | One config line per tool |
| **Discovery** | Read API docs, build requests | AI discovers tools automatically |
| **Maintenance** | Update code when APIs change | Server maintainer handles updates |
| **Interaction** | Code or Zapier/Make workflows | Natural language in your AI assistant |
| **Flexibility** | Fixed workflows you define | AI decides which tools to use based on context |

MCP does not replace APIs. Your MCP server still uses the underlying API to communicate with your tool. The difference is that you never interact with the API directly. The AI does that for you.

## What to look for in an MCP server

Not all MCP servers are equal. When evaluating an MCP server for your product stack, consider:

**Coverage.** Does it expose the operations you need? A server with read-only access to feature requests is less useful than one that also supports status updates, vote queries, and changelog publishing.

**Maintenance.** Is it built into the product or maintained by a third party? Built-in servers stay current with every release. Third-party servers may lag behind API changes.

**Security.** How does authentication work? Does the server require API keys, OAuth tokens, or session credentials? Can you scope permissions to read-only if needed?

**Documentation.** Does each tool have clear descriptions? The AI uses these descriptions to decide when and how to call each tool. Poor descriptions lead to poor AI behavior.

Quackback's MCP server is HTTP-based (Streamable HTTP) and exposes tools and resources across [feedback boards](/features/feedback), [voting](/features/voting), [roadmaps](/features/roadmap), [changelogs](/features/changelog), and the [admin inbox](/features/inbox). It authenticates via API key (`qb_` format) or OAuth and supports both read and write operations. See the full [MCP documentation](/docs/mcp) for details.

## The MCP ecosystem is growing fast

The Model Context Protocol launched in late 2024. In its [first-year ecosystem update](https://www.anthropic.com/news/model-context-protocol), Anthropic reported more than 10,000 active public MCP servers, and community directories list thousands more. Major platforms — Google Cloud, Cloudflare, Figma, Atlassian — have published their own MCP servers or integration guides.

For product teams, this means the tools you already use are becoming AI-accessible. The question is not whether to adopt MCP, but which tools in your stack support it and how to connect them.

The highest-leverage starting point for most product teams is connecting their feedback tool. That is where user intent lives — the raw signal about what to build, fix, and improve. When your AI agent can read that signal directly, every downstream decision gets better.

Quackback is built for that starting point. Its [MCP server](/features/mcp) ships in every instance, so an AI agent can read and act on your feedback as soon as you connect it. Compare how that built-in approach stacks up against community wrappers in [Quackback vs Canny](/compare/quackback-vs-canny) and [Quackback vs Productboard](/compare/quackback-vs-productboard).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What does MCP stand for?

MCP stands for Model Context Protocol. It is an open standard created by Anthropic that lets AI models connect to external tools and data sources through a universal interface.

### Is an MCP server the same as an API?

No. An API requires you to write code for each integration. An MCP server exposes tools in a standardized format that any AI agent can discover and use automatically, without custom code. The MCP server itself uses the underlying API internally, but you never interact with it directly.

### Do I need to be a developer to use MCP servers?

No. Most MCP servers connect through a short JSON config entry. Product managers use them through AI assistants like Claude, Cursor, or ChatGPT without writing code.

### Which AI tools support MCP?

Claude Desktop, Claude Code, Cursor, Windsurf, Cline, and many others support MCP natively. The ecosystem is growing rapidly since the protocol launched in late 2024.

### Does Quackback have an MCP server?

Yes. Quackback ships with a built-in HTTP-based (Streamable HTTP) MCP server as part of every self-hosted instance. It exposes tools and resources for reading feedback, managing feature requests, updating roadmaps, and publishing changelog entries. Connect to it at `your-instance/api/mcp` using an API key (`qb_` format) or OAuth. It works with Claude, Cursor, and any MCP-compatible client. Learn more about the [Quackback MCP integration](/features/mcp).

- [Customer Effort Score (CES): What It Is and How to Measure It](https://quackback.io/blog/customer-effort-score): Customers do not reward you for exceeding expectations. They punish you for making things hard. Here is how to measure effort with CES and reduce it.

Published: 2026-03-31

Customers do not want to be delighted. They want things to be easy.

![Customer Effort Score scale from 1 to 7](/blog/customer-effort-score/hero.webp)

That is not a motivational poster. It is the conclusion of a Harvard Business Review study of 75,000 customer interactions. The researchers found that exceeding expectations had almost no impact on loyalty. What mattered was reducing friction. The study, titled "Stop Trying to Delight Your Customers," led to the creation of Customer Effort Score (CES) — a metric designed to measure how easy or difficult it is for customers to get what they need.

## What CES measures

CES measures the effort a customer expends to complete a specific interaction with your company. Not their overall satisfaction. Not their loyalty. Just how easy or hard one particular interaction was.

This makes CES fundamentally different from NPS and CSAT:

| | CES | CSAT | NPS |
|---|---|---|---|
| **Measures** | Effort to complete a task | Satisfaction with an interaction | Likelihood to recommend |
| **Scope** | One specific interaction | One specific interaction | Overall relationship |
| **Question** | "[Company] made it easy for me to handle my issue" | "How satisfied were you?" | "How likely are you to recommend us?" |
| **Scale** | 1-7 (disagree to agree) | 1-5 (unsatisfied to satisfied) | 0-10 |
| **Predicts** | Churn and disloyalty | Short-term satisfaction | Revenue growth |
| **Predictive power** | 1.8x more than CSAT for loyalty | Moderate | High for revenue |

The key finding: CES is 1.8 times more predictive of customer loyalty than CSAT and twice as predictive as NPS. Effort is a better proxy for whether someone will stay or leave than how happy or how likely to recommend they say they are.

For a deeper comparison with CSAT and NPS, including survey templates for each, see our guides on [CSAT surveys](/blog/customer-satisfaction-survey-template) and [NPS surveys](/blog/nps-survey-template).

## The CES question and scale

The current standard (CES 2.0) uses a statement format:

> "[Company name] made it easy for me to [handle my issue / complete my purchase / get started]."

Respondents rate their agreement on a 7-point scale:

1. Strongly Disagree
2. Disagree
3. Somewhat Disagree
4. Neither Agree nor Disagree
5. Somewhat Agree
6. Agree
7. Strongly Agree

**Calculation:** CES = Sum of all scores / Number of responses

A CES of 5.0 or above is generally good. A CES of 6.0 or above is excellent. Below 4.0 signals significant friction and high churn risk.

**Best practice:** Pair the CES rating with one open-ended follow-up: "What could we have done to make this easier?" This gives you the score for tracking and the context for fixing.

## When to deploy CES surveys

CES surveys must be triggered by a specific interaction, not sent on a schedule. Context decays quickly — a survey sent five minutes after a support resolution captures more accurate data than one sent three days later.

### After support interactions

The highest-value touchpoint for CES. Trigger immediately after a support ticket is resolved or a live chat ends.

**Question:** "[Company] made it easy for me to resolve my issue."

### After onboarding

Trigger after a user completes onboarding or reaches a defined activation milestone.

**Question:** "[Company] made it easy for me to get started."

### After self-service

Trigger after a user visits your help center, knowledge base, or [self-service help center](/blog/self-service-help-center).

**Question:** "Was it easy to find the information you needed?"

### After key feature interactions

Trigger after a user completes a critical workflow for the first time.

**Question:** "How easy was it to use [feature name]?"

### After purchase or checkout

Trigger immediately after purchase completion.

**Question:** "[Company] made it easy for me to complete my purchase."

![High effort vs low effort: the dramatic loyalty gap](/blog/customer-effort-score/loyalty-impact.webp)

## What the data says about effort and loyalty

The Gartner/CEB research that underpins CES is among the most cited in customer experience:

- **96%** of customers with high-effort experiences become disloyal
- Only **9%** of customers with low-effort experiences become disloyal
- **94%** of low-effort customers intend to repurchase
- **88%** of low-effort customers intend to increase spending
- Only **4%** of high-effort customers intend to increase spending
- **81%** of high-effort customers plan to spread negative word-of-mouth
- Low-effort experiences reduce repeat calls by **40%**, escalations by **50%**, and channel switching by **54%**

The asymmetry is striking. Reducing effort from high to low flips the loyalty equation almost entirely. The business case for measuring and reducing effort is one of the strongest in customer experience.

![CES vs CSAT vs NPS — three complementary metrics](/blog/customer-effort-score/ces-vs-nps-vs-csat.webp)

## How to improve CES scores

### Reduce channel switching

Every time a customer is forced to switch channels — from chat to phone, from email to a form, from self-service to a ticket — effort increases. Let customers resolve issues in the channel they started in.

### Achieve first-contact resolution

Train support teams to resolve issues in one interaction. The Gartner data shows first-contact resolution reduces repeat calls by 40%, escalations by 50%, and channel switching by 54%. This is the single highest-leverage improvement for CES.

### Invest in self-service

FAQ pages, [knowledge bases](/blog/self-service-help-center), in-app help, and chatbots let customers solve problems without waiting for a human. Most customers prefer self-service when it works. The key phrase is "when it works" — a bad self-service experience (irrelevant search results, outdated articles, broken links) is worse than no self-service at all.

### Eliminate repetition

Do not make customers repeat their issue to multiple agents. Pass context between channels and agents automatically. If a customer explained their problem in chat, the phone agent should already know what happened.

### Simplify processes

Count the number of steps to complete any task — checkout, returns, account setup, feature configuration. Then reduce them. Every unnecessary step is effort. Every unnecessary form field is effort. Audit for redundancy.

### Be proactive

Anticipate common issues and address them before the customer has to ask. Proactive notifications, status updates, and known-issue banners reduce inbound effort. A [changelog](/features/changelog) that tells customers about fixes before they notice the problem is effort prevention.

### Close the loop on CES feedback

When a customer reports high effort, follow up. Fix the root cause. Track CES by touchpoint to identify which interactions generate the most friction. A [feedback system](/features/feedback) that connects CES responses to specific product areas makes it possible to prioritize improvements by the effort they create.

## CES benchmarks

There is no universal cross-industry benchmark because scales, wording, and industries vary. The most useful approach is to track your own CES over time and benchmark against yourself.

That said, general guidelines on a 7-point scale:

| Score range | Interpretation |
|---|---|
| **6.0-7.0** | Excellent — low friction, high loyalty |
| **5.0-5.9** | Good — room for improvement but not alarming |
| **4.0-4.9** | Mediocre — noticeable friction, improvement needed |
| **Below 4.0** | Poor — high effort, high churn risk |

**By industry:** SaaS and e-commerce tend to score higher (more automation, fewer handoffs). Healthcare, government, and complex B2B services score lower (more process, more human involvement).

**Trending matters more than absolute score.** A CES of 5.2 improving to 5.6 over a quarter is a better signal than a static 6.0. Look for directional movement, not a magic number.

## Frequently asked questions

### When should I use CES instead of NPS or CSAT?

Use CES when you want to measure the ease of a specific interaction (support resolution, onboarding, feature use). Use CSAT when you want to measure satisfaction with a specific experience. Use NPS when you want to measure overall loyalty and likelihood to recommend. Many teams use all three for different touchpoints. CES is most valuable for identifying friction points that drive churn.

### What is a good CES score?

On a 7-point scale, 5.0 or above is good and 6.0 or above is excellent. More important than the absolute number is the trend — improving CES over time correlates with improving retention. Track CES by touchpoint to identify which interactions create the most friction.

### How many responses do I need for a reliable CES score?

A minimum of 100 responses gives you a statistically meaningful average. For touchpoint-level analysis (CES for support vs. CES for onboarding), you need 100 responses per touchpoint. If you are just starting, focus on your highest-volume touchpoint first.

### Should CES replace CSAT and NPS?

No. CES measures effort, CSAT measures satisfaction, and NPS measures loyalty. They are complementary, not competing. The strongest customer experience programs use CES for transactional interactions, CSAT for experience quality, and NPS for strategic direction. Start with CES if you suspect friction is your main retention problem.

### How do I reduce CES without increasing support costs?

The most effective CES improvements actually reduce costs: better self-service content deflects tickets, first-contact resolution reduces repeat contacts, and proactive communication prevents issues from becoming support requests. Reducing effort for customers and reducing cost for the company are usually the same thing.

- [Go-to-Market Strategy Template for SaaS Teams (2026)](https://quackback.io/blog/go-to-market-strategy-template): A GTM strategy answers three questions: who is this for, why should they care, and how will they find out. Here is a practical template you can fill out today.

Published: 2026-03-31

A go-to-market strategy is not a marketing plan. It is the bridge between building something and getting it into the hands of people who will pay for it.

![Go-to-market strategy: audience, value, channels](/blog/go-to-market-strategy-template/hero.webp)

Most SaaS teams build first and figure out distribution later. The result is a good product that nobody knows about, positioned for an audience that does not exist, priced in a way that does not match how customers buy. A GTM strategy forces you to answer the hard questions before you launch — not after.

This template covers the six components of a SaaS GTM strategy with practical guidance for each. It works for new products, new features, new markets, and pricing changes.

## The GTM template

### 1. Target audience

**Who is this for?** Be specific. "SaaS companies" is not a target audience. "Product managers at B2B SaaS companies with 50-500 employees who currently track feature requests in spreadsheets" is.

**Define your Ideal Customer Profile (ICP):**

| Dimension | Your answer |
|---|---|
| Company size (employees) | |
| Industry or vertical | |
| Annual revenue range | |
| Tech stack or tool usage | |
| Pain point or trigger event | |
| Decision maker role | |
| Budget authority | |

**Define your buyer personas (2-3 max):**

For each persona, document:
- Job title and reporting structure
- Daily workflow and tools used
- Primary pain point your product solves
- How they currently solve the problem (the alternative you are replacing)
- What success looks like for them
- How they evaluate and buy software (self-serve, sales-assisted, procurement)

### 2. Value proposition

**Why should they care?** Your value proposition is the intersection of what your product does, what the customer needs, and what competitors do not offer.

**Template:**

> For [target persona] who [pain point or situation], [product name] is a [category] that [key benefit]. Unlike [primary alternative], we [key differentiator].

**Example:**

> For product managers who lose feature requests across Slack, email, and support tickets, Quackback is an open-source feedback tool that centralizes requests with voting and AI-powered analysis. Unlike Canny or Productboard, you own your data.

**Test your value proposition:** Can a stranger read it and understand (a) who it is for, (b) what it does, and (c) why it is different? If any of those are unclear, revise.

### 3. Positioning and messaging

**How do you want to be perceived?** Positioning is the mental space you occupy in the customer's mind relative to alternatives.

**Positioning dimensions:**

| Dimension | Your position |
|---|---|
| Category | What type of product are you? (e.g., "feedback management tool") |
| Primary competitor | Who do customers compare you to? |
| Key differentiator | What do you do that they do not? |
| Price position | Are you cheaper, comparable, or premium? |
| Target segment | Enterprise, mid-market, SMB, or developer? |

**Messaging hierarchy:**
1. **Headline** — one sentence that captures the primary benefit
2. **Subheadline** — one sentence that adds specificity or addresses a common objection
3. **Three pillars** — the three most important capabilities, each with a one-sentence description
4. **Proof points** — customer quotes, metrics, case studies, or social proof

![Four SaaS growth motions: PLG, Sales-Led, Content-Led, Community-Led](/blog/go-to-market-strategy-template/four-growth-motions.webp)

### 4. Channel strategy

**How will they find out?** Choose channels based on where your target audience already spends time, not where you want them to be.

#### Product-led growth (PLG)

The product is the primary acquisition channel. Users sign up, experience value, and convert to paid without talking to sales.

**Works when:** The product delivers value quickly (minutes, not months), the price point is low enough for self-serve purchasing, and the user and buyer are the same person.

**Tactics:** Free tier or trial, in-product onboarding, viral loops (inviting teammates), community and word-of-mouth, content marketing for organic discovery.

**Examples:** Slack, Notion, Figma, Linear.

#### Sales-led growth

Sales teams drive acquisition through outbound prospecting, demos, and relationship building.

**Works when:** The price point justifies sales involvement ($10K+ ACV), the buying process involves multiple decision-makers, and the product requires customization or integration.

**Tactics:** Outbound email, LinkedIn outreach, conference networking, partner referrals, sales engineering demos.

**Examples:** Salesforce, Workday, Pendo.

#### Content-led growth

Educational content drives organic traffic that converts to product signups.

**Works when:** Your target audience actively searches for solutions to the problems you solve, the sales cycle involves research, and you can produce content at a quality level that ranks.

**Tactics:** SEO blog content, comparison pages, template resources, webinars, podcasts, [changelog](/features/changelog) as content.

**Examples:** HubSpot, Ahrefs, Buffer.

#### Community-led growth

A community of users and advocates drives awareness and adoption through peer recommendations.

**Works when:** Your product serves a passionate niche, users benefit from connecting with each other, and your category has a strong practitioner community.

**Tactics:** User forums, Slack or Discord communities, user conferences, ambassador programs, open source contributions.

**Examples:** Figma, dbt, Notion.

**Most SaaS companies use a combination.** A PLG company still needs content for organic discovery. A sales-led company still benefits from a free trial that lets prospects experience the product before a demo. Choose your primary motion and supplement with secondary channels.

### 5. Pricing strategy

**How will they pay?** Pricing is a GTM decision, not just a finance decision. It determines your acquisition channel (self-serve vs sales-assisted), your customer segment (SMB vs enterprise), and your expansion model (seat-based, usage-based, or feature-gated).

**Key pricing decisions:**

| Decision | Options |
|---|---|
| Billing model | Per seat, per usage, flat rate, freemium |
| Free tier | Yes / No / Trial only |
| Annual vs monthly | Annual discount incentive or monthly only |
| Self-serve checkout | Yes (PLG) / No (sales-assisted) / Both |
| Pricing page transparency | Published prices / "Contact sales" |

For a deep dive into how SaaS companies price their products, see our [feedback tool pricing comparison](/blog/feedback-tool-pricing-comparison).

### 6. Launch timeline

**When and how will you go to market?** A realistic timeline for a SaaS GTM execution:

| Week | Activity |
|---|---|
| **Weeks 1-2** | Finalize ICP, personas, and value proposition. Validate with 5-10 customer interviews. |
| **Weeks 3-4** | Build messaging, positioning, and channel plan. Create sales enablement materials. |
| **Weeks 5-6** | Prepare launch assets: landing page, blog post, email sequences, demo video. |
| **Week 7** | Beta launch to early access group. Collect [feedback](/features/feedback). |
| **Week 8** | Public launch. Execute across all channels. Monitor and iterate. |

For a detailed launch execution plan, see our [product launch checklist](/blog/product-launch-checklist).

## GTM for different scenarios

### New product

Full GTM required. All six components above need to be defined from scratch. The highest risk is targeting the wrong audience — validate your ICP with customer interviews before investing in channels.

### New feature

Lighter GTM. Your audience, positioning, and channels already exist. Focus on: which customer segment benefits most, how to communicate the value to existing customers ([changelog](/features/changelog), email, in-app), and whether the feature changes your competitive positioning.

### New market

Medium GTM. Your product exists, but your audience and positioning may need to change. A product that sells to startups in the US may need different messaging, pricing, and channels to sell to enterprises in Europe.

### Pricing change

Targeted GTM. Focus on: communicating the change to existing customers (transparency matters more than spin), updating all public-facing pricing pages, and retraining sales on the new model.

## Validating your GTM with feedback

The riskiest assumption in any GTM strategy is that you understand what your audience wants. [Customer feedback](/blog/collect-customer-feedback) validates or invalidates that assumption before you scale.

**Before launch:** Run your value proposition by 5-10 people in your target audience. Do they understand it? Does it resonate? Do they identify with the pain point? If not, revise before investing in channels.

**During beta:** Collect feedback from early users through a [feedback widget](/features/widget) or [board](/features/feedback). What do they love? What confuses them? What is missing? Beta feedback shapes your launch messaging — if every beta user mentions the same benefit, lead with that.

**After launch:** Monitor [feedback](/features/feedback) for patterns. If customers describe your product differently than your messaging does, listen to them. Their language is often better than yours because it reflects how they actually think about the problem.

## Common GTM mistakes

**Targeting everyone.** A GTM strategy that targets "all SaaS companies" is a GTM strategy that targets nobody. Narrow your ICP until it feels uncomfortably specific. You can expand later.

**Leading with features instead of outcomes.** Customers do not buy features. They buy outcomes. "AI-powered feedback analysis" is a feature. "Know what your customers want without reading 500 tickets" is an outcome.

**Choosing channels before understanding the audience.** "We should be on TikTok" is not a strategy. It is a guess. Choose channels where your audience already spends time, not channels that are trending.

**Skipping the pricing conversation.** Pricing determines everything downstream — acquisition channel, customer segment, sales motion, and unit economics. Decide pricing early, not after launch.

**No feedback loop.** A GTM strategy is a hypothesis. It needs to be tested and refined based on what happens when real customers encounter your product. Build [feedback collection](/blog/collect-customer-feedback) into your launch plan from day one.

## Frequently asked questions

### How long does it take to build a GTM strategy?

Four to eight weeks for a new product, including customer validation. Two to four weeks for a new feature or market. One to two weeks for a pricing change. The research and validation phases take longer than the documentation.

### Do I need a GTM strategy for a feature launch?

A lightweight one, yes. You need to know which customers benefit, how to communicate the value, and how to measure success. You do not need a full ICP exercise or channel strategy — those already exist. See our [product launch checklist](/blog/product-launch-checklist) for the feature-launch version.

### What is the difference between a GTM strategy and a marketing plan?

A GTM strategy defines who your customer is, what your value proposition is, and which channels you will use to reach them. A marketing plan is the tactical execution of the channel strategy — specific campaigns, content calendars, ad budgets, and performance targets. GTM comes first; the marketing plan follows.

### How do I choose between PLG and sales-led?

It depends on your average contract value (ACV) and buying complexity. Products under $10K ACV with a single decision-maker work well with PLG. Products over $50K ACV with multiple stakeholders typically need sales-led. Products in between often use a hybrid: PLG for acquisition and sales for expansion.

### How do I know if my GTM strategy is working?

Track three metrics: customer acquisition cost (CAC) by channel, time-to-first-value for new users, and conversion rate from free to paid (for PLG) or from demo to close (for sales-led). If CAC is rising, your targeting or channel mix needs adjustment. If time-to-first-value is high, your onboarding or product experience needs work.

- [How to Build a Self-Service Help Center for Your SaaS (2026)](https://quackback.io/blog/self-service-help-center): A self-service help center deflects support tickets and helps users solve problems on their own. Here is how to build one that people actually use.

Published: 2026-03-31

Most support tickets should never have been filed. The user just could not find the answer on their own.

![Self-service help center vs support ticket queue](/blog/self-service-help-center/hero.webp)

> A **self-service help center** is a searchable collection of articles, guides, and FAQs that lets customers solve problems on their own without contacting support. Build one by covering your top 20 to 30 most-asked questions first, organizing articles by user goal, investing in search, and measuring ticket deflection. The result is fewer tickets, faster time-to-value, and a support team free to handle the problems that need a human.

Research consistently shows that the majority of customers prefer self-service over contacting support. Gartner found that [70% of customers use self-service channels at some point in their resolution journey](https://www.gartner.com/en/customer-service-support/trends/improving-self-service-containment-from-search-to-resolution). Forrester found that [web self-service surpassed the phone as the most-used customer service channel](https://go.forrester.com/blogs/16-01-28-online_self_service_dominates_yet_again_why_its_an_effortless_way_to_get_to_your_answers/) — ahead of email, phone, and chat. The numbers are not surprising. Waiting for a support response is slow. Finding the answer yourself is instant.

A well-built help center does not just reduce ticket volume. It improves customer satisfaction, shortens time-to-value for new users, and frees your support team to focus on complex problems that actually require human judgment.

Here is how to build one that works.

## What belongs in a help center

Not everything needs an article. A help center is not a documentation dump — it is a curated set of resources that answer the questions users actually ask.

### Getting started guides

The highest-impact content you can write. New users who struggle with setup are the most likely to file support tickets and the most likely to churn. A getting started guide that walks through initial configuration, first-time setup, and core workflows prevents both.

Structure it as a sequence, not a reference. "Step 1: Create your workspace. Step 2: Invite your team. Step 3: Configure your first board." Users should be able to follow it linearly from zero to productive.

### Feature documentation

Each major feature gets its own article covering what it does, how to use it, and common configuration options. Keep these focused on practical usage, not marketing language. Users reading help articles have already bought the product — they need instructions, not persuasion.

Include screenshots sparingly. Screenshots break every time you update your UI, and maintaining them is expensive. Use them for complex workflows where text alone is ambiguous. Skip them for simple actions like clicking a button.

### Troubleshooting guides

Structured around symptoms, not features. Users do not search for "configure SAML SSO" when SSO is broken. They search for "login not working" or "cannot sign in." Write troubleshooting articles from the user's perspective: start with the symptom, list possible causes, and walk through each fix.

The best troubleshooting guides follow a decision tree format: "If you see error A, try X. If that does not work, check Y. If you see error B instead, the problem is Z."

### FAQ and common questions

Short, direct answers to the questions your support team gets asked repeatedly. If your support team answers the same question five times a week, that question belongs in the help center. Review your support ticket data quarterly and convert the most common questions into FAQ entries.

### API and developer documentation

If your product has an API, developer docs belong in or adjacent to your help center. Developers are the most self-service-oriented audience — they strongly prefer documentation over support tickets. Include authentication guides, endpoint references, code examples, and error code explanations.

## Structuring your help center

![Help center information architecture with six top-level categories branching into articles](/blog/self-service-help-center/help-center-ia.webp)

### Information architecture

Organize articles by user goal, not by product feature. Users do not think in terms of your navigation menu. They think in terms of what they are trying to accomplish.

| Organize by goal | Not by feature |
|---|---|
| "Getting started" | "Dashboard" |
| "Managing your team" | "Settings > Team" |
| "Collecting feedback" | "Widget" |
| "Tracking progress" | "Roadmap" |

Limit your top-level categories to five to seven. More than that and users spend time choosing a category instead of finding their answer. Each category should contain between five and twenty articles. Fewer than five suggests the category is too narrow. More than twenty suggests it needs subcategories.

### Search

Search is how most users find help center articles. If your search does not work well, the rest of your help center structure barely matters.

**Full-text search** is the baseline. Users should be able to search article titles, body text, and headings. Partial matches and typo tolerance matter — users searching for "integation" should still find your integrations article.

**Search analytics** are as important as search itself. Track what users search for, which searches return no results, and which searches lead to support tickets anyway. No-result searches tell you exactly which articles are missing. Searches that end in support tickets tell you which articles are not good enough.

### Navigation

Provide multiple paths to every article:

- **Category browsing** for users who want to explore
- **Search** for users who know what they are looking for
- **Related articles** at the bottom of each page for users who landed on something close but not quite right
- **Contextual links** from inside your product pointing to relevant help articles

The contextual links are often the highest-performing path. A "Learn more" link next to a confusing setting sends users directly to the explanation they need, in the moment they need it.

## Tools for building a help center

The right tool depends on your team size, technical capability, and how tightly you want the help center integrated with the rest of your product.

### Dedicated help center platforms

**Intercom** offers a help center as part of its customer messaging platform. Strong integration with live chat — if a user cannot find their answer in an article, they can start a conversation. Pricing starts at $29/seat/month, and the help center is included in all plans.

**Zendesk Guide** is Zendesk's knowledge base product. Deep integration with Zendesk Support for ticket deflection analytics. You can see which articles users viewed before filing a ticket. Starts at $55/agent/month on the Suite plan.

**HelpScout Docs** is a standalone knowledge base with a clean editor and good search. Simpler than Intercom or Zendesk, and priced lower at $22/user/month. A solid choice if you do not need the full customer messaging platform.

### Developer-oriented tools

**GitBook** stores documentation as Markdown in Git repositories. Your engineering team can contribute to the help center using the same workflow they use for code — pull requests, reviews, version control. Free for open-source projects, $8/user/month for teams.

**Mintlify** generates documentation sites from Markdown or MDX with a developer-friendly editing experience. Strong API documentation features. Free tier available, paid plans from $150/month.

**ReadMe** focuses on API documentation but works for general help centers too. Interactive API explorer, custom branding, and analytics. Starts at $99/month.

### Built-in help center features

Some feedback and product tools include help center functionality alongside their core product. This keeps your knowledge base, [feedback boards](/features/feedback), and [changelog](/features/changelog) in one place instead of three separate tools.

[Quackback](/features/feedback) lets you publish help articles alongside your feedback boards, [public roadmap](/features/roadmap), and changelog. Users can search for answers, and if they do not find one, submit feedback directly from the same interface. This closes the loop between "I have a question" and "I have a suggestion" without sending users to a different tool.

Quackback is **open source** (AGPL-3.0) and **self-hosted for free**, with no vendor seat fee, unlike Intercom, Zendesk, or HelpScout. [Quackback Cloud](/pricing) starts at $29/mo billed annually if you would rather not run it yourself. Portal users are free. Quackback also ships an [MCP server](/features/mcp), so an AI assistant can read your feedback and help content directly. See the [docs](/docs) to set up a board, or compare options on the [Quackback vs Canny](/compare/quackback-vs-canny) and [Quackback vs Featurebase](/compare/quackback-vs-featurebase) pages.

### Rolling your own

If you have engineering resources and specific requirements that no tool meets, building a custom help center is an option. Most teams use a static site generator (Next.js, Astro, or similar) with Markdown files for content and a search layer like Algolia or Meilisearch.

The trade-off: full control over design and functionality, but you own the maintenance. Search tuning, analytics, editor tooling, and content workflows all become your responsibility.

## Writing help center articles that work

### Start with the user's problem

Open every article by describing the situation the user is in, not the feature you are about to explain. "You want to add a team member to your workspace" is better than "The Team Management feature allows administrators to invite users."

### Use consistent structure

Every article should follow the same pattern so users know what to expect:

1. **What this article covers** — one sentence
2. **Prerequisites** — what the user needs before starting (plan level, permissions, prior configuration)
3. **Steps** — numbered, sequential instructions
4. **Expected result** — what success looks like
5. **Troubleshooting** — common problems and fixes for this specific workflow

### Write for scanning

Users do not read help articles from top to bottom. They scan for the step they are stuck on. Use descriptive headings, numbered steps, bold key terms, and short paragraphs. If a user has to read 500 words before reaching the actionable instruction, the article needs restructuring.

### Keep articles focused

One article, one topic. "How to invite team members" and "how to set team permissions" are separate articles, even if they are related. Focused articles rank better in search, are easier to maintain, and help users find exactly what they need without wading through irrelevant content.

## Measuring help center effectiveness

### Ticket deflection rate

The primary metric. Track how many users viewed a help center article and did not file a support ticket afterward. Most help center tools provide this, or you can approximate it by comparing help center traffic to ticket volume over time.

Expect modest deflection in the first few months, improving steadily as your content matures and gaps are filled. Gartner estimates that [as much as 40% of live service volume could be resolved in self-service](https://www.gartner.com/en/customer-service-support/trends/improving-self-service-containment-from-search-to-resolution), so there is meaningful headroom to capture.

### Search success rate

What percentage of searches lead to a click on an article? Low click rates suggest your articles do not match what users are searching for — either the content is missing or the titles are not descriptive enough.

### Article feedback

Add a simple "Was this article helpful?" prompt at the bottom of every article. Track the ratio over time. Articles consistently rated unhelpful need rewriting. This is the simplest quality signal you can get.

### Time to resolution

Compare the average time to resolution for issues handled via self-service versus support tickets. Self-service should be significantly faster. If it is not, your help center content may be incomplete or difficult to follow.

## Common mistakes

**Launching with too little content.** A help center with ten articles that does not cover basic workflows is worse than no help center at all. Users learn that your help center does not have what they need and stop checking it. Launch with at least your top 20 most-asked questions covered.

**Writing for experts.** Your help center audience includes users who signed up yesterday. Avoid jargon, define terms on first use, and do not assume familiarity with your product's concepts. When in doubt, over-explain.

**Neglecting maintenance.** Help center articles decay. Features change, UI updates, new options get added. Schedule a quarterly review of your top 20 articles to keep them current. Outdated articles are worse than missing articles — they waste the user's time and erode trust.

**Hiding the help center.** If users cannot find your help center, it does not matter how good it is. Link to it from your product's navigation, your website footer, your onboarding emails, and your support contact page. Make it the first thing users encounter before they file a ticket.

**No feedback loop.** The best source of help center improvement ideas is your support team. They know which questions come up repeatedly, which articles confuse users, and which topics are missing entirely. Build a process for support agents to flag content gaps.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How many articles do I need to launch a help center?

Aim for 20 to 30 articles covering your most common support questions, getting started workflows, and core feature documentation. Expand from there based on search analytics and ticket patterns. The goal is coverage of the basics, not exhaustive documentation on day one.

### How often should I update help center articles?

Review your top articles quarterly and update them whenever you ship UI changes or new features. Set up a process for your support team to flag outdated content in real time. Stale articles are worse than missing articles.

### Should my help center be public or gated?

Public. A public help center is indexed by search engines, which brings in organic traffic and helps prospective customers evaluate your product. It also means users can share article links with colleagues. Gate access only for content that contains sensitive implementation details or security-specific configurations.

### How do I reduce support tickets with a help center?

Three things: make the help center easy to find (link it everywhere), make search work well (users give up after one failed search), and cover the questions your support team actually receives (review ticket data quarterly). Ticket deflection improves gradually as you fill content gaps.

### Can a help center replace live support?

No. A help center handles known, documented problems. Live support handles novel issues, complex configurations, and situations where the user needs judgment, not instructions. The best setup pairs a help center that resolves common questions with a support team focused on problems that require human expertise.

- [The Kano Model Explained: Prioritize Features by Customer Delight](https://quackback.io/blog/kano-model): The Kano Model reveals that not all features contribute equally to satisfaction. Here is how to use it to separate must-haves from delighters and avoid building features nobody cares about.

Published: 2026-03-30

Not all features contribute equally to customer satisfaction. Some features prevent dissatisfaction. Others create delight. Most product teams treat them the same way — and that is why backlogs are full of features nobody uses.

![The Kano Model — three different relationships between features and satisfaction](/blog/kano-model/hero.webp)

> The **Kano Model** is a product prioritization framework that classifies features into five categories based on how they affect customer satisfaction: must-be, one-dimensional, attractive, indifferent, and reverse. It shows that satisfaction is not linear — some features only prevent dissatisfaction, while others create delight. You use it to separate must-haves from delighters before you commit engineering time.

Professor Noriaki Kano introduced this model in 1984 at Tokyo University of Science. The core insight: the relationship between feature implementation and customer satisfaction is not linear. A login system and an AI-powered recommendation engine both take engineering time, but they affect satisfaction in fundamentally different ways. The Kano Model gives you a framework to tell them apart before you build.

## The five categories

### Must-be (basic expectations)

Features customers take for granted. Their presence does not increase satisfaction, but their absence causes immediate dissatisfaction. You never get credit for these. You only get punished for missing them.

**SaaS examples:** Login and authentication, data export, uptime, password reset, basic search, email deliverability, GDPR compliance.

**How to handle them:** Invest enough to make them reliable. Do not invest beyond that — additional polish on a must-be feature produces diminishing returns. A beautifully designed login page does not make anyone more satisfied. A broken one makes everyone furious.

### One-dimensional (performance)

Satisfaction scales linearly with how well the feature is implemented. More is better, less is worse. These are the features where investment produces proportional returns.

**SaaS examples:** Page load speed, storage limits, number of integrations, report customization depth, API rate limits, search relevance.

**How to handle them:** Benchmark against competitors. If your search is slower than theirs, that is a competitive disadvantage. If yours is faster, that is an advantage. Performance features are the main battleground for differentiation in mature markets.

### Attractive (delighters)

Unexpected features that produce disproportionate satisfaction when present but cause zero dissatisfaction when absent. Customers did not expect them, so they cannot miss them. But when they discover them, the reaction is outsized.

**SaaS examples:** AI-powered summarization, smart auto-categorization, personalized onboarding flows, proactive anomaly alerts, natural language querying.

**How to handle them:** These create word-of-mouth and differentiation. They are your competitive moat — competitors cannot copy a delighter as easily as they can match a performance feature. But you cannot build a product on delighters alone. Must-be features come first.

### Indifferent

Features customers do not care about either way. Presence or absence has no measurable effect on satisfaction. These are effort sinks.

**SaaS examples:** A settings page reorganization with no new functionality, backend framework changes with no user-facing impact, a changelog nobody reads, cosmetic updates to internal admin pages.

**How to handle them:** Stop building them. Every engineering hour spent on an indifferent feature is an hour not spent on a performance or attractive feature. Identifying indifferent features is one of the most valuable outcomes of Kano analysis — it tells you what to remove from the backlog.

### Reverse

Features that actively decrease satisfaction when present. Some segment of users is annoyed by them.

**SaaS examples:** Forced onboarding tutorials that cannot be skipped, auto-playing video, aggressive notification defaults, gamification elements in a professional tool, mandatory two-factor authentication for low-risk actions.

**How to handle them:** Either remove them or make them optional. Reverse features often emerge when teams build for one persona without checking with others.

![Kano evaluation table mapping functional and dysfunctional responses to categories](/blog/kano-model/evaluation-table.webp)

## How to run a Kano survey

The Kano survey uses a specific question format: a functional/dysfunctional pair for each feature.

### The question pair

For each feature, ask two questions:

**Functional (positive):** "If [feature] were available, how would you feel?"

**Dysfunctional (negative):** "If [feature] were NOT available, how would you feel?"

Both questions use the same five response options:

1. I like it
2. I expect it
3. I am neutral
4. I can tolerate it
5. I dislike it

### The evaluation table

Cross-reference the functional answer (row) with the dysfunctional answer (column) to classify the feature:

| | Like | Expect | Neutral | Tolerate | Dislike |
|---|---|---|---|---|---|
| **Like** | Q | A | A | A | O |
| **Expect** | R | I | I | I | M |
| **Neutral** | R | I | I | I | M |
| **Tolerate** | R | I | I | I | M |
| **Dislike** | R | R | R | R | Q |

**M** = Must-be, **O** = One-dimensional, **A** = Attractive, **I** = Indifferent, **R** = Reverse, **Q** = Questionable

**How to read it:** If a customer says "I like it" when the feature is present and "I dislike it" when absent, the intersection is **O** (Performance) — satisfaction and dissatisfaction both track with the feature. If they say "I like it" when present but "I am neutral" when absent, that is **A** (Attractive) — they enjoy it but do not miss it.

### Practical tips

- **Frame questions around feelings**, not utility. "How would you feel if..." produces better classification than "Would you use..."
- **Limit to 15-20 features** per survey to avoid fatigue
- **Segment results by persona** or plan tier. A feature might be Must-be for enterprise users but Indifferent for self-serve users
- **Minimum sample size:** 20-30 respondents per segment for reliable classification
- **Add an importance question:** "How important is this feature to you?" on a 1-9 scale adds a weighting dimension that helps when categories are close

![Feature decay: Attractive features become Performance, then Must-be over time](/blog/kano-model/feature-decay.webp)

## Feature decay: why today's delighter becomes tomorrow's expectation

This is the most important practical implication of the Kano Model. Features follow a predictable trajectory over time:

**Attractive → Performance → Must-be**

What delights today becomes expected tomorrow and table stakes next year.

| Feature | 2010 | 2018 | 2026 |
|---|---|---|---|
| Real-time collaboration | Attractive | Performance | Must-be |
| Mobile app for SaaS | Attractive | Performance | Must-be |
| Dark mode | — | Attractive | Performance |
| AI-powered features | — | — | Attractive |

Free hotel WiFi was once a delighter. Now its absence triggers one-star reviews. Smartphone touchscreens were magical in 2007. By 2015 they were table stakes. The same pattern plays out in SaaS on a faster timeline.

**Implication:** Re-run your Kano analysis every 12-18 months. In fast-moving SaaS markets, feature classifications shift quickly. You need a pipeline of new delighters because your current ones are decaying into expectations.

## Using feedback data as a Kano proxy

A formal Kano survey is the gold standard, but you can approximate Kano categories using existing feedback data from your [feedback board](/features/feedback):

| Signal in feedback data | Likely Kano category |
|---|---|
| High vote count + frustration/churn mentions | Must-be (missing a basic expectation) |
| High vote count + positive anticipation | Performance (more = better) |
| Low request volume + outsized positive reaction when shipped | Attractive (unexpected delight) |
| Low vote count + flat engagement after launch | Indifferent (nobody cares) |
| Negative feedback after launching | Reverse (actively harmful) |

This is not as precise as a survey, but it lets you make Kano-informed decisions continuously using data you already collect. [Quackback](/features/feedback) is built to run this loop continuously: a public board captures votes and frustration signals, [AI-powered feedback analysis](/blog/ai-customer-feedback-analysis) detects sentiment patterns across hundreds of submissions, and an [MCP server](/features/mcp) lets you query your feedback directly from an AI assistant. Because Quackback is open source, you can give your whole team access to the data behind these classifications.

![Four prioritization frameworks and when to use each](/blog/kano-model/frameworks-comparison.webp)

## Kano vs other prioritization frameworks

The Kano Model answers a different question than [RICE](/blog/rice-framework-explained) or [MoSCoW](/blog/moscow-prioritization). Here is when to use each:

| Framework | Question it answers | Best for |
|---|---|---|
| **Kano** | What do customers actually value? | Discovery — understanding emotional response before building |
| **RICE** | What should we build first? | Backlog ranking — scoring features by reach, impact, confidence, effort |
| **MoSCoW** | What fits in this release? | Sprint scoping — negotiating scope with stakeholders |
| **Impact-Effort** | Where are the quick wins? | Workshops — fast visual prioritization |

**The recommended workflow:** Use Kano during discovery to understand what matters. Feed Kano classifications into [RICE scoring](/blog/rice-framework-explained) — a Must-be feature gets high Impact regardless of reach. Use [MoSCoW](/blog/moscow-prioritization) to finalize what ships in the next sprint.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How many features should I test in a Kano survey?

Limit a Kano survey to 15-20 features. Each feature needs two questions (functional and dysfunctional), so 20 features means 40 questions, and beyond that respondent fatigue degrades data quality. Split larger feature lists across multiple surveys targeting different segments.

### Can I use Kano for existing features or only new ones?

Both. For existing features, the Kano survey reveals whether customers view them as must-haves, performance differentiators, or indifferent. This is valuable for deciding where to invest improvement effort and where to stop. An existing feature classified as Indifferent is a candidate for deprecation.

### How often should I re-run Kano analysis?

Every 12-18 months in fast-moving SaaS markets. Feature decay means today's delighter becomes next year's expectation. Annual re-evaluation catches these shifts before your competitive advantage erodes. Trigger an ad-hoc analysis after major market changes (new competitor, significant price shift, platform change).

### What if results vary across customer segments?

Segment the analysis by persona or plan tier. A feature can be Must-be for enterprise customers (who expect SSO and compliance) but Indifferent for self-serve users. If you serve multiple segments, build must-be features for all and attractive features for your primary segment.

### How does Kano analysis differ from just looking at feature votes?

Feature votes tell you how many people want something. Kano tells you how they will feel about it. A feature with 200 votes might be a Must-be (customers are frustrated it is missing) or an Attractive delighter (nice to have but fine without). That distinction changes the priority.

- [Product Launch Checklist for SaaS Teams (2026 Template)](https://quackback.io/blog/product-launch-checklist): A complete SaaS product launch checklist for before, during, and after launch, organized by team and timeline. Copy it and adapt it to your workflow.

Published: 2026-03-30

The feature is built, tested, and ready to ship. The launch itself takes a day. The preparation and follow-through take weeks. Most teams underinvest in both.

![Product launch timeline: pre-launch, launch week, and post-launch](/blog/product-launch-checklist/hero.webp)

> A **SaaS product launch checklist** organizes the work across three phases: pre-launch preparation (product, design, docs, marketing, sales), launch week execution (staged rollout, monitoring, announcements), and post-launch follow-through (adoption metrics, feedback review, iteration). Scale your effort to the launch type, and assign each activity an owner so nothing falls through the cracks.

A McKinsey study found companies lose [33% of after-tax profit by shipping six months late, but only 3.5% from overspending 50% on development](https://hbr.org/1991/01/the-return-map-tracking-product-teams). Speed matters. But shipping without a launch plan means your best features go unnoticed, your support team gets blindsided, and you miss the window to collect early feedback that shapes the next iteration.

This checklist covers three phases: pre-launch preparation, launch week execution, and post-launch follow-through. Use it as a starting template and adapt it to your team's workflow.

## Pre-launch (4-8 weeks before)

### Product and engineering

- [ ] Feature is code-complete and passing all automated tests
- [ ] Beta testing completed with at least 5-10 users from different segments
- [ ] Beta feedback reviewed and critical issues resolved
- [ ] Performance testing validates acceptable load times under expected traffic
- [ ] Feature flags configured for staged rollout (percentage-based or segment-based)
- [ ] Rollback plan documented — how to disable the feature without a full deployment
- [ ] API documentation updated if the feature exposes new endpoints
- [ ] Data migration scripts tested (if applicable) with rollback procedures

### Design and UX

- [ ] Final designs reviewed against [acceptance criteria](/blog/acceptance-criteria)
- [ ] Responsive design verified on mobile, tablet, and desktop viewports
- [ ] Accessibility audit completed (keyboard navigation, screen reader compatibility, color contrast)
- [ ] Empty states, error states, and loading states designed and implemented
- [ ] Onboarding flow or tooltip walkthrough created for new users discovering the feature

### Documentation and support

- [ ] Help center articles written and reviewed (how-to guides, configuration options, troubleshooting)
- [ ] [Knowledge base](/blog/self-service-help-center) updated with new feature documentation
- [ ] Internal FAQ prepared for support team — common questions and answers
- [ ] Support team trained on the feature (demo, walkthrough, edge cases)
- [ ] Canned responses created for anticipated support tickets
- [ ] Known limitations documented (what does not work yet, what is planned for v2)

### Marketing and communications

- [ ] Launch messaging finalized — one-sentence description, key benefits, target audience
- [ ] Blog post or announcement drafted
- [ ] Email announcement drafted for existing customers
- [ ] Social media posts scheduled
- [ ] Product screenshots and demo GIF/video created
- [ ] Landing page updated (if the feature warrants its own page)
- [ ] [Changelog](/features/changelog) entry drafted

### Sales enablement

- [ ] Sales team briefed on the feature — what it does, who it is for, how to demo it
- [ ] Battlecard updated with competitive positioning (how this feature compares to competitors)
- [ ] Pricing implications documented (is this included in existing plans or a new tier?)
- [ ] Customer-facing one-pager or feature brief created

## Launch week

### Day of launch

- [ ] Feature flag enabled for the target rollout percentage (start at 10-25%, not 100%)
- [ ] Monitoring dashboards visible — error rates, latency, feature adoption
- [ ] On-call rotation confirmed for engineering (who handles incidents?)
- [ ] [Changelog entry](/features/changelog) published
- [ ] Email announcement sent to customer segments
- [ ] Blog post published
- [ ] Social media posts published
- [ ] In-app announcement or banner activated
- [ ] Sales team notified that the feature is live

### Days 2-3

- [ ] Monitor error rates, support ticket volume, and adoption metrics
- [ ] Review initial customer feedback from [feedback widget](/features/widget), support tickets, and social channels
- [ ] Address critical bugs within 24 hours
- [ ] Expand rollout percentage based on stability data (25% → 50% → 100%)
- [ ] Respond to social media mentions and community questions

### Days 4-7

- [ ] Full rollout to 100% of users (if no critical issues)
- [ ] First adoption metrics report — how many users activated the feature?
- [ ] [Feedback board](/features/feedback) reviewed for early feature requests and complaints
- [ ] Support team check-in — are the canned responses covering the real questions?
- [ ] Remove feature flag (or leave it in place for kill-switch capability)

## Post-launch (2-4 weeks after)

### Metrics and analysis

- [ ] Feature adoption rate measured (percentage of eligible users who used the feature)
- [ ] Retention impact assessed (did the feature improve or harm retention for the cohort?)
- [ ] Support ticket volume analyzed (is the feature generating more tickets than expected?)
- [ ] Performance metrics reviewed (load times, error rates under real traffic)
- [ ] Revenue impact measured (for monetized features: conversion rate, upsell rate)

### Feedback and iteration

- [ ] All feedback from the launch period collected and categorized
- [ ] Top feature requests from launch feedback identified and added to backlog
- [ ] Bug reports triaged and prioritized
- [ ] V2 improvements scoped based on post-launch data
- [ ] Feedback loop closed — notify users who reported issues that fixes are shipped

### Communication

- [ ] Post-launch retrospective held with the cross-functional team
- [ ] [Product update](/blog/product-update-announcement) sent to customers who did not engage with the initial announcement
- [ ] [Public roadmap](/features/roadmap) updated to reflect shipped status
- [ ] Internal wins shared — adoption numbers, customer quotes, impact metrics

## Cross-functional RACI

![Cross-functional RACI diagram with Product, Engineering, Marketing, Sales, and Support roles](/blog/product-launch-checklist/cross-functional-raci.webp)

Who is responsible for what during a launch:

| Activity | Product | Engineering | Marketing | Sales | Support |
|---|---|---|---|---|---|
| Feature scope and acceptance criteria | **R** | C | I | I | I |
| Development and testing | C | **R** | I | I | I |
| Beta program coordination | **R** | C | I | I | C |
| Documentation and help articles | C | I | I | I | **R** |
| Launch messaging and blog post | C | I | **R** | I | I |
| Changelog and in-app announcement | **R** | I | C | I | I |
| Sales enablement and battlecard | C | I | C | **R** | I |
| Monitoring and incident response | C | **R** | I | I | I |
| Post-launch feedback review | **R** | C | I | C | C |

**R** = Responsible, **C** = Consulted, **I** = Informed

## Launch types and how they differ

Not every launch needs the full checklist. Scale your effort to the launch type:

### Major launch (new product or flagship feature)

Use the full checklist. All teams involved. External communications including blog post, email, social media, and potentially press. Beta program of 2-4 weeks. Full cross-functional retrospective.

### Feature launch (significant new capability)

Use most of the checklist. Skip press and landing pages. Focus on changelog, email to affected segments, and in-app announcement. Beta testing with 5-10 users. Abbreviated retrospective.

### Minor release (improvements and fixes)

Changelog entry and in-app notification are sufficient. No email blast, no blog post. Support team informed via Slack message. Engineering monitors for 24 hours. No formal retrospective.

### Silent release (behind a feature flag)

No external communication. Feature flag enables the feature for a percentage of users. Engineering monitors metrics. If metrics are positive, expand rollout. If negative, roll back. Communicate only after the feature is proven at scale.

## Common launch mistakes

**Skipping the beta.** Shipping directly to 100% of users means your entire user base discovers bugs simultaneously. A beta with 5-10 users catches the obvious issues before they scale.

**Announcing before it is ready.** Announcing a feature that is not yet live or is behind a feature flag for only 10% of users creates support tickets from the 90% who cannot find it. Time your announcements to match your rollout.

**Forgetting support.** Your support team gets the first wave of questions. If they learned about the feature from the same changelog entry as the customers, they cannot help. Brief support before launch, not after.

**No rollback plan.** "What do we do if this breaks?" should be answered before launch, not during an incident. Feature flags, database migration rollbacks, and deployment reverts should all be documented and tested.

**Moving on too fast.** Shipping and immediately starting the next sprint means you never measure whether the feature worked. Block two weeks of post-launch time for monitoring, feedback review, and iteration planning. The data from those two weeks determines whether you built the right thing.

## Close the launch feedback loop

The post-launch phase is where most checklists fall apart. You ship, the next sprint starts, and the early signal disappears. Quackback keeps that loop in one place: a [feedback board](/features/feedback) and [feedback widget](/features/widget) capture launch reactions in context, a [public roadmap](/features/roadmap) and [changelog](/features/changelog) keep customers informed, and an [MCP server](/features/mcp) lets you triage and summarize launch feedback from your AI assistant. Because Quackback is open source, your whole launch team — product, support, sales — can read and respond. Built-in AI helps you summarize a launch-week feedback spike.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How far in advance should I start launch preparation?

Four to eight weeks for a major launch. Two to four weeks for a feature launch. One week for a minor release. The documentation, training, and marketing assets take longer than most teams expect — start earlier than you think you need to.

### Should every feature get a launch plan?

No. Bug fixes, minor improvements, and internal tooling changes do not need a launch plan. Use the full checklist for features that affect user workflows, change pricing, or require user education. Use a lightweight version (changelog + monitoring) for everything else.

### How do I measure launch success?

Measure launch success with three metrics: adoption rate (percentage of eligible users who used the feature within 30 days), support impact (whether ticket volume rose or fell), and retention impact (whether the feature improved retention for that cohort). Set target numbers before launch to define success clearly.

### What is the best way to announce a product launch?

A multi-channel approach: [changelog entry](/features/changelog) for in-product visibility, email to relevant customer segments for reach, blog post for SEO and detail, and social media for awareness. The changelog and email are non-negotiable for any significant launch. Blog and social are optional for smaller releases.

### How do I collect feedback during a launch?

Collect launch feedback through a [feedback widget](/features/widget) so users report issues in context, a [feedback board](/features/feedback) for new submissions, support ticket patterns, and a post-launch survey to beta users. The first two weeks after launch are the highest-signal period, so watch them closely.

- [Anonymous Feedback: Why It Gets More Honest Responses (and How to Set It Up)](https://quackback.io/blog/anonymous-feedback): Anonymous feedback surfaces honest insights people will not share with their name attached. Learn when to use it, when to avoid it, and how to set it up.

Published: 2026-03-29

People filter what they say when their name is attached. That is not a character flaw — it is human nature. The question is whether your feedback system accounts for it or pretends it does not exist.

![Anonymous feedback produces more honest responses](/blog/anonymous-feedback/hero.webp)

When a customer submits a feature request with their name and company visible, they are thinking about more than just the feedback. They are thinking about their relationship with your team, whether the request sounds reasonable, and whether anyone will judge them for asking. That self-censoring removes the rough edges — which are often the most valuable part.

Anonymous feedback does not replace identified feedback. It fills a gap that identified feedback cannot reach.

> **Anonymous feedback** is feedback collected without attaching a name, account, or identity to the submission. It tends to surface more honest responses because people stop self-censoring when there is no risk of judgment, damaged relationships, or career consequences. Use it as an honesty check alongside identified feedback — not as a replacement — and enable it gradually, starting with anonymous voting before opening up anonymous commenting and posting.

## The honesty gap

Research on anonymity and honesty is consistent across fields. People disclose more about sensitive topics when they believe their identity is protected, and they report lower social desirability bias under anonymous conditions. The effect is strongest exactly where the stakes feel personal — workplace issues, mistakes, and criticism people would rather not put their name to.

**Social desirability bias** is the tendency to give answers that will be viewed favorably by others. In identified feedback, users skew toward polite, constructive phrasing. They downplay frustration. They avoid criticizing features they know your team spent months building. Anonymous feedback bypasses this filter. Research published in *Behavior Research Methods, Instruments, & Computers* ([Joinson, 1999](https://link.springer.com/article/10.3758/BF03200723)) found that participants reported lower social desirability under anonymous conditions — which is exactly the dynamic that sanitizes product feedback.

**The spiral of silence** describes how people stay quiet when they think their opinion is unpopular. In a public feedback board where votes are visible and names are attached, a user who disagrees with a popular request may not speak up. Anonymous channels break this spiral and give minority opinions a voice.

**Power dynamics** amplify the effect. When a customer depends on your product for their workflow, they may avoid harsh feedback because they worry it could affect their relationship with your team or their account status. This is especially true for enterprise customers with dedicated account managers. An [AllVoices report](https://www.allvoices.co/blog/impact-of-hr-on-employee-feedback) found that 84% of employees had at least one concern they wanted to raise with HR in the past year but never shared.

**Selection bias in participation** is often overlooked. Anonymity does not just make the same people more honest — it can bring in entirely different participants. The same dynamic applies to product feedback: your anonymous channel will hear from users who would never have submitted identified feedback in the first place.

The result: identified feedback tells you what people are comfortable saying publicly. Anonymous feedback tells you what they actually think.

![The honesty gap between anonymous and identified feedback](/blog/anonymous-feedback/honesty-gap.webp)

## When anonymous feedback works

### Sensitive product areas

Users are more likely to share honest feedback anonymously when the topic involves something they find embarrassing or frustrating. A user struggling with your onboarding flow might not want to publicly admit they could not figure out how to set up their account. Anonymity removes the stigma.

### Early-stage products

When your product is new and your user base is small, people are reluctant to post harsh feedback because they know you will see it and might know who they are. Anonymous feedback is especially valuable during beta phases when you need unfiltered reactions to rough features.

### Internal feedback

If you use a feedback tool internally — for employees to suggest process improvements or product ideas — anonymity is critical. People will not criticize a VP's pet project with their name attached. They will if the submission is anonymous.

### Churn signals

Users who are about to leave your product rarely tell you why if they have to identify themselves. They just leave. An anonymous feedback channel gives departing users a low-friction way to explain what went wrong without the awkwardness of a face-to-face conversation, which feeds directly into your [customer retention strategy](/blog/customer-retention-strategies).

### Price sensitivity

Feedback about pricing is almost never honest when identified. Customers do not want to look cheap. They do not want to damage their negotiating position. Anonymous feedback about pricing surfaces the real objections: "this is too expensive for what it does," "I cannot justify this to my manager," "the free tier is too limited."

## When anonymous feedback does not work

### Support issues

If a user reports a bug anonymously, you cannot follow up. You cannot ask for reproduction steps, check their account configuration, or tell them when it is fixed. Bug reports and support requests need identity to be actionable.

### Feature requests that need context

Some feature requests only make sense with user context. "We need SSO" means something different from a three-person startup than from a 500-person enterprise. If you cannot see who is asking, you lose the context that helps you prioritize.

### High-trust communities

In small, tight-knit user communities where people know each other, anonymous feedback can feel unnecessary or even counterproductive. If your users already trust your team and each other, anonymity adds friction without much benefit.

### Accountability-sensitive decisions

When feedback directly influences a product decision — like voting on which feature gets built next — some teams prefer identified feedback because it lets them weight votes by customer segment, revenue, or usage. Anonymous votes count equally regardless of context.

## How to implement anonymous feedback

The implementation depends on what you want to allow anonymous users to do. Most teams start with anonymous voting and expand from there. The [Quackback docs](/docs) walk through configuring these permissions end to end.

### Configurable permission levels

The most flexible approach is a permission system where you control what anonymous users can do:

| Action | Default | When to enable |
|---|---|---|
| **Anonymous voting** | On | Almost always. Low friction, high signal. |
| **Anonymous commenting** | Off | When you want anonymous discussion on existing posts. |
| **Anonymous posting** | Off | When you want to collect anonymous submissions. |

Start with anonymous voting enabled and the others off. This lets unidentified visitors express preferences without opening the door to low-quality anonymous posts. Expand permissions if you find that anonymous voting surfaces demand for anonymous submissions.

[Quackback supports all three permission levels](/features/voting) — anonymous voting, commenting, and posting — configurable independently from the admin panel. Logged-in users get their feedback attributed automatically. Anonymous visitors participate without creating an account. Quackback is open source (AGPL-3.0), so you can open a channel to anonymous and identified participants alike on infrastructure you control.

### Embedding in your product

The most effective anonymous feedback comes from in-product prompts, not standalone surveys. When a user finishes a task, encounters an error, or reaches a milestone, prompt them with an optional anonymous feedback widget. The context is fresh and the friction is minimal.

A [feedback widget](/features/widget) embedded in your product can identify logged-in users automatically while falling back to anonymous mode for visitors who are not signed in. This gives you the best of both: attributed feedback from known users and anonymous feedback from everyone else.

### Preventing abuse

The main concern with anonymous feedback is abuse — spam, offensive content, or deliberately misleading submissions. In practice, this is less common than most teams expect, especially for product feedback tools (as opposed to social platforms). But basic safeguards help:

- **Rate limiting** — restrict how many anonymous submissions come from a single IP or session in a given time window
- **Moderation queue** — route anonymous submissions through a review step before they appear publicly
- **Content filtering** — flag submissions that contain offensive language for manual review
- **Session tracking** — even without identifying the user, track anonymous sessions to detect patterns (same person submitting the same request repeatedly)

## Balancing anonymous and identified feedback

Anonymous feedback is not an all-or-nothing decision. The strongest feedback programs use both and keep them clearly separated.

**Identified feedback** is your primary channel. It gives you context, enables follow-up, and lets you weight feedback by customer segment. Feature requests, bug reports, and detailed product suggestions work best with identity attached.

**Anonymous feedback** is your honesty check. It surfaces the things people will not say publicly. Use it to validate or challenge what your identified feedback is telling you. If your identified feedback says users love your pricing and your anonymous feedback says it is too expensive, you have a signal worth investigating. Not every tool gives you this control over anonymous participation — see how the approaches differ in [Quackback vs Canny](/compare/quackback-vs-canny).

**Do not try to de-anonymize.** If you offer anonymous feedback, respect the anonymity. Do not cross-reference timestamps, IP addresses, or writing style to figure out who submitted something. Users will find out, and you will never get honest feedback again.

## Measuring the impact

How do you know if anonymous feedback is adding value?

**Volume comparison.** If anonymous submissions are significantly higher than identified submissions, that is a signal that users have things to say but are not comfortable saying them publicly. The gap between anonymous and identified volume tells you how much honesty your identified channel is leaving on the table.

**Sentiment comparison.** Compare the average sentiment of anonymous feedback to identified feedback. If anonymous feedback is consistently more negative, it is surfacing dissatisfaction that your identified channel masks.

**New themes.** Track whether anonymous feedback raises topics that never appear in identified feedback. If anonymous users consistently mention pricing, performance, or competitor features that identified users do not raise, those are blind spots in your public feedback. Quackback's [AI analysis](/features/feedback) clusters submissions into themes, and its [MCP server](/features/mcp) lets you query those themes directly from tools like Claude or Cursor.

**Action rate.** Track how often anonymous feedback leads to a product change. If anonymous insights are driving real decisions, the channel is working. If they are just noise, reconsider your approach.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Does anonymous feedback attract trolls and spam?

In product feedback contexts, spam and abuse are rare. Product feedback tools have a narrow audience (your users) and a specific purpose, so low-quality submissions are typically a small fraction of the total. Basic rate limiting, a moderation queue, and content filtering handle the rest.

### Should I make all feedback anonymous by default?

No. Default to identified feedback for logged-in users and anonymous for visitors. Identified feedback is more actionable because you can follow up, segment by customer type, and weight by usage. Anonymous is a supplement, not a replacement.

### How do I act on anonymous feedback if I cannot follow up?

Treat anonymous feedback as directional signal, not individual tickets. If one anonymous user says your pricing is too high, that is an anecdote. If twenty anonymous users say it, that is a trend. Use anonymous feedback to identify themes, then investigate those themes through other channels — [customer interviews](/blog/user-interview-questions), surveys, or targeted outreach to specific segments.

### Can anonymous users vote on existing posts?

Yes, in most feedback tools that support anonymous participation. Anonymous voting is the lowest-friction form of anonymous feedback — it lets visitors express preferences without writing anything. This is particularly useful for [public feedback boards](/features/feedback) where you want the broadest possible participation in prioritization.

### Is anonymous feedback GDPR compliant?

Truly anonymous feedback — where no personal data is collected or stored — falls outside GDPR's scope because there is no data subject to protect. However, if you track sessions, IP addresses, or any identifiers alongside "anonymous" feedback, it may qualify as pseudonymous data and still fall under GDPR. Consult your legal team about your specific implementation.

- [Monday.com Pricing in 2026: Plans, Seat Buckets, and Cheaper Alternatives](https://quackback.io/blog/monday-pricing): Monday.com charges by seat buckets, not individual users. Here is what each plan actually costs, where the hidden fees are, and which alternatives offer better value.

Published: 2026-03-29

Monday.com lists pricing at $9 per seat per month. What it does not tell you upfront is that you cannot buy one seat.

![Monday.com seat bucket billing — paying for empty seats](/blog/monday-pricing/hero.webp)

Monday.com uses a seat-bucket billing model. Every paid plan requires a minimum of three seats, and after that seats are sold in multiples of five. A team of six pays for ten seats. A team of sixteen pays for twenty. This "ghost seat" tax is the single most criticized aspect of Monday's pricing — and it is not obvious until you reach the checkout page.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice.*

## Monday.com pricing plans

All prices are per seat per month, billed annually. Monthly billing costs 18-33% more.

| Plan | Annual price | Monthly price | Min seats | Storage |
|---|---|---|---|---|
| **Free** | $0 | $0 | 1-2 users | 500 MB |
| **Basic** | $9/seat/mo | $12/seat/mo | 3 | 5 GB |
| **Standard** | $12/seat/mo | $14/seat/mo | 3 | 20 GB |
| **Pro** | $19/seat/mo | $24/seat/mo | 3 | 100 GB |
| **Enterprise** | Custom | Custom | Custom | 1 TB+ |

Teams of more than 40 users must request a custom quote.

![Monday.com features gated by pricing tier](/blog/monday-pricing/feature-gates.webp)

## What each plan includes

### Free

Two users maximum, three boards, up to 1,000 items (expandable via referral). No automations, no integrations, 500 MB storage. Functional for personal task tracking. Not viable for team use.

### Basic ($9/seat/month)

Unlimited boards and items, 5 GB storage. This sounds reasonable until you realize what is missing: **zero automations and zero integrations**. You cannot connect Monday to Slack, Gmail, or any other tool. You cannot create any automated workflows.

Basic is the most misleading tier. It looks like a usable plan on the pricing page, but the absence of automations and integrations makes it barely more capable than a shared spreadsheet. Multiple reviewers on G2 and Capterra call this out — the real entry price for a functional project management tool is Standard.

### Standard ($12/seat/month)

This is where Monday becomes usable. You get 250 automation actions per month, 250 integration actions per month, Timeline and Gantt views, Calendar view, and guest access (two guests per paid seat). Storage increases to 20 GB.

The catch: 250 automation actions sounds generous, but each trigger counts as one action. A ten-person team with even light automation — status change notifications, due date reminders, and assignment alerts — can burn through 250 actions in the first week of the month. Hitting the cap forces an upgrade to Pro.

### Pro ($19/seat/month)

The automation cap jumps from 250 to 25,000 actions per month — a 100x increase. Pro adds private boards, time tracking, chart views, formula columns, dependency columns, custom forms, and advanced reporting. Storage increases to 100 GB.

For most teams that outgrow Standard, Pro is the destination. The jump from $12 to $19 per seat per month (58% increase) is the cost of removing the automation ceiling.

### Enterprise (custom pricing)

250,000 automation and integration actions per month. Multi-level permissions, HIPAA compliance, SCIM provisioning, five years of activity logs, 1 TB+ storage, and a dedicated customer success manager. Pricing requires a sales conversation.

![Monday.com seat bucket overpayment by team size](/blog/monday-pricing/seat-bucket-overpay.webp)

## The seat bucket problem

Monday.com does not sell individual seats after the initial three. Seats come in blocks of five: 3, 5, 10, 15, 20, 25, and so on. You always pay for the next increment.

| Team size | Seats billed | Unused seats | Basic annual cost | Pro annual cost |
|---|---|---|---|---|
| 1-3 | 3 | 0-2 | $324 | $684 |
| 4-5 | 5 | 0-1 | $540 | $1,140 |
| 6-10 | 10 | 0-4 | $1,080 | $2,280 |
| 11-15 | 15 | 0-4 | $1,620 | $3,420 |
| 16-20 | 20 | 0-4 | $2,160 | $4,560 |
| 21-25 | 25 | 0-4 | $2,700 | $5,700 |

A six-person team on Pro pays for ten seats — $2,280/year for six users and four empty chairs. That is a 67% markup over the per-user price. The overpayment gets worse at awkward team sizes: a team of eleven pays for fifteen seats (36% markup), and a team of sixteen pays for twenty seats (25% markup).

## Hidden costs and gotchas

**No annual refunds.** Monday.com does not refund unused months on annual plans. If you downsize mid-year, you lose the remaining balance.

**Storage overages.** Additional storage costs $2-5 per user per month beyond plan limits.

**Premium support.** Support packages cost $500-2,000 per month, though negotiated discounts of 40-60% are common.

**Monthly billing penalty.** Choosing monthly billing increases costs by 18-33% depending on the plan. Basic jumps from $9 to $12, Pro from $19 to $24.

**Price increases.** January 2024 saw a significant price hike across plans. February 2026 brought an 18% increase to Monday Service with no corresponding new features.

**Automation cap escalation.** Standard's 250 actions per month is the most common forced-upgrade trigger. Teams that adopt even basic automation outgrow Standard within weeks.

## Free and cheaper alternatives

| Tool | Free tier | Paid from | Key advantage over Monday |
|---|---|---|---|
| **ClickUp** | Unlimited users | $7/user/mo | 15 view types, generous free plan, per-user pricing |
| **Trello** | Unlimited boards | $5/user/mo | Simple Kanban, low learning curve, no seat buckets |
| **Asana** | Up to 10 users | $10.99/user/mo | Clean workflow UI, no seat buckets |
| **Notion** | Unlimited (individuals) | $8/user/mo | Docs + tasks combined, flexible |
| **Linear** | Free for small teams | $8/user/mo | Dev-focused, fast, per-user pricing |
| **SmartSuite** | Free tier | $12/user/mo | 500K automation actions (vs Monday's 250 on Standard) |

The common thread: most competitors use per-user pricing without seat buckets and include automations on lower tiers.

For teams that need project tracking alongside [customer feedback management](/features/feedback), [Quackback](https://quackback.io) is open source and free to self-host. It covers feedback boards, voting, roadmaps, and changelogs — the product feedback workflow that Monday.com does not address. You can use Monday for project execution and Quackback for customer-facing feedback without paying for overlap.

## Is Monday.com worth it?

Monday.com is a genuinely good project management tool. The visual interface, workflow automations (on Pro), and breadth of templates make it easy for non-technical teams to adopt. The G2 rating of 4.7/5 across 15,000+ reviews reflects real user satisfaction with the product itself.

The pricing model is the problem, not the product. Seat-bucket billing, the Basic plan's lack of automations, and Standard's low automation cap create a pricing experience that feels designed to push teams toward Pro. If your team size aligns with a bucket boundary (5, 10, 15, 20) and you need Pro-level features, Monday.com is competitively priced. If your team falls between buckets or you need more than 250 automation actions but less than Pro's full feature set, you are overpaying.

## Frequently asked questions

### Does Monday.com have a free plan?

Yes, for up to two users with three boards and 1,000 items. It includes no automations, no integrations, and 500 MB storage. It is functional for personal task management but not for team collaboration.

### Why does Monday.com charge by seat bucket?

Monday.com has not publicly explained the bucket model. The practical effect is that most teams pay for more seats than they use, increasing average revenue per account. Competitors like Asana, ClickUp, and Linear all use per-user pricing without buckets.

### What is the real minimum cost for Monday.com?

The three-seat minimum means the cheapest paid plan is $27/month (Basic, annual) or $36/month (Standard, annual). Since Basic lacks automations and integrations, the functional minimum is Standard at $36/month for three users.

### How do Monday.com automation limits work?

Each automation trigger counts as one action. Standard allows 250 actions per month across your entire workspace (not per user). Pro allows 25,000. When you hit the limit, automations stop running until the next billing cycle. There is no overage charge — they simply stop working, which can be worse than an overage if you depend on them.

### Is Monday.com cheaper than Asana?

For teams that align with seat-bucket boundaries, Monday Standard ($12/seat/month) is slightly cheaper than Asana Premium ($10.99/user/month) at small team sizes. But Monday's seat-bucket model means a six-person team pays for ten seats ($120/month) while Asana charges for six users ($66/month). At awkward team sizes, Asana is consistently cheaper.

- [User Story Examples for Product Teams (15 Templates You Can Copy)](https://quackback.io/blog/user-story-examples): Most user stories are written backward — starting with the solution instead of the user's problem. Here are 15 examples across common SaaS categories, plus a framework for writing your own.

Published: 2026-03-29

A user story is one sentence. Getting it right determines whether your team builds the right thing or wastes a sprint on the wrong interpretation.

![User story format with the "so that" reason emphasized](/blog/user-story-examples/hero.webp)

The standard format is: **"As a [persona], I want [goal], so that [reason]."** The "so that" clause is the most important part — and the most frequently omitted. Without it, you have a feature request. With it, you have context that lets engineering make better implementation decisions.

> A **user story** is a short, plain-language description of a feature from the user's perspective, written as "As a [persona], I want [goal], so that [reason]." The persona names who needs it, the goal describes what they want to accomplish without specifying the UI, and the reason explains why it matters so engineering can make better trade-off decisions. Good stories follow the INVEST criteria and stay small enough to finish in a single sprint.

## The format explained

**As a [persona]** — who is this for? Not "as a user" (too generic) but "as a team admin" or "as a free-tier customer" or "as a first-time visitor." The persona constrains the scope and tells engineering whose workflow this affects.

**I want [goal]** — what does the persona need to accomplish? Describe the goal, not the UI. "I want to filter the dashboard by date" is better than "I want a dropdown with date options." Goals leave room for design exploration. UI specifications do not.

**So that [reason]** — why does this matter? "So that I can share last week's metrics with my manager" reveals that the output needs to be shareable — maybe as a PDF, a link, or a screenshot. Without the reason, engineering might build a filter that works perfectly but produces output that cannot be shared.

## Good vs bad examples

| Bad | Good | Why it is better |
|---|---|---|
| As a user, I want search | As a support agent, I want to search tickets by customer email, so that I can find a customer's history without scrolling through the full list | Specific persona, specific goal, clear reason |
| As a user, I want a dark mode toggle | As a developer who works late, I want a dark mode, so that the interface does not strain my eyes during evening sessions | The reason reveals the use case and who it is for |
| Build CSV export | As a team lead, I want to export my team's task data as CSV, so that I can build custom reports in Excel for quarterly reviews | Transforms a task into a story with context |
| Add Slack integration | As a product manager, I want feedback from [Slack](/integrations/slack) channels to appear on our feedback board, so that feature requests do not get lost in conversation threads | The reason explains the problem, not just the feature |

## 15 user story examples by category

### Onboarding

**1.** As a new user, I want a guided setup wizard that walks me through creating my first project, so that I can reach a useful state without reading documentation.

**2.** As a team admin who just signed up, I want to invite team members by email during onboarding, so that my team is ready to use the product by the time I finish setup.

**3.** As a returning user who abandoned onboarding, I want to resume where I left off, so that I do not repeat steps I already completed.

### Collaboration

**4.** As a team member, I want to leave comments on specific tasks with @mentions, so that the relevant person gets notified and the context stays attached to the work.

**5.** As a project manager, I want to see which tasks were updated in the last 24 hours, so that I can review progress in my daily standup without asking each person individually.

### Admin and settings

**6.** As a workspace admin, I want to assign roles (Admin, Editor, Viewer) to team members, so that I can control who can modify settings and who can only view data.

**7.** As a billing admin, I want to update our payment method without contacting support, so that I can fix a declined card before the next billing cycle.

### Reporting and analytics

**8.** As a product manager, I want to see a dashboard showing feedback volume by category over the past 90 days, so that I can identify which product areas generate the most requests and prioritize accordingly.

**9.** As an executive, I want a weekly email summary of key metrics, so that I stay informed without logging into the product every day.

### Integrations

**10.** As a support agent, I want to forward a [Zendesk](/integrations/zendesk) ticket to our [feedback board](/features/feedback) with one click, so that feature requests from support conversations are captured without copy-pasting.

**11.** As a developer, I want new feedback posts to create issues in our [Jira](/integrations/jira) project automatically, so that the engineering backlog stays synchronized with customer requests.

### Billing and pricing

**12.** As a customer on the free plan, I want to see a clear comparison of what the paid plan offers, so that I can decide whether to upgrade without contacting sales.

**13.** As a finance manager, I want to download invoices for the past 12 months in PDF format, so that I can submit them to our accounting department for tax reporting.

### Notifications

**14.** As a user who submitted a feature request, I want to receive an email when the status changes to "Planned" or "Shipped," so that I know my feedback was heard and can see the result.

**15.** As a team admin, I want to configure which notification types are enabled for my workspace, so that my team is not overwhelmed by alerts they do not need.

![INVEST criteria checklist for user stories](/blog/user-story-examples/invest-checklist.webp)

## The INVEST criteria

Good user stories follow the INVEST framework:

| Criterion | What it means | How to check |
|---|---|---|
| **Independent** | The story can be developed without depending on other stories | Can it be built and shipped on its own? |
| **Negotiable** | The implementation details are open for discussion | Does the story describe the goal, not the solution? |
| **Valuable** | The story delivers value to the user or business | Does the "so that" clause describe real value? |
| **Estimable** | The team can estimate the effort required | Is the scope clear enough to assign story points? |
| **Small** | The story fits within a single sprint | Can it be completed in 1-2 weeks? |
| **Testable** | You can write [acceptance criteria](/blog/acceptance-criteria) for it | Can you define pass/fail conditions? |

If a story fails any of these tests, it needs refinement. The most common failures are stories that are too large (not Small) and stories that describe a solution instead of a goal (not Negotiable).

## Splitting large stories

When a story is too large for a sprint, it is an epic that needs to be split into smaller stories. Here are practical splitting patterns:

**By user workflow step:**

Epic: "As a user, I want to manage my subscription"

Split into:
- As a user, I want to view my current plan and billing details
- As a user, I want to upgrade to a higher plan with prorated billing
- As a user, I want to downgrade to a lower plan at the end of my billing period
- As a user, I want to cancel my subscription with a confirmation step

**By user role:**

Epic: "As a user, I want to manage team members"

Split into:
- As an admin, I want to invite new team members by email
- As an admin, I want to change a team member's role
- As a member, I want to leave a workspace

**By data variation:**

Epic: "As a user, I want to export data"

Split into:
- As a user, I want to export data as CSV
- As a user, I want to export data as PDF
- As a user, I want to schedule recurring exports

## From customer feedback to user stories

Feature requests submitted through a [feedback board](/features/feedback) are user stories waiting to be formalized. The translation is often straightforward:

**Feedback submission:** "It would be great if I could see which features my team voted for. Right now I have to check each person individually."

**User story:** As a team admin, I want to see a summary of my team's votes across all feature requests, so that I can understand our collective priorities without checking each person's profile individually.

The feedback provides the persona (team admin), the goal (see team votes), and the reason (understand collective priorities). Your job is to formalize the language and validate that the stated problem represents broader demand — which is what vote counts on a feedback board tell you.

When multiple users submit variations of the same request, the combined feedback reveals the user story more clearly than any single submission. Five people asking for "team analytics" in different words tells you the story is about visibility into team activity, not a specific chart or dashboard.

[Quackback](/) is an open-source feedback board (AGPL-3.0) built for this workflow. Its [MCP server](/features/mcp) lets you query feedback from an AI assistant, so you can turn the top-voted requests into draft user stories without copy-pasting between tools. You can invite your whole team to read and vote on feedback.

## Common mistakes

**Omitting the "so that" clause.** Without the reason, engineering cannot make trade-off decisions. "I want to export data" could mean exporting to CSV for Excel, exporting to JSON for API consumption, or exporting to PDF for a presentation. The reason narrows the scope.

**Writing solutions instead of goals.** "I want a dropdown menu" is a UI specification, not a user story. "I want to filter my view by project" is a goal that might be implemented as a dropdown, a sidebar filter, a search bar, or something else entirely.

**Using "as a user" for every story.** If the persona is always "user," you are not distinguishing between different user types with different needs. An admin story and a viewer story have different constraints even if the feature overlaps.

**Making stories too large.** If a story takes more than two weeks to complete, it is too large. Split it using the patterns above. Large stories hide complexity and make estimation unreliable.

**Writing acceptance criteria into the story.** The story describes the goal. [Acceptance criteria](/blog/acceptance-criteria) describe the conditions for completion. Keep them separate so the story stays concise and the criteria stay testable.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How long should a user story be?

One to two sentences. The story itself is deliberately concise — it is a placeholder for a conversation, not a specification document. Details belong in acceptance criteria and design documents, not in the story.

### Who writes user stories?

The product manager writes most user stories, but anyone can contribute. Engineering, design, support, and sales teams all observe user needs that should become stories. The PM's role is to validate, prioritize, and ensure stories follow a consistent format.

### How many user stories should be in a sprint?

Enough to fill the team's capacity based on story point estimates, typically five to fifteen stories depending on team size and story complexity. The number matters less than whether each story is small enough to complete within the sprint.

### Should user stories include technical details?

No. User stories describe what the user needs, not how to implement it. Technical details belong in implementation notes, architecture documents, or spike stories. Keeping stories non-technical ensures they remain negotiable and focused on user value.

### How do user stories relate to feature requests?

A feature request is a raw expression of user need; a user story is the formalized version naming the persona, goal, and reason. Requests collected on a [feedback board](/features/feedback) are the input, and stories are the output. Converting one means validating demand, clarifying the problem, and scoping the smallest valuable story.

- [Acceptance Criteria: How to Write Them Well (With Examples)](https://quackback.io/blog/acceptance-criteria): Vague acceptance criteria are the top cause of scope creep and rework. Here is how to write criteria that are testable, specific, and grounded in real user needs.

Published: 2026-03-28

The most expensive bugs are not code errors. They are features that work exactly as specified — but the specification was wrong.

![Vague vs testable acceptance criteria](/blog/acceptance-criteria/hero.webp)

Acceptance criteria define what "done" means for a user story. They are the contract between product and engineering — the specific, testable conditions that a feature must satisfy before it ships. When acceptance criteria are vague ("the page should load fast"), engineering interprets them differently than product intended, QA cannot write meaningful tests, and the result is either rework or a feature that technically passes but does not solve the user's problem.

> **To write good acceptance criteria, describe the feature's behavior from the user's perspective as specific, binary conditions that either pass or fail.** Use one of three formats — Given/When/Then, a checklist, or scenario-based — and replace every vague word with a number ("fast" becomes "under 2 seconds"). Ground the criteria in real user feedback so they cover the edge cases and expectations users actually have.

## What acceptance criteria are (and are not)

**Acceptance criteria** are the conditions a feature must meet to be accepted by the product owner. They describe behavior from the user's perspective: what happens when the user does X, what the system shows, and what state changes occur.

They are not:

- **Requirements** — requirements describe what to build at a high level. Acceptance criteria describe how to verify it works.
- **User stories** — the user story describes the goal ("As a user, I want to filter reports by date"). Acceptance criteria describe the testable behaviors that satisfy that goal.
- **Technical specifications** — acceptance criteria describe what the user experiences, not how the code implements it. "Data is cached in Redis" is a technical decision, not an acceptance criterion.
- **Definition of done** — the definition of done is a team-level checklist that applies to all work (code reviewed, tests passing, deployed to staging). Acceptance criteria are specific to an individual story.

## Three formats for writing acceptance criteria

### Given/When/Then (Gherkin)

The most structured format, originally designed for behavior-driven development (BDD). Each criterion follows a three-part pattern:

- **Given** — the initial context or precondition
- **When** — the action the user takes
- **Then** — the expected outcome

**Example:**

> **Given** a user is on the dashboard with date filters visible
> **When** the user selects "Last 7 days" from the date dropdown
> **Then** the dashboard updates to show only data from the past 7 days, and the date range label displays the selected range

**Best for:** Complex interactions with multiple preconditions. Teams practicing BDD where criteria map directly to automated tests.

### Checklist format

A simple list of pass/fail conditions. Each item is a binary statement that can be verified.

**Example:**

- [ ] The search bar is visible on all pages
- [ ] Search returns results within 2 seconds for queries under 100 characters
- [ ] Results display title, description, and date for each match
- [ ] "No results found" message appears when the query matches zero items
- [ ] Search input is sanitized to prevent script injection

**Best for:** Straightforward features where a flat list of verifiable conditions is sufficient. Most teams default to this format for its simplicity.

### Scenario-based format

Describes specific user scenarios end-to-end, covering the happy path and common edge cases.

**Example:**

**Scenario 1: Successful password reset**
The user clicks "Forgot password," enters their registered email, receives a reset link within 60 seconds, and can set a new password that meets the strength requirements.

**Scenario 2: Unregistered email**
The user enters an email that is not in the system. The form displays a generic message ("If an account exists, a reset link has been sent") without revealing whether the email is registered.

**Scenario 3: Expired reset link**
The user clicks a reset link more than 24 hours after it was generated. The page displays "This link has expired" with an option to request a new one.

**Best for:** Features with multiple user paths where edge cases matter as much as the happy path.

## 10 real-world examples

### 1. User onboarding flow

- [ ] New users see the onboarding wizard on first login
- [ ] The wizard has 4 steps: profile, workspace, invite team, first project
- [ ] Users can skip any step and return to it later from settings
- [ ] Completing all 4 steps dismisses the wizard permanently
- [ ] Progress is saved if the user closes the browser mid-wizard

### 2. Search functionality

**Given** the user has typed at least 3 characters in the search bar
**When** the user pauses typing for 300ms
**Then** the system displays up to 10 matching results in a dropdown, ranked by relevance, within 500ms

**Given** the search returns no results
**When** the dropdown renders
**Then** it displays "No results for [query]. Try a different search term."

### 3. Email notification preferences

- [ ] Users can toggle email notifications on/off for each notification type independently
- [ ] Changes save immediately without requiring a "Save" button click
- [ ] A toast confirmation appears: "Notification preferences updated"
- [ ] Toggling "All notifications off" disables every individual toggle
- [ ] Re-enabling "All notifications" restores each toggle to its previous state (not all-on)

### 4. CSV data export

- [ ] The export button is visible to users with Admin or Editor roles
- [ ] Clicking "Export" generates a CSV file containing all visible columns in the current view
- [ ] Exported files use UTF-8 encoding with BOM for Excel compatibility
- [ ] Files larger than 10,000 rows generate in the background with an email notification when complete
- [ ] The filename follows the pattern: `[workspace]-[view]-[YYYY-MM-DD].csv`

### 5. Role-based access control

**Given** a user with the Viewer role navigates to the settings page
**When** the page loads
**Then** all form fields are visible but disabled, and a banner displays "You need Editor or Admin access to change settings"

**Given** an Admin removes a user's Editor role
**When** the role change is saved
**Then** the affected user's session is updated within 60 seconds without requiring them to log out and back in

### 6. API rate limiting

- [ ] The API enforces a rate limit of 100 requests per minute per API key
- [ ] When the limit is exceeded, the API returns HTTP 429 with a `Retry-After` header indicating seconds until the next allowed request
- [ ] The response body includes a JSON error: `{"error": "rate_limit_exceeded", "retry_after": <seconds>}`
- [ ] Rate limit counters reset at the start of each calendar minute

### 7. Feedback widget integration

- [ ] The widget loads within 2 seconds of page load on supported browsers (Chrome, Firefox, Safari, Edge — latest 2 versions)
- [ ] The widget trigger button is visible after the identify call resolves
- [ ] Clicking the trigger opens the feedback panel with a slide-in animation under 300ms
- [ ] Submissions appear on the [feedback board](/features/feedback) within 5 seconds
- [ ] The widget does not affect the host page's Cumulative Layout Shift score

### 8. Two-factor authentication setup

**Given** a user navigates to Security settings and clicks "Enable 2FA"
**When** the setup modal opens
**Then** it displays a QR code and a manual entry key, with instructions for authenticator apps

**Given** the user scans the QR code and enters a valid 6-digit code
**When** the user clicks "Verify"
**Then** 2FA is enabled, recovery codes are displayed (downloadable as a text file), and a confirmation email is sent

**Given** the user enters an incorrect 6-digit code three times
**When** the third failed attempt occurs
**Then** the verify button is disabled for 30 seconds with a countdown timer

### 9. Billing plan upgrade

- [ ] The upgrade button shows the price difference between the current and target plan (prorated for the remaining billing period)
- [ ] Clicking "Confirm upgrade" charges the prorated amount to the payment method on file
- [ ] The new plan features are available within 30 seconds of successful payment
- [ ] A confirmation email includes the amount charged, new plan name, and next renewal date
- [ ] If payment fails, the user stays on their current plan with an error message and a link to update payment details

### 10. Slack integration setup

- [ ] Clicking "Connect to Slack" redirects to Slack's OAuth authorization page
- [ ] After authorization, the user is redirected back with the connected workspace name displayed
- [ ] The user can select which Slack channels receive notifications from a multi-select dropdown
- [ ] Test notification sends a formatted message to the selected channel within 10 seconds
- [ ] Disconnecting removes the OAuth token and stops all notifications within 60 seconds

![Transforming vague acceptance criteria into testable ones](/blog/acceptance-criteria/vague-vs-testable.webp)

## How to write testable criteria

Every acceptance criterion should be **binary** — it either passes or fails. If a criterion requires judgment to evaluate ("the page loads reasonably fast"), it is not testable.

**Vague → Testable:**

| Vague | Testable |
|---|---|
| The page should load fast | The page renders in under 2 seconds on a 4G connection |
| Error handling should be good | All API errors return a JSON body with `error` and `message` fields |
| The form should validate input | Email fields reject strings without an @ symbol and display an inline error within 200ms |
| The feature should work on mobile | The layout renders correctly on viewports from 320px to 768px wide |
| Search should be accurate | The first result matches the user's exact query in 90% of test cases |

**The number test:** If you can replace the vague word with a number, you should. "Fast" becomes "under 2 seconds." "Reasonable" becomes "within 24 hours." "Many" becomes "up to 50."

## Using customer feedback to write better criteria

The best acceptance criteria are grounded in real user behavior, not assumptions. [Feature requests](/features/feedback) and the comments attached to them provide this grounding.

When 47 users vote for a feature, their comments describe the problem in their own words. These descriptions contain the edge cases, workflows, and expectations that your acceptance criteria need to cover. A feature request that says "I need to export my data to share with my manager in Excel" tells you the export needs Excel compatibility — a criterion you might miss if you wrote it from the engineering perspective alone.

The pattern: read the feedback, extract the implicit expectations, and convert them into testable criteria. "Users want to filter by date" becomes the specific behaviors described in Example 2 above. The feedback provides the "what users expect." The acceptance criteria formalize it into "what we will verify." This is also where the same input shapes your [user story](/blog/user-story-examples) — the story states the goal, the criteria state the proof.

[Quackback](/features/feedback) keeps that loop close. It is open source, so the feedback that grounds your criteria lives in a board you control rather than a black box. Its [MCP server](/features/mcp) exposes that feedback to AI agents directly, so an assistant can read the votes and comments on a request and draft a first pass of acceptance criteria you then refine.

## Common mistakes

**Too vague.** "The feature should work correctly" is not an acceptance criterion. If it cannot fail a test, it is not testable.

**Too detailed.** Specifying CSS properties, database queries, or implementation algorithms in acceptance criteria couples them to technical decisions that should remain flexible. Describe the behavior, not the implementation.

**Missing edge cases.** The happy path is the easy part. What happens when the input is empty? When the network is slow? When the user does not have permission? Edge cases are where most bugs live.

**Mixing criteria with tasks.** "Set up the database migration" is a task, not a criterion. Criteria describe what the user experiences, not what the developer does to make it happen.

**Writing them after development starts.** Acceptance criteria should be agreed on before a sprint begins. Writing them mid-development leads to moving goalposts and scope creep.

**Not involving engineering.** Product writes criteria, engineering discovers they are technically impossible or prohibitively expensive. Writing criteria collaboratively surfaces constraints early.

---

> **Try Quackback** — open source with a managed cloud option. Collect the feedback that grounds your acceptance criteria, then let the [MCP server](/features/mcp) hand it to your AI agent. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How many acceptance criteria should a user story have?

Three to eight is the sweet spot. Fewer than three suggests the story is trivial or under-specified. More than eight suggests the story is too large and should be split. Consistently writing more than ten criteria per story is a sign your stories are really epics.

### Who writes acceptance criteria?

The product manager or product owner writes the initial criteria. Engineering reviews them for feasibility and completeness. QA reviews them for testability. The final criteria are a collaborative output, not a one-person document.

### Should acceptance criteria include non-functional requirements?

Yes, when they are specific to the story. "The export completes within 30 seconds for datasets under 10,000 rows" is a valid performance criterion for an export feature. Global non-functional requirements (uptime, general page load times) belong in the definition of done, not individual story criteria.

### What is the difference between acceptance criteria and test cases?

Acceptance criteria define what to verify. Test cases define how to verify it. One acceptance criterion ("search returns results within 500ms") might generate multiple test cases (test with 1 result, 100 results, 0 results, special characters, very long queries). Criteria come from product; test cases come from QA.

### How do acceptance criteria relate to the definition of done?

The definition of done is a team-level checklist that applies to all work: code reviewed, tests passing, deployed to staging, documentation updated. Acceptance criteria are story-specific conditions that describe the feature's behavior. A story is complete when it meets both its acceptance criteria and the team's definition of done.

- [Product Development Process: A 7-Stage Guide for Teams](https://quackback.io/blog/product-development-process): A practical guide to the seven stages of product development. What happens at each stage, who is involved, and where most teams go wrong.

Published: 2026-03-28

Two-thirds of new products fail within two years of launch. The most common cause is not bad engineering. It is a bad process — or no process at all.

![Seven stages of the product development process](/blog/product-development-process/hero.webp)

> The **product development process** is the structured sequence of stages a team follows to turn an idea into a shipped, validated product: ideation, discovery, definition, design, development, launch, and iteration. The teams that succeed are not the most talented — they are the ones with a clear process and a tight feedback loop at every stage.

Around two-thirds of new products fail within two years of launch. Products that rank highest for differentiation reach a 98% success rate, compared with 18.4% for the least differentiated — a gap [Robert Cooper's NewProd research](https://wearemagnetic.com/events-insights/our-stories/insights/what-makes-products-successful) ties directly to how well teams understand and validate the problem before building.

This guide covers the seven stages of product development, what happens at each stage, and where customer feedback fits in. If you are building a new product or adding major features to an existing one, this is the process that separates the products that succeed from the ones that do not.

## What is the product development process?

The **product development process** is the structured sequence of stages a team follows to take a product from initial idea to launch and ongoing iteration. It typically spans seven stages — ideation, discovery and research, definition and planning, design and prototyping, development and testing, launch, and analyze and iterate — each with its own owners, outputs, and decisions. A clear process turns a chaotic build into a repeatable system, and customer feedback feeds into every stage of it.

## The seven stages

### 1. Ideation

**What happens:** You generate and capture ideas for what to build. Ideas come from customer feedback, market research, competitive analysis, team brainstorms, and strategic objectives.

**Who is involved:** Product managers, founders, customer-facing teams (support, sales, CS).

**Key outputs:** A list of candidate ideas with rough descriptions of the problem each one solves.

**Where teams go wrong:** Jumping to solutions before understanding the problem. "We should build a Slack integration" is a solution. "Our users lose feedback that comes through Slack" is a problem. Start with problems.

**How feedback fits in:** [Feature request boards](/features/feedback) and [voting](/features/voting) are the highest-signal source of ideation input. They tell you not just what customers want, but how many customers want it. Support ticket analysis and sales call notes add context that pure vote counts miss.

### 2. Discovery and research

**What happens:** You validate that the problem is real, painful, and worth solving. You talk to customers, analyze usage data, study competitors, and size the opportunity.

**Who is involved:** Product managers, UX researchers, data analysts.

**Key outputs:** Problem validation, user personas, opportunity sizing, competitive landscape.

**Where teams go wrong:** Skipping this stage entirely. Dedicated research teams almost always run pre-design research, but most companies overall do little to no UX testing. The ones that skip discovery are building on assumptions instead of evidence.

**How feedback fits in:** Customer interviews are the gold standard, but they do not scale. [AI-powered feedback analysis](/blog/ai-customer-feedback-analysis) can surface patterns across hundreds of feedback submissions, support tickets, and reviews — identifying which problems are most painful before you invest in interviews. For a deeper framework, see our guide on [continuous discovery habits](/blog/continuous-discovery-habits).

### 3. Definition and planning

**What happens:** You scope the solution. What are you building? What are you not building? How will you measure success? You write specs, prioritize features, and build a roadmap.

**Who is involved:** Product managers, engineering leads, design leads.

**Key outputs:** Product requirements, prioritized feature list, success metrics, timeline estimates.

**Where teams go wrong:** Over-specifying upfront. A detailed 50-page spec for a feature that has never been tested with users is waste. Define enough to start building, then learn from what you ship.

**How feedback fits in:** Prioritization frameworks like [RICE](/blog/rice-framework-explained) and [MoSCoW](/blog/moscow-prioritization) use customer demand as an input. Vote counts, request frequency, and customer segment data from your feedback tool inform which features make the cut. A [prioritization matrix](/blog/prioritization-matrix-template) helps you weigh impact against effort using real data instead of gut feel.

### 4. Design and prototyping

**What happens:** Designers create wireframes, mockups, and interactive prototypes. The team tests concepts with users before writing production code.

**Who is involved:** Product designers, UX researchers, product managers.

**Key outputs:** Wireframes, prototypes, usability test results.

**Where teams go wrong:** Treating design as "making it pretty" instead of "making it work." Design is problem-solving. A beautiful interface that users cannot figure out is a failed design.

**How feedback fits in:** Early usability testing with prototypes catches fundamental problems that are expensive to fix later. Internal dogfooding — using the prototype yourself — catches obvious issues. But neither replaces testing with real users who do not know how the feature is supposed to work.

### 5. Development and testing

**What happens:** Engineering builds the feature in sprints or iterations. QA runs functional and regression tests. Beta programs put the feature in front of real users.

**Who is involved:** Engineers, QA, product managers, beta users.

**Key outputs:** Working software, test results, beta feedback.

**Where teams go wrong:** Treating "development complete" as "done." Code that passes tests is not the same as a feature that solves the user's problem. Beta programs bridge this gap by exposing the feature to real workflows before general release.

**How feedback fits in:** Beta feedback is the last chance to catch problems before they hit your full user base. A [feedback widget](/features/widget) embedded in the beta version makes it easy for testers to report issues in context, with screenshots and session details attached.

### 6. Launch

**What happens:** The feature ships to all users. Marketing, sales, support, and documentation are coordinated. The launch is communicated through changelogs, emails, in-app announcements, and social media.

**Who is involved:** Product, marketing, sales, support, documentation.

**Key outputs:** Release notes, [changelog entries](/features/changelog), support documentation, sales enablement materials.

**Where teams go wrong:** Under-investing in launch communication. [McKinsey research](https://hbr.org/1991/01/the-return-map-tracking-product-teams) found companies lose 33% of after-tax profit by shipping six months late, but only 3.5% from overspending 50% on development. Speed matters, but so does making sure customers know what you shipped and how to use it. A great feature that nobody discovers is a wasted feature.

**How feedback fits in:** [Product update announcements](/blog/product-update-announcement) close the feedback loop. When you ship something a customer requested, telling them directly converts a one-time requester into a long-term advocate.

### 7. Analyze and iterate

**What happens:** You measure how the feature performs against success metrics. You track adoption, usage patterns, satisfaction, and business impact. Learnings feed back into the next cycle.

**Who is involved:** Product managers, data analysts, customer-facing teams.

**Key outputs:** Performance dashboards, iteration priorities, learnings for the next cycle.

**Where teams go wrong:** Moving on to the next feature without analyzing how the current one performed. If you do not measure, you do not learn. If you do not learn, you repeat the same mistakes.

**How feedback fits in:** Post-launch feedback is the richest signal for what to build next. Feature-specific feedback, NPS changes, and support ticket patterns tell you whether the feature solved the problem or created new ones. This data feeds directly back into Stage 1, creating a continuous cycle.

![How customer feedback fits into each stage of product development](/blog/product-development-process/feedback-at-each-stage.webp)

## Choosing a framework

The seven stages above are framework-agnostic. How you execute each stage depends on which methodology fits your team and context.

### Stage-Gate

Sequential phases separated by approval checkpoints ("gates"). Each gate requires specific deliverables before the project advances. Best for hardware, regulated industries, and organizations that need formal governance. Risk is controlled upfront through detailed planning.

### Agile

Iterative sprints (typically two weeks) that ship increments of working software. Requirements evolve based on what you learn each sprint. Best for software teams with changing requirements. Risk is managed by shipping early and adapting continuously.

### Lean Startup

Build-Measure-Learn loops focused on testing hypotheses with minimum viable products. Best for early-stage products and unvalidated markets. Risk is managed by testing cheaply before investing heavily. See our guide on [value hypotheses](/blog/value-hypothesis) for the foundation of this approach.

### Hybrid (most common)

In practice, most teams blend these approaches. Many "best practice" physical-product firms run Agile sprints inside traditional Stage-Gate phases — using gates for governance and sprints for iteration. The frameworks are not mutually exclusive.

![Stage-Gate vs Agile vs Lean Startup approaches to product development](/blog/product-development-process/frameworks-compared.webp)

## B2B vs B2C differences

The process is the same, but the execution differs.

| Dimension | B2B | B2C |
|---|---|---|
| **Feedback collection** | Direct relationships, smaller sample, deeper insight | Aggregated at scale, surveys, analytics, A/B tests |
| **Validation** | Pilots, POCs, design partnerships with key accounts | A/B tests, soft launches, feature flags |
| **Release cadence** | Slower, with migration concerns and customer training | Faster, driven by competitive pressure |
| **UX tolerance** | Users tolerate clunky UX if it solves workflow problems | Users abandon immediately if UX is poor |
| **Sales cycle** | 6-24 months, 6-10 decision-makers | Minutes to days, individual decision |

For B2B teams, the feedback connection is especially strong. With fewer customers and higher value per account, losing even one customer to a missed feature request is expensive. Structured [feedback management](/blog/best-customer-feedback-tools-2026) is not optional — it is the primary input to your product development process.

The tool you use to run that loop matters too. [Quackback](/features/feedback) is open source (AGPL-3.0), so you can give every product manager, support rep, and engineer access to feedback. Its [MCP server](/features/mcp) lets you query feedback directly from AI assistants, and AI-powered analysis is built in. Run it [self-hosted for free](/pricing) or on [Quackback Cloud](/pricing) if you would rather not manage infrastructure.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How long does product development take?

Software products typically take 3 to 9 months from ideation to launch, while consumer goods average around 13 months. Speed tends to matter more than budget: McKinsey found companies lose 33% of after-tax profit by shipping six months late.

### What is the most important stage?

Discovery and research. Products built on well-executed predevelopment work succeed far more often than those that skip it, and most failed products turn out to have ignored customer feedback early on. Skipping discovery to "move fast" is the most expensive shortcut in product development.

### Should we use Agile or Waterfall?

Most modern software teams use Agile or a hybrid approach. Pure waterfall is rare because it assumes you can predict requirements upfront, while Agile handles uncertainty better by shipping and adapting. Some stages, like discovery and definition, still benefit from being largely complete before development starts.

### How does customer feedback fit into product development?

Feedback should inform every stage: ideation (what to build), discovery (validating the problem), definition (prioritizing features), development (beta testing), launch (closing the loop), and iteration (measuring success). The high failure rate among products that ignore feedback makes it a core input, not an afterthought.

### What are the biggest reasons products fail?

The top reasons are solving a problem nobody has, poor timing, ignoring customer feedback, over-engineering the first version, and underinvesting in go-to-market. Most are process failures, not engineering failures — they happen in the first three stages, not the build stage.

- [Amplitude Pricing in 2026: Plans, MTU Costs, and Cheaper Alternatives](https://quackback.io/blog/amplitude-pricing): Amplitude bills by monthly tracked users and events. Here is what each plan costs, how the billing model works, and where open-source alternatives save you money.

Published: 2026-03-27

Amplitude's free tier tracks 50,000 monthly users. That is generous for a startup. The problem starts when you grow past it and discover what enterprise product analytics actually costs.

![Amplitude pricing scaling with monthly tracked users](/blog/amplitude-pricing/hero.webp)

> Amplitude offers four plans: a free Starter tier (50,000 MTUs), Plus from $49/month, and custom Growth and Enterprise contracts. It bills on a dual model — monthly tracked users (MTUs) and events per MTU — so you can exceed either limit independently and pay 1.2x your rate on the overage. Mixpanel and the open-source PostHog are usually cheaper and easier to budget at scale.
>
> *Pricing last verified March 2026. Vendors may change plans and pricing without notice.*

Amplitude uses a dual billing model: monthly tracked users (MTUs) and events per MTU. You can be under your user limit but over on events, or vice versa. Both trigger overage charges at 1.2x your contracted rate. This makes budgeting difficult for products with unpredictable growth or power-user-heavy engagement patterns.

## Amplitude pricing plans

| Plan | Price | MTU limit | Data retention |
|---|---|---|---|
| **Starter (Free)** | $0 | 50,000 MTUs | 12 months |
| **Plus** | From $49/mo | 1,000-300,000 MTUs | Up to 2 years |
| **Growth** | Custom | 300,000+ MTUs | Custom |
| **Enterprise** | Custom | 500,000-1M+ MTUs | Custom |

### Plus plan pricing by MTU volume

| MTUs | Monthly cost | Annual cost |
|---|---|---|
| 1,000 | ~$61 | ~$588 |
| 10,000 | ~$161 | ~$1,548 |
| 25,000 | ~$311 | ~$2,988 |
| 50,000 | ~$561 | ~$5,388 |
| 100,000 | ~$1,061 | ~$10,188 |

Annual billing saves approximately 20%. The Plus plan tops out around 300,000 MTUs — beyond that, you need a Growth or Enterprise contract.

### Real-world contract costs

Based on [verified contract data from Vendr's marketplace](https://www.vendr.com/marketplace/amplitude), the median Amplitude contract is roughly $63,720 per year. Companies tracking 100,000 to 500,000 MTUs commonly pay $30,000 to $150,000 annually. Deployments exceeding one million MTUs can exceed $200,000 per year.

![Amplitude's dual billing constraint: MTUs and events can both trigger overages](/blog/amplitude-pricing/dual-billing.webp)

## How MTU and event billing works

**Monthly Tracked Users (MTUs)** are the primary billing unit. Any end user who triggers at least one event in a calendar month counts as one MTU.

**Events** are capped relative to MTUs. You get 1,000 events per MTU purchased. A plan with 10,000 MTUs allows 10 million events per month. Exceed either limit and Amplitude charges 1.2x your per-unit rate for the overage.

**What counts as an event:** Any tracked user action — page views, button clicks, form submissions, API calls, feature interactions. Each discrete action is one event.

**The dual constraint:** This is where costs get unpredictable. A product with 5,000 monthly users who each trigger 500 events is fine on a 10,000 MTU plan (5,000 MTUs used, 5 million events used out of 10 million). But a product with 5,000 power users who each trigger 3,000 events would exceed the event cap (15 million events vs 10 million allowed) while being under the MTU limit. Both users and events can trigger overages independently.

**Monthly reset:** MTU and event counts reset on the first of each calendar month. Overages are calculated on the last day of each month.

## What each plan includes

### Starter (free)

Foundational product analytics, session replay, unlimited feature flags, unlimited data sources and destinations, and starter templates. Limited chart saves and no custom events. Adequate for early-stage products that need basic analytics without advanced segmentation.

### Plus ($49+/month)

Everything in Starter plus unlimited chart saves, custom events, dashboard filters and formulas, up to five behavioral cohorts, custom audiences and syncs, AI-powered data assistant, data quality monitoring, and online support.

### Growth (custom pricing)

Everything in Plus plus advanced behavioral analysis, custom KPI metrics, causal insights monitoring, A/B and multivariate testing (Amplitude Experiment), real-time data streaming and syncs, and priority support.

### Enterprise (custom pricing)

Everything in Growth plus advanced governance and security (SOC 2, HIPAA compliance), dedicated support and customer success manager, custom data retention, bundled Experiment and CDP capabilities, and SSO/SCIM provisioning.

## Hidden costs and gotchas

### Overage penalties

Exceeding your MTU or event cap triggers a 1.2x multiplier on your contracted rate. An unexpected traffic spike — a product going viral, a bot crawling your site, a marketing campaign outperforming projections — can generate significant overage charges before you can react.

### Add-on products

Several capabilities that many teams consider core are sold as separate products:

- **Amplitude Experiment** (A/B testing): $20,000-$60,000+ per year
- **Amplitude CDP** (data streaming and audience syncing): $15,000-$50,000+ per year
- **Professional services** (implementation, training): $10,000-$50,000+ for enterprise

### Contract lock-in

Growth and Enterprise plans are typically annual contracts. Cancellation means paying through the end of the term.

### The event-per-MTU cap

This is the most common surprise. Teams budget for a certain number of MTUs without realizing that event volume per user can independently trigger overages. Products with power users (project management tools, analytics dashboards, collaboration platforms) hit this ceiling faster than expected.

## Free and cheaper alternatives

| Tool | Free tier | Paid starting price | Billing model | Best for |
|---|---|---|---|---|
| **Mixpanel** | 1M events/mo | ~$0.28/1K events | Per event | Mid-market analytics, transparent pricing |
| **PostHog** | 1M events + 5K recordings/mo | ~$0.05/1K events | Per event, usage-based | Technical teams, self-hosting option |
| **Heap** | 10K sessions/mo, 6-month retention | ~$2,500/mo (Growth) | Per session | Auto-capture, low-engineering-effort teams |
| **Google Analytics 4** | Unlimited (with sampling) | $50,000/yr (GA4 360) | Free / enterprise | Marketing analytics, basic product |

**Mixpanel** is the most direct competitor. One million free events per month is generous. Pricing is transparent and per-event, making it easier to budget than Amplitude's dual MTU+event model. At 10 million events per month, Mixpanel costs roughly $2,520/month compared to Amplitude's custom Growth pricing.

**PostHog** is the cheapest at scale — 30-50% less than SaaS competitors. Open source with a self-hosting option. One million free events per month with volume discounts up to 82%. Best for technical teams willing to invest in setup.

**Heap** captures everything automatically without manual event instrumentation. The trade-off is cost — the Growth plan at approximately $100,000 per year for 5 million sessions is expensive. Heap was acquired by Contentsquare.

**Google Analytics 4** is free and unlimited for basic web analytics, but it is not a product analytics tool. It lacks behavioral cohorts, funnel analysis, and the event-level granularity that Amplitude, Mixpanel, and PostHog provide.

### Pairing quantitative analytics with qualitative feedback

Product analytics tools like Amplitude tell you what users do. They do not tell you why. A drop in feature adoption shows up in the data, but the reason — confusing UI, missing functionality, or a competitor doing it better — requires qualitative signal.

Pairing analytics with a [customer feedback tool](/blog/best-customer-feedback-tools-2026) closes this gap. When Amplitude shows declining engagement with a feature, feedback from your [feedback board](/features/feedback) explains what went wrong. When a [feature request](/features/voting) gets 200 votes, Amplitude data shows whether the requesting users are high-value or at-risk. The quantitative and qualitative signals reinforce each other.

This is where **Quackback** fits. Quackback is open source (AGPL-3.0) and self-hostable for free, with a managed [Quackback Cloud](/pricing) for teams that do not want to run infrastructure. Its built-in AI triages and summarizes feedback, and an [MCP server](/features/mcp) lets you query feedback directly from AI tools alongside your Amplitude data. The result is a single place where quantitative signal and qualitative "why" sit side by side.

## Is Amplitude worth it?

Amplitude is a strong product analytics platform with deep behavioral analysis capabilities. For teams that need cohort analysis, funnel optimization, and experimentation, the feature set is competitive with Mixpanel and more advanced than PostHog for non-technical users.

The value breaks down at two points. First, the MTU+event dual billing model makes costs unpredictable for growing products. Second, the opaque pricing on Growth and Enterprise plans forces sales conversations that smaller teams want to avoid. If transparent pricing and predictable costs matter more than the most advanced feature set, Mixpanel or PostHog are better fits.

For teams under 50,000 MTUs, the free Starter plan is one of the most generous in product analytics. Use it until you outgrow it, then compare Amplitude Plus pricing against Mixpanel and PostHog before committing.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Does Amplitude have a free plan?

Yes. Amplitude Starter is free for up to 50,000 monthly tracked users with 12 months of data retention. It includes foundational analytics, session replay, and unlimited feature flags. The main limitations are restricted chart saves and no custom events.

### How does Amplitude's MTU billing work?

A Monthly Tracked User (MTU) is any end user who triggers at least one event in a calendar month. You also get 1,000 events per MTU purchased. Exceed either your MTU cap or your total event cap and Amplitude charges 1.2x your contracted rate for the overage.

### Is Amplitude cheaper than Mixpanel?

At low volumes, Amplitude's free tier (50K MTUs) is more generous than Mixpanel's (1M events but no MTU-based allocation). At mid-to-high volumes, Mixpanel's transparent per-event pricing is typically cheaper and more predictable than Amplitude's custom Growth and Enterprise quotes. The median Amplitude contract is roughly $63,720/year based on Vendr's verified deal data.

### What is the cheapest product analytics tool?

PostHog is the cheapest at scale — open source, self-hostable, with usage-based pricing roughly 30-50% lower than Amplitude or Mixpanel. One million free events per month with volume discounts up to 82%. The trade-off is that it requires more technical setup and the UI is less polished for non-technical users.

### Can I use Amplitude for free long-term?

Yes. The Starter plan has no time limit. As long as you stay under 50,000 MTUs, it is free indefinitely. The limitations (12-month data retention, limited chart saves, no custom events) are real but acceptable for early-stage products that need basic analytics.

- [Customer Retention Strategies That Actually Work (With Real Examples)](https://quackback.io/blog/customer-retention-strategies): Acquiring a customer costs 5-25x more than keeping one. Here are the retention strategies that produced measurable results, backed by data and real company examples.

Published: 2026-03-27

Most SaaS companies spend the majority of their budget on acquisition and treat retention as something that happens naturally if the product is good enough. The data says otherwise.

![Retention as a leaky bucket — patching the holes matters more than pouring faster](/blog/customer-retention-strategies/hero.webp)

Acquiring a new customer costs 5 to 25 times more than retaining an existing one (Harvard Business Review). A 5% improvement in retention can increase profits by 25 to 95% (Bain & Company). The probability of selling to an existing customer is 60-70%, compared to 5-20% for a new prospect. Yet customer acquisition cost in SaaS has risen 55% over the past three years.

The math is clear. Here are the strategies that actually move the needle, with real numbers from companies that implemented them.

## The economics of retention

Before diving into strategies, it helps to understand what you are working with.

![SaaS churn benchmarks by company segment](/blog/customer-retention-strategies/churn-benchmarks.webp)

**SaaS churn benchmarks (2026 data):**

| Segment | Monthly churn | Annual churn |
|---|---|---|
| Enterprise SaaS (1,000+ employees) | 1-2% | 3-7% |
| Mid-market SaaS | 1.5-3% | ~5% |
| SMB-focused SaaS | 3-7% | 30-58% |
| Micro-business (under 10 employees) | ~9% | ~69% |

If your monthly churn is above 5%, you are losing more than half your customer base every year. Even a 3% monthly rate means losing roughly a third. The strategies below target specific churn drivers that compound over time.

## 8 retention strategies with proven results

### 1. Fix your onboarding

The first 90 days determine whether a customer stays or leaves. Users who do not reach their "aha moment" during onboarding are the most likely to churn — and the most expensive to lose, because you spent the full acquisition cost but captured minimal lifetime value.

Groove found that retained users had initial sessions averaging 3 minutes and 18 seconds. Churned users lasted only 35 seconds. Retained users logged in 4.4 times per day on average; churned users logged in 0.3 times.

**What to do:**
- Identify your activation metric — the specific action that correlates with long-term retention (Slack: 2,000 messages sent; Dropbox: one file saved to a shared folder)
- Design onboarding around reaching that action, not touring features
- Use progress indicators, contextual prompts, and milestone emails at 7, 30, and 60 days
- Measure time-to-first-value and optimize it relentlessly

**Example:** Zapier focused on guiding users to complete their first integration during onboarding. This milestone-based approach dropped their churn to 6-10%.

### 2. Build a feedback loop and close it

Customers who feel heard stay longer. Customers who feel ignored leave. It sounds obvious, but most companies collect feedback and never act on it — or worse, never tell the customer what happened.

![The four-stage feedback loop — most teams stop before communicating back](/blog/customer-retention-strategies/feedback-loop.webp)

The feedback loop has four stages: collect, analyze, act, communicate. Most companies stop after step one or two. The retention value comes from step four — telling customers their feedback led to a change.

**What to do:**
- Collect feedback systematically through [in-app widgets](/features/widget), [feedback boards](/features/feedback), NPS surveys, and churn surveys
- Prioritize fixes using an [impact-effort framework](/blog/prioritization-matrix-template)
- Close the loop: when you build something a customer requested, tell them. When you decide not to build something, explain why
- Make your [roadmap](/features/roadmap) public so customers can see their voice matters

**Example:** TripMaster uncovered a 20% onboarding drop-off through systematic feedback collection. Targeted improvements based on that feedback generated $504,758 in net new ARR within one year.

### 3. Implement customer health scoring

Waiting for customers to complain before acting is reactive. By the time a customer contacts support about a problem, they have already considered leaving. Health scoring identifies at-risk accounts before they reach that point.

**What to do:**
- Build a composite score from: login frequency, feature adoption breadth, support ticket volume and sentiment, payment history, and engagement with success resources
- Set automated triggers when scores drop below thresholds (declining logins over two weeks, feature usage drop-off, payment failure)
- Route at-risk accounts to a retention playbook: personalized outreach, executive check-in, or guided re-engagement

**Example:** Groove sent targeted intervention emails to users with low engagement metrics. The campaigns achieved a 26% response rate and 40% retention rate among at-risk users, contributing to a 71% overall churn reduction.

### 4. Drive feature adoption

Most customers use a fraction of your product. They signed up for one feature and never discovered the rest. When a competitor offers that one feature for less, they leave — not because your product is worse, but because they never experienced the difference.

**What to do:**
- Identify underused features that correlate with retention
- Use in-app tooltips, guided tours, and contextual suggestions to surface them
- Send targeted emails highlighting features relevant to each user's workflow
- Track feature adoption by cohort and tie it to retention rates

**Example:** SmartReach.io combined health scoring with feature adoption tracking. Automated alerts when users stopped engaging with key features drove targeted re-engagement that reduced churn by 35%.

### 5. Run proactive outreach campaigns

Do not wait for problems. Reach out to customers before they disengage.

**What to do:**
- Schedule automated check-ins at key lifecycle moments: 30 days post-onboarding, after major feature launches, before renewal dates
- Segment outreach by customer health score, plan tier, and usage patterns
- Personalize the message — "I noticed you have not tried [feature] yet" works better than "Just checking in"
- For high-value accounts, assign a dedicated success manager with quarterly business reviews

**Example:** StatusPage.io implemented automated re-engagement campaigns targeting accounts showing declining usage. The program saved $1.2 million in ARR.

### 6. Reduce involuntary churn

20 to 40% of total churn in SaaS is involuntary — failed credit cards, expired payment methods, billing errors. This is the easiest churn to fix because the customer did not decide to leave.

**What to do:**
- Implement smart retry logic for failed payments (retry on different days, not just immediately)
- Send pre-dunning emails before cards expire
- Offer multiple payment methods and make updating payment info easy
- Use a payment recovery service that handles retry optimization automatically

### 7. Offer pricing flexibility

Rigid pricing forces an all-or-nothing decision. When a customer's needs change — budget cuts, team downsizing, seasonal fluctuation — they either keep paying full price or cancel entirely.

**What to do:**
- Offer downgrade paths that let customers reduce their plan instead of canceling
- Consider usage-based pricing components (companies with usage-based models see 2.1% monthly churn versus 5.6% for flat-rate)
- Provide annual plan discounts that increase commitment without forcing it
- For at-risk accounts, offer retention discounts or plan pauses

**Example:** Rephrasely offered discounts on annual plans to convert monthly subscribers. The approach reduced churn by 56%.

### 8. Build community and co-creation

When customers participate in shaping your product, they develop psychological ownership. They are not just users — they are contributors. This investment raises switching costs in a way that contract lock-in cannot.

**What to do:**
- Create a [public feedback board](/features/feedback) where customers can submit ideas and [vote on priorities](/features/voting)
- Share your [changelog](/features/changelog) and credit the customers whose feedback drove changes
- Build a community forum or Slack group for power users
- Run beta programs that give active customers early access to new features

**Example:** HubSpot built a Customer Happiness Index (CHI) tracking usage frequency, social engagement, and feature adoption. Personalized interventions based on this index retained 33% of previously unhappy customers.

## How to prioritize these strategies

Not every strategy applies equally to every company. Here is a decision framework:

| If your churn is driven by... | Start with... |
|---|---|
| Users not reaching value | Onboarding optimization (#1) |
| Users leaving without explanation | Feedback loops (#2) and health scoring (#3) |
| Payment failures | Involuntary churn reduction (#6) |
| Competitor switching | Feature adoption (#4) and community (#8) |
| Budget constraints | Pricing flexibility (#7) |
| General disengagement | Proactive outreach (#5) |

If you do not know what is driving your churn, start with feedback loops. You cannot fix a problem you do not understand, and systematic [feedback collection](/blog/collect-customer-feedback) is the fastest way to surface the root cause.

## Common mistakes

**Treating retention as a support function.** Retention is a product function. Support handles individual problems; retention addresses systemic patterns. If your retention strategy lives in the support team, it is too late by definition.

**Measuring only revenue churn.** Logo churn (the number of customers who leave) matters as much as revenue churn (the dollars they take with them). A company can have positive net revenue retention while losing 30% of its customer base annually. That is not retention — it is expansion revenue masking a churn problem.

**Offering discounts instead of fixing the product.** Retention discounts buy time. They do not solve the underlying problem. If customers leave because onboarding is broken, a 20% discount does not fix onboarding. Use discounts as a bridge while you fix root causes, not as a permanent strategy.

**Ignoring silent accounts.** The accounts most likely to churn are not the ones filing support tickets. They are the ones that stopped logging in and never complained. Silent accounts churn faster than vocal ones — build systems to detect and engage them.

## Frequently asked questions

### What is a good churn rate for SaaS?

It depends on your segment. Enterprise SaaS companies target less than 5% annual churn. Mid-market targets less than 10%. SMB churn rates of 3-5% monthly are common but problematic — any monthly churn above 3% means you are losing over 30% of customers annually.

### How do I calculate customer retention rate?

Retention rate = ((Customers at end of period - New customers acquired) / Customers at start of period) × 100. For example, if you started the quarter with 200 customers, acquired 50 new ones, and ended with 210: ((210 - 50) / 200) × 100 = 80% retention.

### Which retention metric should I track?

Track three: logo retention (percentage of customers retained), net revenue retention (accounts for expansion and contraction), and gross revenue retention (excludes expansion). Together they tell you how many customers stay, how much existing customers spend, and how much revenue you lose from downgrades and cancellations.

### How does customer feedback reduce churn?

Feedback reduces churn through three mechanisms. First, it surfaces dissatisfaction before it becomes cancellation — customers who complain are giving you a chance to fix the problem. Second, acting on feedback improves the product for everyone, not just the person who reported the issue. Third, closing the feedback loop — telling customers what changed because of their input — builds loyalty. For a deeper look, see our guide on [the customer feedback loop](/blog/customer-feedback-loop).

### When should I invest in retention versus acquisition?

If your monthly churn exceeds 5%, investing in acquisition is filling a leaky bucket. Fix the retention fundamentals first (onboarding, feedback, health scoring), then scale acquisition. The exception is pre-product-market-fit companies that need more users to learn what to build — in that case, acquisition and feedback collection should happen simultaneously.

- [How to Migrate from Canny: A Step-by-Step Guide (2026)](https://quackback.io/blog/migrate-from-canny): A practical guide to migrating from Canny to another feedback tool. What to export, how to map your data, and how to communicate the switch to your users.

Published: 2026-03-27

You have decided to leave Canny. Maybe your tracked-user costs tripled after a product launch. Maybe you need self-hosting for compliance. Maybe you want features that Canny does not offer. Whatever the reason, the migration itself should not be the hard part.

![Migrating feedback data from Canny](/blog/migrate-from-canny/hero.webp)

Most teams overthink this. A feedback tool migration is simpler than migrating a database, a CRM, or an auth provider. Your core data is posts, votes, comments, users, and statuses. The process takes a few hours of preparation, an export, an import, and a week of communication.

This guide walks through the full process regardless of which tool you are migrating to.

> **To migrate from Canny:** audit your data, set up your new tool, export from Canny (via the admin dashboard CSV or the API), import into your destination, verify counts, then communicate the switch to your team and users. Your core data is posts, votes, comments, users, and statuses. A tool with a dedicated Canny importer — like [Quackback](/docs/admin/import-export#migrate-from-canny) — moves all of it in a single operation, and most teams finish in under a week.

## When it is time to leave Canny

Not every frustration justifies a migration. Switching tools has real costs — team retraining, user communication, and a brief period where your feedback workflow is disrupted. But some signals are clear.

**Your costs are unpredictable.** Canny's tracked-user pricing means your bill scales with engagement, not with your team size. A single viral feature request can push you into the next pricing tier automatically. If you cannot predict your monthly cost within 20%, the pricing model is working against you. For a detailed breakdown of how this plays out at different scales, see our [Canny pricing analysis](/blog/canny-pricing).

**You need self-hosting.** Canny is a closed-source SaaS product with no self-hosting option. If your security team requires data to stay on your infrastructure, or your compliance framework mandates it, Canny is not an option regardless of features or pricing.

**You have outgrown the feature set.** Canny covers the basics well: feature request boards, voting, roadmaps, changelogs. But if you need AI-powered feedback analysis, an MCP server for agent integrations, advanced analytics, or a knowledge base, you will need to look elsewhere.

**You want source code access.** With a closed-source tool, you cannot audit the code, extend it, or fork it if the product changes direction. For teams that value vendor independence, this matters.

If you are still evaluating whether to switch, our [Canny alternatives comparison](/blog/best-canny-alternatives) covers seven options with honest pros and cons.

## What you can export from Canny

Canny provides data export through both the admin dashboard and their API.

### Dashboard export

From your Canny admin panel, you can export:

- **Posts** — title, description, status, category, tags, creation date, author
- **Votes** — which users voted on which posts
- **Comments** — comment text, author, timestamps
- **Users** — email, name, avatar URL, creation date
- **Changelogs** — published entries with dates and content

Exports typically come as CSV files. This is the easiest path for most migrations — no code required.

### API export

Canny's API provides programmatic access to the same data with more granularity. Use the API if you need:

- Full comment threading (parent-child relationships)
- Custom field values
- Vote timestamps (not just who voted, but when)
- Pagination through large datasets

The relevant API endpoints are `/posts/list`, `/votes/list`, `/comments/list`, and `/users/list`. All require your API key and return paginated JSON. See the [Canny API reference](https://developers.canny.io/api-reference) for the current request and response formats. *(API details last verified May 2026.)*

### What you cannot export

Some data does not come with you:

- **Internal notes and admin-only comments** may not be included in standard exports
- **Merge history** — if you merged duplicate posts in Canny, the merged posts may export as separate entries
- **Analytics and engagement metrics** — page views, unique visitors, and funnel data stay in Canny
- **Webhook configurations and integrations** — these need to be recreated in your new tool

## Migration checklist

### Step 1: Audit your current data

Before exporting anything, understand what you have.

- **How many posts?** Hundreds are trivial. Thousands may require the API route.
- **How many active users?** These are the people you need to communicate with.
- **What statuses do you use?** Map your Canny statuses (Open, Under Review, Planned, In Progress, Complete, Closed) to your new tool's status model.
- **What categories and tags exist?** Document them. You will need to recreate or map them.
- **Are there merged posts?** Check if merged posts need to be consolidated or kept separate.

### Step 2: Set up your new tool

Create your account and configure the basics before importing data:

- Create boards that match your Canny board structure (or take the opportunity to restructure)
- Set up statuses that map to your Canny statuses
- Create categories and tags
- Configure your team members and permissions
- Set up your widget or portal so it is ready for users after the switch

### Step 3: Export from Canny

Run your export from the Canny admin dashboard or API. Verify the data before proceeding:

- Spot-check that post counts match what you see in Canny
- Verify that votes are attached to the correct posts
- Check that comments preserved their threading
- Confirm that user emails are included (you need these to re-associate identities)

### Step 4: Import into your new tool

How this works depends on your destination tool.

**If your new tool has a Canny importer:** Use it. A purpose-built importer handles the data mapping, status translation, and user matching automatically. This is the fastest path.

[Quackback ships a dedicated Canny importer](/docs/admin/import-export#migrate-from-canny) that connects to the Canny API and maps the data model directly — posts, votes, comments, users, statuses, tags, and even changelog entries and merge relationships come across in a single run. You run the import tool with your Canny API key and a Quackback admin key (run it with a dry run first to validate); no CSV wrangling required. Quackback is [open source](/blog/open-source-feedback-tools) and self-hosted, so the engagement spikes that pushed up your Canny bill do not follow you. See the [import and export feature](/features/import-export) for the full data mapping.

**If your new tool accepts CSV imports:** Map your Canny CSV columns to the tool's expected format. Pay attention to:

- Date formats (Canny's API returns ISO 8601 timestamps; confirm your CSV export matches what your destination expects)
- Status mapping (names may differ between tools)
- User matching (email is usually the join key)

**If your new tool only has an API:** Write a migration script that reads your Canny export and creates records through the destination API. This is more work but gives you the most control over how data is mapped.

### Step 5: Verify the import

After importing, check:

- **Post count** — does it match your Canny export?
- **Vote counts** — pick five popular posts and verify vote totals
- **Comments** — check that threading is preserved and authors are correct
- **Statuses** — verify that Canny statuses mapped to the correct new statuses
- **User profiles** — spot-check that user emails and names came through

### Step 6: Update your integrations

If you had Canny connected to other tools, recreate those connections:

- **Slack integration** — reconnect to your feedback channels
- **Jira or Linear** — re-link issue tracking
- **Webhooks** — update any custom webhooks to point to your new tool's endpoints
- **Widget embed** — replace the Canny widget script in your product with your new tool's widget

### Step 7: Communicate the switch

This is the step most teams skip, and it causes the most friction.

**For your team:** Send a brief message explaining what changed, where to find the new feedback tool, and how the workflow differs. Do this before the switch, not after.

**For your users:** If you have a public-facing feedback portal, your users need to know where to go. Options:

- Send an email to active feedback contributors (anyone who posted or voted in the last 90 days)
- Post a changelog entry announcing the new feedback portal
- Add a redirect or notice on your old Canny URL if possible
- Update links in your product, help docs, and website

Keep the message simple: "We moved our feedback board to [new URL]. Your existing posts and votes have been migrated. Here is where to submit new feedback."

## URL redirects

If your Canny board was at `yourcompany.canny.io` or a custom subdomain, you likely cannot set up server-side redirects on Canny's domain. Instead:

- Update all internal links in your product, docs, and website
- If you used a custom domain (like `feedback.yourcompany.com`) with a CNAME to Canny, you can repoint that DNS record to your new tool
- Add a meta refresh or redirect page at your old custom domain if you control it

## Timeline

A realistic migration timeline for a team with under 5,000 posts:

| Day | Action |
|---|---|
| **Day 1** | Audit data, set up new tool, configure boards and statuses |
| **Day 2** | Export from Canny, import into new tool, verify data |
| **Day 3** | Update integrations, replace widget embed, test end-to-end |
| **Day 4** | Communicate to team and users, go live |
| **Day 5-7** | Monitor for issues, answer questions, verify nothing was missed |

![Canny migration timeline from Day 1 through Day 7](/blog/migrate-from-canny/migration-timeline.webp)

For larger datasets or complex configurations, add a day or two. But this is not a month-long project. Most teams complete the migration in under a week.

## After the migration

**Keep your Canny account active for 30 days.** Do not delete it immediately. You may need to reference historical data, check something that did not import correctly, or handle a user who did not get the memo.

**Monitor your new feedback volume.** A temporary dip in submissions is normal after any tool switch. If volume does not recover within two weeks, check that your widget is working, your portal is discoverable, and your communication reached active users.

**Clean up stale data.** A migration is a good opportunity to close old posts that are no longer relevant. If a feature request has been open for two years with three votes, it is probably not coming. Archive it.

If Quackback is your destination, the dedicated Canny importer brings posts, votes, comments, users, and statuses across in one run — and you land on an open source tool with [AI feedback analysis](/features/feedback), an [MCP server](/features/mcp) for agent workflows, and full data ownership. See [Quackback vs Canny](/compare/quackback-vs-canny) for the full comparison, or follow the [migration guide in the docs](/docs/guides/migrate-from-another-tool).

---
> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)
---

## Frequently asked questions

### Will I lose votes if I migrate from Canny?

No, if you use a tool with a Canny importer or import via the API. Votes are tied to user records by email. As long as user emails are preserved in the import, votes map to the correct users in your new tool.

### How long does a Canny migration take?

Most teams complete the migration in three to five days, including communication. The actual data export and import takes a few hours. The rest is configuration, testing, and user communication.

### Can I migrate from Canny for free?

Yes. Canny's data export is available on all plans, including free. The cost of migration is primarily your team's time, not licensing fees. Many destination tools — including [open-source options like Quackback](/blog/open-source-feedback-tools) — are free to use.

### Should I migrate all historical data or start fresh?

Migrate everything. Historical vote counts and comment threads represent months or years of accumulated user signal. Starting fresh throws away data that helps you prioritize. The one exception is very old posts (2+ years) with minimal engagement — archive those after migration to keep your board focused.

### What if my team uses Canny's API for custom integrations?

Document your API integrations before migrating. Most feedback tools offer similar API endpoints (create post, list posts, cast vote, add comment). You will need to update your API calls to use the new tool's endpoints and authentication, but the data model is usually similar enough that the migration is straightforward.

- [Freshdesk Pricing in 2026: Plans, Agent Costs, and Alternatives](https://quackback.io/blog/freshdesk-pricing): What Freshdesk costs in 2026: every paid plan, per-agent fees, hidden Freddy AI add-ons, and the cheaper alternatives worth comparing before you upgrade.

Published: 2026-03-26

Freshdesk's Free Program now covers 1-2 agents for the first 6 months rather than the open-ended 10-agent free plan it once offered. The question is what happens when that runs out or you outgrow it.

![Freshdesk pricing tiers from Free to Enterprise](/blog/freshdesk-pricing/hero.webp)

The jump from free to paid is where most teams pause. Freshdesk Growth starts at $19 per agent per month — reasonable on paper. But the features that make a help desk actually useful at scale (automations, SLA management, custom roles, multilingual support) are spread across three paid tiers, and the gap between Growth and Pro is where most growing teams get stuck.

> **Freshdesk pricing in 2026:** the Free Program covers 1-2 agents for 6 months, then paid tiers run $19 (Growth), $55 (Pro), and $89 (Enterprise) per agent per month, billed annually. Freddy AI, marketplace apps, and day passes are sold separately and can exceed your base plan cost. For a 15-agent team, the Growth-to-Pro jump alone adds about $6,480 per year.
>
> *Pricing last verified March 2026. Vendors may change plans and pricing without notice.*

## Freshdesk pricing plans

All prices are per agent per month, billed annually. Monthly billing costs approximately 20% more.

| Plan | Annual price | Monthly price | Key features |
|---|---|---|---|
| **Free** | $0 | $0 | 1-2 agents for 6 months, email and social ticketing, knowledge base, ticket dispatch |
| **Growth** | $19/agent/mo | $23/agent/mo | Automation, collision detection, marketplace apps, SLA management, business hours |
| **Pro** | $55/agent/mo | $66/agent/mo | Round-robin routing, custom roles, CSAT surveys, multilingual, multiple SLA policies |
| **Enterprise** | $89/agent/mo | $107/agent/mo | Skill-based routing, audit log, IP whitelisting, sandbox, email bot |

## What the free plan includes

Freshdesk's current Free Program is a 6-month starter offer rather than the open-ended free tier it used to be:

- 1-2 agents for the first 6 months
- Email and social media ticketing
- Knowledge base with unlimited articles
- Ticket dispatch (basic rule-based routing)
- Team collaboration features
- 24/7 email support

**What it lacks:** Automations, SLA management, collision detection (knowing when two agents are working the same ticket), marketplace app integrations, time tracking, and any reporting beyond basic metrics.

For one or two people handling fewer than 200 tickets per month, the free offer covers the basics. The friction starts when the 6 months end, you add a third agent, or you need automation and SLAs.

![Features gated behind Freshdesk Pro — the Growth to Pro gap](/blog/freshdesk-pricing/growth-to-pro-gap.webp)

## The Growth to Pro jump

Like many help desk tools, Freshdesk's most painful pricing boundary is the middle tier jump. Growth at $19/agent/month gives you basic automation and SLA management. But several features that most growing support teams consider essential require Pro at $55/agent/month — a 189% increase:

- **Round-robin routing** — distributing tickets evenly across agents
- **Custom roles and permissions** — controlling who can see and do what
- **CSAT surveys** — measuring customer satisfaction after resolution
- **Multilingual support** — serving customers in multiple languages
- **Multiple SLA policies** — different response time commitments for different customer tiers
- **Multiple business hours** — supporting global teams across time zones
- **Custom reports** — building reports beyond the default dashboards

A 15-person support team on Growth pays $3,420/year. Moving to Pro for round-robin routing and CSAT surveys jumps to $9,900/year — a $6,480 increase for features that arguably should be in the mid-tier plan.

## Hidden costs to watch for

### Freddy AI add-ons

Freshdesk's AI features (Freddy AI) are sold separately from the base plans:

- **Freddy Self Service** (AI-powered chatbot): pricing varies by bot session volume
- **Freddy Copilot** (agent assist): additional per-agent fee on top of your plan
- **Freddy Insights** (AI analytics): Enterprise plan only

The bot session model is particularly opaque. Each customer interaction with the chatbot counts as a session, and overages are charged per session. High-volume support teams can see AI costs exceed their base plan costs.

### Marketplace apps

Freshdesk's marketplace has hundreds of integrations, but many premium apps carry their own subscription fees. CRM integrations, advanced reporting add-ons, and quality assurance tools often cost $10-50 per agent per month on top of your Freshdesk plan.

### Day passes

Freshdesk offers "day passes" for occasional agents who do not need full-time seats — useful for developers or managers who occasionally handle tickets. Day passes are sold in packs and cost roughly $2-3 per day per agent, which adds up if usage is more than truly occasional.

### Field service add-on

For teams managing on-site support, the field service module is a separate add-on starting at $15/agent/month on top of your existing plan.

## Freshdesk pricing at scale

| Team size | Growth annual | Pro annual | Enterprise annual |
|---|---|---|---|
| **5 agents** | $1,140 | $3,300 | $5,340 |
| **10 agents** | $2,280 | $6,600 | $10,680 |
| **25 agents** | $5,700 | $16,500 | $26,700 |
| **50 agents** | $11,400 | $33,000 | $53,400 |
| **100 agents** | $22,800 | $66,000 | $106,800 |

These figures exclude AI add-ons, marketplace apps, and any premium support packages.

## Free and cheaper alternatives

### For help desk and ticketing

**Zoho Desk** offers a free tier for three agents and paid plans from $7/agent/month. It is the closest competitor to Freshdesk's feature set at lower price points, especially for teams already in the Zoho ecosystem.

**Help Scout** starts at $22/user/month with no free tier but includes a knowledge base, in-app messaging, and customer satisfaction surveys on all paid plans — features Freshdesk gates behind Pro.

**osTicket** is open source and free to self-host. It covers basic ticketing, knowledge base, and SLA management without per-agent fees. The trade-off is self-managed infrastructure and a less polished interface.

### For customer feedback alongside support

Support tickets contain product feedback that most teams never extract. A customer reporting a bug is also telling you what to fix. A customer asking "can your product do X?" is submitting a feature request.

[Quackback](https://quackback.io) is open source and free to self-host, and runs as a managed [Quackback Cloud](/pricing) if you would rather not host it yourself. It handles the feedback side of customer communication — [feedback boards](/features/feedback), [voting](/features/voting), [AI-powered analysis](/blog/ai-customer-feedback-analysis), and a [public roadmap](/features/roadmap) — while your help desk handles the support side. The two work together: support agents can forward feature requests from tickets to the feedback board, where they are deduplicated, voted on, and prioritized alongside direct customer submissions.

Quackback's AI analysis is built in, and an [MCP server](/features/mcp) lets you query and triage feedback directly from tools like Claude — something Freshdesk's closed ecosystem does not offer.

### For all-in-one support + feedback

**Intercom** combines help desk, live chat, and a basic feedback inbox in one platform. Pricing starts at $29/seat/month but scales quickly with add-ons. See our [Intercom pricing breakdown](/blog/intercom-pricing) for the full picture.

**Zendesk** offers help desk, knowledge base, and community forums. Suite plans start at $55/agent/month. See our [Zendesk pricing breakdown](/blog/zendesk-pricing) for details.

## Is Freshdesk worth it?

Freshdesk is a solid help desk. The Free Program is now a 6-month, 1-2 agent starter rather than the open-ended 10-agent free tier it once had, so plan to move onto a paid tier sooner. Growth at $19/agent/month is competitive for teams that need automation and SLA management.

The value proposition weakens at Pro ($55/agent/month), where you are paying a premium for features that competitors include at lower price points — particularly CSAT surveys, custom roles, and round-robin routing. If those specific features are what you need, compare the total cost against Help Scout, Zoho Desk, and Intercom before committing to Pro.

For Enterprise ($89/agent/month), evaluate whether you truly need skill-based routing, audit logs, and sandbox environments. If your primary need is compliance features (audit trails, IP whitelisting), the Enterprise tier is justified. If you just want better routing, Pro may be sufficient.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Does Freshdesk have a free plan?

Yes, but it is limited. Freshdesk's Free Program covers 1-2 agents for the first 6 months with email and social ticketing, a knowledge base, and basic ticket routing. This replaced the older open-ended 10-agent free plan. The main limitations are the 6-month window, the 2-agent cap, and no automations, SLA management, or marketplace app integrations.

### How does Freshdesk's per-agent pricing work?

Every team member who handles tickets needs an agent seat. Agents are billed per seat per month. You can choose annual billing (roughly 20% cheaper) or monthly billing. Freshdesk also offers day passes for occasional users who do not need a full-time seat.

### Is Freshdesk cheaper than Zendesk?

Yes, at every tier. Freshdesk Growth ($19/agent/month) undercuts Zendesk Suite Team ($55/agent/month) significantly. However, Zendesk includes more features at its base tier (live chat, messaging, community forums) that Freshdesk charges extra for. The comparison depends on which features you actually need.

### What is the best free alternative to Freshdesk?

For help desk: Freshdesk's Free Program (1-2 agents for 6 months) gets you started, and Zoho Desk has a free tier for up to 3 agents. For feedback collection alongside support: [Quackback](https://quackback.io) is open source and free to self-host.

### Can I use Freshdesk for customer feedback?

Freshdesk handles support tickets, not structured product feedback. It does not have feature request boards, voting, or roadmap features. Most teams pair Freshdesk with a dedicated [feedback tool](/blog/best-customer-feedback-tools-2026) to capture product insights from support conversations.

- [HubSpot Pricing in 2026: Plans, Hidden Costs, and Cheaper Alternatives](https://quackback.io/blog/hubspot-pricing): HubSpot spans five hubs with different billing models. Here is what each plan actually costs, where the hidden fees are, and when cheaper alternatives make more sense.

Published: 2026-03-26

HubSpot's pricing page lists plans starting at $15 per month. The number you actually pay is usually much higher.

![HubSpot pricing tiers with hidden costs](/blog/hubspot-pricing/hero.webp)

> **TLDR:** HubSpot lists plans from $15 per month, but the real cost is usually much higher. The gap comes from three sources: mandatory onboarding fees on Professional and Enterprise plans, contact-based overages in Marketing Hub that auto-upgrade your tier mid-cycle, and essential features gated behind the $890 per month Professional jump. A realistic Marketing plus Sales plus Service setup runs into the thousands per month at team scale.
>
> *Pricing last verified March 2026. Vendors may change plans and pricing without notice.*

Understanding where the costs actually live is the first step to deciding whether HubSpot is the right investment.

## HubSpot's pricing structure

HubSpot is not one product. It is five separate hubs — Marketing, Sales, Service, Content, and Data — each with its own pricing tiers. You can buy hubs individually or bundle them into the Customer Platform.

This modular structure means flexibility, but also complexity. A marketing team might only need Marketing Hub. A full go-to-market team might need Marketing, Sales, and Service. Each combination has a different total cost.

### Marketing Hub

| Plan | Price | Seats included | Marketing contacts | Onboarding fee |
|---|---|---|---|---|
| **Free** | $0 | Unlimited (limited features) | Up to 1M non-marketing contacts | None |
| **Starter** | $15/seat/mo | 1 | 1,000 | None |
| **Professional** | $890/mo | 3 | 2,000 | $3,000 (mandatory) |
| **Enterprise** | $3,600/mo | 5 | 10,000 | $7,000 (mandatory) |

Marketing Hub is the most expensive hub because of contact-based pricing. You pay for the number of "marketing contacts" — contacts you actively email or target with ads. Non-marketing contacts are free up to one million.

The catch: exceeding your contact tier auto-upgrades you mid-billing-cycle. Go from 2,000 to 2,001 marketing contacts on Professional and you are billed for the next block of 5,000 contacts at roughly $250/month. There is no grace period.

### Sales Hub

| Plan | Price | Onboarding fee |
|---|---|---|
| **Free** | $0 | None |
| **Starter** | $20/seat/mo | None |
| **Professional** | $100/seat/mo | $1,500 (mandatory) |
| **Enterprise** | $150/seat/mo | $3,500 (mandatory) |

Sales Hub pricing is per seat across all tiers. A 10-person sales team on Professional pays $1,000/month ($12,000/year) plus the one-time $1,500 onboarding fee.

### Service Hub

| Plan | Price | Onboarding fee |
|---|---|---|
| **Free** | $0 | None |
| **Starter** | $20/seat/mo | None |
| **Professional** | $100/seat/mo | $1,500 (mandatory) |
| **Enterprise** | $150/seat/mo | $3,500 (mandatory) |

Service Hub mirrors Sales Hub pricing exactly.

### Content Hub (formerly CMS Hub)

| Plan | Price | Seats included | Onboarding fee |
|---|---|---|---|
| **Free** | $0 | Limited | None |
| **Starter** | $15/seat/mo | 1 | None |
| **Professional** | $450/mo | 3 | Required |
| **Enterprise** | $1,500/mo | 5 | Required |

### Data Hub (formerly Operations Hub)

| Plan | Price |
|---|---|
| **Free** | $0 |
| **Starter** | $20/mo |
| **Professional** | $800/mo |
| **Enterprise** | $2,000/mo |

### Customer Platform bundle

If you need multiple hubs, the Customer Platform bundles all five:

| Plan | Price | Onboarding fee |
|---|---|---|
| **Starter** | $20/mo (1 seat) | None |
| **Professional** | ~$1,781/mo | $4,500 |
| **Enterprise** | ~$5,000/mo | $12,000 |

![HubSpot Starter to Professional pricing jump by hub](/blog/hubspot-pricing/starter-to-pro-jump.webp)

## The Starter to Professional jump

The most important pricing decision in HubSpot is whether to go from Starter to Professional. The gap is enormous:

- Marketing Hub: $15/seat/mo → $890/mo (a 59x increase for a solo marketer)
- Sales Hub: $20/seat/mo → $100/seat/mo (a 5x increase)
- Service Hub: $20/seat/mo → $100/seat/mo (a 5x increase)

This matters because HubSpot gates critical features behind Professional. Workflows, sequences, A/B testing, custom reporting, and advanced automation all require Professional or higher. Starter gives you the basics — contact management, email, forms — but the features that make HubSpot valuable as a platform are locked behind that jump.

## Hidden costs to watch for

### Mandatory onboarding fees

Every Professional and Enterprise plan requires a paid onboarding. You cannot skip it.

| Hub | Professional onboarding | Enterprise onboarding |
|---|---|---|
| Marketing | $3,000 | $7,000 |
| Sales | $1,500 | $3,500 |
| Service | $1,500 | $3,500 |
| Full Platform | $4,500 | $12,000 |

These are one-time fees, but they add up. A company buying Marketing Pro + Sales Pro + Service Pro pays $6,000 in onboarding before seeing a single feature. Some HubSpot partners can substitute their own onboarding to waive the fee, but you will still pay for the partner's services.

### Contact overage charges

Marketing Hub's contact-based pricing is the most common source of surprise bills. Additional contacts are sold in blocks:

- Professional: 5,000 additional contacts for ~$250/month
- Enterprise: 10,000 additional contacts for ~$100/month

A Marketing Hub Professional user with 10,000 marketing contacts pays roughly $890 (base) + $400 (contact overage) = $1,290/month. The overage can exceed the base price.

### Add-ons and extras

- Transactional email add-on: $600/month (requires Marketing Professional)
- Dedicated IP address: $300/month
- API limit increase (to 1M calls/day): $500/month
- Additional reporting dashboards, calling minutes, and contact lists at various prices

### Annual lock-in

Professional and Enterprise plans require annual contracts paid upfront. There are no early termination refunds — you owe the full remaining balance. Auto-renewal is on by default, and customers commonly report being auto-renewed without clear advance notice. Read your renewal terms before signing.

![HubSpot costs rising steeply as team size grows](/blog/hubspot-pricing/cost-at-scale.webp)

## HubSpot pricing at scale

Here is what HubSpot actually costs for different team sizes, using the most common configuration (Marketing + Sales + Service):

| Team size | Configuration | Monthly cost | Annual cost | Onboarding |
|---|---|---|---|---|
| **Solo founder** | Marketing Starter + Sales Starter | $35/mo | $420/yr | $0 |
| **5-person startup** | Marketing Pro + 5 Sales Starter seats | $990/mo | $11,880/yr | $3,000 |
| **15-person team** | Marketing Pro + 10 Sales Pro + 5 Service Pro seats | $2,390/mo | $28,680/yr | $6,000 |
| **50-person org** | Marketing Enterprise + Sales Enterprise + Service Enterprise | $7,350+/mo | $88,200+/yr | $14,000 |

These figures exclude contact overages, add-ons, and any custom pricing negotiations for large teams.

## Free and cheaper alternatives

### For CRM and sales (replacing Sales Hub)

**Pipedrive** starts at $14/user/month with no feature gates on core CRM functionality. Freshsales starts at $9/user/month with a solid free tier. Both avoid the Starter-to-Professional cliff that makes HubSpot Sales expensive for growing teams.

### For marketing automation (replacing Marketing Hub)

**Brevo** (formerly Sendinblue) offers email automation starting at $9/month with no contact-based pricing — you pay for emails sent, not contacts stored. ActiveCampaign starts at $29/month with automation included on all plans. Neither charges mandatory onboarding fees.

### For customer service (replacing Service Hub)

**Freshdesk** offers a 6-month free tier for 1-2 agents and paid plans from $19/agent/month. Help Scout starts at $25/user/month. Both include automation and knowledge base features that HubSpot gates behind Service Professional.

### For customer feedback (replacing HubSpot's feedback tools)

[**Quackback**](https://quackback.io) is an open source (AGPL-3.0) feedback platform that gives you [feedback boards](/features/feedback), [voting](/features/voting), a [public roadmap](/features/roadmap), and a [changelog](/features/changelog). Where HubSpot meters seats and contacts, Quackback is free to self-host. The built-in [AI analysis](/features/feedback) groups and summarizes feedback. You can [self-host it free](/docs) or use [Quackback Cloud](/pricing) as a managed option, and the [MCP server](/features/mcp) connects your feedback directly to AI assistants. See how it stacks up in our [Quackback vs Canny](/compare/quackback-vs-canny) and [other feedback tool comparisons](/blog/open-source-feedback-tools).

### For CMS (replacing Content Hub)

WordPress with managed hosting costs $5-30/month and offers more flexibility than Content Hub. Webflow starts at $14/month for published sites. Both are significantly cheaper than Content Hub Professional at $450/month.

### For all-in-one

**EngageBay** offers CRM, marketing, sales, and service starting at $14.99/user/month for the full suite. Zoho One bundles 40+ apps at $37/user/month. Neither requires mandatory onboarding fees or annual contracts.

## Is HubSpot worth it?

HubSpot is a strong platform if your team needs tight integration between marketing, sales, and service and you can justify the Professional tier pricing. The free CRM is genuinely good — among the best free CRMs available. The ecosystem of integrations, the app marketplace, and the reporting capabilities at Professional and Enterprise tiers are competitive.

HubSpot is not worth it if you are paying for Professional just to get one or two gated features (like workflows or sequences), if your contact list is growing faster than your revenue, or if mandatory onboarding fees eat a meaningful portion of your budget. In those cases, purpose-built tools for each function will cost less and often do more in their specific domain.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Does HubSpot have a free plan?

Yes. HubSpot's free CRM includes contact management, email tracking, meeting scheduling, and basic forms. It is limited to 5 email templates, 1 automated email per form, and basic reporting. The free plan is a genuine product, not a trial — it works indefinitely.

### How does HubSpot's contact pricing work?

Marketing Hub charges based on "marketing contacts" — contacts you actively email or target with ads. Non-marketing contacts (like CRM-only contacts) are free. You buy contacts in blocks, and exceeding your block auto-upgrades you to the next tier immediately with no grace period.

### Can I cancel a HubSpot annual contract early?

No. HubSpot annual contracts require payment for the full term. There are no early termination refunds. You can request not to auto-renew at the end of your term, but you must do so before the renewal date.

### What is the cheapest HubSpot plan for a small team?

The Starter Customer Platform at $20/month gives you access to all five hubs at the Starter tier. This is the most cost-effective entry point for teams that want more than the free plan. The jump to Professional starts at $890/month (Marketing) or $100/seat/month (Sales/Service).

### Is HubSpot more expensive than Salesforce?

For small teams, yes — HubSpot Professional is often more expensive than Salesforce Essentials ($25/user/month). For enterprise teams, Salesforce typically costs more due to its add-on model and implementation costs. The comparison depends heavily on team size, which hubs you need, and how many marketing contacts you have.

- [How to Collect Customer Feedback in Slack (Without Losing It)](https://quackback.io/blog/collect-feedback-in-slack): Feedback shared in Slack has a half-life of four hours. Here is how to capture it before it disappears into the scroll.

Published: 2026-03-25

Your customers are already telling you what they want. The problem is they are telling you in Slack, and nobody is writing it down.

![Customer feedback messages disappearing in Slack](/blog/collect-feedback-in-slack/hero.webp)

A customer mentions a missing integration in a shared channel. A sales rep pastes a deal-losing objection into a DM. A support engineer flags a recurring complaint in a thread that gets twelve replies and zero follow-up. By next week, all three are buried under thousands of new messages. The feedback still exists somewhere in Slack's search index, but practically speaking, it is gone.

This is not a discipline problem. It is a structural one. Slack was built for conversation, not for collecting and organizing product signals. If you want to use Slack as a feedback channel — and you should, because that is where your team already talks to customers — you need a system that pulls feedback out of the stream before it disappears.

> To collect customer feedback in Slack without losing it, you need a way to pull signals out of the conversation stream and into a structured system. Three approaches work: dedicated feedback channels with workflow forms, emoji-triggered routing that captures messages from any channel, and a feedback tool integration that automatically creates trackable, deduplicated requests. For teams past 50 feedback messages a month, a tool integration is the most reliable because it survives across channels and DMs.

## Why feedback gets lost in Slack

**The volume problem.** Active Slack users send dozens of messages a day. Across an organization, that adds up to thousands of messages flowing through channels every hour. Feedback is a tiny fraction of that volume, and there is no native way to distinguish a feature request from a meeting reminder.

**The fragmentation problem.** Your CS team has a channel. Sales has a channel. Support has a channel. Each one generates customer signals daily, but none of them talk to each other. CS mentions three customers found onboarding confusing. Sales mentions two deals fell through because onboarding looked complicated in the demo. Support closed 40 tickets tracing back to the same onboarding step. Nobody connects the dots because the feedback lives in three different places.

**The DM problem.** A large share of Slack activity happens in direct messages and private channels rather than public ones. When a customer shares critical feedback in a DM with an account manager, that insight is invisible to the product team.

**The "eyes emoji" problem.** Someone reacts with an eyes emoji or writes "interesting, let me flag this." The conversation moves on. Nobody follows up. The feature request is still not built two months later. Emoji reactions feel like action, but they are acknowledgement without accountability.

## Three approaches to capturing Slack feedback

### 1. Dedicated feedback channels with workflow forms

The simplest approach is to create structured channels — `#feature-requests`, `#bug-reports`, `#customer-feedback` — and use Slack's Workflow Builder to replace free-text messages with intake forms.

A workflow form captures structured fields: customer name, product area, request type, and description. This is already better than a wall of unformatted messages because it forces the submitter to categorize their feedback before posting.

**How to set it up:**
- Create channels with clear naming conventions and a consistent prefix like `#feedback-`
- Pin submission guidelines explaining how to use the form, what qualifies as feedback, and expected response times
- Build a Workflow Builder form that posts structured submissions to the channel
- Assign a weekly rotation for someone to review and route submissions

**Where it breaks down:** This approach depends on people using the form every time. In practice, they do not. Someone will drop a quick message instead of clicking through the workflow, and you are back to unstructured text. It also does nothing about feedback shared in other channels or DMs. You are only capturing what people deliberately route to your feedback channel.

**Best for:** Small teams with low feedback volume where one person can manually review submissions weekly.

### 2. Emoji-triggered routing

A step up from dedicated channels: configure automations that trigger when someone reacts to any message with a specific emoji. When a team member spots customer feedback in any channel, they react with a designated emoji (like `:feedback:` or `:bulb:`), and an automation captures the message and routes it to a tracker.

This works across all channels, not just dedicated feedback channels. It turns every team member into a feedback sensor without requiring them to copy-paste messages or fill out forms.

**How to set it up:**
- Create a custom emoji (`:feedback:`) that signals "this is a product signal"
- Build a Slack workflow triggered by that emoji reaction
- Route captured messages to a spreadsheet, Notion database, or feedback tool
- Include the original message link so reviewers can see the full context

**Where it breaks down:** It still requires someone to notice and tag the feedback. DM feedback stays invisible. And emoji routing creates a flat list with no deduplication — if five people share the same request in different channels and all get tagged, you have five entries for one request.

**Best for:** Mid-size teams where feedback appears across many channels and you need lightweight capture without changing how people communicate.

### 3. Dedicated tool integration with automatic routing

The most reliable approach is to connect Slack to a feedback management tool that automatically creates trackable requests from Slack messages. Instead of relying on manual tagging or dedicated channels, the integration pulls feedback directly into a system designed for organizing, deduplicating, and prioritizing it.

This solves the core problem: feedback stays in Slack for the conversation, but a structured copy lives in a tool where it can be voted on, categorized, linked to roadmap items, and tracked to resolution.

**How to set it up:**
- Connect your feedback tool's Slack integration to relevant channels
- Configure routing rules: which channels map to which boards or categories
- Team members forward messages to the tool with a shortcut or slash command
- The tool deduplicates incoming requests and merges them with existing ones

[Quackback's Slack integration](/integrations/slack) supports multi-channel routing. When a team member spots feedback in any Slack channel, they can forward it to Quackback with a shortcut. The message becomes a post on your [feedback board](/features/feedback), where it can be [voted on](/features/voting), commented on, and tracked through your [public roadmap](/features/roadmap). If a similar request already exists, you see it immediately instead of creating a duplicate.

Because Quackback is open source (AGPL-3.0), you can route every person on your team through Slack. It runs as managed [Quackback Cloud](/pricing) or self-hosted for free. And the built-in [MCP server](/features/mcp) lets you query and triage that captured Slack feedback from an AI assistant, with built-in AI summaries.

**Best for:** Any team that wants to capture feedback systematically without changing how people use Slack.

![Three Slack feedback approaches compared on effort vs coverage axes](/blog/collect-feedback-in-slack/slack-feedback-approaches.webp)

## How to choose the right approach

| Approach | Effort | Coverage | Deduplication | Scale |
|---|---|---|---|---|
| **Dedicated channels + forms** | Low | Single channel only | None | Small teams |
| **Emoji-triggered routing** | Medium | All public channels | None | Mid-size teams |
| **Tool integration** | Medium | All channels + shortcuts | Automatic | Any team size |

Start with approach 1 if you have fewer than 50 feedback messages per month. Move to approach 2 or 3 when you notice feedback slipping through the cracks — duplicate requests appearing that nobody connected, or customer complaints surfacing in retros that the product team never saw.

## Setting up a triage workflow

Capturing feedback is half the problem. The other half is making sure someone actually reviews it. Without a triage process, your feedback tracker becomes another inbox that nobody checks.

**Assign a weekly owner.** Rotate responsibility for reviewing new feedback across the product team. One person reviews, categorizes, and routes everything that came in that week. This takes 30 minutes for most teams.

**Categorize immediately.** Every piece of feedback should get a type (feature request, bug report, UX issue, question) and a product area. If you cannot categorize it, you do not have enough context — go back to the original Slack thread and ask.

**Merge duplicates.** Multiple customers asking for the same thing is the strongest signal you can get. But only if you recognize it as one request with multiple voices, not five separate entries. Deduplication is where [AI-powered feedback tools](/blog/ai-customer-feedback-analysis) earn their keep.

**Close the loop.** When you build something a customer asked for, tell them. When you decide not to build something, explain why. Customers who feel heard keep giving feedback. Customers who feel ignored stop — and then they churn. [Research](https://www.helpscout.com/75-customer-service-facts-quotes-statistics/) shows 79% of consumers who tried to share feedback about a poor experience were ignored.

## Common mistakes

**Treating Slack as your system of record.** Slack is a communication tool, not a feedback database. Use it as an input channel, not a storage system. Feedback that stays in Slack is feedback that gets lost.

**Creating too many channels.** Channel sprawl is as bad as having no channels at all. If 80% of your feedback channels are dead, people stop trusting the system and go back to DMs. Start with one or two channels and expand only when volume justifies it.

**No ownership.** If nobody is explicitly responsible for reviewing and routing feedback from Slack, nobody will do it. Assign ownership, even if it rotates weekly.

**Ignoring DMs and private channels.** Some of your most valuable feedback lives in DMs between account managers and customers. Build a culture where team members forward relevant DM feedback to the shared system, whether that is a channel, a form, or a tool integration.

**Collecting without acting.** The fastest way to kill a feedback program is to collect feedback and never do anything with it. If your team stops seeing feedback turn into product changes, they stop submitting it. If your customers stop seeing their requests acknowledged, they stop sharing. Most brands [hear from fewer than 1% of their customers](https://www.alchemer.com/resources/blog/most-brands-hear-from-less-than-1-percent-customers/) in the first place — do not give them a reason to stop.

If you are weighing a dedicated tool, it is worth comparing options side by side — see how Quackback stacks up against [Canny](/compare/quackback-vs-canny) and [Featurebase](/compare/quackback-vs-featurebase), or read the [docs](/docs) to see how the Slack integration works end to end.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How do I get my team to actually use a Slack feedback workflow?

Make it easier than the alternative. If submitting feedback through your workflow takes more effort than dropping a message in a channel, people will drop a message in a channel. Use Slack shortcuts and slash commands that take under ten seconds. And visibly act on what comes in — when people see their submissions turn into shipped features, they submit more.

### Should I use a dedicated Slack channel or integrate with a feedback tool?

Dedicated channels work for small teams with low volume. Past 50 feedback messages per month, or when feedback spans multiple channels, a tool integration saves time on deduplication and routing. The two are not mutually exclusive: many teams keep a channel for visibility and a tool for tracking.

### How do I handle feedback that comes through Slack DMs?

You cannot automate DM capture without significant privacy concerns. Instead, build a team norm: when someone receives product feedback in a DM, they forward it to the shared feedback channel or tool using a Slack shortcut. Make this a one-click action, and it becomes habit within a few weeks.

### What about feedback from Slack Connect channels with external customers?

Slack Connect channels are one of the best sources of unfiltered customer feedback because conversations happen naturally. Apply the same emoji-tagging or tool-integration approach to these channels. The key difference is sensitivity — external channels may require more careful handling of who sees the feedback and how it is categorized.

### How often should I review Slack feedback?

Weekly at minimum. Daily if your volume is high or you are in a rapid iteration phase. The longer feedback sits unreviewed, the more likely it is to become stale or get duplicated. A dedicated 30-minute weekly review session works for most teams under 100 feedback messages per month.

- [ClickUp Pricing in 2026: Plans, Per-User Costs, and the AI Add-On](https://quackback.io/blog/clickup-pricing): ClickUp's pricing plans in 2026. Workspace plans from free to enterprise, Brain AI add-ons, and what it costs to run ClickUp at scale.

Published: 2026-03-24

ClickUp is an all-in-one project management platform used by teams of every size. It covers task management, docs, whiteboards, goals, time tracking, and dashboards in a single workspace. Since launching in 2017, it has grown into one of the most feature-dense tools in the category.

![ClickUp pricing plans overview for 2026](/blog/clickup-pricing/hero.webp)

> **ClickUp pricing has two billing layers: workspace plans (from free to Enterprise, paid plans starting at $7/user/month billed yearly) and Brain AI plans (sold separately at $9 or $28/user/month).** A 50-person team on Business plus Everything AI pays roughly $2,000/month before credit overages, and the workspace-wide upgrade requirement means one person needing Business features moves everyone to Business pricing. Budget for both layers before you commit.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check [ClickUp's pricing page](https://clickup.com/pricing) for the latest figures.*

ClickUp's pricing has two layers: workspace plans and Brain AI plans. They are billed separately. This matters because the sticker price on a workspace plan does not include AI, and the AI add-on can more than double your per-user cost. If you are evaluating ClickUp in 2026, you need to understand both layers to calculate your actual spend.

If you use ClickUp for project management and need a dedicated [feedback and roadmap tool](/features/roadmap), you may also want to read our [feedback tool pricing comparison](/blog/feedback-tool-pricing-comparison) to understand that part of the stack.

## ClickUp's workspace plans

ClickUp offers four main workspace tiers plus a Business Plus tier that sits between Business and Enterprise. Every member of your workspace must be on the same plan — you cannot mix and match.

| Plan | Monthly (annual billing) | Monthly (month-to-month) | Key Features |
|------|--------------------------|--------------------------|--------------|
| Free Forever | $0 | $0 | 60MB storage, unlimited tasks, basic custom fields, 1 form, kanban boards |
| Unlimited | $7/user/mo | $10/user/mo | Unlimited storage, Gantt charts, integrations, custom fields, time tracking, goals |
| Business | $12/user/mo | $19/user/mo | Unlimited dashboards, timeline views, webhooks, 5K automations/month, sprint reporting |
| Business Plus | $19/user/mo | $29/user/mo | Custom roles, 50K automations/month, subtasks in multiple lists, priority support |
| Enterprise | Custom | Custom | SAML SSO, audit logs, 250K automations/month, custom branding, HIPAA/MSA available |

A few things to note about each tier.

The **Free Forever** plan caps you at 60MB of storage across the entire workspace. That is not a typo — a single PDF could eat a large chunk of it. Unlimited tasks and unlimited free members sound generous, but the storage limit and the restriction to 1 form and basic custom fields make this a trial, not a real working environment.

The **Unlimited** plan at $7/user/month (annual) is the first viable tier for most teams. It unlocks unlimited storage, integrations, time tracking, and Gantt charts. If you are paying monthly instead of annually, expect $10/user/month — a 30% premium.

The **Business** plan at $12/user/month (annual) adds dashboards, automations (5,000/month), and sprint reporting. This is where most mid-size teams land because automations and advanced reporting are table-stakes for growing teams.

The **Business Plus** plan at $19/user/month (annual) is not always prominently displayed on ClickUp's pricing page but exists in their documentation. It adds custom role creation, subtasks in multiple lists, 50,000 automations per month (a 10x jump from Business), and priority support. If you need granular permissions or heavy automation, this is the tier to evaluate before jumping to Enterprise.

**Enterprise** pricing is custom and negotiated directly with sales. It includes SAML SSO, audit logs, 250,000 automations per month, custom branding, and compliance features (HIPAA, MSA). Industry data suggests Enterprise contracts land around $25-$40/user/month depending on seat count and negotiation.

The workspace-wide upgrade requirement is the most important thing to understand about ClickUp pricing. If one person on your team needs Business-tier features like automations or sprint reporting, your entire workspace moves to Business. You cannot put a few users on Unlimited and a few on Business. This means one team's requirements dictate the cost for the entire organization.

## ClickUp Brain AI pricing

Brain AI is a separate product line with its own pricing. It is not included in any workspace plan. You buy it on top of whatever workspace tier you are on. This two-layer billing model is the single biggest source of confusion in ClickUp pricing.

![ClickUp Brain AI add-on pricing layers](/blog/clickup-pricing/brain-ai-tiers.webp)

| Brain AI Plan | Monthly Price | Key Features |
|--------------|--------------|--------------|
| Free | $0 | Trial access to AI |
| Brain AI | $9/user/mo | Unlimited assistant, @Brain Agent, AI chat (ChatGPT, Gemini, Claude), enterprise search, 1,500 AI Super Credits/month |
| Everything AI | $28/user/mo | All Brain AI features + ambient answers, talk-to-text, notetaker, image generation, AI automations, AI fields, 5,000 AI Super Credits/month |

The free AI tier gives you trial access only — enough to test the feature, not enough to rely on it. Brain AI is only available on paid workspace plans. You cannot add it to the Free Forever workspace.

The **Brain AI** plan at $9/user/month includes the core assistant, the @Brain Agent for searching across your workspace, and AI chat with access to multiple model providers (ChatGPT, Gemini, Claude). You get 1,500 AI Super Credits per month per user.

**Everything AI** at $28/user/month is ClickUp's recommended tier and the one they push hardest. It adds ambient answers (AI that proactively surfaces relevant information), talk-to-text transcription, an AI notetaker for meetings, image generation, and AI-powered custom fields. The credit allowance increases to 5,000 AI Super Credits per month per user.

**AI Super Credits** are the usage-based component. Credits are consumed when you use AI features beyond the basics. Additional credits cost $0.001 per credit, or $10 for 10,000 credits. The costs seem small per credit, but they accumulate across a team. A 50-person team on Everything AI gets 250,000 credits per month. If your team is running AI automations, generating content, and using the notetaker daily, you can burn through that allocation. There is no hard cap — overages are billed automatically to your account.

Brain AI is billed per paid user seat, not per actual user of AI features. If you enable Everything AI for your workspace, every paid member pays $28/month for the AI add-on whether they use it or not. You cannot selectively enable AI for just the team members who need it.

## ClickUp pricing at scale

The real cost of ClickUp is workspace plan + Brain AI plan per user. Here is what that looks like at different team sizes, all on annual billing.

| Team Size | Business Only | Business + Brain AI | Business + Everything AI |
|-----------|--------------|--------------------|-----------------------|
| 10 users | $120/mo ($1,440/yr) | $210/mo ($2,520/yr) | $400/mo ($4,800/yr) |
| 25 users | $300/mo ($3,600/yr) | $525/mo ($6,300/yr) | $1,000/mo ($12,000/yr) |
| 50 users | $600/mo ($7,200/yr) | $1,050/mo ($12,600/yr) | $2,000/mo ($24,000/yr) |
| 100 users | $1,200/mo ($14,400/yr) | $2,100/mo ($25,200/yr) | $4,000/mo ($48,000/yr) |
| 200 users | $2,400/mo ($28,800/yr) | $4,200/mo ($50,400/yr) | $8,000/mo ($96,000/yr) |

*All prices reflect annual billing on the Business workspace plan ($12/user/mo).*

The numbers tell the story. At 50 users on the Business plan alone, you pay $600/month. Add Everything AI and that becomes $2,000/month — a 233% increase. The AI add-on pushes per-user cost from $12 to $40 per month.

At 200 users on Business + Everything AI, you are spending $96,000 per year. That puts ClickUp in the same price range as enterprise tools that include AI in the base price. For comparison, a 200-person team on [Jira](/blog/jira-product-discovery-pricing) Standard at $7.53/user/month would pay roughly $18,072/year — though Jira charges extra for its own AI and marketplace add-ons.

These figures do not include AI Super Credit overages. A 50-person team on Everything AI gets 250,000 credits per month. Heavy AI usage — automations, content generation, meeting notetaker — could add $100-$500/month on top of the base price depending on usage patterns.

Enterprise pricing is custom. If you need SAML SSO, HIPAA compliance, or more than 250,000 automations per month, you will need to contact sales. Industry data from [Spendbase](https://www.spendbase.co/blog/saas-management/clickup-pricing-costs-savings-discount-playbook/) suggests Enterprise contracts typically land at $25-$40/user/month, and standard negotiated discounts of 20-25% off list pricing are common.

## How to save on ClickUp

There are concrete steps you can take to reduce your ClickUp bill.

**Audit your seat count before renewal.** ClickUp charges for every active member — owners, admins, members, and limited members all count as paid seats. Run a usage audit before your annual renewal. Remove inactive users, convert rarely-active members to guests where possible, and eliminate duplicate accounts. On a team of 50 or more, trimming even a handful of unused seats can save thousands of dollars a year.

**Start with annual billing.** The difference between monthly and annual billing is significant. On the Business plan, monthly billing costs $19/user/month versus $12/user/month annually — a 37% premium for flexibility. If you are confident in the tool, commit annually from the start.

**Control Brain AI adoption.** Brain AI is billed per seat, not per actual AI user. If only 10 of your 50 team members actively use AI, you are paying for 40 unused AI seats. Consider whether the AI add-on is worth it for your entire workspace or if a standalone AI tool (ChatGPT, Claude) would be cheaper for the few people who need it.

**Negotiate at renewal.** Industry data suggests standard negotiated discounts of 20-25% off list pricing are achievable. Larger organizations can push for more. Time your negotiations near the end of ClickUp's fiscal quarter for better leverage.

**Consider Business Plus before Enterprise.** The jump from Business (5,000 automations/month) to Enterprise (250,000 automations/month) is a large cost increase. Business Plus at $19/user/month gives you 50,000 automations/month — a 10x increase over Business — which may be enough for your needs without the Enterprise price tag.

## Hidden costs to consider

The sticker price on ClickUp's pricing page does not tell the full story. Here are the costs that catch teams off guard.

**Brain AI more than doubles your per-user cost.** The workspace plan and AI plan are billed separately, but both charge per user. A Business plan user at $12/month becomes a $21/month user with Brain AI, or a $40/month user with Everything AI. The AI add-on is where ClickUp's pricing gets expensive fast. As of early 2026, competitors like [Asana](/blog/feedback-tool-pricing-comparison) (which includes core AI on paid plans) and Linear (which includes AI agents on all plans) bundle AI into their base pricing, while ClickUp treats AI as a premium upsell.

**Workspace-wide upgrades are mandatory.** Every member of your workspace must be on the same plan. If one team needs Business-tier automations, your entire organization upgrades. A 100-person company where only 10 people need automations still pays Business pricing for all 100. This is the single most expensive gotcha in ClickUp's model.

**Automation limits create cliff pricing.** The Business plan includes 5,000 automations per month. Business Plus includes 50,000. Enterprise includes 250,000. If you hit the Business cap, your automations stop running until the next billing cycle or you upgrade. For teams that rely heavily on automation workflows, this ceiling can force an expensive tier jump — and the jump from Business to Business Plus is $7/user/month for every seat in your workspace.

**Monthly billing is 30-45% more expensive.** The prices most often quoted are annual billing rates. If you pay monthly, Unlimited jumps from $7 to $10/user/month, Business from $12 to $19/user/month, and Business Plus from $19 to $29/user/month. A 50-person team on monthly Business billing pays $11,400/year instead of $7,200/year — a $4,200 premium for the flexibility to cancel.

**Free plan storage is 60MB.** The free plan gives you 60 megabytes of storage across your entire workspace. A single design file or screen recording exceeds that. The free plan is a demo, not a working environment.

**AI Super Credit overages have no cap.** Credits cost $0.001 each. The costs are small per credit, but they accumulate across teams without any spending limit. Overages are billed automatically — there is no alert threshold or hard cap to prevent surprise charges.

## ClickUp alternatives

If ClickUp's pricing does not fit your budget, or if the two-layer billing model is more complexity than you want, here are alternatives worth considering.

### Asana

Asana offers a free plan for up to 10 users and paid plans starting at $10.99/user/month (Premium). It covers task management, timelines, portfolios, and workflow builder. AI features (Asana Intelligence) are included on paid plans without a separate add-on — a meaningful cost advantage over ClickUp's layered AI billing. The trade-off is fewer built-in features compared to ClickUp — no native docs, whiteboards, or time tracking.

### Monday.com

Monday.com starts at $9/seat/month (Basic) and goes up to $19/seat/month (Pro). It is strong on visual project management with customizable boards and dashboards. AI features are available as an add-on. Like ClickUp, the per-seat pricing can get expensive at scale, but Monday.com's minimum seat requirement (3 seats on paid plans) means solo users pay more than expected.

### Linear

Linear focuses on product development teams. Pricing starts at $10/user/month (Basic, billed annually) with a free plan that includes unlimited members but limits you to 250 issues and 2 teams. It is opinionated toward engineering workflows — issues, cycles, roadmaps — rather than being an all-in-one workspace. AI agents are included on all plans at no extra cost. If your use case is software development, [Linear is worth evaluating](/blog/linear-pricing).

### Jira

Jira's free plan supports up to 10 users with most features included. Standard starts at $7.53/user/month billed annually. It is far more customizable than ClickUp but also more complex. For teams that need deep workflow customization or enterprise compliance features, Jira is the more established choice. Read our [Jira pricing breakdown](/blog/jira-product-discovery-pricing) for details.

### Quackback for the feedback layer

If you use ClickUp for project management but need a dedicated [feedback and roadmap tool](/features/feedback), [Quackback](https://quackback.io) covers that layer. Quackback is [open source (AGPL-3.0) and self-hosted for free](/open-source), with a managed [Quackback Cloud](/pricing) if you would rather not run it yourself. Adding teammates does not trigger the workspace-wide upgrades ClickUp requires. Its [AI features](/features/mcp) are built in.

You get [feedback boards](/features/voting), [voting](/features/voting), [public roadmaps](/features/roadmap), and [changelogs](/features/changelog), plus an [MCP server](/features/mcp) that lets AI assistants read and triage feedback directly. Quackback has a native [ClickUp integration](/integrations/clickup) so feature requests flow into your ClickUp workspace as tasks. You get the feedback collection ClickUp does not provide, connected to the project management ClickUp does well.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Does ClickUp have a free plan?

Yes. ClickUp's Free Forever plan includes unlimited tasks, kanban boards, and basic custom fields. The limitations are significant: 60MB storage and 1 form. It is best suited for personal use or a quick evaluation. Most teams will need the Unlimited plan at $7/user/month as a minimum.

### Is ClickUp AI included in the workspace plans?

No. Brain AI is a separate product with its own pricing. The workspace plans (Free, Unlimited, Business, Business Plus, Enterprise) do not include AI features. You need to add Brain AI ($9/user/month) or Everything AI ($28/user/month) on top of your workspace plan. Brain AI is only available on paid workspace plans — you cannot add it to the Free Forever tier.

### How much does ClickUp cost for 50 users?

On the Business plan with annual billing, 50 users cost $600/month ($7,200/year) for the workspace alone. Add Brain AI and it becomes $1,050/month ($12,600/year). Add Everything AI and it becomes $2,000/month ($24,000/year). Enterprise pricing is custom — contact sales for a quote. Negotiated discounts of 20-25% are common at this team size.

### Can I put different users on different ClickUp plans?

No. ClickUp requires your entire workspace to be on the same plan. If one team member needs Business-tier features, every member of the workspace must upgrade to Business. This applies to both workspace plans and Brain AI plans.

### What is the difference between monthly and annual billing?

Annual billing saves 30-45% depending on the plan. Unlimited is $7/user/month (annual) versus $10/user/month (monthly). Business is $12 versus $19. Business Plus is $19 versus $29. The savings are substantial, but annual billing requires an upfront commitment.

### Does ClickUp offer a money-back guarantee?

Yes. ClickUp advertises a 100% money-back guarantee. If you are testing the platform, this reduces the risk of committing to an annual plan.

### What is Business Plus and how does it differ from Business?

Business Plus ($19/user/month annual) sits between Business and Enterprise. It includes everything in Business plus custom role creation, 50,000 automations per month (versus 5,000 on Business), subtasks in multiple lists, custom capacity in workload view, and priority support. It is not always prominently displayed on the pricing page but is available through ClickUp's help center and sales team.

- [Continuous Discovery: Talk to Users Every Week (Guide)](https://quackback.io/blog/continuous-discovery-habits): A practical guide to continuous discovery. How product teams build the habit of weekly user contact, opportunity mapping, and feedback-driven prioritization.

Published: 2026-03-24

Continuous discovery is the practice of maintaining regular contact with users throughout the product development cycle — not just during research sprints. Teams that do it build better products because they make decisions with fresh signal, not stale assumptions.

![Continuous discovery replaces periodic research bursts with steady weekly signal](/blog/continuous-discovery-habits/hero.webp)

Most product teams know they should talk to users more often. The problem is not awareness. It is habit. Research gets scheduled in bursts: a round of interviews before a big project kicks off, a survey after a launch goes sideways, a usability test when a designer insists. Between those bursts, the team operates on assumptions. And assumptions decay fast.

The continuous discovery framework offers a different approach. Instead of treating user research as a project, you treat it as a practice. Something you do every week, not every quarter. The result is a steady stream of insight that keeps your team grounded in real user problems instead of internal narratives about what users want.

> **Continuous discovery** is the practice of maintaining at least weekly contact with users throughout the product development cycle, not just during research sprints. The product trio (PM, designer, engineer) talks to users every week, maps what they learn onto an opportunity solution tree, and tests assumptions before building. The result is a steady stream of fresh signal that grounds decisions in real user problems instead of stale assumptions.

## What is continuous discovery

Continuous discovery is a framework popularized by Teresa Torres in her book *Continuous Discovery Habits*. The core idea is straightforward: product teams should engage with users at least once a week, every week, throughout the product development process.

Torres defines the practice around six key habits:

1. **Outcome-oriented** — Start with a clear desired outcome, not a feature idea
2. **Customer-driven** — Talk to customers weekly, not quarterly
3. **Collaborative** — The product trio (PM, designer, engineer) discovers together
4. **Visual** — Map opportunities with the opportunity solution tree
5. **Experimental** — Test assumptions before building
6. **Continuous** — Discovery and delivery run in parallel, not in sequence

This differs from periodic research sprints in several important ways:

**Frequency over depth.** A 30-minute conversation every week gives you more useful signal than a two-week research sprint every quarter. Weekly contact means you catch changes in user behavior and needs as they happen, not months after the fact.

**Embedded in the team.** In periodic research, a researcher goes away, conducts studies, and returns with a report. In continuous discovery, the product trio — product manager, designer, and engineer — participates directly. The people making decisions are the same people hearing from users.

**Connected to current work.** Each week's conversations are tied to the problems and opportunities the team is actively working on. You are not building a general library of insights. You are answering specific questions about specific decisions you need to make this week.

**Lightweight by design.** Continuous discovery does not require a research lab or a formal recruitment process. It works with short interviews, quick prototype tests, [feedback board](/features/voting) analysis, and automated surveys. The bar for "enough" is low enough to sustain weekly.

The shift is cultural. Teams that practice continuous discovery stop treating user insight as a phase and start treating it as an input that is always available.

## The opportunity solution tree

The opportunity solution tree (OST) is the core framework within continuous discovery for connecting what you learn from users to what you build. Teresa Torres introduced it as a way to structure the messy space between a desired outcome and the solutions you ship.

![The opportunity solution tree connects outcomes to opportunities, solutions, and experiments](/blog/continuous-discovery-habits/opportunity-solution-tree.webp)

The tree has four levels:

**Desired outcome.** This is the measurable result your team is trying to achieve. "Increase activation rate from 30% to 50%" or "Reduce time to first value from 3 days to 1 hour." It comes from your [product strategy](/blog/product-strategy-guide), not from users. Users don't set your outcomes — they reveal the opportunities that help you reach them.

**Opportunities.** These are unmet needs, pain points, and desires you discover through user contact. "Users struggle to understand which features matter during onboarding." "Users can't find how to invite their team." Each opportunity is a problem space, not a solution.

Torres distinguishes three types of opportunities:
- **Pain points** — things that frustrate users about their current workflow ("I spend 2 hours per week copying feedback from Slack into a spreadsheet")
- **Needs** — things users want but don't have ("I need to see which features our enterprise users care about most")
- **Desires** — things that would make users' lives better even if they haven't articulated them ("I wish my feedback tool would auto-suggest which requests to merge")

Structure opportunities as a hierarchy. A top-level opportunity like "users struggle to prioritize feature requests" breaks down into sub-opportunities: "can't see demand across multiple channels," "no way to weight requests by customer value," "team disagrees on what matters." Each sub-opportunity is more specific and more actionable.

**Solutions.** For each opportunity, you brainstorm multiple possible solutions. The tree structure forces you to consider alternatives instead of jumping to the first idea. "Guided onboarding tour," "personalized setup wizard," and "interactive checklist" are three different solutions to the same opportunity.

The rule of thumb: generate at least three solutions for every opportunity before evaluating any of them. This prevents anchoring on the first idea and increases the odds of finding a better approach. Use "[How might we...](/blog/user-interview-questions)" prompts to expand the solution space.

**Experiments.** For each promising solution, you design a small experiment to test whether it actually addresses the opportunity. This might be a prototype test, a painted-door test, a concierge test, or a small-scale A/B test. The goal is to learn fast before committing engineering resources.

Here are four experiment types, ranked by effort:

| Experiment | Effort | What it tests | Example |
|---|---|---|---|
| **One-question survey** | 1 hour | Demand/interest | "Would you use X if we built it?" on your feedback board |
| **Painted door test** | 1 day | Real demand (not stated) | Add a button for the feature that tracks clicks but shows "coming soon" |
| **Prototype test** | 2-3 days | Usability and value | Clickable Figma prototype tested with 5 users |
| **Concierge test** | 1 week | End-to-end value | Manually deliver the solution to 10 users and measure outcomes |

The opportunity solution tree keeps your team honest. It prevents the common failure mode where someone has an idea, the team builds it, and nobody checks whether it actually solves a user problem. By mapping ideas back through opportunities to outcomes, every feature has a clear reason to exist.

## How to build the continuous discovery habit

Knowing the framework is the easy part. Building the habit is where most teams stall. Here is a practical approach to making continuous discovery stick, broken into a 12-week adoption plan.

### Week 1-4: Establish weekly user contact

**Schedule weekly user touchpoints.** Block 30-60 minutes per week for your product trio to talk to a user, watch a session replay, or review recent feedback. Put it on the calendar. Treat it like a standup — it happens every week regardless of what else is going on. The consistency matters more than the format.

Torres recommends "interview snapshots" — brief summaries of each user conversation captured in a consistent format. Use this template after every touchpoint:

- **Date and participant:** Who did you talk to? What segment are they in?
- **Key quote:** One verbatim statement that captures their core need
- **Opportunity identified:** What unmet need or pain point did you discover?
- **Surprise:** What did you learn that you did not expect?
- **Next action:** What should the team do with this insight?

Keep each snapshot to 5 lines or fewer. The constraint forces clarity. Store them in a shared document or channel where the entire trio can reference them during planning.

**Build a participant pipeline.** The most common reason teams stop doing weekly interviews is recruitment friction. Solve this upfront. Add an in-app prompt that asks "Would you be open to a 20-minute chat about your experience?" Offer a small incentive (gift card, early access). Target 10-15 signups per month. You only need one per week.

### Week 5-8: Automate always-on feedback

**Automate feedback collection.** You cannot sustain weekly discovery if every touchpoint requires manual recruitment and scheduling. Set up always-on feedback channels: a [feature request board](/features/voting) where users submit and vote on ideas, an [in-app feedback widget](/features/widget) that captures context automatically, and integrations that pull feedback from support tickets and sales calls into one place.

**Review feedback data in product reviews.** Make feedback analysis a standing agenda item in your weekly product review or planning session. Look at new feature requests, vote count changes, and recurring themes. This turns raw feedback into decision-ready input. You don't need to interview a user every week if you have a steady stream of structured feedback to analyze.

Here is a sample weekly discovery agenda (30 minutes):

1. **Review new feedback** (10 min) — Scan new submissions and votes on your feedback board. Flag anything that maps to current opportunities.
2. **Share interview snapshot** (5 min) — One team member presents their touchpoint from this week.
3. **Update the OST** (10 min) — Add new opportunities, reassess existing ones, decide which solutions to test next.
4. **Plan next touchpoint** (5 min) — Who are we talking to next week? What do we need to learn?

### Week 9-12: Connect discovery to delivery

**Connect insights to your roadmap.** Every insight should lead somewhere. When you identify an opportunity worth pursuing, add it to your opportunity solution tree. When a solution passes its experiment, move it to your [roadmap](/features/roadmap). When you ship it, close the loop by notifying the users who requested it. The feedback-to-roadmap pipeline is what makes discovery actionable instead of academic.

**Start small and expand.** If your team currently does zero user contact between quarterly research sprints, don't try to implement the full framework in week one. The 12-week plan above builds gradually: weekly conversations first, then automated feedback, then structured opportunity mapping. Build the habit before you build the system.

By week 12, your team should have: a populated opportunity solution tree, a steady stream of at least 4 user touchpoints per month, an active feedback board with vote data, and a clear connection between what users tell you and what shows up on your roadmap.

## Assumption testing

Before building anything, continuous discovery teams identify and test their riskiest assumptions. Every solution carries assumptions about desirability (do users want this?), usability (can users figure it out?), feasibility (can we build it?), and viability (does it work for the business?).

Torres recommends this process:

**1. List assumptions for each solution.** For a "feedback board with AI-powered triage" solution, assumptions might include: users will submit feedback through the board (desirability), users can find and use the voting mechanism (usability), the AI can accurately categorize feedback (feasibility), and reducing manual triage saves enough time to justify the cost (viability).

**2. Map assumptions on a risk matrix.** Plot each assumption on two axes: how certain you are it is true (low to high) and how critical it is to the solution's success (low to high). Test the assumptions in the upper-left quadrant first — high criticality, low certainty. Those are your "leap of faith" assumptions.

**3. Design the smallest possible test.** You do not need to build the full feature to test an assumption. A one-question [survey](/blog/nps-survey-template) can test desirability. A paper prototype can test usability. A technical spike can test feasibility. A spreadsheet model can test viability.

**4. Set a pass/fail criterion before you run the test.** "If 60% of interviewed users say they would use this feature at least weekly, the desirability assumption passes." Without a pre-set criterion, you will rationalize any result as positive.

## Outputs vs outcomes

Continuous discovery requires a fundamental mindset shift about what "progress" means. Most product teams measure progress in outputs: features shipped, story points completed, releases deployed. Continuous discovery reframes progress around outcomes: user problems solved, activation rates improved, churn reduced.

The distinction matters operationally. An output-focused team asks "what can we ship this sprint?" An outcome-focused team asks "what user problem should we solve this sprint, and what is the smallest thing we can build to test whether our solution works?"

Here is a concrete comparison:

| | Output-focused team | Outcome-focused team |
|---|---|---|
| **Sprint goal** | "Ship the Slack integration" | "Reduce manual feedback collection by 50%" |
| **Success metric** | Feature deployed to production | Users spend 50% less time on manual collection |
| **If it fails** | "We shipped it, success" | "The integration shipped but only reduced time by 10% — we need to iterate" |
| **Next action** | Move to next feature on the list | Investigate why the outcome was not reached, test a different approach |

Output thinking leads to feature factories. The team ships constantly but the product doesn't get meaningfully better. Users accumulate features they did not ask for and still lack the ones they need. The [roadmap](/blog/what-is-a-product-roadmap) becomes a feature list driven by internal ideas rather than user evidence.

Outcome thinking leads to deliberate product development. The team ships less frequently but each release is grounded in a real user need validated through discovery. Features are smaller and more targeted because they were designed to solve a specific problem, not to fill a sprint.

This is where feedback data becomes strategic. Vote counts on [feature requests](/features/voting) are a proxy for outcome demand. When 300 users vote for "Slack notifications when a teammate comments," that is not just a feature request — it is evidence of an unmet collaboration need. An outcome-focused team uses that signal to explore the opportunity ("users need real-time awareness of team activity") before committing to a specific solution.

## Dual-track agile: running discovery and delivery in parallel

A common objection to continuous discovery is that it slows down delivery. The opposite is true when you structure it correctly using dual-track agile.

The discovery track and delivery track run in parallel:

- **Discovery track** (product trio): interviewing users, mapping opportunities, designing experiments, and validating solutions. This produces validated opportunities and tested solution concepts.
- **Delivery track** (full team): building, testing, and shipping the solutions that passed through discovery. This produces working software.

The tracks operate on different cadences. Discovery runs weekly — new interview, new insights, new experiment results. Delivery runs in sprints or continuous flow. The output of discovery (validated solution concepts) feeds the input of delivery (the sprint backlog).

This means the team is never idle waiting for research. Engineers build solutions that discovery already validated while the product trio discovers and tests the next set of opportunities. The result is higher shipping velocity with fewer wasted features.

## Tools for continuous discovery

Continuous discovery works best when you have infrastructure that captures user signal without requiring constant manual effort. You need tools that keep the feedback channel open between formal interviews.

**Feedback boards** are the backbone of always-on discovery. They give users a place to submit feature requests, describe pain points, and vote on what matters most. Unlike interviews (which capture one user's perspective at a time), a feedback board accumulates signal from your entire user base continuously. Over weeks and months, patterns emerge that no single interview could reveal.

**Voting quantifies demand.** When users vote on feature requests, you get a rough but useful measure of how many people share a given need. This is not a substitute for qualitative understanding — you still need to understand *why* users want something — but it gives you a starting point for [prioritization](/blog/rice-framework-explained) that is grounded in real demand rather than assumptions.

**A public roadmap shows what you are doing about it.** Discovery without action erodes trust. When users see their feedback reflected in your roadmap, they keep providing it. When feedback disappears into a void, they stop. A [public roadmap](/features/roadmap) closes the [feedback loop](/blog/customer-feedback-loop) between "we heard you" and "here is what we are building."

**An in-app widget captures context.** Scheduled interviews give you depth. An [in-app feedback widget](/features/widget) gives you breadth. When a user hits a frustration point, they can submit feedback in the moment — with the page URL, their account context, and their emotional state captured automatically. This is signal you would never get in a scheduled interview because users forget the specifics by the time they sit down to talk.

[Quackback](/features/voting) automates the always-on feedback channel that continuous discovery depends on. Feature request boards capture ongoing signal between interviews. AI-powered [duplicate detection and merge suggestions](/features/feedback) keep your feedback organized as volume grows. Vote counts surface demand patterns. Automatic notifications tell users when their request ships, closing the loop without manual follow-up. Its [MCP server](/features/mcp) lets you query feedback directly from an AI assistant during discovery — ask "what are the top unmet needs from enterprise accounts this month" and get an answer grounded in real submissions. Quackback is [open source](https://github.com/quackbackio/quackback) (AGPL-3.0) with a managed [cloud](/pricing) option, so you can self-host for free or let us run it. For teams practicing continuous discovery, it replaces the spreadsheet-and-Slack approach with a [structured system](/blog/collect-customer-feedback) that scales.

## Product operations and continuous discovery

As organizations scale, the challenge of continuous discovery shifts from "how does one team do it" to "how do multiple teams do it consistently." This is where product operations comes in.

Product ops teams create the systems and processes that make discovery scalable. They standardize how feedback is collected across teams. They build shared repositories of insights so that one team's discovery benefits others. They ensure that feedback from sales, support, and customer success reaches the product teams that need it.

In practice, product ops supports continuous discovery by:

- **Centralizing feedback infrastructure.** One feedback board, one source of truth for feature requests, shared across all product teams. This prevents the common problem of three teams collecting feedback in three different tools with no cross-visibility.
- **Automating feedback routing.** When a support ticket contains a feature request, it should automatically surface in the relevant product team's feedback pipeline. When a sales call reveals a deal-blocking gap, that signal should reach the team responsible for that area.
- **Reporting on discovery health.** Product ops can track whether teams are maintaining weekly user contact, how much feedback is being collected, and whether insights are being connected to roadmap decisions. These metrics keep continuous discovery from quietly fading after the initial enthusiasm wears off.

Track these discovery health metrics monthly:

| Metric | Target | Why it matters |
|---|---|---|
| Weekly user touchpoints per team | At least 1 | Minimum viable discovery |
| Interview snapshots created | 4+ per month | Evidence the team is capturing insights |
| New opportunities identified | 2-3 per month | Discovery is producing actionable input |
| Assumptions tested | 2+ per month | Team is validating before building |
| Feedback submissions per week | Growing or stable | Users trust the feedback channel |
| Time from feedback to roadmap | Under 30 days | Discovery is connected to delivery |

For product ops teams managing feedback at scale, tools that aggregate signal across boards, tag requests by product area, and surface trends automatically reduce the operational burden of keeping discovery running across an entire product organization.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How is continuous discovery different from agile user research?

Continuous discovery is broader than agile user research. Agile research happens within sprint cycles, testing prototypes and feeding findings into the next sprint. Continuous discovery adds ongoing feedback collection, opportunity mapping, and assumption testing, tied to a framework that connects every user contact to a desired outcome.

### What if our users will not talk to us every week?

You do not need the same users or a formal interview every week. Rotate through segments, and count feedback board submissions, support tickets, and session replays as user contact. Build a standing opt-in pipeline so a small slice of active users keeps a steady supply of willing participants on hand.

### How do you balance continuous discovery with shipping speed?

Discovery and delivery run in parallel, not in competition. While engineers build solutions validated in previous weeks, the product trio discovers and tests the next set of opportunities. This dual-track approach means discovery does not slow shipping. It makes shipping more targeted, so fewer features get built that nobody needs.

### Do you need a dedicated researcher for continuous discovery?

No. Continuous discovery is designed for the product trio (product manager, designer, and tech lead), not a separate research team. A dedicated researcher can add depth and coach teams on [interview technique](/blog/user-interview-questions), but the habit of weekly user contact should belong to the people making product decisions.

### How does continuous discovery connect to product strategy?

Your [product strategy](/blog/product-strategy-guide) sets the desired outcomes at the top of your opportunity solution tree. Discovery fills in everything below: the opportunities, solutions, and experiments. Without a strategy, discovery produces insights with no direction. Without discovery, strategy produces bets based on assumptions. The two practices reinforce each other.

### What is the minimum viable version of continuous discovery?

One 20-minute user conversation per week, captured in an interview snapshot and shared with the product trio. That is the floor. Add a [feedback board](/features/voting) to collect signal between conversations, and you have the two core inputs (qualitative interviews and quantitative vote data) that drive the rest of the framework.

- [Customer Experience Management: How Feedback Drives Better CX](https://quackback.io/blog/customer-experience-management): A practical guide to customer experience management. How to use feedback boards, VoC programs, and closed-loop processes to improve CX across every touchpoint.

Published: 2026-03-24

Customer experience management is the practice of designing, measuring, and improving every interaction a customer has with your product. Most teams treat it as a department or a dashboard. The teams that do it well treat it as a feedback loop.

Analytics tell you what happened. Feedback tells you why. A customer who abandons onboarding at step three is a data point. A customer who tells you that step three is confusing and the help docs are wrong is a diagnosis. Customer experience management without feedback is pattern recognition without understanding. You see the symptoms but miss the cause.

This guide covers how to build a CX management strategy grounded in customer feedback. You will learn why feedback is the foundation of CX, how to build a structured feedback process across touchpoints, which tools and metrics matter, and how to close the loop so customers know their input shaped your product.

![The customer experience management feedback loop: collect, analyze, build, announce, repeat](/blog/customer-experience-management/hero.webp)

> **Customer experience management** is the practice of designing, measuring, and improving every interaction a customer has with your product across the full lifecycle. The strongest CX programs run on a structured feedback loop: collect input across touchpoints, quantify demand with voting, act on it through your roadmap, and close the loop in your changelog. Analytics tell you what happened; feedback tells you why, which is the signal most CX programs are missing.

## What is customer experience management

Customer experience management — often shortened to CX management or CXM — is the systematic process of understanding, designing, and improving every touchpoint a customer has with your company. It spans the full lifecycle: awareness, evaluation, purchase, onboarding, usage, support, renewal, and advocacy.

It is not customer service. Customer service is reactive — a customer has a problem, you solve it. Customer experience management is proactive. You study the entire journey, identify where friction exists, and improve the experience before customers need to ask for help. Customer service is one touchpoint within CX. CX management is the system that encompasses all touchpoints.

The connection to feedback is fundamental. You cannot improve what you do not measure. And you cannot measure experience with analytics alone. Behavioral data shows you what customers do. Feedback shows you what they think, what frustrates them, and what they wish existed. A digital customer experience management strategy that ignores direct customer input is operating on half the signal.

The best CX programs combine quantitative data (what happened) with qualitative feedback (why it happened) and use both to inform decisions. The feedback layer is where most programs are weakest — not because teams do not care about customer input, but because they lack a structured system to collect, organize, and act on it.

## Why feedback is the foundation of CX

Every CX improvement starts with understanding the gap between what customers expect and what they experience. Feedback is the most direct way to measure that gap.

**Analytics miss intent.** You can see that 40% of users drop off during onboarding. You cannot see why. Was the flow too long? Was a required field confusing? Did the user get distracted and plan to come back? Analytics give you the "what." Feedback gives you the "why." Without both, your team is guessing at solutions.

**Feedback captures unmet needs.** A customer who submits a feature request is telling you what they expected your product to do but could not. This is experience data. It reveals the gap between their mental model and your product's reality. Aggregated across hundreds of customers, feature requests become a map of unmet expectations — exactly the input a CX management strategy needs.

**Frustration shows up in feedback before it shows up in churn.** A customer who writes a negative comment on your feedback board is still engaged. A customer who quietly cancels is gone. Feedback is a leading indicator of experience problems. By the time a CX issue appears in your churn metrics, you have already lost the customers it affected. Monitoring feedback sentiment lets you catch problems while they are still fixable.

**Feedback creates accountability.** When a customer submits a suggestion and your team updates its status — from "under review" to "planned" to "shipped" — that is a visible act of responsiveness. It demonstrates that customer input shapes the product. This accountability loop is the core of effective customer experience management. Customers who see their feedback acknowledged stay engaged longer, give higher satisfaction scores, and become advocates.

Here is a concrete example. Suppose your analytics show a 30% drop-off on your pricing page. Without feedback, your team might guess: "The pricing is too high." Or: "The page loads too slowly." Or: "The tiers are confusing." With feedback, a customer tells you: "I could not figure out which plan includes API access. The comparison table does not mention it." That is a different problem with a different solution — one that analytics alone would never surface. The fix is not a price change or a performance optimization. It is a clearer comparison table.

This pattern — analytics reveal the "what," feedback reveals the "why" — repeats across every CX touchpoint. The teams that combine both signals make better decisions than teams that rely on either one alone.

## Building a CX management strategy with feedback

A customer experience management strategy does not require an enterprise CX platform or a dedicated team of analysts. It requires a structured process for collecting feedback, understanding it, and acting on it. Here is how to build one.

### Collect feedback across touchpoints

Customer experience spans multiple moments. Your feedback collection should too. Different touchpoints surface different types of signal.

**In-app feedback** captures reactions at the moment of experience. A user hits a confusing workflow and can report it without leaving the page. An embedded [feedback widget](/features/widget) reduces friction and preserves context — you know what page the user was on and what they were doing.

**Feature request boards** capture what customers wish your product could do. A public [feedback board](/features/feedback) with [voting](/features/voting) surfaces demand and lets customers see that others share their needs. This is experience data — it reveals the gap between what your product offers and what customers expect.

**Post-interaction surveys** measure satisfaction at specific touchpoints. A CSAT survey after a support conversation measures service quality. An NPS survey measures overall loyalty. The open-ended follow-up question on these surveys often contains the most actionable CX insight.

**Support conversations** are feedback in disguise. Every ticket about a confusing setting, every chat asking how to accomplish a basic task — these are experience signals. Integrating your support tools with your feedback system turns reactive conversations into proactive CX data.

### Centralize feedback in one place

Feedback scattered across a dozen tools is invisible. A feature request in Intercom, a complaint on Twitter, a suggestion in a support ticket, and a vote on your feedback board might all describe the same experience problem. If they live in separate systems, the pattern never surfaces.

Route all feedback channels into a single system. A feedback board works well as the hub because it creates a searchable, votable backlog. Support integrations pipe in ticket themes. Widget submissions land directly on the board. Sales call notes get logged as internal posts. When everything is in one place, patterns emerge.

Here is what a centralized feedback architecture looks like in practice:

| Source | Integration | What it captures |
|---|---|---|
| In-app widget | Direct submission to board | Real-time product friction |
| Support tickets (Zendesk, Intercom) | Auto-tag and forward themes | Recurring pain points |
| Sales calls | Manual internal post by sales rep | Prospect objections and unmet needs |
| Social media | Manual or automated forward | Public sentiment and brand issues |
| NPS/CSAT surveys | Open-ended responses piped to board | Satisfaction drivers and detractors |
| Feedback board (public) | Native | Feature requests and votes |

The goal is not to pipe every message verbatim. It is to ensure that experience patterns from any channel surface in one place where your product team can see them, quantify them, and act on them. For more on setting up this system, see our [guide to collecting customer feedback](/blog/collect-customer-feedback).

### Quantify with voting

Not all experience problems are equal. Voting lets your customers tell you which ones matter most. A feature request with 200 votes represents a different level of urgency than one with 3. A usability complaint that dozens of users have upvoted is a higher priority than one submitted by a single user.

Voting transforms qualitative feedback into quantitative CX signal. It gives your team a defensible basis for prioritization — not opinion, not the loudest stakeholder in the room, but measured demand from the people who use your product.

![CX feedback flow: multiple sources feed into a central board, which connects to your roadmap and changelog](/blog/customer-experience-management/cx-feedback-flow.webp)

### Connect feedback to your roadmap

Feedback that does not connect to product decisions is wasted. The bridge between customer input and product action is your roadmap. When your team accepts a feedback item and moves it to "planned," it should appear on a public [roadmap](/features/roadmap) that customers can see. This does two things: it tells customers their input matters, and it aligns your team around experience-driven priorities.

The connection also helps you prioritize. When you can see that 150 users voted for "improve onboarding flow" and 8 users voted for "add dark mode," the data makes the priority obvious. This is more reliable than internal stakeholder opinions and faster than commissioning a formal study. For frameworks on how to prioritize what you build, see our guides on [RICE scoring](/blog/rice-framework-explained) and [MoSCoW prioritization](/blog/moscow-prioritization).

### Close the loop

Closing the loop is the most important step in CX management and the one most teams skip. When you ship a feature that customers requested, tell them. When you fix a usability issue that users reported, announce it in your [changelog](/features/changelog). When you decide not to build something, explain why.

Closing the loop converts a one-directional feedback channel into a relationship. Customers who see the cycle — submit, vote, track, ship, announce — develop trust in the process. They give better feedback. They stay longer. They tell others. This is where customer experience management stops being a process and starts being a competitive advantage. For a detailed guide on building this cycle, see our [customer feedback loop guide](/blog/customer-feedback-loop).

## CX maturity: Where does your team stand?

Not every team needs a full CX management platform on day one. The right approach depends on your current maturity level. Here is a framework for assessing where you are and what to do next.

**Level 1: Reactive.** You fix problems when customers complain. There is no structured feedback collection. Support handles issues one at a time. CX improvements happen accidentally, not systematically. **Next step:** Set up a feedback board and start collecting input in one place.

**Level 2: Collecting.** You gather feedback through surveys, a suggestion box, or a feedback board. But the feedback sits in a backlog that nobody owns. It does not connect to your product roadmap. **Next step:** Assign ownership. One person reviews new feedback weekly and updates statuses.

**Level 3: Prioritizing.** You collect and organize feedback. Voting surfaces demand. Your team references feedback data when making product decisions. But customers do not know what happened to their input. **Next step:** Publish a public roadmap. Connect feedback statuses to your roadmap so customers see progress.

**Level 4: Closed-loop.** You collect feedback, prioritize it, build based on it, and announce what shipped. Customers who submitted ideas get notified. The [customer feedback loop](/blog/customer-feedback-loop) is complete. Your changelog references the feedback that motivated each change. **Next step:** Measure the loop. Track time-to-close, submission volume trends, and the correlation between feedback-driven features and retention.

Most teams are at Level 1 or 2. Getting to Level 3 is a process change, not a technology investment. Getting to Level 4 is where tools like [Quackback](https://quackback.io) make the difference — the automation of notifications, status syncing, and changelog generation is what makes the closed loop sustainable at scale.

## Customer experience management tools

CX management is not a single tool. It is a stack of tools that cover different parts of the customer journey. Here is how the categories fit together.

**Analytics tools (Amplitude, Mixpanel, PostHog).** These track behavioral data — what users do inside your product. Page views, feature adoption, funnel conversion, retention curves. They answer the "what" question: what is happening across the customer journey. They do not answer why.

**Survey tools (Typeform, SurveyMonkey).** These handle structured feedback collection: NPS, CSAT, CES, and custom questionnaires. They are good for measuring sentiment at specific touchpoints and benchmarking over time. They do not handle ongoing feature requests, voting, or public roadmaps. For templates, see our [NPS survey template](/blog/nps-survey-template) and [customer satisfaction survey template](/blog/customer-satisfaction-survey-template).

**Feedback and prioritization tools (Quackback, Canny).** These handle the layer between raw customer input and product decisions: feedback boards, voting, status tracking, roadmap, and changelog. [Quackback](https://quackback.io) is the strongest option in this category — open source, free to self-host, with AI-powered triage, duplicate detection, and sentiment analysis, and integrations including [Slack](/integrations/slack), Intercom, Zendesk, Jira, and Linear. An [MCP server](/features/mcp) also exposes your feedback to AI assistants, so you can ask questions across your CX backlog in natural language. It handles the feedback layer of CX management: collecting what customers want, quantifying demand through voting, and closing the loop when you ship. For a broader comparison, see our guide to the [best customer feedback tools in 2026](/blog/best-customer-feedback-tools-2026) or a direct look at [Quackback vs Canny](/compare/quackback-vs-canny).

**Support tools (Zendesk, Intercom, Help Scout).** These manage reactive customer interactions: tickets, live chat, and help center content. Every support interaction contains CX data. The best setup routes patterns from support conversations into your feedback board so experience insights are not trapped in resolved tickets.

The feedback layer is where most CX stacks have a gap. Teams invest in analytics and support but lack a structured system for collecting, prioritizing, and acting on direct customer input. Filling that gap — with a feedback board, voting, and a closed-loop process — is the highest-leverage improvement most teams can make to their customer experience management strategy.

## CX metrics that connect to feedback

Metrics keep your CX program honest. The ones that matter most are the ones that connect to what customers are actually telling you.

**Net Promoter Score (NPS).** Measures loyalty on a 0-10 scale. Useful as a trend indicator — a declining NPS is an early warning. The follow-up question ("What's the primary reason for your score?") is where the actionable CX insight lives. Track NPS quarterly and segment by customer type. Use our [NPS calculator](/tools/nps-calculator) to compute your score.

**Customer Satisfaction Score (CSAT).** Measures satisfaction with a specific interaction on a 1-5 scale. Deploy immediately after support conversations, onboarding completion, or major feature interactions. CSAT is contextual — it tells you how a specific touchpoint performs, not how customers feel overall. Use our [CSAT calculator](/tools/csat-calculator) to track it.

**Customer Effort Score (CES).** Measures how easy it was for a customer to accomplish a task. "How easy was it to resolve your issue?" on a 1-7 scale. High effort correlates strongly with churn. If customers consistently report that a specific workflow is difficult, that is a CX problem worth prioritizing regardless of what your analytics show.

**Feature request volume.** The total number of feature requests submitted per period. Rising volume indicates engaged users who trust the feedback channel. Declining volume is a warning — either your product is meeting all needs (unlikely) or customers have stopped expecting their input to matter. Track this alongside the ratio of requests that move to "planned" or "shipped."

**Time to close the loop.** The elapsed time from when a customer submits feedback to when they receive a status update. This measures the health of your CX feedback process. A short time to close signals that the team is responsive. A long time signals that feedback is collecting dust. The best teams respond to new submissions within days, not months.

Here is a practical CX metrics dashboard you can set up with existing tools:

| Metric | Source | Review cadence | Action threshold |
|---|---|---|---|
| NPS | Quarterly survey | Quarterly | Drop of 5+ points triggers investigation |
| CSAT | Post-interaction survey | Weekly | Score below 4.0 triggers process review |
| CES | Post-task survey | Monthly | Score above 5 (on 7-point scale) flags friction |
| Feature request volume | Feedback board | Weekly | 20%+ decline signals engagement problem |
| Time to first response | Feedback board | Weekly | Over 5 business days triggers triage review |
| Feedback-to-ship ratio | Feedback board + changelog | Monthly | Below 10% suggests backlog debt |

You do not need all six metrics on day one. Start with NPS and feature request volume. Add the others as your CX process matures. The key is regular review — metrics you check quarterly are lagging indicators. Metrics you check weekly are actionable. For a deeper dive into feedback analysis, see our guide on [AI-powered customer feedback analysis](/blog/ai-customer-feedback-analysis).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is customer experience management?

Customer experience management is the practice of designing, measuring, and improving every interaction a customer has with your product, from first awareness through renewal. Unlike reactive customer service, it is proactive: you study the journey and fix friction before customers ask. The foundation is direct customer feedback. See our [Voice of the Customer guide](/blog/voice-of-customer).

### What tools do I need for customer experience management?

Most teams need four categories: analytics (Amplitude, Mixpanel) for behavioral data, surveys (Typeform) for sentiment, a feedback and prioritization tool ([Quackback](https://quackback.io)) for collecting and acting on customer input, and a support tool (Zendesk, Intercom) for reactive interactions. The feedback layer is where most stacks have a gap. You do not need a dedicated CX platform to start.

### How is digital customer experience management different from traditional CX?

Digital customer experience management focuses on online touchpoints: product UI, onboarding flows, in-app messaging, and support chat. Traditional CX includes physical interactions like retail and in-person onboarding. The principles are the same, but digital CX adds richer behavioral data (analytics, session recordings) alongside feedback, making it easier to correlate what users say with what they do.

### How do I start a customer experience management strategy with limited resources?

Start with the feedback loop. Set up a [feedback board](/features/feedback) where customers submit ideas and vote, connect it to your support tool, review feedback weekly, and publish a [changelog](/features/changelog) when you ship. This lightweight cycle (collect, prioritize, build, communicate) needs no dedicated CX team or expensive software. Scale the tooling as volume grows.

Here is a week-one action plan:

1. **Day 1:** Set up a feedback board with [Quackback](https://quackback.io) (free to self-host, under 5 minutes to deploy)
2. **Day 2:** Connect your support tool (Zendesk, Intercom, or Help Scout) so ticket themes route to the board
3. **Day 3:** Add an in-app [feedback widget](/features/widget) so users can submit without leaving your product
4. **Day 4:** Review existing support tickets from the past month and create feedback posts for recurring themes
5. **Day 5:** Share the board with your team. Assign one person as the triage owner. Set a weekly 15-minute review meeting.

This is enough to start the CX feedback cycle. No enterprise platform required. For a broader overview of feedback tools, see our guide to the [best customer feedback tools](/blog/best-customer-feedback-tools-2026).

- [Digital Suggestion Box: Why Modern Teams Use Feedback Boards Instead](https://quackback.io/blog/digital-suggestion-box): The digital suggestion box has evolved. Learn why product teams are replacing traditional suggestion boxes with feedback boards, voting, and public roadmaps.

Published: 2026-03-24

The suggestion box has been around for decades. Drop a note in the slot and hope someone reads it. The digital version made the slot a web form and the box a database, but the fundamental problem remained: suggestions go in and nothing comes out.

The best teams have moved past the suggestion box entirely. They use feedback boards with voting, status tracking, and public roadmaps. The shift is not about technology. It is about closing the loop between the people who submit ideas and the people who build the product.

This guide covers why traditional suggestion boxes fail, how modern feedback boards solve each failure, what to look for in a suggestion box alternative, and practical setups for customer-facing, internal, and product discovery use cases.

![Evolution from a one-directional suggestion box to a modern feedback board with voting and status tracking](/blog/digital-suggestion-box/hero.webp)

## What is a digital suggestion box

A digital suggestion box is an online tool that lets customers or employees submit ideas, feature requests, or feedback through a form or portal. It replaces the physical box with a web interface. At its simplest, it is a Google Form connected to a spreadsheet. At its most sophisticated, it becomes something closer to a feedback board — with voting, categorization, and status tracking.

The term covers a wide range of tools: free online suggestion box platforms, anonymous feedback tools, dedicated suggestion box software, and general-purpose form builders repurposed for feedback collection. The common thread is that users submit input and someone on the receiving end is supposed to do something with it.

The problem is that "supposed to" does most of the work in that sentence.

## Why traditional suggestion boxes fail

Whether physical or digital, suggestion boxes share structural flaws that limit their usefulness.

**No prioritization.** Every suggestion carries equal weight. A request submitted by one person looks the same as an idea that a hundred people care about. Without a mechanism to surface demand, the team reviewing suggestions has no way to distinguish signal from noise. They end up building based on whoever wrote the most persuasive note or whoever submitted most recently.

**No transparency.** The person who submits a suggestion has no visibility into what happens next. Did anyone read it? Is the team considering it? Was it rejected? This black hole erodes trust. Users who submit ideas and hear nothing stop submitting. Over time, the suggestion box goes quiet — not because people have nothing to say, but because they have learned that saying it is pointless.

**No follow-through.** Most suggestion boxes lack any workflow for turning a suggestion into action. There is no triage process, no status tracking, no assignment to a team. Suggestions accumulate in a spreadsheet or inbox that nobody owns. A quarterly review meeting pulls out a few interesting ones, but the rest are forgotten.

**No way to measure demand.** If five people submit variations of the same idea through separate form submissions, you have five rows in a spreadsheet that may not even look related. There is no aggregation, no deduplication, no vote count. The most requested feature and the least requested feature are indistinguishable.

**No conversation.** A suggestion box is one-directional. The submitter writes something and walks away. There is no mechanism for the team to ask clarifying questions, for other users to add context, or for the submitter to see that others share the same need. The richest signal — the conversation around an idea — never happens.

These problems apply equally to a physical employee suggestion box, a virtual suggestion box on your intranet, and a customer suggestion box on your website. The format is not the issue. The architecture is.

Here is what the suggestion box lifecycle actually looks like at most companies:

1. Team launches suggestion box with enthusiasm
2. Suggestions flow in during the first month
3. Team reviews suggestions sporadically — no clear owner, no process
4. Submitters hear nothing back
5. Submission rate drops as users learn that input is ignored
6. The suggestion box becomes a dead page that nobody visits
7. Someone asks "why aren't we getting feedback?" and the cycle repeats

The pattern is predictable because it is structural. The tool is designed for collection, not action. Fixing this requires a different architecture, not a better form.

## From suggestion box to feedback board

The evolution from suggestion box to modern feedback tool happened in stages. Each stage solved a specific failure of the previous one.

![Four stages of suggestion box evolution: physical box, digital form, feedback board with voting, and closed-loop feedback with roadmap](/blog/digital-suggestion-box/evolution-stages.webp)

**Stage 1: Physical suggestion box.** Anonymous, unstructured, one-directional. Someone empties the box periodically and skims what is inside. No prioritization, no tracking, no follow-up.

**Stage 2: Digital suggestion box.** A form on a website or intranet that collects submissions into a database or spreadsheet. Easier to search and sort than paper, but still lacks prioritization, transparency, and conversation. Most online suggestion box tools stop here.

**Stage 3: Feedback board with voting.** Users submit ideas to a public or private board. Other users can see existing submissions and vote on the ones they care about. Duplicates are reduced because users find existing requests before creating new ones. Demand becomes quantifiable. Ten votes on a single request is a clearer signal than ten separate form submissions. [Feature voting](/features/voting) transforms a pile of suggestions into a ranked list of priorities.

**Stage 4: Feedback board with roadmap and closed loop.** The board connects to a public [roadmap](/features/roadmap) that shows what the team is working on and what is coming next. When a suggestion moves from "under review" to "planned" to "shipped," the people who submitted and voted on it get notified. The team publishes a [changelog](/features/changelog) that announces what was built and why. The loop closes: submit, vote, track, ship, announce.

Stage 4 is where the best product teams operate today. It solves every failure of the traditional suggestion box: prioritization through voting, transparency through status tracking, follow-through via roadmap integration, demand measurement through vote aggregation, and conversation through comments and updates.

## What to look for in a modern suggestion box alternative

If you are evaluating tools to replace a suggestion box — whether for customers, employees, or both — here is what matters.

**Voting.** Users should be able to vote on existing ideas instead of creating duplicates. Voting surfaces demand and reduces noise. Without it, you are back to manually counting similar submissions in a spreadsheet.

**Transparency.** Every submission should have a visible status: open, under review, planned, in progress, shipped, or declined. Users should be able to track the status of their ideas without asking.

**Status tracking and notifications.** When the status of a suggestion changes, the people who submitted or voted on it should be notified automatically. This is what closes the loop. It turns a one-directional submission into an ongoing relationship.

**Anonymous option.** Some feedback — especially employee feedback — is more honest when anonymous. An anonymous feedback tool option encourages submissions that people would not attach their name to. Look for tools that support anonymous posting without requiring it for all submissions.

**Integrations.** Your suggestion box alternative should connect to the tools your team already uses. Slack notifications for new submissions. Jira or Linear integration so accepted ideas become tickets. Intercom or Zendesk integration so support conversations feed into your feedback board. The fewer manual steps between submission and action, the more likely action happens.

**Public or private boards.** A customer suggestion box is usually public — users see what others have submitted and can vote. An employee suggestion box may need to be private or restricted to specific teams. The right tool supports both.

**Search and deduplication.** As volume grows, duplicate suggestions become a real problem. AI-powered duplicate detection catches redundant submissions and merges them, keeping your board clean and your vote counts accurate.

**Categorization and tagging.** You need a way to organize suggestions by theme, product area, or urgency. Without categories, a board with 200+ suggestions becomes as hard to navigate as a spreadsheet. Tags let your team filter by what matters — "UX issues" versus "new features" versus "billing questions."

Here is a quick evaluation checklist you can use when comparing tools:

| Capability | Suggestion box | Feedback board |
|---|---|---|
| Collect submissions | Yes | Yes |
| Users see existing ideas | No | Yes |
| Voting / prioritization | No | Yes |
| Status tracking | No | Yes |
| Notifications on updates | No | Yes |
| Public roadmap | No | Yes |
| Duplicate detection | No | Yes |
| Conversation / comments | No | Yes |
| Anonymous option | Sometimes | Configurable |

If a tool only checks the "Suggestion box" column, it will reproduce the same problems you are trying to solve.

## Online suggestion box ideas for your team

The right setup depends on who you are collecting feedback from and what you plan to do with it.

### For customer-facing products

Set up a public [feedback board](/features/feedback) where customers can submit feature requests, report usability issues, and vote on ideas from other users. Link it from your app's navigation or help menu so users can find it without searching. Connect an in-app [feedback widget](/features/widget) so users can submit ideas without leaving your product. Publish a public roadmap so customers can see what you are building next.

This setup replaces the traditional customer suggestion box with something that actively reduces support volume. When users can see that an issue is already reported and planned, they stop opening support tickets about it.

### For internal teams

Create a private board for employee suggestions about processes, tools, and workplace improvements. Enable anonymous submissions so employees can raise sensitive topics without hesitation. Review the board in a regular meeting — weekly or biweekly — and update statuses so employees see that their input is being considered.

The employee suggestion box fails most often because submissions are never acknowledged. A board with visible statuses and a regular review cadence solves this.

A practical setup for an internal suggestion board:

- **Categories:** Processes, Tools, Workplace, Culture, Other
- **Review cadence:** Biweekly during team leads meeting
- **Response SLA:** Every new submission gets a status update within 5 business days
- **Owner:** One person is responsible for triaging — not necessarily acting on every suggestion, but ensuring every submission is acknowledged
- **Transparency rule:** When a suggestion is declined, post a brief explanation. "We considered this and decided not to pursue it because [reason]" is more respectful than silence.

### For product discovery

Use a feedback board during early-stage product development to validate ideas before committing resources. Share it with beta users or a customer advisory board. The voting data tells you which problems matter most to the people who will use your product. This is more reliable than internal opinions and faster than running formal surveys.

The feedback board becomes a lightweight form of [continuous discovery](/blog/continuous-discovery-habits). Instead of scheduling formal user interviews for every question, you have an always-on channel where users tell you what matters. You still need interviews for depth, but the board handles breadth — surfacing which problems to investigate further. For more on validating product assumptions early, see our [value hypothesis guide](/blog/value-hypothesis).

## Suggestion box tools compared

Teams replacing a suggestion box typically consider three categories of tools.

**General-purpose forms (Google Forms, Typeform).** These are free or cheap and quick to set up. They work as a basic digital suggestion box — users fill out a form, submissions land in a spreadsheet. But there is no voting, no status tracking, no public board, and no way for users to see what others have submitted. Every suggestion is isolated. You get collection without any of the mechanisms that make feedback useful. A free online suggestion box built on Google Forms is better than nothing, but not by much.

**Project management tools (Jira, Trello, Asana).** Some teams repurpose a Kanban board as a suggestion box. Users submit tickets, the team moves them through columns. This works for internal teams where everyone has access to the tool. It fails for customer-facing use cases because project management tools are not designed for public submission, voting, or transparency. They also introduce significant friction — asking a customer to create a Jira ticket is not a realistic feedback channel.

**Purpose-built feedback boards (Quackback, Canny, Featurebase).** These tools are designed specifically for the suggestion-to-roadmap workflow. [Quackback](https://quackback.io) provides feedback boards, voting, status tracking, a public roadmap, changelog, and AI-powered triage — open source and free to self-host. Canny and Featurebase are hosted alternatives with similar core features. A purpose-built feedback board beats a form because it adds prioritization, transparency, and closed-loop communication. It beats a project management tool because it is designed for the people submitting ideas, not just the people building the product.

For most teams, the jump from a form-based suggestion box to a feedback board is the highest-leverage change you can make. The technology difference is small. The process difference is transformative.

## How to migrate from a suggestion box to a feedback board

If you already have a suggestion box with existing submissions, here is how to transition without losing data or momentum.

**Step 1: Export existing suggestions.** Pull all submissions from your current tool — whether it is a Google Sheet, a Typeform response list, or an email inbox. You need the suggestion text, the submitter (if known), and the date.

**Step 2: Deduplicate and categorize.** Before importing, group similar suggestions together. Five variations of "add dark mode" should become one feedback post with a note that multiple users requested it. This is the manual version of the deduplication that a feedback board handles automatically going forward.

**Step 3: Import into your feedback board.** Create posts for each unique suggestion. If you know how many people submitted the same idea, add proxy votes so the vote count reflects historical demand. [Quackback](https://quackback.io) supports bulk import and proxy voting for exactly this scenario.

**Step 4: Update statuses.** Any suggestion that is already in progress, planned, or completed should have its status set before you make the board visible. Users should see an active, maintained board on day one — not a fresh import with everything marked "open."

**Step 5: Announce the switch.** Tell your users (or employees) that the suggestion box has been replaced and where to find the new feedback board. Explain what is different: they can now vote, see statuses, and get notified when their ideas ship. Link to the board from wherever the old suggestion box lived.

**Step 6: Retire the old tool.** Remove the form, close the inbox, archive the spreadsheet. Having two collection points splits submissions and creates confusion. One board, one source of truth.

## Frequently asked questions

### Is a suggestion box anonymous?

It depends on the tool. A physical suggestion box is anonymous by default — there is no name attached to a slip of paper. Digital suggestion boxes vary. Some require users to log in, which ties submissions to an identity. Others support anonymous feedback. The best approach is to make anonymity optional: let users choose whether to attach their name. This is especially important for an employee suggestion box, where honest feedback about management or processes may not surface if names are required. [Quackback](https://quackback.io) supports anonymous posting alongside identified submissions, so users can choose their comfort level.

### What is the best online suggestion box?

For most teams, a purpose-built feedback board is a better choice than a traditional suggestion box tool. [Quackback](https://quackback.io) is the strongest option if you want voting, status tracking, a public roadmap, and AI triage in an open-source package you can self-host. Canny and Featurebase are good hosted alternatives. If you just need a basic form to collect submissions without voting or tracking, Google Forms works — but you will outgrow it quickly once volume increases. For a broader comparison, see our guides to the [best customer feedback tools](/blog/best-customer-feedback-tools-2026) and [best feature request tools](/blog/best-feature-request-tools).

### How do I create a digital suggestion box?

Start by deciding who you are collecting feedback from (customers, employees, or both) and whether submissions should be public or private. For the simplest option, create a Google Form with a single open-text field and share the link. For something more useful, set up a feedback board with [Quackback](https://quackback.io) — you can deploy it in under five minutes. Add categories to organize submissions by topic, enable voting so users can support existing ideas, and configure status tracking so submitters see progress. Connect it to Slack for notifications and to Jira or Linear so accepted suggestions flow into your development workflow.

### How do I measure whether my suggestion box replacement is working?

Track three metrics. First, **submission volume over time** — a healthy feedback board should see steady or growing submissions, not the declining curve of an ignored suggestion box. Second, **time to first response** — how quickly does a new submission get a status update? Aim for under 5 business days. Third, **close rate** — what percentage of submissions eventually reach a terminal status (shipped, declined, or merged)? If your backlog grows indefinitely without resolution, you have a suggestion box wearing a feedback board's clothes. For more metrics, see our guide on [how to ask for customer feedback](/blog/how-to-ask-for-customer-feedback).

### What is the difference between a suggestion box and a feedback board?

A suggestion box collects input. A feedback board collects, organizes, prioritizes, and communicates. With a suggestion box, users submit ideas into a queue that only the receiving team can see. There is no voting, no status tracking, and no way for submitters to know what happened to their idea. A feedback board adds voting to surface demand, statuses to show progress, comments for conversation, and notifications to close the loop. The suggestion box is a mailbox. The feedback board is a conversation. For more on building a complete feedback process, see our [customer feedback loop guide](/blog/customer-feedback-loop).

- [Hotjar Pricing in 2026: Plans, Session Limits, and the Contentsquare Merger](https://quackback.io/blog/hotjar-pricing): Hotjar's pricing in 2026 after the Contentsquare merger. Session-based plans for heatmaps, recordings, and surveys across three product lines.

Published: 2026-03-24

Hotjar was one of the most widely used behavior analytics tools on the web. Heatmaps, session recordings, and on-site surveys — it was the default choice for product teams that wanted to understand how users interact with their site. In 2023, Contentsquare acquired Hotjar. By 2026, the merger is complete and the pricing model has changed fundamentally.

![Hotjar pricing breakdown after the Contentsquare merger](/blog/hotjar-pricing/hero.webp)

**TLDR:** Hotjar now redirects to Contentsquare. What was one product with one bill is now three separately priced product lines: Experience Analytics (heatmaps/recordings, from $49/month), Voice of Customer (surveys, from $99/month), and Product Analytics (custom pricing). Free tiers exist for each. The catch: each product has its own bill, session limits drive costs up as traffic grows, and the Growth plan's "$49/month" starting price scales steeply with session volume (up to $739/month at 200K sessions). If you used all of Hotjar's features, expect to pay two or three separate subscriptions to get equivalent coverage.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check [Contentsquare's pricing page](https://contentsquare.com/pricing/) for the latest figures.*

If you go to hotjar.com/pricing today, you get redirected to contentsquare.com/pricing. The Hotjar brand still exists within the Contentsquare platform, but the pricing structure has changed significantly. What was once a single tool with a simple pricing page is now three separate product lines, each with its own plans and session limits. All paid plans include unlimited user seats — Contentsquare does not charge per user, only per session volume or response count.

## What happened to Hotjar pricing

Contentsquare acquired Hotjar in 2023. Over the following two years, the companies merged their product lines. As of July 2025, the transition is complete. The hotjar.com domain redirects to contentsquare.com for pricing, sign-up, and documentation.

The core Hotjar features — heatmaps, session recordings, and surveys — still exist. But they are now organized into three distinct product lines under the Contentsquare umbrella:

- **Experience Analytics** (formerly Hotjar Observe) — heatmaps, session recordings, funnels, error monitoring
- **Voice of Customer** (formerly Hotjar Ask) — surveys, interviews, usability tests
- **Product Analytics** — event-based analytics, user journeys, engagement metrics (this was not part of the original Hotjar)

Each product line has its own pricing tiers and session limits. You can use one, two, or all three, but each is billed independently.

This matters for budgeting. If you previously paid one Hotjar bill for heatmaps and surveys, you now pay two separate bills to get the same coverage. Teams that also want product analytics are looking at three subscriptions. The "pick only what you need" framing sounds flexible, but in practice it means managing multiple billing lines for what used to be a single product.

## Experience Analytics pricing

Experience Analytics is the core Hotjar product — heatmaps, session recordings, funnels, and error monitoring. This is what most people think of when they think of Hotjar.

| Plan | Monthly Price | Sessions | Projects | Key Features |
|------|--------------|----------|----------|--------------|
| Free | $0 | 200K sessions | 1 | Session replays, heatmaps, funnels, error monitoring, basic surveys (100/month), LLM/MCP connectivity |
| Growth | $49-$739/mo | 7K-200K+ sessions | 1 | 13-month data access, zone-based heatmaps, journey analysis, impact quantification, Sense AI, 20K replay captures |
| Pro | Custom | 1M+ sessions | 3 | Precision filtering (retroactive), multi-session replay summaries (AI), revenue goal tracking |
| Enterprise | Custom | Custom | Unlimited | Experience monitoring, error summaries (AI), data feeds, dedicated support and SLAs |

The free plan is generous on session volume — 200,000 sessions per month — but limited to 1 project and basic features. It also includes basic surveys (100 responses/month) and the ability to connect with LLMs via MCP (Model Context Protocol).

The Growth plan is where the pricing gets nuanced. "Starting at $49/month" is for 7,000 sessions. The price scales with session volume up to $739/month at 200,000+ sessions. That is a 15x price range within a single tier. A site with 50,000 monthly sessions will pay significantly more than $49, and the exact pricing is not transparent until you sign up and configure your plan.

The Pro plan handles 1 million+ sessions with custom pricing and adds precision filtering (retroactive, meaning you can apply filters to data already collected), AI-powered multi-session replay summaries, and revenue goal tracking. You also get 3 projects instead of 1. The Sense Analyst add-on is available at extra cost on Pro.

Enterprise adds unlimited projects, experience monitoring, AI error summaries, data feeds, and dedicated support with SLAs.

All paid plans offer a 20% discount with yearly billing. One detail worth noting: the $49/month Growth rate applies to credit card or PayPal payments with annual commitment. Organizations using invoice-based purchasing (standard for corporate procurement) pay $588/year without a discount — a $117.60 annual difference for identical features.

![How Hotjar Experience Analytics pricing scales with session volume](/blog/hotjar-pricing/session-scaling.webp)

## Voice of Customer pricing

Voice of Customer covers surveys, interviews, and usability tests. This was part of the original Hotjar product but is now a separate billing line.

| Plan | Monthly Price | Survey Responses | Interviews/Tests | Key Features |
|------|--------------|-----------------|------------------|--------------|
| Free | $0 | 100/month | 5/month | 3 concurrent surveys, AI survey generator, AI summary reports |
| Growth | $99-$1,479/mo | 500-100K/month | 10/month | Advanced targeting, AI sentiment analysis, custom branding, 11 integrations |
| Pro | Custom | 500+/month | Up to 300/month | Panel recruitment (200K+ participants), API access, 120-min interviews, up to 4 moderators + 10 spectators |

The free plan gives you 100 survey responses per month, 5 interviews or usability tests, and 3 concurrent surveys. It includes an AI survey generator and AI summary reports — useful features that were not part of the original Hotjar.

Growth starts at $99/month for 500 responses. Like Experience Analytics, the price scales with usage — up to $1,479/month at 100,000 responses. You get 10 interviews per month, advanced targeting and filtering, AI-automated survey analysis, custom branding, and 11 integrations. The scaling here is steep: going from 500 to 100,000 responses means a 15x price increase within the same tier.

Pro is custom pricing for teams that need more than 500 responses, up to 300 interviews per month, panel recruitment from a pool of 200,000+ participants, and API access. Pro also supports longer interviews (120 minutes) and multiple moderators.

If you used Hotjar primarily for its survey widget, note that basic surveys (100 responses/month) are included in the Experience Analytics free plan. But if you need more than 100 responses, advanced targeting, or sentiment analysis, you need the Voice of Customer product — at a separate cost. This is where the unbundling hits hardest: a feature that used to be included in your Hotjar plan now requires its own subscription starting at $99/month.

## Product Analytics pricing

Product Analytics is a separate application that was not part of the original Hotjar. It covers event-based analytics, user journeys, and engagement metrics.

| Plan | Monthly Price | Sessions | Key Features |
|------|--------------|----------|--------------|
| Free | $0 | 10K sessions | 6-month data history |
| Growth | Custom pricing | Starting at 17K sessions | Sense AI, 12-month data |
| Pro | Custom pricing | 33K+ sessions | Account-level analytics, engagement matrix |
| Enterprise | Custom pricing | 1M+ sessions | Data warehouse sync |

The free plan gives you 10,000 sessions with 6 months of data history. Growth starts at 17,000 sessions with Sense AI and 12-month data retention. Pro adds account-level analytics and an engagement matrix. Enterprise handles 1 million+ sessions with data warehouse sync.

Product Analytics operates as a fully separate application from Experience Analytics. If you need both heatmaps and product analytics, you are paying for two products.

## Hotjar pricing at scale

The key cost driver across all three product lines is session volume and response limits. Here is what costs look like as you grow.

**Experience Analytics alone:**

| Session Volume | Plan | Estimated Monthly Cost |
|---------------|------|----------------------|
| Up to 200K | Free | $0 |
| 7K sessions | Growth | $49 |
| 50K sessions | Growth | ~$200-300 |
| 200K sessions | Growth | $739 |
| 1M+ sessions | Pro | Custom (contact sales) |
| Enterprise volume | Enterprise | Custom |

**Experience Analytics + Voice of Customer:**

For a team that needs both heatmaps/recordings and surveys, you are paying two bills. The minimum combined cost at Growth tier is $49 + $99 = $148/month. But these scale independently. A site with 100K sessions running 5,000 survey responses per month could easily spend $400-600/month across both products. That is a significant jump from the "$49/month" headline price.

**All three products at Growth tier:**

| Scenario | EA Cost | VoC Cost | PA Cost | Total |
|----------|---------|----------|---------|-------|
| Low usage (7K sessions, 500 responses) | $49/mo | $99/mo | Custom | $148+/mo |
| Medium usage (50K sessions, 2K responses) | ~$250/mo | ~$300/mo | Custom | $550+/mo |
| High usage (200K sessions, 10K responses) | $739/mo | ~$500/mo | Custom | $1,239+/mo |

*Product Analytics pricing is custom at all paid tiers. Add it and your total increases further.*

Add-ons like Sense Analyst, error summaries, and data monitoring are available at additional cost on top of these base prices. A mid-sized product team using all three products with add-ons could spend $1,500-$2,000/month — far more than the original Hotjar plans cost.

## Hidden costs to consider

The sticker price on Contentsquare's pricing page does not tell the full story. Here are the costs that catch teams off guard.

**Three products, three bills.** The original Hotjar bundled heatmaps, recordings, and surveys into one plan. Under Contentsquare, these are now separate product lines. If you used all of Hotjar's features, you need to subscribe to at least two products (Experience Analytics + Voice of Customer) to get equivalent coverage. Each has its own pricing tiers and billing cycles.

**Session limits create unpredictable costs.** Experience Analytics and Product Analytics both bill based on session volume. As your site traffic grows, your costs grow. There is no flat-rate option for high-traffic sites. A viral blog post, a ProductHunt launch, or a marketing campaign that spikes traffic will spike your analytics bill. When approaching session caps, Hotjar implements daily session sampling — distributing data captures evenly throughout 24-hour periods — which means you may miss data during high-traffic moments.

**Invoice billing costs more.** The advertised $49/month Growth rate applies to credit card or PayPal payments with annual commitment. Corporate procurement teams using invoice-based purchasing pay $588/year without any discount. That is a $117.60/year premium for the same features — a detail buried in the billing flow.

**Survey response caps are low.** The Voice of Customer free plan gives you 100 responses per month. Growth starts at 500 but scales to $1,479/month at 100K responses. If you run always-on [NPS](/tools/nps-calculator) or [CSAT surveys](/tools/csat-calculator) on a high-traffic site, you will hit the base cap quickly and face steep scaling costs.

**Performance impact on your site.** Hotjar's tracking script adds approximately 829ms to page load time and increases page weight by 0.47MB. While loaded asynchronously (so it does not block rendering), the script records cursor movement, scroll depth, and clicks 10 times per second, which increases CPU usage on resource-intensive pages. For sites where Core Web Vitals matter for SEO, this is worth measuring.

**Add-ons are extra.** Features like Sense Analyst, error summaries, and data monitoring are sold as add-ons on top of your plan. These are not included in the base Growth or Pro pricing.

**Data retention is tiered.** The free Experience Analytics plan has limited data history. Growth gives you 13 months. Product Analytics free tier retains only 6 months. There is no data retention beyond 365 days on any plan — you need to export data externally for longer historical analysis.

**The free plan is limited to 1 project.** If you manage multiple products or domains, you need Pro (3 projects) or Enterprise (unlimited projects) for Experience Analytics. Growth is also limited to 1 project — there is no multi-project option until Pro.

**Contentsquare now undercuts Hotjar internally.** Contentsquare launched its own Growth tier at $40/month in late 2025 — $9 less than Hotjar's $49/month Growth tier for comparable features. If you are signing up new, compare both pricing pages before committing.

## Hotjar alternatives

If the multi-product pricing model does not work for you, or if you want a simpler billing structure, here are alternatives to consider.

### PostHog

PostHog is open source and offers product analytics, session recordings, feature flags, and A/B testing in one platform. It has a generous free tier (1 million events, 5,000 recordings per month) and usage-based pricing beyond that. Everything is in one product with one bill — no separate pricing for analytics versus recordings. For teams frustrated by Hotjar's unbundling, PostHog's all-in-one model is the most direct alternative.

### Lucky Orange

Lucky Orange bundles heatmaps, session recordings, surveys, and live chat into a single product starting at $32/month — approximately 31% cheaper than Hotjar's invoice-paid Growth tier. It is less sophisticated than Contentsquare's offering but covers the core use cases that most product teams need without the multi-bill complexity.

### FullStory

FullStory focuses on digital experience analytics with session replay, heatmaps, and frustration signals. Pricing is custom and session-based. It is a single product rather than three separate billing lines, which simplifies cost planning. The trade-off is that pricing is not published — you need to talk to sales.

### Amplitude

Amplitude is a product analytics platform with a free plan (up to 50,000 monthly tracked users) and paid plans starting from custom pricing. It covers event analytics, user journeys, and experimentation. It does not include heatmaps or session recordings natively, but integrates with tools that do.

### Quackback for the feedback layer

If you used Hotjar primarily for its survey and feedback widgets, [Quackback](https://quackback.io) covers the [voice-of-customer](/use-cases/voice-of-customer) layer differently. It is [free, open source, and self-hosted](/open-source). [Feedback boards](/features/feedback), [voting](/features/voting), [public roadmaps](/features/roadmap), and [changelogs](/features/changelog) with no session limits or response caps. You collect structured [feedback](/use-cases/feedback-management) directly from users rather than intercepting it through on-site widgets. No per-response billing, no session-based pricing. If your goal is understanding what users want built next, Quackback gives you that signal without the complexity of a behavior analytics subscription.

## Frequently asked questions

### Is Hotjar still available as a standalone product?

Not as of July 2025. Hotjar now redirects to Contentsquare. The Hotjar brand exists within the Contentsquare platform, but pricing, sign-up, and billing all happen through contentsquare.com. The core features (heatmaps, recordings, surveys) are still available but organized into separate product lines with independent pricing.

### How much does Hotjar cost in 2026?

It depends on which products you need and your usage volume. Experience Analytics starts at $49/month for 7,000 sessions but scales to $739/month at 200,000+ sessions. Voice of Customer starts at $99/month for 500 responses and scales to $1,479/month at 100,000 responses. Product Analytics has custom pricing at all paid tiers. Free tiers exist for all three. If you need multiple product lines, each is billed separately. A 20% discount applies with yearly billing via credit card or PayPal.

### Does Hotjar have a free plan?

Yes. Each of the three product lines has a free tier. Experience Analytics free includes 200,000 sessions, 1 project, and basic features plus 100 basic survey responses. Voice of Customer free includes 100 survey responses and 5 interviews. Product Analytics free includes 10,000 sessions with 6-month data retention. The free tiers are useful for small sites and evaluations but have meaningful limits on projects, responses, and data history.

### Why is Hotjar pricing more complicated now?

The Contentsquare merger reorganized Hotjar's features into three separate product lines, each with its own pricing. The original Hotjar bundled heatmaps, recordings, and surveys into one plan. Under Contentsquare, these are distinct products. This gives you the flexibility to buy only what you need, but it also means managing multiple subscriptions if you want the full feature set.

### Does Hotjar slow down my website?

Hotjar's tracking script adds approximately 829ms to page load time and 0.47MB to page weight. The script loads asynchronously so it does not block rendering, but it records cursor movement, scroll depth, and clicks 10 times per second, which increases CPU usage. If Core Web Vitals are important to your site's SEO, test the impact before committing.

### How does Hotjar compare to Contentsquare pricing?

Contentsquare (Hotjar's parent company) launched its own Growth tier at $40/month in late 2025 — $9/month cheaper than Hotjar's Growth tier for comparable features. Both platforms are owned by the same company. If you are signing up new, compare both pricing pages. The Contentsquare-branded product may offer better value.

### Can I cancel Hotjar at any time?

Hotjar offers a 30-day money-back guarantee for new customers if cancelled before the first renewal. After the initial renewal, no partial refunds apply. Annual plans lock you in for the full year.

- [Keep a Changelog: The Definitive Guide for Product Teams](https://quackback.io/blog/keep-a-changelog): How to write and maintain a changelog your users will actually read. Covers the Keep a Changelog standard, changelog formats, best practices, and tools.

Published: 2026-03-24

Most changelogs are bad. They are commit log dumps pasted into a markdown file. They use inconsistent date formats, skip versions, and bury useful information under noise. Users stop reading them. Teams stop writing them.

The Keep a Changelog standard exists to fix this. It is a set of principles and a format for writing changelogs that are useful, consistent, and readable. If you maintain a product changelog for your SaaS product — or you want to start one — this guide covers the standard, the format, and how to apply it to your team's workflow. You will get the seven Keep a Changelog principles, a complete format reference with copy-paste examples, best practices from real SaaS companies, and a checklist for auditing your own changelog.

![A well-structured changelog with organized sections for Added, Changed, and Fixed entries](/blog/keep-a-changelog/hero.webp)

> **Keep a Changelog** is an open standard, documented at keepachangelog.com, that defines a consistent format and seven principles for writing changelogs that are useful, readable, and built for humans rather than machines. It groups changes into six standard types (Added, Changed, Deprecated, Removed, Fixed, Security), lists the newest version first, and uses ISO 8601 dates. Follow it to keep your product changelog scannable and trustworthy.

## What is a changelog

A changelog is a file or page that contains a chronological list of notable changes for each version of a project. It answers one question: what changed between this version and the last one.

A good product changelog serves three audiences simultaneously:

- **Users** learn what is new, what is fixed, and what they need to do differently.
- **Your team** tracks what shipped and when, creating an institutional record of product decisions.
- **Support teams** answer questions about recent changes without reading code diffs or pinging engineering.

A changelog is not a commit log. Commit logs are written for developers working on the codebase. Changelogs are written for people who use the product. The audience is different. The language should be different. The level of detail should be different.

Here is a quick test. Compare these two entries describing the same change:

| Commit log entry | Changelog entry |
|---|---|
| `fix: null ref in ReportFilterService#apply` | Fixed a bug where reports failed to load when filtered by date range |
| `refactor: migrate to new auth provider` | Single sign-on now supports SAML 2.0 in addition to OAuth |
| `feat: add CSV export endpoint` | You can now export your roadmap items as a CSV file from the dashboard |

If your changelog reads like the left column, it is not a changelog. It is a developer artifact that happens to be public.

## The Keep a Changelog standard

The Keep a Changelog standard, documented at keepachangelog.com, defines seven principles for writing good changelogs. These Keep a Changelog principles form the foundation for any product changelog worth reading.

### 1. Changelogs are for humans, not machines

Write for the people who use your product. Use plain language. Describe what changed from the user's perspective, not the developer's. "Fixed a bug where reports failed to load when filtered by date range" is useful. "Fix null ref in ReportFilterService#apply" is not.

### 2. Every version should have an entry

Do not skip versions. If a release shipped, it should have a changelog entry — even if the changes were minor. Gaps in the changelog erode trust. Users wonder what changed in the versions you skipped.

### 3. Group identical change types together

Do not mix bug fixes, new features, and deprecations in one undifferentiated list. Group them by type so users can scan for what matters to them. The Keep a Changelog format defines six standard types (covered in the next section).

### 4. Versions and sections should be linkable

Every version heading and every change type section should have an anchor link. Users should be able to link directly to a specific version or a specific section within a version. This matters for support tickets, internal discussions, and documentation references.

### 5. Most recent version comes first

Reverse chronological order. The newest changes appear at the top. Users care about what changed recently, not what changed two years ago. Do not make them scroll.

### 6. Show the release date for each version

Every version entry should include the date it was released. Use ISO 8601 format: YYYY-MM-DD. Not "March 24th" or "24/03/2026" or "03-24-2026." ISO 8601 is unambiguous across locales and cultures.

### 7. Follow Semantic Versioning

The Keep a Changelog standard recommends Semantic Versioning (semver.org). Version numbers communicate the nature of changes: major versions for breaking changes, minor versions for new features, and patch versions for bug fixes. When your versioning is meaningful, users can assess the significance of a release before reading the details.

These seven principles are simple. Most teams violate at least two of them. The value of the standard is not that it introduces novel ideas — it is that it codifies good practice in a way that is easy to follow consistently.

### Quick audit: Score your current changelog

Rate your changelog against each principle (yes/no). If you score below five out of seven, your changelog has structural problems that this guide will help you fix.

| Principle | Yes / No |
|---|---|
| Written for users, not developers | |
| Every version has an entry | |
| Changes grouped by type | |
| Versions and sections are linkable | |
| Reverse chronological order | |
| Release dates in ISO 8601 | |
| Follows Semantic Versioning | |

## Changelog format

The Keep a Changelog format uses six standard change types to categorize every entry. This changelog format gives users a predictable structure they can scan quickly.

![The six Keep a Changelog change types: Added, Changed, Deprecated, Removed, Fixed, and Security](/blog/keep-a-changelog/format-overview.webp)

### Added

New features and capabilities. Things that did not exist before this release.

```markdown
### Added
- Team-level permissions for feedback boards
- CSV export for roadmap items
- Webhook support for changelog publish events
```

### Changed

Changes to existing functionality. Behavior that worked one way before and works differently now.

```markdown
### Changed
- Dashboard charts now default to 30-day view instead of 7-day
- Email notifications consolidated into a daily digest
```

### Deprecated

Features that still work but are scheduled for removal. This is the early warning. Tell users what is going away, when, and what to use instead.

```markdown
### Deprecated
- Legacy API v1 endpoints. Will be removed in v4.0. Migrate to v2 endpoints.
- CSV import via the settings page. Use the new bulk import API instead.
```

### Removed

Features that were deprecated previously and are now gone.

```markdown
### Removed
- Legacy API v1 endpoints (deprecated in v3.0)
- Support for Internet Explorer 11
```

### Fixed

Bug fixes. Describe what was broken and what the correct behavior is now.

```markdown
### Fixed
- Roadmap items no longer disappear when changing the sort order
- Email notifications now respect the user's timezone setting
```

### Security

Changes that address security vulnerabilities. Call these out separately so security-conscious users and teams can find them immediately.

```markdown
### Security
- Patched XSS vulnerability in the feedback comment field
- Upgraded dependency to address CVE-2026-1234
```

A complete changelog entry in Keep a Changelog format looks like this:

```markdown
## [2.1.0] - 2026-03-24

### Added
- Team-level permissions for feedback boards
- Webhook support for changelog publish events

### Changed
- Dashboard charts now default to 30-day view

### Fixed
- Roadmap items no longer disappear when changing sort order
- Email notifications now respect timezone settings

### Security
- Patched XSS vulnerability in feedback comment field
```

The standard also recommends keeping an `[Unreleased]` section at the top of your CHANGELOG.md file. This is where changes accumulate between releases. When you cut a new version, move the unreleased items into a versioned entry with a date. This approach keeps the changelog up to date incrementally rather than requiring a rush of documentation at release time.

## Changelog best practices for product teams

The Keep a Changelog standard covers the format. These practices cover the workflow — how product teams can maintain a changelog that stays useful over time.

**Write entries as you ship, not after.** If you wait until the end of the sprint or release cycle to write changelog entries, you will forget things. You will rush. The quality will suffer. Add entries to the Unreleased section when changes merge, not when the release goes out. A practical approach: make "update the changelog" a checkbox in your pull request template or definition of done. The person who ships the change writes the entry because they understand the context.

**Write for your audience, not your team.** Internal shorthand, ticket numbers, and component names mean nothing to users. "Fixed QB-4521" tells your team what happened. "Fixed a bug where the search bar returned no results for queries with special characters" tells your users what happened. Write the second one.

A useful rewriting exercise: read each entry and ask "would a customer who has never seen our codebase understand this?" If not, rewrite it.

**Be specific about what changed and why it matters.** "Performance improvements" is not a changelog entry. "Reduced page load time for dashboards with more than 1,000 items from 8 seconds to under 2 seconds" is a changelog entry. Specificity builds credibility. Here are more before/after examples:

| Vague entry | Specific entry |
|---|---|
| Bug fixes | Fixed a bug where CSV exports included deleted items |
| UI improvements | Redesigned the settings page with grouped sections and search |
| Performance improvements | API response times for list endpoints reduced from 1.2s to 200ms |
| New integrations | Added Slack integration: get notified in your channel when feedback status changes |

**Do not dump your commit log.** This is the most common anti-pattern. A changelog that lists every commit — including "fix typo," "update dependencies," and "WIP" — is noise. Curate the list. Include only changes that affect users. A useful filter: if the change is invisible to someone using your product, it does not belong in the changelog. Internal refactors, dependency updates, and CI pipeline changes are important work, but they are not changelog material.

**Do not ignore deprecations.** Removing a feature without warning is one of the fastest ways to lose user trust. The Deprecated category exists for a reason. Give users advance notice. Tell them the timeline. Tell them the alternative. A good deprecation entry follows this formula: "[Feature] is deprecated. It will be removed in [version/date]. Use [alternative] instead. [Link to migration guide]."

**Use consistent date formats.** ISO 8601 (YYYY-MM-DD). Always. Mixed date formats in a changelog look unprofessional and create confusion for international users.

**Link to related documentation.** When a changelog entry describes a new feature, link to the docs page that explains it. When a breaking change requires migration, link to the migration guide. The changelog is a summary. Let users go deeper when they need to. For tips on writing these entries as standalone announcements, see our guide on [product update announcements](/blog/product-update-announcement).

**Keep one canonical source.** Do not maintain a changelog in three places — your marketing site, your GitHub repo, and your docs. Pick one source of truth and link to it from everywhere else.

**Connect releases to user feedback.** The best changelogs do not just announce what shipped — they explain what motivated the change. "Added CSV export for roadmap items (your #3 most requested feature)" tells users their input matters. This feedback-to-release connection turns a changelog from a product record into a relationship-building tool. For more on this approach, see our guide to the [customer feedback loop](/blog/customer-feedback-loop).

## Changelog examples from SaaS companies

Several SaaS companies maintain changelogs that are worth studying. Their approaches differ, but they all take the format seriously. The table below summarizes the key differences, followed by a deeper look at each. *Publishing cadences observed as of May 2026 and may shift over time.*

| Company | Audience | Format | Frequency | Key strength |
|---|---|---|---|---|
| Linear | Product teams, designers | Narrative blog-style | Weekly | Writing quality and design polish |
| Stripe | Developers | Structured by product area | Per-release | Precision and migration details |
| Notion | General users | Concise summaries | Biweekly | Scannability and brevity |
| Vercel | Developers | Deep-dive marketing | Per-release | Video walkthroughs and technical depth |

**Linear** publishes a changelog that reads more like a product blog. Each entry has a headline, a brief narrative explaining the feature and the design thinking behind it, and a polished screenshot. The writing is confident and direct. The result is a changelog that users subscribe to and read voluntarily — not because they need to, but because it is genuinely well-written. The takeaway: invest in writing quality. A changelog people want to read is a marketing asset.

**Stripe** organizes [release notes](/blog/release-notes-template) by product area — Payments, Billing, Connect, Radar — and writes primarily for developers. Entries include exact endpoint names, parameter changes, and migration steps. Breaking changes appear at the top. The format prioritizes precision over narrative because Stripe's users are engineers integrating APIs who need exact details. The takeaway: match the level of technical detail to your audience. Developer-facing products need exact specs, not marketing copy.

**Notion** keeps its changelog concise. Entries are typically two or three sentences with a link to documentation for anyone who wants more detail. The format respects users' time. You can scan the entire changelog in a few minutes and understand what shipped. The takeaway: brevity works. Not every entry needs a paragraph. Link to docs for depth.

**Vercel** treats its changelog as both a communication tool and a marketing channel. Major features get video walkthroughs and technical deep dives. The entries are longer than most changelogs, but the depth gives developers confidence and makes complex features accessible. The takeaway: for significant features, a changelog entry can double as a launch post.

What these companies share is consistency. They publish regularly. They use a predictable format. They write for their specific audience. The format details differ, but the discipline is the same.

## Changelog tools

You can maintain a changelog in a CHANGELOG.md file. For open-source libraries and developer tools, that is often enough. For SaaS products with non-technical users, you need more: a public changelog page, email notifications, in-app widgets, and a way to connect updates to user feedback.

The right tool depends on your context:

**CHANGELOG.md in your repo.** Best for open-source projects and developer tools where users already live in GitHub. Zero cost, version-controlled, and diffs are visible in pull requests. Combine with tools like `standard-version` or `semantic-release` to automate version bumping from [Conventional Commits](https://www.conventionalcommits.org/). Limitation: no email notifications, no in-app widget, no way for non-technical users to discover or subscribe to updates.

**GitHub Releases.** A step up from a markdown file. Each release gets a page with a description, downloadable assets, and contributor attribution. GitHub can auto-generate release notes from merged pull requests. Good for open-source projects. Still developer-centric — not suitable for communicating with end users who do not use GitHub.

**Purpose-built changelog tools.** For SaaS products where your audience includes non-technical users, a dedicated changelog tool adds the distribution layer: public changelog pages, email notifications, in-app widgets, RSS feeds, and integrations.

[Quackback's changelog](/features/changelog) is built for product teams that want to close the loop between feedback and releases. When you publish a changelog entry, Quackback automatically notifies every user who voted or commented on the related feedback posts. You do not need to manually track who asked for what. The connection between feedback and releases is structural, not manual.

Quackback also generates draft changelog entries using AI, based on the feedback posts linked to a release. Your team reviews and edits the draft rather than writing from scratch. The result is a changelog that stays connected to the user requests that drove each change — which is what the Keep a Changelog principle of "changelogs are for humans" looks like in practice.

Quackback is open source (AGPL-3.0) and self-hostable for free, with a managed [Quackback Cloud](/pricing) option when you would rather not run it yourself. You can add your whole team to the changelog workflow. An [MCP server](/features/mcp) also lets AI assistants read your feedback and roadmap directly, so you can draft and link changelog entries without leaving your editor.

For a full comparison of changelog tools, see the [best changelog tools](/blog/best-changelog-tools) guide.

## Common changelog mistakes and how to fix them

Even teams that follow the Keep a Changelog standard make mistakes. Here are the patterns that undermine otherwise good changelogs.

**The "what's new" page that never updates.** You launch a changelog page, publish three entries with enthusiasm, then stop. The last entry is from six months ago. This is worse than having no changelog because it signals abandonment. Fix: assign changelog ownership to a specific person. Add "write changelog entry" to your release checklist. If you use [Quackback](/features/changelog), AI-generated drafts reduce the friction that causes this pattern.

**The commit log dump.** Your changelog lists every commit message verbatim. Users see entries like "bump version," "fix lint," and "WIP: refactor auth." This tells them nothing useful. Fix: curate entries during the release process. A 50-commit release might produce 5-8 changelog entries. Everything else is internal housekeeping.

**The marketing changelog.** Every entry reads like ad copy. "We are thrilled to announce our groundbreaking new dashboard." Users want to know what changed, not how excited you are about it. Fix: state the change, state the benefit, move on. Let the product speak for itself.

**Inconsistent granularity.** One version has 30 line items detailing every minor tweak. The next version has a single entry: "Various improvements." Users cannot predict what they will learn from any given entry. Fix: aim for 3-10 entries per release. Roll minor changes into summary items. Break major changes into separate entries.

**No deprecation warnings.** Features disappear without notice. Users discover the removal when their workflow breaks. Fix: always use the Deprecated category before using the Removed category. Give users at least one full version cycle of warning, ideally two or three.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is the difference between a changelog and release notes?

A changelog is the cumulative record of all changes across every version, typically one file or page. Release notes document a single version or release. A changelog is made up of individual release notes entries. The terms are often used interchangeably, and the same principles apply to both.

### Should every project have a changelog?

Any project with users should have a changelog. For open-source libraries, a CHANGELOG.md file in the repository is the convention. For SaaS products, a public changelog page serves the same purpose. Internal tools benefit from changelogs too — they reduce "what changed?" questions from colleagues and create a record of decisions. The overhead of maintaining a changelog is low if you write entries as you ship rather than retroactively.

### How do you start a changelog for an existing project?

Start from the current version. Do not try to reconstruct the complete history of every change. Create a CHANGELOG.md or changelog page, document the current version, and maintain it going forward. If there are significant recent changes worth capturing, go back a few versions. But the goal is to build the habit of maintaining the changelog from now on, not to create a perfect historical record.

### What is the difference between a changelog and a product roadmap?

A changelog looks backward — it documents what you already shipped. A [product roadmap](/blog/what-is-a-product-roadmap) looks forward — it communicates what you plan to build next. They serve different purposes but work best together. When your roadmap shows an item as "shipped" and your changelog documents the details, users get a complete picture: what was promised, what was delivered, and how it works. For more on roadmaps, see our [product roadmap examples](/blog/product-roadmap-examples) guide.

### What is the difference between Keep a Changelog and Conventional Commits?

Keep a Changelog is a standard for the changelog that users read. Conventional Commits is a standard for the commit messages developers read. They complement each other: tools like standard-version or semantic-release can draft a changelog from Conventional Commits, but you still rewrite each entry in plain language for users.

- [Linear Pricing in 2026: Plans, Per-User Costs, and Feature Limits](https://quackback.io/blog/linear-pricing): Linear's pricing plans in 2026. Free tier limits, per-user costs on paid plans, and what you get at each tier for project tracking and issue management.

Published: 2026-03-24

Linear is a modern issue tracker built for product teams. It launched in 2019 and gained traction quickly among startups and growth-stage companies that wanted something faster and more opinionated than Jira. The interface is keyboard-driven, the defaults are sensible, and the workflows are built around cycles, projects, and triage rather than customizable-everything. More than 25,000 companies now use Linear.

![Linear pricing plans overview for 2026](/blog/linear-pricing/hero.webp)

> Linear's free plan gives you unlimited members but caps you at 250 non-archived issues and 2 teams, which most active teams hit within weeks. Paid plans are per-user, per-month: Basic is $10/user/month and Business is $16/user/month, both billed annually, with Enterprise on custom pricing. AI agents are included on every plan at no extra cost, and costs scale linearly with headcount. The main gotchas: SAML/SCIM SSO requires Enterprise, and Zendesk/Intercom integrations require Business.
>
> *Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check [Linear's pricing page](https://linear.app/pricing) for the latest figures.*

Linear's pricing model is straightforward: per-user, per-month, with annual billing as the default. There are no tracked-user tiers, no session limits, and no usage-based surprises. The main constraint on the free plan is the 250 non-archived issue cap, which most teams hit within weeks of active use.

## Linear's pricing plans

Linear offers four tiers in 2026. The pricing page shows annual billing rates. Monthly billing is available but at a premium (rates not published — expect 15-20% more).

| Plan | Price (billed annually) | Members | Teams | Issues | Key Features |
|------|------------------------|---------|-------|--------|--------------|
| Free | $0 | Unlimited | 2 | 250 (non-archived) | Slack and GitHub access, AI agents, 10MB file uploads |
| Basic | $10/user/mo | Unlimited | 5 | Unlimited | Unlimited file uploads, admin roles, full API access |
| Business | $16/user/mo | Unlimited | Unlimited | Unlimited | Private teams, guests, Triage Intelligence, Linear Insights, Linear Asks, Zendesk and Intercom integrations |
| Enterprise | Custom (annual only) | Unlimited | Unlimited | Unlimited | SAML/SCIM, granular admin controls, advanced org modeling, migration support, priority support |

### Free

The free plan lets you add unlimited members, which is generous. The catch is in the constraints: 2 teams, 250 non-archived issues, and a 10MB file upload limit. You get Slack and GitHub integrations and access to Linear's AI agents. For a two-person side project, this works. For a product team shipping weekly, 250 issues runs out fast. The enforcement is strict — when you hit 250 non-archived issues, new issue creation is blocked with no grace period.

### Basic — $10/user/month (billed annually)

Basic removes the issue cap and increases the team limit to 5. You get unlimited file uploads, admin roles for managing permissions, and full API access. This is the plan most small-to-mid-size teams land on. At $10/user/month billed annually ($120/user/year), it is competitively priced against other project tracking tools. Monthly billing is available at a higher rate if you want flexibility without a full-year commitment, though the exact monthly price is not published on the pricing page.

### Business — $16/user/month (billed annually)

Business unlocks unlimited teams, private teams, and guest access. You also get Triage Intelligence (AI-assisted issue routing), Linear Insights (analytics on team velocity and cycle performance), and Linear Asks (a question-and-answer layer on top of your issue data). Zendesk and Intercom integrations are only available at this tier, which matters for teams that want customer support context flowing into their issue tracker.

The $6/user/month premium over Basic is driven by three things: unlimited teams, support integrations, and AI-powered analytics. If you do not need Zendesk/Intercom integration or Triage Intelligence, Basic may be sufficient.

![Linear plan comparison — Free vs Basic vs Business vs Enterprise](/blog/linear-pricing/plan-comparison.webp)

### Enterprise — custom pricing

Enterprise adds SAML and SCIM for identity management, granular admin controls, enterprise-grade security, and advanced organizational modeling for complex team structures. Pricing requires a sales conversation. Annual billing only. Invoice/PO billing is available. Migration and onboarding support is included. Industry estimates put Enterprise pricing at $250-$350/user/year for teams around 100 users, with volume discounts reducing the effective rate to $230-$300/user/year at 500+ users. Implementation fees are typically waived for contracts over $50,000.

## Linear pricing at scale

Linear's per-user pricing scales linearly. No volume discounts are published for Basic or Business plans. Enterprise may include negotiated rates.

| Team Size | Basic (Annual Billing) | Business (Annual Billing) | Monthly Cost Difference |
|-----------|----------------------|--------------------------|------------------------|
| 10 users | $1,200/yr ($100/mo) | $1,920/yr ($160/mo) | +$60/mo for Business |
| 25 users | $3,000/yr ($250/mo) | $4,800/yr ($400/mo) | +$150/mo for Business |
| 50 users | $6,000/yr ($500/mo) | $9,600/yr ($800/mo) | +$300/mo for Business |
| 100 users | $12,000/yr ($1,000/mo) | $19,200/yr ($1,600/mo) | +$600/mo for Business |
| 200 users | $24,000/yr ($2,000/mo) | $38,400/yr ($3,200/mo) | +$1,200/mo for Business |
| 500 users | $60,000/yr ($5,000/mo) | $96,000/yr ($8,000/mo) | +$3,000/mo for Business |

*Prices reflect annual billing rates ($10/user/mo Basic, $16/user/mo Business).*

At 50 users on the Business plan, you are paying $9,600 per year. At 100 users, $19,200 per year. At 500 users on Business, costs reach $96,000 annually — at which point Enterprise negotiations become worthwhile for potential volume discounts.

These numbers are predictable. There are no usage-based overages, no tracked-user thresholds, no session limits. But per-user pricing means every new hire or contractor with a Linear seat adds to your bill. There is no read-only or viewer tier that would let stakeholders follow progress without a full paid seat.

For comparison, Jira Standard at 100 users costs approximately $9,036/year ($7.53/user/month). Linear Business at 100 users costs $19,200/year — roughly 112% more. However, Jira offers free stakeholder licenses for unlimited read-only access, which creates a cost advantage for organizations with many external collaborators or observers. The choice between the two usually comes down to workflow preferences and team culture rather than pricing alone.

Enterprise pricing is custom. For teams above 100 users, expect to negotiate directly with Linear's sales team. Volume discounts are not publicly documented but are available.

## Free plan limitations

The free plan is more restrictive than it appears at first glance.

**250 non-archived issues.** This is the hard limit. Non-archived means any issue that is open, in progress, backlogged, or triaged. Once you hit 250, you need to archive issues to create new ones. A product team running two-week cycles with 20-30 issues per cycle will burn through this in a couple of months, faster if you use Linear for bug tracking alongside feature work.

**2 teams only.** If you have separate engineering, design, and product teams — or if you organize by squad — you are already over the limit. Consolidating everything into 2 teams to stay on the free plan forces unnatural workflow compromises.

**10MB file upload cap.** Screenshots are fine. Screen recordings, design files, or large attachments will not fit. This pushes teams to host files elsewhere and link to them, which adds friction.

**No admin roles.** The free plan does not include admin roles, which means you cannot manage permissions granularly. Every member has the same level of access.

For solo developers or very small teams evaluating Linear, the free plan is a reasonable trial. For any team doing real product development, you will need to upgrade within the first month or two.

## Hidden costs to consider

Linear's pricing is simpler than many competitors, but there are still costs that are not obvious from the pricing page.

**Per-user billing includes every seat.** Linear charges for every user with an active account. If you add a contractor for a two-week sprint, they count as a full user for that billing period. There is no read-only or viewer tier on the paid plans. Everyone who needs access pays the same rate. For organizations where many stakeholders need visibility into engineering work, this can add up — Jira's free stakeholder licenses create a meaningful cost advantage in this scenario.

**Enterprise pricing is opaque.** If you need SAML/SCIM — a common requirement for companies above 50 employees — you must move to Enterprise with custom pricing. There is no published price. Industry estimates suggest $250-$350/user/year for teams around 100 users, but the jump from Business pricing is not predictable without a sales conversation.

**Annual billing is the default.** Linear encourages annual commitments. Monthly billing is available on Basic and Business plans at a premium, but the monthly rates are not published on the pricing page. You need to sign up to see the monthly option. If you want to trial Linear with a paid plan before committing annually, be aware that you will pay more per month.

**No self-hosting option.** Linear is a cloud-only product. There is no on-premises or self-hosted deployment. For teams with strict data residency requirements or a preference for self-managed infrastructure, this is a hard constraint.

**Zendesk and Intercom integrations require Business.** If your team needs customer support context in your issue tracker, you need the Business plan at minimum. This is a $6/user/month premium over Basic just for the integration access. For teams that rely on support ticket context to prioritize engineering work, this forces the higher tier.

**No implementation fees, but no migration tools either.** Linear does not charge implementation fees for self-service plans, and Enterprise onboarding support is typically included for larger contracts. However, migrating from Jira or another tool requires manual effort or third-party migration tools. There is no automated Jira-to-Linear migration wizard — plan for the time cost of switching.

**AI features are included, but the platform is the product.** Linear's AI agents are included on all plans at no extra cost. That is a strength — unlike [ClickUp](/blog/clickup-pricing), which charges $9-$28/user/month for AI on top of workspace pricing. But Linear is an issue tracker, not a [feedback collection tool](/use-cases/feedback-management). If you need to collect [feature requests](/use-cases/feature-requests) from end users, run a public roadmap, or manage a changelog, you will need a separate tool on top of Linear.

## Linear alternatives

If Linear's per-user pricing does not fit your budget, or if you need capabilities that Linear does not cover, here are the main alternatives.

### Jira

The incumbent. Jira's free plan supports up to 10 users with most features included. Standard is $7.53/user/month (billed annually) and Premium is $13.53/user/month. Jira is far more customizable than Linear but also more complex. A key advantage: Jira offers free stakeholder licenses for unlimited read-only access, which significantly reduces costs for organizations with many non-engineering observers. Teams that want speed and simplicity tend to prefer Linear. Teams that need deep workflow customization or enterprise compliance features tend to land on Jira. Read our [Jira pricing breakdown](/blog/jira-product-discovery-pricing) for the full comparison.

### Asana

Asana is a project management tool that overlaps with Linear's use case for non-engineering teams. The free plan supports up to 15 users. Paid plans start at $10.99/user/month. Asana is broader in scope — it covers marketing, operations, and cross-functional work — but less opinionated about software development workflows. AI features are included on paid plans at no extra cost.

### Shortcut

Shortcut (formerly Clubhouse) targets the same audience as Linear: fast-moving product teams. The free plan supports up to 10 users. Paid plans start at $8.50/user/month. The feature set is similar to Linear with a slightly different interface philosophy. Worth evaluating if you want a Linear-like experience at a lower per-user cost.

### ClickUp

ClickUp offers a free plan with unlimited tasks. Paid plans start at $7/user/month. It covers a broader surface area than Linear — docs, whiteboards, goals, time tracking — but the experience is less focused. The AI add-on is a separate cost ($9-$28/user/month), unlike Linear where AI is included. Teams that want an all-in-one workspace may prefer ClickUp. Teams that want an opinionated issue tracker tend to prefer Linear. See our [ClickUp pricing breakdown](/blog/clickup-pricing) for the full cost picture.

### Plane

Plane is an open-source project management tool that targets the same audience as Linear. It offers a free self-hosted option and a cloud plan. If you want a Linear-like experience with the ability to self-host, Plane is worth evaluating.

### Quackback for the feedback layer

Linear is an issue tracker. It is not designed to collect feedback from your end users, run a [public voting board](/features/voting), or publish a customer-facing [roadmap](/features/roadmap). If you need that feedback collection layer, [Quackback](https://quackback.io) is [open source](/open-source) (AGPL-3.0), with a free self-hosted option and a managed [Quackback Cloud](/pricing) if you would rather not run it yourself. It handles [feedback boards](/features/feedback), voting, roadmaps, and [changelogs](/features/changelog). Quackback has a native [Linear integration](/integrations/linear) so [feature requests](/use-cases/feature-requests) flow directly into your Linear workspace as issues. There is also an [MCP server](/features/mcp), so you can triage and query feedback from AI tools, with AI analysis built in. You get the feedback collection that Linear does not provide, connected to the issue tracking that Linear does well.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Does Linear have a free plan?

Yes. Linear's free plan includes unlimited members, 2 teams, 250 non-archived issues, 10MB file uploads, Slack and GitHub integrations, and AI agents. The 250 issue cap is the main constraint, and most active product teams exceed it within weeks. The first paid tier (Basic) starts at $10/user/month billed annually.

### How much does Linear cost per user?

Basic is $10/user/month and Business is $16/user/month, both billed annually. Monthly billing is available at roughly a 15-20% premium, but the exact monthly prices are not published. Enterprise is custom pricing. There are no published volume discounts for Basic or Business plans.

### What happens when I hit 250 issues on the free plan?

New issue creation is blocked immediately with no grace period. You cannot create new issues until you archive existing ones to bring your non-archived count below 250. There is no overage billing. You must manage your backlog or upgrade to a paid plan.

### Does Linear include SSO?

SAML and SCIM are only available on Linear's Enterprise plan, which requires custom pricing and a sales conversation. Basic and Business plans do not include SSO. This is a common pain point for growing companies that hit compliance requirements around the 50-employee mark.

### How does Linear compare to Jira on pricing?

With annual billing, Jira Standard starts at $7.53/user/month and Linear Basic is $10/user/month. At the higher tier, Linear Business is $16/user/month versus Jira Premium at $13.53/user/month. Jira also offers free read-only stakeholder licenses, while Linear charges every user the same rate, which favors teams with many observers.

- [Product Requirements Document Template (Free PRD Template)](https://quackback.io/blog/product-requirements-document-template): A free PRD template with sections, examples, and best practices. Learn what to include in a product requirements document and when to write one.

Published: 2026-03-24

A product requirements document defines what you are building, who it is for, and how you will know it worked. It is the single artifact that aligns engineering, design, and leadership around the same set of expectations before work begins.

Most teams skip PRDs or write bad ones. They jump straight to building because writing feels slow. Then they discover misalignment two weeks into a sprint — engineering built the wrong thing, design solved the wrong problem, and the PM assumed everyone understood the context that was only in their head.

A good PRD takes a few hours to write. It saves weeks of rework. This guide covers what a product requirements document is, when to write one, what to include, and provides a free PRD template you can copy and adapt. You will also find a filled-out example PRD, a decision framework for when to write one, and best practices drawn from how product teams actually work.

![A product requirements document with organized sections for goals, requirements, and metrics](/blog/product-requirements-document-template/hero.webp)

> A product requirements document (PRD) is a written specification that defines what you are building, who it is for, and how you will know it worked. A good PRD covers the problem, the proposed solution, the requirements, and the success criteria in two to four pages. It takes a few hours to write and saves weeks of rework by aligning engineering, design, and leadership before work begins. Copy the free template below and adapt it to your team.

## What is a product requirements document

A product requirements document is a written specification that describes a product feature or initiative from the user's perspective. It defines the problem, the proposed solution, the requirements, and the success criteria.

A PRD is not a technical specification. It does not prescribe how to build something. It defines what to build and why. The engineering team uses the PRD to understand the problem and constraints, then decides the implementation approach.

A PRD is also not a project plan. It does not cover timelines, resource allocation, or sprint planning in detail. It may include a rough timeline or milestones, but the focus is on requirements — what the product needs to do — not logistics.

The best PRDs are concise. They give the team enough context to make good decisions without prescribing every interaction or edge case. They leave room for engineering and design to contribute their expertise while ensuring everyone agrees on the outcome.

## When to write a PRD (and when not to)

Write a PRD when the work involves meaningful ambiguity. If the feature touches multiple teams, affects existing user workflows, introduces new concepts, or requires more than a few days of engineering time, a PRD is worth the investment.

**Write a PRD when:**
- You are building a new feature that affects user-facing behavior
- The work spans multiple engineering teams or disciplines
- Stakeholders need to align on scope before work begins
- The feature involves trade-offs that should be documented
- You need to communicate the reasoning behind a product decision

**Skip the PRD when:**
- The work is a straightforward bug fix with an obvious solution
- The change is cosmetic or trivial — copy changes, color tweaks
- The team is small enough that a 10-minute conversation achieves alignment
- You are running a quick experiment or prototype that will be thrown away

The mistake most teams make is binary thinking: either every feature gets a PRD or none do. The right approach is proportional. Match the rigor to the risk.

| Initiative size | Documentation level | Typical length | Example |
|---|---|---|---|
| Major (multi-team, 4+ weeks) | Full PRD with all sections | 3-5 pages | New permissions system, billing overhaul |
| Medium (one team, 1-3 weeks) | Lightweight PRD | 1-2 pages | New CSV export feature, onboarding redesign |
| Small (one person, a few days) | Ticket with context | A few paragraphs | Copy change, bug fix, small UI tweak |
| Experiment / prototype | Hypothesis doc | Half a page | A/B test, throwaway prototype |

The threshold question is: "If this goes wrong, how much time do we lose?" A two-day task with a clear spec does not need a PRD. A three-week initiative involving design, backend, and frontend does.

## What to include in a PRD

A product requirements document template should cover seven core sections. Not every PRD needs every section in full detail, but these are the building blocks.

### Overview

A short summary of what you are building and why. Two to three sentences. Anyone reading the PRD should understand the initiative after reading just this section. Think of it as the executive summary.

### Goals and non-goals

Goals define what success looks like. Non-goals define what is explicitly out of scope. Non-goals are as important as goals — they prevent scope creep and make trade-offs visible.

A goal might be: "Reduce time-to-first-value for new users from 3 days to 1 day." A non-goal for the same initiative: "We are not redesigning the entire onboarding flow. This effort focuses on the first 15 minutes after signup."

### User stories

Describe the feature from the user's perspective. Who is the user? What do they want to do? Why do they want to do it?

The standard format works: "As a [user type], I want to [action] so that [outcome]." Write three to five user stories that cover the primary use cases. These stories ground the requirements in real user needs rather than abstract feature descriptions.

Here is what user stories look like for a real feature — say, adding team-level permissions to a feedback board:

- As a **team lead**, I want to restrict who can change the status of feedback posts so that only authorized team members can move items to "planned" or "shipped."
- As an **admin**, I want to assign different permission levels (viewer, contributor, moderator) to team members so that I can control access without creating separate boards.
- As a **contributor**, I want to see which actions I have permission to take so that I do not attempt something that will be blocked.

Notice that each story identifies a specific user type, a specific action, and a specific reason. "As a user, I want permissions to work" is not a user story. It is a wish.

If your team collects [customer feedback](/blog/collect-customer-feedback), pull user stories directly from feedback posts and support tickets. Real user language is more specific and more grounded than anything you write from scratch. [User interview questions](/blog/user-interview-questions) can also surface the stories you need.

### Requirements

The functional requirements. What the product needs to do, described in concrete terms. Each requirement should be testable — you should be able to look at the shipped feature and determine whether the requirement is met.

Separate requirements into categories:
- **Must-have:** The feature does not ship without these. These are the minimum viable requirements.
- **Should-have:** Important but not blocking. Include if time and complexity allow.
- **Nice-to-have:** Desirable but deferrable. Candidates for a follow-up release.

This is where the [MoSCoW framework](/blog/moscow-prioritization) or [RICE scoring](/blog/rice-framework-explained) can help you prioritize within the PRD itself.

### Success metrics

How will you measure whether this feature achieved its goals? Define specific, measurable outcomes.

Bad metric: "Users like the new feature." Good metric: "30% of active users adopt the feature within 60 days of launch. Support tickets related to the old workflow decrease by 50%."

Define the metrics before you build. If you cannot articulate what success looks like, you do not understand the problem well enough to write requirements for the solution.

### Timeline and milestones

A rough timeline, not a detailed project plan. Include key milestones: design complete, engineering start, internal beta, public launch. This section sets expectations without over-committing to specific dates.

For larger initiatives, break the timeline into phases. Phase 1 ships the must-haves. Phase 2 adds the should-haves. This gives the team a structure for incremental delivery.

### Open questions

Every PRD has unknowns. List them. Open questions are not a sign of a bad PRD — they are a sign of an honest one. Questions might include technical feasibility concerns, unresolved design decisions, dependencies on other teams, or areas where user research is incomplete.

Documenting open questions ensures they get answered. Unanswered questions that live only in someone's head tend to surface as surprises during implementation.

## Free PRD template

Copy and adapt this product requirements document template for your team.

```markdown
# [Feature Name] — Product Requirements Document

**Author:** [Name]
**Date:** [YYYY-MM-DD]
**Status:** [Draft / In Review / Approved]
**Stakeholders:** [List names and roles]

---

## Overview

[2-3 sentence summary. What are you building and why?]

## Goals

- [Goal 1: Specific, measurable outcome]
- [Goal 2: Specific, measurable outcome]

## Non-goals

- [What is explicitly out of scope for this initiative]
- [What you are not trying to solve]

## User stories

- As a [user type], I want to [action] so that [outcome].
- As a [user type], I want to [action] so that [outcome].
- As a [user type], I want to [action] so that [outcome].

## Requirements

### Must-have

- [ ] [Requirement — specific and testable]
- [ ] [Requirement — specific and testable]
- [ ] [Requirement — specific and testable]

### Should-have

- [ ] [Requirement]
- [ ] [Requirement]

### Nice-to-have

- [ ] [Requirement]

## Design

[Link to Figma, wireframes, or design specs. Include screenshots
of key screens if available.]

## Success metrics

| Metric | Current | Target | Measured by |
|--------|---------|--------|-------------|
| [Metric name] | [Baseline] | [Target] | [How you measure it] |
| [Metric name] | [Baseline] | [Target] | [How you measure it] |

## Timeline

| Milestone | Target date |
|-----------|-------------|
| Design complete | [Date] |
| Engineering start | [Date] |
| Internal beta | [Date] |
| Public launch | [Date] |

## Open questions

- [ ] [Question that needs to be answered before or during development]
- [ ] [Question that needs to be answered before or during development]

## References

- [Link to user research]
- [Link to related feedback posts]
- [Link to competitive analysis]
- [Link to technical design doc]
```

Adapt the template to your context. A startup building its first feature needs less structure than an enterprise team coordinating across five engineering teams. Remove sections that add no value for your team size and stage.

## Filled-out PRD example

Templates are more useful with an example. Here is a condensed PRD for a real-world feature: adding CSV export to a feedback board.

![A filled-out PRD example showing real content in every section](/blog/product-requirements-document-template/example-prd.webp)

```markdown
# CSV Export for Feedback Boards — Product Requirements Document

**Author:** Sarah Chen
**Date:** 2026-03-15
**Status:** Approved
**Stakeholders:** James (Engineering Lead), Maria (Design), Tom (CS Lead)

---

## Overview

Users need to export their feedback board data for reporting, analysis,
and sharing with stakeholders who do not use the product. We will add
CSV export for feedback posts, including votes, status, and metadata.

## Goals

- Enable users to export feedback data without manual copy-paste
- Support common reporting workflows (quarterly reviews, board meetings)

## Non-goals

- We are not building a BI integration or API endpoint (future work)
- We are not supporting PDF or Excel export in this iteration

## User stories

- As a product manager, I want to export all feedback posts with vote
  counts so I can include the data in my quarterly business review.
- As a CS lead, I want to filter by status before exporting so I can
  share only "planned" items with our customer advisory board.

## Requirements

### Must-have

- [ ] Export all feedback posts as CSV with columns: title, description,
      status, vote count, category, created date, author
- [ ] Allow filtering by status and category before export
- [ ] Include a "Download CSV" button on the board settings page

### Should-have

- [ ] Allow selecting which columns to include in the export
- [ ] Support date range filtering

### Nice-to-have

- [ ] Schedule recurring exports via email

## Success metrics

| Metric | Current | Target | Measured by |
|--------|---------|--------|-------------|
| Users exporting data manually (copy-paste) | ~15/week | 0 | Support ticket volume |
| Feature adoption | 0% | 20% of active boards within 60 days | Analytics |

## Open questions

- [ ] Should we include voter email addresses in the export? (Privacy)
- [ ] What is the maximum row count before we need async export?
```

This example is deliberately concise. A two-page PRD like this takes about an hour to write and gives engineering everything they need to start.

## PRD best practices

**Start with the problem, not the solution.** The most common PRD failure is describing a solution without establishing the problem. If the reader does not understand why this work matters after reading the Overview and Goals, the PRD is not doing its job. Root the document in user problems and business outcomes.

**Keep it concise.** A PRD is not a novel. Most good PRDs are two to four pages. If yours is longer than five pages, you are probably including implementation details that belong in a technical design doc. The PRD should contain enough context for the team to start, not every detail they will need along the way.

**Write requirements that are testable.** "The feature should be fast" is not a requirement. "The page loads in under 2 seconds on a 3G connection" is a requirement. Every requirement should have a clear pass/fail criterion.

**Include non-goals explicitly.** Scope creep kills timelines. Non-goals prevent the conversation where someone asks "shouldn't we also..." three weeks into development. If you considered something and decided not to include it, write it down as a non-goal.

**Collaborate early.** Share the PRD in draft form before it is polished. Get engineering input on feasibility. Get design input on user experience. Get stakeholder input on priorities. A PRD written in isolation and presented as final creates alignment problems, not solutions.

**Update it as decisions change.** A PRD is a living document during active development. When the team decides to cut a should-have or change an approach, update the PRD. The document should reflect what you actually built, not just what you planned to build. This makes it useful as a reference after launch.

**Ground decisions in user feedback.** The strongest PRDs cite specific user feedback, support ticket volumes, and feature request data. "42 users have requested this feature in the last quarter, with an average of 3 support tickets per week related to the workaround" is more convincing than "we think users want this." Pull data from your [feedback board](/features/feedback) and reference it directly.

**Use a prioritization framework for requirements.** The must-have / should-have / nice-to-have split is a good start. For more rigor, apply [MoSCoW prioritization](/blog/moscow-prioritization) or [RICE scoring](/blog/rice-framework-explained) to rank requirements within each tier. This is especially useful when stakeholders disagree about what is essential versus desirable. A framework makes trade-offs explicit. You can also use a [prioritization matrix](/blog/prioritization-matrix-template) to visualize the effort-impact relationship.

**Review before kickoff, not after.** A PRD that the team reads for the first time in the sprint planning meeting is too late. Share the draft at least a week before work begins. Give engineering time to flag feasibility concerns. Give design time to identify UX gaps. The goal is to resolve major questions in the document, not in the standup.

## PRD vs other product documents

A product requirements document is one of several documents product teams use. Here is how it relates to the others.

**PRD vs technical design doc.** The PRD defines what to build and why. The technical design doc defines how to build it. The PRD is owned by the product manager. The technical design doc is owned by engineering. They are complementary — engineering writes the tech design doc after reviewing the PRD.

**PRD vs user stories.** User stories are a component of a PRD, not a replacement. User stories describe individual interactions from the user's perspective. A PRD provides the broader context: goals, constraints, success metrics, and trade-offs that surround those stories.

**PRD vs design brief.** A design brief describes the visual and interaction design requirements. It is narrower than a PRD — focused on the user experience rather than the full product context. Some teams include design requirements in the PRD. Others write a separate design brief that references the PRD.

**PRD vs product spec.** The terms are often used interchangeably. When there is a distinction, a product spec tends to be more detailed and more prescriptive — describing exact behaviors, states, and edge cases — while a PRD stays at the requirements level. For most teams, one document serving both purposes is sufficient.

**PRD vs one-pager.** A one-pager is a condensed version of a PRD, typically used for smaller features or for getting initial buy-in before writing the full document. If the feature is small enough that a one-pager covers it, you may not need a full PRD at all.

## Tools for writing PRDs

Most teams write PRDs in the same tool they use for other documentation.

**Notion** is popular for PRDs because it supports rich formatting, embedded databases, and templates. You can create a PRD template in Notion and duplicate it for each new initiative. The built-in commenting and mention features work well for async review.

**Confluence** is the standard for larger organizations, especially those already using Jira. It integrates with project management workflows and supports granular permissions. The editor is less elegant than Notion but adequate for structured documents.

**Google Docs** works for teams that want simplicity. Real-time collaboration, commenting, and suggestion mode make it easy to review and iterate. The limitation is organization — Google Docs does not have a built-in way to structure and navigate a library of PRDs over time.

**Linear Docs** is gaining popularity among teams that use Linear for project management. Writing a PRD next to your project tracker means requirements and tasks stay connected. Linear's approach is opinionated — which helps maintain consistency across a team.

Whichever tool you use, the most important input to a good PRD is understanding what your users need. [Quackback](/features/feedback) connects user feedback directly to product decisions. When you are writing the user stories section of your PRD, you can reference specific feedback posts, vote counts, and user comments rather than guessing what users want. The feedback data grounds your requirements in evidence. When the feature ships, [Quackback's changelog](/features/changelog) closes the loop by notifying the users who requested it.

Quackback is open source (AGPL-3.0), so you can invite every PM, engineer, and stakeholder who needs to read a PRD. Its [MCP server](/features/mcp) lets you pull feedback and voting data straight into the AI assistant where you draft the document, and AI features are built in. You can self-host for free or run [Quackback Cloud](/pricing) as a managed option. See the [docs](/docs) to connect a board to your PRD workflow.

The workflow looks like this: collect feedback on a [feedback board](/features/feedback), identify the highest-voted requests with [feature voting](/features/voting), write a PRD grounded in that data, build the feature, and announce it through a [changelog](/features/changelog) that notifies every user who voted. The PRD is the bridge between what users ask for and what your team builds.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How long should a PRD be?

Most PRDs should be two to four pages. Match the length to the complexity and risk of the initiative: a one-week feature might need a single page, while a multi-team platform initiative might need five to six. If yours exceeds six pages, move implementation details into a technical design doc.

### Who writes the PRD?

The product manager typically owns and writes the PRD. But writing it should not happen in isolation. Engineering provides feasibility input and effort estimates. Design contributes user experience perspective. Stakeholders validate goals and priorities. The PM synthesizes these inputs into a coherent document.

### When should you write a PRD versus just creating tickets?

Write a PRD when the work involves ambiguity, trade-offs, or cross-team coordination. Tickets are good for well-understood tasks with clear acceptance criteria. A PRD provides the context and reasoning that individual tickets cannot capture. For medium-sized features, write a lightweight PRD and then break it into tickets for execution.

### How do you get stakeholders to actually read the PRD?

Keep it concise and put the overview, goals, and non-goals at the top. Make it scannable with headers, bullets, and tables. Share it in draft and ask for feedback on specific sections, not a vague "any thoughts?" Make reading the PRD a prerequisite for the kickoff meeting.

- [Product Strategy: How to Build One That Connects Vision to Execution](https://quackback.io/blog/product-strategy-guide): A practical guide to product strategy. How to define your product vision, set goals, prioritize with user feedback, and align your team around what to build.

Published: 2026-03-24

Product strategy is the bridge between your company vision and your daily execution. It answers one question: why are we building this and not something else?

![Product strategy connects your company vision to daily execution](/blog/product-strategy-guide/hero.webp)

Without a product strategy, teams build features that don't compound. Engineers ship what's loudest in the backlog. Designers solve problems in isolation. Product managers spend their days reacting to requests instead of directing effort toward outcomes that matter. Everyone stays busy, but the product drifts.

A good product strategy gives your team a framework for saying no. It connects the features you ship today to the business outcomes you need this quarter and the vision you are working toward over the next few years. It turns a pile of [feature requests](/blog/best-feature-request-tools) into a coherent plan.

## What is a product strategy

A product strategy is a set of deliberate choices about who your product serves, what problems it solves, and how it wins against alternatives. It defines the direction, not the details. The details come later in your [roadmap](/blog/what-is-a-product-roadmap) and backlog.

Roger Martin's "Playing to Win" framework distills strategy down to five choices: winning aspiration, where to play, how to win, capabilities required, and management systems. Product strategy follows the same logic. You choose a market, define how your product wins in that market, and align your team around those choices.

This distinction matters because teams regularly confuse a product strategy with adjacent artifacts:

- **A roadmap** is not a product strategy. A [roadmap](/blog/product-roadmap-examples) describes what you plan to build and roughly when. It is an output of your strategy, not the strategy itself.
- **A backlog** is not a product strategy. A backlog is a [prioritized](/blog/rice-framework-explained) list of tasks. It is a tool for execution. If your strategy is just your backlog, you are letting urgency drive direction.
- **A business plan** is not a product strategy. A business plan covers revenue models, market sizing, and financial projections. Your product strategy should support your business plan, but it operates at a different level — closer to the product, closer to the user.

A product strategy sits above all three. It is the reasoning that explains why your roadmap looks the way it does, why certain backlog items rank higher than others, and why your product decisions support the business model.

Here is a concrete example. A B2B feedback tool might set its product strategy as: "Win mid-market SaaS teams (50-500 employees) by being the only feedback platform that connects feature requests directly to a public roadmap, with AI that reduces triage time by 80%." That single statement defines the audience (mid-market SaaS), the differentiator (feedback-to-roadmap connection plus AI), and the measurable claim (80% triage reduction). Every roadmap decision flows from it.

## The components of a product strategy

Every product strategy worth the name includes five components. You don't need a 40-page document. You need clear answers to five questions.

![The five components of a product strategy](/blog/product-strategy-guide/components.webp)

**Vision.** Where is the product going in 2-5 years? This is your north star. It should be specific enough to guide decisions and ambitious enough to motivate the team. "Become the default way teams collect and act on user feedback" is a vision. "Make customers happy" is not.

Test your vision with this question: does it help you decide what *not* to build? If the answer is no, the vision is too broad. Slack's early vision was not "improve workplace communication." It was "replace internal email." That constraint made every feature decision clearer.

**Goals and outcomes.** What measurable results will tell you the strategy is working? Good goals are outcomes, not outputs. "Reduce time-to-first-value from 3 days to 30 minutes" is an outcome. "Ship onboarding redesign" is an output. The outcome is what you care about. The output is one possible way to get there.

Use OKRs (Objectives and Key Results) to structure this. The objective is qualitative and directional: "Make onboarding effortless for new teams." The key results are measurable: "Activation rate from 30% to 50%," "Median time-to-value from 72 hours to 4 hours," "Support tickets about setup reduced by 60%." Three key results per objective is usually enough.

**Target audience.** Who are you building for, specifically? Not "everyone." The more precisely you define your target user, the easier every downstream decision becomes. Knowing that your primary user is a product manager at a 20-100 person SaaS company makes design, pricing, positioning, and prioritization dramatically simpler.

Write a one-paragraph user profile for your primary persona. Include their role, company size, daily workflow, biggest frustration, and what success looks like for them. Here is an example: "Sarah is a PM at a 60-person SaaS company. She spends 3 hours per week manually aggregating feedback from Slack, Intercom, and email into a spreadsheet. She needs a single place where her team can see what users are asking for, ranked by demand, so she can justify roadmap decisions to her VP of Product."

**Competitive positioning.** How does your product win against alternatives? This includes direct competitors, adjacent tools, and the spreadsheet or manual process your users rely on today. You need a clear answer to why someone should choose your product over their current solution.

Map your competitive landscape into three categories: direct competitors (same problem, same audience), adjacent tools (overlapping features, different core), and non-consumption (the spreadsheet, the Slack channel, doing nothing). Your positioning should articulate a clear wedge — the one dimension where you are unambiguously better. Price, speed, integration depth, and data ownership are common wedges.

**Key bets and themes.** What are the 2-4 big areas you are investing in this quarter or half? These are the strategic themes that translate your vision into action. "Expand self-serve onboarding," "Build integrations with support tools," or "Improve feedback-to-roadmap workflow" are themes. They give your team focus without prescribing specific features.

Each theme should have a hypothesis attached: "We believe that building Slack and Intercom integrations will reduce manual feedback collection by 70%, leading to a 15% increase in weekly active usage among PMs." This makes the bet testable. At the end of the quarter, you can evaluate whether the hypothesis held.

## How feedback shapes product strategy

User feedback is the most underused input to product strategy. Teams [collect it](/blog/collect-customer-feedback), file it, and occasionally reference it during planning. But feedback should be a continuous signal that shapes which bets you make and how you prioritize within those bets.

There are three ways feedback improves your product development strategy:

**Feedback tells you what to prioritize.** When 200 users ask for a Slack integration and 12 ask for a Microsoft Teams integration, you have a signal. Not a mandate — you still apply judgment — but a data point that is hard to get any other way. Vote counts on [feature requests](/features/voting) quantify demand in a way that gut feeling cannot.

Consider a real scenario: your strategy says "invest in integrations" as a theme. You have bandwidth for two integrations this quarter. Without feedback data, the team debates based on opinions. With a [feedback board](/features/voting) showing 340 votes for Slack, 180 for Jira, 45 for Teams, and 30 for Asana, the first two bets are obvious. You still validate the decision (maybe the Jira voters are all enterprise accounts worth 10x the revenue), but you start from evidence.

**Feedback reveals problems you didn't anticipate.** Your strategy might focus on acquisition, but feedback from existing users reveals a churn problem you hadn't scoped. The best product strategies are feedback-informed. They absorb new information and adjust.

Here is how this works in practice. A team launches a new pricing tier expecting it to drive expansion revenue. Within two weeks, their feedback board fills with posts about confusion around feature limits, unexpected billing changes, and lost access to tools they were using. The strategy assumed pricing was an acquisition lever. Feedback revealed it was creating a retention problem. The team pivots their Q2 theme from "launch enterprise tier" to "simplify pricing and restore trust." Without the [feedback loop](/blog/customer-feedback-loop), this shift would have taken two quarters to surface through churn metrics.

**Feedback validates or challenges your bets.** You bet on "improve onboarding" as a strategic theme. Three months in, feedback data shows that onboarding is no longer the top pain point — users are now asking for better reporting. A feedback-informed strategy surfaces this shift early instead of waiting for quarterly metrics to reveal it.

The key distinction: the best strategies are feedback-informed, not feedback-driven. You don't build everything users ask for. You use feedback as one input alongside business goals, technical constraints, and your own product judgment. But ignoring it is worse than over-indexing on it.

A useful framework: weight feedback by strategic alignment. When a feature request maps directly to one of your strategic themes, it gets priority attention. When it falls outside your current themes, it goes into a "future consideration" bucket — valuable signal for the next strategy cycle, but not something that pulls the team off their current bets.

## Building a product strategy step by step

Here is a practical process for building a product strategy from scratch or revising one that has gone stale. This works whether you are a solo PM at a startup or a product leader managing multiple teams.

**1. Define your vision (30 minutes).** Write a 1-2 sentence description of where your product is headed. It should be specific, opinionated, and durable. Test it by asking: does this help me decide what not to build?

Template: "In [time horizon], [product name] will be [specific position] for [specific audience] by [key differentiator]."

Example: "In 3 years, Quackback will be the default feedback platform for product-led SaaS teams by connecting every user voice directly to the roadmap through AI-powered triage."

**2. Set measurable outcomes (1 hour).** Pick 3-5 outcomes for the next quarter. Each should be measurable, tied to a user or business result, and achievable within the time frame. Avoid vanity metrics. Focus on retention, activation, time-to-value, or revenue per user.

Format each outcome as: "[Metric] from [current baseline] to [target] by [date]."

- Activation rate from 30% to 50% by end of Q2
- Median time-to-first-value from 72 hours to 4 hours by end of Q2
- Net revenue retention from 95% to 105% by end of Q3

**3. Gather user signal (2-3 hours).** Review your feedback boards, support tickets, sales call notes, and [churn surveys](/blog/product-market-fit-survey). Look for patterns, not individual requests. What problems appear repeatedly? What workarounds are users building? Where is the highest concentration of unmet need?

Pull data from these sources:
- Feature request boards (vote counts and request frequency)
- Support tickets (tag by category, count by theme)
- Sales call notes (lost deal reasons, feature gaps mentioned)
- Churn surveys (reasons for leaving)
- Session recordings (where users get stuck)
- NPS verbatim responses (what drives promoters vs detractors)

**4. Identify themes (1 hour).** Group the patterns into 2-4 strategic themes. A theme is a problem space, not a solution. "Users struggle to share insights with their team" is a theme. "Build a Slack integration" is a solution that might fall under that theme.

Use affinity mapping: write each feedback pattern on a sticky note (or digital equivalent), cluster similar patterns, and name the clusters. Those names become your themes. If you end up with more than four, force-rank them using a [prioritization framework](/blog/rice-framework-explained) and cut the bottom ones.

**5. Make bets (1 hour).** For each theme, decide how much of your team's capacity to allocate. This is where strategy gets real. Saying "we will invest 40% of engineering effort in onboarding improvements" is a bet. It means you are choosing not to invest that capacity elsewhere.

Write each bet as a hypothesis: "We believe [action] will result in [outcome] because [evidence]." Example: "We believe adding a guided setup wizard will increase activation from 30% to 50% because 65% of churned users never completed initial configuration, and our top competitor with a wizard sees 3x our activation rate."

**6. Communicate via roadmap.** Translate your themes and bets into a [roadmap](/blog/what-is-a-product-roadmap) that shows what comes first, what comes next, and what you are considering for later. Use a Now/Next/Later format rather than rigid dates — it gives stakeholders visibility without creating false precision.

The roadmap is the public expression of your strategy. A [public roadmap](/features/roadmap) takes this further by letting users see your direction and vote on what matters to them, feeding signal back into your next strategy cycle.

**7. Iterate.** Review your strategy every quarter. Check outcomes against targets. Review fresh feedback data. Adjust themes and bets based on what you learned. A strategy that never changes is a strategy that ignores reality.

Build a simple scorecard: for each bet, track the hypothesis, the outcome metric, the baseline, the target, and the actual result. After one quarter, you will have a clear picture of which bets paid off and which need adjustment.

## Product strategy vs product roadmap

This is the most common confusion in product management, and it leads to real problems.

Your product strategy is the **why**. Why are you focused on these problems? Why are you targeting this audience? Why are these the right bets for this quarter?

Your [product roadmap](/blog/what-is-a-product-roadmap) is the **what and when**. What are you building? What comes first? When can stakeholders expect to see results?

The two should be connected. Every item on your roadmap should trace back to a strategic theme. If it doesn't, you are either missing a theme or building something that doesn't support your strategy.

Here is a practical test: pick any item on your current roadmap. Can you answer these three questions about it?

1. Which strategic theme does this support?
2. Which outcome will this move?
3. What user evidence supports building this now?

If you cannot answer all three, the item is either missing strategic context or should not be on the roadmap. Run this test on your top 10 roadmap items. The results will tell you how well your strategy and roadmap are connected.

When teams skip the strategy and jump straight to the roadmap, the roadmap becomes a feature list driven by whoever is loudest. There is no way to evaluate trade-offs because there is no framework for what matters. A digital product strategy provides that framework.

When teams write a strategy but disconnect it from the roadmap, the strategy becomes a document that lives in a slide deck and gets referenced once a quarter. It has no operational impact.

The fix is simple: your roadmap should be organized by strategic themes. Each theme maps to an outcome from your strategy. Features and initiatives within each theme are the specific bets you are making to achieve that outcome. See our guide on [product roadmap examples](/blog/product-roadmap-examples) for concrete templates that use this theme-based structure.

| | Strategy | Roadmap |
|---|---|---|
| **Answers** | Why are we building this? | What are we building and when? |
| **Time horizon** | 1-3 years (revisited quarterly) | 1-3 quarters (updated continuously) |
| **Audience** | Leadership, product org, cross-functional | Engineering, design, stakeholders, users |
| **Format** | Document or single page | Kanban board, timeline, or Now/Next/Later |
| **Changes when** | Market shifts, new data invalidates bets | Sprint planning, reprioritization |

## Common product strategy frameworks

Several established frameworks can help structure your strategic thinking. Choose one that fits your context rather than trying to combine all of them.

**Playing to Win (Lafley & Martin).** Five cascading choices: winning aspiration, where to play, how to win, capabilities required, and management systems. Best for teams that need to make clear market positioning decisions. Start by defining where you will *not* play — the constraints are more useful than the aspirations.

**Jobs to Be Done (Christensen).** Define strategy around the jobs your users are hiring your product to do. "When [situation], I want to [motivation], so I can [expected outcome]." This framework keeps strategy anchored to user needs rather than competitive moves. It pairs well with [voice of customer](/blog/voice-of-customer) data.

**Lean Product Strategy.** Start with a [value hypothesis](/blog/value-hypothesis) ("Does this solve a real problem?") and a growth hypothesis ("How will users discover this?"). Validate both before investing heavily. Best for early-stage products or new product lines where assumptions outnumber facts.

**Now/Next/Later Themes.** Organize your strategic themes by time horizon. "Now" themes get 60% of capacity. "Next" themes get 30% (research and early prototyping). "Later" themes get 10% (monitoring and signal collection). This maps directly to a [roadmap format](/blog/roadmap-template) your stakeholders already understand.

## Communicating your product strategy

A product strategy that only lives in your head or in a document your team has never read is not a strategy. It is a thought exercise. Communication is where strategy becomes operational.

**Internally**, share your strategy with the entire product and engineering organization. Use it to explain why certain projects are prioritized and others are not. Reference it in sprint planning, design reviews, and roadmap discussions. The strategy should be the answer to "why are we building this?"

Create a one-page strategy brief that every team member can reference. Include: vision (2 sentences), target user (1 paragraph), three outcomes for this quarter, and 2-3 strategic themes with their hypotheses. Post it where your team works — in your project management tool, on a wiki page, in your team channel. If someone has to search for the strategy, they will not use it.

**With stakeholders**, translate the strategy into language that connects to their concerns. Executives care about business outcomes. Sales cares about competitive positioning and feature gaps. Support cares about which user problems are being addressed. Frame your strategy in terms each audience cares about.

| Audience | Frame strategy as | Example |
|---|---|---|
| CEO/Board | Revenue and market impact | "This theme drives $2M ARR expansion by Q4" |
| Sales | Competitive wins and deal unblocks | "Slack integration closes the #1 lost-deal gap" |
| Engineering | Technical direction and debt trade-offs | "We are investing in API infrastructure before new features" |
| Support | User problems being solved | "Top 3 ticket categories will drop 40% by Q3" |
| Users | What is coming and why | "You asked for integrations — here is what is next" |

**With users**, a [public roadmap](/features/roadmap) is the most effective way to communicate your product launch strategy and ongoing direction. It shows users what you are working on, what comes next, and what you have shipped. A public roadmap turns your strategy into a conversation. Users vote on what matters to them, leave feedback on planned features, and see that their input shapes your direction.

[Feedback boards](/features/voting) close the loop in the other direction. They give users a structured way to tell you what they need, and they give you a [continuous stream of signal](/blog/continuous-discovery-habits) that feeds back into your strategy.

## Frequently asked questions

### How often should you revisit your product strategy?

Review it quarterly. A lightweight check every month helps you catch early signals that a bet is not working. A deeper review each quarter lets you adjust themes, update outcomes, and incorporate what you learned from the previous cycle. Strategies that only get revisited annually tend to drift from reality.

Use a simple quarterly review checklist: (1) Score each bet's hypothesis against actual outcomes. (2) Review new feedback data for emerging patterns. (3) Check if target audience assumptions still hold. (4) Decide what to double down on, what to pivot, and what to stop.

### What is the difference between a product strategy and a go-to-market strategy?

A product strategy defines what you build and why. A go-to-market strategy defines how you bring it to market — pricing, positioning, channels, launch tactics. They should be aligned. Your go-to-market strategy should reflect the same target audience and competitive positioning defined in your product strategy.

### How do you get buy-in for a product strategy from leadership?

Start with outcomes, not features. Executives care about business results. Frame your strategy around the outcomes it will drive — retention improvement, expansion revenue, reduced churn — and explain why your chosen themes are the best bets to achieve those outcomes. Use feedback data to support your case. Vote counts and request volumes make prioritization decisions concrete rather than subjective.

Present a "strategy on a page" with four sections: the outcome you are targeting, the user evidence supporting your bets, the capacity allocation across themes, and the risks if you do not act. One page, four sections, ten minutes. That is enough for most leadership reviews.

### Can a small team benefit from a formal product strategy?

Yes. A small team benefits more, not less. When you have limited capacity, every decision about what to build carries more weight. A clear strategy helps a small team avoid spreading effort across too many priorities. Even a one-page document with a vision, three outcomes, and two themes is enough to align a team of five.

### How do you prioritize within a strategic theme?

Once you have chosen your themes, use a scoring framework like [RICE](/blog/rice-framework-explained) (Reach, Impact, Confidence, Effort) or [MoSCoW](/blog/moscow-prioritization) to rank initiatives within each theme. The strategy tells you *which problem spaces* to invest in. The prioritization framework tells you *which specific solutions* to build first within those spaces.

### What tools support product strategy execution?

Your strategy should connect to three operational tools: a feedback system to gather continuous user signal, a roadmap tool to communicate direction, and a prioritization framework to evaluate trade-offs. [Feature voting boards](/features/voting) quantify demand. A [public roadmap](/features/roadmap) communicates direction. And frameworks like RICE or MoSCoW structure the ranking decisions within your themes.

- [ServiceNow Pricing 2026: Module Costs and True TCO](https://quackback.io/blog/servicenow-pricing): ServiceNow's pricing in 2026. Per-user module costs, license tiers, AI add-ons, and the true total cost of ownership including implementation.

Published: 2026-03-24

ServiceNow is the dominant enterprise IT service management platform. It powers ITSM, ITOM, HR service delivery, and customer service management for large organizations. If you work at a company with more than 1,000 employees, there is a good chance ServiceNow runs your internal help desk, change management, or asset tracking.

![ServiceNow total cost of ownership — the iceberg model](/blog/servicenow-pricing/hero.webp)

> ServiceNow does not publish public pricing — every contract is a custom quote negotiated with sales. Industry estimates put **ITSM** at $70-$200+ per fulfiller per month depending on tier, with the **Now Assist** AI add-on adding a 50-60% uplift and implementation typically costing 3-5x the first-year license fee. A mid-market organization of 50 fulfillers should budget $500K-$2M for year one including implementation, and enterprise buyers routinely negotiate 40-50% off list prices.
>
> *Pricing last verified March 2026. ServiceNow does not publish public pricing. All figures are industry estimates from multiple sources. Actual pricing varies by contract size, modules, and negotiation. Contact ServiceNow for a quote.*

ServiceNow's pricing model is fundamentally different from most SaaS tools. There is no pricing page, no self-serve signup, and no transparent per-user rate card. Everything is negotiated. The cost depends on which modules you license, how many fulfillers (agents) you have, what add-ons you select, and how much leverage you bring to the negotiation. For comparison, alternatives like [Zendesk](/blog/zendesk-pricing) and Jira Service Management publish their pricing publicly.

## How ServiceNow pricing works

ServiceNow uses a subscription model with several key dimensions. Understanding these dimensions is essential before entering a sales conversation.

**Fulfiller-based licensing.** You pay per fulfiller — the agents and admins who work within the platform. End users who submit tickets through a self-service portal generally do not count as fulfillers. The distinction matters: a 5,000-employee company might have only 50-100 fulfillers, but the licensing cost is based on that fulfiller count, not total headcount. Organizations with 1,000+ users sometimes see rates drop to $50-$75/fulfiller/month due to volume.

**Module-based pricing.** Each product area (ITSM, ITOM, HR Service Delivery, Customer Service Management, SecOps) is a separate module with its own pricing. You pick the modules you need and pay for each one. Bundling multiple modules may yield discounts, but each addition increases your annual commitment. Some modules have user minimums — you cannot buy a single seat.

**Tier-based feature access.** Within each module, ServiceNow offers tiers (Standard, Professional, Enterprise, Pro Plus) that unlock progressively more features. Higher tiers cost more per fulfiller. The Pro Plus tier includes AI capabilities (Now Assist) and adds a 50-60% uplift.

**Custom quotes only.** There is no public price list. Every contract is negotiated directly with ServiceNow's sales team. Pricing depends on deal size, contract length, and your organization's negotiating position. The average annual contract value from public data is approximately $130,000, but this reflects a wide distribution from $50,000 mid-market deals to multi-million-dollar enterprise contracts.

**Annual billing with multi-year commitments.** ServiceNow contracts are billed annually, typically with 2-3 year commitments. Annual price escalators of 3-7% are standard. Your year-three cost is higher than your year-one cost even if nothing else changes.

## ITSM pricing tiers

ITSM is ServiceNow's core product and the module most organizations start with. Here are the estimated per-fulfiller costs based on industry data.

![ServiceNow ITSM pricing tiers — estimated costs per fulfiller](/blog/servicenow-pricing/itsm-tiers.webp)

| Tier | Est. Cost (per fulfiller/month) | Est. with AI Uplift | Key Features |
|------|--------------------------------|---------------------|--------------|
| ITSM Standard | $70-$100 | $105-$160 | Incident management, knowledge management, self-service portal, basic SLA management |
| ITSM Professional | $120-$150 | $180-$240 | Standard + Performance Analytics, Vendor Manager Workspace |
| ITSM Enterprise | $160-$200+ | $240-$320+ | Professional + Workforce Optimization, Process Mining |

**ITSM Standard** covers the basics: incident management, a knowledge base, a self-service portal for end users, and SLA management. Most organizations start here. At $70-$100/fulfiller/month, it is the entry point — but still significantly more expensive than alternatives like Jira Service Management ($19/agent/month) or Freshservice ($19/agent/month).

**ITSM Professional** adds Performance Analytics for reporting on team efficiency and SLA compliance, plus Vendor Manager Workspace for tracking third-party service providers. The jump from Standard to Professional is roughly $50/fulfiller/month — a meaningful premium for analytics and vendor management capabilities.

**ITSM Enterprise** layers on Workforce Optimization (agent scheduling, capacity planning) and Process Mining (automated workflow analysis). These features matter for large service desks with hundreds of agents where optimizing agent utilization directly impacts cost.

**Pro Plus (Now Assist AI)** is ServiceNow's generative AI add-on. It adds auto-generated incident summaries, suggested resolutions, conversational search, and AI-assisted knowledge article creation. The cost is a 50-60% uplift on your base tier price. At the Enterprise tier, that means an estimated $240-$320+ per fulfiller per month. In 2026, ServiceNow is also shifting toward consumption-based pricing for some AI features — "Assist" tokens and orchestration transactions may have monthly caps, with overage charges if limits are exceeded. Get clarity on this before signing.

## Other module pricing

ServiceNow's platform extends well beyond ITSM. Each additional module is a separate line item with its own per-fulfiller pricing.

| Module | Est. Cost (per fulfiller/month) | Est. Annual (10 fulfillers) | Key Capabilities |
|--------|--------------------------------|----------------------------|-----------------|
| ITOM | $150-$200 | $18,000-$24,000 | Discovery, service mapping, event management, cloud management |
| HR Service Delivery | $120-$180 | $14,400-$21,600 | Employee service center, case management, onboarding workflows |
| CSM | $150-$200 | $18,000-$24,000 | Customer support workflows, case management, customer portals |
| SecOps | $150-$250 | $18,000-$30,000 | Security incident response, vulnerability management |
| AI & Analytics Add-ons | $50-$100+ | $6,000-$12,000 | Advanced analytics, AI agents, predictive intelligence |

**ITOM (IT Operations Management)** is typically purchased alongside ITSM for organizations that want visibility into their infrastructure. At $150-$200/fulfiller/month, it is one of the more expensive modules but covers critical capabilities like automated discovery and service mapping.

**HR Service Delivery** powers employee service centers, case management, and onboarding workflows. The fulfiller count here is HR team members, not all employees. At $120-$180/fulfiller/month, a 10-person HR team adds $14,400-$21,600/year to your ServiceNow bill.

**Customer Service Management (CSM)** covers external-facing customer support workflows. Pricing varies widely based on scope and integration requirements. CSM tends to be one of the more expensive modules because it overlaps with dedicated customer support platforms like [Zendesk](/blog/zendesk-pricing) and [Intercom](/blog/intercom-pricing) that cost a fraction of the price for most use cases.

**Integration licensing** is a hidden cost. Connecting ServiceNow to Slack, Salesforce, Jira, or other tools may require additional hub licenses beyond the base module pricing.

Each module you add increases your annual commitment. Organizations that start with ITSM often expand into ITOM, then HR, then CSM over several years. ServiceNow's sales motion is built around this land-and-expand pattern. Industry data on typical discounts by module: ITSM 40-50% off list, ITOM 35-55% off, HR Service Delivery 55-70% off. Newer and less popular modules tend to carry deeper discounts because ServiceNow is incentivized to drive adoption.

## ServiceNow pricing at scale

Here is what ServiceNow ITSM costs at different scales, using the mid-range of industry estimates.

| Fulfillers | ITSM Standard (Est. Annual) | ITSM Professional (Est. Annual) | ITSM Enterprise (Est. Annual) |
|-----------|---------------------------|-------------------------------|------------------------------|
| 10 | $10,200-$12,000 | $14,400-$18,000 | $19,200-$24,000 |
| 50 | $42,000-$60,000 | $72,000-$90,000 | $96,000-$120,000 |
| 100 | $84,000-$120,000 | $144,000-$180,000 | $192,000-$240,000 |
| 500 | $420,000-$600,000 | $720,000-$900,000 | $960,000-$1,200,000 |

These figures are license costs only for a single module (ITSM). They do not include implementation, customization, additional modules, or AI add-ons. The average ServiceNow contract value from public data is approximately $130,000 annually, which reflects a wide range of deal sizes from mid-market to large enterprise.

At 500 fulfillers on ITSM Enterprise, license costs alone can exceed $1M annually. Add ITOM, HR Service Delivery, and the Now Assist AI uplift, and total license fees can reach $3M+ per year for large organizations.

## The real total cost of ownership

The license fee is only one part of what ServiceNow actually costs. The total cost of ownership is significantly higher — and this is where most organizations underestimate.

![ServiceNow total cost of ownership breakdown](/blog/servicenow-pricing/tco-breakdown.webp)

**Implementation multiplier: 3-5x license cost.** ServiceNow implementations are complex. They involve workflow design, integration with existing systems (Active Directory, email, monitoring tools, asset databases), data migration, user training, and change management. Industry data consistently shows implementation costs at 3-5x the first-year license fee. A $200,000 annual license translates to $600,000-$1,000,000 in implementation costs. Implementation partner fees range from $30,000 for basic setups to $450,000+ for full enterprise deployments.

**First-year total for mid-market.** A mid-market organization (50 fulfillers) licensing ITSM can expect $150,000-$400,000 in annual license fees and $500,000-$2,000,000 in total first-year costs when implementation is included. Here is a realistic cost breakdown:

| Cost Category | Mid-Market (50 fulfillers) | Enterprise (500 fulfillers) |
|--------------|---------------------------|----------------------------|
| ITSM License (annual) | $150,000-$400,000 | $420,000-$1,200,000 |
| Implementation | $150,000-$450,000 | $500,000-$2,000,000 |
| Admin Personnel (annual) | $100,000-$300,000 | $300,000-$750,000 |
| Training & Change Mgmt | $30,000-$75,000 | $100,000-$250,000 |
| **First-Year Total** | **$430,000-$1,225,000** | **$1,320,000-$4,200,000** |
| **Annual Ongoing (Year 2+)** | **$250,000-$700,000** | **$720,000-$1,950,000** |

**Ongoing administration.** ServiceNow is not a set-and-forget platform. Most organizations require 1-3 dedicated full-time ServiceNow administrators to manage the instance, build workflows, handle upgrades, and support users. Certified ServiceNow administrators command $120,000-$175,000 annually in the US market. If your admin leaves, replacing them takes time and often requires expensive contractors ($150-$200/hour) to bridge the gap.

**Multi-year contracts with escalators.** ServiceNow typically requires multi-year commitments (2-3 years). Annual price escalators of 3-7% are standard. On a $300,000/year contract with a 5% escalator, you pay $315,000 in year two and $330,750 in year three — an additional $45,750 over the contract without any changes to scope or usage.

## How to negotiate ServiceNow pricing

ServiceNow pricing is always negotiable. Here are strategies that enterprise buyers use to reduce costs.

**Start negotiations 6-12 months before renewal.** ServiceNow's sales team gains leverage as your contract expiration approaches. Starting early gives you time to evaluate alternatives, benchmark pricing, and avoid being pressured into quick decisions. Do not let negotiations get squeezed into the final weeks.

**Negotiate by module, not by bundle.** ServiceNow will often propose bundled pricing that looks like a discount but hides unfavorable terms on individual modules. Negotiate pricing for each module separately. Industry data shows typical discounts of 40-50% off list for ITSM, 35-55% for ITOM, and 55-70% for HR Service Delivery.

**Bring usage data to the table.** Use ServiceNow's own analytics tools to identify unused licenses and underutilized modules. Showing data on actual versus purchased usage gives you leverage to right-size your contract. Unused licenses should be eliminated or converted.

**Escalate strategically.** Executive escalation can unlock deeper discounts. One documented case showed a CIO escalating and increasing the discount from 25% to 45% by clearly articulating budget constraints and the availability of alternatives.

**Secure price protections.** Negotiate future price caps, renewal rate protections, or swap rights for products and volumes you are not using. Without protections, the standard 3-7% annual escalator can add up to 20%+ over a three-year term.

**Time purchases around fiscal quarters.** ServiceNow's sales team is quota-driven. Deals closed at the end of a fiscal quarter or fiscal year often carry better discounts as reps push to hit their numbers.

**Push back on ServiceNow Impact.** ServiceNow Impact is a premium support and success offering that gets bundled into deals. Industry analysts note that ServiceNow needs Impact in your deal more than you need Impact. Negotiate for reduced percentages or connect Impact pricing to product pricing for better overall terms.

## Hidden costs

Beyond the sticker price and implementation, there are costs that catch organizations off guard.

**Module expansion tax.** ServiceNow's platform is designed to pull you into additional modules over time. Each module you add is a new line item with its own per-fulfiller pricing. What starts as an ITSM deployment can grow into ITSM + ITOM + HR + CSM, with total license costs multiplying several times over. This land-and-expand model is intentional — ServiceNow's growth depends on it.

**AI add-on uplift.** Now Assist (the Pro Plus AI SKU) adds a 50-60% uplift on your base license cost. For an ITSM Enterprise customer paying $200/fulfiller/month, the AI add-on pushes costs to $300-$320/fulfiller/month. That is a significant premium for AI features that many competitors — like Freshservice (Freddy AI included on higher tiers) and Jira Service Management — include in their base pricing.

**No free trial or self-serve signup.** You cannot try ServiceNow before committing. The sales process requires discovery calls, demos, and contract negotiation. This is a significant barrier for mid-market organizations that want to evaluate the platform before signing a multi-year commitment.

**No self-hosting option.** ServiceNow is a cloud-only platform. There is no on-premises or self-hosted deployment. For organizations with strict data residency or sovereignty requirements, this limits your options.

**Test environment fees.** ServiceNow provides standard production and non-production environments, but additional test environments — often needed for larger implementations — carry extra fees.

**Security add-ons are separate.** Advanced encryption features and security modules (SecOps) are not included in base ITSM pricing. If your compliance requirements demand these capabilities, budget for them separately.

**Customization lock-in.** The more you customize ServiceNow — custom workflows, integrations, scripts, and configurations — the harder it becomes to migrate away. Heavy customization also complicates upgrades, which can require re-testing and re-validating custom code. This technical debt is a real cost that grows over time.

**SSO is typically included at enterprise tier.** Unlike some tools that gate SSO behind premium plans, ServiceNow generally includes SSO at the enterprise level. But you are already paying enterprise-tier pricing to get there.

## ServiceNow alternatives

If ServiceNow's pricing and complexity do not match your organization's size or budget, there are alternatives worth evaluating. The cost difference can be dramatic.

| Tool | Starting Price | Best For |
|------|---------------|----------|
| Jira Service Management | $19.04/agent/mo | Mid-market ITSM with Atlassian ecosystem |
| Freshservice | $19/agent/mo | Mid-market ITSM with simpler setup |
| Zendesk | $55/agent/mo | Help desk and customer support |
| ServiceNow ITSM Standard | $70-$100/fulfiller/mo (est.) | Enterprise ITSM at scale |

### Jira Service Management

Atlassian's ITSM product. A free plan supports up to 3 agents. Standard starts at $19.04/agent/month. Premium is $47.82/agent/month. Jira Service Management covers incident management, change management, asset management, and SLA tracking. It lacks ServiceNow's depth in ITOM and HR but costs a fraction of the price for small-to-mid-size teams. At 50 agents on Standard, you pay roughly $11,424/year — compared to $42,000-$60,000/year for ServiceNow ITSM Standard at the same scale. The Atlassian ecosystem (Confluence, Jira Software) provides tight integration.

### Freshservice

Freshworks' ITSM product. Starter begins at $19/agent/month, Growth is $49/agent/month, and Pro is $99/agent/month (billed annually); Enterprise is custom-quoted. Freshservice covers the core ITSM workflows with a simpler setup process and lower implementation costs. Freddy AI is a paid add-on rather than the 50-60% platform-wide uplift ServiceNow's Now Assist carries. A strong option for mid-market organizations that need ITSM without ServiceNow's complexity or cost. At 50 agents on Growth, you pay roughly $29,400/year.

### Zendesk

Primarily a customer support platform, but [Zendesk's](/blog/zendesk-pricing) Suite plans ($55-$115/agent/month) cover ticket management, knowledge bases, and self-service portals that overlap with basic ITSM use cases. Not a full ServiceNow replacement, but sufficient for organizations whose primary need is a help desk rather than enterprise-grade ITSM.

### Quackback for the feedback layer

ServiceNow handles IT service management, but it is not built for collecting product feedback from end users. If you need [feature request boards](/features/feedback), [public voting](/features/voting), a customer-facing [roadmap](/features/roadmap), or [changelogs](/features/changelog), ServiceNow does not cover that workflow. [Quackback](https://quackback.io) is [open source](/open-source) and self-hostable. It handles the [feedback collection](/use-cases/feedback-management) layer — boards, voting, roadmaps, changelogs, and 25 integrations — that enterprise ITSM platforms leave out. Run it free on your own infrastructure with [self-hosting](/self-hosted), or use the managed [Quackback Cloud](/pricing) if you would rather not operate it yourself.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Does ServiceNow publish its pricing?

No. ServiceNow does not have a public pricing page. All pricing is custom and requires a conversation with their sales team. The estimates in this guide are based on industry data and publicly available contract information. This opacity is intentional — it gives ServiceNow maximum flexibility in negotiations.

### How much does ServiceNow cost per year?

It varies widely. Mid-market organizations (50 fulfillers) typically pay $150,000-$400,000 annually for ITSM licensing. Enterprise organizations (500+ fulfillers) with multiple modules can pay $1M-$3M+ annually. Total first-year costs including implementation run 3-5x higher than the license fee alone. The average annual contract value from public data is approximately $130,000.

### What is a fulfiller in ServiceNow?

A fulfiller is a licensed user who works within the ServiceNow platform — agents who resolve tickets, admins who configure workflows, and managers who use reporting. End users who submit requests through a self-service portal are generally not counted as fulfillers. The distinction matters for budgeting: a 5,000-employee company might only license 50-100 fulfillers.

### How much does Now Assist (AI) cost?

Now Assist is ServiceNow's generative AI add-on, sold as the Pro Plus SKU. It adds an estimated 50-60% uplift on top of your base tier pricing. For an ITSM Professional customer at $135/fulfiller/month, the AI add-on brings the total to approximately $200-$215/fulfiller/month. In 2026, ServiceNow is also introducing consumption-based pricing for some AI features with token caps and potential overages.

### Can I self-host ServiceNow?

No. ServiceNow is a cloud-only platform with no self-hosting or on-premises deployment option.

### What is the average ServiceNow contract value?

Public data puts the average annual contract value at approximately $130,000. This reflects a wide distribution — smaller deals in the $50,000-$100,000 range and large enterprise contracts well above $1M annually.

### What discounts can I negotiate?

Enterprise buyers routinely secure 40-50% off list prices for core ITSM modules. Newer modules like HR Service Delivery may carry discounts of 55-70%. Timing matters — end-of-quarter deals tend to carry better discounts. Start negotiations 6-12 months before contract expiration for maximum leverage.

### How does ServiceNow compare to Jira Service Management on cost?

At 50 agents, Jira Service Management Standard costs roughly $11,424/year. ServiceNow ITSM Standard at the same scale costs an estimated $42,000-$60,000/year — 4-5x more. Jira Service Management also includes a free plan (3 agents) and has a simpler implementation process. ServiceNow's advantage is depth: it handles ITOM, HR, and CSM in ways that Jira does not. The question is whether that depth justifies the cost difference for your organization.

### Is ServiceNow worth the cost?

For large enterprises with complex ITSM requirements, hundreds of agents, and the budget for proper implementation, ServiceNow is the market leader for a reason. The platform is deep, the ecosystem is mature, and it scales to very large organizations. For mid-market companies or teams with simpler requirements, the total cost of ownership — license fees, implementation, ongoing administration — may be difficult to justify when alternatives like Jira Service Management or Freshservice cover the core workflows at a fraction of the cost.

- [MCP Server for Feedback Management: A Practical Guide (2026)](https://quackback.io/blog/mcp-server-feedback-management): How MCP servers let AI agents search, triage, and manage customer feedback. A practical guide to setup and use with Quackback's open-source MCP server.

Published: 2026-03-21

AI agents are moving beyond text generation into tool use — read-write access to the systems your team uses every day. The mechanism enabling this is MCP, the Model Context Protocol, an open standard that lets AI models call external tools and query external data sources.

![MCP server connecting AI agents to feedback management](/blog/mcp-server-feedback-management/hero.webp)

> An **MCP server** for feedback management exposes your feedback tool's data and actions to AI agents through the Model Context Protocol, so any MCP-compatible client can search posts, triage requests, draft responses, detect duplicates, and create changelog entries directly from your feedback database. Quackback ships a built-in MCP server that works with clients like Claude Desktop, Cursor, and Windsurf. Setup takes minutes, and every action is logged, attributed, and reversible.

Feedback management is one of the first categories where this matters. Product teams collect hundreds of feature requests, bug reports, and suggestions. Most of that feedback sits in a board somewhere, waiting for a human to read it, categorize it, respond, and decide what to build. The bottleneck is not collecting feedback. It is processing it.

An AI agent with access to your feedback system can search across posts, detect duplicates, triage incoming requests, draft responses, and update your roadmap. Each operation completes in seconds rather than the minutes a human would spend. Every action is logged, attributed, and reversible.

This post covers what MCP is, how it works in the context of feedback management, and what you can do with [Quackback's MCP server](/features/mcp) today.

## What is MCP?

MCP stands for Model Context Protocol. Anthropic created it as an open standard for connecting AI models to external tools and data sources. Think of it as a universal adapter between an AI assistant and the software it needs to interact with.

Before MCP, connecting an AI model to an external system meant writing custom code. You would build an API integration, handle authentication, parse responses, and wire it all into your agent framework. Every tool required its own integration. Every AI client required its own connector.

MCP standardizes this. An MCP server exposes a set of tools (functions the AI can call) and resources (data the AI can read). An MCP client (the AI assistant) discovers those tools automatically and calls them when relevant. The protocol handles discovery, invocation, and response formatting.

In practice, this means you can install a single MCP server and every compatible AI assistant gets access to the same capabilities. Claude Desktop, Cursor, Windsurf, and any other MCP-compatible client can connect to the same server and use the same tools. No per-client integration work.

The protocol is open. Anthropic published the [specification](https://modelcontextprotocol.io) and reference implementations. Anyone can build an MCP server for their product. The ecosystem is growing. There are MCP servers for databases, file systems, cloud providers, and now feedback management.

## How MCP works for feedback management

![MCP server architecture diagram showing the flow from AI assistant to feedback database](/blog/mcp-server-feedback-management/mcp-architecture.webp)

The flow is straightforward. Here is what happens when you ask your AI assistant a question about your feedback:

1. **You ask a question.** In Claude Desktop, Cursor, or any MCP-compatible client, you type something like "What are the top feature requests about performance?" or "Triage the feedback that came in today."

2. **The assistant discovers available tools.** When the MCP server is connected, the assistant knows it can search posts, read feedback details, create responses, update statuses, merge duplicates, and more. It picks the right tool based on your request.

3. **The assistant calls the MCP server.** The server receives the tool call with parameters (search query, filters, post IDs) and executes it against your feedback database. Authentication is handled at the server level, so the assistant never sees raw credentials.

4. **The server returns results.** Structured data comes back: a list of matching posts with their vote counts, statuses, tags, and comments. Or a confirmation that an action was completed.

5. **The assistant processes the results.** It can summarize what it found, suggest next steps, or take further actions. If you asked it to triage, it might categorize each post, assign tags, and set statuses in a single pass. If you asked it to find duplicates, it might identify clusters and propose merges.

6. **You review and confirm.** Depending on your setup, some actions happen automatically and some require approval. Either way, every action is logged with the agent's identity so your team knows what happened and who (or what) did it.

This is not a chatbot. It is an agent with tool access. The distinction matters. A chatbot generates text. An agent takes actions. When your AI assistant has MCP access to your feedback system, it can read and write data, not just talk about it.

## What Quackback's MCP server can do

Quackback ships with a built-in MCP server. You do not need to install a separate package or configure a third-party integration. The server exposes the full feedback management workflow to any MCP-compatible AI client.

Here is what it covers:

### Search feedback

Find posts by keyword, status, tag, board, or semantic similarity. The search is fast and flexible. You can ask your agent to find "all open requests about SSO" or "feedback mentioning slow load times" and get structured results with vote counts, statuses, and timestamps.

This replaces the manual workflow of opening your [feedback board](/features/feedback), applying filters, and scanning through results. The agent does it in one call.

### Triage requests

Incoming feedback often needs categorization before it is useful. The MCP server lets your agent assign tags, set statuses, move posts between boards, and add internal notes. You can set up your agent to triage every new post that arrives in your [inbox](/features/inbox), categorizing it by topic, urgency, and team.

A single prompt like "Triage everything in the inbox" can process dozens of posts in seconds. Each post gets categorized, tagged, and routed to the right board. Your team starts their day with a clean, organized queue instead of an unsorted pile.

### Write responses

Drafting responses to feedback takes time, especially when you need to acknowledge the request, explain your current thinking, and set expectations. The MCP server lets your agent draft and post responses directly.

You stay in control. You can have the agent draft responses for your review before posting, or let it post routine acknowledgments automatically. Either way, users get faster responses and your team spends less time on repetitive writing.

### Detect duplicates

Duplicate feedback is one of the biggest time sinks in feedback management. The same request gets submitted five different ways by five different users. Each version has slightly different wording, so keyword search does not catch them all.

The MCP server combines keyword and semantic search to find similar posts. Your agent can identify clusters of related feedback and propose merges with reasoning. When posts are merged, votes are consolidated and all subscribers get notified. No feedback is lost.

### Create changelog entries

When you ship a feature, you need to close the loop with the users who requested it. That means writing a [changelog](/features/changelog) entry, updating the status of related feedback posts, and notifying voters.

Your agent can draft changelog entries based on the feedback posts linked to a shipped feature. It pulls in context from the original requests, summarizes what was built, and prepares the entry for your review. After publishing, voters are automatically notified that their request was addressed.

### Manage roadmap

The MCP server can update items on your [roadmap](/features/roadmap), change statuses, and link feedback posts to roadmap items. When you move a feature from "Planned" to "In Progress," the agent can update every linked feedback post simultaneously.

### Attribution and auditability

Every action taken through the MCP server is attributed to the agent that performed it. Your team can see a clear audit trail: what was changed, when, and by whom. If an agent triages a post incorrectly, you can see exactly what it did and reverse it.

### Current limitations

MCP is an emerging standard. The ecosystem is growing but not yet universal. Your AI client must support MCP — as of early 2026, that includes Claude Desktop, Claude Code, Cursor, VS Code, and Windsurf. Agent quality depends on the underlying model. Complex triage decisions may require human review. Bulk operations (triaging hundreds of posts at once) work but can be slow depending on the model's context window and rate limits.

For a full overview of these capabilities, see the [MCP feature page](/features/mcp).

## Setting up the MCP server

Setup takes a few minutes. The MCP server is a built-in HTTP endpoint at `/api/mcp` on your Quackback instance. You configure your AI client to point at it, and you are ready to go. No separate package to install.

Quackback supports two authentication methods: OAuth (browser-based login flow) and API keys (for CI/programmatic use). Here is an example configuration for Claude Code using OAuth:

```json
{
  "mcpServers": {
    "quackback": {
      "type": "http",
      "url": "https://your-instance.example.com/api/mcp"
    }
  }
}
```

For Cursor or Windsurf, use an API key instead. Generate one from Settings > Developers in your admin panel (keys use a `qb_` prefix):

```json
{
  "mcpServers": {
    "quackback": {
      "url": "https://your-instance.example.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ${env:QUACKBACK_API_KEY}"
      }
    }
  }
}
```

The configuration varies slightly by client. Quackback's admin panel at Settings > Developers > MCP Server shows ready-to-copy configs for Claude Code, Cursor, VS Code, Windsurf, and Claude Desktop.

For full setup instructions, including self-hosted configurations and advanced options, see the [documentation](/docs).

## Use cases

The MCP server is a general-purpose interface. You can use it however fits your workflow. Here are four scenarios product teams are using today.

### Engineering standup

Monday morning. Your team wants to know what users reported over the weekend. Instead of opening the feedback board, scrolling through posts, and summarizing themes manually, you ask your AI assistant:

"What feedback came in this week about performance?"

The agent searches your feedback for performance-related posts from the past seven days, returns a summary with vote counts and sentiment, and highlights anything urgent. Your standup stays focused on what matters.

### Product review

You are preparing for a quarterly planning session. You need to know where user demand is highest. Ask your agent:

"Summarize the top 10 feature requests by votes."

You get a ranked list with vote counts, key quotes from users, and the current status of each request. No spreadsheets. No manual data pulling. The information is current as of the moment you ask.

### Support handoff

A user reported a bug two weeks ago. Your team fixed it in the latest release. Now you need to let them know. Ask your agent:

"Draft a response to the bug report about CSV export errors, explaining that the fix ships in v2.4 this Thursday."

The agent finds the post, drafts a response with the right context and timeline, and either posts it directly or holds it for your review. The user gets a specific, helpful response instead of a generic "we'll look into it."

### Release prep

You just finished a sprint and shipped four features. Each one was linked to feedback posts from your users. Ask your agent:

"Create a changelog entry for everything we shipped this sprint."

The agent pulls the linked feedback posts, summarizes what was built and why, drafts a changelog entry, and prepares it for publishing. After you review and publish, every user who voted on those features gets notified automatically.

## Why this matters

Feedback management has always been a manual process. Someone reads every post, decides what it means, tags it, responds to it, and eventually closes the loop when the feature ships. This work is important, but it is repetitive. And the more feedback you collect, the more time it consumes.

MCP changes the economics. An AI agent with tool access can handle the repetitive parts (searching, categorizing, detecting duplicates, drafting responses) while your team focuses on the decisions that require human judgment. Which features to prioritize. What trade-offs to make. How to communicate your roadmap.

This is not about replacing product managers. It is about reducing the time spent on categorization, duplicate detection, and routine responses — work that is necessary but repetitive. A team that processes feedback faster can close the loop with users sooner. Duplicates get caught before votes fragment across multiple posts. Shipped features get announced to the users who requested them.

The combination of AI agents and structured feedback data creates a tighter feedback loop. Users submit requests. Agents triage them. Your team reviews the organized queue. You build. Agents draft the changelog. Users get notified. The cycle runs with less manual overhead at each step.

If you want to see this in practice, [Quackback's MCP server](/features/mcp) is available today. It is open source, self-hostable, and works with any MCP-compatible AI client. The MCP server runs the same way on the managed [Quackback Cloud](/pricing) and on self-hosted instances — no add-on tier and no per-use charge either way. You can also explore how AI enhances other parts of the feedback workflow in our post on [AI-powered customer feedback analysis](/blog/ai-customer-feedback-analysis), or compare [feedback tools](/blog/best-customer-feedback-tools-2026) to find the right fit for your team.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is an MCP server in the context of customer feedback?

An MCP server is a small program that exposes your feedback tool's data and actions to AI agents through the Model Context Protocol. Instead of writing custom API code for each AI assistant, the server declares tools like search, triage, and respond. Any MCP-compatible agent can then read posts, update statuses, and draft replies directly from your feedback database. Quackback ships with a built-in MCP server, so you do not need to install or host a separate service.

### How does an MCP server differ from a traditional API integration for feedback tools?

An MCP server standardizes into one protocol what a traditional API integration handles with custom code per client: authentication, request shaping, response parsing, and wiring. Point any MCP-compatible client at the server URL and it discovers the available tools automatically. One MCP server replaces a separate integration per AI client.

### Do I need a specific AI client to use the MCP server?

No. The MCP server works with any client that supports the Model Context Protocol. As of early 2026 that includes Claude Desktop, Claude Code, Cursor, VS Code, and Windsurf, with new clients adding support regularly. Because MCP is an open standard, you are not locked into a single AI provider.

### Can the AI agent make changes without approval?

That depends on how you configure it. You can grant full write access for automatic triage, responses, and merges, or require human review on drafted actions. Quackback's MCP server supports OAuth and scoped API keys, so you can limit agents to read-only access or specific boards. Every action is logged.

### Is the MCP server available on the self-hosted version?

Yes. The MCP server ships with every Quackback instance, including self-hosted deployments. There is no separate license, no add-on tier, and no per-use charge from Quackback. You run the server alongside your existing instance and generate an API key from the admin panel. See the [docs](/docs) for setup instructions.

- [AI Customer Feedback Analysis in 2026](https://quackback.io/blog/ai-customer-feedback-analysis): How AI is transforming customer feedback analysis. Sentiment analysis, duplicate detection, topic clustering, and AI agents for feedback management.

Published: 2026-03-20

Your users are giving you more feedback than ever. Feature requests come in through support tickets, Slack messages, in-app widgets, email, sales calls, and public review sites. A product with 1,000 active users can easily generate hundreds of feedback items per month. A product with 10,000 users generates thousands.

![AI analyzing and categorizing customer feedback](/blog/ai-customer-feedback-analysis/hero.webp)

Most teams handle this manually. Someone reads each post, tags it, checks if it's a duplicate, routes it to the right team, and updates the status. That process works at 50 posts per month. It breaks at 500. At 5,000, it's impossible without a dedicated team.

AI changes the math. Not by replacing the humans who make product decisions, but by handling the repetitive work that prevents those humans from getting to the decisions in the first place. Sorting, tagging, deduplicating, summarizing, routing — these are tasks where AI is reliably good and getting better. The judgment calls (what to build, what to defer, what to say no to) still belong to your team.

Here's what AI can actually do with customer feedback today, how the major tools implement it, and what to look for when evaluating AI-powered feedback analysis.

## What AI can do with customer feedback

![AI feedback analysis capabilities: sentiment, duplicates, clustering, summaries, routing](/blog/ai-customer-feedback-analysis/ai-capabilities.webp)

AI capabilities in feedback tools fall into five categories. Each solves a specific bottleneck in the feedback workflow.

### Sentiment analysis

Sentiment analysis classifies feedback as positive, negative, or neutral. Modern implementations go beyond simple polarity. They detect frustration, urgency, and satisfaction levels within individual posts.

This matters for triage. A feature request from a happy customer exploring new use cases is different from the same request from a frustrated customer considering alternatives. Sentiment data lets you prioritize not just by what users want, but by how they feel about the current state.

Automated sentiment analysis runs on every post as it comes in. No manual tagging required. Your team sees a sentiment breakdown across all feedback at a glance, and can filter to surface the most frustrated users first.

The limitation: sentiment models work well on clear, direct feedback. They struggle with sarcasm, cultural nuance, and context-dependent language. A post saying "great, another update that breaks my workflow" is negative, but a naive model might flag "great" as positive. Modern LLM-based sentiment analysis handles these cases better than older keyword-based approaches, but it's not perfect.

### Duplicate detection

Duplicate feedback is one of the biggest time sinks in feedback management. Users don't search before posting. They describe the same problem in different words. "Add dark mode," "please support dark theme," "the app is too bright at night," and "need a night mode option" are all the same request.

Without AI, someone on your team has to catch these manually. That means reading every new post, remembering (or searching for) similar ones, and merging them. At scale, duplicates pile up. You end up with 15 posts about the same feature, each with a handful of votes, instead of one post with the true demand signal.

AI duplicate detection compares new submissions against your existing feedback using semantic similarity, not just keyword matching. It understands that "dark mode" and "the app is too bright at night" are related even though they share no words. When a match is found, the system suggests a merge. Your team reviews the suggestion and accepts or dismisses it in one click.

The result: cleaner boards, accurate vote counts, and a true picture of what your users want most.

### Topic clustering

Topic clustering groups feedback into themes automatically. Instead of maintaining a manual taxonomy of tags and hoping your team applies them consistently, AI identifies natural groupings in your feedback data.

You might discover that 30% of recent feedback relates to mobile experience, 20% is about integrations, and 15% is about pricing. These clusters update as new feedback arrives. You see emerging themes before they become obvious.

This is particularly useful for quarterly planning. Instead of reading through hundreds of posts to identify patterns, you get a structured view of what your users care about, broken down by theme, with the volume and sentiment of each cluster.

The caveat: clustering quality depends on volume. With fewer than 50 posts, the clusters may be noisy or too broad. The feature gets more useful as your feedback grows.

### Summarization

Long feedback threads are hard to process. A popular feature request might have 40 comments from different users, each adding context, use cases, or workarounds. Reading and synthesizing all of that takes time.

AI summarization generates concise overviews of feedback threads. A good summary includes the core request, the main arguments for and against, key quotes from users, and any suggested solutions. Your product manager gets the substance of a 40-comment thread in a paragraph.

This is useful for stakeholder communication. When your CEO asks "what are users saying about X," you can share a generated summary with key quotes instead of a link to a long thread.

### Smart routing

Smart routing uses content analysis to send feedback to the right team automatically. A bug report about the billing system goes to the payments team. A feature request about API endpoints goes to the platform team. A complaint about onboarding goes to the growth team.

This replaces the manual triage step where someone reads each post and decides who should see it. Routing rules based on keywords are brittle — they miss posts that describe the problem without using the expected terms. AI-based routing understands intent, not just keywords.

Smart routing works best when combined with your existing tools. Feedback about infrastructure can create a Linear issue for the platform team. Feedback about UX can notify the design channel in Slack. The feedback doesn't just get categorized — it gets to the right people.

## AI feedback tools compared

Most feedback tools have added AI features in the past two years. The implementations vary significantly in scope, pricing, and approach.

### Quackback

[Quackback](https://quackback.io) is open source (AGPL-3.0) and connects to any OpenAI-compatible provider — OpenAI, Azure OpenAI, Cloudflare AI Gateway, or any compatible service.

The AI capabilities include duplicate detection with merge suggestions, sentiment analysis on every post, and [post summaries](/features/feedback) with key quotes and next steps. When the system detects a potential duplicate, it shows the reasoning so your team can make an informed decision.

What makes Quackback distinct is the [MCP server](/features/mcp). It implements the Model Context Protocol, which lets AI agents in Claude, Cursor, and Windsurf interact with your feedback directly. More on that in the next section.

Because Quackback is open source and self-hostable, your feedback data and the AI that processes it stay under your control.

### Canny Autopilot

Canny's AI suite, Autopilot, focuses on feedback discovery from support conversations. It monitors conversations in Intercom, Zendesk, Help Scout, Gong, and 10 public review sites, then extracts feature requests and links them to existing posts on your board.

Autopilot also generates smart replies to prompt users for clarification and summarizes comment threads. Credits were initially capped but are now uncapped on all plans.

The strength of Canny's approach is capturing feedback that would otherwise stay buried in support tickets. The limitation is that Autopilot operates within Canny's UI — there's no way for external agents or tools to interact with it programmatically beyond the standard API. For a broader comparison, see [Quackback vs Canny](/compare/quackback-vs-canny).

### Productboard AI

Productboard includes AI via a credits system on the Spark plan ($15/maker/month annual or $19/maker/month monthly). Each maker gets 250 credits per month. The AI features include insight extraction from support tickets, semantic search across feedback, auto-linking of related insights, and summarization.

The focus is on connecting customer feedback to product strategy — identifying patterns across hundreds of notes and linking them to features in your product hierarchy. This fits Productboard's positioning as a product management platform rather than a standalone feedback tool.

The trade-off is credit limits. A team of five makers gets 1,250 credits per month. Teams that process high volumes of feedback may find this constraining. See [Quackback vs Productboard](/compare/quackback-vs-productboard) for a full breakdown.

### Comparison table

| Capability | Quackback | Canny | Productboard |
|---|---|---|---|
| **Sentiment analysis** | Included | Limited | Included via credits (250/maker/mo) |
| **Duplicate detection** | Included | Autopilot (discovers related feedback) | No |
| **Summarization** | Included | Autopilot (uncapped) | Included via credits (250/maker/mo) |
| **Feedback discovery** | Via [inbox](/features/inbox) | Autopilot (support + review sites) | From support tickets |
| **AI agent access (MCP)** | Yes | No | No |
| **Pricing model** | Open source, self-hostable | Included in plan | Included via credits (250/maker/mo) |
| **Merge suggestions** | Yes, with reasoning | No | No |

## AI agents in feedback management

AI agents represent a new category in feedback tooling. Instead of AI features embedded within a product's UI, agents are autonomous programs that interact with your tools through standardized protocols.

The [Model Context Protocol (MCP)](https://modelcontextprotocol.io) is the standard that makes this possible. MCP defines how AI agents connect to external tools and data sources. Think of it as a universal API for AI agents. Claude, Cursor, and Windsurf all support MCP natively.

Quackback's [MCP server](/features/mcp) is an early implementation of this protocol in the feedback tool category. When you connect an AI agent to a feedback tool via MCP, the agent can:

- **Search feedback** — Query your board by keyword, status, sentiment, or topic. The agent understands natural language queries like "find all frustrated users asking about API improvements."
- **Triage requests** — Categorize incoming feedback, assign tags, and update statuses based on content analysis.
- **Write responses** — Draft responses to feature requests. Your team reviews and approves before publishing.
- **Create changelog entries** — When a feature ships, the agent can draft a changelog post referencing the feedback that drove it.
- **Merge duplicates** — Identify and merge duplicate posts with attribution.

The practical requirement for any MCP-based agent workflow is auditability. Every action should be logged and attributed so your team can see what the agent did, when, and why. Look for tools that treat agent actions as suggestions for human review, not autonomous decisions.

The practical impact: your team spends less time on administrative feedback tasks and more time on product decisions. An agent can process a backlog of 200 unreviewed posts in minutes, surfacing the ones that need human attention and handling the routine triage automatically. The results still vary — agents work well on straightforward categorization and duplicate detection, but struggle with ambiguous requests that require product context to interpret correctly.

This is early. MCP was released in late 2024 and adoption is still growing. The pattern is promising — AI agents that operate across your tools have the potential to be more useful than AI features locked inside a single product. But the tooling is still maturing. Expect rough edges, especially around error handling and multi-step workflows.

## BYOK vs vendor-controlled AI

There are two approaches to AI in feedback tools. Each has real trade-offs.

**Bring your own key (BYOK)** is one approach. You provide an API key from your LLM provider (OpenAI, Azure OpenAI, or any OpenAI-compatible service), and AI features use your key directly. You pay your provider at their rates.

**Vendor-controlled AI** is the model most other tools use. Canny, Productboard, and Featurebase run AI on their infrastructure and charge you for it, either through add-on pricing, per-use credits, or by bundling it into higher-tier plans.

### Advantages of BYOK

- **Cost transparency.** You see exactly what each API call costs. No markup.
- **Provider choice.** Switch between OpenAI, Azure, or other compatible providers based on performance, cost, or compliance requirements.
- **No vendor lock-in on AI.** If a better model comes out, you point your key at it. You're not waiting for the feedback vendor to upgrade.
- **Data control.** Your feedback data goes to the LLM provider you choose, under the terms you've agreed to. Not through an intermediary.
- **No usage caps.** No credit system, no tier limits. Run as much analysis as you need.

### Advantages of vendor-controlled AI

- **Simpler setup.** No API key to configure. AI features work out of the box.
- **Optimized prompts.** The vendor can tune prompts and post-processing for their specific data model. They control the full pipeline.
- **No separate billing.** One invoice for everything.
- **Potentially better integration.** When the vendor controls both the AI and the product, they can build tighter loops (like Canny's Autopilot discovering feedback from support conversations).

### Which is better?

For most teams, BYOK wins on cost and flexibility. OpenAI API pricing has dropped significantly — a typical feedback analysis call costs fractions of a cent. Credit-based AI (Productboard's 250 credits per maker per month) or per-resolution fees (Featurebase at $0.49 each) for the same underlying capability can add up, especially at scale.

Vendor-controlled AI makes more sense when the vendor is doing something proprietary that requires deep integration with their data model. Canny's Autopilot, which scans support conversations across multiple platforms to discover feedback, is a good example. That workflow requires infrastructure the vendor maintains.

The ideal is BYOK for standard analysis tasks (sentiment, duplicates, summaries) and vendor-specific AI for workflows that genuinely require it. If you're evaluating tools and data ownership matters, see our guide to [open source feedback tools](/blog/open-source-feedback-tools) — most open source options use BYOK or let you run models locally.

## Getting started with AI feedback analysis

If your team is still processing feedback manually, here's how to introduce AI without disrupting your existing workflow.

**Step 1: Centralize your feedback.** AI works best on structured data. If your feedback is scattered across Slack threads, emails, and spreadsheets, consolidate it into a single tool first. A [feedback board](/features/feedback) with an [inbox](/features/inbox) gives AI something to work with.

**Step 2: Start with duplicate detection.** This delivers the most immediate value. Duplicate posts are the biggest source of noise in any feedback board. Turn on duplicate detection, let it surface matches for a week, and review the suggestions. Most teams find 15-30% of their existing posts are duplicates.

**Step 3: Add sentiment analysis.** Once duplicates are merged, sentiment analysis gives you a clearer picture of user satisfaction across topics. Filter by negative sentiment to find the areas causing the most frustration.

**Step 4: Use summaries for stakeholder communication.** Generate summaries of your top feature requests and share them in product reviews. This saves the "let me pull together the feedback on X" step that delays decisions.

**Step 5: Explore AI agents.** If you are already using Claude, Cursor, or Windsurf, check whether your feedback tool supports MCP. Start with read-only access (searching and summarizing feedback) before enabling write actions (triaging, responding).

**Step 6: Measure the impact.** Track how long feedback sits before triage, how many duplicates are caught, and how often your team references AI-generated summaries. These metrics tell you whether AI is saving time or just adding another tool to manage.

## Frequently asked questions

### Is AI accurate enough for customer feedback analysis?

For structured tasks like sentiment classification and duplicate detection, modern LLMs are reliable. Sentiment analysis accuracy on clear, direct feedback typically exceeds 90%. Duplicate detection with semantic similarity catches matches that keyword-based search misses entirely. Summarization quality is high for factual, straightforward threads. Where AI falls short is nuance — sarcasm, cultural context, and domain-specific jargon can trip up any model. The practical approach is to use AI for the first pass and have your team review the output. Most feedback tools present AI results as suggestions, not final decisions.

### How much does AI feedback analysis cost?

It depends on the pricing model. Some tools, including [Quackback](https://quackback.io), connect to your own LLM provider, so a sentiment or duplicate check costs fractions of a cent. With vendor-controlled AI, costs are higher: Productboard includes 250 AI credits per maker per month, and Featurebase charges $0.49 per AI resolution.

### Can AI replace my product manager for feedback triage?

No. AI handles the mechanical parts of triage well: detecting duplicates, classifying sentiment, routing to the right team, and generating summaries. These are pattern-matching tasks. What AI cannot do is make product judgment calls — deciding whether a feature request aligns with your strategy, weighing trade-offs between competing requests, or understanding the political context of feedback from a key account. AI reduces the time your product manager spends on administrative triage so they can spend more time on decisions that require human judgment. The best [feedback tools](/blog/best-customer-feedback-tools-2026) present AI output as suggestions for human review, not autonomous actions. For tools that support AI agents via MCP, every agent action is logged and attributable, giving your team full oversight of what the AI did and why.

- [Canny vs UserVoice: Which Feedback Tool Is Right for You?](https://quackback.io/blog/canny-vs-uservoice): A neutral comparison of Canny and UserVoice in 2026. Features, pricing, target audience, and when to consider an open-source, self-hosted alternative.

Published: 2026-03-19

Canny and UserVoice both help product teams collect feature requests, prioritize what to build, and close the loop with customers. They cover the same category but target different segments of the market.

![Canny vs UserVoice comparison with Quackback as alternative](/blog/canny-vs-uservoice/hero.webp)

> Canny is a mid-market feedback tool with a free plan (25 tracked users) and paid tiers from $19/mo. UserVoice is an enterprise platform starting at $16,000/year (~$1,333/mo) with revenue-linked prioritization and NLP analytics. If you want an open-source alternative with no vendor lock-in, [Quackback](https://quackback.io) is free to self-host and offers a managed cloud option.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

Canny is built for mid-market SaaS teams. It offers a self-service signup, a lower starting price, and a product that's designed to get running in a day. UserVoice is built for enterprise product organizations. It leads with revenue-linked prioritization, NLP-powered feedback analysis, and deep CRM integrations. The starting price is $16,000 per year (~$1,333/mo) with annual billing.

If you're choosing between the two, the decision comes down to your team size, budget, how much analytics you need, and whether you want a tool you can start using this afternoon or one that takes weeks to onboard.

This guide compares Canny and UserVoice across features, pricing, and ideal use cases. It also covers where an open-source alternative like [Quackback](/compare/quackback-vs-canny) fits in for teams that want to avoid vendor lock-in entirely.

## Canny overview

[Canny](/compare/quackback-vs-canny) launched in 2017 and has become one of the most widely used hosted feedback tools for SaaS companies. The core product covers feature request boards with voting, a public roadmap, changelogs, and an AI feature called Autopilot that discovers feedback from support conversations.

### Pricing

In May 2025, Canny overhauled its pricing model. The company moved from per-admin billing to tiered pricing based on tracked users. A tracked user is anyone who posts, votes, or comments on your feedback board. Canny offers a free plan (25 tracked users, limited features) but most teams outgrow it quickly. For a detailed breakdown, see our [Canny pricing analysis](/blog/canny-pricing).

The current plans:

- **Free** — $0/mo for 25 tracked users, 5 managers. Autopilot AI included.
- **Core** — $19/mo (billed annually) for 100+ tracked users, 5 managers. Custom domains, content translations.
- **Pro** — $79/mo (billed annually) for 100+ tracked users, 10 managers. PM integrations (Jira, ClickUp, Linear), advanced privacy.
- **Business** — Custom pricing for 5,000+ tracked users. SSO/SAML, CRM integrations, white-label, dedicated support.

At scale, costs increase as you exceed tracked user limits and get auto-upgraded to the next tier. Tracked users accumulate over time. Someone who voted once six months ago still counts.

### Strengths

**Fast setup.** You can create a Canny workspace, embed your first feedback board, and start collecting votes in under an hour. No sales calls required for the free, Core, and Pro plans.

**Clean product design.** Canny's interface is polished and intuitive. Feature request boards, voting, and status updates work well with default settings. The roadmap view gives users a clear picture of what's planned, in progress, and shipped.

**Autopilot AI.** Canny's Autopilot scans support conversations from tools like Intercom and Zendesk, identifies feature requests, and attributes them to the correct users. This saves product managers from manually reviewing support tickets for feedback signals.

**Good integration ecosystem.** Canny integrates with Slack, Jira, Linear, GitHub, Intercom, Zendesk, HubSpot, and several others. On the Pro plan and above, PM integrations like Jira and Linear are available.

### Weaknesses

**Tiered tracked-user pricing can surprise you.** Your costs increase when you cross tracked user thresholds, triggering auto-upgrades to the next tier. You can set spend caps to prevent this, but a viral feature request can push you across a threshold quickly.

**No self-hosting.** Canny is a hosted SaaS product. You can't run it on your own infrastructure, audit the code, or fork it if the product direction changes.

**SSO requires the Business plan.** If your organization mandates SAML SSO for compliance, you need the Business plan (custom pricing).

**Free plan is very limited.** Canny's free plan caps at 25 tracked users. The Core plan at $19/mo provides 100+ tracked users but PM integrations like Jira require the Pro plan at $79/mo.

**No open-source option.** If Canny raises prices (which it did in 2025), you absorb the increase or migrate. There's no way to self-host as a hedge. For more on alternatives, see [best Canny alternatives](/blog/best-canny-alternatives).

## UserVoice overview

[UserVoice](/compare/quackback-vs-uservoice) launched in 2008 and is one of the original customer feedback platforms. It helped define the category. In 2026, it positions itself as an enterprise product management tool with a focus on revenue-linked prioritization and NLP-powered analytics.

### Pricing

UserVoice is the most expensive standalone feedback tool on the market. There is no free plan and no self-service signup. You "Talk to an Expert," negotiate a contract, and commit to annual billing. A 30-day free trial is available. For a full pricing breakdown, see our [UserVoice pricing analysis](/blog/uservoice-pricing).

The current pricing:

- **Starting at $16,000/year** (~$1,333/mo). Custom pricing based on monthly feedback volume and integrations.
- **No per-seat charges** — anyone in your organization can access the platform.
- **Annual billing** with a sales process required.
- **30-day free trial** available after engaging with sales.

Annual costs start at $16,000 and scale higher based on volume, integrations, and enterprise requirements. UserVoice does not publish this figure on its pricing page; the $16,000/year entry point is widely reported from sales quotes, so your negotiated number may differ.

### Strengths

**Revenue-linked prioritization.** UserVoice connects to Salesforce and HubSpot and lets you see which feature requests have the most ARR behind them. Product managers can sort and filter requests by revenue impact, not just vote count. This is the feature that justifies UserVoice's price for many enterprise teams.

**NLP-powered feedback analysis.** On the Premium plan, UserVoice uses natural language processing to surface themes across thousands of feedback submissions. It groups related requests, detects sentiment patterns, and generates reports that help product teams see the bigger picture without reading every post.

**Internal feedback capture.** UserVoice provides structured workflows for sales and support teams to submit feedback on behalf of customers. Contributors can tag requests with account context, deal stage, and priority level. This keeps product managers informed without requiring them to sit in on customer calls or read support transcripts.

**Enterprise compliance features.** SSO/SAML, advanced permissions, audit logs, and SLA-backed uptime guarantees are available on the Enterprise plan. For organizations in regulated industries, these capabilities are non-negotiable.

### Weaknesses

**High entry price.** At $16,000/year (~$1,333/mo) with annual billing, UserVoice is sized for enterprise budgets. Startups and smaller teams will find it out of range. A 30-day free trial is available, but the jump to paid is steep.

**Longer onboarding.** UserVoice deployments typically take weeks. Sales calls, contract negotiation, account configuration, SSO setup, CRM integration, and user training are part of the process. This is typical for enterprise software but slower than self-service tools.

**Older interface design.** The UI has improved over the years but still feels less modern than Canny or newer alternatives. Product teams accustomed to tools like Linear or Notion may notice the difference.

**No self-hosting.** UserVoice is hosted only. Your data lives on their infrastructure. There is no open-source version, no data portability guarantee beyond standard export, and no way to run it on-premises. For alternatives, see [best UserVoice alternatives](/blog/best-uservoice-alternatives).

**SSO availability unclear.** UserVoice lists security and compliance as a feature, but the current pricing page does not break down which capabilities require higher-tier plans. Historically, SAML SSO required an enterprise-level contract.

## Feature comparison

| Feature | Canny | UserVoice | Quackback |
|---------|-------|-----------|-----------|
| **Feedback boards** | Yes | Yes | Yes |
| **Voting** | Yes | Yes | Yes |
| **Public roadmap** | Yes | Yes | Yes |
| **Changelog** | Yes | No | Yes |
| **AI duplicate detection** | Autopilot (related feedback) | No | Yes |
| **AI merge suggestions** | No | No | Yes |
| **Sentiment analysis** | No | Yes (NLP, Premium+) | Yes |
| **Revenue-linked prioritization** | No | Yes (Premium+) | No |
| **NLP theme detection** | No | Yes (Premium+) | No |
| **SmartVote surveys** | No | Yes (Premium+) | No |
| **Autopilot (support scanning)** | Yes | No | No |
| **MCP server for AI agents** | No | No | [Yes](/features/mcp) |
| **SSO/SAML** | Business (custom pricing) | Included (security/compliance) | Free self-hosted · Enterprise on Cloud |
| **Custom branding** | Business (custom pricing) | All plans | Included free |
| **Self-hosting** | No | No | Yes (Docker) |
| **Open source** | No | No | Yes (AGPL-3.0) |
| **Integrations** | 15+ | 10+ | [20+](/integrations) |
| **API** | Yes | Yes | [Yes](/features/api) |
| **Slack integration** | Yes | Yes | Yes |
| **Jira integration** | Pro ($79/mo)+ | Yes | Yes |
| **Salesforce integration** | Business (custom pricing) | Yes | Yes |

Canny and UserVoice each have capabilities the other lacks. Canny's Autopilot scans support conversations for feedback signals. UserVoice's NLP groups thousands of feedback submissions into themes and ties them to revenue data. [Quackback](/compare/quackback-vs-uservoice) takes a different approach: open source, self-hosted, with AI features like duplicate detection, merge suggestions, and an [MCP server](/features/mcp) that lets AI agents interact directly with your feedback data.

## Pricing comparison

| | Canny | UserVoice | Quackback |
|---|---|---|---|
| **Free plan** | Yes (25 tracked users) | No (30-day trial available) | Yes (self-hosted, unlimited) |
| **Entry price** | Free (25 tracked users), $19/mo (Core) | $16,000/yr (~$1,333/mo) | $0 |
| **Mid-tier** | $79/mo (Pro) | Custom (volume-based) | $0 |
| **Enterprise** | Custom pricing (Business) | Custom | $0 |
| **Billing model** | Tiered by tracked users | Annual (no per-seat charges) | None |
| **Minimum commitment** | None (monthly billing) | $16,000/yr | None |
| **Annual cost (entry)** | $1,188–4,800/yr | $16,000+/yr | $0 |
| **SSO cost** | Business (custom pricing) | Included | Included |
| **AI cost** | Included on all plans | Included | Included |

The pricing gap between Canny and UserVoice is significant. Canny's Pro plan at $79+/mo covers what most mid-market teams need. UserVoice starts at $16,000/year. Over a year, a team paying $79/mo for Canny Pro spends $948. The same team on UserVoice would spend $16,000 or more.

The question is whether UserVoice's enterprise analytics justify the price premium. For teams with large Salesforce deployments and thousands of feedback submissions per month, the answer may be yes. The lack of per-seat charges is a plus for large organizations. For everyone else, it's hard to make the math work.

## When to choose Canny

Canny is the better choice if your team fits this profile:

**You're a mid-market SaaS company.** Your team has 5–50 people. You have a product manager (or a few) who needs to collect feedback, prioritize requests, and share a roadmap. You don't need revenue-linked prioritization tied to Salesforce opportunity data.

**You want self-service setup.** You want to sign up, configure your workspace, and start collecting feedback today. Not next month after a series of sales calls and an onboarding process.

**Your budget is under $500/mo.** Canny's Pro plan covers most needs for teams with moderate feedback volume. If you need SSO, the Business plan (custom pricing) is still a fraction of UserVoice's entry price.

**You value Autopilot.** If your team gets a lot of feedback buried in support conversations (Intercom, Zendesk, Help Scout), Canny's Autopilot can surface feature requests automatically. UserVoice doesn't offer an equivalent feature.

**You want a polished, modern interface.** Canny's product design is clean and well-maintained. The voting experience for end users is straightforward. If user experience matters to your team (and it should), Canny delivers a more modern feel than UserVoice.

## When to choose UserVoice

UserVoice is the better choice if your team fits this profile:

**You're an enterprise product organization.** Your company has 200+ employees. You have multiple product managers, a product operations team, or a dedicated feedback analyst. The volume of feedback you receive justifies a tool that can process thousands of submissions with NLP.

**Revenue-linked prioritization is critical.** Your product decisions are tied to revenue impact. You use Salesforce or HubSpot, and you need to know which feature requests carry the most ARR. Sorting by vote count isn't sufficient. You need to sort by revenue at risk.

**You need NLP-powered analytics.** Your feedback volume is high enough that no human can read every submission. UserVoice's NLP groups related requests into themes, identifies sentiment trends, and generates reports. This saves product managers hours of manual categorization per week.

**Internal feedback capture matters.** Your sales and support teams are a primary source of customer feedback. You need a structured system where account executives and support agents can submit feature requests with account context, deal size, and urgency, without the overhead of ad hoc Slack messages to the product team.

**You have enterprise compliance requirements.** Your organization requires SAML SSO, audit logging, SLA-backed uptime, and dedicated support. UserVoice's Enterprise plan covers these needs. The price is steep, but for regulated industries, it may be the cost of doing business.

## Consider Quackback if...

Neither Canny nor UserVoice is open source. Neither offers self-hosting. Both charge monthly fees that increase as your usage grows. If any of the following matter to your team, [Quackback](https://quackback.io) is worth evaluating.

**You want to own your data.** Quackback is self-hosted. Your feedback data lives in your PostgreSQL database, on your infrastructure. No third-party vendor stores, processes, or has access to your customer feedback. If you leave Quackback, your data stays right where it is.

**You want no vendor lock-in.** Quackback is open source under AGPL-3.0. You can read every line of code, fork the project, and modify it to fit your workflow. If the project's direction changes, you're not stranded. With Canny or UserVoice, a pricing change or feature removal means you either accept it or migrate.

**You want to minimize feedback tooling costs.** Quackback is free to self-host. There is no minimum contract. You deploy with Docker and you are running. The AI features (duplicate detection, merge suggestions, sentiment analysis, post summaries) are included on every self-hosted installation.

**You want AI agent access to your feedback.** Quackback's [MCP server](/features/mcp) implements the Model Context Protocol. Connect Claude, Cursor, or Windsurf and your AI agent gets structured access to search posts, triage requests, write responses, create changelog entries, and merge duplicates. No other feedback tool offers this.

**You need SSO without paying enterprise prices.** Canny requires the Business plan (custom pricing) for SSO. UserVoice requires a $16,000+/year contract. Quackback includes SSO/OIDC free on every self-hosted installation, and on Quackback Cloud it is a listed self-serve price rather than a custom contract.

For direct comparisons, see [Quackback vs Canny](/compare/quackback-vs-canny) and [Quackback vs UserVoice](/compare/quackback-vs-uservoice). For a broader look at the open-source feedback landscape, see [open-source feedback tools](/blog/open-source-feedback-tools).

## Frequently asked questions

### Can Canny and UserVoice both integrate with Salesforce?

Yes, but with different depth. Canny syncs Salesforce account data on its Business plan (custom pricing) and lets you filter feedback by Salesforce fields. UserVoice goes deeper with revenue-linked prioritization, surfacing the ARR behind each request. Quackback also includes a Salesforce integration, without revenue-linked prioritization yet.

### Is UserVoice worth the price compared to Canny?

It depends on your needs. UserVoice's price premium buys NLP theme detection, revenue-linked prioritization, and structured internal feedback capture. Those analytics can justify the cost for high-volume, revenue-driven enterprise teams. Mid-market teams get the core workflow from Canny at 10–20% of the cost, or from self-hosted [Quackback](/blog/open-source-feedback-tools) for free.

### Can I migrate from UserVoice or Canny to Quackback?

Yes. Canny and UserVoice both offer data export, and Quackback accepts imports through a REST API you can script. Small workspaces migrate in hours; large deployments with complex user mappings take a few days. The [migration docs](/docs) and [Quackback pricing](/pricing) cover self-hosted and cloud paths.

- [Canny vs Productboard: Which Feedback Tool Is Right for You?](https://quackback.io/blog/canny-vs-productboard): A neutral comparison of Canny and Productboard in 2026. Features, pricing, pros and cons, and when to consider an open-source alternative like Quackback.

Published: 2026-03-18

Canny and Productboard both deal with customer feedback, but they approach the problem differently. Canny is a focused feedback management tool: boards, voting, roadmaps, changelogs. Productboard is an enterprise product management platform that includes feedback as one piece of a broader strategy workflow.

![Canny vs Productboard comparison with Quackback as alternative](/blog/canny-vs-productboard/hero.webp)

> **Canny** is a focused feedback tool with boards, voting, and changelogs, best for teams that want a clean feature-request workflow. **Productboard** is an enterprise product management platform with prioritization frameworks and strategy alignment, built for product orgs that connect feedback to roadmaps. For an open-source alternative with no vendor lock-in, [Quackback](https://quackback.io) is free to self-host and also offers a managed cloud.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

If you're evaluating both tools in 2026, the right choice depends on what you're trying to solve. A team that needs a clean way to collect feature requests and show a public roadmap has different requirements than a product org that needs to connect customer insights to quarterly objectives and prioritization frameworks.

This guide breaks down what each tool does well, where each falls short, how they compare on features and pricing, and when an open-source alternative might be the better path. For deeper dives on each tool's pricing, see the [Canny pricing breakdown](/blog/canny-pricing) and [Productboard pricing analysis](/blog/productboard-pricing).

## Canny overview

Canny has been in the feedback space since 2017. It covers the core loop that most SaaS teams need: users submit feature requests, vote on ideas they care about, and get notified when you ship something. Your team gets a centralized place to track what users want.

The product includes feedback boards, voting, a public roadmap, a changelog, and an AI feature called Autopilot that discovers feedback in support conversations from tools like Intercom, Zendesk, and Help Scout. Autopilot attributes that feedback to users and creates posts on your behalf, saving your team from manually combing through support tickets.

### Pricing

Canny overhauled its pricing in May 2025, moving from per-admin billing to tiered pricing based on tracked users. A tracked user is anyone who has a post, vote, or comment attributed to them in your workspace.

- **Free:** $0/mo for 25 tracked users, 5 managers, Autopilot AI included
- **Core:** $19/mo (billed annually) for 100+ tracked users, 5 managers, custom domains, content translations
- **Pro:** $79/mo (billed annually) for 100+ tracked users, 10 managers, PM integrations (Jira, ClickUp, Linear)
- **Business:** Custom pricing for 5,000+ tracked users, SSO/SAML, CRM integrations, white-label

Costs increase as you cross tracked user thresholds — Canny auto-upgrades you to the next tier if you exceed your limit (you can set spend caps). A small team with 2,000 active feedback users pays more than a large team with 50 internal users on the board. For a detailed cost breakdown at different scales, see [Canny pricing in 2026](/blog/canny-pricing).

### Strengths

- **Focused product.** Canny does one thing and does it well. The interface is clean and easy to learn. Most teams are up and running within a day.
- **Autopilot AI.** Feedback discovery from support conversations is genuinely useful. It surfaces insights your team would otherwise miss.
- **Mature integrations.** Slack, Jira, Linear, GitHub, Intercom, Zendesk, Salesforce (Business only), and more. The integrations are stable and well-maintained.
- **Established product.** Nine years in market. Thousands of customers. The product is reliable and unlikely to disappear.

### Weaknesses

- **Tiered tracked-user pricing.** Exceeding your tier's tracked user limit triggers an auto-upgrade to the next tier. A viral feature request or a support tool integration can push you across thresholds quickly. You can set spend caps, but plan for cost growth tied to user activity.
- **SSO requires the Business plan.** If your organization needs SAML SSO for compliance, you need the Business plan (custom pricing).
- **No self-hosting.** Canny is hosted SaaS only. No way to run it on your own infrastructure or audit the source code.
- **Free plan caps at 25 tracked users.** Most teams outgrow the free tier quickly. The Core plan at $19/mo is the first paid tier with 100+ tracked users.
- **PM integrations require Pro.** Jira, ClickUp, and Linear integrations are locked to the Pro plan at $79/mo.

For alternatives to Canny, see [best Canny alternatives in 2026](/blog/best-canny-alternatives).

## Productboard overview

Productboard is a product management platform built for mid-size and enterprise product organizations. Feedback collection is one capability within a larger system that includes prioritization frameworks, opportunity mapping, driver-based roadmaps, and strategic alignment tools.

The feedback side works through a portal where users submit ideas and vote, plus an insights collection system that pulls feedback from Intercom, Zendesk, Salesforce, Gong, email, and manual notes. What sets Productboard apart is what happens after feedback arrives: product managers link insights to features, score features using custom prioritization criteria, map them to strategic objectives, and build roadmaps that reflect company priorities rather than raw vote counts.

### Pricing

Productboard uses per-maker pricing. A "maker" is anyone who creates or edits features, roadmaps, or insights. Viewers and contributors (people who submit feedback) are free.

- **Spark:** $15/maker/month (billed annually) or $19/maker/month (monthly), 250 AI credits per maker per month
- **Enterprise:** Custom pricing for SSO/SAML, advanced security, custom roles, and dedicated support

Productboard consolidated its old tiered plans (Essentials, Pro, Scale, Enterprise) into a single Spark plan. AI features are now included via a credits system rather than sold as a separate add-on. Each maker gets 250 credits per month. New signups get 150 free credits to trial AI. For a detailed cost analysis, see [Productboard pricing in 2026](/blog/productboard-pricing).

### Strengths

- **Product strategy tools.** Prioritization matrices, opportunity scoring, OKR alignment, and driver-based roadmaps. No feedback tool offers this depth.
- **Enterprise integrations.** Deep Salesforce, Jira, and Zendesk integrations. Revenue data from CRM can weight feature requests by customer value.
- **Multi-team alignment.** Multiple product teams can share insights, align on objectives, and coordinate roadmaps in one place.
- **Insights from everywhere.** Capture feedback from support tickets, sales calls (Gong), email, CRM, and manual notes. Everything flows into a single repository.

### Weaknesses

- **Costs grow with team size.** A 10-person team on the Spark plan pays $150/mo (annual) or $190/mo (monthly). Enterprise contracts with SSO and advanced features cost more.
- **AI credits may be limiting.** The 250 credits per maker per month power all AI interactions. Heavy AI users may exhaust credits before the month ends.
- **Steep learning curve.** The interface is complex. Onboarding a team takes weeks, not days.
- **Overkill for feedback collection.** If you just need a voting board and a roadmap, Productboard's strategy tools add complexity you don't need.
- **No self-hosting.** Hosted SaaS only, like Canny.
- **No native changelog.** Productboard focuses on the upstream process (insights to strategy). It doesn't include a changelog to announce what you shipped.

For alternatives to Productboard, see [best Productboard alternatives in 2026](/blog/best-productboard-alternatives).

## Feature comparison

Here's how Canny, Productboard, and Quackback compare across the features that matter for feedback management and product planning.

| Feature | Canny | Productboard | Quackback |
|---|---|---|---|
| **Feedback boards** | Yes | Yes (portal + insights) | Yes |
| **Voting** | Yes | Yes | Yes |
| **Public roadmap** | Yes | Yes (portal roadmap) | Yes |
| **Changelog** | Yes | No | Yes |
| **AI features** | Autopilot (all plans) | Included via credits (250/maker/mo) | Included |
| **MCP server** | No | No | Yes |
| **Integrations** | PM integrations on Pro ($79/mo) | 20+ on all paid plans | 20+ included |
| **API** | REST API | REST API | REST API |
| **SSO** | Business plan (custom pricing) | Enterprise plan | Free self-hosted · Enterprise on Cloud |
| **Self-hosting** | No | No | Yes (Docker) |
| **Open source** | No | No | Yes (AGPL-3.0) |
| **Starting price** | Free (25 tracked users) | $15/maker/mo (annual) | Free self-hosted / $29/mo Cloud |
| **Prioritization framework** | Basic (impact/effort) | Advanced (custom scoring, drivers) | Community voting + AI insights |
| **Duplicate detection** | Basic | Manual | AI-powered |

The three tools cover different ground. Canny and Productboard gate some features (SSO, advanced AI, white-label) behind higher tiers, which is standard for SaaS pricing models. Quackback includes all features on every self-hosted installation, but requires you to manage your own infrastructure.

## Pricing comparison

What each tool costs depends on your team size and how many users interact with your feedback system. Here's a side-by-side estimate at different scales.

### Small team (3 product people, 500 feedback users)

| | Canny | Productboard | Quackback |
|---|---|---|---|
| **Plan needed** | Pro (for PM integrations) | Spark | Self-host or Cloud Pro |
| **Monthly cost** | From $79/mo (Pro), rising as tracked users grow | $45/mo (3 makers x $15 annual) | Self-host ~$10 · Cloud $29/mo Pro (5 seats) |
| **Annual cost** | $948+ | $540 | Self-host ~$120 · Cloud $348 |
| **AI cost** | Included on all plans | Included (750 credits/mo) | Self-host: your LLM bill. Cloud: included Quinn usage, then $10 top-up packs. |

### Mid-size team (8 product people, 2,000 feedback users)

| | Canny | Productboard | Quackback |
|---|---|---|---|
| **Plan needed** | Pro or Business | Spark or Enterprise | Self-host or Cloud Business |
| **Monthly cost** | $79+/mo (Pro); 2,000 tracked users likely pushes toward Business (custom) | $120/mo (8 makers x $15 annual) | Self-host ~$20 · Cloud $59/mo Business (20 seats) |
| **Annual cost** | $948+ | $1,440 | Self-host ~$240 · Cloud $708 |
| **AI cost** | Included | Included (2,000 credits/mo) | Self-host: your LLM bill. Cloud: included Quinn usage, then $10 top-up packs. |
| **SSO** | Business plan (custom pricing) | Enterprise only (custom) | Free self-hosted · Enterprise on Cloud |

### Enterprise (20 product people, 10,000+ feedback users)

| | Canny | Productboard | Quackback |
|---|---|---|---|
| **Plan needed** | Business or Enterprise | Enterprise | Self-host or Cloud Enterprise |
| **Monthly cost** | Contact sales | $300/mo (20 makers x $15 annual) + enterprise features | Self-host infra · Cloud $99/mo Enterprise |
| **Annual cost** | Likely $15,000–30,000+ | $3,600+ (enterprise with SSO likely higher) | Self-host infra · Cloud $1,188 |

Each pricing model scales differently. Canny's tiered tracked-user pricing means costs increase as you cross user thresholds. Productboard's per-maker billing means costs grow with team size. Quackback Cloud is a flat workspace price from $29/mo billed annually (Free plan, 1 seat), with portal users free. Self-host is $0 software plus infrastructure and your own LLM usage. The right model depends on which dimension you expect to grow fastest.

## When to choose Canny

Canny is the right fit when your primary goal is focused feedback management and you don't need the product strategy layer that Productboard provides.

**Choose Canny if:**

- You want a dedicated feedback tool, not a product management platform. Canny's simplicity is a feature. Boards, voting, roadmap, changelog. Your team learns it quickly and users find it intuitive.
- Your tracked-user count will stay manageable. If your feedback community is in the hundreds rather than thousands, Canny's pricing stays reasonable. Teams with a smaller, engaged user base get good value from the Core or Pro plan.
- You rely on support conversation mining. Canny's Autopilot is genuinely useful for pulling insights out of Intercom, Zendesk, and Help Scout conversations. If your team processes a high volume of support tickets and wants feedback extracted automatically, Canny handles this well.
- You want a mature, established product. Canny has been in market since 2017. The product is stable, the integrations are well-tested, and the company isn't going anywhere.

Where Canny struggles: large-scale user bases (tracked-user costs become unpredictable), teams that need SSO without Business-tier custom pricing, and organizations that want to own their data or self-host.

## When to choose Productboard

Productboard is the right fit for product organizations that need more than feedback collection — teams that need to connect customer insights to product strategy, prioritize with data, and align multiple stakeholders.

**Choose Productboard if:**

- You need strategic product management tools. Opportunity scoring, prioritization frameworks, OKR alignment, and driver-based roadmaps are Productboard's core strength. If your team debates feature priorities in spreadsheets and wants a structured process, Productboard provides that.
- Your product org has multiple teams. Productboard handles the coordination problem: shared insights, team-level roadmaps that roll up to a company view, and cross-team visibility into what's being built and why.
- You need deep CRM integration. Productboard's Salesforce integration ties feature requests to customer revenue data. Product managers can see which features would affect the most ARR. This matters for enterprise SaaS companies where a single customer's feedback can drive product decisions.
- You have budget for it. Productboard is a significant investment. If your organization budgets for product management tooling at the enterprise level, the cost is justifiable. If you're a startup watching every dollar, it's not.

Where Productboard struggles: small teams that just need a voting board, budget-conscious organizations, teams that want fast setup without weeks of onboarding, and anyone who needs a changelog.

## Consider Quackback if...

Neither Canny nor Productboard is the only path. If the trade-offs of both tools don't sit well with you, [Quackback](https://quackback.io) takes a fundamentally different approach.

**You want to avoid vendor lock-in.** Quackback is open source under AGPL-3.0. The code is available, auditable, and forkable. You're not dependent on a vendor's pricing decisions, feature roadmap, or continued existence. If Quackback the company disappeared tomorrow, the software keeps running on your server.

**You want everything on one installation.** No feature gates based on plan tiers. One installation gives you [feedback boards](/features/feedback), voting, a public roadmap, a changelog, 25 integrations, SSO/OIDC, custom branding, and REST API access.

**You want AI built in.** Quackback includes duplicate detection, merge suggestions, sentiment analysis, and post summarization on every self-hosted installation. Productboard meters AI through 250 credits per maker per month, and Canny gates it by tier.

**You want an MCP server.** Quackback's [MCP server](/features/mcp) implements the Model Context Protocol, the standard supported by Claude, Cursor, and Windsurf. Connect an AI agent and it gets full access to your feedback data: search posts, triage requests, write responses, create changelog entries, and merge duplicates. No other feedback tool offers this.

**You want to self-host.** Deploy with Docker or on Railway. Your data lives in your PostgreSQL database on your infrastructure. Full control over backups, access, and compliance. This matters for teams with data residency requirements or organizations that can't send customer feedback to a third-party SaaS platform.

**The trade-off:** you manage your own infrastructure instead of paying a SaaS vendor. For teams with DevOps capacity, a $10–20/mo VPS runs the full platform. For teams that want managed hosting without the ops work, [Quackback Cloud](/pricing) is live now — the same open-source product, hosted and maintained for you.

For detailed head-to-head comparisons, see [Quackback vs Canny](/compare/quackback-vs-canny) and [Quackback vs Productboard](/compare/quackback-vs-productboard). For a broader look at the open-source landscape, see [open-source feedback tools](/blog/open-source-feedback-tools).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Is Canny or Productboard better for a small SaaS team?

Canny is the better fit for most small SaaS teams. It is simpler to set up and covers the core feedback workflow (boards, voting, roadmap, changelog) without Productboard's strategic-planning overhead. If budget is the primary concern, [Quackback](https://quackback.io) offers the same core feedback features open source at no cost.

### Can I use Productboard just for feedback collection?

You can, but it is not a good use of the tool. Productboard's value is in prioritization, opportunity scoring, and strategic alignment after feedback arrives. If you only need a feedback portal and voting board, you are paying for a platform you will not fully use. Canny or Quackback fit better.

### Do Canny or Productboard offer self-hosting?

No. Both Canny and Productboard are hosted SaaS products with no self-hosting option. If self-hosting, data ownership, or open-source licensing matters, [Quackback](/compare/quackback-vs-canny) is the primary alternative: open source (AGPL-3.0), deploys with Docker, and stores everything in your own PostgreSQL database. SSO, AI, and 25 integrations are included.

### Is Canny or Productboard cheaper at scale?

It depends on which dimension grows. Canny's tracked-user pricing rises as your feedback community grows, while Productboard's per-maker billing rises with team size. A large feedback audience favors Productboard; a large product team favors Canny. [Quackback](/pricing) is open source and free to self-host.

### Does Productboard have a changelog?

No. Productboard has no native changelog to announce shipped features, because it focuses on the upstream process from insights to strategy. Canny includes a [changelog](/features/changelog), and so does Quackback. Teams using Productboard typically pair it with a separate changelog tool to close the loop with users.

- [Feedback Tool Pricing Comparison 2026: Full Breakdown](https://quackback.io/blog/feedback-tool-pricing-comparison): A side-by-side pricing comparison of the top customer feedback tools in 2026. Plans, billing models, hidden costs, and the cheapest options for every team size.

Published: 2026-03-17

Feedback tool pricing is confusing. One vendor charges per tracked user. Another charges per "maker." A third won't even show you a price without a sales call. Some bill per board, some per seat, some per resolution. A few are free. Figuring out what you'll actually pay, especially as your team and user base grow, requires reading fine print, running estimates, and sometimes just asking.

![Feedback tool pricing comparison overview](/blog/feedback-tool-pricing-comparison/hero.webp)

> Feedback tool pricing ranges from free (Quackback, Fider) to $16,000+/year (UserVoice). Billing models vary: tiered by tracked users (Canny), per maker (Productboard), per seat, or enterprise quotes. [Quackback](https://quackback.io) is open source — free to self-host, or run it on a managed [Quackback Cloud](/pricing) plan when you want zero infrastructure to maintain.
>
> *Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

This guide compares the pricing of the most popular customer feedback tools in 2026. No vague ranges where exact numbers exist. No "contact sales" where public pricing is available. The goal is a clear picture of what each tool costs at every scale, so you can make a decision based on numbers rather than marketing pages.

## Pricing models explained

Before comparing specific tools, it helps to understand the billing models the market has settled on. There are six distinct approaches.

### Tiered by tracked users (Canny)

Canny uses tiered pricing based on "tracked users" — anyone who has a post, vote, or comment attributed to them in your workspace. Each plan tier includes a set number of tracked users. If you exceed your limit, Canny auto-upgrades you to the next tier (you can set spend caps to prevent this). A five-person startup with 2,000 active feedback users pays more than a fifty-person company with 50 internal users. The risk is crossing tier thresholds unexpectedly. A viral feature request or a support tool integration that attributes feedback to customers can push your tracked-user count past a tier limit, triggering an auto-upgrade. See the full [Canny pricing breakdown](/blog/canny-pricing) for details.

### Per maker (Productboard)

Productboard charges per "maker" — anyone who creates or manages product content. Viewers and contributors who only submit feedback don't count toward your bill. This model scales with team size rather than user engagement. Under the new Spark plan, a team of 5 makers pays $75/mo (annual) or $95/mo (monthly). A team of 20 pays $300/mo (annual). AI is included via 250 credits per maker per month. See the full [Productboard pricing breakdown](/blog/productboard-pricing).

### Per user (Aha!)

Aha! Ideas charges a flat per-user rate. Ideas Essentials is $39/user/month. Ideas Advanced is $59/user/month. If you also use Aha! Roadmaps (which most Ideas customers do), that's another $59/user/month. For a team of 10, you're looking at $590–1,180/mo on Ideas alone, or $1,180–1,780/mo with Roadmaps included.

### Enterprise quote (UserVoice, Pendo)

UserVoice and Pendo don't offer self-service pricing. UserVoice starts at $16,000/year (~$1,333/mo) with annual billing. Pendo doesn't publish prices at all — customers report annual contracts starting at $20,000–50,000+ depending on MAUs and modules. Both require a sales process before you can evaluate the product. See the full [UserVoice pricing breakdown](/blog/uservoice-pricing).

### Flat rate (Nolt, Upvoty)

Nolt and Upvoty use flat-rate pricing that doesn't scale with users or team size. Nolt charges $29/mo for one board (Essential, billed annually) or $69/mo for five boards (Pro). Upvoty charges $15/mo for one board (Power) or $39/mo for unlimited boards (Superpower). The trade-off is a narrower feature set — neither offers AI, and both are limited in integrations compared to more expensive tools.

### Free and open source (Quackback, Fider)

[Quackback](https://quackback.io) and Fider are both open source and free to self-host. There are no feature gates tied to pricing tiers. Your only cost is infrastructure — typically $5–20/mo for a small VPS. Quackback includes the full feature set ([feedback boards](/features/feedback), [voting](/features/voting), [public roadmap](/features/roadmap), changelogs, 25 integrations, SSO/OIDC, and AI features) at no cost. Fider covers the basics (voting boards, comments, tags) but has no changelog, no roadmap view, and no AI.

## Pricing comparison table

Here's every major feedback tool compared across the dimensions that affect your bill.

| Tool | Starting Price | Billing Model | Free Tier | SSO Plan | AI Features | Self-Hosting |
|------|---------------|---------------|-----------|----------|-------------|--------------|
| **Canny** | Free (25 tracked users) | Tiered by tracked users | Yes (25 tracked users) | Business (custom pricing) | Autopilot (all plans) | No |
| **UserVoice** | $16,000/yr (~$1,333/mo) | Enterprise quote (annual) | 30-day trial | Included | Included | No |
| **Productboard** | $15/maker/mo (annual) | Per maker | No | Enterprise only | Included via credits (250/maker/mo) | No |
| **Aha! Ideas** | $39/user/mo | Per user | No | Enterprise only | Included on higher tiers | No |
| **Pendo** | ~$20,000+/yr | Enterprise quote (MAU-based) | No | Included | Included | No |
| **Featurebase** | $29/seat/mo | Per seat | Yes (1 seat) | Professional ($59/seat/mo) | Fibi ($0.49/resolution) | No |
| **Nolt** | $29/mo | Per board | No | All paid plans | No | No |
| **Upvoty** | $15/mo | Per board | No | No | No | No |
| **Sleekplan** | $13/mo | Flat rate (tiered) | Yes (1 seat, limited) | Business ($38/mo) | 1,000 credits on Starter | No |
| **Quackback** | Free self-hosted / $29/mo Cloud | Self-hosted or workspace | Self-hosting (full features) · Cloud Free (1 seat) | Free self-hosted · Enterprise ($99/mo) on Cloud | Quinn on paid Cloud · BYOK self-host | Yes |
| **Fider** | Free | Free / self-hosted | Yes (basic features) | OAuth included | No | Yes |

![Feedback tools plotted by price vs feature completeness](/blog/feedback-tool-pricing-comparison/price-vs-features.webp)

A few things stand out. SSO is consistently locked behind expensive plans across closed-source tools. Canny requires the Business plan (custom pricing). Featurebase requires $59/seat/mo Professional. Productboard and Aha! gate it to Enterprise tiers. Self-hosted Quackback and Fider include SSO at no extra cost. On Quackback Cloud, SSO sits on the Enterprise plan ($99/mo), but it is self-serve with no seat minimums and no sales call, unlike the custom-priced enterprise gates elsewhere in this table.

AI features follow a similar pattern. Productboard includes AI via credits (250 per maker per month on the Spark plan), which may limit heavy users. Featurebase charges $0.49 per AI resolution. Canny includes Autopilot AI on all plans, including the free tier. Self-hosted Quackback includes all AI features with your own model key. Quackback Cloud includes Quinn on every paid plan, with Standard usage on Pro, Higher on Business, and Maximum on Enterprise, plus $10 top-up packs, and no per-resolution fee. It also ships an [MCP server](/features/mcp), so you can query and triage feedback from Claude or Cursor, a capability none of the closed-source tools here offer.

## Cost at scale

The table above shows starting prices. What matters more is what you pay as your product and user base grow. Here's the estimated monthly cost at different scales for the four tools that teams most often compare.

| Users / Scale | Canny (Pro est.) | UserVoice | Productboard (Spark, 10 makers) | Quackback |
|--------------|--------------------|-----------------------|------------------------------|-----------|
| **100 users** | $19–79/mo (Core or Pro) | $1,333/mo | $150/mo | Self-host $0 · Cloud from $29/mo |
| **500 users** | $79+/mo (higher tier) | $1,333/mo | $150/mo | Self-host $0 · Cloud from $29/mo |
| **1,000 users** | Higher tier (est.) | $1,333/mo | $150/mo | Self-host $0 · Cloud from $29/mo |
| **5,000 users** | Business (custom pricing) | $1,333/mo+ | $150/mo | Self-host $0 · Cloud from $29/mo |
| **10,000 users** | Business (custom pricing) | Custom (higher volume) | $150/mo | Self-host $0 · Cloud from $29/mo |

A few notes on how to read this table.

**Canny** uses tiered pricing with tracked user limits. The free plan covers 25 tracked users. Core starts at $19/mo and Pro at $79/mo, each with 100+ tracked users at the base tier. As your tracked user count grows, you move into higher tiers within your plan. Business requires 5,000+ tracked users and uses custom pricing.

**UserVoice** has a flat entry point of $16,000/year (~$1,333/mo) with custom pricing based on feedback volume and integrations. There are no per-seat charges. Higher-volume organizations pay more based on their usage and integration needs.

**Productboard** scales with makers (team members), not end users. A team of 10 makers on the Spark plan pays $150/mo (annual) regardless of whether 100 or 10,000 users submit feedback. AI is included via credits (250 per maker per month). The cost grows when you add makers, not when your user base grows.

**[Quackback](/compare/quackback-vs-canny)** is free to self-host. The cost is your infrastructure: a VPS at $5–20/mo for small deployments, potentially more for high-traffic installations. Quackback Cloud has a Free plan with 1 seat, and paid plans start at $29/mo billed annually.

Each tool scales differently. Canny's costs increase as you cross tracked user tier thresholds. UserVoice has a high floor regardless of scale. Productboard scales with team size. Quackback Cloud is a flat workspace price with included seats, not a per-end-user meter. Self-hosting keeps the software subscription at zero but requires infrastructure management.

## Hidden costs to watch for

Every feedback tool has costs that don't appear on the pricing page. These are common across the category.

**SSO tax.** If your organization requires SAML or OIDC single sign-on for compliance, expect to pay a premium. Canny gates SSO to the Business plan (custom pricing). Featurebase gates end-user SSO to the $59/seat/mo Professional plan and admin SAML/SCIM to Enterprise at $99/seat with a 5-seat minimum. Productboard reserves it for Enterprise tiers with custom pricing. UserVoice includes security and compliance features but requires a $16,000+/year contract. For a 10-person team that needs SSO, the "SSO tax" alone can add $200–400/mo to your bill. [Quackback](/compare/quackback-vs-productboard) includes SSO/OIDC free on every self-hosted installation, and on Cloud it is a listed self-serve price (Enterprise, $99/mo) rather than a sales conversation.

**AI credit and usage limits.** Productboard includes AI via credits (250 per maker per month on the Spark plan). Teams with heavy AI usage may find this constraining. Featurebase charges $0.49 per AI resolution: at 500 resolutions per month, that's $245/mo. Quackback Cloud includes Quinn on every paid plan with $10 top-up packs, so there is no per-resolution line item. Canny includes Autopilot AI on all plans, including the free tier. These charges and limits are easy to miss during evaluation.

**Tracked-user accumulation.** Canny's tracked users accumulate over time. Once someone votes, comments, or submits a post, they count toward your limit indefinitely. Over time, your tracked-user count only goes up. A product with years of feedback history accumulates thousands of tracked users, even if most are no longer active. This can push you into higher tiers based on historical engagement you no longer benefit from.

**Integration limits.** Canny's Core plan includes custom domains and translations. PM integrations like Jira, ClickUp, and Linear require the Pro plan at $79/mo. Nolt locks several integrations behind the Pro plan at $69/mo. Evaluate whether the integrations you need are included in the tier you're considering, not just the tier above it.

**Branding removal fees.** Removing "Powered by [tool name]" branding from your feedback portal often requires an expensive plan upgrade. Canny requires the Business plan (custom pricing) to remove branding. This is a cost that matters if your feedback portal is customer-facing and you want a professional appearance.

**Onboarding and implementation time.** Enterprise tools like UserVoice and Pendo require weeks of setup: sales demos, contract negotiation, CRM integration, team training. During this time, you're paying for the subscription but not yet collecting feedback at full capacity. Simpler tools (Nolt, Sleekplan, Quackback) let you start collecting feedback in minutes or hours.

## The cheapest options by category

Not every team needs the same thing. Here's the cheapest option for four common scenarios.

### Best free option

**[Quackback](https://quackback.io)** is free, open source (AGPL-3.0), and self-hosted, with a managed [Cloud](/pricing) from $29/mo. Self-hosted, it includes feedback boards, voting, a public roadmap, changelogs, a status page, support inbox, help center, integrations, SSO/OIDC, and AI features; your only cost is infrastructure. **[Fider](/compare/quackback-vs-fider)** is another free, open-source option with a lighter feature set (voting boards, comments, tags). Both require self-hosting.

### Best under $50/mo

**Sleekplan** at $13/mo (Starter) gives you feedback boards, a roadmap, changelog, CSAT/NPS surveys, and 1,000 AI credits. It's the cheapest hosted option that covers the full feedback workflow. **Upvoty** at $15/mo is another option if you want boards, roadmap, and changelog without AI. **Nolt** at $29/mo is simpler but includes SSO on all paid plans, which is notable given how many tools gate SSO to expensive tiers.

### Best open source

**[Quackback](https://quackback.io)** covers the full feedback workflow (boards, voting, roadmap, changelog, AI, integrations). **[Fider](/compare/quackback-vs-fider)** is lighter and simpler, covering voting boards, comments, and tags. Both are free to self-host. For a deeper comparison, see [Open Source Feedback Tools](/blog/open-source-feedback-tools).

### Best enterprise value

If your organization requires enterprise features (SSO, advanced analytics, CRM integration) but wants to avoid UserVoice or Pendo pricing, there are several paths.

**Self-hosted or managed:** self-hosted Quackback includes SSO/OIDC, all integrations, AI features, and a REST API at infrastructure cost only. [Quackback Cloud](/pricing) starts at $29/mo billed annually. Quinn is included on paid plans, with $10 top-up packs if you need more, plus a bundled status page. Portal users are free.

**Mid-range hosted:** Canny's Pro plan ($79+/mo depending on tracked user tier) or Featurebase's Growth plan ($29/seat/mo) offer solid features at a fraction of UserVoice's entry point. Both scale with usage over time. Quackback Cloud's Pro plan starts at $29/mo and includes tickets, a status page, and API access that Featurebase reserves for higher tiers.

**Enterprise hosted with CRM integration:** If you need revenue-linked prioritization with Salesforce data, UserVoice and Productboard are the established options. The cost is higher, but the capability is unique.

For detailed breakdowns, see [Canny pricing](/blog/canny-pricing), [UserVoice pricing](/blog/uservoice-pricing), and [Productboard pricing](/blog/productboard-pricing).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is the cheapest customer feedback tool?

For self-hosted: [Quackback](https://quackback.io) is free with no user or feature limits. Your only cost is a server ($5–20/mo for most teams). For cloud-hosted: Sleekplan starts at $13/mo, Upvoty at $15/mo, and Canny has a free plan (25 tracked users) and Core starts at $19/mo. Sleekplan and Upvoty include flat-rate pricing that doesn't scale with users. Canny's tiered tracked-user model means costs increase when you cross tier thresholds.

### Why do feedback tools charge per seat or per user?

Per-seat and per-user pricing lets vendors scale revenue with customer growth. The logic is that larger teams get more value, so they should pay more. The problem is that it creates friction: teams hesitate to add new members because each seat costs money. Tiered tracked-user pricing (Canny's model) can be unpredictable because crossing tier thresholds triggers auto-upgrades, and your tracked user count is driven by external engagement you don't fully control. Open source tools like Quackback, which you self-host, sidestep that dynamic.

### Is it worth paying for a feedback tool or should I use a free one?

It depends on your team's needs and capacity. Free, open-source tools like Quackback and Fider cover the core feedback workflow when self-hosted, and [Quackback Cloud](/pricing) offers a managed plan if you want zero infrastructure responsibility without giving up the full feature set. Paid hosted tools like Sleekplan ($13/mo) or Nolt ($29/mo) also remove that overhead at a modest cost. Enterprise tools like UserVoice ($16,000+/year) and Pendo ($20,000+/yr) are harder to justify on price alone, but they offer unique capabilities (revenue-linked prioritization, product analytics) that cheaper tools don't replicate.

### How do I estimate my total cost of ownership for a feedback tool?

Start with the base subscription price, then add: the SSO plan upgrade if you need it, AI add-on costs, the number of seats or tracked users you expect in 12 months (not just today), integration costs if key integrations are locked to higher tiers, and the time cost of onboarding and setup. For enterprise tools like UserVoice or Pendo, add the implementation timeline (2–6 weeks where you're paying but not fully operational). For self-hosted tools like Quackback, your total cost is your server bill. For a broader view of the tools available, see [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026).

- [7 Best Productboard Alternatives in 2026](https://quackback.io/blog/best-productboard-alternatives): Looking for a Productboard alternative? Compare 7 product management and feedback tools with simpler pricing, open-source options, and focused feature sets.

Published: 2026-03-15

You added a third product manager to your team and your Productboard bill jumped by another $15–19 per month. Per-maker pricing compounds fast.

Productboard is a product management platform built for enterprise product orgs. It connects customer feedback to strategy through prioritization frameworks, opportunity scoring, and driver-based roadmaps. For large teams managing complex product portfolios, it does the job.

But most teams don't need all of that. They need to collect feedback, let users vote, show a roadmap, and announce what shipped. Productboard's Spark plan charges $15/maker/month (annual) or $19/maker/month (monthly) for a full product management platform. AI is included via credits (250 per maker per month), but credit limits may constrain heavy users.

Enterprise pricing for SSO, advanced security, and custom features is custom. For a detailed side-by-side, see our [Quackback vs Productboard comparison](/compare/quackback-vs-productboard).

If you're paying for strategy tools you don't use, or watching your bill grow with every product manager you add, here are seven alternatives worth evaluating.

![Seven Productboard alternatives compared](/blog/best-productboard-alternatives/hero.webp)

> **The best Productboard alternative for most teams is [Quackback](https://quackback.io)** — open source, and the only tool on this list with an MCP server. Run it self-hosted for free or use the managed Quackback Cloud. Canny, Aha!, UserVoice, Featurebase, Nolt, and Fider round out the list, each suited to a different need. The ranked picks:
>
> 1. **[Quackback](https://quackback.io)** — Open source. Self-hosted free or managed cloud. AI + MCP server included.
> 2. **[Canny](/compare/quackback-vs-canny)** — Established hosted feedback tool. Voting, roadmap, changelog, AI Autopilot.
> 3. **[Aha!](/compare/quackback-vs-aha)** — Full product management suite covering strategy, roadmapping, and development.
> 4. **[UserVoice](/compare/quackback-vs-uservoice)** — Enterprise feedback with revenue-linked prioritization via Salesforce.
> 5. **[Featurebase](/compare/quackback-vs-featurebase)** — Free tier. All-in-one feedback, support inbox, and help center.
> 6. **[Nolt](/compare/quackback-vs-nolt)** — Simple feedback board with flat-rate pricing. No per-user billing.
> 7. **[Fider](/compare/quackback-vs-fider)** — Open source, lightweight voting board. Bare-bones but stable.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

## Why teams switch from Productboard

The most common reasons teams look for a Productboard alternative:

- **Per-maker pricing adds up fast.** Productboard's Spark plan charges $15/maker/month (annual) or $19/maker/month (monthly). A 10-person product team costs $150–190/mo. Enterprise pricing for SSO and advanced features is custom and higher.
- **AI credit limits.** Each maker gets 250 AI credits per month. Teams that rely heavily on AI-driven feedback analysis may exhaust credits before the month ends.
- **Complexity you may not need.** Productboard is a full product management suite with strategy layers, objectives, and scoring frameworks. If you just need feedback boards and a roadmap, you're paying for features you won't use.
- **No self-hosting.** Your data lives on Productboard's infrastructure. No open-source option, no data portability beyond standard export.

For a detailed pricing breakdown, see [Productboard Pricing in 2026](/blog/productboard-pricing).

## 1. Quackback

[Quackback](https://quackback.io) is open source (AGPL-3.0) and free to self-host. No feature gates tied to pricing tiers. Deploy it on your own infrastructure with Docker, or skip the ops and use the managed [Quackback Cloud](/pricing). Either way you get the full feature set from day one.

![Quackback feedback board interface](/blog/best-productboard-alternatives/quackback.webp)

The core workflow covers everything Productboard charges for in its feedback loop: [feedback boards](/features/feedback) with [voting](/features/voting), a [public roadmap](/features/roadmap), a [changelog](/features/changelog), SSO/OIDC, custom branding, and 25 integrations including Slack, Jira, Linear, GitHub, Intercom, Zendesk, and Salesforce. Productboard doesn't have a native changelog. You need a separate tool to tell users what shipped. Quackback handles collection through announcement in a single product.

Where Quackback differs most is its approach to AI. Duplicate detection catches redundant posts before they pile up. Merge suggestions identify related requests with reasoning your team can accept or dismiss in one click. Sentiment analysis runs on every post, and summaries pull out key quotes and next steps. Productboard includes AI via credits (250 per maker per month), but heavy users may hit those limits.

The [MCP server](/features/mcp) is something no other tool on this list offers. It implements the Model Context Protocol, the standard that Claude, Cursor, and Windsurf support. Connect an AI agent and it gets full access to your feedback data: search posts, triage requests, write responses, create changelog entries, and merge duplicates. Every action is attributed and auditable.

**Key features:**
- Feature request boards with voting, status tracking, and nested comments
- Public roadmap and changelog with automatic voter notifications
- Built-in AI: duplicate detection, merge suggestions, sentiment analysis, post summaries
- MCP server for AI agents (search, triage, respond, create, merge)
- 25 integrations: Slack, Linear, Jira, GitHub, Intercom, Zendesk, Salesforce, and more
- SSO/OIDC, webhooks, full [REST API](/features/api)
- Custom branding with themes, custom CSS, and your own domain
- [Import/export](/features/import-export) for migration from other tools

**Pricing:** Free and open source to self-host with Docker or Railway. A managed [Quackback Cloud](/pricing) is available if you would rather not run your own infrastructure.

**Pros:**
- Full-featured feedback, voting, roadmap, and changelog in one product
- AI included at no extra cost when self-hosted (bring your own model key)
- MCP server for AI agent access — unique in the category
- Open source — audit the code, fork it, own your data
- 25 integrations, SSO, and custom branding included on every self-hosted installation
- Built-in changelog that Productboard lacks

**Cons:**
- Self-hosting means you manage your own infrastructure (Docker or Railway) — though managed cloud removes that
- Newer project with a smaller community than Productboard
- No weighted scoring or objective-based prioritization (vote-based instead)

**Best for:** Teams that want focused feedback collection, voting, roadmap, and changelog without paying for a full PM suite.

For a detailed feature-by-feature breakdown, see the [full Quackback vs Productboard comparison](/compare/quackback-vs-productboard).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [Self-host with Docker](/docs) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. Canny

[Canny](/compare/quackback-vs-canny) is one of the most established feedback tools in the category. It covers the standard workflow: feature request boards, voting, a public roadmap, a changelog, and status notifications. The interface is clean and the product is mature.

![Canny feedback board interface](/blog/best-productboard-alternatives/canny.webp)

Canny overhauled its pricing in May 2025, moving from per-admin billing to tiered pricing based on tracked users. A tracked user is anyone who posts, votes, or comments. Costs increase as you cross tracked user thresholds, with auto-upgrades to the next tier.

Canny offers a free plan (25 tracked users, 5 managers) but most teams outgrow it quickly. Core is $19/mo for 100+ tracked users. Pro is $79/mo for PM integrations (Jira, ClickUp, Linear). Business is custom pricing for 5,000+ tracked users.

Compared to Productboard, Canny is more focused on the feedback loop and less on product strategy. You get boards, voting, a roadmap, and a changelog. You don't get prioritization frameworks, opportunity scoring, or objective alignment. If that's what drove you to Productboard in the first place, Canny won't replace it. But if you only used Productboard for feedback collection, Canny covers that ground at a lower price point.

Canny's AI feature, Autopilot, handles feedback discovery, deduplication, smart replies, and comment summaries. It's included on all plans, including the free tier. SSO is locked behind the Business plan (custom pricing).

**Key features:**
- Feedback boards with voting, status tracking, and user segmentation
- Public roadmap and changelog
- Autopilot AI: feedback discovery, deduplication, smart replies, comment summaries (all plans)
- Integrations: Slack, Jira, Linear, GitHub, Intercom, Zendesk, Salesforce, and more
- Custom domain and branding
- SSO (Business plan, custom pricing)

**Pricing:** Free (25 tracked users). Core at $19/mo (100+ tracked users). Pro at $79/mo (PM integrations). Business is custom pricing (5,000+ tracked users).

**Pros:**
- Mature, well-designed product
- Covers the full feedback-to-changelog workflow
- Broad integration set
- Established company with a large user base

**Cons:**
- Tiered tracked-user pricing means costs increase as you cross user thresholds
- Free plan caps at 25 tracked users
- SSO locked behind the Business plan (custom pricing)
- No self-hosting, no open source
- AI (Autopilot) is included on all plans

**Best for:** Mid-size SaaS teams that want a proven hosted feedback tool and can budget for tracked-user pricing.

See how it compares: [Quackback vs Canny](/compare/quackback-vs-canny).

## 3. Aha!

[Aha!](/compare/quackback-vs-aha) is a full product management suite. It goes beyond feedback collection into strategy, roadmapping, idea management, and development planning. If Productboard felt too focused on the insights-to-strategy pipeline, Aha! is even broader — it covers the entire product lifecycle from vision to sprint.

![Aha! Ideas portal and roadmap interface](/blog/best-productboard-alternatives/aha.webp)

Aha! Ideas is the feedback-specific module. It lets you create an ideas portal where customers and internal teams submit feature requests, vote, and comment. Ideas link to features and epics in Aha! Roadmaps, creating a traceable path from customer request to shipped product.

The depth comes at a cost. [Aha! Ideas](https://www.aha.io/ideas/pricing) starts at $39/user/month for the Essentials tier, with the Advanced add-on at +$20/user/month (annual). [Aha! Roadmaps](https://www.aha.io/roadmaps/pricing) is a separate product at $59/user/month. A minimum of three paid seats is required, and a team of 10 product managers across both products faces a bill north of $500/month. Aha! also offers Aha! Develop for engineering workflows, which adds another layer (and another line item).

The product is dense. Setup takes time. Learning curves are real. But for enterprise product organizations that need a single platform covering strategy, roadmapping, idea management, and development, Aha! is one of the few tools that does it all.

**Key features:**
- Ideas portal for customer feedback and voting
- Strategic roadmapping with multiple views (timeline, Gantt, list, board)
- Feature scoring and prioritization frameworks
- Knowledge base and whiteboards
- Integrations: Jira, Azure DevOps, Slack, Salesforce, Zendesk, and 30+ more
- Reports, dashboards, and custom analytics
- SSO/SAML

**Pricing:** Aha! Ideas Essentials at $39/user/month, with the Advanced add-on at +$20/user/month (annual). Aha! Roadmaps at $59/user/month. Three-seat minimum. Enterprise pricing is custom.

**Pros:**
- Comprehensive product management platform
- Strong strategic roadmapping capabilities
- Deep integration between ideas, roadmaps, and development
- Established company (founded 2013) with a large enterprise customer base

**Cons:**
- Expensive — per-user, per-module pricing adds up fast across Ideas and Roadmaps
- Steep learning curve and complex configuration
- Overkill for teams that just need feedback and a roadmap
- No self-hosting, no open source
- Setup and onboarding take weeks

**Best for:** Enterprise product organizations that need a complete strategy-to-development platform, not just feedback collection.

See how it compares: [Quackback vs Aha!](/compare/quackback-vs-aha).

## 4. UserVoice

[UserVoice](/compare/quackback-vs-uservoice) was one of the first customer feedback platforms. It pioneered the voting board concept that most tools in this category still use. In 2026, UserVoice positions itself as an enterprise feedback platform with CRM-linked prioritization and revenue-based scoring.

![UserVoice feedback portal interface](/blog/best-productboard-alternatives/uservoice.webp)

The differentiator is its ability to tie feedback to revenue. By integrating with Salesforce, UserVoice lets you see which feature requests come from your highest-value accounts. Product teams can prioritize by ARR impact, not just vote count. For enterprise B2B companies where a single customer might represent six or seven figures of revenue, this changes how you make product decisions.

The trade-off is cost and commitment. UserVoice starts at $16,000/year (~$1,333/mo) with custom pricing based on monthly feedback volume and integrations. No per-seat charges.

Annual billing is required. There is no free tier, no monthly option, and no self-serve signup. A 30-day free trial is available, but you go through sales first, negotiate a contract, and wait for onboarding.

If you came to Productboard for revenue-linked prioritization and found it lacking, UserVoice is the specialist. If you came to Productboard because you needed a feedback board and a roadmap, UserVoice is more tool than you need at a price that's hard to justify.

**Key features:**
- Feedback portal with voting and smart vote capture
- Revenue-based prioritization with Salesforce integration
- NPS surveys and contributor tracking
- Internal feedback capture for support and sales teams
- Product analytics and insights dashboards
- SSO/SAML, custom branding

**Pricing:** Starting at $16,000/year (~$1,333/mo). Custom pricing based on volume. Annual billing required. No per-seat charges. 30-day free trial.

**Pros:**
- Revenue-linked feedback prioritization
- Deep Salesforce integration for B2B teams
- Internal feedback capture across support and sales
- Established brand (founded 2008)

**Cons:**
- Starts at $16,000/year with annual billing
- No free tier, no self-serve signup
- No self-hosting, no open source
- Dated interface compared to newer tools
- Long onboarding process

**Best for:** Large B2B organizations with enterprise budgets that need revenue-based feedback prioritization.

See how it compares: [Quackback vs UserVoice](/compare/quackback-vs-uservoice).

## 5. Featurebase

[Featurebase](/compare/quackback-vs-featurebase) bundles feedback boards, a changelog, roadmap, help docs, and a support inbox into one product. It has a free plan (1 seat, limited features), making it one of the more accessible starting points for teams that don't want to self-host.

![Featurebase feedback board interface](/blog/best-productboard-alternatives/featurebase.webp)

The AI agent, Fibi, auto-resolves customer questions using context from your help center, feedback posts, and past conversations. It can submit feature requests on behalf of users. The catch: Fibi charges $0.49 per resolution on top of your plan cost. At volume, that adds up.

Compared to Productboard, Featurebase is simpler and cheaper. You won't get prioritization frameworks, opportunity scoring, or strategy alignment. You will get a feedback board, a changelog, help docs, and a support inbox in one tool for $29/seat/month. For teams that used Productboard primarily as a feedback collection layer, Featurebase covers that ground and adds things Productboard doesn't have — a changelog and built-in help docs.

Per-seat pricing ($29–99/seat/month on paid plans) still means costs grow with your team, though not as fast as Productboard. Post merging and user segmentation are locked to the Business tier ($38+/mo).

**Key features:**
- Feedback boards with voting, status tracking, and user segmentation
- Changelog, public roadmap, and surveys (NPS, CSAT)
- Unified support inbox with live chat and email
- Fibi AI Agent for auto-resolving questions ($0.49/resolution)
- Help docs / knowledge base
- 12 integrations: Linear, Jira, GitHub, Slack, Intercom, Zendesk, and more

**Pricing:** Free (1 seat, limited). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- Free tier available for getting started
- All-in-one: feedback, support, help docs in one product
- Growing fast with regular feature updates
- Surveys (NPS, CSAT) included

**Cons:**
- Per-seat pricing adds up for larger teams
- AI resolutions are usage-based ($0.49 each)
- No self-hosting, no open source
- Post merging locked to Business tier

**Best for:** Startups and small teams that want a hosted all-in-one tool with a free starting point.

See how it compares: [Quackback vs Featurebase](/compare/quackback-vs-featurebase).

## 6. Nolt

[Nolt](/compare/quackback-vs-nolt) takes the opposite approach to Productboard. It's simple. You get a clean feedback board where users submit and vote on ideas, plus a basic roadmap view and status notifications. That's it. No AI, no changelog, no support inbox, no prioritization frameworks.

![Nolt feedback board interface](/blog/best-productboard-alternatives/nolt.webp)

The pricing is flat-rate: $29/mo for one board on the Essential plan (billed annually). No tracked-user billing, no per-seat charges. You know exactly what you'll pay. After dealing with Productboard's per-maker pricing that scales with team size, Nolt's predictability is a relief.

The concern is pace. Nolt has seen minimal product updates over the past two years. Core feature requests from users — changelog, comment threading, bulk editing — remain unbuilt. Per-board pricing also means costs multiply if you manage feedback for multiple products. The Essential plan covers one board. The Pro plan covers five boards at $69/mo.

If your needs are simple — one product, one feedback board, flat pricing — Nolt handles it. If you need more than that, you'll outgrow it.

**Key features:**
- Feedback board with voting and custom statuses
- Roadmap view
- SSO, private boards, and password-protected boards
- Integrations: Slack, Discord, Jira, Linear, GitHub, Zapier (Pro plan)
- Custom domain and branding

**Pricing:** Essential at $29/mo for 1 board (annual). Pro at $69/mo for 5 boards. Enterprise is custom.

**Pros:**
- Flat-rate pricing — no per-user surprises
- Clean, focused UI
- Quick to set up
- SSO included on paid plans

**Cons:**
- No changelog, no AI features
- Minimal product updates since 2022
- Per-board pricing multiplies costs across products
- No self-hosting, no open source

**Best for:** Small teams that want a simple, predictable-cost feedback board and nothing more.

See how it compares: [Quackback vs Nolt](/compare/quackback-vs-nolt).

## 7. Fider

[Fider](/compare/quackback-vs-fider) is the other open-source option on this list. It's licensed under AGPL-3.0, built with Go and React, and deploys with Docker. Fider covers the core feedback workflow: users submit ideas, vote, and comment. Admins manage posts with tags, custom statuses, and filters.

![Fider feedback board interface](/blog/best-productboard-alternatives/fider.webp)

Fider has been around since 2017 and has a stable, lightweight codebase. Go makes it efficient on resources — you can run it on a small VPS for $5/month. If you need a bare-bones voting board and nothing else, Fider does the job well.

Where Fider falls short is everything beyond the basics. There's no changelog. No roadmap view. No AI features. Integrations are limited to webhook-based connections with Slack, Discord, and Microsoft Teams. No native Jira, Linear, or GitHub integration. The project also moved to an open-core model in v0.33.0, putting content moderation and SEO indexing behind the paid cloud tier.

If you're leaving Productboard because it does too much, Fider is the extreme opposite — it does the minimum. You'll need separate tools for your roadmap, changelog, and integrations.

**Key features:**
- Feedback boards with voting, comments, and rich text editor
- Tags, filters, and customizable statuses
- REST API and webhooks
- Multi-language support (10+ languages)
- SSO with OAuth providers
- Self-hosted on any cloud or on-premise

**Pricing:** Free and open source for self-hosting. Cloud free tier limited to 250 feedback items. Cloud Pro at $49/month.

**Pros:**
- Mature, stable codebase (since 2017)
- Lightweight and resource-efficient
- Simple to set up and operate
- Truly open source for self-hosting

**Cons:**
- No changelog, no roadmap, no AI features
- Limited integrations (webhooks only)
- Open-core model means some features are paywalled on cloud
- Development pace has slowed
- No duplicate detection, no post merging

**Best for:** Developers who want a minimal, open-source voting board with low resource requirements.

See how it compares: [Quackback vs Fider](/compare/quackback-vs-fider).

## Comparison table

Here's how all seven alternatives stack up against Productboard on the features that matter most.

| Feature | Productboard | Quackback | Canny | Aha! | UserVoice | Featurebase | Nolt | Fider |
|---|---|---|---|---|---|---|---|---|
| **Starting price** | $15/maker/mo (annual) | Free self-hosted / $29/mo Cloud | Free (25 tracked users) | $39/user/mo | $16,000/yr | Free (1 seat) | $29/mo | Free |
| **Pricing model** | Per maker | Workspace (Cloud) or free self-hosted | Tiered by tracked users | Per user | Annual (no per-seat) | Per seat | Per board | Free / $49/mo |
| **Open source** | No | Yes (AGPL-3.0) | No | No | No | No | No | Yes (AGPL-3.0) |
| **Self-hosting** | No | Yes | No | No | No | No | No | Yes |
| **Feedback boards** | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| **Public roadmap** | Yes | Yes | Yes | Yes | No | Yes | Yes | No |
| **Changelog** | No | Yes | Yes | No | No | Yes | No | No |
| **AI features** | Included via credits (250/maker/mo) | Yes (built in) | Autopilot (all plans) | Limited | Limited | Fibi ($0.49/resolution) | No | No |
| **MCP server** | No | Yes | No | No | No | No | No | No |
| **SSO included** | Paid plans | Yes | Business (custom pricing) | Yes | Yes | Paid plans | Yes | Yes |
| **Free tier** | No | Free (open source) | Yes (25 tracked users) | No | No | Yes (1 seat) | No | Yes (250 items) |

## How to choose

Start with two questions: what do you actually need, and what are you willing to manage?

**If you used Productboard mainly for feedback collection:** You were overpaying. Quackback, Canny, and Featurebase all cover feedback boards, voting, roadmaps, and changelogs. Productboard's value is in its strategy and prioritization layer. If you weren't using that, you don't need to replace it.

**If cost is the priority:** Quackback is free and open source to self-host. Fider is also free and open source but covers less ground. Among hosted options, Nolt ($29/mo flat) and Featurebase (free tier) are the most affordable starting points.

**If you want open source:** Quackback and Fider are your options. Quackback gives you the full feature set — boards, roadmap, changelog, 25 integrations, AI, MCP server. Fider covers basic voting boards. Both deploy with Docker.

If you want a tool you won't outgrow, Quackback is the stronger choice. For more options, see [Open Source Feedback Tools](/blog/open-source-feedback-tools).

**If you need enterprise product management:** Aha! is the closest replacement for Productboard's strategy and roadmapping capabilities. It's broader, more expensive, and has a steeper learning curve — but it covers ideation through development in one platform.

**If you need revenue-linked prioritization:** UserVoice is the specialist. Its Salesforce integration ties feedback to account revenue so you can prioritize by ARR impact. You'll pay $16,000/year or more for that capability, but no other tool on this list matches it.

**If you want simplicity:** Nolt is the lightest option. One board, flat pricing, minimal UI. It does not try to be a product management platform. It collects votes and shows a roadmap. If that is all you need, it is enough.

**If you're migrating from Productboard:** The most common reasons teams leave are per-maker pricing, AI credit limitations, and complexity they don't need. If you want the feedback loop without the PM suite, Quackback covers boards, voting, roadmap, changelog, integrations, SSO, and AI at no cost. See the [full comparison](/compare/quackback-vs-productboard) for a detailed breakdown.

For a broader look at the feedback tool landscape, see [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026).

## Frequently asked questions

### What is the best free alternative to Productboard?

[Quackback](https://quackback.io) is the most full-featured free alternative. It's open source (AGPL-3.0), self-hosted, and includes [feedback boards](/features/feedback), [voting](/features/voting), a [public roadmap](/features/roadmap), a [changelog](/features/changelog), 25 integrations, SSO/OIDC, and built-in AI features. There are no feature gates. Among hosted tools, Featurebase offers a limited free tier with one seat.

### Why are people switching from Productboard?

Three factors drive most of the migration. First, per-maker pricing grows with team size — a team of 10 PMs costs $150–190/month on the Spark plan, and enterprise pricing with SSO is higher. Second, AI credits (250 per maker per month) may not be enough for teams that rely heavily on AI-driven feedback analysis. Third, many teams only use Productboard for feedback collection but pay for a full product management suite they don't need. Simpler tools cover that workflow at a fraction of the cost.

### Is there an open-source Productboard alternative?

Yes. Quackback is the closest open-source equivalent to Productboard's feedback capabilities. It covers feedback boards, voting, a public roadmap, a changelog, 25 integrations, SSO, and AI — features that span multiple Productboard pricing tiers. The [MCP server](/features/mcp) adds AI agent access that Productboard doesn't offer.

Fider is another open-source option, though it only covers basic voting boards. Both self-host with Docker. For a deeper comparison, see [Open Source Feedback Tools](/blog/open-source-feedback-tools).

### Can I migrate from Productboard to another tool?

Productboard supports data export, so you can extract your feedback notes, features, and user data. The migration process depends on your destination tool. You'll need to map users, votes, statuses, and any linked objectives or scores.

Tools that focus purely on feedback (like Quackback or Canny) won't import Productboard's strategy layer — prioritization scores, objectives, and driver mappings don't have equivalents. Focus on migrating your feedback data and start fresh with the new tool's native features. Check the [Quackback docs](/docs) for import guidance.

### Does Productboard have a free plan?

Productboard does not have a free plan. The Spark plan starts at $15/maker/month (billed annually) or $19/maker/month (monthly). New signups get 150 free credits to trial AI features, but the plan itself requires payment. For teams that want full feedback functionality, Quackback is free and open source to self-host.

- [7 Best UserVoice Alternatives in 2026: Honest Comparison](https://quackback.io/blog/best-uservoice-alternatives): Looking for a UserVoice alternative? Compare 7 feedback tools that cost less, deploy faster, and don't require enterprise contracts. Honest pros and cons.

Published: 2026-03-14

You need to collect feature requests from your users. UserVoice wants $16,000 per year and an annual contract before you can start. That is the barrier most teams hit first.

UserVoice was one of the first customer feedback platforms. It helped establish the category. But in 2026, its pricing and commitment structure push many teams to look elsewhere.

The numbers are hard to ignore. UserVoice starts at $16,000 per year (~$1,333/mo) with custom pricing based on monthly feedback volume and integrations. No per-seat charges, but annual billing is required and you need to go through a sales process to get started.

There is no free tier, no monthly option, and no self-serve signup. A 30-day free trial is available, but you still talk to sales first, negotiate a contract, and wait for onboarding. For a detailed breakdown, see our [Quackback vs UserVoice comparison](/compare/quackback-vs-uservoice).

That model made sense when UserVoice was one of the only options. It doesn't in 2026. The feedback tool category has matured. Open-source alternatives now match UserVoice's feature set.

Mid-range SaaS tools offer similar capabilities at a fraction of the cost. The features UserVoice charges a premium for, like CRM-linked prioritization and AI, are now available from tools that cost $0 to $79 per month. Here are seven alternatives worth considering.

![Seven UserVoice alternatives compared](/blog/best-uservoice-alternatives/hero.webp)

> The best UserVoice alternative for most teams is **Quackback**, an open-source feedback platform that matches UserVoice's core workflow for free, with a managed cloud option for teams that prefer hosting. UserVoice starts at $16,000 per year with an annual contract, while the alternatives below range from $0 to $79 per month. Ranked best to worst fit:
>
> 1. **[Quackback](https://quackback.io)** — Open source, self-hosted or managed cloud. Built-in AI + MCP server included.
> 2. **[Canny](/compare/quackback-vs-canny)** — Established hosted feedback tool. Voting, roadmap, changelog, and AI Autopilot.
> 3. **[Productboard](/compare/quackback-vs-productboard)** — Enterprise product management suite with strategy and prioritization layers.
> 4. **[Featurebase](/compare/quackback-vs-featurebase)** — Free tier. All-in-one feedback, support inbox, and help center.
> 5. **[Nolt](/compare/quackback-vs-nolt)** — Simple feedback board with flat-rate pricing. No per-user billing.
> 6. **[Fider](/compare/quackback-vs-fider)** — Open source, lightweight voting board. Bare-bones but stable.
> 7. **[Aha! Ideas](/compare/quackback-vs-aha)** — Full product management suite with strategic roadmapping and idea portals.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

## Why teams switch from UserVoice

The most common reasons teams look for a UserVoice alternative:

- **Enterprise-only pricing.** UserVoice starts at $16,000/year (~$1,333/mo) with annual billing. Startups and mid-market teams are priced out before they can evaluate the product.
- **Weeks-long onboarding.** Enterprise procurement means sales calls, security reviews, and dedicated onboarding. Weeks pass before your team collects a single piece of feedback.
- **No self-service signup.** You cannot try UserVoice without going through sales. A 30-day free trial is now available, but there is no free tier and no public pricing beyond the $16,000/year starting point.
- **Closed source.** No ability to audit code, self-host, or customize the platform beyond their settings.
- **Overkill for most teams.** UserVoice's NLP analytics and revenue-linked prioritization are designed for enterprise product organizations. Teams that just need feedback boards and voting are paying for features they will never use.

For a detailed pricing breakdown, see [UserVoice Pricing in 2026](/blog/uservoice-pricing).

## 1. Quackback

**Best for:** Teams that want enterprise-grade feedback without enterprise pricing.

[Quackback](https://quackback.io) is an open-source customer feedback platform licensed under AGPL-3.0. It's free to self-host and covers the full workflow that UserVoice charges $16,000+ per year for: [feature voting boards](/features/voting), a [public roadmap](/features/roadmap), [changelogs](/features/changelog), and [25 integrations](/integrations) including Slack, Jira, Linear, GitHub, Intercom, Zendesk, and Salesforce.

![Quackback feedback board interface](/blog/best-uservoice-alternatives/quackback.webp)

Where UserVoice takes weeks to onboard, Quackback deploys in about five minutes with Docker Compose or a one-click Railway deploy. Your data stays in your own PostgreSQL database. If you would rather not run infrastructure, Quackback Cloud is a managed option that handles hosting for you. Either way: no contracts, no sales calls, no annual commitments.

The AI features are built in. Duplicate detection catches redundant posts before they pile up. Merge suggestions identify related requests with reasoning your team can accept or dismiss in one click. Sentiment analysis runs automatically on every post.

Summaries extract key quotes and next steps.

The [MCP server](/features/mcp) is something no other feedback tool offers. It implements the Model Context Protocol, the standard that Claude, Cursor, and Windsurf support. Connect an AI agent and it gets structured access to your feedback data: search posts, triage requests, write responses, create changelog entries, and merge duplicates. Every action is attributed and auditable.

**Key features:**
- [Feature voting boards](/features/voting) with status tracking, nested comments, and official responses
- [Public roadmap](/features/roadmap) with planned, in progress, and shipped views
- [Changelog](/features/changelog) with automatic voter notifications
- AI: duplicate detection, merge suggestions, sentiment analysis, post summaries
- [MCP server](/features/mcp) for AI agents (search, triage, respond, create, merge)
- [25 integrations](/integrations): Slack, Linear, Jira, GitHub, Intercom, Zendesk, Salesforce, and more
- [SSO/OIDC](/features/sso), webhooks, [full REST API](/features/api)
- Custom branding with themes, custom CSS, and your own domain
- User segments and admin inbox with bulk actions

**Pricing:** Free and open source (AGPL-3.0). Self-host at no cost, or use Quackback Cloud for managed hosting.

**Pros:**
- Full feature set that matches UserVoice at $0
- AI included at no extra cost
- MCP server for AI agent access, unique among feedback tools
- Open source means no surprise pricing changes or feature paywalling
- 5-minute setup vs UserVoice's weeks-long onboarding

**Cons:**
- Self-hosting means you manage your own infrastructure (Docker or one-click Railway deploy), unless you choose Quackback Cloud
- Newer project with a smaller community than UserVoice

**Why switch from UserVoice:** You get the same feedback workflow, more integrations, and AI features that UserVoice doesn't offer, for $0 per year instead of $16,000. The trade-off is self-hosting, which takes minutes, not months.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. Canny

**Best for:** Mid-size SaaS teams that want a hosted feedback solution without enterprise pricing.

[Canny](/compare/quackback-vs-canny) has been around since 2017 and is one of the most established hosted feedback tools. It covers feature request tracking, voting, roadmaps, changelogs, and AI-powered feedback discovery through its Autopilot feature.

![Canny feedback board interface](/blog/best-uservoice-alternatives/canny.webp)

Compared to UserVoice, Canny is dramatically cheaper. Canny offers a free plan (25 tracked users) and paid tiers starting at $19/mo (Core). The billing model uses tiered pricing based on tracked users — anyone who submits a post, vote, or comment counts toward your tier limit.

Costs increase as you cross tracked user thresholds, with auto-upgrades to the next tier (you can set spend caps). Pro starts at $79/mo and Business uses custom pricing.

Canny's Autopilot AI discovers feedback from support conversations in Intercom, Zendesk, Help Scout, and Gong, plus 10 public review sites. Smart replies prompt users for clarification. Credits are now uncapped on all plans.

**Key features:**
- Feedback boards with voting and prioritization
- Public and private roadmaps
- Changelog with email notifications
- Autopilot AI: feedback discovery, smart replies, comment summarization
- Integrations with Jira, Linear, Slack, HubSpot (Salesforce requires Business plan)

**Pricing:** Free (25 tracked users). Core from $19/mo. Pro from $79/mo. Business is custom pricing.

**Pros:**
- Established product with a large user base
- Lower starting price than UserVoice by a wide margin
- Strong AI feedback discovery features
- Good integration ecosystem

**Cons:**
- Tiered tracked-user pricing means costs increase as you cross user thresholds
- Auto-upgrades when you exceed tracked user limits unless you set spend caps
- No self-hosting or open source
- Removing "Powered by Canny" branding requires the Business plan
- Jira integration requires Pro ($79/mo)

**Why switch from UserVoice:** You save over $15,000 per year on day one. You get a modern interface, better AI capabilities, and faster onboarding. The risk is that tiered tracked-user pricing can push costs up as your community grows, though it starts much lower.

## 3. Productboard

**Best for:** Enterprise product organizations that need feedback as part of a broader product management suite.

[Productboard](/compare/quackback-vs-productboard) is a product management platform that includes feedback capabilities. It connects customer insights to product strategy through opportunity scoring, prioritization matrices, and driver-based roadmaps. If your team thinks in terms of product strategy, not just feature requests, Productboard speaks that language.

![Productboard product management interface](/blog/best-uservoice-alternatives/productboard.webp)

You can capture insights from Intercom, Zendesk, Salesforce, email, and Slack. The layer on top links feedback to features, scores impact, and aligns teams around priorities. AI features are included via a credits system (250 credits per maker per month) for summarization, insight extraction, semantic search, and auto-linking.

Compared to UserVoice, Productboard offers more structure around product strategy at a lower price point. The Spark plan costs $15/maker/month (annual) or $19/maker/month (monthly). Enterprise pricing for SSO and advanced features is custom.

**Key features:**
- Insights portal for collecting and organizing customer feedback
- Feature prioritization with custom scoring frameworks
- Driver-based roadmaps tied to company objectives
- Integrations with Jira, Azure DevOps, Slack, Salesforce, Zendesk, Intercom
- AI included via credits (250/maker/month) for summarization, insight extraction, semantic search

**Pricing:** Spark at $15/maker/month (annual) or $19/maker/month (monthly). Enterprise is custom.

**Pros:**
- Deep product strategy features beyond feedback
- Strong prioritization frameworks
- Deep CRM integrations for revenue-linked insights
- AI included in the base plan via credits
- Established enterprise vendor with compliance features

**Cons:**
- AI credits (250/maker/month) may be limiting for heavy users
- More product management tool than feedback tool, overkill for simple use cases
- No self-hosting
- Steep learning curve

**Why switch from UserVoice:** You get better product strategy features and a more modern platform. Pricing can be comparable at enterprise scale, so this is a lateral move on cost, not a downgrade. The value is in the product management layer that UserVoice lacks.

## 4. Featurebase

**Best for:** Startups and small SaaS teams that want free hosted feedback to start.

[Featurebase](/compare/quackback-vs-featurebase) bundles feedback boards, a changelog, roadmap, help docs, customer support inbox, and live chat into a single product. Every plan includes both the Support Suite and the Product Suite. The free plan gives you one seat with 50 help center articles and basic feedback features.

![Featurebase feedback board interface](/blog/best-uservoice-alternatives/featurebase.webp)

Their AI agent, Fibi, automatically resolves customer questions using context from your help center, feedback posts, changelogs, and past conversations. It can submit feature requests to your boards on behalf of customers. AI resolutions cost $0.49 each.

Compared to UserVoice, Featurebase is a modern, more affordable alternative with broader capabilities. The combined feedback-and-support model means fewer tools in your stack. The free tier makes it accessible to startups that UserVoice prices out entirely.

**Key features:**
- Feedback boards with voting, status tracking, and user segmentation
- Changelog, public roadmap, and surveys (NPS, CSAT, multiple choice)
- Unified support inbox with live chat, email, and ticketing
- Help center with AI-powered search
- Fibi AI Agent: auto-resolves questions, submits feedback on behalf of users
- 12 integrations: Linear, Jira, GitHub, ClickUp, Slack, Intercom, Zendesk, HubSpot

**Pricing:** Free plan (1 seat, 50 help center articles, no AI). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- Free tier with usable feedback features
- All-in-one: feedback, support, and help center in one product
- Modern interface with fast iteration cycle
- AI agent can handle support and feedback simultaneously

**Cons:**
- Per-seat pricing adds up for larger teams
- AI resolutions at $0.49 each are usage-based and can become significant at volume
- Post merging and user segmentation locked to higher tiers
- No self-hosting or open source

**Why switch from UserVoice:** You go from $16,000 per year to free (or $29 per seat for paid features). You get a modern platform that combines feedback and support. The trade-off is less enterprise-specific functionality like revenue-weighted prioritization.

## 5. Nolt

**Best for:** Small teams that want the simplest possible feedback board.

[Nolt](/compare/quackback-vs-nolt) keeps things deliberately simple. You get a clean feedback board, voting, custom statuses, a basic roadmap view, and status notifications. There are no AI features and no changelog. Setup takes minutes.

![Nolt feedback board interface](/blog/best-uservoice-alternatives/nolt.webp)

Nolt uses flat-rate pricing: $29 per month for one board on Essential (billed annually), $69 per month for five boards on Pro. No tracked-user limits, no per-seat charges. After UserVoice's pricing complexity, the simplicity is appealing.

The concern with Nolt in 2026 is pace. The product has seen minimal updates over the past two years. Core feature requests from users, like changelog support, comment threading, and bulk editing, remain unbuilt.

**Key features:**
- Feedback board with voting and custom statuses
- Roadmap view
- SSO, private boards, and password-protected boards
- Integrations: Slack, Discord, Jira, Linear, Asana, Trello, GitHub, Zapier (Pro plan)
- Custom domain and branding

**Pricing:** Essential at $29/month for 1 board (annual). Pro at $69/month for 5 boards. Enterprise is custom.

**Pros:**
- Flat-rate pricing with no per-user charges
- Clean, minimal interface
- Fast to set up and easy to use
- Good set of integrations for the price

**Cons:**
- No changelog
- No AI features
- Limited updates since 2022
- Per-board pricing means costs multiply if you manage multiple products
- No self-hosting

**Why switch from UserVoice:** You save over $15,000 per year and get a feedback board running in minutes instead of weeks. You lose revenue-linked prioritization, enterprise security features, and the breadth of UserVoice's internal capture tools. For small teams that just need voting and a roadmap, that trade-off often makes sense.

## 6. Fider

**Best for:** Developers who want a bare-bones open-source feedback board with no cost.

[Fider](/compare/quackback-vs-fider) is an open-source feedback tool licensed under AGPL-3.0. It's built with Go and React, backed by PostgreSQL, and deploys with Docker. Fider handles the core workflow: users submit ideas, vote, and comment. Admins manage posts with tags, custom statuses, and filters.

![Fider feedback board interface](/blog/best-uservoice-alternatives/fider.webp)

Fider has been around since 2017 and has a stable codebase. If all you need is a voting board and nothing more, it does the job well. Go makes it efficient on resources. The interface is clean and functional.

Where Fider falls short is everything beyond the basics. There is no changelog, no roadmap view, no AI features, and integrations are limited to webhook-based connections with Slack, Discord, and Microsoft Teams. No native Jira, Linear, or GitHub integration. The project moved to an open-core model in v0.33.0, putting content moderation and SEO indexing behind the paid cloud tier.

**Key features:**
- Feedback boards with voting, comments, and rich text editor
- Tags, filters, and customizable statuses
- REST API and webhooks (4 event types)
- Multi-language support (10+ languages, including RTL)
- SSO with OAuth providers

**Pricing:** Free and open source for self-hosting. Cloud free tier limited to 250 feedback items. Cloud Pro at $49/month.

**Pros:**
- Free and open source with a mature codebase
- Lightweight and resource-efficient
- Simple to set up with Docker
- Multi-language support out of the box

**Cons:**
- No changelog, no roadmap, no AI features
- Limited integrations (webhooks only, no native issue tracker connections)
- Open-core model means some features are paywalled on the cloud version
- Development pace has slowed
- No duplicate detection or post merging

**Why switch from UserVoice:** You go from $16,000 per year to $0. You get data ownership and an auditable codebase. The trade-off is significant: you lose roadmaps, changelogs, AI, and most integrations. Fider is a good choice if you need only the voting workflow and want to self-host. If you need more, consider Quackback, which offers the full feature set at the same price (free).

## 7. Aha Ideas

**Best for:** Large organizations that need product strategy, roadmapping, and feedback in a single enterprise platform.

[Aha!](/compare/quackback-vs-aha) is a product management suite where Ideas is the feedback module. It connects directly to Aha! Roadmaps, giving product teams a unified view from customer request to shipped feature. If your organization already uses Aha! for roadmapping, adding the Ideas module is a natural extension.

![Aha! Ideas portal interface](/blog/best-uservoice-alternatives/aha.webp)

Aha! Ideas includes idea portals, voting, proxy voting (where internal teams submit and vote on behalf of customers), status updates, and dynamic forms. The integration with Aha! Roadmaps is the main draw: feedback flows directly into your strategic planning, with scoring, prioritization, and capacity planning built in.

The pricing is per user per month, and it adds up. Ideas Essentials starts at $39 per user per month. Ideas Advanced is $59 per user per month. Aha! Roadmaps, which you'll likely need to get the full value, costs an additional $59 per user per month. For a team of 10, you're looking at $590 to $1,180 per month before adding the roadmapping product.

**Key features:**
- Idea portals with voting, categories, and dynamic forms
- Proxy voting for internal teams to submit on behalf of customers
- Direct integration with Aha! Roadmaps for strategy-to-delivery workflows
- Custom scoring and prioritization frameworks
- Integrations with Jira, Azure DevOps, Slack, Salesforce, Zendesk
- Enterprise security: SAML SSO, audit logs, custom SLAs

**Pricing:** Ideas Essentials at $39/user/month. Ideas Advanced at $59/user/month. Aha! Roadmaps at $59/user/month (separate). Enterprise pricing available.

**Pros:**
- Tight integration with Aha! Roadmaps for end-to-end product management
- Strong enterprise security and compliance features
- Proxy voting for internal advocacy
- Well-maintained with consistent updates

**Cons:**
- Expensive, especially when combined with Aha! Roadmaps
- Per-user pricing scales quickly for larger teams
- Most valuable when used with the broader Aha! suite, less standalone appeal
- No self-hosting or open source
- Complex product with a learning curve

**Why switch from UserVoice:** You get a more modern platform with stronger product management integration. Pricing can be lower for small teams but approaches UserVoice-level costs for larger orgs. The main advantage is the strategic layer: connecting feedback to roadmaps, scoring, and capacity planning in a way UserVoice doesn't support natively.

## Comparison table

| Feature | Quackback | Canny | Productboard | Featurebase | Nolt | Fider | Aha! Ideas | UserVoice |
|---|---|---|---|---|---|---|---|---|
| **Starting price** | Free | Free (25 tracked users) | $15/maker/mo (annual) | Free | $29/mo | Free | $39/user/mo | $16,000/yr |
| **Billing model** | Free (self-host) | Tiered by tracked users | Per maker | Per seat | Flat rate per board | Free (self-host) | Per user | Flat monthly |
| **Free plan** | Yes (open source) | Yes (25 tracked users) | No | 1 seat | No | 250 items (cloud) | No | No |
| **Feedback boards** | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| **Public roadmap** | Yes | Yes | Yes | Yes | Yes | No | Yes | No |
| **Changelog** | Yes | Yes | No | Yes | No | No | No | No |
| **AI features** | Yes (built in) | Yes (Autopilot) | Yes (included via credits, 250/maker/mo) | Yes ($0.49/resolution) | No | No | No | No |
| **MCP server** | Yes | No | No | No | No | No | No | No |
| **Self-hosted** | Yes | No | No | No | No | Yes | No | No |
| **Open source** | Yes (AGPL-3.0) | No | No | No | No | Yes (AGPL-3.0) | No | No |
| **SSO** | Yes (OIDC/SAML) | Yes | Yes | Yes | Yes | Yes (OAuth) | Yes (SAML) | Yes (SAML) |
| **Integrations** | 23 | 15+ | 20+ | 12 | 8+ | 3 (webhooks) | 15+ | 10+ |
| **Setup time** | ~5 minutes | Same day | Days to weeks | Same day | Minutes | ~5 minutes | Days | Weeks |

## How to choose a UserVoice alternative

The right alternative depends on three things: your budget, your team size, and how much of the feedback workflow you want to own.

**If cost is the primary driver:** Quackback and Fider are free. Quackback gives you the full feature set that UserVoice charges $16,000 per year for. Fider covers the basics. Both are open source and self-hosted. Featurebase has a usable free tier if you prefer hosted.

**If you want the closest match to UserVoice's features:** Quackback covers voting, roadmaps, changelogs, integrations, SSO, and AI. It adds capabilities UserVoice doesn't offer, like an [MCP server](/features/mcp) for AI agents and open-source transparency. You can self-host it for free or run it on Quackback Cloud. Canny and Featurebase are the closest hosted mid-range options.

**If you need product strategy beyond feedback:** Productboard or Aha! Ideas give you prioritization frameworks, scoring models, and strategic roadmapping tied to feedback. These are product management platforms with feedback built in, not feedback tools with product management bolted on. They cost accordingly.

**If simplicity matters most:** Nolt is the simplest tool on this list. Flat pricing, clean interface, minutes to set up. You lose AI, changelogs, and deep integrations, but you get a working feedback board fast.

**If data ownership matters:** Quackback and Fider are the only self-hosted options. Your feedback data stays in your PostgreSQL database, on your infrastructure. No vendor has access to your customer data. For teams with compliance requirements or data residency concerns, this can be the deciding factor.

**If AI and automation matter:** Quackback includes duplicate detection, merge suggestions, sentiment analysis, and post summaries. Its MCP server lets AI agents act on feedback directly. Canny's Autopilot discovers feedback from support conversations. Featurebase's Fibi resolves support questions.

Productboard includes AI via credits (250 per maker per month), which may limit heavy users. UserVoice has no comparable AI features. For a broader look at feedback tools with AI, see our [guide to customer feedback tools in 2026](/blog/best-customer-feedback-tools-2026).

## Frequently asked questions

### Why do people switch from UserVoice?

Pricing is the most common reason. UserVoice starts at $16,000 per year with annual billing, hard to justify when alternatives offer similar features for $0 to $79 per month. Other drivers include the dated interface, weeks-long onboarding, no public roadmap feature, and the absence of AI capabilities newer tools include.

### Is there a free alternative to UserVoice?

Yes. [Quackback](https://quackback.io) is free and open source. You self-host it with Docker and get feature voting, roadmaps, changelogs, 25 integrations, and built-in AI at no cost. [Fider](/compare/quackback-vs-fider) is also free and open source but covers only basic voting boards without roadmaps, changelogs, or AI.

Featurebase offers a free tier with usage limits. For more open-source options, see our [guide to open-source feedback tools](/blog/open-source-feedback-tools).

### Can I migrate my data from UserVoice?

Yes. Most feedback tools support data import through CSV or API. Quackback has a [REST API](/features/api) you can use to import feature requests, votes, and comments from UserVoice. Plan for mapping user accounts, preserving vote counts, and maintaining status history. Check your UserVoice plan's export options first, since lower tiers limit them.

### Does UserVoice offer a free plan?

UserVoice has no free plan, though it offers a 30-day free trial. The entry price is $16,000 per year with annual billing, and you go through a "Talk to an Expert" sales process to start. Most alternatives on this list offer a free plan, a lower-cost trial, or are free and open source.

### What features does UserVoice have that alternatives don't?

UserVoice's primary differentiator is revenue-linked prioritization. Connect Salesforce or HubSpot, and UserVoice pulls in account-level ARR data so you see the revenue behind each request. Most alternatives lack this exact feature, though [Productboard](/compare/quackback-vs-productboard) and Aha! offer similar prioritization frameworks. For teams that do not need CRM-linked revenue data, it rarely justifies the price.

- [7 Best Canny Alternatives in 2026](https://quackback.io/blog/best-canny-alternatives): Looking for a Canny alternative? Compare 7 feedback tools with better pricing, open-source options, and features Canny lacks. Honest pros and cons for each.

Published: 2026-03-13

Your Canny bill just doubled and you are not sure why. That is the reality of tracked-user pricing — one viral feature request and your costs spike overnight.

Canny has been a go-to feedback tool since 2017. Feature request boards, voting, roadmaps, changelogs — it covers the standard workflow. But in the past year, three changes have pushed teams to look elsewhere.

In May 2025, Canny overhauled its pricing. The company moved from per-admin billing to tiered pricing based on tracked users. A tracked user is anyone who posts, votes, or comments on your board. Costs increase as you cross tracked user thresholds, with auto-upgrades to the next tier.

Canny's free plan exists but caps at 25 tracked users with limited features. Most teams outgrow it quickly. The first paid tier is Core at $19/mo (billed annually) for 100+ tracked users. For a deeper breakdown of what Canny actually costs at scale, see our [Canny pricing analysis](/blog/canny-pricing).

Beyond pricing, Canny is closed source with no self-hosting option. You can't run it on your own infrastructure, audit the code, or fork it if the product changes direction. For teams that care about data ownership, vendor independence, or predictable costs, these are real limitations. Here are seven alternatives worth considering.

![Seven Canny alternatives compared side by side](/blog/best-canny-alternatives/hero.webp)

> The best Canny alternatives in 2026 are Quackback, Featurebase, Productboard, Nolt, Fider, Upvoty, and Sleekplan. Quackback is the strongest overall option: it is open source, free to self-host or run on Quackback Cloud, and has no tracked-user limits. Here are all seven ranked:
>
> 1. **[Quackback](https://quackback.io)** — Open source, self-hosted or managed cloud. AI + MCP server included.
> 2. **[Featurebase](/compare/quackback-vs-featurebase)** — Free tier. Feedback, roadmap, changelog, and support inbox in one tool.
> 3. **[Productboard](/compare/quackback-vs-productboard)** — Enterprise product management suite. Strategy and prioritization focused.
> 4. **[Nolt](/compare/quackback-vs-nolt)** — Simple feedback board with flat-rate pricing. No per-user billing.
> 5. **[Fider](/compare/quackback-vs-fider)** — Open source, lightweight voting board. Bare-bones but stable.
> 6. **[Upvoty](/compare/quackback-vs-upvoty)** — Affordable hosted tool with boards, roadmap, and changelog from $15/mo.
> 7. **[Sleekplan](/compare/quackback-vs-sleekplan)** — Widget-first feedback with built-in NPS/CSAT surveys.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

## Why teams switch from Canny

The most common reasons teams look for a Canny alternative:

- **Tiered tracked-user pricing surprises.** Canny uses tiered pricing with tracked user limits. Exceeding your tier triggers an auto-upgrade. Launch a popular feature request page and you may cross a tier threshold overnight. You can set spend caps, but teams with growing user bases find the auto-upgrade mechanism catches them off guard.
- **Free plan is very limited.** Canny's free plan caps at 25 tracked users. Most teams outgrow it quickly and move to the Core plan at $19/mo.
- **No self-hosting.** Your feedback data lives on Canny's servers. Teams with data residency requirements, compliance needs (SOC 2, HIPAA-adjacent), or a preference for infrastructure control have no option.
- **Closed source.** You cannot audit the code, fix bugs yourself, or customize behavior beyond what Canny's settings allow.
- **Feature gates.** PM integrations (Jira, ClickUp, Linear) require the Pro plan ($79/mo). SSO requires the Business plan (custom pricing). Autopilot AI is included on all plans.

For a detailed pricing breakdown, see [Canny Pricing in 2026](/blog/canny-pricing).

## 1. Quackback

[Quackback](https://quackback.io) is open source (AGPL-3.0), self-hosted, and free. No tracked-user limits. No feature gates based on pricing tiers.

![Quackback feedback board interface](/blog/best-canny-alternatives/quackback.webp)

You get the full feedback workflow in a single product: [feedback boards](/features/feedback) with [voting](/features/voting), a [public roadmap](/features/roadmap), a [changelog](/features/changelog), SSO/OIDC, custom branding, and 25 integrations including Slack, Jira, Linear, GitHub, Intercom, Zendesk, and Salesforce. Everything Canny charges for on its paid plans is included in the free self-hosted version.

The AI features are where Quackback pulls ahead. Duplicate detection catches redundant posts before they pile up. Merge suggestions identify related requests with reasoning your team can accept or dismiss in one click. Sentiment analysis runs on every post. Summaries pull out key quotes and next steps. The AI connects to any OpenAI-compatible provider.

The [MCP server](/features/mcp) is something no other feedback tool offers. It implements the Model Context Protocol, the standard that Claude, Cursor, and Windsurf support. Connect an AI agent and it gets full access to your feedback data: search posts, triage requests, write responses, create changelog entries, and merge duplicates. Every action is attributed and auditable.

**Key features:**
- Feature request boards with voting, status tracking, and nested comments
- Public roadmap and changelog with automatic voter notifications
- Built-in AI: duplicate detection, merge suggestions, sentiment analysis, post summaries
- MCP server for AI agents (search, triage, respond, create, merge)
- 25 integrations: Slack, Linear, Jira, GitHub, Intercom, Zendesk, Salesforce, and more
- SSO/OIDC, webhooks, full REST API
- Custom branding with themes, custom CSS, and your own domain

**Pricing:** Free and open source. Self-host with Docker or deploy on Railway at no cost, or choose Quackback Cloud for a fully managed option.

**Pros:**
- Full-featured and free to self-host
- Built-in AI for duplicate detection, merge suggestions, sentiment, and summaries
- MCP server for AI agent access
- Open source — audit the code, fork it, own your data
- 25 integrations, SSO, and custom branding included on every self-hosted installation

**Cons:**
- Self-hosting means you manage your own infrastructure (Docker or Railway), though Quackback Cloud removes that work
- Newer project with a smaller community than Canny

**Best for:** Teams that want open-source, self-hosted feedback with AI and no user limits.

For a detailed side-by-side breakdown, see the [full Quackback vs Canny comparison](/compare/quackback-vs-canny).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. Featurebase

[Featurebase](/compare/quackback-vs-featurebase) bundles feedback boards, a changelog, roadmap, help docs, and a support inbox into one product. It has a free plan (1 seat, limited features), which makes it an accessible starting point for small teams that don't want to self-host.

![Featurebase feedback board interface](/blog/best-canny-alternatives/featurebase.webp)

The AI agent, Fibi, auto-resolves customer questions using context from your help center, feedback posts, and past conversations. It can also submit feature requests on behalf of users. The catch: Fibi charges $0.49 per resolution on top of your plan cost, which adds up at volume.

Featurebase is closed source and hosted only. Per-seat pricing ($29–99/seat/month on paid plans) means costs grow with your team size. Post merging and user segmentation are locked to the Business tier ($38+/mo). But for small teams that want a hosted all-in-one tool with a free starting point, it's a solid option.

**Key features:**
- Feedback boards with voting, status tracking, and user segmentation
- Changelog, public roadmap, and surveys (NPS, CSAT)
- Unified support inbox with live chat and email
- Fibi AI Agent for auto-resolving questions ($0.49/resolution)
- 12 integrations: Linear, Jira, GitHub, Slack, Intercom, Zendesk, and more

**Pricing:** Free (1 seat, limited). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- Free tier available for getting started
- All-in-one: feedback, support, help docs in one product
- Growing fast with regular feature updates
- Surveys (NPS, CSAT) included

**Cons:**
- Per-seat pricing adds up for larger teams
- AI resolutions are usage-based ($0.49 each)
- No self-hosting, no open source
- Post merging locked to Business tier

**Best for:** Small teams wanting a free hosted option with feedback and support combined.

See how it compares: [Quackback vs Featurebase](/compare/quackback-vs-featurebase).

## 3. Productboard

[Productboard](/compare/quackback-vs-productboard) is a product management platform, not just a feedback tool. It connects customer insights to product strategy through opportunity scoring, prioritization matrices, and driver-based roadmaps.

![Productboard product management interface](/blog/best-canny-alternatives/productboard.webp)

If your team needs more than feedback collection — if you need to link customer insights to company objectives, score features by impact, and align multiple product teams around priorities — Productboard is built for that. Deep integrations with Jira, Salesforce, Zendesk, and Intercom let you capture feedback from across your stack.

The trade-off is complexity and cost. The Spark plan costs $15/maker/month (annual) or $19/maker/month (monthly). AI is included via credits (250 per maker per month). Enterprise pricing for SSO and advanced features is custom. For teams that just want a feedback board and a roadmap, Productboard is overkill.

**Key features:**
- Insights portal for collecting and organizing customer feedback
- Feature prioritization with custom scoring frameworks
- Driver-based roadmaps tied to company objectives
- Deep Jira, Salesforce, Zendesk, and Intercom integrations
- AI included via credits (250/maker/month) for summarization, insight extraction, and auto-linking

**Pricing:** Spark at $15/maker/month (annual) or $19/maker/month (monthly). Enterprise is custom.

**Pros:**
- Deep product management features beyond feedback
- Strategy-level roadmapping tied to business objectives
- Deep integrations with enterprise tools
- AI included in the base plan via credits
- Established company with large customer base

**Cons:**
- AI credits (250/maker/month) may be limiting for heavy users
- Steep learning curve
- Overkill for simple feedback collection
- No self-hosting

**Best for:** Enterprise product orgs that need strategy and prioritization tools beyond feedback.

See how it compares: [Quackback vs Productboard](/compare/quackback-vs-productboard).

## 4. Nolt

[Nolt](/compare/quackback-vs-nolt) takes the opposite approach to Productboard. It's simple. You get a clean feedback board where users submit and vote on ideas, plus a basic roadmap view and status notifications. That's it. No AI, no changelog, no support inbox.

![Nolt feedback board interface](/blog/best-canny-alternatives/nolt.webp)

The pricing is flat-rate: $29/mo for one board on the Essential plan (billed annually). No tracked-user billing, no per-seat charges. You know exactly what you'll pay. This is Nolt's main advantage over Canny — predictable costs.

The concern is pace. Nolt has seen minimal product updates over the past two years. Core feature requests from users (changelog, comment threading, bulk editing) remain unbuilt. Per-board pricing also means costs multiply if you manage feedback for multiple products.

**Key features:**
- Feedback board with voting and custom statuses
- Roadmap view
- SSO, private boards, and password-protected boards
- Integrations: Slack, Discord, Jira, Linear, GitHub, Zapier (Pro plan)
- Custom domain and branding

**Pricing:** Essential at $29/mo for 1 board (annual). Pro at $69/mo for 5 boards. Enterprise is custom.

**Pros:**
- Flat-rate pricing — no per-user surprises
- Clean, focused UI
- Quick to set up
- SSO included on paid plans

**Cons:**
- No changelog, no AI features
- Minimal product updates since 2022
- Per-board pricing multiplies costs across products
- No self-hosting

**Best for:** Small teams wanting a simple, predictable-cost feedback board.

See how it compares: [Quackback vs Nolt](/compare/quackback-vs-nolt).

## 5. Fider

[Fider](/compare/quackback-vs-fider) is the other open-source option on this list. It's licensed under AGPL-3.0, built with Go and React, and deploys with Docker. Fider covers the core feedback workflow: users submit ideas, vote, and comment. Admins manage posts with tags, custom statuses, and filters.

![Fider feedback board interface](/blog/best-canny-alternatives/fider.webp)

Fider has been around since 2017 and has a stable, lightweight codebase. Go makes it efficient on resources — you can run it on a small VPS. If you need a bare-bones voting board and nothing else, Fider does the job well.

Where Fider falls short is everything beyond the basics. There's no changelog. No roadmap view. No AI features. Integrations are limited to webhook-based connections with Slack, Discord, and Microsoft Teams. No native Jira, Linear, or GitHub integration. The project also moved to an open-core model in v0.33.0, putting content moderation and SEO indexing behind the paid cloud tier.

**Key features:**
- Feedback boards with voting, comments, and rich text editor
- Tags, filters, and customizable statuses
- REST API and webhooks
- Multi-language support (10+ languages)
- SSO with OAuth providers
- Self-hosted on any cloud or on-premise

**Pricing:** Free and open source for self-hosting. Cloud free tier limited to 250 feedback items. Cloud Pro at $49/month.

**Pros:**
- Mature, stable codebase (since 2017)
- Lightweight and resource-efficient
- Simple to set up and operate
- Truly open source for self-hosting

**Cons:**
- No changelog, no roadmap, no AI features
- Limited integrations (webhooks only)
- Open-core model means some features are paywalled on cloud
- Development pace has slowed
- No duplicate detection, no post merging

**Best for:** Developers who want bare-bones open-source feedback with minimal overhead.

See how it compares: [Quackback vs Fider](/compare/quackback-vs-fider).

## 6. Upvoty

[Upvoty](/compare/quackback-vs-upvoty) is a hosted feedback tool that covers the three essentials: feedback boards, a roadmap, and a changelog. It's one of the more affordable options in the category, starting at $15/mo.

![Upvoty feedback board interface](/blog/best-canny-alternatives/upvoty.webp)

The feature set is simpler than Canny or Featurebase. You get voting boards, status updates, a public roadmap, and a changelog with email notifications. There are no AI features, no support inbox, and fewer integrations. But if your needs are straightforward — collect votes, show a roadmap, announce releases — Upvoty handles it at a lower price point.

Upvoty uses per-board pricing on its lower tiers. The Power plan ($15/mo) includes 1 board. The Superpower plan ($39/mo) includes unlimited boards. Both include unlimited tracked users, which is a direct advantage over Canny's model.

**Key features:**
- Feedback boards with voting and status updates
- Public roadmap
- Changelog with email notifications
- Custom domain and branding
- SSO on higher plans
- Integrations: Slack, Jira, Zapier, webhooks

**Pricing:** Power at $15/mo (1 board). Superpower at $39/mo (unlimited boards). Enterprise is custom.

**Pros:**
- Affordable starting price
- No tracked-user limits
- Covers the core workflow: boards, roadmap, changelog
- Clean interface

**Cons:**
- No AI features
- Simpler feature set than most alternatives
- Per-board pricing on lower tier
- No self-hosting, no open source
- Smaller company with less frequent updates

**Best for:** Budget-conscious teams wanting a hosted SaaS tool with boards, roadmap, and changelog.

See how it compares: [Quackback vs Upvoty](/compare/quackback-vs-upvoty).

## 7. Sleekplan

[Sleekplan](/compare/quackback-vs-sleekplan) takes a widget-first approach to feedback. Instead of sending users to a separate portal, Sleekplan embeds directly into your app as an in-app widget. Users can submit feedback, vote on ideas, read your changelog, and respond to satisfaction surveys without leaving your product.

![Sleekplan feedback widget interface](/blog/best-canny-alternatives/sleekplan.webp)

The built-in CSAT and NPS surveys are a differentiator. Most feedback tools treat surveys as a separate concern. Sleekplan includes them natively, so you can measure satisfaction alongside feature requests. The AI features ("Sleek Intelligence") on paid plans handle basic categorization and insights.

The free Indie plan is limited: one seat, no roadmap, no surveys, no AI. The Starter plan ($13/mo) unlocks the roadmap, surveys, and AI credits. The Business plan ($38/mo) adds post merging, user segmentation, and conditional surveys.

**Key features:**
- Feedback board with voting, status updates, and impact scoring
- Changelog with scheduled posting and subscriber notifications
- Roadmap (Starter plan and above)
- Built-in CSAT and NPS surveys
- Embeddable in-app widget, standalone site, or iframe
- 12 integrations: Jira, Linear, Slack, Intercom, GitHub, Zapier, and more

**Pricing:** Free Indie plan (1 seat, limited). Starter at $13/mo. Business at $38/mo. Enterprise is custom.

**Pros:**
- In-app widget reduces friction for feedback submission
- Built-in NPS/CSAT surveys
- Free tier available
- Affordable paid plans

**Cons:**
- Free plan is very limited (no roadmap, no surveys, no AI)
- Widget-first means the standalone portal is less polished
- Post merging requires Business plan ($38/mo)
- No self-hosting, no open source
- No duplicate detection on the public board

**Best for:** Teams prioritizing in-app feedback collection with built-in satisfaction surveys.

See how it compares: [Quackback vs Sleekplan](/compare/quackback-vs-sleekplan).

## Comparison table

Here's how all seven alternatives stack up against Canny on the features that matter most.

| | Canny | Quackback | Featurebase | Productboard | Nolt | Fider | Upvoty | Sleekplan |
|---|---|---|---|---|---|---|---|---|
| **Starting price** | Free (25 tracked users) | Free | Free (1 seat) | Free (limited) | $29/mo | Free | $15/mo | Free (1 seat) |
| **Open source** | No | Yes (AGPL-3.0) | No | No | No | Yes (AGPL-3.0) | No | No |
| **Self-hosting** | No | Yes | No | No | No | Yes | No | No |
| **AI features** | Autopilot (all plans) | Yes (built-in) | Fibi ($0.49/resolution) | Included via credits (250/maker/mo) | No | No | No | Starter plan+ |
| **Changelog** | Yes | Yes | Yes | No | No | No | Yes | Yes |
| **Free tier** | Yes (25 tracked users) | Free (open source) | Yes (1 seat) | No | No | Yes (250 items) | No | Yes (1 seat) |
| **User limits** | 25 tracked (Free), 100+ (Core/Pro) | None | None on free | None (Spark) | None | 250 items (free cloud) | None | None |

## How to choose

Start with your constraints. Budget, technical capacity, and what you actually need today.

**If cost is the priority:** Quackback is free to self-host with no user limits. Fider is also free and open source but covers less ground. Among hosted options, Sleekplan ($13/mo) and Upvoty ($15/mo) are the most affordable paid tools.

**If you want open source:** Quackback and Fider are your options. Quackback gives you the full feature set — boards, roadmap, changelog, 25 integrations, AI, MCP server. Fider covers basic voting boards. Both deploy with Docker.

If you want a tool you won't outgrow, Quackback is the stronger choice.

**If you need enterprise product management:** Productboard is purpose-built for product strategy at scale. It's expensive and complex, but nothing else on this list connects feedback to opportunity scoring, driver-based roadmaps, and company objectives the way Productboard does.

**If you want simplicity:** Nolt and Upvoty are the lightest hosted options. Nolt is the simpler of the two. Upvoty gives you a changelog on top of boards and roadmap. Neither has AI, but both have predictable pricing.

**If you want in-app feedback:** Sleekplan's widget-first approach makes it the best choice for collecting feedback inside your product. The built-in NPS/CSAT surveys are a bonus that most other tools don't include.

**If you're migrating from Canny:** The most common reasons teams leave Canny are tracked-user pricing, the limited free plan, and lack of self-hosting. Quackback addresses all three. It's free, has no user limits, and self-hosts on your infrastructure.

The feature set covers the same ground: boards, voting, roadmap, changelog, integrations, and SSO. See the [full Canny vs Quackback comparison](/compare/quackback-vs-canny) for a detailed breakdown.

For a broader look at the feedback tool landscape, see [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026) and [Open Source Feedback Tools](/blog/open-source-feedback-tools).

## Frequently asked questions

### What is the best free alternative to Canny?

[Quackback](https://quackback.io) is the most full-featured free alternative. It is open source (AGPL-3.0), free to self-host, and includes feedback boards, voting, roadmap, changelog, 25 integrations, SSO/OIDC, and AI, with no tracked-user limits. Featurebase and Sleekplan offer limited free hosted tiers.

### Why are people switching from Canny?

Three changes in 2025 drove the migration: Canny moved to tiered tracked-user pricing in May 2025, making costs unpredictable as your user base grows; the free plan caps at 25 tracked users; and Canny remains closed source with no self-hosting option, locking teams into its pricing model.

### Is there an open-source Canny alternative?

Yes. Quackback is the closest open-source equivalent to Canny. It covers the same core workflow — feedback boards, voting, roadmap, changelog, integrations, SSO — and adds AI features and an [MCP server](/features/mcp) that Canny doesn't offer.

Fider is another open-source option, though it only covers basic voting boards without a changelog, roadmap, or AI. Both self-host with Docker. For a deeper comparison, see [Open Source Feedback Tools](/blog/open-source-feedback-tools).

### Can I migrate from Canny to another tool?

Canny provides data export, so you can extract your posts, votes, comments, and user data. The migration process depends on which tool you're moving to. You'll need to map users, votes, statuses, and comments to the new platform.

The longer you've been on Canny, the more data you'll need to move. Some tools offer import assistance — check the [Quackback docs](/docs) for migration guidance.

### What is the cheapest Canny alternative?

For self-hosted: Quackback is free with no limits. You pay only for your own infrastructure (a small VPS typically costs $5–20/month). For hosted SaaS: Sleekplan starts at $13/mo, Upvoty at $15/mo, and Nolt at $29/mo. All three avoid Canny's tiered tracked-user pricing model, so your costs stay predictable as your user base grows.

- [Productboard Pricing 2026: Plans, Costs & Alternatives](https://quackback.io/blog/productboard-pricing): Productboard pricing in 2026. The Spark plan, credit-based AI, per-maker costs, and cheaper alternatives for product teams on a budget.

Published: 2026-03-12

Productboard is an enterprise product management platform built around a specific idea: connect customer insights directly to product strategy. It does this well. Feedback from support tickets, sales calls, and NPS surveys flows into a centralized insights repository. Product managers can then link those insights to features, score priorities using customizable frameworks, and communicate decisions through visual roadmaps.

![Productboard pricing plans breakdown](/blog/productboard-pricing/hero.webp)

> **Productboard pricing in 2026** centers on a single plan called Spark at $15/maker/mo (annual) or $19/maker/mo (monthly), with AI included via a credits system (250 credits per maker per month). The old Essentials/Pro/Scale/Enterprise tiers are no longer listed, and SSO still requires custom Enterprise pricing. Free alternatives exist: [Quackback](https://quackback.io) is open source, available self-hosted for free or as a managed cloud.
>
> *Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

The platform has carved out a strong position with mid-market and enterprise product teams. Companies like Zendesk, Microsoft, and UiPath use it. The product-market fit is real, especially for organizations that struggle to connect what customers are saying to what the product team is building.

But Productboard's pricing still reflects that enterprise positioning. Plans are billed per maker, credits limit how much AI you can use, and key integrations may require contacting sales for custom pricing. If you're evaluating Productboard in 2026, this guide breaks down exactly what it costs, what the Spark plan includes, and where the alternatives stand.

## Productboard pricing plans

Productboard revamped its pricing in 2026 around a single product called **Spark**. The old tiered structure (Essentials, Pro, Scale, Enterprise) is no longer listed on the pricing page. Enterprise pricing is still available through sales.

| Plan | Price | Credits | Key Features |
|------|-------|---------|--------------|
| **Spark** | $15/maker/mo (annual) or $19/maker/mo (monthly) | 250 credits/maker/month | Feedback portal, insights, feature prioritization, roadmaps, AI (via credits) |
| **Enterprise** | Custom pricing | Custom | SSO/SAML, advanced security, custom roles, dedicated support, audit log, custom credit limits |

The Spark plan consolidates what was previously spread across Essentials and Pro. You get the feedback portal, prioritization boards, roadmap views, and AI features in a single tier. AI is no longer a separate add-on — it runs on a credits system, with 250 credits per maker per month included. New signups also get 150 free credits to trial AI features.

The credits power all AI interactions in Productboard: insight extraction, summarization, semantic search, and auto-linking. How quickly you burn through credits depends on usage volume. Teams that rely heavily on AI-driven feedback analysis may find 250 credits per maker constraining, particularly at scale.

Enterprise pricing is not publicly listed. For organizations that need SSO/SAML, advanced security, custom roles, and dedicated support, you still contact sales for custom pricing.

## What is a maker?

A maker is Productboard's billing unit. Anyone who creates, edits, or manages content in Productboard counts as a maker. This includes product managers, product owners, designers who update feature specs, and engineering leads who manage roadmap items.

Productboard also offers a contributor role. Contributors can view roadmaps, submit feedback through the portal, and leave comments, but they cannot create or edit features, modify prioritization scores, or manage the roadmap. Contributors are free and do not count toward your maker limit.

This distinction matters for budgeting. If you have a 10-person product team where 5 PMs actively manage the backlog and 5 engineers just need visibility, you pay for 5 makers. The 5 engineers use contributor access at no cost.

The challenge is that the maker role is broadly defined. A designer who occasionally updates a feature description counts as a maker. A support lead who logs customer feedback directly into the system rather than through the portal counts as a maker. As your organization adopts Productboard more deeply, the number of people who need maker access tends to grow beyond the original product team.

## Productboard pricing at scale

Here's what Productboard costs across team sizes on the Spark plan, based on the published annual pricing of $15/maker/mo.

![Productboard pricing at scale by team size](/blog/productboard-pricing/cost-at-scale.webp)

| Makers | Spark (Annual) | Spark (Monthly) | Credits/Month | Annual Cost |
|--------|---------------|-----------------|---------------|-------------|
| 5 | $75/mo | $95/mo | 1,250 | $900/yr |
| 10 | $150/mo | $190/mo | 2,500 | $1,800/yr |
| 25 | $375/mo | $475/mo | 6,250 | $4,500/yr |
| 50 | $750/mo | $950/mo | 12,500 | $9,000/yr |

At 10 makers on the annual Spark plan, you're paying $1,800/yr. At 25 makers, it's $4,500/yr. For a 50-person product organization, annual costs reach $9,000 on the base plan. Enterprise pricing for organizations needing SSO, advanced security, and custom credit limits will be higher.

These numbers assume base Spark pricing. If your team needs more AI credits than the included 250 per maker per month, or requires enterprise features, costs increase from there.

## Hidden costs

The plan prices above don't capture the full cost of running Productboard. Several expenses add up beyond the per-maker fee.

**AI credits may not be enough.** Productboard now includes AI via a credits system — 250 credits per maker per month on the Spark plan. Credits power insight extraction, summarization, semantic search, and auto-linking. This is an improvement over the old model where AI was a separate paid add-on. But 250 credits per maker may not go far for teams that process high volumes of feedback. If you exhaust your credits before the month ends, you either wait or negotiate additional credits with sales.

**Key integrations may require enterprise pricing.** Under the old tier structure, integrations like Salesforce and Zendesk were locked behind higher plans. With Spark consolidating the tiers, check whether the integrations you need are included or require an enterprise agreement. If your team relies on Salesforce opportunity data to prioritize features, confirm this is covered before committing.

**SSO requires Enterprise.** SAML SSO is only available on the Enterprise plan. For organizations with security policies that mandate SSO for all SaaS tools, this means skipping directly to custom Enterprise pricing. Even if your product team is small, the security requirement forces you into the most expensive tier.

**No self-hosting option.** Productboard is a hosted SaaS product. There is no on-premises or self-hosted deployment option. Your product data, customer feedback, and roadmap strategy live on Productboard's infrastructure. If you operate in a regulated industry or have data residency requirements, this is a constraint worth noting.

**Annual contracts are the norm.** While Productboard offers monthly billing, discounts are structured around annual commitments. Annual contracts mean committing thousands of dollars upfront. If your needs change within the first few months, you may still be locked into the annual term.

**Onboarding and training overhead.** Productboard is a deep tool with a learning curve. Setting up prioritization frameworks, configuring integrations, importing existing feedback, and training your team takes time. For large organizations, Productboard offers paid onboarding services. Even without paid services, the internal time investment is significant. Expect 2-4 weeks before your team is fully productive.

## Free and cheaper alternatives

If Productboard's pricing exceeds your budget, or if you want to avoid per-maker billing entirely, these alternatives cover the core feedback-to-roadmap workflow at a fraction of the cost.

### Quackback

[Quackback](https://quackback.io) is open source (AGPL-3.0), free to self-host, and also available as a managed cloud from $29/mo billed annually. It covers feedback boards, voting, a [public roadmap](/features/roadmap), changelogs, and 25 integrations. AI features, SSO/OIDC, custom branding, and an [MCP server](/features/mcp) are included free on every self-hosted installation. On Cloud, Quinn is included on paid plans, and SSO is self-serve on Enterprise. Self-host with Docker or deploy on Railway. See the [full comparison of Quackback vs Productboard](/compare/quackback-vs-productboard).

Quackback does not replicate Productboard's strategic planning layer (objectives alignment, capacity planning, portfolio roadmaps). If those features are critical to your workflow, Productboard may still be the right fit. For teams whose primary need is collecting and organizing customer feedback, Quackback covers that workflow.

### Canny

[Canny](/compare/quackback-vs-canny) offers a free plan (25 tracked users) and paid tiers starting at $19/mo (Core). It covers feedback boards, voting, roadmaps, and changelogs with a polished interface. The billing model uses tiered pricing based on tracked users rather than per maker. Small teams with limited feedback volume can use Canny's free plan or Core tier affordably. But costs increase as you cross tracked user thresholds, with auto-upgrades to the next tier. The free plan caps at 25 tracked users. PM integrations like Jira require the Pro plan at $79/mo. See the [full comparison of Quackback vs Canny](/compare/quackback-vs-canny).

### Featurebase

[Featurebase](/compare/quackback-vs-featurebase) offers a free plan with 1 seat and limited features. Paid plans start at $29/seat/mo. The platform bundles feedback boards, a changelog, roadmap, and a support inbox into one tool. It's closed source and hosted only. The AI agent (Fibi) charges $0.49 per resolution on top of your plan cost. It covers more of the workflow than Canny but less of the strategic layer than Productboard.

### Nolt

[Nolt](/compare/quackback-vs-nolt) takes a simpler approach with flat-rate pricing at $29/mo per board (billed annually). No per-user billing. The feature set is minimal: feedback boards and voting with basic integrations. No changelog, no AI features, and development has slowed in recent years. It works for teams that want a simple, predictable-cost feedback board and nothing more.

## Cost comparison table

Here's how Productboard compares to alternatives on the features and pricing dimensions that matter most.

| | Productboard | Quackback | Canny | Featurebase | Nolt |
|---|---|---|---|---|---|
| **Starting price** | $15/maker/mo (annual) | Free self-hosted / $29/mo Cloud | Free (25 tracked users) | Free (1 seat) | $29/mo |
| **Pricing model** | Per maker | Workspace (Cloud) or free self-hosted | Tiered by tracked users | Per seat | Per board |
| **Cost for 10-person team** | $150/mo (Spark annual) | $59/mo Cloud Business (20 seats) | $79+/mo (Pro tier) | $29/seat/mo (scales per paid seat) | $29/mo (1 board) |
| **Self-hosting** | No | Yes (Docker) | No | No | No |
| **Open source** | No | Yes (AGPL-3.0) | No | No | No |
| **AI features** | Included via credits (250/maker/mo) | Included | Autopilot (all plans) | Fibi ($0.49/resolution) | No |
| **MCP server** | No | Yes | No | No | No |
| **SSO** | Enterprise only (custom pricing) | Free self-hosted · Enterprise on Cloud | Business plan (custom pricing) | Professional ($59/seat/mo) | All paid plans |
| **Integrations** | Included on Spark (enterprise integrations may require custom pricing) | 20+ included | PM integrations on Pro ($79/mo) | 12 included | 8–12 |
| **Roadmap** | Yes (advanced, multi-view) | Yes (public) | Yes | Yes | No |
| **Prioritization frameworks** | Yes (custom scoring) | Community voting | Community voting | Community voting | Community voting |

Productboard's advantage is the strategic planning layer: custom prioritization scores, objectives alignment, capacity planning, and portfolio-level roadmaps. If your product organization needs that, Productboard delivers it. The alternatives listed here focus on the feedback collection and prioritization workflow and do it at a lower cost, but they don't replace Productboard's product strategy features.

For teams whose primary need is collecting customer feedback, organizing it, and sharing a roadmap, the cost difference between Productboard and simpler tools is worth evaluating carefully. A 10-maker Spark subscription costs $1,800/yr. Self-hosted and flat-rate alternatives cover the core feedback workflow at a fraction of that cost, or for free.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Does Productboard have a free plan?

No. Productboard does not offer a free plan. The cheapest option is the Spark plan at $15/maker/mo (annual) or $19/maker/mo (monthly). New signups get 150 free credits to trial AI. For a free tool, [Quackback](https://quackback.io) is open source and free to self-host.

### How does Productboard's per-maker pricing work?

A maker is anyone who creates, edits, or manages content in Productboard, including product managers, designers, and engineering leads. Contributors who only view roadmaps and submit feedback are free. On Spark, your monthly cost equals makers multiplied by $15 (annual) or $19 (monthly), each with 250 AI credits.

### Is Productboard AI included in the base price?

Yes. Under the Spark plan, AI features are included via a credits system. Each maker gets 250 credits per month, which power insight extraction, summarization, semantic search, and auto-linking. AI is no longer a separate paid add-on. The constraint is credit volume: heavy AI usage may find 250 credits per maker limiting.

### Can I self-host Productboard?

No. Productboard is a hosted SaaS product with no self-hosting or on-premises deployment option. Your data lives on Productboard's infrastructure. If you need self-hosted product management, [Quackback](/compare/quackback-vs-productboard) is open source and runs on your own servers with Docker.

### What is the best alternative to Productboard for small teams?

For small teams focused on feedback collection and prioritization, [Quackback](https://quackback.io) is the most cost-effective alternative. It is open source, free to self-host, and includes [feedback boards](/features/feedback), voting, a [public roadmap](/features/roadmap), changelogs, AI features, and 25 integrations.

For a full rundown of alternatives, see [Best Productboard Alternatives](/blog/best-productboard-alternatives), [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026), [Open Source Feedback Tools](/blog/open-source-feedback-tools), and [Feedback Tool Pricing Comparison](/blog/feedback-tool-pricing-comparison). For teams that need Productboard's advanced features (custom prioritization frameworks, objectives alignment, capacity planning) but want to evaluate alternatives first, the [Quackback vs Productboard comparison](/compare/quackback-vs-productboard) breaks down the differences feature by feature.

- [UserVoice Pricing in 2026: Plans, Costs, and Alternatives](https://quackback.io/blog/uservoice-pricing): A detailed breakdown of UserVoice pricing in 2026. Enterprise plans starting at $16,000/year, annual commitments, and cheaper alternatives for smaller teams.

Published: 2026-03-11

UserVoice is one of the original feedback management platforms. Founded in 2008, it helped establish the category that tools like Canny, Productboard, and Quackback now occupy. For nearly two decades, it has served enterprise product teams that need to collect feature requests, prioritize by revenue impact, and close the loop with customers.

![UserVoice pricing breakdown](/blog/uservoice-pricing/hero.webp)

> **UserVoice pricing starts at $16,000/year (~$1,333/mo)** with annual billing and no self-service signup. There are no visible tiered plans — pricing is custom based on monthly feedback volume and integrations, with no per-seat charges and a 30-day free trial. Free alternatives exist: [Quackback](https://quackback.io) is open source with a managed cloud, so you can start with a 14-day free trial in the cloud or self-host at no cost.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

The platform does genuine things well. Revenue-linked prioritization lets you connect Salesforce or HubSpot data and see which feature requests carry the most ARR behind them. NLP-powered feedback analysis surfaces themes across thousands of submissions. Internal feedback capture gives sales and support teams a structured way to relay what customers are asking for, without flooding product managers with unstructured Slack messages.

But UserVoice's pricing reflects its enterprise positioning. The entry point is $16,000/year (~$1,333/mo) with annual billing. There is no free plan and no self-service signup — you "Talk to an Expert" to get started, though a 30-day free trial is available. If you're a startup, a small team, or a mid-size company exploring feedback tools, the cost alone may rule UserVoice out.

This guide breaks down what UserVoice costs in 2026, what you get at each tier, and where the alternatives stand.

## UserVoice pricing structure

UserVoice no longer publishes tiered plans on its pricing page. Instead, pricing starts at $16,000/year and scales based on monthly feedback volume and integrations. There are no per-seat charges — anyone in your organization can access the platform. You go through a sales process ("Talk to an Expert") to get a custom quote. A 30-day free trial is available.

### What you get

The platform includes a single product with features that scale based on your contract:

- Centralized feedback portal for collecting feature requests
- Feedback capture tools for internal and external submissions
- Communications suite for closing the loop with customers
- Quantitative feedback data enhancement
- Taxonomy, filtering, and sorting
- Customer segmentation
- Security and compliance features
- Expert onboarding

### Pricing factors

UserVoice does not publish a fixed feature matrix with visible tiers. Based on the current pricing page, your cost depends on:

- **Monthly feedback volume** — the number of feedback submissions your portal processes
- **Integrations** — which CRM and support tool connections you need
- **Organization size** — though there are no per-seat charges

The $16,000/year starting point (~$1,333/mo) is the floor. Larger organizations with high feedback volume, advanced integrations (Salesforce, HubSpot), and enterprise security requirements will pay more. Annual billing is standard.

### What changed from previous pricing

UserVoice previously published three visible tiers: Essentials ($999/mo), Premium ($1,500–2,500/mo estimated), and Enterprise ($3,000–5,000+/mo). The current pricing page no longer shows these tiers. The entry price has increased from $999/mo ($11,988/year) to $16,000/year (~$1,333/mo). UserVoice also now offers a 30-day free trial, which was not previously available, and highlights that there are no per-seat charges.

## Why UserVoice is expensive

UserVoice's pricing is a direct consequence of its positioning. The company targets enterprise product teams at companies with 200+ employees. It is not trying to compete with Canny on the low end or with free tools like Quackback for startups.

**Annual billing at $16,000/year.** The minimum annual commitment is $16,000. While UserVoice now offers a 30-day free trial, the jump from trial to paid is significant. There is no monthly billing option.

**No self-service signup.** You cannot create an account, enter a credit card, and start using UserVoice. Every new customer goes through a "Talk to an Expert" sales process. A 30-day trial is available after that conversation, but you still need to engage with sales before evaluating the product.

**Long onboarding cycles.** UserVoice implementations often involve configuration, data migration, CRM integration, and team training. The platform assumes you'll have a dedicated rollout period. Expert onboarding is listed as a core feature. For teams that want to start collecting feedback today, this timeline is a poor fit.

**Deep CRM integrations require investment.** The revenue-linked prioritization that makes UserVoice unique depends on a properly configured Salesforce or HubSpot integration. Setting this up, mapping account data to feedback, and maintaining the connection over time requires ongoing effort from your ops team.

**No per-seat charges is a plus.** One thing in UserVoice's favor: there are no per-seat charges. Anyone in your organization can access the platform without adding to the bill. This is better than per-seat models where adding a product manager costs $19–59/month.

These factors contribute to a total cost of ownership that goes beyond the annual subscription. When evaluating UserVoice, factor in onboarding time, integration setup, and the implementation timeline alongside the subscription cost.

## UserVoice pricing at scale

Here's what UserVoice costs at different commitment levels.

![UserVoice annual pricing at scale](/blog/uservoice-pricing/cost-at-scale.webp)

| Scenario | Annual Cost | 3-Year Cost |
|----------|-------------|-------------|
| **Entry (minimum)** | $16,000 | $48,000 |
| **Mid-range (est.)** | $25,000–40,000 | $75,000–120,000 |
| **Enterprise (est.)** | $50,000–80,000+ | $150,000–240,000+ |

At the entry level, you're spending $16,000/year for a feedback portal with custom pricing based on volume. Over three years, that's $48,000.

For organizations with higher feedback volume and advanced CRM integrations, expect annual costs of $25,000–40,000 or more. Over three years, that's $75,000–120,000.

## Hidden costs

The subscription price is only part of what UserVoice costs.

**Annual commitment upfront.** The minimum annual cost is $16,000. UserVoice now offers a 30-day free trial, which is an improvement over previous years. But once you commit, you're locked into an annual contract. If you decide after two months that UserVoice isn't the right fit, you've already committed for the year.

**Implementation and onboarding time.** UserVoice is not a tool you configure in an afternoon. Teams report onboarding timelines of 2–6 weeks, depending on integration complexity. During this time, you're paying for the subscription but not yet collecting feedback at full capacity. If your team bills internally for engineering and ops time, add that to the total cost.

**No self-hosting option.** UserVoice is a hosted SaaS product with no on-premises deployment. For teams with strict data residency requirements, this is a constraint worth noting.

**CRM integration maintenance.** The revenue-linked prioritization feature requires a live connection to your CRM. Salesforce and HubSpot integrations need ongoing maintenance: field mapping updates, permission changes, data sync monitoring. This is invisible work that adds to total cost of ownership.

**No native changelog.** UserVoice does not include a changelog feature. If you want to announce shipped features and notify voters, you'll need a separate tool. This adds another subscription and another integration to maintain.

## Free and cheaper alternatives

UserVoice is the right tool for a specific type of organization: large enterprises with CRM-driven prioritization needs and budget to match. For everyone else, there are alternatives that deliver the core feedback workflow at a fraction of the cost, or for free.

### Quackback

[Quackback](https://quackback.io) is open source (AGPL-3.0) with a managed cloud you can [try free for 14 days](https://quackback.io). It covers feedback boards, [voting](/features/voting), a public [roadmap](/features/roadmap), [changelogs](/features/changelog), and 25 integrations. SSO/OIDC, an [MCP server](/features/mcp), and custom branding are included free on every self-hosted installation; on Cloud, MCP starts on the Pro plan and SSO on the self-serve Enterprise plan. Prefer to self-host? Run it with Docker or deploy on Railway at no cost. See the [full comparison of Quackback vs UserVoice](/compare/quackback-vs-uservoice).

### Canny

[Canny](/compare/quackback-vs-canny) offers a free plan (25 tracked users) and paid tiers starting at $19/mo (Core). It covers feedback boards, voting, roadmaps, and changelogs. The interface is polished and onboarding takes minutes, not weeks. The trade-off is tiered tracked-user pricing: your costs increase as you cross tracked user thresholds, with auto-upgrades to the next tier. Still far less than UserVoice, but costs can grow as your feedback community scales. See the [Quackback vs Canny comparison](/compare/quackback-vs-canny).

### Featurebase

[Featurebase](/compare/quackback-vs-featurebase) bundles feedback boards, a changelog, roadmap, and support inbox into one tool. A free plan exists (1 seat, limited features). Paid plans start at $29/seat/month. The AI agent charges $0.49 per resolution on top of plan cost. It's closed source and hosted only. See the [Quackback vs Featurebase comparison](/compare/quackback-vs-featurebase).

### Nolt

[Nolt](/compare/quackback-vs-nolt) offers flat-rate pricing at $29/mo for a single feedback board (billed annually). No tracked-user billing, no per-seat charges. The feature set is limited: no changelog, no AI, and the product has seen minimal updates recently. Per-board pricing means costs multiply if you run multiple products.

### Fider

[Fider](/compare/quackback-vs-fider) is open source and free to self-host. It covers the basics: feedback boards, voting, comments, and tags. Built on Go and PostgreSQL, it runs with Docker. The feature set is smaller than Quackback or Canny. No changelog, no roadmap view, no AI features, and limited integrations. But it costs nothing to run.

## Cost comparison table

| | UserVoice | Quackback | Canny | Featurebase | Nolt |
|---|---|---|---|---|---|
| **Starting price** | $16,000/yr (~$1,333/mo) | Free | Free (25 tracked users) | Free (1 seat) | $29/mo |
| **Billing model** | Annual (custom) | Free / self-hosted | Tiered by tracked users | Per seat | Per board |
| **User limits** | No per-seat charges | None | 25 (Free), 100+ (Core/Pro) | None on free | None |
| **Self-hosting** | No | Yes (Docker) | No | No | No |
| **Open source** | No | Yes (AGPL-3.0) | No | No | No |
| **SSO** | Enterprise only | Free self-hosted · Enterprise on Cloud | Business (custom pricing) | $59/seat/mo plan | All paid plans |
| **AI features** | NLP (Premium+) | Included | Autopilot (all plans) | $0.49/resolution | No |
| **Changelog** | No | Yes | Yes | Yes | No |
| **Revenue prioritization** | Yes (Premium+) | No | No | No | No |
| **MCP server** | No | Yes | No | No | No |
| **Annual cost (entry tier)** | $16,000 | $0 | $0 (free plan) or $228 (Core) | $0 | $300 |
| **Free trial** | 30 days | N/A (free) | No | No | No |

UserVoice sits at the high end of the market. At $16,000/year for the entry tier, it is the most expensive standalone feedback tool available. Teams that need revenue-linked prioritization with CRM data may find the cost worthwhile. Teams that primarily need feedback boards and voting have less expensive options.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Does UserVoice have a free plan or free trial?

UserVoice does not offer a free plan. However, it now offers a 30-day free trial. You still need to go through the "Talk to an Expert" sales process to get started, but you can evaluate the product before committing to a paid contract. This is an improvement over previous years when no trial was available.

### What is the minimum cost to start using UserVoice?

The minimum cost is $16,000/year (~$1,333/mo), billed annually. There are no per-seat charges — anyone in your organization can access the platform. You cannot pay monthly. This makes UserVoice the most expensive entry point among mainstream feedback tools.

### Is UserVoice worth $16,000/year?

It depends on your organization. Enterprises needing revenue-weighted prioritization with a mature Salesforce integration get features cheaper tools lack, plus no per-seat charges. For startups and small teams that mainly need feedback boards and voting, $16,000/year is hard to justify when [open-source alternatives](/blog/open-source-feedback-tools) deliver the core workflow free.

### Can I migrate from UserVoice to a cheaper alternative?

Yes. UserVoice supports CSV data export. Quackback has a dedicated [UserVoice import tool](/docs/guides/migrate-from-another-tool) that maps UserVoice fields to Quackback fields. You can migrate posts, votes, and metadata. The process takes minutes for the data import, though you'll need time to reconfigure integrations and retrain your team.

### What are the best UserVoice alternatives for small teams?

For small teams and startups, consider [Quackback](https://quackback.io) (free, open source, self-hosted), Canny (free plan or $19/mo Core), or Nolt ($29/mo flat rate). All three let you start collecting feedback within minutes and cost a fraction of UserVoice's entry price. For a deeper comparison, see [Best UserVoice Alternatives](/blog/best-uservoice-alternatives) and [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026).

- [Canny Pricing 2026: Plans, Costs & Free Alternatives](https://quackback.io/blog/canny-pricing): Canny's pricing plans in 2026: tiered tracked-user costs, plan limits, hidden fees at scale, and free, open-source alternatives for teams on a budget.

Published: 2026-03-10

Canny is one of the most popular feedback management tools on the market. It has been around since 2017 and covers the standard workflow: feature request boards, voting, roadmaps, and changelogs. Thousands of SaaS teams use it to collect and prioritize user feedback.

![Canny pricing breakdown and cost analysis](/blog/canny-pricing/hero.webp)

> **Canny has a free plan (25 tracked users) and paid plans starting at $19/mo billed annually.** Costs rise as you exceed tracked-user limits and get auto-upgraded to the next tier, and SSO is locked to the custom-priced Business plan. Free alternatives exist — [Quackback](https://quackback.io) is open source and self-hosted at no cost.
>
> *Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

In May 2025, Canny overhauled its pricing model. The company moved from per-admin billing to tiered pricing based on tracked users, a shift that changes how much you pay and when costs increase. If you're evaluating Canny in 2026 or checking whether your current plan still makes sense, this guide breaks down exactly what Canny costs, what you get at each tier, and where the hidden expenses show up.

## Canny's pricing plans

Canny offers a free plan and three paid tiers in 2026.

| Plan | Monthly Price | Tracked Users | Managers | Key Features |
|------|--------------|---------------|----------|--------------|
| Free | $0 | 25 | 5 | Feedback boards, voting, roadmap, changelog, Autopilot AI, unlimited posts |
| Core | $19/mo (billed annually) | 100+ | 5 | Custom domains, content translations, Autopilot AI |
| Pro | $79/mo (billed annually) | 100+ | 10 | PM integrations (Jira, ClickUp, Linear), advanced privacy, Autopilot AI |
| Business | Custom pricing | 5,000+ | Custom | SSO/SAML, CRM integrations, dedicated support, white-label |

A few things to note. The free plan exists but caps you at 25 tracked users with limited features. Most teams outgrow it quickly. The Core plan at $19/mo is the first paid tier with 100+ tracked users and 5 managers. If you need PM integrations like Jira, ClickUp, or Linear, you need the Pro plan at $79/mo. The Business plan is the only tier that includes SSO, which matters for any team with enterprise security requirements. Business pricing is custom — you need to contact sales.

Autopilot AI (feedback discovery, deduplication, smart replies, comment summaries) is included on all plans, including the free tier.

## What are tracked users?

Tracked users are the core of Canny's billing model. A tracked user is anyone who has a post, vote, or comment attributed to them in your Canny workspace. It doesn't matter whether the person is an active user of your product or someone who voted on a feature request six months ago and never came back. Once they're tracked, they count toward your limit.

Canny uses tiered pricing with tracked user limits. Each plan tier includes a set number of tracked users. If you exceed your tier's limit, Canny auto-upgrades you to the next tier. You can set spend caps to prevent unexpected upgrades, but by default your costs grow as engagement grows. A five-person startup with 2,000 users submitting feedback pays more than a fifty-person company with 50 internal users on the board.

The trade-off is that costs can increase when you cross tier thresholds. If you launch a public roadmap and a feature request gets traction on social media, each new voter becomes a tracked user. Your tracked user count could push you into a higher tier, driven by a single popular post rather than overall product growth.

Another scenario: you integrate Canny with your support tool (Intercom, Zendesk, Help Scout). Canny's Autopilot discovers feedback in support conversations and attributes it to the customer. Each attributed customer becomes a tracked user. The more support tickets you process, the faster your tracked user count grows.

There's no easy way to "un-track" users in bulk. Once someone is counted, reducing your tracked user count requires manual cleanup or waiting for Canny's periodic recalculation. This makes it difficult to bring costs back down after a spike.

## Canny pricing at scale

Canny uses tiered pricing with tracked user limits at each tier. The free plan allows 25 tracked users. Core starts at $19/mo with 100+ tracked users. Pro starts at $79/mo with 100+ tracked users and more managers. If you exceed your tier's tracked user limit, Canny auto-upgrades you to the next tier (though you can set spend caps to prevent this).

![Canny pricing at scale compared to Quackback](/blog/canny-pricing/cost-at-scale.webp)

| Tracked Users | Free | Core (Est.) | Pro (Est.) | Business |
|--------------|------|-------------|------------|----------|
| 25 | $0/mo | — | — | — |
| 100 | — | $19/mo | $79/mo | Custom |
| 500 | — | Higher tier | Higher tier | Custom |
| 1,000 | — | Higher tier | Higher tier | Custom |
| 5,000+ | — | — | — | Custom |

Canny's exact per-tier pricing above the base is not fully published. As your tracked user count grows, you move into higher tiers within your plan, and costs increase accordingly. The Business plan requires 5,000+ tracked users and uses custom pricing.

The key takeaway: costs are predictable within a tier but increase as you cross tracked user thresholds. Teams with thousands of active feedback users should expect significant monthly costs. The auto-upgrade mechanism means your bill can increase without explicit approval unless you set spend caps.

## Hidden costs to consider

The sticker price on Canny's pricing page doesn't tell the full story. Here are the costs that catch teams off guard.

**Tracked users accumulate over time.** Even if a user hasn't interacted with your feedback board in months, they may still count toward your tracked user limit. Your bill reflects the total number of tracked users, not just the active ones. Over the life of your product, this number only goes up.

**Auto-upgrade risk.** If you exceed your tier's tracked user limit, Canny automatically upgrades you to the next tier. You can set spend caps to prevent this, but the default behavior means your bill can increase without explicit approval.

**AI Autopilot is included on all plans.** Canny's AI features (feedback discovery, deduplication, smart replies, comment summaries) are included on every plan, including the free tier. This is a strength — you don't pay extra for AI.

**SSO is locked to the Business plan.** If your organization requires SAML SSO for compliance or security, you need the Business plan with custom pricing. For teams that need SSO but don't need the other Business-tier features, this is an expensive gate.

**No self-hosting option.** Canny is a hosted SaaS product with no on-premises deployment. For teams with data residency requirements or a preference for self-managed infrastructure, this is a constraint.

**PM integrations require Pro.** Jira, ClickUp, and Linear integrations require the Pro plan at $79/mo. The Core plan includes custom domains and content translations but not PM tool integrations. Most teams need at least one PM integration from day one.

## Free and cheaper alternatives to Canny

If Canny's pricing doesn't fit your budget, or if you want to avoid tiered tracked-user pricing entirely, there are several alternatives worth considering.

### Quackback

[Quackback](https://quackback.io) is free, open source (AGPL-3.0), and self-hosted, with a managed [Quackback Cloud](/pricing) from $29/mo on annual billing if you would rather not run infrastructure. It covers [feedback boards](/features/feedback), [voting](/features/voting), a public [roadmap](/features/roadmap), [changelogs](/features/changelog), and 25 integrations. AI features and SSO/OIDC are included free on every self-hosted installation. On Cloud, Quinn is included on paid plans, and SSO is self-serve on Enterprise. A built-in [MCP server](/features/mcp) lets AI agents read and triage feedback directly, something Canny does not offer. Self-host with Docker or deploy on Railway. See the [full comparison of Quackback vs Canny](/compare/quackback-vs-canny).

### Fider

[Fider](/compare/quackback-vs-fider) is another open-source option. It covers the basics: feedback boards, voting, comments, and tags. It's built on Go and PostgreSQL and self-hosts with Docker. The feature set is smaller than Canny or Quackback — no changelog, no roadmap view, no AI features, and limited integrations. But it's free to run and the code is open. See the [comparison of Quackback vs Fider](/compare/quackback-vs-fider).

### Featurebase

[Featurebase](/compare/quackback-vs-featurebase) bundles feedback boards, a changelog, roadmap, and support inbox into one tool. It has a free plan (1 seat, limited features). Paid plans start at $29/seat/month. It's closed source and hosted only. The AI agent (Fibi) charges $0.49 per resolution on top of your plan cost. See the [comparison of Quackback vs Featurebase](/compare/quackback-vs-featurebase).

### Nolt

[Nolt](/compare/quackback-vs-nolt) offers flat-rate pricing starting at $29/mo for a single feedback board (billed annually). No tracked-user billing. The trade-off is a limited feature set: no changelog, no AI features, and the product has seen minimal updates in the past two years. Per-board pricing means costs multiply if you manage multiple products. See the [comparison of Quackback vs Nolt](/compare/quackback-vs-nolt).

## Cost comparison table

Here's how Canny stacks up against alternatives on the features that matter most.

| | Canny | Quackback | Featurebase | Nolt |
|---|---|---|---|---|
| **Starting price** | Free (25 tracked users) | Free self-hosted / $29/mo Cloud | Free (1 seat) | $29/mo |
| **First paid tier** | $19/mo (Core) | $29/mo (Cloud) | $29/seat/mo | $29/mo |
| **User limits** | 25 tracked users (Free), 100+ (Core/Pro) | None | None on free, seat-based on paid | None |
| **Pricing model** | Tiered by tracked users | Workspace (Cloud) or free self-hosted | Per seat | Per board |
| **Self-hosting** | No | Yes (Docker) | No | No |
| **Open source** | No | Yes (AGPL-3.0) | No | No |
| **AI features** | Autopilot (all plans) | Quinn on paid Cloud · BYOK self-host | Fibi ($0.49/resolution) | No |
| **MCP server** | No | Yes | No | No |
| **SSO** | Business plan (custom pricing) | Free self-hosted · Enterprise plan on Cloud | Professional plan ($59/seat/mo) | All paid plans |
| **Integrations** | PM integrations on Pro ($79/mo) | 25 included | 12 included | 8–12 (plan-dependent) |

Each billing model has trade-offs. Canny's tiered tracked-user model means costs increase as you cross user thresholds. Per-seat pricing (Featurebase) scales with team size. Flat-rate pricing (Nolt) stays predictable but offers fewer features. Self-hosted tools (Quackback, Fider) eliminate subscription costs but require infrastructure management.

## Is Canny worth it?

Canny is a mature product. The interface is polished. The integrations work well. Autopilot AI is included on all plans (including free) and adds real value for teams that process a lot of support conversations. The free plan is a reasonable starting point for small teams, and the Core plan at $19/mo is affordable for teams that need more than 25 tracked users.

The main concern is cost predictability at scale. Tiered pricing with tracked user limits means your costs increase as you cross thresholds, and auto-upgrades can catch you off guard without spend caps. SSO requires the Business plan (custom pricing). And because Canny is a hosted product, you depend on their pricing structure for as long as you use it.

For teams that want predictable costs or prefer to own their infrastructure, open-source tools like [Quackback](/compare/quackback-vs-canny) or [Fider](/compare/quackback-vs-fider) offer the core feedback workflow without tiered user billing. Flat-rate tools like Nolt offer another path to cost predictability.

The choice depends on what you value. Canny offers a polished, managed experience with strong AI features. Open-source and flat-rate alternatives offer cost control. Both are valid paths depending on your team's priorities.

For a broader comparison of feedback tools, see [Best Canny Alternatives](/blog/best-canny-alternatives), [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026), and [Open Source Feedback Tools](/blog/open-source-feedback-tools).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Does Canny have a free plan?

Yes. Canny's free plan includes 25 tracked users, 5 managers, unlimited posts, and Autopilot AI. The 25 tracked-user cap means most teams outgrow it quickly. The first paid tier is Core at $19/mo. Free open-source alternatives include [Quackback](https://quackback.io) and [Fider](/compare/quackback-vs-fider), both self-hosted.

### How does Canny's tracked-user pricing work?

A tracked user is anyone with a post, vote, or comment attributed to them in your Canny workspace. Each tier includes a set number of tracked users, and exceeding your limit auto-upgrades you to the next tier unless you set a spend cap. Costs grow with engagement.

### What is the cheapest Canny plan?

The free plan ($0/mo) is the entry point, with 25 tracked users, 5 managers, and Autopilot AI. The cheapest paid tier is Core at $19/mo (billed annually) for 100+ tracked users, custom domains, and content translations. PM integrations like Jira, ClickUp, and Linear require the Pro plan at $79/mo.

### Is Canny worth the price?

It depends on your scale and requirements. For small teams, the free plan or Core plan at $19/mo is reasonable, and Canny's polish, AI Autopilot, and integrations are real strengths. The main trade-offs are auto-upgrades when you exceed tracked-user limits, SSO locked to the Business plan, and no self-hosting.

### What is the best free alternative to Canny?

[Quackback](https://quackback.io) is the most complete free option: open source and self-hosted, with feedback boards, voting, a roadmap, changelogs, 25 integrations, SSO, and AI all included. [Fider](/compare/quackback-vs-fider) is also free and open source but lighter, covering voting boards, comments, and tags. See [Quackback vs Canny](/compare/quackback-vs-canny).

- [Best Changelog Tools and Software in 2026 (7 Compared)](https://quackback.io/blog/best-changelog-tools): Compare the 7 best changelog and release notes tools in 2026 on features, pricing, and trade-offs. Announce product updates and notify the users who asked.

Published: 2026-03-07

![Best changelog and release notes tools compared](/blog/best-changelog-tools/hero.webp)

> The best changelog tool depends on whether you need standalone announcements or a feedback-connected release workflow. Quackback is the best overall: it automatically notifies every voter when their requested feature ships, with AI-drafted release notes, and runs as open source self-hosted or managed cloud. Beamer and LaunchNotes are stronger if you need audience segmentation and marketing-grade announcements. The seven best changelog tools in 2026 ranked:
>
> 1. **[Quackback](https://quackback.io)** — Open source, self-hosted or cloud. AI-drafted release notes with automatic voter notifications.
> 2. **[Canny](/compare/quackback-vs-canny)** — Hosted changelog connected to feature request boards. Voters notified when entries publish.
> 3. **[Featurebase](/compare/quackback-vs-featurebase)** — Changelog that doubles as a knowledge base for the Fibi AI support agent.
> 4. **[Sleekplan](/compare/quackback-vs-sleekplan)** — Embeddable widget-first changelog with read tracking and satisfaction surveys.
> 5. **Beamer** — Standalone in-app notification tool with audience segmentation and push notifications.
> 6. **LaunchNotes** — Marketing-grade release announcements with multi-channel delivery and subscriber preferences.
> 7. **Headway** — Simple, lightweight changelog with in-app widget and emoji reactions.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

Your users want to know what changed. Every product update that ships without an announcement is a missed opportunity to build trust, reduce support tickets, and re-engage users who stopped paying attention.

A changelog is the simplest way to keep your users informed. When done well, it tells users what you shipped, why it matters, and what to do next. It reduces "is this feature available yet?" support tickets. It gives your team a visible record of progress. And it signals to customers that the product is alive and actively improving.

The problem is that most teams treat changelogs as an afterthought. They write release notes in a Google Doc, paste them into a Slack channel, and move on. Users never see them. The feedback loop stays broken.

A dedicated changelog tool solves this. It gives you a structured place to write and publish release notes, notify users through email and in-app widgets, and connect updates to the feature requests and feedback that drove them. Here are seven changelog tools in 2026, compared by features, pricing, and trade-offs.

## 1. [Quackback](https://quackback.io)

**Best for:** Teams that want an open-source changelog that automatically notifies the users who asked for each feature.

Quackback is an open-source product feedback platform (AGPL-3.0) where the [changelog](/features/changelog) is connected to [feedback boards](/features/feedback), [feature voting](/features/voting), and a [public roadmap](/features/roadmap). The key difference from standalone changelog tools: every entry can link to the feedback posts that drove the work. When you publish a changelog entry for a shipped feature, Quackback automatically notifies every user who voted or commented on it. The feedback loop closes without manual effort.

![Quackback changelog interface](/blog/best-changelog-tools/quackback.webp)

The changelog editor supports rich text with markdown, images, and embedded media. Each entry can be categorized with labels and linked to the feedback posts that drove the work. You can publish entries immediately or schedule them. Users can subscribe to updates via email or follow specific categories. An RSS feed is generated automatically.

Where Quackback differs from every other changelog tool on this list is AI draft generation and the [MCP server](/features/mcp). AI generates draft release notes from linked feedback posts, summarizes what shipped and why, and suggests which user segments to notify. Your team edits and publishes. The MCP server lets AI agents in Claude, Cursor, or Windsurf create changelog entries directly. Every agent action is attributed and auditable.

Self-host with Docker or deploy on Railway, or use the managed [Quackback Cloud](/pricing) and skip the infrastructure. Custom domain, custom branding with themes and CSS, and no "powered by" watermark on any plan. Self-hosted, your data stays in your own PostgreSQL database.

**Key changelog features:**
- Rich text changelog editor with markdown, images, and scheduling
- Automatic voter and commenter notifications when features ship
- Categories, labels, and links to feedback posts
- Email subscriber management and RSS feed
- AI-generated draft release notes from linked feedback
- [MCP server](/features/mcp) for AI agents to create and draft changelog entries
- Custom domain, branding, and no watermark
- In-app widget for surfacing updates inside your product
- [25 integrations](/integrations): Slack, Linear, Jira, GitHub, and more

**Pricing:** Free and open source (AGPL-3.0). Self-host at no cost, or use [Quackback Cloud](/pricing) from $29/mo with a 14-day free trial.

**Pros:**
- Changelog fully integrated with feedback boards, voting, and roadmap
- Automatic notifications close the feedback loop without manual work
- AI drafts release notes and suggests notification segments
- MCP server lets AI agents draft and publish changelog entries
- Open source with no vendor lock-in

**Cons:**
- AGPL-3.0 license requires care if you modify and redistribute the code
- Newer than incumbents like Canny and Beamer

---

> **Ship your changelog with Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. [Canny](/compare/quackback-vs-canny)

**Best for:** SaaS teams that want a hosted changelog connected to feature request boards and voter data.

Canny's changelog is part of its feedback suite. The main advantage: entries link to the feature requests they address, so users who voted see that their feedback led to a shipped feature. Email notifications go to voters and board followers automatically.

![Canny changelog interface](/blog/best-changelog-tools/canny.webp)

The editor supports rich text and images. You can schedule posts and set entries as published or draft. Canny generates an RSS feed and offers an in-app widget for surfacing entries. Categories and labels help organize entries by type (new feature, improvement, fix).

The limitation for changelogs specifically is the pricing model. Canny moved to tiered pricing based on tracked users in May 2025. Your changelog subscriber base contributes to your tracked user count. The more users who read and engage with your changelog, the higher your bill. There is no audience segmentation, so you cannot target different updates to different user groups. Removing "Powered by Canny" branding requires the Business plan (custom pricing).

**Key changelog features:**
- Rich text editor with images and scheduled publishing
- Email notifications to voters and board followers
- Categories and labels for organizing entries
- RSS feed and in-app widget
- Links entries to feature request posts
- No audience segmentation (all subscribers see all entries)

**Pricing:** Free plan (25 tracked users). Core from $19/mo. Pro from $79/mo. Business is custom pricing.

**Pros:**
- Changelog entries linked to feedback boards with voter notifications
- Mature product with reliable email delivery
- RSS and in-app widget for distribution

**Cons:**
- Every changelog subscriber is a tracked user that increases your bill
- No audience segmentation for targeted release notes
- Branding removal requires Business plan (custom pricing)
- No AI draft generation
- No self-hosting

For a detailed breakdown, see our [Quackback vs Canny comparison](/compare/quackback-vs-canny).

## 3. [Featurebase](/compare/quackback-vs-featurebase)

**Best for:** Teams that want a changelog that doubles as a knowledge source for their AI support agent.

Featurebase's changelog is part of its all-in-one suite: feedback boards, roadmap, help docs, support inbox, and changelog. Entries support rich text, images, and categories. You can link entries to the feature requests they resolve, and users who voted receive a notification when the changelog entry goes live.

![Featurebase changelog interface](/blog/best-changelog-tools/featurebase.webp)

The unique changelog angle for Featurebase is its AI agent, Fibi. When a customer asks "did you fix the export bug?" or "when did you add PDF support?", Fibi checks your changelog entries and responds with the right context. Your changelog becomes a searchable knowledge base for support, not just an announcement feed.

Email notifications and an in-app widget handle distribution. RSS is available. Per-seat pricing is the main consideration. At $29/seat/month on the Growth plan, costs scale with your team size.

**Key changelog features:**
- Rich text editor with images, categories, and scheduled publishing
- Email notifications and in-app widget for distribution
- Links to feedback posts for closing the loop
- AI agent (Fibi) references changelog entries in support responses
- RSS feed and custom domain

**Pricing:** Free plan (1 seat). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- AI support agent uses changelog as a knowledge source
- Changelog entries linked to feedback with voter notifications
- Modern, clean interface

**Cons:**
- Per-seat pricing adds up for larger teams
- No audience segmentation for targeted release notes
- Free plan is limited to one seat
- No self-hosting or open source

For more detail, see our [Quackback vs Featurebase comparison](/compare/quackback-vs-featurebase).

## 4. [Sleekplan](/compare/quackback-vs-sleekplan)

**Best for:** Budget-conscious teams that want a changelog with an embeddable widget and satisfaction surveys.

Sleekplan offers a changelog as part of its feedback and roadmap suite. The changelog supports rich text, images, and scheduled publishing. Entries can be categorized and tagged. Users receive notifications when new entries are published, and you can track who has read each update.

![Sleekplan changelog interface](/blog/best-changelog-tools/sleekplan.webp)

The distinguishing feature is the embeddable widget. Sleekplan's widget combines your changelog, feedback board, and roadmap into a single in-app experience. Users see new changelog entries without leaving your product. The widget can be configured to show only the changelog, only feedback, or the full suite.

Sleekplan also includes built-in CSAT and NPS surveys, which means you can measure user satisfaction alongside your release announcements. AI features ("Sleek Intelligence") are available on paid plans and can help summarize feedback, though they are primarily focused on the feedback board rather than changelog generation.

The free plan includes a changelog but is limited to one seat and does not include the roadmap or surveys. Starter at $13/month unlocks more features.

**Key changelog features:**
- Rich text changelog editor with scheduling and categories
- Embeddable in-app widget (changelog, feedback, and roadmap combined)
- Subscriber notifications and read tracking
- Built-in CSAT and NPS surveys
- RSS feed
- Custom domain on paid plans

**Pricing:** Free Indie plan (1 seat, changelog only). Starter at $13/month. Business at $38/month. Enterprise is custom.

**Pros:**
- Affordable starting price
- Widget-first approach for in-app changelog delivery
- Built-in satisfaction surveys alongside changelog
- Read tracking shows which users saw your updates

**Cons:**
- Free plan is very limited
- Widget-first design means the standalone changelog page is less polished
- AI features focused on feedback, not changelog generation
- No self-hosting

See our [Quackback vs Sleekplan comparison](/compare/quackback-vs-sleekplan) for a full breakdown.

## 5. Beamer

**Best for:** Teams that want a standalone changelog and in-app notification tool without a full feedback platform.

Beamer is a dedicated changelog and product notification tool. It focuses on one job: announcing product updates to your users. The in-app widget is the core experience. A notification icon sits in your product's navigation, showing a badge with unread updates. Users click to see a feed of changelog entries without leaving your app.

![Beamer changelog widget interface](/blog/best-changelog-tools/beamer.webp)

The editor supports rich text, images, video, and GIFs. Entries can be categorized and segmented so different user groups see different updates. Beamer includes push notifications, email notifications, and an RSS feed. You can also create standalone landing pages for major releases.

Beamer does not include feature request boards or a public roadmap. It is purely a changelog and announcement tool. If you need the full feedback-to-changelog pipeline, you will need to pair Beamer with a separate feedback tool. Beamer offers a feedback widget add-on, but it is basic compared to dedicated feedback platforms.

Beamer also includes NPS surveys and a feature request widget as add-on modules. The notification center can display banners, pop-ups, and top bars in addition to the standard changelog feed.

**Key changelog features:**
- In-app changelog widget with notification badge
- Rich text editor with images, video, and GIFs
- User segmentation for targeted announcements
- Push notifications, email notifications, and RSS feed
- Standalone release landing pages
- NPS surveys and feature request widget (add-ons)
- Custom domain and branding

**Pricing:** Free plan with limited features and Beamer branding. Starter at $49/month. Pro at $99/month (segmentation, custom domain). Scale at $199/month. Enterprise is custom.

**Pros:**
- Purpose-built for changelog and product announcements
- Strong in-app notification experience with badge, banners, and pop-ups
- User segmentation for targeted updates
- Standalone release landing pages for major launches

**Cons:**
- No feature request boards or public roadmap (separate add-ons only)
- Pricing is steep for a standalone changelog tool
- Branding removal requires a paid plan
- No self-hosting or open source
- No AI features for draft generation

## 6. LaunchNotes

**Best for:** Product marketing teams that want to turn release notes into a polished communication channel.

LaunchNotes positions itself as a product communication platform rather than a simple changelog tool. The focus is on turning release notes into marketing-grade announcements. You can create themed release pages, schedule announcements across email, in-app, and Slack, and segment your audience based on plan type, role, or custom attributes.

![LaunchNotes release notes interface](/blog/best-changelog-tools/launchnotes.webp)

The editor is designed for non-technical users. It supports rich text, images, video embeds, and custom layouts. Each announcement can target specific user segments, so enterprise customers see relevant updates while free-tier users see theirs.

LaunchNotes also includes a subscriber management system. Users can subscribe to specific categories of updates (new features, bug fixes, security) and manage their notification preferences. This gives users control over what they receive rather than getting everything.

The platform integrates with Jira, Linear, GitHub, and Slack to pull context from your development tools. You can auto-generate draft release notes from completed tickets and refine them before publishing.

LaunchNotes does not include feature request boards or voting. It is focused on the output side: announcing what shipped. You will need a separate tool for collecting and prioritizing feedback.

**Key changelog features:**
- Polished release note pages with custom layouts
- Audience segmentation by plan, role, or custom attributes
- Multi-channel delivery: email, in-app widget, Slack, RSS
- Subscriber management with category-based preferences
- Integrations with Jira, Linear, GitHub for auto-draft generation
- Custom domain and branding

**Pricing:** Starter plan available. Growth and Enterprise tiers with custom pricing. Contact sales for details.

**Pros:**
- Marketing-quality release announcements
- Strong audience segmentation and subscriber management
- Multi-channel delivery (email, in-app, Slack)
- Auto-drafts from development tool integrations

**Cons:**
- No feature request boards, voting, or public roadmap
- Pricing not transparent (requires contacting sales)
- Focused solely on announcements, not the full feedback loop
- No self-hosting or open source

## 7. Headway

**Best for:** Small teams that want a simple, low-cost changelog with minimal setup.

Headway is a lightweight changelog tool. You write release notes, categorize them, and publish. Users see updates through an in-app widget, a standalone changelog page, or email notifications. Setup takes minutes. The interface is clean and the editor is straightforward.

![Headway changelog interface](/blog/best-changelog-tools/headway.webp)

The widget is simple: a bell icon or custom trigger that opens a changelog feed inside your product. New entries show a badge so users know there are unread updates. Entries support categories like "new," "improvement," and "fix." You can add images and format text with a basic rich text editor.

Headway includes email notifications and an RSS feed. You can use a custom domain for your changelog page and customize the branding with colors and your logo. There is also a basic reactions feature so users can respond to entries with emoji reactions.

The trade-off is depth. Headway does not include feature request boards, voting, roadmaps, or AI features. There is no audience segmentation (all users see all entries). There is no integration with development tools for auto-generating release notes. It is a straightforward changelog tool and nothing more.

**Key changelog features:**
- Simple rich text editor with images and categories
- In-app widget with notification badge
- Email notifications and RSS feed
- Emoji reactions on changelog entries
- Custom domain and branding
- Standalone changelog page

**Pricing:** Free plan with unlimited entries and Headway branding. Pro at $29/month removes branding and adds a custom domain, Slack/Twitter integrations, scheduled publishing, and team collaboration. Those are the only two plans.

**Pros:**
- Simple and fast to set up
- Clean interface
- Affordable for basic needs
- Emoji reactions for lightweight engagement

**Cons:**
- No feature request boards, voting, or roadmap
- No audience segmentation
- No AI features
- No development tool integrations for auto-drafts
- No self-hosting or open source

See how it compares: [Quackback vs Headway](/compare/quackback-vs-headway).

## Comparison table

| Feature | Quackback | Canny | Featurebase | Sleekplan | Beamer | LaunchNotes | Headway |
|---|---|---|---|---|---|---|---|
| **Rich text editor** | Yes | Yes | Yes | Yes | Yes | Yes | Basic |
| **Email notifications** | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| **RSS feed** | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| **In-app widget** | Yes | Yes | Yes | Yes (combined) | Yes (primary) | Yes | Yes |
| **Categories/tags** | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| **Custom domain** | Yes | Yes | Yes | Paid plans | Pro+ | Yes | Yes |
| **Subscriber management** | Yes | Limited | Limited | Yes | Yes | Yes (advanced) | Basic |
| **Audience segmentation** | Yes | No | No | No | Yes | Yes | No |
| **Scheduled publishing** | Yes | Yes | Yes | Yes | Yes | Yes | No |
| **Read tracking** | No | No | No | Yes | Yes | Yes | No |
| **Voter notifications** | Yes (automatic) | Yes (automatic) | Yes (automatic) | No | No | No | No |
| **AI draft generation** | Yes (from feedback) | No | No | No | No | Yes (from tickets) | No |
| **Feedback boards** | Yes | Yes | Yes | Yes | Add-on | No | No |
| **Public roadmap** | Yes | Yes | Yes | Yes | No | No | No |
| **Self-hosting** | Yes | No | No | No | No | No | No |
| **Open source** | Yes | No | No | No | No | No | No |
| **Starting price** | Free | Free (25 tracked users) | $29/seat/mo | $13/mo | $49/mo | Contact sales | $29/mo |

## How to write release notes that users actually read

Most release notes go unread. Not because users don't care, but because the notes are written for the team that built the feature, not the people who will use it. Here are the practices that make a difference.

**Lead with the benefit, not the feature name.** "You can now export reports as PDF" is better than "PDF export functionality." Start with what users can do, not what you built. Frame every update in terms of the problem it solves or the workflow it improves.

**Use plain language.** Avoid internal jargon, technical implementation details, and vague descriptions. "Fixed a bug where emails weren't sending for accounts with custom domains" is clear. "Resolved an edge case in the SMTP relay configuration for non-standard MX records" is not. Write for your least technical user.

**Categorize consistently.** Use clear categories like "New," "Improved," and "Fixed." Users scan changelogs. Categories help them find what matters to them. A user looking for bug fixes should not have to read through ten new feature announcements.

**Keep entries focused.** One entry per feature or fix. Don't bundle unrelated changes into a single post. If you shipped five things this week, write five short entries, or group them by theme with clear subheadings. Bundling everything into one wall of text guarantees nobody reads it.

**Add context for major changes.** For significant updates, explain why you made the change, not just what changed. "We redesigned the dashboard based on feedback that the previous layout made it hard to find key metrics" tells users you listened. Link to the [feedback posts](/features/feedback) or [feature requests](/features/voting) that drove the decision.

**Include visuals.** A screenshot or short GIF showing the change communicates more than a paragraph of text. For UI changes, always include a visual. It takes 30 seconds to capture and saves users the effort of going to find the change themselves.

**Notify the right people.** Not every update is relevant to every user. If your changelog tool supports audience segmentation, use it. Send billing changes to account admins. Send API updates to developers. Send new feature announcements to everyone. Irrelevant notifications train users to ignore all notifications.

**Link back to your roadmap.** When you ship something from your [public roadmap](/features/roadmap), link the changelog entry back to the roadmap item. Users who have been following the feature's progress want to see it move from "in progress" to "shipped." This reinforces that your roadmap is a living document, not a static marketing page.

## Frequently asked questions

### What is a changelog tool?

A changelog tool is software that helps you write, publish, and distribute product release notes to your users. Most include a rich text editor, email notifications, an in-app widget, and an RSS feed. Some also include feature request boards and roadmaps to connect what you ship back to what users asked for. The goal is to keep users informed about product changes without relying on scattered blog posts or Slack messages.

### Do I need a standalone changelog tool or one integrated with feedback?

It depends on your workflow. A standalone tool like Beamer or Headway works if you only need to announce updates and your feedback collection happens elsewhere. An integrated tool like [Quackback](https://quackback.io), Canny, or Featurebase connects your changelog to your [feedback boards](/features/feedback) and [roadmap](/features/roadmap), so you can automatically notify users who voted on a feature when it ships. The integrated approach closes the feedback loop with less manual effort. For teams already collecting [feature requests](/blog/best-feature-request-tools) or [customer feedback](/blog/best-customer-feedback-tools-2026), an integrated tool avoids maintaining two separate systems.

### How often should I publish changelog entries?

Publish when you ship, not on a fixed schedule. Users prefer timely, relevant updates over a weekly digest of changes they can't remember asking for. That said, batching small fixes into a weekly or biweekly roundup is reasonable. Major features deserve their own dedicated entry. The key is consistency. If you publish regularly, users learn to check your changelog. If you go silent for months and then publish a wall of changes, nobody will read it.

### What is the best free changelog tool?

[Quackback](https://quackback.io) is the best free option. It is open source and free to self-host with no limits on entries, subscribers, or features. You get a rich text editor, email notifications, an in-app widget, RSS, categories, custom domain, and AI-generated draft release notes. The [changelog](/features/changelog) is fully integrated with feedback boards and a public roadmap, so notifications go out automatically when features ship. Among hosted tools, Sleekplan offers a limited free tier with changelog included, and Headway has a free plan with basic functionality and their branding.

- [Best Customer Feedback Tools in 2026: 8 Compared](https://quackback.io/blog/best-customer-feedback-tools-2026): Compare the 8 best customer feedback and feature request tools in 2026. Pricing, self-hosting, open source, AI, and MCP capabilities, side by side.

Published: 2026-03-06

Customer feedback software has been around for over a decade. The core workflow (collect feature requests, let users vote, show a roadmap, publish a changelog) hasn't changed much. What has changed is how teams act on that feedback. AI agents can now triage, respond, and close the loop automatically. Open-source alternatives have matured. And pricing models have gotten more complex (and in some cases, more expensive).

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

> The best customer feedback tools in 2026 are Quackback (open source, self-hosted or cloud, built-in AI, MCP server), Canny, Productboard, UserVoice, Featurebase, Fider, Nolt, and Sleekplan. Quackback is the strongest pick for teams that want to own their data; Canny and Featurebase suit hosted mid-size teams; UserVoice and Productboard fit enterprise budgets; Sleekplan and Nolt are the cheapest simple boards.

Here are eight customer feedback tools and feature request management platforms in 2026, compared side by side.

## 1. [Quackback](https://quackback.io)

![Quackback open source feedback board with feature voting and roadmap](/blog/best-customer-feedback-tools-2026/quackback.webp)

**Best for:** Teams that want open-source, self-hosted feature request management with built-in AI and agent access.

Quackback is an open-source customer feedback platform licensed under AGPL-3.0. You get [feature voting boards](/features/voting), a [public roadmap](/features/roadmap), [changelogs](/features/changelog), and [25 integrations](/integrations). Three things set it apart: the code is open and auditable, AI features are built in, and an [MCP server](/features/mcp) lets your AI agents act on feedback directly.

The AI catches duplicates before they pile up, suggests merges with reasoning your team can accept or dismiss in one click, runs sentiment analysis on every post, and generates summaries with key quotes and next steps. The AI connects to any OpenAI-compatible provider (OpenAI, Azure OpenAI, Cloudflare AI Gateway, or any compatible service).

The MCP server means agents in Claude, Cursor, or Windsurf can search your feedback, triage feature requests, write responses, and create changelog entries. The same actions your team does manually, but faster. Every agent action is attributed and auditable.

Self-host with Docker or deploy on Railway. Your data stays in your PostgreSQL database. Being open source also means no surprise pricing changes. Several closed-source tools on this list have raised prices, changed billing models, or paywalled previously-free features. With Quackback, the code is yours. If the project's direction ever changes, you can fork it.

**Key features:**
- Feature request boards with voting, status tracking, and nested comments
- Public roadmap and changelog with automatic voter notifications
- Built-in AI: duplicate detection, merge suggestions, sentiment analysis, post summaries
- MCP server for AI agents (search, triage, respond, create, merge)
- 25 integrations: [Slack, Linear, Jira, GitHub, Intercom, Zendesk, Salesforce](/integrations), and more
- User segments, [SSO/OIDC](/features/sso), webhooks, [full API](/features/api)
- Custom branding with themes, custom CSS, and your own domain

**Pricing:** Free and open source (AGPL-3.0). Self-host at no cost, or use [Quackback Cloud](/pricing) for a managed option from $29/mo, with a 14-day free trial. Because the code is open source, you can always move between cloud and self-hosting without lock-in.

**Trade-offs:** Self-hosting means running your own infrastructure (Docker or a one-click Railway deploy). If you would rather not manage servers, Quackback Cloud handles hosting for you.

## 2. [Canny](/compare/quackback-vs-canny)

![Canny feedback board with voting and prioritization](/blog/best-customer-feedback-tools-2026/canny.webp)

**Best for:** Mid-size SaaS teams that want a hosted feedback board.

Canny has been around since 2017. It covers feature request tracking, voting, roadmaps, and changelogs.

The pricing model changed in May 2025. Canny moved from per-admin billing to tiered pricing based on tracked users. A "tracked user" is anyone with a post, vote, or comment attributed to them. Costs increase as you cross tracked user thresholds, with auto-upgrades to the next tier.

Canny's AI suite, Autopilot, handles feedback discovery from support conversations (Intercom, Zendesk, Help Scout, Gong) and 10 public review sites, generates smart replies to prompt users for clarification, and summarizes comment threads. Credits are now uncapped on all plans.

**Key features:**
- Feedback boards with voting and prioritization
- Public and private roadmaps
- Changelog with email notifications
- Autopilot AI: feedback discovery, smart replies, comment summarization (uncapped credits)
- Integrations with Jira, Linear, Slack, HubSpot, and others (Salesforce requires Business plan)

**Pricing:** Free plan (25 tracked users). Core from $19/mo (billed annually). Pro from $79/mo. Business is custom pricing.

**Trade-offs:** Tiered tracked-user pricing means costs increase when you cross user thresholds, with auto-upgrades unless you set spend caps. No anonymous posting (users must log in). Jira integration requires Pro ($79/mo). No self-hosting. Removing "Powered by Canny" branding requires the Business plan.

## 3. [Productboard](/compare/quackback-vs-productboard)

![Productboard insights portal for customer feedback and prioritization](/blog/best-customer-feedback-tools-2026/productboard.webp)

**Best for:** Enterprise product teams that need feedback as part of a broader product management suite.

Productboard is a product management platform with feedback capabilities. It connects customer insights to product strategy through opportunity scoring, prioritization matrices, and driver-based roadmaps.

You can capture insights from Intercom, Zendesk, Salesforce, email, and Slack. The layer on top links feedback to features, scores impact, and aligns teams around priorities. The customer portal shows vote counts but not the feedback others left.

**Key features:**
- Insights portal for collecting and organizing customer feedback
- Feature prioritization with custom scoring frameworks
- Driver-based roadmaps tied to company objectives
- Integrations with Jira, Azure DevOps, Slack, Salesforce, Zendesk, Intercom, and more
- AI included via credits (250/maker/month) for summarization, insight extraction, semantic search, and auto-linking

**Pricing:** Spark at $15/maker/month (annual) or $19/maker/month (monthly). AI included via credits (250/maker/month). Enterprise pricing is custom for SSO, advanced security, and dedicated support.

**Trade-offs:** Per-maker pricing grows with team size. AI credits (250/maker/month) may be limiting for heavy users. More product management tool than feedback tool. Overkill if you just need boards and voting. No self-hosting. Steep learning curve.

## 4. [UserVoice](/compare/quackback-vs-uservoice)

![UserVoice feature request portal with revenue-linked prioritization](/blog/best-customer-feedback-tools-2026/uservoice.webp)

**Best for:** Large enterprises with budget for a premium feedback platform and CRM integration.

UserVoice pioneered the customer feedback category. It still targets enterprise teams and charges accordingly. The platform handles feature request management, internal feedback capture from sales and support teams, and connects ideas to revenue data so you can prioritize by business impact.

The main differentiator is revenue-linked prioritization. Connect Salesforce or HubSpot, and UserVoice pulls in account-level ARR data and aggregates the total revenue behind each feature request. You can distinguish "10 enterprise accounts worth $1M want this" from "50 free-tier users want this."

**Key features:**
- Feedback portal with voting and status updates
- Internal capture through integrations (Salesforce, Zendesk, HubSpot, Slack)
- Revenue-weighted prioritization tied to CRM data
- Separate Validation product ($199/mo) for microsurvey-based product research
- Enterprise security: SAML SSO, custom SLAs, compliance features

**Pricing:** Starting at $16,000/year (~$1,333/mo) with custom pricing based on monthly feedback volume and integrations. No per-seat charges. Annual billing required. 30-day free trial available. Sales process required.

**Trade-offs:** Pricing puts it out of reach for startups and most small teams. No public roadmap at any tier. A 30-day free trial is available but there is no free plan. The interface feels dated. Phone-only support. Microsoft, once their most prominent customer, walked away in 2021. No self-hosting.

## 5. [Featurebase](/compare/quackback-vs-featurebase)

![Featurebase feedback and support suite with AI agent](/blog/best-customer-feedback-tools-2026/featurebase.webp)

**Best for:** SaaS teams that want feedback, support, and a help center in one tool.

Featurebase bundles feedback boards, a changelog, roadmap, help docs, customer support inbox, and live chat into a single product. Every plan includes both the Support Suite and the Product Suite at no extra cost.

Their AI agent, Fibi, automatically resolves customer questions using context from your entire workspace: help center articles, feedback posts, changelogs, and past conversations. It can also submit feature requests to your boards on behalf of customers.

**Key features:**
- Feedback boards with voting, status tracking, and user segmentation
- Changelog, public roadmap, and surveys (NPS, CSAT, multiple choice)
- Unified support inbox with live chat, email, and ticketing
- Help center / knowledge base with AI-powered search
- Fibi AI Agent: auto-resolves questions, submits feedback on behalf of users ($0.49/resolution)
- 12 integrations: Linear, Jira, GitHub, ClickUp, Slack, Intercom, Zendesk, HubSpot, and more

**Pricing:** Free plan (1 seat, 50 help center articles, no AI). Growth at $29/seat/month. Professional at $59/seat/month adds workflows, SLAs, and multilingual support. Enterprise at $99/seat/month.

**Trade-offs:** Per-seat pricing adds up for larger teams. AI resolutions at $0.49 each are usage-based and can become significant at volume. Post merging and user segmentation locked to the $38+/mo Business tier. No self-hosting. No open source. Multilingual support requires Professional ($59/seat).

## 6. [Fider](/compare/quackback-vs-fider)

![Fider open source feedback board with voting and comments](/blog/best-customer-feedback-tools-2026/fider.webp)

**Best for:** Developers who want a free, self-hosted feedback board with minimal overhead.

Fider is the other open-source option in this list. It covers the basics: feature voting boards, comments, tags, status updates, and a REST API. It runs on Go and PostgreSQL and deploys with Docker.

Where Fider falls short is everything beyond the basics. There's no changelog, no roadmap view, no AI features, and integrations are limited to webhook-based connections with Slack, Discord, and Teams. The project moved to an open-core model in v0.33.0, putting content moderation and SEO indexing behind the paid cloud tier.

**Key features:**
- Feedback boards with voting, comments, and rich text editor
- Tags, filters, and customizable statuses
- REST API and webhooks (4 event types)
- Multi-language support (10+ languages, including RTL)
- SSO with OAuth providers
- Self-hosted on any cloud or on-premise

**Pricing:** Free and open source for self-hosting. Cloud free tier limited to 250 feedback items. Cloud Pro at $49/month for unlimited items and premium features.

**Trade-offs:** No changelog, no roadmap, no AI features, and no native issue tracker integrations. The open-core shift means some features are now paywalled. Works for simple voting boards, but lacks the features most teams eventually need.

## 7. [Nolt](/compare/quackback-vs-nolt)

![Nolt simple feedback board with voting](/blog/best-customer-feedback-tools-2026/nolt.webp)

**Best for:** Small teams that want a simple, quick-to-set-up feedback board.

Nolt keeps things simple. You get a clean feedback board where users can submit and vote on ideas, plus a basic roadmap view and status notifications. There are no AI features and no changelog.

The concern with Nolt in 2026 is pace. The product has seen minimal updates over the past two years. Core feature requests from users (changelog, comment threading, bulk editing) remain unbuilt.

**Key features:**
- Feedback board with voting and custom statuses
- Roadmap view
- SSO, private boards, and password-protected boards
- Integrations: Slack, Discord, Jira, Linear, Asana, Trello, GitHub, Zapier (Pro plan)
- Custom domain and branding

**Pricing:** Essential at $25/month (annual) for 1 board. Pro at $69/month (annual) for 5 boards with moderation, more integrations, and webhooks. Enterprise is custom.

**Trade-offs:** Per-board pricing means costs multiply across products. No changelog. Limited updates since 2022. No self-hosting.

## 8. [Sleekplan](/compare/quackback-vs-sleekplan)

![Sleekplan embeddable feedback widget with surveys and changelog](/blog/best-customer-feedback-tools-2026/sleekplan.webp)

**Best for:** Budget-conscious teams that want feedback collection with built-in surveys.

Sleekplan offers feedback boards, a roadmap, changelog, and satisfaction surveys (CSAT/NPS) in a single embeddable widget. Paid plans start at $13/month, making it one of the cheaper hosted options. It also includes AI-powered features ("Sleek Intelligence") on paid plans.

The free plan is limited to a feedback board and changelog with one seat. Roadmap, surveys, and AI features require the Starter plan or above.

**Key features:**
- Feedback board with voting, status updates, and impact scoring
- Changelog with scheduled posting and subscriber notifications
- Roadmap (Starter plan and above)
- Built-in CSAT and NPS surveys
- Embeddable in-app widget, standalone site, or iframe
- 12 integrations: Jira, Linear, Azure DevOps, Slack, Intercom, ClickUp, GitHub, Zapier

**Pricing:** Free Indie plan (1 seat, no roadmap/surveys). Starter at $13/month adds roadmap, surveys, and 1,000 AI credits. Business at $38/month adds post merging, user segmentation, and conditional surveys. Enterprise is custom.

**Trade-offs:** The free plan is very limited (no roadmap, no surveys, no AI). Post merging and user segmentation require the Business plan ($38/mo). No duplicate detection on the public board. Cannot submit feedback on behalf of users. Widget-first approach means the standalone portal is less polished.

## How to choose

The right tool depends on three things: your budget, whether you need to self-host, and how much of your feedback workflow you want to automate.

**If you want open source and self-hosting:** Quackback gives you the full feature set (boards, roadmap, changelog, 25 integrations, built-in AI). You own your data, you can audit the code, and you're not subject to the pricing changes that have hit users of Canny, Productboard, and others. Fider covers the basics if you only need a simple voting board, though its move to open-core means some features are now paywalled.

**If you want hosted and have budget:** Canny and Featurebase work for mid-size teams, though watch for tracked-user and per-seat costs as you scale. Productboard makes sense if you need a full product management suite beyond just feedback. UserVoice is for enterprises with CRM-driven prioritization and enterprise budgets.

**If you want affordable and simple:** Sleekplan and Nolt are the lightest options. Sleekplan gives you more for the price. Nolt is faster to set up.

**If you want AI built in:** Quackback includes duplicate detection, merge suggestions, sentiment analysis, and post summaries, and connects to any OpenAI-compatible provider. Its MCP server also lets your existing AI agents search, triage, and respond to feedback directly. Other tools have added AI features (Canny's Autopilot, Featurebase's Fibi, Productboard's credit-based AI), but these are either copilot-style features within their UI or carry per-use charges and credit limits. None expose an open protocol for external agents.

The feedback tool space has consolidated around a common feature set. The differentiators in 2026 are who owns the data, who controls the pricing, and whether AI is bolted on or built in. Closed-source SaaS tools can change their terms, raise prices, or paywall features at any time. Several on this list have done exactly that. Open source removes that risk. You get the same features, the same integrations, and the freedom to run the software on your terms.

For deeper dives into specific categories, see our guides to the [best feature request tools](/blog/best-feature-request-tools), [best feature voting tools](/blog/best-feature-voting-tools), [best public roadmap tools](/blog/best-public-roadmap-tools), and [best changelog tools](/blog/best-changelog-tools). If you're evaluating alternatives to specific tools, see [best Canny alternatives](/blog/best-canny-alternatives), [best Productboard alternatives](/blog/best-productboard-alternatives), and [best UserVoice alternatives](/blog/best-uservoice-alternatives). For pricing details, see our [feedback tool pricing comparison](/blog/feedback-tool-pricing-comparison) and individual pricing breakdowns for [Canny](/blog/canny-pricing), [Productboard](/blog/productboard-pricing), and [UserVoice](/blog/uservoice-pricing). Teams interested in self-hosting should read our guide to [open source feedback tools](/blog/open-source-feedback-tools).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is a customer feedback tool?

A customer feedback tool lets you collect, organize, and act on input from your users. Most include feature request boards with voting, a public roadmap, and a changelog. The goal is to close the loop between what users ask for and what your team ships.

### What is a feature request tool?

A feature request tool is a specific type of customer feedback software focused on collecting and prioritizing product ideas. Users submit feature requests, vote on ideas they care about, and follow status updates. Your team uses voting data, user segments, and integrations with tools like Jira or Linear to decide what to build next. Some tools (like [Quackback](https://quackback.io)) add AI to detect duplicates and suggest merges automatically.

### What is the difference between a feature request and a bug report?

A feature request suggests something new: a capability, integration, or workflow that does not exist yet. A bug report describes something broken or not working as expected. Most feedback tools track both but prioritize them differently. Feature requests rank by demand (votes, revenue); bug reports rank by severity.

### Are there any open-source customer feedback tools?

Yes. [Quackback](https://quackback.io) and [Fider](/compare/quackback-vs-fider) are both open source. Quackback is the more full-featured option with feature voting, roadmaps, changelogs, 25 integrations, and built-in AI. Fider covers the basics (voting boards, comments, tags) but has no changelog, no roadmap view, and no AI features. Both self-host with Docker on your own infrastructure.

### How do I track and manage feature requests?

Give users a dedicated board to submit ideas instead of scattered emails and Slack messages. Use voting to surface demand, tags and segments to organize requests, and status updates to keep users informed. Connect the board to your issue tracker (Jira, Linear, GitHub) so accepted requests flow into development.

- [Best Public Roadmap Tools in 2026 (Free and Paid, Ranked)](https://quackback.io/blog/best-public-roadmap-tools): Compare the best public roadmap tools for sharing your product direction with customers. Kanban boards, linked feedback, and custom statuses.

Published: 2026-03-05

![Best public roadmap tools compared](/blog/best-public-roadmap-tools/hero.webp)

> The best public roadmap tool depends on how closely you want your roadmap tied to user feedback. Quackback links every roadmap item to its source feature request and vote count, with automatic changelog notifications when items ship. Productboard suits enterprise orgs that need strategic objective mapping, and Aha offers the most advanced roadmap visualization. Here are all seven ranked:
>
> *Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

1. **[Quackback](https://quackback.io)** — Open source and self-hosted, with a managed cloud option. Every roadmap item backed by live vote and feedback data.
2. **[Canny](/compare/quackback-vs-canny)** — Hosted roadmap with voting directly from the roadmap view. Public and private visibility.
3. **[Productboard](/compare/quackback-vs-productboard)** — Enterprise driver-based roadmaps tied to strategic objectives and scoring.
4. **[Featurebase](/compare/quackback-vs-featurebase)** — Kanban roadmap connected to feedback, support inbox, and changelog.
5. **[Nolt](/compare/quackback-vs-nolt)** — Basic status-grouped view with flat-rate pricing. No kanban or timeline.
6. **[Upvoty](/compare/quackback-vs-upvoty)** — Affordable roadmap with voting on planned items and changelog from $15/mo.
7. **[Aha!](/compare/quackback-vs-aha)** — Enterprise roadmapping with Gantt timelines, dependency mapping, and capacity planning.

A public roadmap tells your customers what you are building and when. Teams that publish roadmaps get fewer "when is this coming?" support tickets, build trust with users who can see their feedback being acted on, and create accountability that keeps development focused.

The problem is not the idea. It is the tooling. Most teams either skip the public roadmap or build one in Notion that goes stale within weeks. A good public roadmap tool makes it easy to share your plans, link them to customer feedback, and keep statuses current without adding maintenance burden.

Here are seven public roadmap tools in 2026, compared on roadmap capabilities: public visibility, kanban views, feedback linking, custom statuses, embeddable widgets, and status notifications. We built each public roadmap in a trial account and verified every pricing figure against the vendor's published plans in March 2026.

## 1. [Quackback](https://quackback.io)

**Best for:** Teams that want an open-source public roadmap where every item is backed by real user feedback and vote data.

Quackback is an open-source product feedback platform (AGPL-3.0). The [public roadmap](/features/roadmap) is not a standalone kanban board. It is a live view of your feedback data. Every roadmap item links back to its source feature request, showing vote counts, comments, and status history. Your customers see exactly why something is planned and how much demand it has.

![Quackback public roadmap interface](/blog/best-public-roadmap-tools/quackback.webp)

The roadmap uses kanban-style columns with custom statuses. Move a feature request from "Planned" to "In Progress" and your roadmap updates automatically. Move it to "Shipped" and every voter gets notified through the [changelog](/features/changelog). No manual status syncing between your feedback board and your roadmap. They are the same data.

AI duplicate detection keeps your roadmap clean by preventing the same request from appearing under multiple titles. The [MCP server](/features/mcp) lets AI agents in Claude, Cursor, or Windsurf update roadmap items, triage incoming feedback, and draft changelog entries for shipped features.

Self-host with Docker or deploy on Railway. With [25 integrations](/integrations) including Slack, Linear, Jira, and GitHub, roadmap status changes flow into your development workflow.

**Key roadmap features:**
- Kanban board with custom statuses that sync with your feedback board
- Every item linked to its source feature request, votes, and comments
- Automatic voter notifications when items ship (via [changelog](/features/changelog))
- No manual roadmap maintenance; statuses update from your feedback workflow
- [MCP server](/features/mcp) for AI agents to update roadmap items
- [25 integrations](/integrations): Slack, Linear, Jira, GitHub, Intercom, Zendesk, Salesforce

**Pricing:** Free and open source (AGPL-3.0). Self-host at no cost, or use [Quackback Cloud](/pricing) as a managed option.

**Pros:**
- Roadmap items are backed by live vote and comment data, not static cards
- Status changes flow through feedback, roadmap, and changelog automatically
- Open source and self-hosted, with a managed cloud option

**Cons:**
- Self-hosting requires running your own infrastructure
- Newer than incumbents, so fewer prebuilt roadmap templates

---

> **Publish your public roadmap with Quackback** — open source and self-hosted. Deploy in under five minutes.
> [Get started free](/docs) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. [Canny](/compare/quackback-vs-canny)

**Best for:** Mid-size SaaS teams that want a hosted public roadmap connected to feedback boards and support tools.

Canny's roadmap displays items organized by status columns, each linked to its feedback post with vote counts visible. Users can vote directly from the roadmap view, not just from the feedback board. The roadmap supports both public and private visibility, so you can share different views with customers and internal stakeholders.

![Canny public roadmap interface](/blog/best-public-roadmap-tools/canny.webp)

Status changes trigger email notifications to voters. Autopilot, Canny's AI suite, discovers feature requests from support conversations and can surface items that should be on your roadmap but are not yet represented.

The roadmap is functional but limited in layout options. There is no timeline view, no dependency mapping, and no embeddable roadmap widget. The pricing model changed in May 2025 to tiered pricing based on tracked users. Users who interact with your roadmap count as tracked users.

**Key roadmap features:**
- Public and private roadmaps with status columns
- Voting directly from the roadmap view
- Items linked to feedback posts with vote counts
- Email notifications on status changes

**Pricing:** Free plan (25 tracked users). Core from $19/mo. Pro from $79/mo. Business is custom pricing.

**Pros:**
- Roadmap tightly connected to feedback boards with vote data
- Public/private visibility controls for different audiences

**Cons:**
- No timeline view, dependency mapping, or embeddable roadmap widget
- Tiered tracked-user pricing means costs increase as you cross user thresholds
- Removing branding requires Business plan
- No self-hosting

For a detailed breakdown, see our [Quackback vs Canny comparison](/compare/quackback-vs-canny).

## 3. [Productboard](/compare/quackback-vs-productboard)

**Best for:** Enterprise product organizations that need a strategic roadmap tied to prioritization frameworks and company objectives.

Productboard takes a different approach. Instead of a simple kanban board, it offers driver-based roadmaps tied to strategic objectives with custom scoring criteria. You can build multiple views for different audiences: a timeline for executives, a feature view for product managers, and a customer portal for users.

![Productboard roadmap interface](/blog/best-public-roadmap-tools/productboard.webp)

The customer portal lets users see planned features and vote on them. The strength is the strategic layer: score features against custom drivers, connect them to company objectives, and present a coherent roadmap.

The trade-off is cost and complexity. For teams that need a public roadmap without the full product management suite, Productboard is more than you need.

**Key roadmap features:**
- Driver-based roadmaps tied to company objectives
- Multiple views (timeline, board, list) for different audiences
- Customer portal with voting on planned features
- Prioritization scoring with custom frameworks

**Pricing:** Spark at $15/maker/month (annual) or $19/maker/month (monthly). AI included via credits (250/maker/month). Enterprise is custom.

**Pros:**
- Most sophisticated roadmap and prioritization on this list
- Multiple views for different stakeholders

**Cons:**
- Per-maker pricing grows with team size
- Customer portal is limited compared to purpose-built roadmap tools
- Overkill if you only need a public roadmap; no self-hosting

See our [Quackback vs Productboard comparison](/compare/quackback-vs-productboard) for a full feature-by-feature breakdown.

## 4. [Featurebase](/compare/quackback-vs-featurebase)

**Best for:** SaaS teams that want a kanban roadmap connected to feedback, support, and a help center in one tool.

Featurebase's public roadmap uses a kanban layout with customizable status columns. Each card links to its source feedback post with vote counts, so users browsing your roadmap can see the demand behind every planned feature.

![Featurebase public roadmap interface](/blog/best-public-roadmap-tools/featurebase.webp)

The roadmap connects to Featurebase's support inbox. When a customer submits a feature request through support or via Fibi (the AI agent), it can appear on your roadmap once triaged. Status changes trigger notifications, and shipped items automatically generate changelog entries.

The all-in-one approach keeps your roadmap, feedback, and support data in one place. The limitation is roadmap flexibility. Custom statuses are available, but there are no timeline views, grouped-by-objective layouts, or dependency mapping.

**Key roadmap features:**
- Kanban layout with custom status columns
- Items linked to feedback posts and vote counts
- Status change notifications and changelog integration
- Fibi AI agent triages support conversations to roadmap items ($0.49/resolution)

**Pricing:** Free (1 seat). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- Roadmap items inherit vote data and discussion from feedback boards
- Support-to-roadmap pipeline through AI agent

**Cons:**
- No timeline view, dependency mapping, or advanced layouts
- Per-seat pricing adds up for larger teams
- No self-hosting or open source

See how it compares: [Quackback vs Featurebase](/compare/quackback-vs-featurebase).

## 5. [Nolt](/compare/quackback-vs-nolt)

**Best for:** Small teams that want a basic public roadmap view with flat pricing and minimal setup.

Nolt's roadmap groups feedback posts by status. It is not a kanban board; it is a filtered view of your feedback board organized by status labels. Status changes send email notifications to voters.

![Nolt roadmap view interface](/blog/best-public-roadmap-tools/nolt.webp)

For teams with a small number of planned features, this is adequate. The concern is what happens when items ship. Nolt has no changelog, so the roadmap's lifecycle ends at "Done." There is no built-in way to announce shipped features or notify the users who were following them. The roadmap also has no timeline view, no embeddable widget, and no dependency mapping.

**Key roadmap features:**
- Status grouping view with items linked to feedback posts
- Status notifications to voters via email
- Custom statuses, domain, and branding

**Pricing:** Essential at $25/month (1 board). Pro at $69/month (5 boards). Enterprise is custom.

**Pros:**
- Quick to set up with flat pricing
- Status view gives users visibility into what is planned

**Cons:**
- No changelog to announce shipped items
- Status grouping, not a true kanban board
- No timeline, embedding, or dependency features
- Minimal product updates since 2022
- No self-hosting

For more, see our [Quackback vs Nolt comparison](/compare/quackback-vs-nolt).

## 6. [Upvoty](/compare/quackback-vs-upvoty)

**Best for:** Budget-conscious teams that want a public roadmap with voting and a changelog at the lowest price point.

Upvoty provides a public roadmap with status columns where users can vote directly on planned items. Status changes notify voters. When items ship, the changelog announces them. The roadmap can be accessed via a custom domain.

![Upvoty public roadmap interface](/blog/best-public-roadmap-tools/upvoty.webp)

At $15/month, Upvoty is the most affordable roadmap tool here. The complete loop (roadmap to changelog with voter notifications) works. The trade-off is layout flexibility. The roadmap is a basic status board. No timeline view, no grouped-by-objective layouts, no dependency mapping, and no embeddable roadmap widget.

**Key roadmap features:**
- Status columns with voting directly on roadmap items
- Status notifications to voters
- Changelog for announcing shipped items
- Custom domain and branding

**Pricing:** Starts at $15/month. Higher tiers for more boards and features.

**Pros:**
- Most affordable roadmap tool on this list
- Full loop: roadmap, voting, changelog, and notifications

**Cons:**
- Basic status board with no timeline or advanced layouts
- No AI features and limited integrations
- No self-hosting or open source

See our [Quackback vs Upvoty comparison](/compare/quackback-vs-upvoty) for a full breakdown.

## 7. [Aha](/compare/quackback-vs-aha)

**Best for:** Enterprise product teams that need a full-featured roadmapping platform with strategic planning capabilities.

Aha is a dedicated roadmapping platform with the most sophisticated capabilities on this list: Gantt-style timelines, strategic initiative grouping, capacity planning, dependency mapping, and multiple layouts. You can build roadmaps for different audiences and share them as live web pages.

![Aha! Roadmaps interface](/blog/best-public-roadmap-tools/aha.webp)

The Ideas portal is the public-facing component. Customers submit ideas and vote on them, and ideas link to features on your roadmap. Aha Roadmaps is a standalone product, separate from the broader suite (Aha Ideas, Aha Develop).

At $59/user/month, Aha is over-engineered for teams that need a simple public roadmap. For enterprise organizations managing multiple products with cross-team dependencies, the depth is justified.

**Key roadmap features:**
- Timeline, board, list, and workflow views
- Strategic initiative grouping and dependency mapping
- Capacity planning and release scheduling
- Ideas portal with voting and feedback linking
- Shareable roadmap links with view-only access

**Pricing:** Aha Roadmaps at $59/user/month. Aha Ideas at $39/user/month. Enterprise is custom.

**Pros:**
- Most advanced roadmap visualization and planning on this list
- Dependency mapping and capacity planning

**Cons:**
- Expensive; Ideas portal and Roadmaps are separate products
- Steep learning curve
- No self-hosting or open source

See how it compares: [Quackback vs Aha!](/compare/quackback-vs-aha).

## Comparison table

| Feature | Quackback | Canny | Productboard | Featurebase | Nolt | Upvoty | Aha |
|---|---|---|---|---|---|---|---|
| **Public roadmap** | Yes | Yes | Customer portal | Yes | Yes | Yes | Yes (shareable links) |
| **Kanban view** | Yes | Status columns | Board view | Yes | No | Status columns | Yes |
| **Linked feedback** | Yes (votes, comments) | Yes (votes) | Yes (insights) | Yes (votes, comments) | Yes (votes) | Yes (votes) | Yes (ideas portal) |
| **Custom statuses** | Yes | Limited | Yes | Yes | Yes | Limited | Yes |
| **Embeddable widget** | Yes (feedback widget) | No | No | No | No | No | No |
| **Status notifications** | Yes (via changelog) | Yes (email) | Yes (email) | Yes (email) | Yes (email) | Yes (email) | Yes (email) |
| **Timeline view** | No | No | Yes | No | No | No | Yes |
| **AI features** | Yes (duplicate detection, sentiment, merge) | Yes (Autopilot) | Yes (included via credits) | Yes (Fibi) | No | No | Yes (limited) |
| **Open source** | Yes (AGPL-3.0) | No | No | No | No | No | No |
| **Self-hosting** | Yes | No | No | No | No | No | No |
| **Starting price** | Free | Free (25 tracked users) | $15/maker/mo (annual) | $29/seat/mo | $25/mo | $15/mo | $59/user/mo |

## How to build a public roadmap that works

Publishing a public roadmap is easy. Maintaining one that builds trust is harder. Here are the practices that matter.

**Use outcomes, not feature names.** Customers do not care that you are "refactoring the notification service." They care that you are "making notifications faster and more reliable." Frame roadmap items in terms of the user outcome, not the implementation detail.

**Keep statuses current.** A roadmap with stale statuses is worse than no roadmap. If an item has been "In Progress" for six months, users lose trust in the entire board. Set a weekly review cadence. Transparency about delays builds more trust than silence.

**Link every item to feedback.** The most effective public roadmaps show users that their [feedback](/features/feedback) directly influenced what is being built. When a roadmap item links to the original feature request with 200 votes, every voter feels heard.

**Close the loop with a changelog.** A roadmap without a [changelog](/features/changelog) has a gap at the end. When an item moves to "Shipped," announce it. Notify every user who voted or commented. This turns your roadmap into a retention tool.

**Curate what you show.** Not everything belongs on a public roadmap. Internal infrastructure work and sensitive competitive moves should stay private. A public roadmap full of items that never ship erodes trust faster than having no roadmap at all.

**Choose the right level of commitment.** Some teams use "Exploring," "Planned," and "In Progress" to signal confidence. Others use "Now, Next, Later" to avoid date commitments. For more on roadmap strategy, see our guides on [technology roadmaps](/blog/technology-roadmap) and [IT roadmaps](/blog/it-roadmap-guide).

**Connect to your development workflow.** Use integrations with Jira, Linear, or GitHub to keep roadmap statuses in sync with development progress. Manual status updates get forgotten. Automated ones stay current.

## Frequently asked questions

### What is a public roadmap?

A public roadmap is a shared view of what your product team plans to build, what is in progress, and what has shipped. It is visible to your customers on a dedicated page or embedded in your product. Items typically display in a kanban board with status columns, linked to [feature requests](/features/feedback) so users can see the votes behind every planned item.

### Should I use a public roadmap or keep it internal?

A public roadmap builds trust and reduces "when is this shipping?" questions. The risk is that published plans create expectations. If you frequently change direction, a public roadmap can erode trust. The middle ground is keeping your date-specific roadmap internal and publishing a "Now, Next, Later" view publicly. [Quackback](https://quackback.io) lets you control which items are public versus private.

### How do I link my roadmap to customer feedback?

Use a tool where feedback and roadmap live in the same product, so promoting a [feature request](/features/feedback) to your roadmap carries its votes, comments, and context. When you ship it, voters get notified through the [changelog](/features/changelog). [Quackback](https://quackback.io), Canny, and Featurebase support this natively.

### What is the best free public roadmap tool?

[Quackback](https://quackback.io) is the best free option. It is open source and free to self-host. You get a [public roadmap](/features/roadmap) with kanban views, [feedback boards](/features/feedback) with voting, a [changelog](/features/changelog) with voter notifications, and built-in AI. Among hosted tools, Canny's free plan caps at 25 tracked users.

- [Best Feature Voting Tools in 2026: 7 Ranked & Compared](https://quackback.io/blog/best-feature-voting-tools): Compare the 7 best feature voting and upvote tools in 2026, ranked on voting depth, pricing, and AI deduplication. Find the right board to surface real demand.

Published: 2026-03-04

Feature voting is how product teams separate signal from noise. Instead of guessing what to build next, you let your users tell you. A voting board gives every user a voice and gives your team a quantified view of demand. The ideas with the most votes rise to the top.

But not all voting implementations are equal. Some tools count raw upvotes. Others weight votes by user segment or revenue. Some let anyone vote anonymously. Others require authentication. A one-click upvote captures far more signal than a multi-step form.

This guide compares seven feature voting tools in 2026, evaluated specifically on voting capabilities. For a broader comparison, see our [guide to the best feature request tools](/blog/best-feature-request-tools) or our [best customer feedback tools roundup](/blog/best-customer-feedback-tools-2026).

![Best feature voting tools compared](/blog/best-feature-voting-tools/hero.webp)

> The best feature voting tool depends on how you use vote data. **Quackback** keeps vote counts accurate with AI duplicate detection, and is open source with a managed cloud option. Canny discovers implicit votes from support conversations. Featurebase segments voters by customer plan. The seven tools ranked:
>
> 1. **Quackback** — Open source, AI deduplication, MCP server.
> 2. **Canny** — Hosted boards, AI vote attribution from support tools.
> 3. **Featurebase** — Voter segmentation by plan, support inbox.
> 4. **Fider** — Open source, minimal upvoting, no analytics.
> 5. **Nolt** — Simple board, flat-rate pricing.
> 6. **Upvoty** — Affordable boards with changelog from $15/mo.
> 7. **Sleekplan** — Embeddable widget with impact scoring.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

1. **[Quackback](https://quackback.io)** — Open source and self-hosted. AI deduplication keeps vote counts accurate.
2. **[Canny](/compare/quackback-vs-canny)** — Hosted voting boards with AI that attributes votes from support conversations.
3. **[Featurebase](/compare/quackback-vs-featurebase)** — Voter segmentation by plan and company. Combines voting with support inbox.
4. **[Fider](/compare/quackback-vs-fider)** — Open source, minimal voting board. Basic upvoting with no analytics.
5. **[Nolt](/compare/quackback-vs-nolt)** — Simple voting board with flat-rate pricing. No per-voter billing.
6. **[Upvoty](/compare/quackback-vs-upvoty)** — Affordable voting boards with voter notifications and changelog from $15/mo.
7. **[Sleekplan](/compare/quackback-vs-sleekplan)** — Embeddable in-app voting widget with impact scoring beyond raw vote counts.

## 1. [Quackback](https://quackback.io)

**Best for:** Teams that want open-source feature voting with AI-powered deduplication.

Quackback is an open-source feature voting platform licensed under AGPL-3.0. The [voting board](/features/voting) is the core of the product. Users submit feature requests, upvote ideas with a single click, and follow posts for status notifications. Votes are tallied in real time and surface the most-requested features to the top.

![Quackback feature voting board interface](/blog/best-feature-voting-tools/quackback.webp)

What sets Quackback apart is the AI layer. Duplicate detection identifies when a new request matches an existing one before it splits your vote count. Merge suggestions let your team combine related requests with one click, consolidating votes into a single thread. This solves the biggest problem with feature voting at scale: fragmented demand signals.

The [feedback board](/features/feedback) supports nested comments on every post, so voters can explain why they care about a feature. Status tracking keeps voters informed. When a feature ships, the [changelog](/features/changelog) notifies every user who voted for it. The [public roadmap](/features/roadmap) shows what you are building next.

Self-host with Docker or deploy on Railway, or use [Quackback Cloud](/pricing) if you would rather not run infrastructure. Your vote data stays in your PostgreSQL database. An [MCP server](/features/mcp) lets AI assistants query and triage vote data directly, which no other tool in this list offers.

**Voting features:**
- One-click upvoting with real-time vote counts
- AI duplicate detection prevents vote fragmentation across similar requests
- Merge suggestions consolidate votes from related posts
- Voter notifications when statuses change or features ship
- Trending indicators based on recent vote velocity
- Voter analytics showing who voted, when, and on what
- Anonymous voting support

**Pricing:** Free and open source (AGPL-3.0). Self-host at no cost, or use [Quackback Cloud](/pricing) for a managed option from $29/mo, with a 14-day free trial.

**Pros:**
- AI deduplication keeps vote counts accurate and consolidated
- Open source with full data ownership, plus a managed cloud option
- Complete voting-to-shipping workflow: votes, roadmap, changelog, notifications
- MCP server lets AI assistants triage and query vote data directly

**Cons:**
- Self-hosting requires Docker or Railway setup
- Younger product than incumbents like Canny

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. [Canny](/compare/quackback-vs-canny)

**Best for:** Mid-size SaaS teams that want hosted voting boards with AI-powered feedback discovery.

Canny has offered feature voting since 2017. Users submit ideas and upvote them on a clean board. Votes drive a prioritization score that helps your team sort by demand. The Autopilot AI suite discovers feature requests in support conversations from Intercom, Zendesk, Help Scout, and Gong, attributing votes accordingly.

![Canny feature voting board interface](/blog/best-feature-voting-tools/canny.webp)

The pricing model is the concern for voting at scale. Canny bills by tracked users, and anyone who votes is a tracked user. The more people vote, the higher your bill. Canny's free plan caps at 25 tracked users. As your voter count grows, you cross tier thresholds and get auto-upgraded.

**Voting features:**
- One-click upvoting with vote counts
- Voter identification tied to user profiles
- Vote-based prioritization scoring
- Autopilot discovers votes from support conversations
- Status change notifications to voters
- No anonymous voting (users must authenticate)
- Vote limits tied to tracked-user tier thresholds

**Pricing:** Free plan (25 tracked users). Core from $19/mo. Pro from $79/mo. Business is custom pricing.

**Pros:**
- Mature voting interface with a large user base
- AI discovers implicit votes from support tools
- Good prioritization views combining votes with other signals

**Cons:**
- Every voter is a tracked user that increases your bill
- No anonymous voting
- Tiered pricing auto-upgrades you when you exceed tracked user limits
- No self-hosting

For a detailed breakdown, see our [Quackback vs Canny comparison](/compare/quackback-vs-canny).

## 3. [Featurebase](/compare/quackback-vs-featurebase)

**Best for:** Teams that want feature voting alongside customer support and a help center.

Featurebase combines feature voting boards with a support inbox, help center, and live chat. Posts show vote counts, status labels, and comment threads. The Fibi AI agent can submit votes on behalf of customers during support conversations.

![Featurebase feature voting board interface](/blog/best-feature-voting-tools/featurebase.webp)

Featurebase ties votes to user segments. Filter by customer plan, company size, or other attributes to see which segments want a feature most. Per-seat pricing means costs scale with team size, not voter count.

**Voting features:**
- One-click upvoting with vote counts
- User segmentation on votes (filter by plan, company, attributes)
- AI agent submits votes from support conversations
- Status notifications to voters
- Voter analytics on paid plans
- No anonymous voting on free plan
- No vote limits per user

**Pricing:** Free plan (1 seat, limited features). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- Voter segmentation connects votes to customer data
- AI agent captures votes from support interactions
- Combines voting with support and help center

**Cons:**
- Per-seat pricing adds up for larger teams
- Post merging locked to higher tiers (vote consolidation requires upgrade)
- No self-hosting or open source
- User segmentation requires paid plan

For more detail, see our [Quackback vs Featurebase comparison](/compare/quackback-vs-featurebase).

## 4. [Fider](/compare/quackback-vs-fider)

**Best for:** Developers who want a minimal, self-hosted voting board with zero overhead.

Fider is the other open-source option for feature voting. Built with Go and PostgreSQL, it provides a clean voting board where users submit ideas and upvote them. Setup takes minutes with Docker.

![Fider feature voting board interface](/blog/best-feature-voting-tools/fider.webp)

Users click to upvote. Posts sort by vote count. Comments let voters discuss ideas. Custom statuses communicate progress. That is the full scope of Fider's voting capabilities.

There is no AI deduplication, no voter segmentation, no trending indicators, and no changelog to notify voters when features ship. Fider moved to an open-core model in v0.33.0, putting some features behind the paid cloud tier. Development has slowed.

**Voting features:**
- One-click upvoting with vote counts
- Comments on voted posts
- Custom statuses for voted features
- Anonymous voting via email-only sign-in
- REST API access to vote data
- No vote limits
- No voter analytics or segmentation

**Pricing:** Free and open source for self-hosting. Cloud free tier limited to 250 feedback items. Cloud Pro at $49/month.

**Pros:**
- Lightweight and fast to deploy
- Open source (AGPL-3.0)
- Simple voting experience with no learning curve
- Multi-language support for international voting boards

**Cons:**
- No AI duplicate detection (votes fragment across similar posts)
- No changelog or voter notifications when features ship
- No voter segmentation or analytics
- Development has slowed

See our [Quackback vs Fider comparison](/compare/quackback-vs-fider) for a side-by-side breakdown.

## 5. [Nolt](/compare/quackback-vs-nolt)

**Best for:** Small teams that want a simple voting board they can set up in minutes.

Nolt provides a clean, minimal voting board. Users submit ideas, upvote them, and leave comments. A basic roadmap view groups voted features by status. Voters get notifications when statuses change. Setup takes minutes.

![Nolt feature voting board interface](/blog/best-feature-voting-tools/nolt.webp)

The flat pricing is appealing. Essential is $29/month for one board (billed annually) with no per-user billing. Your voter count can grow without increasing costs. The concern is stagnation. Nolt has seen minimal updates over the past two years. There is no AI duplicate detection, no changelog, and no voter analytics beyond basic counts.

**Voting features:**
- One-click upvoting with vote counts
- Status notifications to voters
- Private and password-protected voting boards
- SSO for voter authentication
- No vote limits
- No voter analytics or segmentation
- No anonymous voting without SSO workarounds

**Pricing:** Essential at $29/month for 1 board (annual). Pro at $69/month for 5 boards. Enterprise is custom.

**Pros:**
- Simple, clean voting interface
- Flat pricing with no per-voter costs
- Quick to set up

**Cons:**
- No changelog (voters are not notified when features ship)
- No AI duplicate detection
- Minimal updates since 2022
- Per-board pricing multiplies costs if you have multiple products
- No self-hosting

See how it compares: [Quackback vs Nolt](/compare/quackback-vs-nolt).

## 6. [Upvoty](/compare/quackback-vs-upvoty)

**Best for:** Budget-conscious teams that want affordable voting boards with a roadmap and changelog.

Upvoty offers feature voting boards at a lower price point than most competitors. Plans start at $15/month. Users submit ideas, upvote them, and get notified when statuses change. Boards can be embedded in your app or accessed via a custom domain.

![Upvoty feature voting board interface](/blog/best-feature-voting-tools/upvoty.webp)

The voting experience covers the essentials: one-click upvotes, vote counts, status labels, and a roadmap view. There is a changelog for announcing shipped features, which closes the loop for voters. The trade-off is depth. No AI duplicate detection, no voter segmentation, and no way to weight votes by customer value.

**Voting features:**
- One-click upvoting with vote counts
- Voter notifications on status changes
- Embeddable voting widget
- Changelog for notifying voters about shipped features
- Custom domain for voting boards
- No voter segmentation
- No vote limits

**Pricing:** Starts at $15/month. Higher tiers available for more boards and features.

**Pros:**
- Affordable starting price for a voting board
- Includes changelog to close the voter loop
- Simple to set up and embed

**Cons:**
- No AI duplicate detection
- Limited integrations
- No voter segmentation or weighted voting
- No self-hosting or open source

See our [Quackback vs Upvoty comparison](/compare/quackback-vs-upvoty) for a full breakdown.

## 7. [Sleekplan](/compare/quackback-vs-sleekplan)

**Best for:** Teams that want an embeddable voting widget with built-in satisfaction surveys.

Sleekplan packages feature voting into an in-app widget alongside a roadmap, changelog, and satisfaction surveys. Voters never leave your product to submit or upvote ideas. Paid plans include AI features for analyzing vote patterns.

![Sleekplan feature voting widget interface](/blog/best-feature-voting-tools/sleekplan.webp)

The voting board supports impact scoring beyond raw vote counts. Posts are scored based on voter engagement and recency, surfacing features with momentum rather than just all-time popularity.

The free plan is limited to a feedback board and changelog with one seat. Roadmap and AI features require the Starter plan at $13/month. Post merging and user segmentation need the Business plan at $38/month.

**Voting features:**
- One-click upvoting with vote counts
- Impact scoring beyond raw vote tallies
- In-app voting widget (no redirect to external board)
- Changelog with subscriber notifications
- AI-powered vote analysis on paid plans
- No vote limits
- Post merging on Business plan ($38/mo)
- No anonymous voting on free plan

**Pricing:** Free Indie plan (1 seat, limited features). Starter at $13/month. Business at $38/month. Enterprise is custom.

**Pros:**
- Embeddable widget keeps voting in-app
- Impact scoring adds nuance beyond raw vote counts
- Affordable starting price
- Built-in surveys complement voting data

**Cons:**
- Post merging (vote consolidation) requires Business plan
- Widget-first approach means the standalone portal is less polished
- Cannot submit votes on behalf of users
- No self-hosting

See how it compares: [Quackback vs Sleekplan](/compare/quackback-vs-sleekplan).

## Comparison table

| Voting feature | Quackback | Canny | Featurebase | Fider | Nolt | Upvoty | Sleekplan |
|---|---|---|---|---|---|---|---|
| **One-click upvote** | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| **Anonymous voting** | Yes | No | Paid plans | Email-only | No | No | Paid plans |
| **Vote limits** | None | Tracked-user tier limits | None | None | None | None | None |
| **Vote notifications** | Yes (status + changelog) | Yes (status) | Yes (status) | No | Yes (status) | Yes (status + changelog) | Yes (changelog) |
| **Trending indicators** | Yes (vote velocity) | No | No | No | No | No | Yes (impact scoring) |
| **Voter analytics** | Yes | Yes | Paid plans | No | No | No | Paid plans |
| **AI duplicate detection** | Yes | Yes (Autopilot) | No | No | No | No | No |
| **Vote merging** | Yes | Yes | Paid plans | No | No | No | Business plan |
| **Voter segmentation** | Yes | Yes (Pro+) | Paid plans | No | No | No | Business plan |
| **Embeddable widget** | Yes | Yes | Yes | No | No | Yes | Yes |
| **Open source** | Yes | No | No | Yes | No | No | No |
| **Self-hosting** | Yes | No | No | Yes | No | No | No |
| **MCP / API access** | Yes (MCP + API) | API | API | REST API | API | API | API |
| **Starting price** | Free | Free (25 tracked users) | $29/seat/mo | Free | $29/mo | $15/mo | Free |

## How to implement feature voting effectively

Setting up a voting board is the easy part. Making it work for your team and your users takes more thought.

**Reduce friction to zero.** Every extra click between your user and the upvote button reduces participation. One-click voting is the baseline. If your tool requires account creation before voting, you lose casual voters. Anonymous voting or lightweight authentication captures a broader signal.

**Solve the duplicate problem early.** Without deduplication, the same request appears under five different titles, each getting a fraction of the votes. Your most-requested feature might look like five mediocre ones. AI duplicate detection (Quackback and Canny) catches this automatically. If your tool lacks it, merge duplicates weekly.

**Weight votes, do not just count them.** Raw vote counts favor features wanted by your largest user segment, often your free tier. Filter by customer plan, company size, or ARR. Ten votes from enterprise customers paying $50,000/year carry different weight than ten from free-trial users. [Quackback](/features/voting) and Featurebase let you segment voters this way.

**Close the loop with voters.** Users who vote and never hear back stop voting. When you ship a feature, voters should know. When you decline one, explain why. Tools with automatic status notifications and a [changelog](/features/changelog) handle this for you.

**Set expectations about what votes mean.** A voting board is not a democracy. Votes inform your decisions but do not dictate them. Some features with fewer votes may be strategically important. Communicate this upfront.

**Review vote data regularly.** Set a weekly or biweekly review. Look at new submissions and vote velocity. A feature that received 50 votes over two years carries different urgency than one that received 50 this week. Trending indicators in Quackback and Sleekplan surface this automatically.

## Frequently asked questions

### What is a feature voting tool?

A feature voting tool lets your users submit product ideas and upvote the ones they care about. Votes create a ranked list of demand that your team uses to inform prioritization. Most also include status tracking, a [public roadmap](/features/roadmap), and notifications so voters know when features ship.

### Should feature voting be anonymous or require authentication?

It depends on your use case. Anonymous voting lowers friction and works well for public-facing products. Authenticated voting ties votes to user profiles and customer segments, giving you richer analytics and preventing manipulation. [Quackback](/features/voting) supports both. If you serve B2B customers and need to know which accounts are voting, authentication is worth the friction.

### How do I prevent duplicate votes from skewing results?

Duplicates are the biggest threat to accurate vote data. When the same feature appears under multiple posts, votes split and your top request looks less popular than it is. Use a tool with AI duplicate detection that catches duplicates at submission time. If your tool lacks this, review new submissions weekly and merge related posts manually.

### What is the best free feature voting tool?

[Quackback](https://quackback.io) is the best free option. It is open source and free to self-host, and [Quackback Cloud](/pricing) offers a managed option from $29/mo with a 14-day free trial. You get AI duplicate detection, voter notifications, a [public roadmap](/features/roadmap), and a [changelog](/features/changelog). Fider is another free self-hosted option but covers only basic voting.

- [7 Best Feature Request Tools in 2026 (Free & Paid)](https://quackback.io/blog/best-feature-request-tools): Comparing the 7 best feature request tracking tools in 2026. Collect, organize, and prioritize user feature requests with voting, roadmaps, AI triage, and an MCP server.

Published: 2026-03-03

Feature requests are the lifeblood of product development. Every product team knows this. But most teams still collect them across Slack threads, support tickets, emails, and spreadsheets. Requests get lost. Duplicates pile up. The loudest voices win, not the most important ones.

A feature request tool gives your users a dedicated place to submit ideas and vote on what matters. Your team gets a structured view of demand, tied to statuses, roadmaps, and development workflows. The right tool makes it easy to collect, organize, and prioritize feature requests without drowning in manual triage.

Here are seven feature request tools in 2026, compared by features, pricing, and trade-offs.

![Best feature request tracking tools compared](/blog/best-feature-request-tools/hero.webp)

> If you need to collect and organize feature requests at scale, Quackback is the best feature request tool: open source, free to self-host (with a managed cloud option), and AI duplicate detection and triage built in. Canny is the strongest hosted alternative for teams that want to capture requests from support tools. Productboard suits enterprise orgs that need strategic prioritization frameworks. Here are all seven ranked:
>
> *Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

1. **[Quackback](https://quackback.io)** — Open source and self-hosted. AI triage, duplicate detection, and MCP server included.
2. **[Canny](/compare/quackback-vs-canny)** — Hosted request boards with AI that extracts feature requests from support conversations.
3. **[Productboard](/compare/quackback-vs-productboard)** — Enterprise product management with request prioritization scoring and driver-based roadmaps.
4. **[Featurebase](/compare/quackback-vs-featurebase)** — Captures feature requests from support inbox and feedback boards in one tool.
5. **[Fider](/compare/quackback-vs-fider)** — Open source, minimal request board. Basic collection with no triage tools.
6. **[Nolt](/compare/quackback-vs-nolt)** — Simple request board with flat-rate pricing. No duplicate detection or changelog.
7. **[Upvoty](/compare/quackback-vs-upvoty)** — Affordable request boards with roadmap and changelog from $15/mo.

## 1. [Quackback](https://quackback.io)

**Best for:** Teams that want an open-source tool to collect, organize, and prioritize feature requests with AI triage.

Quackback is an open-source feature request platform licensed under AGPL-3.0. Users submit requests through [feedback boards](/features/feedback), organized by category and status. Each request collects votes, nested comments, and sentiment data so your team can see exactly what users want and why. Requests flow through statuses from open to planned to shipped, visible on the [public roadmap](/features/roadmap) and announced via the [changelog](/features/changelog).

![Quackback feature request board interface](/blog/best-feature-request-tools/quackback.webp)

The biggest challenge with feature requests is triage. Quackback's AI layer handles the work that buries most teams. Duplicate detection catches redundant requests before they pile up. Merge suggestions identify related posts with reasoning your team can accept or dismiss in one click. Sentiment analysis flags frustrated users. Summaries pull out key quotes and suggest next steps.

The [MCP server](/features/mcp) is unique among feature request tools. It implements the Model Context Protocol, the standard that Claude, Cursor, and Windsurf support. Connect an AI agent and it can search requests, triage incoming posts, write responses, create changelog entries, and merge duplicates. Every action is attributed and auditable.

Self-host with Docker or deploy on Railway. Your data stays in your PostgreSQL database. With [25 integrations](/integrations) including Slack, Linear, Jira, GitHub, Intercom, Zendesk, and Salesforce, feature requests flow directly into your development workflow.

**Key features:**
- Dedicated request submission with categories, tags, and nested comments
- AI duplicate detection and merge suggestions to reduce request sprawl
- Sentiment analysis and automated summaries for faster triage
- [Feature voting](/features/voting) so users can upvote requests that matter to them
- Status tracking from open through planned to shipped
- [MCP server](/features/mcp) for AI agents to search, triage, respond, and merge requests
- [25 integrations](/integrations): Slack, Linear, Jira, GitHub, Intercom, Zendesk, Salesforce, and more
- User segments, SSO/OIDC, webhooks, and full REST API

**Pricing:** Free and open source (AGPL-3.0). Self-host at no cost, or use [Quackback Cloud](/pricing) for a managed option from $29/mo, with a 14-day free trial.

**Pros:**
- Covers the full request lifecycle: collection, triage, prioritization, and shipping
- AI triage included
- MCP server enables AI agent access, something no other feature request tool offers
- Open source means no surprise pricing changes

**Cons:**
- Self-hosting requires running your own infrastructure (the managed cloud removes this)
- Newer than incumbents like Canny and Productboard

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. [Canny](/compare/quackback-vs-canny)

**Best for:** Mid-size SaaS teams that want a hosted tool to capture feature requests from multiple channels.

Canny has been in the feature request space since 2017. Users submit requests through a dedicated board, and your team tracks them with statuses, categories, and internal comments. The AI suite, Autopilot, is the standout for request collection: it discovers feature requests buried in support conversations across Intercom, Zendesk, Help Scout, and Gong, then creates posts automatically. Requests that would otherwise stay trapped in support tickets surface on your board.

![Canny feature request board interface](/blog/best-feature-request-tools/canny.webp)

The pricing model changed in May 2025. Canny moved from per-admin to tiered pricing based on tracked users. A "tracked user" is anyone with a post, vote, or comment attributed to them. Costs increase as you cross tracked user thresholds, with auto-upgrades to the next tier. Canny offers a free plan (25 tracked users) but most teams outgrow it quickly. The first paid tier is Core at $19/mo.

Canny is a solid option if you want a hosted solution and can absorb the scaling costs. The concern is predictability. As your product grows and more users submit requests, your bill grows with them. Several customers have reported unexpected cost increases after the billing model change.

**Key features:**
- Dedicated request boards with categories, statuses, and internal notes
- Autopilot AI discovers requests from support conversations automatically
- Smart replies and comment summarization for faster triage
- Public and private roadmaps linked to requests
- Integrations with Jira, Linear, Slack, HubSpot, and others

**Pricing:** Free plan (25 tracked users). Core from $19/mo. Pro from $79/mo. Business is custom pricing.

**Pros:**
- Mature product with a large user base
- AI extracts feature requests from support tools automatically
- Good integration ecosystem for routing requests to dev teams

**Cons:**
- Tracked-user pricing makes costs unpredictable at scale
- Tiered pricing with auto-upgrades when you exceed tracked user limits
- Jira integration requires Pro ($79/mo)
- No self-hosting option
- Removing "Powered by Canny" branding requires Business plan

For a detailed breakdown, see our [Quackback vs Canny comparison](/compare/quackback-vs-canny).

## 3. [Productboard](/compare/quackback-vs-productboard)

**Best for:** Enterprise product organizations that need to connect feature requests to strategic prioritization frameworks.

Productboard is a product management platform built around a concept it calls "insights." Feature requests from Intercom, Zendesk, Salesforce, email, and Slack are captured as notes and linked to features. The insights portal aggregates requests across channels, so your team can see every customer who asked for the same thing in one place.

![Productboard product management interface](/blog/best-feature-request-tools/productboard.webp)

Where Productboard differs from dedicated request tools is prioritization. You can score requests against custom drivers (revenue impact, user reach, effort), build roadmaps tied to company objectives, and align cross-functional teams around what to build. If your org needs to connect raw feature requests to a formal prioritization process, Productboard provides that layer.

The trade-off is cost and complexity. Productboard's Spark plan costs $15/maker/month (annual) or $19/maker/month (monthly). AI is included via credits (250 per maker per month). Enterprise pricing for SSO and advanced features is custom. For teams that just need to collect and organize feature requests, Productboard is more than you need.

**Key features:**
- Insights portal captures requests from support, sales, and email channels
- Feature prioritization with custom scoring frameworks (RICE, weighted, custom)
- Integrations with Jira, Azure DevOps, Slack, Salesforce, Zendesk, and Intercom
- AI included via credits (250/maker/month) for request summarization and semantic search

**Pricing:** Spark at $15/maker/month (annual) or $19/maker/month (monthly). Enterprise is custom.

**Pros:**
- Connects feature requests to strategic prioritization and scoring
- Aggregates requests across support, sales, and email into one view
- AI included in the base plan via credits
- Enterprise-grade security and compliance

**Cons:**
- AI credits (250/maker/month) may be limiting for heavy users
- Steep learning curve for teams that just need request collection
- No self-hosting
- Overkill if you only need feature request tracking

See our [Quackback vs Productboard comparison](/compare/quackback-vs-productboard) for a full feature-by-feature breakdown.

## 4. [Featurebase](/compare/quackback-vs-featurebase)

**Best for:** Startups that want to capture feature requests from support conversations and feedback boards in one tool.

Featurebase bundles feature request boards with a support inbox, help center, and live chat. The premise is that many feature requests start as support tickets. A customer asks "can I do X?" and your team realizes X does not exist yet. Featurebase keeps the support conversation and the resulting feature request connected.

![Featurebase feature request board interface](/blog/best-feature-request-tools/featurebase.webp)

Their AI agent, Fibi, resolves customer questions using context from your workspace and can submit feature requests to your boards on behalf of customers. This means requests get captured even when users contact support instead of visiting your feedback board.

The free plan gives you one seat and basic boards. Growth starts at $29/seat/month. Fibi AI resolutions cost $0.49 each, which adds up at volume. Post merging and user segmentation, both important for managing request volume, are locked to higher tiers.

**Key features:**
- Feedback boards with categories, statuses, and user segmentation
- AI agent captures feature requests from support conversations ($0.49/resolution)
- Post merging to consolidate duplicate requests (paid tiers)
- Unified support inbox with live chat, email, and ticketing
- 12 integrations: Linear, Jira, GitHub, ClickUp, Slack, Intercom, Zendesk, HubSpot

**Pricing:** Free plan (1 seat, limited features). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- Captures feature requests from support conversations automatically
- Keeps the support-to-request pipeline in one product
- Modern, clean interface

**Cons:**
- Per-seat pricing adds up for larger teams
- AI resolutions at $0.49 each are usage-based
- No self-hosting or open source
- Post merging and segmentation locked to higher tiers

For more detail, see our [Quackback vs Featurebase comparison](/compare/quackback-vs-featurebase).

## 5. [Fider](/compare/quackback-vs-fider)

**Best for:** Developers who want a minimal, open-source place for users to submit feature requests.

Fider is the other open-source option for feature request collection. Built with Go and PostgreSQL, it gives you a single board where users submit requests, vote on them, and discuss in comments. Tags and custom statuses help you organize requests. It deploys with Docker and runs on minimal resources.

![Fider feature request board interface](/blog/best-feature-request-tools/fider.webp)

Fider has been around since 2017 and has a stable codebase. If all you need is a submission board where users can post requests and your team can tag and triage them, Fider covers it.

The limitation is everything beyond basic collection. There is no duplicate detection, so the same request appears under different titles and you merge manually. No changelog means you cannot notify requesters when their feature ships. No roadmap view, no AI features, and integrations are limited to webhook-based connections with Slack, Discord, and Teams. The project moved to an open-core model in v0.33.0, putting content moderation and SEO indexing behind the paid cloud tier. Development has slowed.

**Key features:**
- Single request board with voting, comments, and rich text editor
- Tags, filters, and customizable statuses for organizing requests
- REST API and webhooks (4 event types) for custom workflows
- Multi-language support (10+ languages, including RTL)
- SSO with OAuth providers

**Pricing:** Free and open source for self-hosting. Cloud free tier limited to 250 feedback items. Cloud Pro at $49/month.

**Pros:**
- Lightweight and fast to deploy
- Simple request collection with no learning curve
- Open source (AGPL-3.0)
- Multi-language support

**Cons:**
- No duplicate detection; requests fragment across similar posts
- No changelog, no roadmap, no AI features
- No native Jira, Linear, or GitHub integrations
- Development has slowed

See our [Quackback vs Fider comparison](/compare/quackback-vs-fider) for a side-by-side breakdown.

## 6. [Nolt](/compare/quackback-vs-nolt)

**Best for:** Small teams that want a simple board for collecting feature requests with predictable pricing.

Nolt gives you a clean board where users submit feature requests, vote, and leave comments. Statuses track each request through your process. A basic roadmap view groups requests by status. Setup takes minutes.

![Nolt feature request board interface](/blog/best-feature-request-tools/nolt.webp)

The flat pricing is appealing. Essential is $25/month for one board. No tracked-user billing, no per-seat scaling. You know what you will pay regardless of how many users submit requests.

The concern with Nolt in 2026 is stagnation. The product has seen minimal updates since 2022. There is no duplicate detection, so similar requests pile up without consolidation. No changelog means you cannot notify requesters when features ship. No bulk editing, no comment threading, no AI. If your request volume grows beyond what one person can manually triage, you will outgrow Nolt.

**Key features:**
- Request board with voting, custom statuses, and comments
- Roadmap view grouped by request status
- SSO, private boards, and password-protected boards
- Integrations: Slack, Discord, Jira, Linear, Asana, Trello, GitHub, Zapier (Pro plan)
- Custom domain and branding

**Pricing:** Essential at $25/month for 1 board. Pro at $69/month for 5 boards with moderation, webhooks, and more integrations. Enterprise is custom.

**Pros:**
- Simple and quick to set up
- Flat pricing regardless of request volume
- Clean, user-friendly interface

**Cons:**
- No duplicate detection; similar requests pile up
- No changelog to notify requesters when features ship
- Minimal product updates since 2022
- Per-board pricing multiplies costs across products
- No self-hosting or AI features

For more, see our [Quackback vs Nolt comparison](/compare/quackback-vs-nolt).

## 7. [Upvoty](/compare/quackback-vs-upvoty)

**Best for:** Budget-conscious teams that need a basic request board at a low price point.

Upvoty offers feature request boards with voting, a public roadmap, and a changelog starting at $15/month. Users submit requests, vote on ideas, and get notified when statuses change. Boards can be embedded in your app or accessed via a custom domain.

![Upvoty feature request board interface](/blog/best-feature-request-tools/upvoty.webp)

For basic request collection, Upvoty works. Users submit ideas, your team assigns statuses, and a roadmap shows what is planned. The changelog announces shipped features.

The trade-off is triage tooling. There is no duplicate detection, so similar requests accumulate without consolidation. No user segmentation means you cannot filter requests by customer plan or revenue. Integrations are limited compared to Canny or Quackback. If your request volume is low and your needs are simple, Upvoty covers the basics at a fair price.

**Key features:**
- Request boards with voting, statuses, and tags
- Public roadmap and changelog
- Custom domain and embeddable boards
- SSO support
- Integrations with Slack, Jira, and Zapier

**Pricing:** Starts at $15/month. Higher tiers available for more boards and features.

**Pros:**
- Most affordable hosted request tool on this list
- Covers collection, roadmap, and changelog in one product
- Simple to set up

**Cons:**
- No duplicate detection or request merging
- No user segmentation to filter requests by customer value
- Limited integrations
- No self-hosting or open source

See our [Quackback vs Upvoty comparison](/compare/quackback-vs-upvoty) for a full breakdown.

## Comparison table

| Feature | Quackback | Canny | Productboard | Featurebase | Fider | Nolt | Upvoty |
|---|---|---|---|---|---|---|---|
| **Request submission** | Board + API + integrations | Board + Autopilot from support | Insights portal + integrations | Board + AI agent from support | Board | Board | Board |
| **Duplicate detection** | AI (automatic) | AI (Autopilot) | Manual | No (paid merging) | No | No | No |
| **Request merging** | Yes (AI-suggested) | Yes | Manual | Paid tiers | No | No | No |
| **Status tracking** | Custom statuses | Custom statuses | Custom statuses | Custom statuses | Custom statuses | Custom statuses | Preset statuses |
| **Requester notifications** | Yes (status + changelog) | Yes (status + changelog) | Yes (email) | Yes (status + changelog) | No | Yes (status) | Yes (status + changelog) |
| **User segmentation** | Yes | Yes (Pro+) | Yes | Paid tiers | No | No | No |
| **AI triage** | Yes (sentiment, summaries, merge suggestions) | Yes (Autopilot) | Included via credits (250/maker/mo) | Fibi ($0.49/resolution) | No | No | No |
| **MCP server** | Yes | No | No | No | No | No | No |
| **Dev tool integrations** | Jira, Linear, GitHub + 20 more | Jira (Pro+), Linear, Slack | Jira, Azure DevOps, Slack | Jira, Linear, GitHub, ClickUp | Webhooks only | Jira, Linear, GitHub (Pro) | Jira, Slack, Zapier |
| **Open source** | Yes (AGPL-3.0) | No | No | No | Yes (AGPL-3.0) | No | No |
| **Self-hosting** | Yes | No | No | No | Yes | No | No |
| **Starting price** | Free | Free (25 tracked users) | $15/maker/mo (annual) | $29/seat/mo | $49/mo (cloud) | $25/mo | $15/mo |

## What to look for in a feature request tool

Not every feature request tool fits every team. Here are the criteria that matter most when evaluating your options.

**Submission and collection channels.** Your users submit feature requests everywhere: in-app, through support, on Slack, in sales calls, and via email. A good tool consolidates these channels into one place. Look for native integrations with your support tools and the ability to submit requests on behalf of users. If requests stay scattered, you will never get an accurate picture of demand.

**Duplicate detection and merging.** The same feature request appears under five different titles. Without deduplication, your most-requested feature looks like five mediocre ones. AI duplicate detection catches this at submission time. Manual merging handles what AI misses. This is the single most impactful capability for high-volume request management.

**Voting and prioritization.** Users should be able to vote on requests. Look for tools that go beyond simple upvote counts. User segments, revenue data, and scoring frameworks help you distinguish between "many users want this" and "your highest-value customers need this."

**Roadmap integration.** Feature requests are only useful if they connect to what you are building. A built-in roadmap lets you show users what is planned, in progress, and shipped. It closes the feedback loop and reduces "when is this coming?" inquiries.

**Notifications and status updates.** When you ship a feature, every user who requested or voted for it should know. Automatic notifications turn your feature request board into a retention tool. Users who feel heard stay engaged.

**API and integrations.** Feature requests need to flow into your development workflow. Look for native integrations with your issue tracker (Jira, Linear, GitHub) and communication tools (Slack, Teams). A REST API or webhooks let you build custom workflows.

**Pricing model.** This matters more than most teams realize. Tiered tracked-user pricing (Canny) means costs increase as you cross user thresholds. Per-seat pricing (Featurebase, Productboard) scales with team size. Per-board pricing (Nolt) scales with products. Open-source self-hosting (Quackback, Fider) gives you a fixed infrastructure cost. Understand how your costs will grow before you commit.

**Self-hosting and data ownership.** If your organization has data residency requirements, compliance obligations, or simply wants to own its feedback data, self-hosting matters. Only Quackback and Fider offer this. Every other tool on this list stores your data on their servers.

**AI capabilities.** In 2026, AI is no longer optional for high-volume feature request management. Duplicate detection prevents the same request from appearing dozens of times. Sentiment analysis surfaces frustrated users. Summarization helps product managers process large volumes of feedback without reading every post. Look for tools where AI is built in, not bolted on as a per-use add-on.

## How to manage feature requests effectively

Collecting feature requests is the easy part. The hard part is turning them into informed product decisions.

**Give users a single place to submit requests.** Consolidate feedback from Slack, email, support tickets, and sales calls into one tool. When requests live in multiple places, duplicates multiply and signal gets lost.

**Use voting to surface demand, not to make decisions.** Vote counts tell you what's popular, but popularity alone is not a prioritization strategy. Combine voting data with user segments, revenue impact, and strategic alignment. Use a framework like RICE (Reach, Impact, Confidence, Effort) to score requests objectively. Our [RICE scoring calculator](/tools/rice-scoring-calculator) can help you apply this consistently.

**Close the loop.** When you ship a feature, notify every user who requested or voted for it. When you decline a request, explain why. Users who see their feedback acknowledged, even when the answer is no, are more likely to keep contributing.

**Triage regularly.** Set a cadence for reviewing new requests. Merge duplicates. Update statuses. Respond to questions. A feature request board that goes unmanaged is worse than having no board at all, because it signals to users that their feedback goes nowhere.

**Connect requests to your development workflow.** Link accepted feature requests to issues in Jira, Linear, or GitHub. This keeps your engineering team in their existing tools while maintaining a direct line from user feedback to shipped code.

## Frequently asked questions

### What is a feature request tool?

A feature request tool is software that helps you collect, organize, and prioritize product ideas from your users. Users submit requests, vote on ideas, and follow status updates. Your team uses voting data and integrations with tools like Jira or Linear to decide what to build next.

### What is the best free feature request tool?

[Quackback](https://quackback.io) is the best free feature request tool. It is open source and free to self-host, including [feature voting](/features/voting), a [roadmap](/features/roadmap), [changelog](/features/changelog), and built-in AI. Fider is another free self-hosted option, but covers only voting boards and comments.

### How do I prioritize feature requests?

Collect votes to gauge demand, then layer in customer segment, attached revenue, and strategic alignment. Frameworks like RICE (Reach, Impact, Confidence, Effort) score requests objectively rather than by gut feeling. Try our [RICE scoring calculator](/tools/rice-scoring-calculator). AI tools like [Quackback](https://quackback.io) automate triage by detecting duplicates and summarizing feedback.

### Should I use a feature request tool or just a spreadsheet?

A dedicated tool wins once you pass a handful of requests. Spreadsheets cannot let users self-serve voting, surface duplicates, notify requesters, or connect to your dev workflow. Past a dozen requests or a few hundred users, a tool like [Quackback](https://quackback.io) saves significant time. See our [best customer feedback tools guide](/blog/best-customer-feedback-tools-2026) for more.

### What is the difference between a feature request tool and a bug tracking tool?

A feature request tool collects and prioritizes new product ideas from users, using public voting, roadmaps, and changelogs. A bug tracking tool like Jira or Linear manages defects and engineering tasks internally. Many teams pair both, linking accepted requests to bug-tracker issues via [integrations](/integrations/jira).

- [7 Best Beamer Alternatives for Changelogs and Product Updates in 2026](https://quackback.io/blog/best-beamer-alternatives): Looking for a Beamer alternative? Compare 7 changelog and product update tools with feedback features, open-source options, and better pricing.

Published: 2026-03-01

Beamer started as a changelog and notification tool. It helps SaaS teams announce product updates through in-app widgets, notification centers, and standalone changelog pages. For pure announcement workflows, it does the job.

But if you also need feedback collection, feature voting, and roadmaps, Beamer doesn't cover it. You end up paying for two tools: one for announcements and another for feedback. Beamer's pricing reflects its announcement focus — paid plans start at $49/month and scale based on monthly active users, not the size of your team or the number of features you use.

The result is a tool that does one thing well but leaves gaps that most product teams need to fill. Teams that want a single tool for the full loop — collect feedback, prioritize, build, announce — find themselves looking elsewhere.

If you are re-evaluating Beamer, here are seven alternatives that cover more ground, cost less, or give you better control over your data.

![Seven Beamer alternatives compared](/blog/best-beamer-alternatives/hero.webp)

**TLDR:** The best Beamer alternatives ranked:

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

1. **[Quackback](https://quackback.io)** — Changelog + feedback + roadmap in one. Open source. Free.
2. **[Canny](/compare/quackback-vs-canny)** — Feedback-focused with changelog feature. From $19/mo.
3. **[Featurebase](/compare/quackback-vs-featurebase)** — Changelog + feedback + roadmap + support inbox. Free plan.
4. **[AnnounceKit](/compare/quackback-vs-announcekit)** — Pure changelog alternative with segmentation. From $89/mo.
5. **[Frill](/compare/quackback-vs-frill)** — Simple changelog + feedback boards. From $25/mo.
6. **[Sleekplan](/compare/quackback-vs-sleekplan)** — Widget-first with changelog and feedback. From $13/mo.
7. **[Headway](/compare/quackback-vs-headway)** — Lightweight changelog tool. Free plan available.

## Why teams switch from Beamer

The most common reasons teams look for a Beamer alternative:

- **Changelog-only focus.** Beamer is built around announcements. There is no feature voting, no feedback boards, no roadmap. If your team wants to close the loop with users — collecting what they want and showing them what you're building — you need a second tool.
- **No feedback collection.** Beamer lets users react to posts with emoji reactions, but it does not support structured feedback. You cannot capture feature requests, triage submissions, or track votes in Beamer. For teams that treat the changelog as part of a feedback workflow, this is a real gap.
- **MAU-based pricing.** Beamer charges based on monthly active users who see your widget or page. Costs can increase as your product grows, independent of how many features you actually use. Teams with large user bases pay more even if they only send one update a month.
- **No open-source option.** Beamer is a closed, hosted SaaS product. You cannot self-host it, audit the code, or migrate away without losing your announcement history. For teams that care about data ownership or vendor lock-in, this is a constraint.
- **Need for an all-in-one solution.** Most teams using Beamer pair it with a separate feedback tool like Canny or a feature voting board. Consolidating into a single product that handles the full workflow — collect, prioritize, build, announce — is cheaper and simpler to operate.

## 1. Quackback

[Quackback](https://quackback.io) is open source (AGPL-3.0), self-hosted, and free. It covers the complete product feedback loop that Beamer covers only a slice of: [feedback boards](/features/feedback) with [voting](/features/voting), a [public roadmap](/features/roadmap), a [changelog](/features/changelog), SSO/OIDC, custom branding, and 25 integrations including Slack, Jira, Linear, GitHub, Intercom, Zendesk, and Salesforce.

![Quackback changelog and feedback interface](/blog/best-beamer-alternatives/quackback.webp)

The [changelog](/features/changelog) works differently from Beamer's. When you ship a feature, you can notify every user who voted for it — automatically. Voters get a direct message that the thing they asked for is done. No manual list-building, no broadcast to everyone, no unsubscribes from users who didn't care.

The in-app widget lets users view your changelog, submit feedback, and vote on ideas without leaving your product. Beamer's widget is announcement-only. Quackback's widget is a two-way channel.

The AI features extend what you can do with the feedback you collect. Duplicate detection catches redundant posts before they pile up. Merge suggestions identify related requests with reasoning your team can accept or dismiss in one click. Sentiment analysis runs on every post. Summaries pull out key quotes and next steps. The AI connects to any OpenAI-compatible provider.

The [MCP server](/features/mcp) is something no other tool on this list offers. It implements the Model Context Protocol, the standard that Claude, Cursor, and Windsurf support. Connect an AI agent and it gets full access to your feedback data: search posts, triage requests, write responses, create changelog entries, and merge duplicates. Every action is attributed and auditable.

**Key features:**
- [Changelog](/features/changelog) with automatic voter notifications and in-app widget
- Feature request boards with voting, status tracking, and nested comments
- Public roadmap with planned, in-progress, and shipped views
- Built-in AI: duplicate detection, merge suggestions, sentiment analysis, post summaries
- MCP server for AI agents (search, triage, respond, create, merge)
- 25 integrations: Slack, Linear, Jira, GitHub, Intercom, Zendesk, Salesforce, and more
- SSO/OIDC, webhooks, full REST API
- Custom branding with themes, custom CSS, and your own domain

**Pricing:** Free and open source. Self-host with Docker or deploy on Railway at no cost.

**Pros:**
- Full changelog + feedback + roadmap workflow at no cost
- Automatic voter notifications on shipped features
- Built-in AI for duplicate detection, merge suggestions, sentiment, and summaries
- MCP server for AI agent access — unique in the category
- Open source — audit the code, fork it, own your data
- No MAU-based pricing surprises

**Cons:**
- Self-hosted only — no managed cloud option
- You manage your own infrastructure (Docker or Railway)
- Newer project with a smaller community than Beamer

**Best for:** Teams that want changelog, feedback, and roadmap in one open-source tool with no usage-based pricing.

For a detailed look at what Quackback's changelog can do, see the [changelog feature page](/features/changelog).

---

> **Try Quackback** — open source and self-hosted. Deploy in under five minutes with Docker.
> [Get started free](/docs) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. Canny

[Canny](/compare/quackback-vs-canny) is one of the most established feedback tools in the category. It covers feature request boards, voting, roadmaps, changelogs, and AI-powered feedback discovery through its Autopilot feature. If you are switching from Beamer because you want feedback collection alongside announcements, Canny covers the feedback side well.

![Canny feedback board and changelog interface](/blog/best-beamer-alternatives/canny.webp)

Canny's changelog is functional — you can publish release notes, notify users by email, and link changelog entries to the feature requests that drove them. The link between a feature request and the announcement it generated is a genuine advantage over Beamer's standalone widget approach.

Autopilot AI discovers feedback from support conversations in Intercom, Zendesk, Help Scout, and Gong, plus 10 public review sites. This is useful if your team fields large volumes of support tickets and wants to extract feature signals automatically.

The billing model uses tiered pricing based on tracked users — anyone who posts, votes, or comments on your board counts toward your tier. The Core plan starts at $19/mo for 100+ tracked users. Crossing a tier threshold triggers an auto-upgrade. For teams with large communities, costs can increase quickly.

**Key features:**
- Feedback boards with voting and prioritization
- Public and private roadmaps
- Changelog with email notifications
- Autopilot AI: feedback discovery from support conversations and review sites
- Integrations with Jira, Linear, Slack, Intercom, HubSpot, and more

**Pricing:** Free (25 tracked users). Core from $19/mo. Pro from $79/mo. Business is custom pricing.

**Pros:**
- Established product with a large user base
- Strong AI feedback discovery via Autopilot
- Changelog linked to source feature requests
- Good integration ecosystem

**Cons:**
- Tiered tracked-user pricing can increase costs as your community grows
- Auto-upgrades when you exceed tracked user limits
- No self-hosting or open source
- Jira integration requires the Pro plan ($79/mo)

**Best for:** SaaS teams that want feedback collection and a changelog in one hosted tool with AI-powered discovery.

See how it compares: [Quackback vs Canny](/compare/quackback-vs-canny).

## 3. Featurebase

[Featurebase](/compare/quackback-vs-featurebase) bundles feedback boards, a changelog, roadmap, help docs, and a unified support inbox into one product. It has a free plan (1 seat, limited features) and is one of the more complete all-in-one options at the lower end of the price range.

![Featurebase changelog and feedback interface](/blog/best-beamer-alternatives/featurebase.webp)

Where Beamer is announcement-only, Featurebase is the opposite direction: it treats the support inbox and feedback board as equally important as the changelog. The Fibi AI agent can auto-resolve customer questions using context from your help center, feedback posts, and past conversations — and it can submit feature requests on behalf of users. AI resolutions cost $0.49 each, which adds up at volume.

Featurebase is closed source and hosted only. Per-seat pricing ($29–99/seat/month on paid plans) means costs grow with your team. Post merging and user segmentation are locked to higher tiers. But for teams that want a free starting point with feedback and announcement features in one place, it is a solid option.

**Key features:**
- Feedback boards with voting, status tracking, and user segmentation
- Changelog with scheduled posts and subscriber notifications
- Public roadmap
- Unified support inbox with live chat and email
- Fibi AI Agent for auto-resolving questions ($0.49/resolution)
- 12 integrations: Linear, Jira, GitHub, Slack, Intercom, Zendesk, and more

**Pricing:** Free (1 seat, limited). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- Free tier available for getting started
- All-in-one: feedback, support, help docs, and changelog
- Surveys (NPS, CSAT) included on paid plans
- Growing fast with regular feature updates

**Cons:**
- Per-seat pricing adds up for larger teams
- AI resolutions are usage-based ($0.49 each)
- No self-hosting, no open source
- Post merging locked to higher tiers

**Best for:** Small teams wanting a free hosted option that combines changelog, feedback boards, and support in one product.

See how it compares: [Quackback vs Featurebase](/compare/quackback-vs-featurebase).

## 4. AnnounceKit

[AnnounceKit](/compare/quackback-vs-announcekit) is the closest direct Beamer replacement on this list. It is purpose-built for product announcements — in-app widgets, standalone changelog pages, email notifications, and RSS feeds. If you want to replace Beamer with something that does the same thing better, AnnounceKit is worth a look.

![AnnounceKit changelog widget interface](/blog/best-beamer-alternatives/announcekit.webp)

The main advantages over Beamer are segmentation and targeting. You can show changelog entries to specific user segments based on plan, role, language, or custom attributes. You can run NPS surveys and reaction polls inside the widget. The analytics dashboard tracks views, clicks, and engagement per post.

AnnounceKit does not have feedback boards or feature voting. Like Beamer, it is a one-way announcement tool. If you need feedback collection alongside announcements, you will still need a second product.

Pricing starts at $89/mo for the Essentials plan (1 team member, no segmentation). The Growth plan at $149/mo adds user segmentation, Slack, and Intercom. The Scale plan at $399/mo adds SSO/SAML and Jira. NPS surveys are a separate product at $49/mo.

**Key features:**
- In-app widget with unread post badges and notification center
- Standalone changelog page with custom domain
- Email notifications and RSS feed for subscribers
- User segmentation for targeted announcements
- NPS surveys and reaction polls
- Analytics: views, clicks, and engagement per post
- Integrations: Slack, Intercom, HubSpot, Zapier, and more

**Pricing:** Essentials at $89/mo. Growth at $149/mo. Scale at $399/mo. NPS is a separate product at $49/mo.

**Pros:**
- Purpose-built for changelogs with polished widget UI
- User segmentation for targeted posts
- Built-in NPS surveys and reactions
- No MAU-based pricing — flat monthly rate
- Clean analytics per post

**Cons:**
- No feedback boards or feature voting
- More expensive than Beamer's entry plan at comparable feature levels
- No self-hosting or open source
- Still requires a second tool for feedback collection

**Best for:** Teams that want a pure changelog tool with better segmentation and targeting than Beamer.

See how it compares: [Quackback vs AnnounceKit](/compare/quackback-vs-announcekit).

## 5. Frill

[Frill](/compare/quackback-vs-frill) covers both changelogs and feedback boards in a single hosted product. It is simpler than Featurebase or Canny but more complete than Beamer or Headway. You get a feedback board with voting, a public roadmap, and a changelog — the three core pieces of the product feedback loop.

![Frill changelog and feedback board interface](/blog/best-beamer-alternatives/frill.webp)

The interface is clean and takes minutes to configure. Users submit ideas, vote on existing ones, and follow your roadmap through stages. When something ships, you publish a changelog entry and notify followers. There is no AI, no support inbox, and fewer integrations than Featurebase or Canny. But for teams that want a lightweight all-in-one tool without a steep learning curve, Frill is a practical choice.

Frill uses idea-based pricing on its lower plans. The Startup plan at $25/mo covers 50 ideas. The Business plan at $49/mo unlocks unlimited ideas. Both include the changelog, feedback boards, and roadmap. The Growth plan at $149/mo adds white labeling and advanced surveys.

**Key features:**
- Feedback board with voting and custom statuses
- Public roadmap with stage-based views
- Changelog with email notifications to followers
- In-app widget for feedback submission and changelog display
- Custom branding and domain on Business plan
- SSO on Business plan
- Integrations: Slack, Jira, Linear, Zapier

**Pricing:** Startup at $25/mo (50 ideas). Business at $49/mo (unlimited). Growth at $149/mo. Enterprise from $349/mo.

**Pros:**
- Covers feedback, roadmap, and changelog in one product
- Clean, easy to set up
- In-app widget included
- Reasonable entry price for small teams

**Cons:**
- Idea limits on the Startup plan ($25/mo)
- No AI features
- White labeling requires the Growth plan ($149/mo)
- Fewer integrations than Canny or Featurebase
- No self-hosting or open source

**Best for:** Small to mid-size teams that want a simple changelog and feedback board without the complexity of larger platforms.

See how it compares: [Quackback vs Frill](/compare/quackback-vs-frill).

## 6. Sleekplan

[Sleekplan](/compare/quackback-vs-sleekplan) takes a widget-first approach to feedback and announcements. Instead of directing users to a separate portal, Sleekplan embeds directly into your app as an in-app widget. Users can read your changelog, submit feedback, vote on ideas, and respond to satisfaction surveys without leaving your product.

![Sleekplan in-app widget interface](/blog/best-beamer-alternatives/sleekplan.webp)

The built-in CSAT and NPS surveys are a genuine differentiator. Most tools treat surveys as a separate concern. Sleekplan includes them natively, so you measure satisfaction alongside feature requests and changelog engagement. For teams switching from Beamer who want to add feedback collection and surveys without a major tool change, the embedded widget makes the transition low-friction.

The free Indie plan is limited: one seat, no roadmap, no surveys, no AI. The Starter plan at $13/mo unlocks the roadmap, surveys, and basic AI features. The Business plan at $38/mo adds post merging, user segmentation, and conditional surveys.

**Key features:**
- Changelog with scheduled posting and subscriber notifications
- Feedback board with voting, status updates, and impact scoring
- Roadmap (Starter plan and above)
- Built-in CSAT and NPS surveys
- Embeddable in-app widget, standalone site, or iframe
- 12 integrations: Jira, Linear, Slack, Intercom, GitHub, Zapier, and more

**Pricing:** Free Indie plan (1 seat, limited). Starter at $13/mo. Business at $38/mo. Enterprise is custom.

**Pros:**
- In-app widget reduces friction for feedback and changelog consumption
- Built-in NPS/CSAT surveys included
- Free tier available
- Affordable paid plans — cheaper than Beamer at comparable feature levels

**Cons:**
- Free plan is very limited (no roadmap, no surveys, no AI)
- Widget-first means the standalone portal is less polished
- Post merging requires the Business plan ($38/mo)
- No self-hosting, no open source

**Best for:** Teams prioritizing in-app changelog and feedback collection with built-in satisfaction surveys.

See how it compares: [Quackback vs Sleekplan](/compare/quackback-vs-sleekplan).

## 7. Headway

[Headway](/compare/quackback-vs-headway) is the lightest tool on this list. It is a standalone changelog product with an in-app widget, a hosted changelog page, email notifications, and a basic RSS feed. No feedback boards, no roadmap, no voting. Pure announcements.

![Headway changelog widget interface](/blog/best-beamer-alternatives/headway.webp)

Headway's appeal is simplicity and price. The free plan includes unlimited changelog entries and the in-app widget — with Headway branding. The Pro plan at $29/mo removes branding, adds a custom domain, Slack integration, and team management. Two plans, flat-rate, no MAU-based pricing.

For teams that want a Beamer replacement focused purely on announcements — and want to get started for free — Headway is worth considering. The feature set is narrower than Beamer's. There are no reactions, no NPS surveys, no detailed analytics per post. But if your only goal is to publish release notes and notify users, it does that reliably at a lower cost.

**Key features:**
- In-app widget with unread notification badge
- Hosted changelog page with custom domain (Pro)
- White labeling on Pro plan
- Integrations: Slack, Twitter/X (Pro only)

**Pricing:** Free (unlimited entries, Headway branding). Pro at $29/mo (removes branding, custom domain, Slack, team management).

**Pros:**
- Free plan with no entry limit and no MAU pricing
- Two simple plans — no complex tier structure
- Quick to set up and operate

**Cons:**
- No feedback boards, no roadmap, no voting
- No reactions, no NPS surveys, no email notifications
- No API or webhooks
- Very limited integrations (Slack and Twitter/X only on Pro)
- No self-hosting or open source

**Best for:** Teams that want a free, lightweight changelog widget with no MAU-based pricing and no complexity.

See how it compares: [Quackback vs Headway](/compare/quackback-vs-headway).

## Comparison table

| | Beamer | Quackback | Canny | Featurebase | AnnounceKit | Frill | Sleekplan | Headway |
|---|---|---|---|---|---|---|---|---|
| **Starting price** | $0 (limited) | Free | Free (25 users) | Free (1 seat) | $89/mo | $25/mo | Free (1 seat) | Free |
| **Changelog** | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| **Feedback boards** | No | Yes | Yes | Yes | No | Yes | Yes | No |
| **Roadmap** | No | Yes | Yes | Yes | No | Yes | Yes | No |
| **Feature voting** | No | Yes | Yes | Yes | No | Yes | Yes | No |
| **In-app widget** | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| **User segmentation** | Yes | Yes | Limited | Yes | Growth plan | Growth plan | Yes | No |
| **AI features** | No | Yes (built-in) | Autopilot | Fibi | AI editor | Smart Merge | Sleek Intelligence | No |
| **Open source** | No | Yes (AGPL-3.0) | No | No | No | No | No | No |
| **Self-hosting** | No | Yes | No | No | No | No | No | No |

## How to choose

Start with what you actually need. If Beamer covered your use case and you just want something cheaper or with better segmentation, AnnounceKit or Headway are the most direct replacements.

**If you want to replace Beamer and add feedback collection:** Quackback gives you changelog, feedback boards, and a public roadmap in a single tool for free. You also get AI features and automatic voter notifications when features ship — something Beamer cannot do.

**If you want a hosted all-in-one tool:** Featurebase has the broadest feature set on a free plan. Canny is stronger on the feedback side. Frill is simpler with a lower learning curve.

**If cost is the priority:** Headway is free. Sleekplan starts at $13/mo. Quackback is free if you can self-host. None of them use MAU-based pricing.

**If you want open source:** Quackback is the only open-source option in this category that includes a changelog. You get the full workflow — feedback, roadmap, changelog — with no vendor lock-in, no pricing tiers, and no user limits.

For a broader look at changelog tools beyond this list, see [Best Changelog Tools in 2026](/blog/best-changelog-tools). For the feedback side of the equation, see [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026).

## Frequently asked questions

### What is the best free alternative to Beamer?

[Quackback](https://quackback.io) is the most complete free alternative. It is open source and self-hosted — you get a [changelog](/features/changelog) with automatic voter notifications, feedback boards with voting, a public roadmap, 25 integrations, SSO/OIDC, and built-in AI. Headway also has a free plan, but it covers only the announcement side with no feedback or roadmap. If you want the pure-changelog workflow, Headway is a simpler free start.

### Can I replace Beamer with a tool that also collects feedback?

Yes. Several tools on this list cover both changelogs and feedback collection. Quackback, Canny, Featurebase, Frill, and Sleekplan all include feedback boards alongside changelog features. Quackback is the only one that is open source and free. If you want a hosted option with a free tier, Featurebase or Sleekplan are worth evaluating. For more on building a feedback workflow, see the [guide to collecting customer feedback](/blog/best-customer-feedback-tools-2026).

### How does Beamer's pricing compare to alternatives?

Beamer's paid plans start at $49/mo and scale based on monthly active users. Most alternatives use flat-rate or per-seat pricing, which is more predictable. AnnounceKit starts at $89/mo (flat rate, no MAU pricing). Sleekplan starts at $13/mo. Headway has a free plan with Pro at $29/mo. Quackback is free to self-host with no usage-based pricing at all. For teams concerned about costs scaling with product growth, MAU-based pricing like Beamer's is worth examining closely before committing. See our [release notes template](/blog/release-notes-template) and [product update announcement guide](/blog/product-update-announcement) for tips on running an effective changelog workflow regardless of which tool you choose.

- [7 Best Upvoty Alternatives in 2026 (Free & Open Source)](https://quackback.io/blog/best-upvoty-alternatives): Compare 7 Upvoty alternatives with more features, AI, and open-source options. Honest pros, cons, and pricing for each tool.

Published: 2026-02-28

Upvoty covers the basics. Boards, voting, a roadmap, and a changelog — the core feedback workflow in a single hosted tool. For teams that need exactly that and nothing more, it works.

But "simple" also means limited. Upvoty has no AI features. No open-source option. No self-hosting. The integration list is short. And the product has seen minimal development in recent years while competitors have added AI analysis, duplicate detection, MCP servers, and deeper integrations with the tools product teams already use.

Upvoty's pricing is per-board on lower tiers. The Power plan ($15/mo) covers one board. Multi-product teams on the Superpower plan ($39/mo) get unlimited boards. There are no tracked-user limits, which is an advantage over Canny. But there is also no free tier — once the trial ends, you pay.

Teams that outgrow Upvoty typically want one of three things: more features (AI, better integrations, changelog history), a free or open-source option, or a clearer product development roadmap from the vendor. Here are seven alternatives worth considering.

![Seven Upvoty alternatives compared](/blog/best-upvoty-alternatives/hero.webp)

> The best Upvoty alternative is **Quackback**, an open-source feedback tool you can self-host for free or run on Quackback Cloud, with built-in AI and an MCP server. **Featurebase** and **Sleekplan** are the strongest hosted options with free tiers, and **Canny** offers the deepest integrations. The full ranked list:
>
> 1. **[Quackback](https://quackback.io)** — Open source, self-hosted free or managed cloud. AI + MCP server included.
> 2. **[Canny](/compare/quackback-vs-canny)** — Established feedback tool with strong integrations and AI Autopilot. From $19/mo.
> 3. **[Featurebase](/compare/quackback-vs-featurebase)** — Free tier with feedback, changelog, roadmap, and a support inbox.
> 4. **[Frill](/compare/quackback-vs-frill)** — Simple and affordable with clean boards and a changelog. From $25/mo.
> 5. **[Sleekplan](/compare/quackback-vs-sleekplan)** — Widget-first with built-in NPS/CSAT surveys. From $13/mo.
> 6. **[Nolt](/compare/quackback-vs-nolt)** — Flat-rate pricing, clean feedback boards, no per-user billing. $29/mo.
> 7. **[Fider](/compare/quackback-vs-fider)** — Open source, bare-bones voting board. Free to self-host.

*Pricing last verified February 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

## Why teams switch from Upvoty

The most common reasons teams look for an Upvoty alternative:

- **No AI features.** Upvoty has no duplicate detection, no merge suggestions, no sentiment analysis, and no AI-assisted triage. As feedback volumes grow, manual curation becomes the bottleneck. Competitors have invested heavily in AI tooling; Upvoty has not.
- **Limited integrations.** Upvoty connects to Slack, Jira, and Zapier. There is no native Linear, GitHub, Intercom, Zendesk, or Salesforce integration. Teams with established stacks often hit this ceiling quickly.
- **No open-source or self-hosting option.** Your data lives on Upvoty's servers with no alternative. Teams with data residency requirements or a preference for infrastructure ownership have no path forward.
- **Minimal product development.** As of early 2026, Upvoty's public changelog shows few notable feature additions, and long-standing requests — a better API, post merging, user segmentation — remain unbuilt.
- **No free tier.** Unlike Featurebase and Sleekplan, Upvoty has no free plan. You pay from day one.
- **Per-board pricing.** Multi-product teams on the Power plan pay per board. Managing feedback across several products or internal tools gets expensive before you reach the flat-rate Superpower plan.

## 1. Quackback

[Quackback](https://quackback.io) is open source (AGPL-3.0), self-hosted, and free. No feature gates.

![Quackback feedback board interface](/blog/best-upvoty-alternatives/quackback.webp)

You get the full feedback workflow in a single product: [feedback boards](/features/feedback) with [voting](/features/voting), a [public roadmap](/features/roadmap), a [changelog](/features/changelog), SSO/OIDC, custom branding, and 25 integrations including Slack, Jira, Linear, GitHub, Intercom, Zendesk, and Salesforce. Everything Upvoty lacks — AI, self-hosting, open source, deep integrations — is included at no cost when you self-host.

The AI features are where Quackback pulls well ahead of Upvoty. Duplicate detection catches redundant posts before they pile up. Merge suggestions identify related requests with reasoning your team can accept or dismiss in one click. Sentiment analysis runs on every post. Summaries pull out key quotes and next steps.

The [MCP server](/features/mcp) is something no other feedback tool in this category offers. It implements the Model Context Protocol, the standard that Claude, Cursor, and Windsurf support. Connect an AI agent and it gets full, structured access to your feedback data: search posts, triage requests, write responses, create changelog entries, and merge duplicates. Every action is attributed and auditable.

**Key features:**
- Feature request boards with voting, status tracking, and nested comments
- Public roadmap and changelog with automatic voter notifications
- Built-in AI: duplicate detection, merge suggestions, sentiment analysis, post summaries
- MCP server for AI agents (search, triage, respond, create, merge)
- 25 integrations: Slack, Linear, Jira, GitHub, Intercom, Zendesk, Salesforce, and more
- SSO/OIDC, webhooks, full REST API
- Custom branding with themes, custom CSS, and your own domain

**Pricing:** Free and open source to self-host with Docker, or run it on the managed [Quackback Cloud](/pricing) if you would rather not manage infrastructure.

**Pros:**
- Full-featured feedback, roadmap, and changelog in one product
- AI included at no extra cost when self-hosted (bring your own model key)
- MCP server for AI agent access
- Open source — audit the code, fork it, own your data
- Self-host for free or use the managed cloud
- 25 integrations, SSO, and custom branding included on every self-hosted installation

**Cons:**
- Self-hosting means you manage your own infrastructure (the managed cloud removes this)
- Newer project with a smaller community than established SaaS tools

**Best for:** Teams that want open-source, self-hosted feedback with AI and no usage limits.

For a detailed side-by-side breakdown, see the [full Quackback vs Upvoty comparison](/compare/quackback-vs-upvoty).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. Canny

[Canny](/compare/quackback-vs-canny) is one of the most established feedback tools in the category. It covers boards, voting, a roadmap, and a changelog — the same core workflow as Upvoty — with a stronger integration suite and a more active development pace.

![Canny feedback board interface](/blog/best-upvoty-alternatives/canny.webp)

Where Upvoty's integration list tops out at Slack, Jira, and Zapier, Canny connects natively to Linear, GitHub, ClickUp, Intercom, Zendesk, Salesforce, HubSpot, and more. The Autopilot AI feature, included on all paid plans, detects feedback from Intercom and Zendesk conversations and automatically creates posts on your board without manual triage.

The trade-off is pricing structure. Canny moved to tiered tracked-user pricing in May 2025. A tracked user is anyone who posts, votes, or comments. Costs increase as you cross tier thresholds, and auto-upgrades to the next tier can catch teams off guard. The Core plan starts at $19/mo (annual) for 100+ tracked users. Jira, Linear, and ClickUp integrations require the Pro plan ($79/mo).

**Key features:**
- Feedback boards with voting, status tracking, and custom fields
- Roadmap and changelog with scheduled posts
- Autopilot AI: auto-capture feedback from Intercom and Zendesk
- Integrations: Jira, Linear, GitHub, ClickUp, Intercom, Zendesk, Salesforce, HubSpot, and more
- SSO (Business plan), custom domain, and custom branding

**Pricing:** Free plan (25 tracked users). Core at $19/mo (annual). Pro at $79/mo. Business is custom.

**Pros:**
- Established product with a large user base and frequent updates
- Strong integration suite including CRM and support tools
- AI Autopilot included on all paid plans
- Clean, polished interface

**Cons:**
- Tracked-user pricing can spike unexpectedly
- Free plan limited to 25 tracked users
- PM integrations (Jira, Linear) locked to Pro plan ($79/mo)
- No self-hosting, no open source

**Best for:** Teams that want a proven hosted feedback tool with strong integrations and are comfortable with usage-based pricing.

See how it compares: [Quackback vs Canny](/compare/quackback-vs-canny).

## 3. Featurebase

[Featurebase](/compare/quackback-vs-featurebase) bundles feedback boards, a changelog, a roadmap, a help center, and a support inbox into one product. It has a free plan (1 seat, limited features), which makes it one of the most accessible starting points for teams evaluating alternatives to Upvoty.

![Featurebase feedback board interface](/blog/best-upvoty-alternatives/featurebase.webp)

The AI agent, Fibi, auto-resolves customer questions using context from your help center, feedback posts, and past conversations. It can also submit feature requests on behalf of users. The catch: Fibi charges $0.49 per resolution on top of your plan cost, which adds up at volume. Duplicate detection and post merging are included on paid plans.

Featurebase is closed source and hosted only. Per-seat pricing ($29–99/seat/month on paid plans) means costs grow with your team size. User segmentation and advanced analytics are locked to higher tiers. But for small teams that want a hosted all-in-one tool with a free starting point, it covers significantly more ground than Upvoty.

**Key features:**
- Feedback boards with voting, status tracking, and user segmentation
- Changelog, public roadmap, and surveys (NPS, CSAT)
- Unified support inbox with live chat and email
- Fibi AI Agent for auto-resolving questions ($0.49/resolution)
- 12 integrations: Linear, Jira, GitHub, Slack, Intercom, Zendesk, and more

**Pricing:** Free (1 seat, limited). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- Free tier available with no time limit
- All-in-one: feedback, support inbox, help docs in one product
- Surveys (NPS, CSAT) included
- Growing fast with regular feature updates

**Cons:**
- Per-seat pricing adds up for larger teams
- AI resolutions are usage-based ($0.49 each)
- No self-hosting, no open source
- Post merging locked to paid tiers

**Best for:** Small teams wanting a free hosted option that combines feedback with a support inbox.

See how it compares: [Quackback vs Featurebase](/compare/quackback-vs-featurebase).

## 4. Frill

[Frill](/compare/quackback-vs-frill) is a focused feedback tool that covers boards, a roadmap, and a changelog. It's closer to Upvoty in scope than some other alternatives on this list — no support inbox, no AI, no complex prioritization framework — but it has a cleaner interface and more active product development.

![Frill feedback board interface](/blog/best-upvoty-alternatives/frill.webp)

Frill's Startup plan starts at $25/mo and covers 50 ideas, a changelog, and a public roadmap. The Business plan ($49/mo) unlocks unlimited ideas. The Growth plan ($149/mo) adds white labeling and advanced surveys. Unlike Upvoty's per-board model, Frill's plans are not limited by the number of boards.

All plans include unlimited teammates, SSO, webhooks, API access, and custom domains. Frill has fewer integrations than Canny or Featurebase — it connects to Slack, Zapier, and a handful of others, but lacks native Jira, Linear, and GitHub connections on lower tiers.

**Key features:**
- Feedback boards with voting, status updates, and custom fields
- Public roadmap with status-based categorization
- Changelog with subscriber notifications
- Custom domain and branding (Business plan)
- Integrations: Slack, Zapier, and more via API

**Pricing:** Startup at $25/mo (50 ideas). Business at $49/mo (unlimited). Growth at $149/mo. Enterprise from $349/mo.

**Pros:**
- Clean, focused interface
- Active product development with regular updates
- Changelog and roadmap included on the base plan
- No per-board pricing

**Cons:**
- No AI features
- Startup plan limited to 50 ideas
- Fewer native integrations than Canny or Featurebase
- No self-hosting, no open source

**Best for:** Teams that like Upvoty's simplicity but want a more actively developed hosted alternative.

See how it compares: [Quackback vs Frill](/compare/quackback-vs-frill).

## 5. Sleekplan

[Sleekplan](/compare/quackback-vs-sleekplan) takes a widget-first approach to feedback. Instead of sending users to a separate portal, Sleekplan embeds directly into your app as an in-app widget. Users can submit feedback, vote on ideas, read your changelog, and respond to satisfaction surveys without leaving your product.

![Sleekplan feedback widget interface](/blog/best-upvoty-alternatives/sleekplan.webp)

The built-in CSAT and NPS surveys are a genuine differentiator. Most feedback tools treat surveys as a separate concern. Sleekplan includes them natively, so you can measure satisfaction alongside feature requests in the same tool. The AI features ("Sleek Intelligence") on paid plans handle basic categorization and insights.

The free Indie plan is limited: one seat, no roadmap, no surveys, no AI. The Starter plan ($13/mo) unlocks the roadmap, surveys, and AI credits — making it the cheapest hosted option on this list with a meaningful feature set. The Business plan ($38/mo) adds post merging, user segmentation, and conditional surveys.

**Key features:**
- Feedback board with voting, status updates, and impact scoring
- Changelog with scheduled posting and subscriber notifications
- Roadmap (Starter plan and above)
- Built-in CSAT and NPS surveys
- Embeddable in-app widget, standalone portal, or iframe
- 12 integrations: Jira, Linear, Slack, Intercom, GitHub, Zapier, and more

**Pricing:** Free Indie plan (1 seat, limited). Starter at $13/mo. Business at $38/mo. Enterprise is custom.

**Pros:**
- In-app widget reduces friction for feedback submission
- Built-in NPS/CSAT surveys — unique in this category
- Cheapest paid plan with a real feature set ($13/mo)
- Free tier available

**Cons:**
- Free plan is very limited (no roadmap, no surveys, no AI)
- Widget-first means the standalone portal is less polished
- Post merging requires Business plan ($38/mo)
- No self-hosting, no open source

**Best for:** Teams prioritizing in-app feedback collection with built-in satisfaction surveys.

See how it compares: [Quackback vs Sleekplan](/compare/quackback-vs-sleekplan).

## 6. Nolt

[Nolt](/compare/quackback-vs-nolt) is the most stripped-down hosted option on this list. You get a clean feedback board where users submit and vote on ideas, plus a basic roadmap view and status notifications. There is no changelog, no AI, no support inbox, and no surveys.

![Nolt feedback board interface](/blog/best-upvoty-alternatives/nolt.webp)

The pricing is flat-rate: $29/mo for one board on the Essential plan (billed annually). No tracked-user billing, no per-seat charges. You know exactly what you will pay each month regardless of how many users submit or vote. This predictability is Nolt's primary advantage.

The limitation is scope. Nolt's public changelog has been quiet in recent releases, and core feature requests — a changelog, comment threading, bulk editing — remain unbuilt. Per-board pricing also means costs multiply if you manage feedback across multiple products or internal tools.

**Key features:**
- Feedback board with voting and custom statuses
- Roadmap view
- SSO, private boards, and password-protected boards
- Integrations: Slack, Discord, Jira, Linear, GitHub, Zapier (Pro plan)
- Custom domain and branding

**Pricing:** Essential at $29/mo for 1 board (annual). Pro at $69/mo for 5 boards. Enterprise is custom.

**Pros:**
- Flat-rate pricing — no per-user surprises
- Clean, focused interface with a fast setup
- SSO included on paid plans
- No tracked-user limits

**Cons:**
- No changelog, no AI features, no surveys
- Quiet recent release history
- Per-board pricing multiplies costs across multiple products
- No self-hosting, no open source

**Best for:** Small teams wanting a simple, predictably priced feedback board with no moving parts.

See how it compares: [Quackback vs Nolt](/compare/quackback-vs-nolt).

## 7. Fider

[Fider](/compare/quackback-vs-fider) is the open-source alternative on this list for teams that want to self-host without the full feature set of Quackback. It's licensed under AGPL-3.0, built with Go and React, and deploys with Docker. Users submit ideas, vote, and comment. Admins manage posts with tags, custom statuses, and filters.

![Fider feedback board interface](/blog/best-upvoty-alternatives/fider.webp)

Fider has been around since 2017 and has a stable, lightweight codebase. Go makes it resource-efficient — you can run it on a small VPS. The trade-off is scope. There is no changelog. No roadmap view. No AI features. Integrations are limited to webhook-based connections with Slack, Discord, and Microsoft Teams. No native Jira, Linear, or GitHub integration.

The project also moved to an open-core model in v0.33.0, putting content moderation and SEO indexing behind the paid cloud tier. For self-hosted deployments, those features are absent from the free version.

**Key features:**
- Feedback boards with voting, comments, and rich text editor
- Tags, filters, and customizable statuses
- REST API and webhooks
- Multi-language support (10+ languages)
- SSO with OAuth providers
- Self-hosted on any cloud or on-premise

**Pricing:** Free and open source for self-hosting. Cloud free tier limited to 250 feedback items. Cloud Pro at $49/month.

**Pros:**
- Mature, stable codebase (since 2017)
- Lightweight and resource-efficient
- Truly open source for self-hosting
- Simple to set up and operate

**Cons:**
- No changelog, no roadmap, no AI features
- Limited integrations (webhooks only, no native Jira or Linear)
- Open-core model means some features are paywalled on cloud
- No duplicate detection or post merging
- Development pace has slowed

**Best for:** Developers who want a bare-bones open-source voting board with minimal overhead and no SaaS dependency.

See how it compares: [Quackback vs Fider](/compare/quackback-vs-fider).

## Comparison table

| | Upvoty | Quackback | Canny | Featurebase | Frill | Sleekplan | Nolt | Fider |
|---|---|---|---|---|---|---|---|---|
| **Starting price** | $15/mo | Free | Free (25 users) | Free (1 seat) | $25/mo | Free (1 seat) | $29/mo | Free |
| **Open source** | No | Yes (AGPL-3.0) | No | No | No | No | No | Yes (AGPL-3.0) |
| **Self-hosting** | No | Yes | No | No | No | No | No | Yes |
| **Feedback boards** | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| **Roadmap** | Basic | Yes | Yes | Yes | Yes | Yes | Yes | No |
| **Changelog** | Basic | Yes | Yes | Yes | Yes | Yes | No | No |
| **AI features** | No | Yes (built in) | Autopilot | Fibi ($0.49/res) | No | Basic | No | No |
| **MCP server** | No | Yes | No | No | No | No | No | No |
| **Integrations** | Limited | 23 | 15+ | 10+ | Slack, Zapier | Slack, Zapier | Slack, Jira | Webhooks |
| **SSO** | No | OIDC | Business plan | Paid plans | All plans | Paid plans | Paid plans | OAuth |

## How to choose

Start with what Upvoty is missing for your team. That narrows the list fast.

**If you want open source and self-hosting:** Quackback is the only option that matches Upvoty's full feature set — boards, roadmap, changelog — and adds AI, an MCP server, and 25 integrations at no cost. Fider is the lighter alternative if you only need voting boards and want a minimal footprint.

**If you want a free hosted tier:** Featurebase and Sleekplan both offer free plans. Featurebase's free tier is more capable for feedback collection. Sleekplan's free plan is more limited but unlocks quickly at $13/mo.

**If you want the simplest possible tool:** Nolt is the closest to Upvoty in scope. Flat-rate pricing, no usage surprises, clean UI. It just has no changelog and no AI.

**If you want AI features:** Quackback (self-hosted, free), Canny (Autopilot on all paid plans), and Featurebase (Fibi AI agent, $0.49/resolution) are the only tools here with meaningful AI. Sleekplan has basic AI categorization on paid plans.

**If you want the deepest integrations:** Canny and Featurebase connect to the widest range of tools. Canny covers CRM (Salesforce, HubSpot) and PM tools (Jira, Linear, ClickUp). Featurebase covers support (Intercom, Zendesk) and includes a native support inbox.

For a broader look at the feedback tool landscape, see [Best Feature Voting Tools](/blog/best-feature-voting-tools), [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026), and [Open Source Feedback Tools](/blog/open-source-feedback-tools).

## Frequently asked questions

### What is the best free alternative to Upvoty?

[Quackback](https://quackback.io) is the most full-featured free alternative. It's open source (AGPL-3.0), self-hosted, and includes [feedback boards](/features/feedback), [voting](/features/voting), a [public roadmap](/features/roadmap), a [changelog](/features/changelog), 25 integrations, SSO/OIDC, and built-in AI features — all at no cost when self-hosted. Among hosted tools, Featurebase and Sleekplan both offer limited free tiers, though they restrict features until you upgrade to a paid plan.

### Is there an open-source alternative to Upvoty?

Yes. [Quackback](https://quackback.io) is the closest open-source equivalent, covering boards, voting, roadmap, changelog, integrations, and AI features that Upvoty does not offer. [Fider](/compare/quackback-vs-fider) is another open-source option for teams that need only a basic voting board. Both self-host with Docker. For a deeper comparison, see [Open Source Feedback Tools](/blog/open-source-feedback-tools).

### How does Upvoty pricing compare to its alternatives?

Upvoty starts at $15/mo for one board with no tracked-user limits. Among hosted alternatives, Sleekplan is cheaper at $13/mo. Frill starts at $25/mo and Nolt at $29/mo. Canny starts at $19/mo but uses tracked-user tiering that can increase costs as your user base grows. Featurebase and Sleekplan both have free tiers. Quackback is free to self-host — you pay only for your own infrastructure.

- [Best Self-Hosted Feedback Tools in 2026](https://quackback.io/blog/self-hosted-feedback-tools): A guide to self-hosted customer feedback tools. Compare deployment options, data ownership, and costs for teams that want to own their feedback infrastructure.

Published: 2026-02-26

Your customer feedback data is some of the most valuable information your company produces. It tells you what users want, what's broken, and where to invest next. Handing that data to a third-party SaaS vendor means trusting them with your product strategy, your users' identities, and your compliance posture. For a growing number of teams, that trade-off no longer makes sense.

Self-hosting your feedback tool gives you full control. Your data stays in your database, on your infrastructure, behind your firewall. You choose the region. You control the encryption. You decide who has access. For teams operating under GDPR, SOC 2, or HIPAA-adjacent requirements, this isn't a nice-to-have. It's a prerequisite.

There's also the cost argument. SaaS feedback tools charge per seat, per tracked user, or per feature tier. Those costs compound as your team and user base grow. Self-hosting converts that variable expense into a predictable infrastructure cost. A $20/month VPS can run a feedback platform that would cost $200+/month on a SaaS plan. And if the vendor raises prices or paywalls features you depend on, you have no leverage. With self-hosted software, you do.

![Self-hosted feedback tools — own your infrastructure](/blog/self-hosted-feedback-tools/hero.webp)

**TLDR:** The best self-hosted feedback tools: Quackback (most complete — AI, integrations, MCP server), Fider (simple voting boards), Astuto (lightweight), and ClearFlask (feature-rich but heavy). All deploy with Docker. Infrastructure costs range from $10-100/mo depending on scale.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

## Benefits of self-hosting your feedback platform

### Data sovereignty and compliance

When you self-host, feedback data never leaves your infrastructure. You control the database, the backups, the encryption keys, and the access logs. This matters for teams subject to GDPR (data must stay in the EU), SOC 2 (you need to demonstrate access controls), or any policy that requires knowing exactly where customer data lives. You can also run your feedback tool on air-gapped networks or private VPCs that have no public internet exposure.

### Predictable costs

SaaS feedback tools use variable pricing models that can change. Canny moved from per-admin to tiered tracked-user billing. Productboard charges $15–19/maker/month with AI limited to 250 credits per maker. UserVoice starts at $16,000/year. With self-hosting, your cost is the server. A small team can run a feedback platform on a $10-20/month VPS. A larger team might spend $50-100/month on a dedicated server or managed Kubernetes cluster. Either way, the cost doesn't scale with the number of users submitting feedback.

### No vendor lock-in

SaaS vendors control the data format, the export options, and the API. If they shut down, raise prices, or change the product direction, migration requires effort. Self-hosted open-source tools reduce this risk. You own the database directly. You can fork the codebase. Your data remains accessible regardless of the vendor's decisions.

### Full customization and extensibility

Self-hosted tools give you access to the source code. You can modify the UI, add custom integrations, change the data model, or extend the [API](/features/api) to fit your workflow. You're not limited to what the vendor decides to build. If you need a custom field, a unique notification flow, or an integration with an internal tool, you can build it yourself.

### Air-gapped and private network deployment

Some organizations cannot send data to external services. Government contractors, healthcare companies, financial institutions, and defense teams operate environments where internet-connected SaaS is prohibited by policy. Self-hosted feedback tools can run entirely within a private network. The process: pull Docker images on an internet-connected machine, transfer them to your air-gapped environment via approved media, and run the containers. The application needs no outbound connectivity after initial setup. Note that AI features requiring external LLM APIs will not work in fully air-gapped environments unless you run a local model.

## Self-hosted vs SaaS feedback tools

![Self-hosted vs SaaS feedback tool comparison diagram](/blog/self-hosted-feedback-tools/self-hosted-vs-saas.webp)

Both approaches have legitimate use cases. Here's how they compare across the dimensions that matter most.

| Factor | Self-Hosted | SaaS |
|---|---|---|
| **Data location** | Your servers, your region, your rules | Vendor's cloud (usually US) |
| **Cost model** | Fixed infrastructure cost ($10-100/mo) | Per-seat or per-user pricing ($29-999+/mo) |
| **Compliance** | Full control over access, encryption, audit logs | Dependent on vendor's certifications |
| **Customization** | Source code access, unlimited modifications | Limited to vendor's configuration options |
| **Maintenance** | You handle updates, backups, monitoring | Vendor handles everything |
| **Setup time** | 5-30 minutes with Docker | Instant sign-up |
| **Scaling** | You manage infrastructure scaling | Vendor scales automatically (and charges accordingly) |

The trade-off is clear: self-hosting gives you control and cost predictability at the expense of maintenance responsibility. SaaS gives you convenience at the expense of control and long-term cost certainty. Most teams that choose self-hosting do so because they've already been burned by a SaaS pricing change or because their compliance requirements make third-party hosting a non-starter.

## Best self-hosted feedback tools

### Quackback

**License:** AGPL-3.0
**Stack:** Docker Compose, PostgreSQL, Dragonfly (Redis-compatible)
**Best for:** Teams that want a complete feedback platform with AI, integrations, and agent access.

[Quackback](https://quackback.io) is an open-source feedback platform that covers the full workflow: [feature voting boards](/features/voting), a [public roadmap](/features/roadmap), [changelogs](/features/changelog), [feedback collection](/features/feedback), and built-in AI. It deploys with Docker Compose and uses PostgreSQL as its database.

What sets Quackback apart from other self-hosted options is the breadth of included features. You get [25 integrations](/integrations) (Slack, Linear, Jira, GitHub, Intercom, Zendesk, Salesforce, and more), [SSO/OIDC authentication](/features/sso), a [full REST API](/features/api), and an [MCP server](/features/mcp) that lets AI agents in Claude, Cursor, or Windsurf search, triage, and respond to feedback directly.

The AI features include duplicate detection, merge suggestions with reasoning, sentiment analysis, and post summaries. You configure an OpenAI-compatible provider (OpenAI, Azure OpenAI, Cloudflare AI Gateway, or any compatible provider). For air-gapped environments, you can point the AI configuration at a locally-hosted model.

Deployment takes under five minutes with Docker Compose. See the [quick start below](#quick-start-deploying-quackback-with-docker) or the [documentation](/docs) for the full deployment guide.

### Fider

**License:** AGPL-3.0
**Stack:** Go, React, PostgreSQL, Docker
**Best for:** Teams that need a simple voting board and nothing more.

[Fider](/compare/quackback-vs-fider) has been around since 2017 and covers the basics well. You get feedback boards with voting, comments, tags, status updates, and a REST API. The Go binary is efficient — 256MB of RAM is typically enough — and it deploys with a single Docker image plus PostgreSQL.

The limitation is scope. Fider has no changelog, no roadmap view, no AI features, and integrations are limited to webhooks for Slack, Discord, and Teams. There is no native connection to Jira, Linear, GitHub, or any issue tracker. The project moved to an open-core model in v0.33.0, which put content moderation and SEO indexing behind the paid cloud tier. If you need a no-frills voting board, Fider works. If you expect to need roadmaps, changelogs, or deeper integrations over time, you will outgrow it. See the [Quackback vs Fider comparison](/compare/quackback-vs-fider) for a feature-by-feature breakdown.

### Astuto

**License:** GPL-3.0
**Stack:** Ruby on Rails, PostgreSQL, Docker
**Best for:** Small teams that want a lightweight, self-hosted feedback board.

Astuto is built with Ruby on Rails and PostgreSQL. It provides feedback boards, voting, comments, and basic status tracking. A single Docker Compose file gets you running. Resource requirements are low — 512MB of RAM handles small to moderate deployments.

The feature set is limited to the core feedback loop. There are no integrations with issue trackers, no AI features, no SSO, and no roadmap view. The codebase is approachable for Rails developers who want to extend the platform. The community is small, so expect to troubleshoot independently. A good fit for internal tools, side projects, or teams that want the lightest possible self-hosted option.

### ClearFlask

**License:** AGPL-3.0
**Stack:** Java, React, Docker
**Best for:** Teams with Java expertise who want a self-hosted option.

ClearFlask offers feedback boards, voting, a roadmap, and a changelog. The feature set is broader than Fider or Astuto, but the setup is more involved. The Java (Spring Boot) backend requires a JVM — plan for at least 2GB of RAM for the application server alone. The deployment involves multiple services: the application server, a MySQL or DynamoDB database, and optionally an Elasticsearch instance for search.

Development has slowed in recent years. If you choose ClearFlask, plan to maintain it yourself. The documentation for self-hosting is sparse, and you will need familiarity with Java application servers to troubleshoot issues.

## Quick start: deploying Quackback with Docker

You can go from zero to a running feedback platform in under five minutes. All you need is Git, [Bun](https://bun.sh/), and Docker installed on your machine.

**1. Clone and set up**

```bash
git clone https://github.com/QuackbackIO/quackback.git
cd quackback
bun run setup    # Install deps, start Docker (Postgres + Dragonfly + MinIO), run migrations
```

The setup command starts a Docker Compose stack with PostgreSQL, Dragonfly (Redis-compatible), and MinIO (S3-compatible storage). It also runs database migrations automatically.

**2. Start the dev server**

```bash
bun run dev
```

**3. Open your browser**

Navigate to `http://localhost:3000`. Create your admin account, set up your first board, and start collecting feedback. You can configure your branding (logo, colors, custom domain), invite team members, and connect [integrations](/integrations) like Slack and Linear from the admin dashboard.

For production deployments, build the Docker image (`docker build -t quackback -f apps/web/Dockerfile .`) and deploy with your own PostgreSQL and Redis-compatible store. You can also deploy in one click on Railway. The [docs](/docs) cover production setup in detail, including environment variables for email, SSO, AI, and integrations.

## When SaaS makes more sense

Self-hosting is not the right choice for every team. If you don't have anyone comfortable with Docker, server administration, or basic infrastructure management, the maintenance burden will slow you down. Updates, backups, monitoring, and security patches all become your responsibility.

If your team is small and non-technical, a hosted solution removes that overhead entirely. Tools like [Canny](/compare/quackback-vs-canny) or [Productboard](/compare/quackback-vs-productboard) handle hosting, updates, and scaling for you. You pay more per month, but you pay nothing in engineering time.

There's also the question of time-to-value. A SaaS tool is ready the moment you sign up. Self-hosting requires setup, even if it's only five minutes. For a team that needs to collect feedback today and doesn't have infrastructure preferences, SaaS is the faster path.

The good news is that this isn't a permanent decision. If you start with a SaaS tool and later decide you want more control, open-source tools like Quackback support data import. And if you start self-hosted and later decide you'd rather not own the ops — the backups, updates, patching, and uptime — Quackback Cloud takes all of that off your plate, and your data migrates across without loss.

For a broader comparison of feedback tools across both self-hosted and SaaS categories, see the [full comparison of feedback tools](/blog/best-customer-feedback-tools-2026). If you're specifically interested in open-source options, see [open-source feedback tools](/blog/open-source-feedback-tools).

## Frequently asked questions

### What does self-hosted mean for a feedback tool?

Self-hosted means the software runs on your own servers instead of the vendor's cloud. You download the application (usually as a Docker image), deploy it to your infrastructure, and connect it to your own database. All data stays on your machines. You control updates, backups, access, and security. The vendor provides the software, but you operate it. This is the opposite of SaaS, where the vendor runs everything and you access it through a browser.

### How much does it cost to self-host a feedback tool?

The software itself is free if you use an open-source tool like Quackback or Fider. Your costs are infrastructure: a server to run the application and a database. A small team can run Quackback on a $10-20/month VPS (DigitalOcean, Hetzner, or similar). Larger teams with higher traffic might spend $50-100/month on a more capable server or managed database. Compare that to SaaS tools that charge $29-999+/month depending on your team size and feature needs. The self-hosted cost stays relatively flat regardless of how many users submit feedback.

### Can I migrate from a SaaS feedback tool to self-hosted?

Yes, though the ease of migration depends on the tools involved. Most SaaS feedback tools offer some form of data export (CSV, API access, or a migration tool). Quackback supports importing data from other platforms, so you can bring your existing feedback, votes, and user data with you. The key is to export your data before canceling your SaaS subscription. Check your current tool's export capabilities and the self-hosted tool's import documentation before starting. Plan for a transition period where both systems run in parallel so you can verify the migration is complete before cutting over.

### Is self-hosting secure?

Self-hosting can be more secure than SaaS, but only if you manage it properly. You control the firewall rules, encryption, access policies, and update schedule. That means no one else can access your data, but it also means you're responsible for applying security patches, configuring TLS, and maintaining backups. Use strong database passwords, keep your Docker images updated, run the application behind a reverse proxy with SSL, and restrict network access to the ports you need. Quackback supports [SSO/OIDC](/features/sso) for authentication, and the [API](/features/api) uses token-based access control. The [documentation](/docs) includes a production security checklist.

- [Best Open Source Feedback Tools in 2026](https://quackback.io/blog/open-source-feedback-tools): The best open source feedback tools in 2026 compared. Features, deployment, and trade-offs for Quackback, Fider, LogChimp, Astuto, and ClearFlask.

Published: 2026-02-24

Most feedback tools are closed-source SaaS products. Your data lives on the vendor's servers, you pay per seat or per tracked user, and the vendor controls pricing. Canny moved from per-admin to tiered tracked-user billing in 2025. Productboard charges $15–19 per maker per month with AI limited to 250 credits per maker. UserVoice starts at $16,000 per year. With closed-source tools, pricing and feature availability can change at the vendor's discretion.

Open source feedback tools remove that risk. You get data ownership: your feedback lives in your database, on your infrastructure, under your control. No vendor lock-in: if the project's direction changes, you fork it. Predictable costs: self-hosting means you pay for compute, not per-seat licenses that scale with your team. And auditability: you can read every line of code, review every dependency, and verify exactly what the software does with your data.

The open source landscape for feedback tools has matured. There are now several viable options, each with different trade-offs in features, tech stack, and community activity. Here are the five most notable open source feedback tools in 2026, compared side by side.

![Open source feedback tools — code meets customer feedback](/blog/open-source-feedback-tools/hero.webp)

**TLDR:** The best open source feedback tools in 2026: Quackback (most complete — boards, roadmap, changelog, AI, 25 integrations), Fider (basic but proven), ClearFlask (feature-rich but complex), plus LogChimp and Astuto. All self-hostable with Docker.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

## Quackback

[Quackback](https://quackback.io) is an open source customer feedback platform licensed under AGPL-3.0. It covers the full feedback workflow: [feature voting boards](/features/voting), a [public roadmap](/features/roadmap), [changelogs](/features/changelog), [SSO/OIDC](/features/sso), a [REST API](/features/api), and [25 integrations](/integrations) including Slack, Linear, Jira, GitHub, Intercom, Zendesk, and Salesforce.

![Screenshot of Quackback feedback board](/blog/open-source-feedback-tools/quackback.webp)

What separates Quackback from other open source options is scope. Most open source feedback tools handle the basics: collect votes, show a board. Quackback matches the feature set of commercial tools like Canny and UserVoice, then adds capabilities they don't offer.

The AI features are built in. Duplicate detection catches redundant posts before they pile up. Merge suggestions identify related requests with reasoning your team can accept or dismiss in one click. Sentiment analysis runs on every post automatically. Summaries pull out key quotes and next steps. The AI features work with OpenAI-compatible providers (OpenAI, Azure OpenAI, Cloudflare AI Gateway, or any compatible provider).

The [MCP server](/features/mcp) is unique among feedback tools, open source or otherwise. It implements the Model Context Protocol, the same standard that Claude, Cursor, and Windsurf support. Connect an AI agent and it gets full access to your feedback data: search posts, triage requests, write responses, create changelog entries, and merge duplicates. Every action is attributed and auditable. This means your existing AI agents can participate in your feedback loop without custom integrations.

Deploy with Docker on any infrastructure. Your data stays in your PostgreSQL database. Self-hosting has no license fees. You can also see how Quackback stacks up against specific tools: [compared to Canny](/compare/quackback-vs-canny) and [compared to Fider](/compare/quackback-vs-fider).

**Key features:**
- [Feature voting boards](/features/voting) with status tracking, nested comments, and official responses
- [Public roadmap](/features/roadmap) with planned, in progress, and shipped views
- [Changelog](/features/changelog) with automatic voter notifications
- AI: duplicate detection, merge suggestions, sentiment analysis, post summaries
- [MCP server](/features/mcp) for AI agents (search, triage, respond, create, merge)
- [25 integrations](/integrations): Slack, Linear, Jira, GitHub, Intercom, Zendesk, Salesforce, and more
- [SSO/OIDC](/features/sso), webhooks, [full REST API](/features/api)
- Custom branding with themes, custom CSS, and your own domain
- User segments and admin inbox with bulk actions

**License:** AGPL-3.0

**Tech stack:** TypeScript, PostgreSQL, Docker

**Deployment:** Docker Compose or one-click deploy on Railway. See the [self-hosting docs](/docs) for setup instructions.

**Pros:**
- Full-featured: covers boards, roadmap, changelog, integrations, and AI in a single product
- AI features built in, working with OpenAI-compatible providers
- MCP server enables AI agent access, a capability no other feedback tool offers
- Free to self-host with full data ownership
- Managed Cloud takes the ops off your plate — backups, updates, and uptime handled
- Active development with frequent releases

**Cons:**
- Self-hosting requires running your own infrastructure (or a one-click Railway deploy)
- Newer project compared to some alternatives on this list

## Fider

[Fider](/compare/quackback-vs-fider) is an open source feedback tool licensed under AGPL-3.0. It's built with Go and React, backed by PostgreSQL, and deploys with Docker. Fider handles the core feedback collection workflow: users submit ideas, vote on them, and leave comments. Admins manage posts with tags, custom statuses, and filters.

![Screenshot of Fider feedback board](/blog/open-source-feedback-tools/fider.webp)

Fider has been around since 2017 and has a stable codebase. If you need a straightforward voting board and nothing more, it does the job well. The interface is clean, the setup is simple, and the Go binary runs with minimal overhead — 256MB of RAM is typically sufficient.

Where Fider falls short is everything beyond the basics. There's no changelog. No roadmap view. No AI features. Integrations are limited to webhook-based connections with Slack, Discord, and Microsoft Teams. There's no native Jira, Linear, or GitHub integration. The project moved to an open-core model in v0.33.0, which put content moderation and SEO indexing behind the paid cloud tier.

**Key features:**
- Feedback boards with voting, comments, and rich text editor
- Tags, filters, and customizable statuses
- REST API and webhooks (4 event types)
- Multi-language support (10+ languages, including RTL)
- SSO with OAuth providers
- Markdown support in posts and comments

**License:** AGPL-3.0

**Tech stack:** Go, React, PostgreSQL

**Deployment:** Docker on any cloud provider or on-premises. Also available as a managed cloud service.

**Pros:**
- Mature and stable codebase (since 2017)
- Lightweight and resource-efficient thanks to Go
- Simple to set up and operate
- Multi-language support included (10+ languages)

**Cons:**
- No changelog, no roadmap view, no AI features
- Limited integrations (webhooks only, no native issue tracker connections)
- Open-core model means some features are paywalled on the cloud version
- Development pace has slowed in recent years
- No duplicate detection, no post merging

## LogChimp

**LogChimp** is an open source feedback board and roadmap tool. It's built with Node.js and Vue.js. The project aims to give teams a simple way to collect feature requests and display a public roadmap.

![Screenshot of LogChimp feedback board](/blog/open-source-feedback-tools/logchimp.webp)

LogChimp covers the essentials: users can submit feedback, vote on posts, and view a roadmap. The interface is minimal and clean. Setup requires Node.js 14+ and a PostgreSQL database. There is no official Docker image, so you run it directly or build your own container.

The concern with LogChimp in 2026 is development activity. Commits have become infrequent. The community is small, and the feature set has not expanded significantly. Open issues and pull requests on GitHub suggest limited maintainer bandwidth. If you adopt LogChimp, you should be comfortable maintaining a fork if the project stalls further.

**Key features:**
- Feedback boards with voting
- Public roadmap view
- Post statuses and categorization
- REST API
- Email notifications

**License:** MIT

**Tech stack:** Node.js, Vue.js, PostgreSQL

**Deployment:** Manual Node.js deployment or Docker.

**Pros:**
- Simple and lightweight
- MIT license (permissive, no copyleft restrictions)
- Clean interface

**Cons:**
- Development has slowed significantly
- Small community with limited support
- No AI features, no changelog, no SSO
- Limited integrations
- Documentation is sparse
- No duplicate detection or post merging

## Astuto

**Astuto** is an open source feedback tool licensed under GPL-3.0. It's built with Ruby on Rails and React, and it deploys with Docker. Astuto provides feedback boards where users can submit ideas, vote, and comment.

![Screenshot of Astuto feedback board](/blog/open-source-feedback-tools/astuto.webp)

Astuto is deliberately minimal. The scope is limited to boards, voting, comments, statuses, and basic customization. It runs on a single Rails process with PostgreSQL, so resource requirements are low — 512MB of RAM is sufficient for small deployments.

The trade-off is feature ceiling. There is no public roadmap view, no changelog, no AI features, no integrations with issue trackers like Jira or Linear, and no SSO. If you start with Astuto and later need these capabilities, you will need to migrate to a different tool.

**Key features:**
- Feedback boards with voting and comments
- Custom statuses and board categories
- Custom branding (logo, colors)
- Multi-language support
- Webhooks for basic automation
- User roles and moderation

**License:** GPL-3.0

**Tech stack:** Ruby on Rails, React, PostgreSQL

**Deployment:** Docker Compose. Official Docker images available.

**Pros:**
- Genuinely simple to deploy and run
- Lightweight resource requirements
- Clean, focused interface
- Active maintainer responsive to issues

**Cons:**
- No roadmap view, no changelog
- No AI features
- No integrations with issue trackers (Jira, Linear, GitHub)
- No SSO/OIDC
- Limited to basic feedback collection
- Small community

## ClearFlask

**ClearFlask** is an open source feedback platform licensed under AGPL-3.0. It was originally a commercial SaaS product that later released its source code. The platform includes feature voting, a public roadmap, a changelog, and user segmentation.

![Screenshot of ClearFlask feedback board](/blog/open-source-feedback-tools/clearflask.webp)

ClearFlask is the most feature-rich option on this list after Quackback. It supports idea boards with voting, a roadmap with multiple views, a changelog with subscriber notifications, and basic analytics. The platform also includes features like credit-based voting (where users have a limited number of votes to distribute) and single sign-on.

The trade-off is operational complexity. ClearFlask is built with Java (Spring Boot) and React. The JVM requires at least 2GB of RAM for the application server alone. Setup involves multiple services (application server, database, search index), and the documentation for self-hosting assumes familiarity with Java ecosystems. Development has slowed since the open source release, and the community is small.

**Key features:**
- Feature voting boards with multiple vote types (including credit-based voting)
- Public roadmap with timeline and column views
- Changelog with subscriber notifications
- User segmentation and analytics
- SSO support
- REST API
- White-labeling and custom domains

**License:** AGPL-3.0

**Tech stack:** Java (Spring Boot), React, MySQL/DynamoDB

**Deployment:** Docker, though setup is more involved than other tools on this list. Requires multiple services.

**Pros:**
- Feature-rich for an open source tool (roadmap, changelog, analytics, SSO)
- Multiple voting mechanisms including credit-based voting
- White-labeling support
- Originally battle-tested as a commercial product

**Cons:**
- Complex setup compared to alternatives
- Heavier infrastructure requirements (Java, multiple services)
- Development has slowed since going open source
- Small community and limited documentation for self-hosting
- No AI features, no MCP server
- No native integrations with issue trackers

## Comparison table

| Feature | Quackback | Fider | LogChimp | Astuto | ClearFlask |
|---|---|---|---|---|---|
| **License** | AGPL-3.0 | AGPL-3.0 | MIT | GPL-3.0 | AGPL-3.0 |
| **Feedback Boards** | Yes | Yes | Yes | Yes | Yes |
| **Public Roadmap** | Yes | No | Yes | No | Yes |
| **Changelog** | Yes | No | No | No | Yes |
| **AI Features** | Yes (duplicate detection, sentiment, merge suggestions, summaries) | No | No | No | No |
| **MCP Server** | Yes | No | No | No | No |
| **SSO** | Yes (OIDC/SAML) | Yes (OAuth) | No | No | Yes |
| **Integrations** | 23 (Slack, Jira, Linear, GitHub, Intercom, Zendesk, Salesforce, etc.) | 3 (Slack, Discord, Teams via webhooks) | None | Webhooks only | None |
| **Docker Deploy** | Yes | Yes | Yes | Yes | Yes (complex) |
| **Active Development** | Yes | Slowed | Minimal | Moderate | Slowed |

## How to choose

Start with what you actually need today and what you'll need in six months.

**If you just need a voting board:** Fider or Astuto will get you running in minutes. Fider is more mature and has multi-language support. Astuto is simpler and lighter. Both handle the basics well. The limitation is that "the basics" is all they handle. When you need a roadmap, changelog, or integrations, you'll hit a wall.

**If you need the full feedback workflow:** Quackback and ClearFlask are the two options that cover boards, roadmap, and changelog. Quackback adds 25 integrations, AI features, and an MCP server. ClearFlask offers credit-based voting and analytics but has a more complex setup and slower recent development. Evaluate both against your specific requirements.

**If you want the simplest possible setup:** Astuto is the lightest option. A single Docker Compose command gets you a working feedback board. Good for side projects, internal tools, or early-stage products where you just need a place for users to submit ideas.

**If permissive licensing matters:** LogChimp is the only MIT-licensed option. The others use copyleft licenses (AGPL-3.0 or GPL-3.0). If your organization has restrictions on copyleft software, LogChimp may be the only option, though the slow development pace is a real risk.

**If AI and automation matter:** Quackback is the only open source feedback tool with built-in AI. Duplicate detection, sentiment analysis, merge suggestions, and post summaries are included. The MCP server means your AI agents in Claude, Cursor, or Windsurf can search, triage, and respond to feedback without custom code. No other open source tool on this list offers AI features of any kind.

**If you're migrating from a commercial tool:** If you're moving from Canny, UserVoice, or another paid platform, evaluate whether the open source option covers the features you actually use. Quackback and ClearFlask are the most feature-complete options on this list (boards, roadmap, changelog). For a broader comparison that includes commercial tools, see [feedback tools compared](/blog/best-customer-feedback-tools-2026).

## Frequently asked questions

### What is an open source feedback tool?

An open source feedback tool is software for collecting and managing customer feedback where the source code is publicly available. You can read, modify, and redistribute the code under the terms of its license. This means you can self-host the tool on your own infrastructure, audit what it does with your data, and customize it for your specific needs. The alternative is closed-source SaaS tools like Canny or UserVoice, where you rely on the vendor to host, maintain, and control the software.

### Can I self-host these tools?

Yes. All five tools on this list support self-hosting with Docker. The complexity varies. Astuto and Fider are the simplest to deploy: a single Docker Compose file with a PostgreSQL database. Quackback is similarly straightforward with Docker Compose or a one-click Railway deploy. Check the [Quackback self-hosting docs](/docs) for a step-by-step guide. LogChimp requires a Node.js setup. ClearFlask has the most involved deployment, requiring multiple services and familiarity with Java infrastructure.

### Are open source feedback tools really free?

The software itself is free. You don't pay license fees, per-seat charges, or subscription costs. You do pay for the infrastructure to run it: a server, a database, and whatever compute resources the tool needs. For most of these tools, a small VPS ($5-20/month) is sufficient. That's a fixed, predictable cost, unlike SaaS pricing that scales with users or seats. Some tools (Fider and Quackback) also offer managed cloud versions if you'd rather not run your own infrastructure.

### How do open source feedback tools compare to Canny or UserVoice?

The core workflow is the same: collect feature requests, let users vote, show a roadmap, publish a changelog. The difference is in control and cost. Canny uses tiered pricing with tracked user limits and auto-upgrades you if you exceed your tier. UserVoice starts at $16,000/year. Neither offers self-hosting or source code access. Open source tools like Quackback give you the same features with full data ownership and the ability to audit and modify the code. The trade-off historically was that open source tools had fewer features. That gap has closed. Quackback now offers [feature voting](/features/voting), [roadmaps](/features/roadmap), [changelogs](/features/changelog), [25 integrations](/integrations), and [AI features](/features/feedback) that match or exceed what commercial tools provide.

### What is the best open source alternative to Canny?

Quackback is the closest open source equivalent to Canny. It covers the same core features: [feature voting boards](/features/voting), [public roadmap](/features/roadmap), [changelog](/features/changelog), [SSO](/features/sso), and integrations with tools like Slack, Jira, Linear, and GitHub. It also includes AI features (duplicate detection, sentiment analysis, merge suggestions) and an [MCP server](/features/mcp) for AI agent access, neither of which Canny offers. Self-hosting is free. For a detailed comparison, see [Quackback vs Canny](/compare/quackback-vs-canny).

- [Aha Pricing in 2026: Plans, Per-User Costs, and Alternatives](https://quackback.io/blog/aha-pricing): Aha pricing breakdown in 2026. Aha Roadmaps and Aha Ideas plans, per-user costs, bundled pricing, and simpler alternatives for product teams.

Published: 2026-02-21

**Aha** is a product management platform suite that covers strategy, roadmapping, idea management, and delivery across separate applications. It has been around since 2013 and serves thousands of product teams across enterprise, mid-market, and growth-stage companies. Unlike most product tools, Aha does not sell a single product — it sells a suite of separate applications, each addressing a different part of the product management workflow.

![Aha pricing plans and cost breakdown](/blog/aha-pricing/hero.webp)

> Aha Roadmaps starts at $59/user/mo and Aha Ideas starts at $39/user/mo, both billed annually. Bundles combine the two at a reduced rate, and the full suite is enterprise-priced. If you need feedback collection and a public roadmap without the complete PM suite, alternatives like [Quackback](https://quackback.io) start free.
>
> *Pricing last verified February 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

## Aha product lineup

Aha sells four distinct products. You can buy each separately or combine them in a bundle.

**Aha Roadmaps** is the flagship product. It covers product strategy, goals, feature planning, and visual roadmaps. It is the product most people mean when they say "Aha."

**Aha Ideas** is the feedback and idea management product. It provides a public-facing ideas portal where customers submit and vote on requests. Product teams use it to capture, organize, and link feedback to features in Roadmaps.

**Aha Develop** is aimed at engineering teams. It covers agile sprint planning, backlog management, and workflow tracking. It integrates with Aha Roadmaps to close the loop between strategy and delivery.

**Aha Knowledge** is a product documentation and wiki tool. Teams use it to create product specs, internal docs, and team wikis alongside their roadmap work.

Each product has its own pricing tiers. If you want both strategy and feedback management, you need Aha Roadmaps and Aha Ideas — either separately or as a bundle.

## Aha Roadmaps pricing

Aha Roadmaps has three tiers. All prices are per user per month, billed annually.

| Plan | Price | What's included |
|------|-------|-----------------|
| **Starter** | $59/user/mo | Roadmaps, strategy, goals, features, releases, basic integrations (Jira, GitHub, Azure DevOps), standard reports |
| **Premium** | $89/user/mo | Everything in Starter plus capacity planning, advanced analytics, custom roadmap views, competitor tracking, unlimited workspaces |
| **Enterprise** | $149/user/mo | Everything in Premium plus SSO/SAML, audit logs, custom roles and permissions, dedicated customer success manager, SLA |

The Starter plan covers the core roadmapping workflow. You get feature planning, release management, goal tracking, and connections to the most common development tools. It is enough for a single product team running a straightforward process.

Premium adds capacity planning and deeper analytics — features that matter when you are managing multiple product lines or presenting to leadership. Enterprise is aimed at large organizations that need compliance features and managed onboarding.

Note that SSO/SAML is locked to the Enterprise tier. Any organization with a security policy requiring SSO must budget for $149/user/mo.

## Aha Ideas pricing

Aha Ideas has two tiers. Again, all prices are per user per month, billed annually.

| Plan | Price | What's included |
|------|-------|-----------------|
| **Essentials** | $39/user/mo | Ideas portal, voting, comments, idea categorization, basic reporting, link to Aha Roadmaps |
| **Advanced** | $59/user/mo | Everything in Essentials plus custom portal branding, advanced analytics, empathy sessions, in-app surveys, AI-powered idea summarization |

The Essentials plan covers the standard feedback portal workflow: customers submit ideas, vote, and comment; your team reviews and links requests to roadmap features.

Advanced adds the features that matter for teams who want to go deeper with customer engagement — custom branding, in-app surveys, and AI summarization that surfaces patterns across large volumes of ideas.

Aha Ideas is not a standalone changelog tool. It does not include a public changelog natively. If you need that, you would pair Ideas with Roadmaps or manage it separately.

## Bundle pricing

Aha offers bundled pricing when you combine Roadmaps and Ideas. The bundle is available at each tier level and offers a discount compared to purchasing both products separately.

Aha does not publish exact bundle prices publicly — they vary based on team size and configuration. The general structure works as follows:

- **Starter bundle** (Roadmaps Starter + Ideas Essentials): discount off the combined list price
- **Premium bundle** (Roadmaps Premium + Ideas Advanced): discount off the combined list price
- **Enterprise bundle**: custom pricing through sales

To get exact bundle pricing for your team size, you need to contact Aha sales or start a trial and request a quote. Annual billing is required for all bundles.

## Cost at scale

Here is what Aha costs annually at different team sizes, using published list prices for the most common plan combinations.

| Users | Roadmaps Starter ($59) | Roadmaps Premium ($89) | Roadmaps + Ideas Essentials ($59 + $39) | Roadmaps + Ideas Advanced ($89 + $59) |
|-------|------------------------|------------------------|-----------------------------------------|---------------------------------------|
| **5** | $3,540/yr | $5,340/yr | $5,940/yr | $8,880/yr |
| **10** | $7,080/yr | $10,680/yr | $11,880/yr | $17,760/yr |
| **25** | $17,700/yr | $26,700/yr | $29,700/yr | $44,400/yr |
| **50** | $35,400/yr | $53,400/yr | $59,400/yr | $88,800/yr |

These figures use list pricing before any bundle discounts. Your actual cost with a bundle may be lower. At 25 users on Roadmaps Premium plus Ideas Advanced, the undiscounted list total is $44,400/yr. Even with a 20% bundle discount, that is $35,500/yr — a significant annual commitment.

Enterprise pricing adds further cost above these figures for SSO, audit logs, dedicated support, and custom roles.

## Hidden costs

The sticker price is only part of the picture. Several factors add to your total cost of ownership with Aha.

**Annual commitments lock you in.** Aha offers both monthly and annual billing, with annual paid upfront for a discount (roughly 20% versus monthly). If you commit annually and your team shrinks or your needs change, you still pay through the end of the contract.

**Separate products mean separate costs.** Roadmaps and Ideas are distinct products with separate pricing. If you want both — which most teams eventually do — you pay for both. The bundle discounts help, but the base cost is high before any discount applies.

**Feature gates increase at each tier.** Capacity planning, advanced analytics, and custom roadmap views require Premium. SSO requires Enterprise. In-app surveys and AI summarization require Ideas Advanced. Moving up a tier for a single feature means paying the full tier increase across every user.

**Setup and onboarding time.** Aha is a deep product with a significant learning curve. Configuring strategy hierarchies, customizing workflows, setting up integrations, and training your team can take weeks. Aha offers professional services for larger implementations — an additional cost on top of the subscription.

**Integrations are available on Starter** for the core development tools (Jira, GitHub, Azure DevOps), but some CRM and data integrations are limited to higher tiers or require API access that comes with Premium and above.

**No self-hosting option.** Aha is hosted SaaS only. Your product data, strategy documents, and customer feedback live on Aha's infrastructure. Teams with data residency requirements or a preference for on-premises tools have no alternative within the Aha ecosystem.

![Annual cost comparison across Aha pricing tiers and plan combinations at 5, 10, 25, and 50 users](/blog/aha-pricing/aha-cost-comparison.webp)

## When Aha makes sense

Aha is built for large product organizations. It is a reasonable fit when:

- You manage multiple product lines and need a unified strategy layer across all of them.
- Your product organization has 10 or more people across product, design, and engineering who need coordinated planning.
- You need a structured approach to strategy: goals cascading to initiatives cascading to features.
- You have compliance or security requirements (SOC 2, SSO, audit logs) that simpler tools do not meet.
- You are replacing spreadsheets and disconnected tools across a large team and need a single source of truth.

Aha is not a good fit for small teams or early-stage companies. The pricing starts at $59/user/mo before you add Ideas. At five people, that is $3,540/yr just for Roadmaps Starter. The complexity and cost make sense for organizations that have outgrown simpler tools — not for teams still finding product-market fit.

## Simpler alternatives

If your primary need is collecting customer feedback and sharing a roadmap, several tools cover that workflow at a fraction of Aha's cost.

| Tool | Starting price | Feedback portal | Roadmap | Changelog | Open source |
|------|---------------|-----------------|---------|-----------|-------------|
| **[Quackback](https://quackback.io)** | Free self-hosted · $29/mo Cloud | Yes | Yes | Yes | Yes (AGPL-3.0) |
| **[Canny](/blog/canny-pricing)** | Free (25 tracked users), $19/mo paid | Yes | Yes | Yes | No |
| **Productboard** | $19/maker/mo | Yes | Yes (advanced) | No | No |
| **Featurebase** | Free (1 seat), $29/seat/mo paid | Yes | Yes | Yes | No |

**Quackback** is free, open source, and self-hosted, with a managed [Quackback Cloud](/pricing) from $29/mo on annual billing if you would rather not run it yourself. It covers [feedback boards](/features/feedback), [voting](/features/voting), a public [roadmap](/features/roadmap), [changelogs](/features/changelog), and 25 integrations with no per-user pricing when self-hosted. AI features and SSO/OIDC are included free on every self-hosted installation. On Cloud, Quinn is included on paid plans, and SSO is self-serve on Enterprise. An [MCP server](/features/mcp) lets you query and triage feedback directly from your AI tools. For teams that want feedback and roadmap functionality without enterprise pricing, it is worth a look. See the [full comparison of Quackback vs Aha](/compare/quackback-vs-aha).

**Canny** offers a polished hosted experience with a free plan (25 tracked users) and paid plans starting at $19/mo. It covers the standard feedback-to-roadmap workflow. See [Canny pricing](/blog/canny-pricing) for a full breakdown.

**Productboard** sits closer to Aha in terms of positioning — it has a structured planning layer and per-maker pricing. The Spark plan starts at $19/maker/mo (monthly) or $15/maker/mo (annual). See [Productboard pricing](/blog/productboard-pricing) for a full breakdown.

**Featurebase** offers a free plan with one seat and bundles feedback, roadmap, and changelog in a single tool. Paid plans start at $29/seat/mo. It is a hosted-only product.

For a broader look at how these tools compare on pricing, see [Feedback Tool Pricing Comparison](/blog/feedback-tool-pricing-comparison). For a full roundup, see [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026) and [Product Management Tools](/blog/product-management-tools).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How much does Aha cost per user?

Aha Roadmaps costs $59, $89, or $149/user/mo (Starter, Premium, Enterprise). Aha Ideas costs $39 or $59/user/mo (Essentials, Advanced). Aha offers both monthly and annual billing; annual is paid upfront for a discount. Roadmaps and Ideas are separate products, so you pay for each unless you buy a discounted bundle.

### Does Aha have a free plan or free trial?

Aha does not offer a free plan; all products require a paid annual subscription. Aha does offer a 30-day free trial for Roadmaps and Ideas. If you need a free ongoing option, [Quackback](https://quackback.io) is open source and free to self-host with no user limits.

### Is Aha worth the price for small teams?

For most small teams, Aha is overpriced relative to the value delivered. A five-person team pays $3,540/yr for Roadmaps Starter alone, before adding Ideas. Aha is built for structured, multi-product organizations. Smaller teams are better served by [Quackback](/compare/quackback-vs-aha) (free, self-hosted) or [Canny](/blog/canny-pricing) ($19/mo).

### Does Aha offer monthly billing?

Yes. Aha's pricing page has a monthly/annual toggle, so you can pay month-to-month on Aha Roadmaps and Aha Ideas. Annual billing is paid upfront and discounted by roughly 20% versus monthly, but you commit for the full term and pay through the end of the contract even if your team size changes.

### What is the difference between Aha Roadmaps and Aha Ideas?

Aha Roadmaps handles product strategy, goals, feature planning, and visual roadmaps. Aha Ideas handles feedback collection through a public ideas portal where customers submit and vote on requests. They are priced separately; teams that want both buy each product or a discounted bundle.

- [Best Product Management Tools in 2026](https://quackback.io/blog/product-management-tools): A guide to the best product management tools in 2026. From feedback collection to roadmapping to analytics — tools for every stage of the product lifecycle.

Published: 2026-02-19

Product management tools span a wide range. Some help you collect feature requests. Others help you plan what to build, track the work, or measure what happened after you shipped. No single tool covers the entire product lifecycle, and most teams use three or four in combination.

*Pricing last verified March 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

![Product management tool stack overview](/blog/product-management-tools/hero.webp)

This guide covers the best product management tools in 2026, organized by what they do. Whether you are building your first tool stack or replacing something that no longer fits, this should help you narrow the field.

![Product management tool stack showing four categories: feedback, roadmapping, project management, and analytics](/blog/product-management-tools/pm-tool-stack.webp)

## Feedback and feature request tools

Every product decision starts with input. Feature request tools give your users a place to tell you what they need and vote on what matters most. They replace the scattered Slack threads, support tickets, and spreadsheets that most teams start with.

### Quackback

[Quackback](https://quackback.io) is an open-source feedback platform licensed under AGPL-3.0. It covers [feature voting boards](/features/voting), a [public roadmap](/features/roadmap), a [changelog](/features/changelog), and 25 integrations with tools like Slack, Linear, Jira, GitHub, Intercom, Zendesk, and Salesforce.

The AI layer handles duplicate detection, merge suggestions, sentiment analysis, and post summaries. The [MCP server](/features/mcp) lets AI agents in Claude, Cursor, and Windsurf search your feedback, triage requests, write responses, and create changelog entries. Every agent action is attributed and auditable.

Self-host with Docker or deploy on Railway. Your data stays in your PostgreSQL database.

**Pricing:** Free and open source to self-host. Or let us run it: Quackback Cloud is fully managed (backups, updates, and uptime handled) from $29/mo on annual billing, with a 14-day free trial, no card required.

For deeper comparisons, see [Quackback vs Canny](/compare/quackback-vs-canny), [Quackback vs Productboard](/compare/quackback-vs-productboard), and [Quackback vs UserVoice](/compare/quackback-vs-uservoice). You can also read our guides to the [best feature request tools](/blog/best-feature-request-tools) and the [best customer feedback tools in 2026](/blog/best-customer-feedback-tools-2026).

### Canny

Canny is a hosted feedback platform with voting boards, roadmaps, changelogs, and AI-powered feedback discovery from support conversations. Their AI suite, Autopilot, identifies feature requests in Intercom, Zendesk, Help Scout, and Gong conversations and links them to your board automatically.

In May 2025, Canny moved from per-admin billing to tiered pricing based on tracked users. A tracked user is anyone with a post, vote, or comment. Canny offers a free plan (25 tracked users) and paid tiers starting with Core at $19/mo. Costs increase as you cross tracked user thresholds, with auto-upgrades to the next tier.

**Pricing:** Free plan (25 tracked users). Core from $19/mo. Pro from $79/mo. Business is custom pricing.

### Productboard

Productboard is a product management platform with feedback capabilities. It connects customer insights to product strategy through opportunity scoring, prioritization matrices, and driver-based roadmaps. You can capture feedback from Intercom, Zendesk, Salesforce, email, and Slack, then score features against custom drivers like revenue impact, user reach, and effort.

The trade-off is cost and complexity. Productboard revamped its pricing around a single Spark plan at $15/maker/month (annual) or $19/maker/month (monthly). AI is included via credits (250 per maker per month). Enterprise pricing for SSO and advanced features is custom.

**Pricing:** Spark at $15/maker/month (annual) or $19/maker/month (monthly). Enterprise is custom.

### UserVoice

UserVoice pioneered the customer feedback category and still targets enterprise teams. The main differentiator is revenue-linked prioritization. Connect Salesforce or HubSpot, and UserVoice pulls in account-level ARR data so you can see the total revenue behind each feature request.

The pricing reflects the enterprise focus. Plans start at $16,000/year (~$1,333/mo) with annual billing. No per-seat charges. A 30-day free trial is available.

**Pricing:** Starting at $16,000/year (~$1,333/mo). Custom pricing based on volume. Annual billing required.

## Roadmapping tools

A roadmap communicates what you are building, when, and why. Good roadmapping tools connect your plans to user demand, development capacity, and business objectives. They give your team alignment and give your users transparency.

### Quackback roadmap

Quackback includes a [public roadmap](/features/roadmap) as part of its feedback platform. Feature requests flow directly into roadmap items with planned, in progress, and shipped statuses. When you move a request to "shipped," voters get notified automatically through the [changelog](/features/changelog). The roadmap is public by default, so your users can see what you are working on without asking.

This approach works well when your roadmap is driven primarily by user demand. Feature requests, vote counts, and user segments feed directly into what appears on the roadmap.

### Aha!

Aha! is a dedicated roadmapping and product management platform. It supports strategy canvases, initiative tracking, feature prioritization with scoring, and visual roadmaps with timeline, list, and board views. It integrates with Jira, Azure DevOps, Rally, and other development tools.

Aha! is built for product organizations that need to connect roadmaps to company strategy, OKRs, and cross-team dependencies. The depth is significant, but so is the learning curve and cost.

**Pricing:** Roadmaps starts at $59/user/month. Ideas (feedback) is $39/user/month. Enterprise pricing available.

See how it compares: [Quackback vs Aha!](/compare/quackback-vs-aha).

### Linear

Linear is primarily a project management tool, but its roadmap features have matured. You can organize projects into initiatives, set target dates, and view progress across teams. Linear roadmaps are lightweight compared to Aha! but integrate tightly with the issue tracking you are already doing in Linear.

For teams that use Linear for project management, adding roadmapping within the same tool avoids context switching and keeps plans connected to actual work.

**Pricing:** Free for small teams. Standard at $8/user/month. Plus at $14/user/month.

### Productboard

Productboard appears in this section too because its roadmapping capabilities are strong. Driver-based roadmaps let you tie features to strategic objectives and score them against custom criteria. The roadmap views include timeline, release, and board formats. If you need roadmaps that are deeply connected to customer feedback and business strategy, Productboard handles both.

## Project management tools

Once you decide what to build, you need to track the work. Project management tools handle task assignment, sprint planning, issue tracking, and cross-team coordination.

### Linear

Linear has become the default project management tool for many software teams. It covers issues, projects, cycles (sprints), and triage workflows. The interface is fast. Keyboard shortcuts handle most actions. Issue creation, status changes, and assignments feel immediate in a way that heavier tools do not.

Linear integrates with Slack, GitHub, GitLab, Figma, Sentry, and Zendesk. Its API is well-documented and widely used for custom workflows. Quackback integrates with Linear so feature requests can be pushed directly into your Linear workspace as issues.

**Pricing:** Free for small teams. Standard at $8/user/month. Plus at $14/user/month.

### Jira

Jira is the most widely used project management tool in software development. It handles issue tracking, sprint planning, kanban boards, release management, and custom workflows. The flexibility is its strength and its weakness. You can configure Jira to do almost anything, which means most Jira instances end up heavily customized and hard to maintain.

For large engineering organizations with complex workflows, cross-team dependencies, and compliance requirements, Jira remains difficult to replace. Quackback integrates with Jira to push feature requests into your backlog.

**Pricing:** Free for up to 10 users. Standard at $7.75/user/month. Premium at $15.25/user/month. Enterprise is custom.

### Asana

Asana covers project management for both technical and non-technical teams. It supports list, board, timeline, and calendar views. Workflows automate task routing and status changes. Portfolios let you track progress across multiple projects.

Asana works well for teams that need to coordinate across engineering, marketing, design, and operations. It is less developer-focused than Linear or Jira but more accessible to non-technical team members.

**Pricing:** Free for up to 10 users. Starter at $10.99/user/month. Advanced at $24.99/user/month. Enterprise is custom.

### Notion

Notion is a flexible workspace that can function as a project management tool through its databases, views, and relations. Many teams use Notion for documentation, wikis, and lightweight project tracking. Its strength is versatility. You can build almost any workflow with databases, templates, and formulas.

The limitation is that Notion is not purpose-built for software development. It lacks native sprint planning, issue tracking conventions, and developer integrations that tools like Linear and Jira provide. It works best as a complement to a dedicated project management tool, handling documentation, specs, and team knowledge while Linear or Jira handles execution.

**Pricing:** Free for individuals. Plus at $10/user/month. Business at $15/user/month. Enterprise is custom.

## Analytics tools

Analytics tools tell you what happened after you shipped. They measure feature adoption, user behavior, retention, and the impact of product changes. Without analytics, you are guessing whether what you built actually solved the problem.

### Amplitude

Amplitude is a product analytics platform focused on behavioral analysis. It tracks user events, builds funnels, analyzes retention cohorts, and identifies the actions that correlate with long-term engagement. The charts and dashboards are built for product teams, not just data analysts.

Amplitude also offers experiment tracking (A/B testing) and a customer data platform. The free tier is generous for early-stage products.

**Pricing:** Free Starter plan (up to 50K monthly tracked users). Plus from $49/mo. Growth is custom.

### Mixpanel

Mixpanel covers similar ground to Amplitude: event tracking, funnels, retention analysis, and user segmentation. Its query builder is flexible and the interface is clean. Mixpanel has traditionally been stronger on real-time analytics and easier to set up for smaller teams.

The choice between Amplitude and Mixpanel often comes down to preference and which analytics model fits your team. Both are capable.

**Pricing:** Free Starter plan (up to 20M events/month). Growth from $24/mo. Enterprise is custom.

### PostHog

PostHog is an open-source product analytics platform. It bundles event analytics, session replays, feature flags, A/B testing, and surveys into one product. You can self-host or use their cloud. The open-source model means you can inspect the code, contribute, and avoid vendor lock-in.

PostHog is a good fit for engineering-led teams that value transparency and data ownership. The self-hosted option gives you full control over your analytics data.

**Pricing:** Free tier with generous limits. Paid usage-based pricing starts at low per-event rates. Self-hosting is free.

### Pendo

Pendo combines product analytics with in-app guides and user onboarding. It tracks feature adoption, builds user segments based on behavior, and lets you create tooltips, walkthroughs, and announcements inside your product without code changes.

The analytics-plus-guidance approach is useful for teams that want to measure adoption and drive it at the same time. Pendo targets mid-market and enterprise teams.

**Pricing:** Free plan available with limited features. Growth, Portfolio, and Enterprise tiers require a sales call.

## Prioritization frameworks and tools

Deciding what to build next is the hardest part of product management. Prioritization frameworks give you a structured way to evaluate ideas instead of relying on gut feeling or whoever argues loudest.

### RICE scoring

RICE stands for Reach, Impact, Confidence, and Effort. You estimate how many users a feature will reach, how much impact it will have, how confident you are in those estimates, and how much effort it takes to build. The formula produces a score you can use to rank features against each other.

RICE works well because it forces you to be explicit about your assumptions. Two people can look at the same feature request and disagree on impact, but at least the disagreement is visible and specific. Use our [RICE scoring calculator](/tools/rice-scoring-calculator) to apply the framework. For a deeper explanation, see our guide to the [RICE framework explained](/blog/rice-framework-explained).

### ICE scoring

ICE stands for Impact, Confidence, and Ease. It is simpler than RICE. You score each dimension from 1 to 10 and multiply. ICE works well for quick prioritization when you need a lightweight framework. The trade-off is that it does not account for reach, which means a feature that delights 10 users can score the same as one that helps 10,000.

### MoSCoW

MoSCoW categorizes features as Must-have, Should-have, Could-have, or Won't-have. It is less quantitative than RICE or ICE but useful for release planning and scope negotiations. MoSCoW works best when you have a fixed set of features and need to decide what makes the cut for a specific release or sprint.

### Voting as data input

Prioritization frameworks are only as good as the data you feed them. Feature voting in feedback tools gives you a real signal for the "Reach" dimension of RICE. Instead of guessing how many users want a feature, you have actual vote counts broken down by user segment. Combine voting data with revenue signals and effort estimates from your engineering team, and you have a solid foundation for prioritization decisions.

## How to build your PM tool stack

You do not need one tool for every category. Most early-stage teams do well with two: a feedback tool and a project management tool. Collect feature requests in one place, track work in another.

**Start with feedback and project management.** Pick a feedback tool that handles collection, voting, roadmapping, and changelog in one place. Pair it with Linear or Jira for issue tracking and sprint planning. An integration between the two means accepted feature requests flow into your development workflow without manual re-entry.

**Add analytics when you need it.** Once you have enough users that you cannot track behavior through direct conversations, bring in Amplitude, Mixpanel, or PostHog. This usually happens around the time you start worrying about retention and feature adoption rather than just shipping.

**Skip dedicated roadmapping tools unless you need strategic alignment.** If your roadmap is driven by user feedback and your team is small enough to stay aligned without formal planning tools, the roadmap feature built into most feedback tools (Quackback, Canny, Featurebase) is enough. Aha! and Productboard make sense when you have multiple product teams, company-wide OKRs, and cross-functional stakeholders who need visibility.

**Avoid overlapping tools.** Every tool you add creates another place where information lives. If your project management tool has a basic roadmap view, you may not need a separate roadmapping tool. If your feedback tool includes a changelog, you do not need a separate changelog product. Consolidation reduces context switching and keeps your team focused.

**Re-evaluate annually.** Your tool stack should grow with your team and product. What works for a five-person startup does not work for a fifty-person product organization. Review what is working and what is creating friction once a year.

## Feedback tool comparison

If feedback and feature request management is the most important piece of your stack, here is how the main options compare.

| Feature | Quackback | Canny | Productboard | UserVoice | Featurebase |
|---|---|---|---|---|---|
| **Voting boards** | Yes | Yes | Yes | Yes | Yes |
| **Public roadmap** | Yes | Yes | Yes | No | Yes |
| **Changelog** | Yes | Yes | No | No | Yes |
| **AI features** | Yes (duplicate detection, sentiment, merge suggestions) | Yes (Autopilot) | Yes (included via credits, 250/maker/mo) | No | Yes (Fibi, $0.49/resolution) |
| **MCP server** | Yes | No | No | No | No |
| **Open source** | Yes (AGPL-3.0) | No | No | No | No |
| **Self-hosting** | Yes | No | No | No | No |
| **Integrations** | 20+ | 15+ | 20+ | 10+ | 12 |
| **Free tier** | Yes (self-host) | 25 tracked users | Limited | No | 1 seat |
| **Starting price** | Free self-hosted / $29/mo Cloud | Free (25 tracked users) | $15/maker/mo (annual) | $16,000/yr | $29/seat/mo |

## Frequently asked questions

### What tools do product managers use every day?

Most product managers use a combination of three to four tools daily. A feedback tool (Quackback, Canny, or Productboard) for reviewing feature requests and updating the roadmap. A project management tool (Linear or Jira) for tracking development work. An analytics tool (Amplitude or Mixpanel) for measuring feature adoption. And a communication tool (Slack or Notion) for internal alignment and documentation.

### Do I need a dedicated roadmapping tool?

Not necessarily. If your team is small and your roadmap is driven by user feedback, the roadmap built into your feedback tool is usually sufficient. Most feedback platforms (Quackback, Canny, Featurebase) include a public roadmap that connects to feature requests and a changelog. Dedicated roadmapping tools like Aha! make sense when you have multiple product teams, strategic planning needs, and stakeholders across the organization who need visibility into long-term plans.

### What is the best free product management tool?

It depends on what you need. For feedback and feature requests, [Quackback](https://quackback.io) is free and open source, with a self-hosted option you run on your own infrastructure. For project management, Linear offers a free tier for small teams. For analytics, both Amplitude and Mixpanel have free plans, and PostHog is open source with a generous free tier.

### How do I prioritize feature requests without a framework?

You can start simple. Look at vote counts in your feedback tool to understand demand. Talk to your highest-value customers to understand urgency. Estimate effort with your engineering team. But as your product grows, a structured framework helps. RICE scoring is the most widely used. It accounts for reach, impact, confidence, and effort. Use our [RICE scoring calculator](/tools/rice-scoring-calculator) to get started. The key is moving from "I think this is important" to "here is why this scores higher than that."

- [RICE Framework Explained: How to Prioritize Features](https://quackback.io/blog/rice-framework-explained): A complete guide to the RICE scoring framework. Learn how to score Reach, Impact, Confidence, and Effort to prioritize your product backlog objectively.

Published: 2026-02-17

Feature prioritization is one of the hardest parts of product management. Every team has more ideas than capacity. Users want different things. Stakeholders push competing agendas. Without a structured approach, decisions default to whoever argues loudest or whoever has the most seniority.

![RICE scoring framework formula visualization](/blog/rice-framework-explained/hero.webp)

The result is predictable. You build features that don't move metrics. You delay high-impact work because it wasn't top of mind during planning. You can't explain to your team or your users why you chose one thing over another.

RICE gives you a framework to score and compare ideas objectively. It won't make decisions for you, but it surfaces trade-offs clearly, replaces gut feelings with structured reasoning, and gives your team a shared language for prioritization.

> **RICE** is a product prioritization framework that scores each feature on four factors — **Reach**, **Impact**, **Confidence**, and **Effort** — using the formula `(Reach x Impact x Confidence) / Effort`. The higher the score, the better the value per unit of work, so you rank your backlog by score to decide what to build first. It turns subjective debate into a defensible, comparable number.

## What is the RICE framework?

RICE is a prioritization framework developed by [Intercom's product team in 2016](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/). It scores ideas across four factors — Reach, Impact, Confidence, and Effort — and produces a numeric score you use to rank your backlog.

The formula is straightforward:

**RICE Score = (Reach x Impact x Confidence) / Effort**

The numerator captures the total expected value of an idea. Reach tells you how many users benefit. Impact tells you how much they benefit. Confidence adjusts for uncertainty. Dividing by Effort gives you a value-per-unit-of-work score that makes it possible to compare a small quick win against a large strategic bet.

RICE works because it forces you to think about each dimension separately. Most teams already consider reach and effort intuitively. But they rarely estimate confidence explicitly, so a well-researched idea scores the same as a speculative one. And they rarely quantify impact on a consistent scale, making comparison across feature types impossible.

The framework is simple enough to use in a spreadsheet. Score each idea, sort by RICE score, and you have a defensible starting point for your [roadmap](/features/roadmap).

## The four RICE factors

### Reach

Reach measures how many users will be affected by this feature in a given time period. The standard unit is users per quarter, but you can adapt it to whatever makes sense for your product: monthly active users, transactions per month, or new signups per quarter.

The key is consistency. Every idea on your list should use the same Reach metric and the same time period. If you measure one feature's reach in daily active users and another in annual signups, the comparison is meaningless.

Where do you get reach numbers? Your analytics. If you're building a feature for your settings page, check how many users visit that page per quarter. If you're improving onboarding, use your quarterly new signup count. If you're adding an integration, check your [feedback board](/features/feedback) for request counts and support ticket volumes. Even a rough estimate based on real data is better than guessing.

**Examples:**
- A change to the onboarding flow that affects every new user: 2,000 users/quarter (based on your signup rate).
- A new integration requested by a segment of your user base: 400 users/quarter (based on voting data and usage patterns).
- A power-user feature for a niche workflow: 50 users/quarter.

### Impact

Impact measures how much this feature will move the needle for each user it reaches. Unlike Reach, which is a concrete number, Impact uses a standardized scale:

- **3 = Massive impact.** A fundamental improvement to the user experience or a feature that directly drives conversion, retention, or revenue.
- **2 = High impact.** A significant improvement that users will notice and value.
- **1 = Medium impact.** A useful improvement, but not life-changing.
- **0.5 = Low impact.** A minor improvement. Nice to have.
- **0.25 = Minimal impact.** Barely noticeable to most users.

The scale is intentionally coarse. Trying to distinguish between 1.7 and 1.8 is false precision. The five-point scale forces a judgment call: is this a big deal or a small deal?

Impact is the most subjective RICE factor. Two people on your team might score the same feature differently. That's fine — the conversation about why they disagree is often more valuable than the score itself.

To calibrate, pick shipped features as reference points. "CSV export was a 1. The dashboard redesign was a 2." Shared references reduce subjective drift over time.

### Confidence

Confidence is a percentage that reflects how sure you are about your Reach and Impact estimates. It adjusts the score downward when you're guessing and keeps it high when you have evidence.

Use these benchmarks:

- **100% = High confidence.** You have quantitative data: usage analytics, A/B test results, or large sample survey data.
- **80% = Medium confidence.** You have some supporting data but not conclusive evidence. Qualitative feedback from interviews, or directional data from a small sample.
- **50% = Low confidence.** Mostly a gut feeling. You think it's a good idea, but you don't have data to back it up.

Below 50%, you probably shouldn't be scoring the idea at all. You should be running a discovery sprint to learn more.

Confidence is what makes RICE more honest than other frameworks. Without it, a speculative moonshot scores the same as a well-validated improvement. With it, the speculative idea gets discounted appropriately.

How do you increase confidence? Gather data. Check your [feature voting board](/features/voting) for request volume and user comments. Interview users who asked for the feature. Analyze support tickets. Build a prototype and test it. Every piece of evidence moves your Confidence score up.

When 200 users have voted for a feature and left detailed comments, your Confidence in Reach and Impact is much higher than when two users mentioned it in passing during sales calls.

### Effort

Effort measures how much work this feature requires, expressed in person-months. One team member working for one month is 1 person-month. A feature that takes one engineer two weeks is 0.5 person-months. Two engineers, one designer, and one PM working a full month is 4 person-months.

Include all work: design, engineering, QA, documentation, and launch activities. Teams that only count engineering time consistently underestimate Effort.

Keep the unit consistent across all features. And be honest — the natural tendency is to underestimate, especially for features you're excited about.

**Examples:**
- Adding a new notification preference toggle: 0.5 person-months.
- Building a new integration with a third-party API: 2 person-months.
- Redesigning the reporting dashboard: 6 person-months.

## RICE scoring example

![RICE scoring example with three feature comparisons](/blog/rice-framework-explained/scoring-example.webp)

Let's walk through three feature ideas for a SaaS product and score each one.

### Feature A: Slack integration for notifications

Users have been asking for Slack notifications when key events happen. You have data from your [feedback board](/features/feedback) showing demand.

- **Reach:** 800 users/quarter. Based on voting data and the percentage of your user base that uses Slack.
- **Impact:** 2 (High). Keeps users engaged without requiring them to check your product constantly.
- **Confidence:** 80%. You have voting data and interview feedback, but you haven't validated the exact notification types users want.
- **Effort:** 2 person-months. One engineer for backend integration, plus design and QA time.

**RICE Score = (800 x 2 x 0.8) / 2 = 640**

### Feature B: Advanced analytics dashboard

A redesigned analytics page with custom date ranges, new chart types, and exportable reports.

- **Reach:** 1,200 users/quarter. Most active users visit the analytics page.
- **Impact:** 1 (Medium). Useful but not transformative. Users can already see their data; this makes it easier to slice.
- **Confidence:** 50%. You've heard requests for better analytics, but you haven't validated which specific improvements matter most.
- **Effort:** 4 person-months. Two engineers for two months, plus design.

**RICE Score = (1,200 x 1 x 0.5) / 4 = 150**

### Feature C: Onboarding checklist

A guided checklist that walks new users through setup steps during their first week.

- **Reach:** 500 users/quarter. Based on your new signup rate.
- **Impact:** 3 (Massive). Your data shows that users who complete setup in the first week retain at 3x the rate of those who don't.
- **Confidence:** 100%. You have strong retention data and A/B test results from a similar feature at a previous company.
- **Effort:** 1.5 person-months. One engineer, one designer, three weeks.

**RICE Score = (500 x 3 x 1.0) / 1.5 = 1,000**

### The ranking

| Feature | Reach | Impact | Confidence | Effort | RICE Score |
|---|---|---|---|---|---|
| C: Onboarding checklist | 500 | 3 | 100% | 1.5 | 1,000 |
| A: Slack integration | 800 | 2 | 80% | 2 | 640 |
| B: Advanced analytics | 1,200 | 1 | 50% | 4 | 150 |

The onboarding checklist wins despite having the lowest Reach. Its massive Impact, high Confidence, and low Effort make it the best investment. The advanced analytics dashboard scores last — not because it's a bad idea, but because low Confidence and high Effort make it a risky bet. The right move might be to run a discovery sprint on analytics (increasing Confidence) before committing 4 person-months to it.

The scores don't make the decision. They start the conversation in the right place.

## RICE vs other prioritization frameworks

RICE is not the only prioritization framework. Here's how it compares to the alternatives.

### ICE (Impact, Confidence, Ease)

ICE scores three factors on a 1-10 scale and multiplies them together. Simpler than RICE — it drops Reach and replaces Effort with Ease (the inverse).

**Pros:** Fast to score. Low overhead. Good for early-stage teams with small backlogs.
**Cons:** No Reach component means a feature affecting 10 users scores the same as one affecting 10,000. The 1-10 scale for each factor introduces more subjectivity than RICE's structured scales.

### MoSCoW (Must, Should, Could, Won't)

MoSCoW sorts features into four buckets rather than scoring them numerically. Must-haves are non-negotiable. Should-haves are important but not critical. Could-haves are nice to have. Won't-haves are explicitly out of scope.

**Pros:** Simple to explain. Forces a "won't do" category, which many frameworks lack.
**Cons:** No way to prioritize within a bucket. If you have 15 must-haves, you still need a second framework to rank them. Everything tends to drift into the "must" bucket over time.

### WSJF (Weighted Shortest Job First)

WSJF comes from the SAFe (Scaled Agile Framework) methodology. It divides cost of delay by job duration. Cost of delay includes user value, time criticality, and risk reduction.

**Pros:** Accounts for time sensitivity, which RICE does not. Good for features with deadlines or market windows.
**Cons:** More complex to score. Cost of delay is harder to estimate than RICE's four factors. Best suited for organizations already using SAFe.

### Kano model

The Kano model categorizes features by their effect on satisfaction: basic expectations (cause dissatisfaction when missing), performance features (satisfaction scales linearly), and delighters (unexpected features that create outsized satisfaction).

**Pros:** Captures the non-linear relationship between features and satisfaction. Prevents over-investing in basics.
**Cons:** Requires user research to categorize accurately. Doesn't produce a numeric ranking, so you still need a scoring method for build order.

RICE is a good default for most product teams. It balances simplicity with rigor. If you need to account for time sensitivity, consider WSJF. For speed over precision, use ICE. Use MoSCoW for stakeholder communication, and the Kano model for strategic thinking — but pair either with a numeric scoring method for tactical prioritization.

## Tips for using RICE effectively

**1. Score as a team, not alone.** RICE works best when multiple people contribute estimates. The PM might know Reach best. Engineering knows Effort best. Designers often have a different read on Impact. Score together, discuss disagreements, and converge on a number. The conversation matters as much as the score.

**2. Revisit scores when new data arrives.** RICE scores are snapshots. When you collect new [customer feedback](/blog/collect-customer-feedback) or ship a feature that changes the landscape, update affected scores. A feature you scored at 50% Confidence six months ago might be at 80% now that you have voting data from your [feedback board](/features/feedback).

**3. Don't over-optimize the formula.** RICE is a decision-support tool, not a decision-making algorithm. If two features score 620 and 640, they are effectively tied. The framework is most valuable when it separates the 1,000s from the 150s — revealing that an idea you assumed was important is a poor investment compared to alternatives.

**4. Use consistent time periods and units.** Measure Reach in the same time period for every feature. Measure Effort in the same unit. If you mix quarterly reach with annual reach, or person-weeks with person-months, the scores are not comparable.

**5. Keep a scoring log.** Document the reasoning behind each score, not just the number. "Reach = 800 based on Slack usage survey from Q4" is far more useful than "Reach = 800" when you revisit three months later. The log also helps onboard new team members into your prioritization process.

## Tools for RICE scoring

You can run RICE scoring in a spreadsheet. Create columns for Reach, Impact, Confidence, Effort, and the calculated RICE score. Sort by score. That works fine for small backlogs.

For a faster option, use [Quackback's RICE calculator](/tools/rice-scoring-calculator). Enter your four values and get the score instantly, which is useful during planning meetings or when evaluating a single idea.

The harder part of RICE is not the math — it's getting reliable inputs. This is where [feature voting](/features/voting) data becomes valuable. When users vote on features and leave comments on your [feedback board](/features/feedback), you get real data for two of the four RICE factors. Vote counts inform Reach. The volume and specificity of comments inform Confidence. Instead of guessing how many users want a feature, you see the number directly.

Quackback is open source and self-hosted, with a managed [Quackback Cloud](/pricing) option. Your whole team can score and discuss the backlog together. Its [MCP server](/features/mcp) also lets an AI assistant read your live vote counts and feedback, so you can draft RICE estimates straight from real demand data rather than memory.

The framework provides the structure. Feedback data provides the inputs. Together, they replace opinion-driven prioritization with something defensible.

If you're building out your [product management toolkit](/blog/product-management-tools), RICE scoring and a [feature request tool](/blog/best-feature-request-tools) are two of the highest-leverage additions you can make.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### When should you not use RICE?

Avoid RICE for infrastructure work, technical debt, or compliance requirements, where Reach and Impact do not map cleanly. Use a separate track for those. Bug fixes and security patches have their own urgency criteria and do not belong in a RICE scoring exercise. RICE suits user-facing features best.

### How often should you re-score your backlog?

Re-score at the start of each planning cycle — typically quarterly. Between cycles, update individual scores when significant new data arrives: a spike in feature requests, user research results, or a change in team capacity that affects Effort estimates. Avoid re-scoring everything weekly. The overhead erodes the framework's value.

### Can you customize the RICE scales?

Yes. The standard scales are a starting point. Some teams add a sixth Impact level, use a 1-10 Confidence scale, or measure Effort in story points. What matters is that your team agrees on the definitions and uses them consistently. Customizing scales is fine; changing them mid-cycle is not.

### How do you handle dependencies between features?

RICE scores each feature independently, so it doesn't account for dependencies. If Feature B requires Feature A, the score alone won't tell you that. Handle dependencies separately — flag them during scoring, and when you build your [roadmap](/features/roadmap), sequence dependent features together regardless of individual scores.

- [Jira Product Discovery Pricing 2026: Plans and Alternatives](https://quackback.io/blog/jira-product-discovery-pricing): Jira Product Discovery pricing breakdown in 2026. Free tier, per-user costs, total cost with Jira Software, and standalone alternatives.

Published: 2026-02-15

Jira Product Discovery is Atlassian's answer to product feedback and prioritization. It gives product managers a dedicated space to collect ideas, score them against impact and effort criteria, and build roadmaps — all within the Jira ecosystem. That tight integration is both its core value proposition and its principal constraint.

If your team already runs on Jira Software and Confluence, adding JPD is low friction. If you don't, you're evaluating an entire Atlassian stack, not just one tool.

![Jira Product Discovery pricing and plan comparison](/blog/jira-product-discovery-pricing/hero.webp)

> Jira Product Discovery has a free tier for up to 3 creators, Standard at $10/creator/month, and Premium at $25/creator/month. Only creators are billable — contributors who view and comment are free. The catch is that most product teams also need Jira Software, which is priced separately, so a 50-creator team's combined bill can exceed $1,500/month. Standalone alternatives like [Quackback](https://quackback.io) work without Jira and cost nothing to self-host.
>
> *Pricing last verified February 2026. Vendors may change plans and pricing without notice. Check Atlassian's pricing page for the latest figures.*

## What is Jira Product Discovery

Jira Product Discovery is Atlassian's product management tool for collecting, organizing, and prioritizing product ideas. It launched in beta in 2023 and reached general availability in 2024. It sits alongside Jira Software in the Atlassian ecosystem, and is built specifically for product managers rather than developers.

The core workflow: ideas come in from stakeholders, customers, or your own team. You score them using configurable fields (impact, confidence, effort). Views let you sort and filter ideas by score, status, or label. You build a roadmap from prioritized ideas, then link them to Jira Software issues for delivery tracking. When development is complete, the linked issues surface status updates back in JPD.

This delivery feedback loop — where Jira Software ticket progress reflects in JPD — is the product's clearest differentiator. It works well when your engineering team is already on Jira Software. It adds no value when they are not.

## Pricing breakdown

Jira Product Discovery is priced per creator per month, billed monthly or annually. Annual billing gives you up to 17% off the monthly rate. Only creators — people who create and manage ideas, fields, and views — are billable; contributors who view and comment are free with an Atlassian account.

| Plan | Price (per creator) | Creators | Key Features |
|------|---------------|-------|--------------|
| **Free** | $0 | Up to 3 | Idea capture, custom fields, prioritization views, roadmaps, basic integrations |
| **Standard** | $10/creator/mo | Unlimited | Everything in Free, project permissions, audit logs, 250 GB storage |
| **Premium** | $25/creator/mo | Unlimited | Everything in Standard, advanced roadmaps, unlimited storage, admin insights |
| **Enterprise** | Custom | Unlimited | Everything in Premium, unlimited sites, Atlassian Access included, SAML SSO, dedicated support |

The free tier covers up to 3 creators and includes the core workflow: ideas, custom fields, scoring views, and roadmaps. For very small teams that only need internal prioritization, this is a usable starting point.

Standard at $10/creator/month adds the operational features that matter once you have more than a handful of people: project-level permissions, audit logging, and expanded storage. Most teams beyond the free tier land here first.

Premium at $25/creator/month adds advanced roadmaps (cross-project views, dependencies), unlimited storage, and admin insights. The advanced roadmap view is the primary reason to upgrade from Standard, and it's only relevant if you're managing multiple product lines or need timeline views with dependency tracking.

Enterprise is sold with custom pricing and billed annually. It includes Atlassian Access (centralized user provisioning and SSO across the Atlassian suite) and unlimited Atlassian sites.

Note that SSO and SCIM provisioning below the Enterprise tier are available through Atlassian Guard (formerly Atlassian Access), which is a separate add-on subscription. If your organization requires SSO but is not on Enterprise, you pay for JPD plus a Guard subscription on top.

## Total cost with Jira Software

Jira Product Discovery is priced separately from Jira Software. Most product and engineering teams need both: JPD for the product management layer, Jira Software for the development backlog and sprint tracking. The delivery tracking integration — linking JPD ideas to Jira Software issues — only works if your engineering team is on Jira Software.

This means your real cost is the combined subscription, not just the JPD line item.

Jira Software is priced at $8.15/user/month (Standard) and $16/user/month (Premium), billed annually. The table below shows the combined monthly cost for teams that need both tools.

| Team Size | JPD Standard | Jira Software Standard | Combined (Standard) | Combined (Premium) |
|-----------|-------------|----------------------|--------------------|--------------------|
| 10 users | $100/mo | $81.50/mo | $181.50/mo | $410/mo |
| 25 users | $250/mo | $203.75/mo | $453.75/mo | $1,025/mo |
| 50 users | $500/mo | $407.50/mo | $907.50/mo | $2,050/mo |
| 100 users | $1,000/mo | $815/mo | $1,815/mo | $4,100/mo |

With 3 or fewer creators, you can use JPD for free while paying for Jira Software on whatever plan your engineering team already uses. The free JPD tier is genuinely useful here — it costs nothing to add JPD to an existing Jira Software subscription for a tiny product team.

Above 3 creators, JPD costs stack on top of whatever your team already pays for Jira Software. At 50 creators on Standard, you're looking at roughly $900/month combined. At 100 creators on Premium, the combined bill reaches about $4,100/month.

These figures count every JPD creator and every Jira Software user. In practice many viewers are free JPD contributors, and some engineers only need Jira Software. But any person who actively creates ideas in JPD and also works in Jira Software counts toward both subscriptions.

## What you get

Jira Product Discovery covers the standard product management workflow with some additions specific to the Jira ecosystem.

**Ideas and feedback capture.** You can create ideas manually, collect them via a submission form, or import from integrations like Slack, Salesforce, and Zendesk. Each idea is a first-class object with a description, status, and configurable fields.

**Custom fields and scoring.** You can add custom numeric, text, select, and formula fields to any idea. Impact scoring is done through configurable formulas — you define the calculation, JPD computes a score for each idea based on the field values. This is more flexible than fixed frameworks (ICE, RICE) and lets you build scoring models that reflect your team's actual priorities.

**Prioritization views.** Ideas can be viewed as a list, matrix (two-axis prioritization chart), or board (Kanban-style). Views are filterable and sortable by any field. You can save views for recurring use.

**Roadmap.** The roadmap view is a timeline-style view that shows ideas across time. On Standard, this is a single-project roadmap. On Premium, you get cross-project roadmap views with dependency tracking.

**Delivery tracking.** When you link a JPD idea to one or more Jira Software issues, the status of those issues surfaces in JPD. This lets product managers see development progress without leaving JPD or asking engineers for updates. This is the feature that distinguishes JPD from standalone tools.

**Integrations.** JPD includes native integrations with Slack, Salesforce, Zendesk, and other common tools for feedback capture. Deeper integrations with other Atlassian products (Confluence, Jira Service Management) are available given that everything lives on the same platform.

## Limitations

JPD has real limitations that are worth understanding before committing to it.

**Tied to the Atlassian ecosystem.** JPD is not a standalone product. It lives inside Jira, depends on Atlassian's infrastructure, and the delivery tracking feature only works if your engineering team uses Jira Software. If you're not already on Jira, adding JPD means adopting Atlassian's broader platform.

**No meaningful public-facing roadmap.** JPD's roadmap views are internal by default. You can share a read-only roadmap link, but it is basic — no public voting, no commenting from external users, no branding customization. If you want customers to vote on features or follow your roadmap publicly, JPD does not support this workflow.

**No customer-facing feedback portal.** External users cannot submit ideas or vote on existing ones through a public portal. Feedback collection happens through embedded forms or integrations, not through a dedicated customer-facing board. This is a significant gap for teams that want to build a visible feedback loop with their customers.

**No changelog.** JPD has no mechanism for publishing release notes or changelogs to external audiences. If you want to tell customers what shipped, you need a separate tool.

**No purpose-built API for automation.** JPD has no dedicated public API. Because JPD ideas are stored as Jira issues, you can read and update them through the general Jira Cloud REST API, but there is no first-class API for views and no out-of-the-box way to connect AI agents to your discovery data. Automation leans on Atlassian's own rules and integrations. Tools built for automation — Quackback, for example, with its [MCP server](/features/mcp) — let AI agents read and act on feedback directly.

**Learning curve if you're new to Jira.** Jira's data model — projects, issue types, schemes, permissions — is not intuitive for new users. JPD inherits this complexity. Teams that have used Jira for years will adapt quickly. Teams coming from simpler tools will spend meaningful time in setup and training before they can use JPD productively.

**Storage and SLA limits on Standard.** The Standard plan includes 250 GB of storage and no SLA. For most teams this is sufficient, but organizations with compliance requirements may need Premium's unlimited storage and 99.9% SLA.

## Who it's best for

JPD is a good fit for product teams that are already deep in the Jira and Confluence ecosystem. If your engineers live in Jira Software and your documentation lives in Confluence, JPD slots in with minimal disruption. The delivery tracking integration — seeing Jira issue progress inside JPD — provides real value for teams where the PM and engineering workflows are otherwise siloed.

It is also a reasonable choice for Atlassian customers who want to consolidate tooling. Adding JPD to an existing Atlassian subscription is administratively simple: same identity provider, same billing, same admin console.

For teams not on Jira, the calculus is different. You'd be adopting JPD and Jira Software together, which means a substantial combined cost and a non-trivial onboarding investment. Most standalone feedback and prioritization tools cost less and require less setup.

![Combined monthly cost of Jira Product Discovery and Jira Software across team sizes and plan tiers](/blog/jira-product-discovery-pricing/jpd-combined-cost-tiers.webp)

## Alternatives for teams not on Jira

If you're not already in the Jira ecosystem — or if you want a tool that handles customer-facing feedback, voting, and changelogs — these alternatives are worth comparing.

| Tool | Price | Key Differences |
|------|-------|-----------------|
| [Quackback](https://quackback.io) | Free (open source, self-hosted) | Feedback portal, public voting, roadmap, changelog, AI features, SSO — no Jira dependency |
| Canny | From $19/mo | Public feedback boards, voting, roadmap, changelog — standalone, no Jira required. [See Canny pricing.](/blog/canny-pricing) |
| Productboard | From $19/maker/mo | Strategic roadmaps, insight repository, prioritization frameworks — standalone. [See Productboard pricing.](/blog/productboard-pricing) |

**Quackback** is the free, open-source option. You self-host it with Docker, there are no per-user fees, and it includes feedback boards with [public voting](/features/voting), a [customer-facing roadmap](/features/roadmap), [changelogs](/features/changelog), and 25 integrations. SSO/OIDC is included. Where JPD has no open API for automation, Quackback ships an [MCP server](/features/mcp) so AI agents and scripts can read and act on feedback programmatically, and its AI summarization runs on your own API key — no per-summary credit caps. It does not have delivery tracking tied to a specific project management tool, but it works with any stack. Prefer not to host it yourself? [Quackback Cloud](/pricing) is a managed option. See the [Quackback vs Productboard](/compare/quackback-vs-productboard) comparison and the [best feature request tools](/blog/best-feature-request-tools) guide for more context.

**Canny** is a hosted tool with a polished interface, a public feedback board, voting, roadmap, and changelog. It works without Jira. The Core plan at $19/month covers 100+ tracked users, and PM integrations for Jira, ClickUp, and Linear are available on the Pro plan at $79/month. See the full [Canny pricing breakdown](/blog/canny-pricing).

**Productboard** is the closest to JPD in terms of strategic depth. It has a strong insight repository, custom prioritization scoring, and multi-view roadmaps. It does not require Jira. The Spark plan starts at $15/maker/month (annual). See the full [Productboard pricing breakdown](/blog/productboard-pricing).

For a broader view, see the [feedback tool pricing comparison](/blog/feedback-tool-pricing-comparison), [best public roadmap tools](/blog/best-public-roadmap-tools), and [product management tools overview](/blog/product-management-tools).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Is Jira Product Discovery free?

Yes, for up to 3 creators. The free tier includes idea capture, custom fields, prioritization views, roadmaps, and basic integrations. Beyond 3 creators, Standard is $10/creator/month and Premium is $25/creator/month, billed monthly or annually (annual saves up to 17%). Contributors who only view and comment are free. Teams that need Jira Software too pay for that subscription separately.

### Do I need Jira Software to use Jira Product Discovery?

No, but the most valuable feature — delivery tracking — depends on Jira Software. JPD can capture ideas, score them, and display a roadmap independently. The integration that shows linked Jira Software issue progress inside JPD only works when your engineering team uses Jira Software. If they don't, you're paying for JPD without access to the feature that differentiates it from standalone tools.

### What is the total cost of Jira Product Discovery for a 50-person team?

At 50 creators on Standard, JPD costs $500/month and Jira Software for 50 users costs $407.50/month — a combined total of about $907.50/month, or roughly $10,900/year. On Premium, the combined cost reaches about $2,050/month. These figures assume all 50 people are billable in both products.

### Does Jira Product Discovery support public feedback voting?

No. Jira Product Discovery has no customer-facing feedback portal where external users submit ideas and vote on them. Feedback collection happens through forms and integrations, not a public board. For public voting, you need a different tool: [Quackback](https://quackback.io), Canny, and Productboard all offer public-facing portals.

- [NPS Survey Template: Questions and Examples](https://quackback.io/blog/nps-survey-template): Free NPS survey templates with example questions, follow-up prompts, and distribution strategies. Calculate your score with our free NPS calculator.

Published: 2026-02-13

NPS distills customer loyalty into a single number. One question, one scale, one score. But the number itself is not the point. The follow-up — what you ask after the score, how you distribute the survey, and what you do with the results — determines whether NPS actually improves your product.

![NPS survey scale with promoter, passive, and detractor zones](/blog/nps-survey-template/hero.webp)

Most teams send the NPS question and stop there. They get a score, compare it to an industry benchmark, and move on. The score tells you how users feel. The follow-up tells you why. This guide provides complete NPS survey templates, follow-up questions for every segment, and practical advice on timing, distribution, and closing the loop.

## The NPS question

![NPS scale from 0 to 10 with detractor, passive, and promoter zones color-coded](/blog/nps-survey-template/nps-scale.webp)

The standard Net Promoter Score question is:

> "How likely are you to recommend [Product/Company] to a friend or colleague?"

Users respond on a scale of 0 to 10. Their responses place them into three groups:

- **Promoters (9-10):** Loyal users who actively recommend your product.
- **Passives (7-8):** Satisfied but not enthusiastic. Vulnerable to competitors.
- **Detractors (0-6):** Unhappy users who may discourage others from using your product.

Your NPS is calculated by subtracting the percentage of detractors from the percentage of promoters. The result ranges from -100 to +100. Use the [NPS calculator](/tools/nps-calculator) to compute your score and see how it compares to industry averages.

The question itself should not be modified significantly. Changing the wording or the scale undermines the ability to benchmark your score against other companies and against your own historical data. Where you have flexibility — and where most of the value lives — is in what you ask next.

## Follow-up questions by segment

The NPS score tells you who is happy and who is not. The follow-up question tells you what to do about it. Tailor your follow-up based on which segment the respondent falls into.

### Promoters (9-10)

Promoters already like your product. Your goal is to understand what drives their loyalty and turn that enthusiasm into something concrete — a review, a referral, or a case study.

> "What do you like most about [Product]?"

> "Which feature or aspect of [Product] has had the biggest impact on your work?"

> "Would you be willing to leave us a review on [G2/Capterra/etc.]?"

> "Is there anyone on your team who might also benefit from [Product]?"

Don't take promoters for granted. Their answers reveal what to protect and double down on. If ten promoters all mention the same feature, that feature is load-bearing — do not deprioritize it.

### Passives (7-8)

Passives are the most underserved segment. They're satisfied enough to stay, but not satisfied enough to recommend you. A small improvement could turn them into promoters. A competitor's pitch could turn them into churned users.

> "What would make you rate us a 9 or 10?"

> "What's one thing we could improve about [Product]?"

> "Is there a feature or capability you feel is missing?"

> "How does [Product] compare to other tools you've used for this purpose?"

Passive responses are a roadmap for incremental improvements. The gap between a 7 and a 9 is often specific and fixable — a missing integration, a clunky workflow, a pricing concern.

### Detractors (0-6)

Detractors have something specific to tell you. Make it easy for them. The follow-up should be open-ended enough to capture the real issue, not defensive or leading.

> "What's the main reason for your score?"

> "What could we do to improve your experience with [Product]?"

> "What was the most frustrating part of using [Product]?"

> "Would you be open to a brief conversation so we can better understand your experience?"

Detractor feedback is the most actionable feedback you will receive. It points directly at problems. Respond to it personally when possible — a human reply to a detractor can reverse their sentiment entirely.

## NPS survey templates

The NPS question and follow-up work differently depending on context. Here are four complete templates for common scenarios.

### Post-onboarding NPS

Send 7-14 days after a new user completes onboarding. This captures first impressions while the experience is fresh.

> **Question 1:** "Now that you've been using [Product] for a week, how likely are you to recommend it to a friend or colleague?" (0-10)
>
> **Question 2 (if 9-10):** "What stood out most during your first week with [Product]?"
>
> **Question 2 (if 7-8):** "What would have made your onboarding experience better?"
>
> **Question 2 (if 0-6):** "What was the biggest challenge you faced getting started with [Product]?"
>
> **Question 3 (optional):** "Is there anything else you'd like us to know?"

Post-onboarding NPS reveals whether your activation flow delivers on the promise your marketing made. A low score here often means the gap between expectation and reality is too wide. It is also the earliest signal of potential churn. Expect response rates of 20-30% when sent at the right moment during onboarding.

### Quarterly relationship NPS

Send to your entire active user base once per quarter. This is your benchmark — the score you track over time to measure overall product health.

> **Question 1:** "How likely are you to recommend [Product] to a friend or colleague?" (0-10)
>
> **Question 2:** "What's the primary reason for your score?"
>
> **Question 3 (if 9-10):** "Would you be open to sharing your experience in a short review or case study?"
>
> **Question 3 (if 0-6):** "Would you be open to a brief call so we can learn how to improve?"

Keep quarterly NPS minimal. Two to three questions maximum. The goal is a high response rate and consistent data over time. Adding extra questions lowers completion rates and makes quarter-over-quarter comparisons harder. Target a 15-25% response rate. If yours is below 10%, the survey may be reaching users at the wrong time or too frequently.

### Post-support NPS

Send within 24 hours of a support ticket being resolved. This measures whether your support experience strengthens or weakens loyalty.

> **Question 1:** "Based on your recent support experience, how likely are you to recommend [Product] to a friend or colleague?" (0-10)
>
> **Question 2 (if 9-10):** "What did our support team do well?"
>
> **Question 2 (if 7-8):** "How could we have made your support experience better?"
>
> **Question 2 (if 0-6):** "What went wrong during your support experience?"

Post-support NPS is distinct from [CSAT](/tools/csat-calculator), which measures satisfaction with the specific interaction. NPS after support tells you whether the interaction changed the user's overall perception of your product. Both are worth measuring, but they answer different questions. Expect response rates of 25-35% when sent within 24 hours of resolution.

### Feature-specific NPS

Send after a user has had meaningful exposure to a new feature — typically 2-4 weeks after launch.

> **Question 1:** "Now that you've used [Feature Name], how likely are you to recommend [Product] to a friend or colleague?" (0-10)
>
> **Question 2:** "How has [Feature Name] impacted your workflow?"
>
> **Question 3 (if 0-8):** "What would make [Feature Name] more useful for you?"

Feature-specific NPS tells you whether a new capability is moving the needle on overall loyalty. A feature that users like but doesn't lift NPS may be solving a low-priority problem. A feature that lifts NPS among a specific segment tells you where to invest next.

## When to send NPS surveys

Timing determines response rates, data quality, and whether users perceive your survey as helpful or annoying.

**After onboarding (7-14 days).** Early enough that the experience is fresh. Late enough that the user has formed a real opinion. Sending on day one captures setup frustration, not product sentiment.

**Quarterly for relationship NPS.** Once every 90 days is the standard cadence. It provides enough data points to identify trends without exhausting your users. Pick a consistent week each quarter and stick to it.

**After major interactions.** Support resolution, a large feature launch, a plan upgrade or downgrade. These moments create strong opinions — capture them while they're fresh.

**Avoid survey fatigue.** Never send NPS to the same user more than once per quarter. If a user receives a post-support NPS survey in March, exclude them from the quarterly send in March. Stack overlapping surveys and users will ignore all of them.

**Consider the day and time.** Midweek, mid-morning emails consistently get the highest open and response rates. Avoid Mondays (inbox overload) and Fridays (users are checked out). For in-app surveys, trigger them during active sessions — not at login, when users are focused on getting to their work.

## NPS survey distribution channels

How you deliver the survey affects who responds and how thoughtfully they respond.

### Email

The most common distribution method. Email works well for quarterly relationship NPS because it reaches users regardless of how active they are in your product. Include the 0-10 scale directly in the email body so users can click their score without opening a new page. One-click response significantly increases completion rates.

### In-app surveys

In-app distribution captures feedback during active use. The context is richer — the user is inside your product, experiencing it in real time. Tools like the [Quackback widget](/features/widget) let you trigger NPS surveys based on user behavior, time in product, or milestones reached. In-app surveys consistently produce higher response rates than email for active users — often 30-40% compared to 15-25% for email.

### Slack and messaging integrations

For teams that live in Slack or Microsoft Teams, delivering NPS surveys where they already work reduces friction. This works particularly well for B2B products where the buyer and user communicate through shared channels.

### Embedded in product flows

Embed NPS questions at natural pause points in your product. After completing a task, after exporting a report, after closing a project. The key is choosing moments where the user has just accomplished something and has a moment to reflect. Avoid interrupting active workflows.

## What to do with NPS results

Collecting NPS data without acting on it is a waste of everyone's time — yours and your users'. The score is a starting point, not an endpoint.

### Close the loop with respondents

Every detractor who leaves a comment should get a personal response. Not a canned email — a real reply from someone who read what they wrote and wants to help. This is the highest-leverage action you can take with NPS data. Users who feel heard often revise their opinion even before you fix the problem.

For promoters, a simple thank-you and a link to leave a review converts enthusiasm into social proof. For passives, acknowledge their feedback and let them know you are working on improvements they mentioned.

### Feed insights into your feedback system

NPS responses should not live in a spreadsheet that gets reviewed once a quarter. Route them into your [feedback board](/features/feedback) where they can be categorized, tagged, and prioritized alongside feature requests, support insights, and other input. When five detractors all mention the same pain point, that should surface as a clear priority — not get lost in a CSV.

For a deeper look at how to build this process, see our guide on [building a customer feedback loop](/blog/customer-feedback-loop).

### Track trends over time

A single NPS score is a snapshot. The trend is what matters. Track your score quarterly and segment it by user cohort, plan type, and tenure. A declining score among new users tells a different story than a declining score among long-tenured accounts. The first suggests an onboarding problem. The second suggests your product is not keeping up with expectations.

### Connect NPS to action

Map recurring themes from NPS responses to your product roadmap. If detractors consistently cite a specific gap, that gap should appear on your roadmap with a clear priority. When you ship the fix, notify the users who raised it. This closes the feedback loop and converts detractors into users who feel invested in your product's direction. Use [feature voting](/features/voting) to validate whether the themes you see in NPS data match broader user demand.

## Frequently asked questions

### What is a good NPS score?

It depends on your industry and stage. For B2B SaaS, scores above 30 are considered good. Above 50 is excellent. Above 70 is world-class. But your most useful benchmark is your own history. A score of 25 that is trending upward is healthier than a score of 40 that is declining. Focus on the trend and on the qualitative feedback behind the number.

### How many responses do I need for a reliable NPS score?

A minimum of 100 responses gives you a statistically meaningful score with a reasonable margin of error. Below that, individual outliers skew the result significantly. If your user base is small, extend the collection window or combine multiple survey periods before drawing conclusions. For larger user bases, aim for a response rate above 20% to ensure the sample represents your full user population.

### Should I use NPS or CSAT?

They measure different things. NPS measures overall loyalty and likelihood to recommend. CSAT measures satisfaction with a specific interaction or experience. Use NPS for quarterly health checks and trend tracking. Use [CSAT](/tools/csat-calculator) for evaluating specific touchpoints like support, onboarding, or feature launches. Most teams benefit from running both. For a broader look at feedback collection methods and when to use each, see our [guide to collecting customer feedback](/blog/collect-customer-feedback).

### Can I customize the NPS question?

You can add context — for example, "Based on your experience over the past 90 days..." — but avoid changing the core structure or the 0-10 scale. The standard wording exists so you can benchmark your score against industry data and track it consistently over time. If you need to measure something more specific, use a CSAT survey or a custom question alongside NPS, not instead of it. Our [user feedback guide](/blog/user-feedback-guide) covers how to combine multiple feedback methods into a coherent program.

- [How to Ask for Customer Feedback (With Templates)](https://quackback.io/blog/how-to-ask-for-customer-feedback): Templates and strategies for asking customers for feedback. When to ask, how to phrase requests, and which channels work best for different types.

Published: 2026-02-11

The way you ask for feedback determines the quality of what you get back. A vague request produces vague answers. A poorly timed request gets ignored. A request that feels like a chore produces resentful, low-quality responses — or no response at all.

![How to ask for customer feedback effectively](/blog/how-to-ask-for-customer-feedback/hero.webp)

Most teams understand that customer feedback matters. Fewer think carefully about the mechanics of asking for it. The channel, the timing, the phrasing, and the follow-up all shape what users tell you and whether they bother telling you anything at all.

This guide covers when to ask, how to phrase your requests, which channels work best, and provides copy-pasteable templates you can adapt for your product. If you are looking for a broader overview of feedback collection methods, see our [guide to collecting customer feedback](/blog/collect-customer-feedback).

> To ask for customer feedback effectively, time the request to a moment with fresh context (after onboarding, a support interaction, a feature launch, or churn), phrase one or two specific open-ended questions, and explain why you are asking. Choose the channel to match the goal: email for considered replies, in-app prompts for in-context reactions, and feedback boards for ongoing feature requests. Then close the loop so users see their input lead to change.

## When to ask for feedback

Timing matters more than most teams realize. Ask too early and users don't have enough context to give useful input. Ask too late and the experience has faded from memory. Ask at the wrong moment and you interrupt a workflow, which generates annoyance rather than insight.

![Best timing for feedback requests along the customer journey](/blog/how-to-ask-for-customer-feedback/feedback-timing-journey.webp)

Here are the moments that consistently produce the highest-quality feedback.

**After onboarding.** The first few days of using your product are when users form their strongest opinions. They notice friction that long-time users have learned to work around. Ask within the first week, while the experience is still fresh. Focus on what was confusing, what was missing, and whether they found value quickly.

**After a support interaction.** Users who just received help from your team are primed to share their experience. This is the best moment for a [CSAT survey](/tools/csat-calculator) — a quick satisfaction rating immediately after resolution. The context is specific and the feedback is actionable.

**After a feature launch.** When you ship something new, the users who try it have direct, relevant feedback about whether it solves their problem. Reach out within the first week of launch. Ask about specific aspects of the feature rather than general satisfaction.

**At renewal time.** Renewal conversations are natural feedback moments. Users are already evaluating whether your product is worth continuing to pay for. This is the right time for a broader conversation about overall satisfaction, unmet needs, and what would make the product more valuable.

**After churn.** Users who cancel have already made their decision, which paradoxically makes them more honest. They have nothing to lose by telling you the truth. Exit surveys and churn follow-ups produce some of the most actionable feedback you will ever receive. Don't skip this step because it feels uncomfortable.

## Feedback request templates

These templates are starting points. Adapt the tone and specifics to match your product and audience. Each one targets a specific moment and feedback type.

### Post-onboarding email

> **Subject: Quick question about your first week**
>
> Hi [name],
>
> You have been using [product] for about a week now. I'd like to hear how it's going.
>
> Two quick questions:
>
> 1. What was the most confusing part of getting started?
> 2. Is there anything you expected to find but didn't?
>
> No need for a detailed write-up — a few sentences is plenty. Your answers help us improve the experience for the next person who signs up.
>
> Thanks,
> [sender]

This template works because it is specific, short, and explains why you are asking. Two questions is the right number — enough to surface useful detail, few enough that users actually respond. In our experience, active users tend to respond at a modest rate, so send to a meaningful sample.

### Feature feedback prompt

> **Subject: How's [feature name] working for you?**
>
> Hi [name],
>
> We shipped [feature name] last week and I noticed you've been using it. I'd love to hear your take.
>
> - Does it solve the problem you were hoping it would?
> - Is there anything about it that feels clunky or unintuitive?
> - What would make it more useful for your workflow?
>
> Your feedback goes directly into how we iterate on this. We read every response.
>
> Thanks,
> [sender]

Targeting users who actually used the feature is key. Sending this to your entire user base dilutes the signal. Only ask people who have relevant context. Response rates tend to run higher here because the request is specific and timely.

### NPS follow-up

> **Subject: Thanks for your feedback — one more question**
>
> Hi [name],
>
> You recently rated us a [score] out of 10. Thank you for taking the time.
>
> I'm curious about the reasoning behind your score. What's the single biggest thing we could improve?
>
> If there is nothing specific, that's fine too. But if something came to mind when you chose that number, I'd genuinely like to hear it.
>
> Thanks,
> [sender]

The open-ended follow-up is where the real value of [NPS](/tools/nps-calculator) lives. The score itself is a benchmark. The follow-up response tells you what to actually do about it. Response rates for NPS follow-ups vary by segment: in our experience detractors respond more often than promoters, because they have something specific they want to say. For more NPS question examples and distribution strategies, see our [NPS survey template guide](/blog/nps-survey-template).

### Bug report follow-up

> Hi [name],
>
> The issue you reported — [brief description] — has been fixed and the update is live.
>
> Would you mind confirming it's working as expected on your end? And if there is anything else that's been frustrating you about [product area], I'd like to hear about it while we're in here making improvements.
>
> Thanks for flagging this. Reports like yours help us catch things we'd otherwise miss.
>
> [sender]

This template does double duty. It closes the loop on the original bug and opens the door for additional feedback. Users who see their reports addressed promptly are far more likely to report issues in the future.

### Churn exit survey

> **Subject: We'd like to understand why**
>
> Hi [name],
>
> We noticed you cancelled your [product] account. We're sorry to see you go.
>
> If you have 30 seconds, it would help us to know the main reason:
>
> - It didn't solve the problem I needed it to
> - Too expensive for the value
> - Switched to a different tool
> - Missing a specific feature I need
> - I no longer need this type of product
> - Other
>
> If you're open to sharing more detail, reply to this email. Every response is read by a real person.
>
> Thanks for giving us a try,
> [sender]

Keep exit surveys short. Churned users have already decided to leave — a lengthy survey won't get completed. A single multiple-choice question followed by an optional open-ended reply strikes the right balance. Response rates here are low, but even a small number of responses is valuable because churned users are unusually candid.

### In-app micro-survey

> **How would you rate your experience with [feature/area]?**
>
> [1] [2] [3] [4] [5]
>
> *(Optional)* What would make this better?

Micro-surveys work because they respect the user's time. One rating and one optional text field. Show them contextually — after a user completes a specific action, not randomly during their session. In-app widgets like the [Quackback widget](/features/widget) support this kind of contextual feedback collection without requiring users to leave what they are doing. In our experience, contextual in-app micro-surveys consistently see the highest response rates of any channel.

## Best channels for asking

The channel you choose affects who responds, how much detail you get, and how willing people are to be honest.

**Email** is best for longer, more considered feedback. Users can respond on their own schedule. Email response rates tend to be modest, so volume depends on your list size. Email works well for post-onboarding surveys, NPS follow-ups, and churn exit surveys. The limitation is that it pulls users out of context — they're remembering their experience rather than reacting to it in the moment.

**In-app prompts** capture feedback at the point of experience. Users are inside your product, interacting with the thing you want feedback on. This produces more specific, context-rich responses than email. An in-app widget lets users submit feedback, report issues, and vote on existing requests without leaving your app. In-app collection consistently gets higher response rates than any external channel.

**Feedback boards** are best for ongoing feature request collection. A public [feedback board](/features/feedback) gives users a dedicated space to submit ideas, see what others have requested, and vote on the features they want most. Boards are passive — you set them up once and users contribute on their own terms. They're less useful for measuring satisfaction or collecting bug reports, but they're the best channel for understanding feature demand at scale. Quackback is open source (AGPL-3.0), so you can put the whole team on the board — and self-host it for free or run it on [Quackback Cloud](/pricing).

**Support conversations** are an underutilized feedback channel. Every support interaction is an opportunity to ask "Is there anything else about this area of the product that's been bothering you?" Your support team already has rapport with the user and context about their issue. A natural follow-up question at the end of a resolved ticket can surface insights that no survey would capture.

**Social media** is useful for monitoring unsolicited feedback, but less effective for actively soliciting it. Users who post about your product on Twitter, Reddit, or review sites are sharing unfiltered opinions. Monitor these channels for patterns, but don't rely on them as a primary feedback collection method. The sample is too skewed toward the very happy and the very frustrated.

## How to phrase your ask

The words you choose shape the responses you get. Small changes in phrasing produce meaningfully different feedback.

**Be specific about what you want to know.** "How's everything going?" invites a shrug. "What was the most confusing part of setting up your first project?" invites a useful answer. The more specific your question, the more actionable the response. Don't ask users to do the work of figuring out what you need to hear.

**Ask open-ended questions.** Yes/no questions give you data points but no understanding. "Did you find onboarding easy?" tells you less than "What would have made onboarding easier?" Open-ended questions let users surface problems you didn't think to ask about. The best feedback often comes from questions that give users room to surprise you.

**Keep it short.** Every additional question reduces completion rates. If you're sending a survey, aim for three to five questions maximum. If you're sending an email, ask one or two things. If you need more detail, conduct an interview instead of adding questions to a survey. Respect your users' time and they'll be more willing to give it.

**Explain why you're asking.** Users respond at higher rates when they understand the purpose. "We're redesigning the onboarding flow and want to make sure we fix the right things" is more motivating than "Please take our survey." It frames the request as a collaboration rather than a chore. Tell users how their feedback will be used and they'll give you better answers.

**Avoid leading questions.** "How much do you love our new dashboard?" assumes a positive experience and makes users uncomfortable giving honest criticism. "What's your experience been with the new dashboard?" is neutral and invites honest feedback in either direction. Your goal is truth, not validation.

## What to do after you ask

Collecting feedback is the beginning, not the end. What happens after a user shares their thoughts determines whether they'll share again.

**Acknowledge every response.** Even a brief reply — "Thank you, we've logged this" — tells users their feedback was received. Silence after someone takes the time to respond is the fastest way to kill future engagement. If you use a feedback board, automatic status updates handle this at scale.

**Close the loop when you act.** When you build something a user requested, tell them. When you fix a bug someone reported, let them know. This is the single most effective way to build a culture where users actively contribute feedback. For a deeper look at building this process, see our guide on the [customer feedback loop](/blog/customer-feedback-loop).

**Use voting to prioritize.** Individual feedback requests can be hard to evaluate in isolation. When you aggregate requests on a [feedback board with voting](/features/voting), demand becomes visible. Ten separate emails asking for the same thing are hard to track. Ten votes on a single request are easy to prioritize.

**Communicate decisions publicly.** A [changelog](/features/changelog) that announces shipped features — especially ones tied to user requests — shows your entire user base that feedback leads to action. This encourages more users to contribute, even those who haven't submitted feedback before.

**Track feedback trends over time.** A single request is an anecdote. The same request appearing consistently over three months is a trend. Review your feedback regularly — weekly or biweekly — to spot emerging patterns before they become urgent problems. Quackback's [MCP server](/features/mcp) lets you query and summarize incoming feedback from an AI assistant, so you can analyze trends without leaving the tools you already use.

## Common mistakes

**Asking for feedback but never acting on it.** This is the most damaging mistake. Users who share their thoughts and never hear back stop contributing. Worse, they tell other users that providing feedback is a waste of time. If you are not ready to build a process around incoming feedback, you are better off not asking.

**Surveying at the wrong moment.** A pop-up survey that appears while a user is in the middle of completing a task generates frustration, not insight. Timing matters. Ask after a user completes an action, not during it. Ask after a support ticket is resolved, not while the user is still frustrated. The same question asked at the right moment versus the wrong one produces completely different results.

**Making feedback requests feel transactional.** Generic survey invitations that feel automated get treated accordingly — ignored or answered with minimal effort. Personalize your requests. Use the user's name. Reference their specific usage. Explain what you'll do with their input. The more it feels like a genuine conversation, the more thoughtful the response.

**Only asking promoters and ignoring detractors.** It is tempting to follow up with your happiest users because those conversations feel good. But the most valuable feedback often comes from users who are dissatisfied or who recently churned. Those conversations are harder, but they tell you what's actually broken. Make a deliberate effort to hear from the full spectrum of your user base.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How many feedback requests can I send before users get annoyed?

Limit proactive requests to about one per user per month, outside of transactional moments like a CSAT survey after a support ticket. The warning sign is declining response rates. User-initiated channels such as [feedback boards](/features/feedback) sidestep the limit entirely.

### What's the best way to ask for feedback from enterprise customers?

Enterprise customers respond better to direct, personal outreach than automated surveys. A short, specific email from their account manager, or feedback questions built into quarterly business reviews, outperforms a generic NPS blast. Give them a shared [feedback board](/features/feedback) so no single account dominates the roadmap.

### Should I offer incentives for completing feedback surveys?

Generally, no. Incentives raise response volume but lower quality, since people optimize for completion over honesty. The exception is user interviews, where a small reward fairly compensates for someone's time. For surveys, reduce friction, explain why you are asking, and [close the loop](/blog/customer-feedback-loop) instead.

### What is the best time to ask for customer feedback?

The best time is right after a moment with fresh context: within the first week of onboarding, immediately after a support interaction, soon after a feature launch, at renewal, or just after churn. Avoid interrupting an active workflow, which produces annoyance rather than insight.

### What makes a good feedback request email subject line?

A good subject line is short, specific, and signals a quick ask. Lines like "Quick question about your first week" or "How's [feature] working for you?" set clear expectations and reference the user's recent experience, which lifts open and response rates over generic "Take our survey" wording.

- [7 Best Pendo Alternatives for Feedback and Roadmaps in 2026](https://quackback.io/blog/best-pendo-alternatives): Looking for a Pendo alternative? Compare 7 feedback and roadmap tools with transparent pricing, focused feature sets, and open-source options.

Published: 2026-02-10

Pendo bundles product analytics, in-app guides, and feedback into one enterprise platform. The price reflects that scope. If you mainly need feedback collection, feature voting, and roadmapping, you're paying for capabilities you don't use.

Pendo's analytics-first design shapes everything in the product. The feedback module — Pendo Listen — sits alongside session replay, NPS surveys, funnel analysis, and guide building. For teams that need all of that, Pendo makes sense. For teams that just want users to submit ideas, vote on them, and see a public roadmap, it's significant overhead.

The pricing model reinforces this. Pendo operates on MAU-based billing. Costs grow as your active user count grows, which means a successful product launch can trigger a significant price increase. Most teams don't discover the actual cost until they're already in a sales conversation, as Pendo does not publish pricing publicly.

Seven focused alternatives handle feedback collection and roadmapping without the analytics platform overhead.

![Seven Pendo alternatives compared side by side](/blog/best-pendo-alternatives/hero.webp)

**TLDR:** The best Pendo alternatives ranked:

*Pricing last verified February 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

1. **[Quackback](https://quackback.io)** — Open source and self-hosted. Full feedback, roadmap, and changelog with AI and MCP server included.
2. **[Canny](/compare/quackback-vs-canny)** — Established feedback tool with boards, voting, and roadmaps. From $19/mo.
3. **[Productboard](/compare/quackback-vs-productboard)** — Enterprise PM suite with strategy, prioritization, and feedback. From $19/maker/mo.
4. **[UserVoice](/compare/quackback-vs-uservoice)** — Enterprise feedback platform built for large support and product teams. From $16k/year.
5. **[Featurebase](/compare/quackback-vs-featurebase)** — Lightweight feedback and changelog tool with a free plan.
6. **[Sleekplan](/compare/quackback-vs-sleekplan)** — Widget-first feedback with built-in NPS and CSAT surveys. From $13/mo.
7. **[Frill](/compare/quackback-vs-frill)** — Simple, focused feedback boards for small teams. From $25/mo.

## Why teams look for Pendo alternatives

The most common reasons teams look beyond Pendo when their primary need is feedback:

- **Enterprise pricing starts at $10k+/year.** Pendo does not publish pricing. Most customers report starting costs of $10,000–$20,000 per year for the full platform. That's difficult to justify if you're using 20% of the product.
- **Feedback is secondary to analytics.** Pendo was built as a product analytics and in-app guide platform. Feedback collection was added later. The experience reflects that — the feedback workflow is less polished than tools built for that purpose specifically.
- **MAU-based billing is unpredictable.** Costs scale with your monthly active users. A product launch or seasonal traffic spike can push you into a higher pricing tier without warning.
- **Implementation takes weeks.** Deploying Pendo requires installing the agent across your app, configuring feature tagging, training your team on the data model, and integrating with your stack. Simple feedback tools take hours, not weeks.
- **No self-hosting option.** Pendo is SaaS-only. Your data lives on Pendo's infrastructure. Teams with data residency requirements, compliance constraints, or a preference for infrastructure control have no alternative.

For a detailed breakdown of what Pendo actually costs, see our [Pendo pricing analysis](/blog/pendo-pricing).

## 1. Quackback

[Quackback](https://quackback.io) is open source (AGPL-3.0), self-hosted, and free. No feature gates based on pricing tiers.

![Quackback feedback board interface](/blog/best-pendo-alternatives/quackback.webp)

You get the full feedback workflow in a single product: [feedback boards](/features/feedback) with [voting](/features/voting), a [public roadmap](/features/roadmap), a [changelog](/features/changelog), SSO/OIDC, custom branding, and 25 integrations including Slack, Jira, Linear, GitHub, Intercom, Zendesk, and Salesforce. There's no analytics module and no in-app guide builder — Quackback does feedback, roadmaps, and changelogs, and does them well.

The AI features set Quackback apart from most tools in this category. Duplicate detection catches redundant posts before they pile up. Merge suggestions identify related requests with reasoning your team can accept or dismiss in one click. Sentiment analysis runs on every post. Summaries pull out key quotes and next steps.

The [MCP server](/features/mcp) is something no other feedback tool offers. It implements the Model Context Protocol, the standard that Claude, Cursor, and Windsurf support. Connect an AI agent and it gets full access to your feedback data: search posts, triage requests, write responses, create changelog entries, and merge duplicates. Every action is attributed and auditable.

**Key features:**
- Feature request boards with voting, status tracking, and nested comments
- Public roadmap and changelog with automatic voter notifications
- Built-in AI: duplicate detection, merge suggestions, sentiment analysis, post summaries
- MCP server for AI agents (search, triage, respond, create, merge)
- 25 integrations: Slack, Linear, Jira, GitHub, Intercom, Zendesk, Salesforce, and more
- SSO/OIDC, webhooks, full REST API
- Custom branding with themes, custom CSS, and your own domain

**Pricing:** Free and open source. Self-host with Docker or deploy on Railway at no cost.

**Pros:**
- Full-featured feedback, roadmap, and changelog in one product
- AI included at no extra cost when self-hosted (bring your own model key)
- MCP server for AI agent access
- Open source — audit the code, fork it, own your data
- 25 integrations, SSO, and custom branding included on every self-hosted installation

**Cons:**
- Self-hosted only — no managed cloud option
- You manage your own infrastructure (Docker or Railway)
- Newer project with a smaller community than Pendo

**Best for:** Teams that want open-source, self-hosted feedback with AI built in.

For a detailed side-by-side breakdown, see the [full Quackback vs Pendo comparison](/compare/quackback-vs-pendo).

---

> **Try Quackback** — open source and self-hosted. Deploy in under five minutes with Docker.
> [Get started free](/docs) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. Canny

[Canny](/compare/quackback-vs-canny) is one of the most established dedicated feedback tools on the market. It covers the standard workflow: feature request boards, voting, roadmaps, and changelogs. Teams migrating from Pendo often find Canny familiar — it handles feedback well without the analytics overhead.

![Canny feedback board interface](/blog/best-pendo-alternatives/canny.webp)

The Core plan starts at $19/mo (billed annually) for 100+ tracked users. Canny moved to tracked-user pricing in May 2025, which means costs grow as more of your users submit posts, vote, or comment. Autopilot — Canny's AI layer for deduplication, categorization, and summarization — is included across all plans. PM integrations like Jira, Linear, and ClickUp require the Pro plan ($79/mo).

Canny is closed source with no self-hosting option. For teams switching from Pendo specifically because of vendor lock-in or data sovereignty concerns, that's worth noting. But for teams that want a polished hosted tool with a known brand and a track record, Canny is a solid step down from Pendo's complexity and price.

**Key features:**
- Feedback boards with voting, tags, and custom statuses
- Public roadmap with status-based filtering
- Changelog with scheduled posts and email notifications
- Autopilot AI for deduplication, categorization, and summarization (all plans)
- Integrations: Jira, Linear, GitHub, Intercom, Zendesk, Salesforce, Slack (Pro+)

**Pricing:** Free (25 tracked users). Core at $19/mo. Pro at $79/mo. Business is custom.

**Pros:**
- Established product with a long track record
- Autopilot AI included on all plans
- Polished UI with a clean public-facing board
- Well-documented and easy to set up

**Cons:**
- Tracked-user billing can be unpredictable at scale
- Free plan caps at 25 tracked users
- PM integrations require the Pro plan ($79/mo)
- No self-hosting, no open source

**Best for:** SaaS teams wanting a polished, hosted feedback tool without Pendo's analytics overhead.

See how it compares: [Quackback vs Canny](/compare/quackback-vs-canny).

## 3. Productboard

[Productboard](/compare/quackback-vs-productboard) is a product management platform, not just a feedback tool. It connects customer insights to product strategy through opportunity scoring, prioritization matrices, and driver-based roadmaps. Teams coming from Pendo that want to retain some of the strategic product tooling — but without the in-app guide and analytics components — often consider Productboard as a middle ground.

![Productboard product management interface](/blog/best-pendo-alternatives/productboard.webp)

Where Pendo leans on behavioral analytics to inform product decisions, Productboard leans on structured insight capture and prioritization frameworks. Deep integrations with Jira, Salesforce, Zendesk, and Intercom let you pull feedback from across your stack and link it to features and objectives. The Spark plan costs $15/maker/month (annual) or $19/maker/month (monthly).

The trade-off is complexity. Productboard has a steeper learning curve than most tools on this list. For teams that just want a feedback board and a roadmap, it's overkill. But for product organizations that need to align multiple teams around priorities, score features by business impact, and tie roadmaps to company objectives, it's a well-designed platform.

**Key features:**
- Insights portal for collecting and organizing customer feedback
- Feature prioritization with custom scoring frameworks
- Driver-based roadmaps tied to company objectives
- Deep Jira, Salesforce, Zendesk, and Intercom integrations
- AI included via credits (250/maker/month) for summarization and insight extraction

**Pricing:** Spark at $15/maker/month (annual) or $19/maker/month (monthly). Enterprise is custom.

**Pros:**
- Deep product management features beyond feedback
- Strategy-level roadmapping tied to business objectives
- Strong integrations with enterprise tools
- AI included in the base plan via credits
- Established company with a large customer base

**Cons:**
- Steep learning curve
- AI credits (250/maker/month) may be limiting for heavy users
- Overkill for simple feedback collection
- No self-hosting
- Per-maker pricing grows with team size

**Best for:** Product organizations that need strategy, prioritization, and roadmapping tools beyond basic feedback.

See how it compares: [Quackback vs Productboard](/compare/quackback-vs-productboard).

## 4. UserVoice

[UserVoice](/compare/quackback-vs-uservoice) is the enterprise-tier alternative on this list. It's built for large organizations with dedicated support teams, product managers, and complex internal workflows. Like Pendo, it sells through a sales process with custom pricing — starting around $16,000/year — and targets the same enterprise buyer profile.

![UserVoice feedback platform interface](/blog/best-pendo-alternatives/uservoice.webp)

Where Pendo emphasizes analytics and in-app guidance, UserVoice emphasizes structured feedback capture at scale. Customer feedback comes in from multiple channels — support tickets, sales calls, direct submission — and gets organized, tagged, and linked to product ideas. Internal stakeholders can submit feedback on behalf of customers. Product managers use built-in prioritization tools to evaluate which requests to build.

The platform is deeply integrated with Salesforce and Zendesk, making it popular with enterprise support organizations. Implementation takes time — similar to Pendo — and the per-year pricing puts it out of reach for smaller teams. If budget is the reason you're leaving Pendo, UserVoice is not a downgrade in cost.

**Key features:**
- Multi-channel feedback capture (portal, widget, API, internal submission)
- Idea management with voting, prioritization scoring, and status tracking
- Internal stakeholder collaboration on feature requests
- Salesforce and Zendesk integrations
- NPS and satisfaction surveys
- Custom reporting and analytics dashboards

**Pricing:** Starts at approximately $16,000/year. Custom pricing based on users and features.

**Pros:**
- Built for enterprise-scale feedback workflows
- Strong support team integrations (Salesforce, Zendesk)
- Internal stakeholder feedback capture
- Mature platform with a long track record

**Cons:**
- Very expensive — starts around $16k/year
- No self-hosting, no open source
- Implementation is slow (similar to Pendo)
- Overkill for most non-enterprise teams
- No public pricing transparency

**Best for:** Large enterprises with dedicated product and support teams managing feedback at scale.

See how it compares: [Quackback vs UserVoice](/compare/quackback-vs-uservoice).

## 5. Featurebase

[Featurebase](/compare/quackback-vs-featurebase) bundles feedback boards, a changelog, a roadmap, help docs, and a support inbox into one product. It has a free plan — one seat, limited features — which makes it an accessible starting point for smaller teams that don't want to self-host and aren't ready for a paid subscription.

![Featurebase feedback board interface](/blog/best-pendo-alternatives/featurebase.webp)

The contrast with Pendo is stark. Featurebase is focused, fast to set up, and transparent about pricing. You don't need to sit through a sales call to get started. The tradeoff is depth — Featurebase doesn't offer product analytics, in-app guides, or the kind of strategic prioritization tooling that Pendo provides.

The AI agent, Fibi, auto-resolves customer questions using context from your help center, feedback posts, and past conversations. It can also submit feature requests on behalf of users. Fibi charges $0.49 per resolution on top of your plan, which adds up at volume. Per-seat pricing ($29–99/seat/month on paid plans) means costs grow with your team size.

**Key features:**
- Feedback boards with voting, status tracking, and user segmentation
- Changelog, public roadmap, and surveys (NPS, CSAT)
- Unified support inbox with live chat and email
- Fibi AI Agent for auto-resolving questions ($0.49/resolution)
- 12 integrations: Linear, Jira, GitHub, Slack, Intercom, Zendesk, and more

**Pricing:** Free (1 seat, limited). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- Free tier available for getting started
- All-in-one: feedback, support, help docs in one product
- Surveys (NPS, CSAT) included
- Fast to set up — no sales process required

**Cons:**
- Per-seat pricing adds up for larger teams
- AI resolutions are usage-based ($0.49 each)
- No self-hosting, no open source
- Post merging locked to Business tier

**Best for:** Small teams wanting a free hosted option with feedback, support, and changelog combined.

See how it compares: [Quackback vs Featurebase](/compare/quackback-vs-featurebase).

## 6. Sleekplan

[Sleekplan](/compare/quackback-vs-sleekplan) takes a widget-first approach to feedback. Instead of directing users to a separate portal, Sleekplan embeds directly into your app as an in-app widget. Users submit feedback, vote on ideas, read your changelog, and respond to satisfaction surveys without leaving your product.

![Sleekplan feedback widget interface](/blog/best-pendo-alternatives/sleekplan.webp)

Teams leaving Pendo for Sleekplan are typically trading the analytics depth for simplicity and lower cost. Sleekplan doesn't do session replay, funnel analysis, or feature tagging. It handles in-app feedback collection and satisfaction measurement — the two things most teams actually use in Pendo's feedback module.

The built-in NPS and CSAT surveys are a differentiator. Most dedicated feedback tools treat surveys as a separate concern. Sleekplan includes them natively alongside the feedback board and changelog. The free Indie plan is limited (one seat, no roadmap, no surveys, no AI). The Starter plan at $13/mo unlocks the roadmap, surveys, and AI features.

**Key features:**
- Feedback board with voting, status updates, and impact scoring
- Changelog with scheduled posting and subscriber notifications
- Roadmap (Starter plan and above)
- Built-in NPS and CSAT surveys
- Embeddable in-app widget, standalone site, or iframe
- 12 integrations: Jira, Linear, Slack, Intercom, GitHub, Zapier, and more

**Pricing:** Free Indie plan (1 seat, limited). Starter at $13/mo. Business at $38/mo. Enterprise is custom.

**Pros:**
- In-app widget reduces friction for feedback submission
- Built-in NPS/CSAT surveys included natively
- Affordable paid plans starting at $13/mo
- Free tier available

**Cons:**
- Free plan is very limited (no roadmap, no surveys, no AI)
- Widget-first means the standalone portal is less polished
- Post merging requires Business plan ($38/mo)
- No self-hosting, no open source
- Much narrower scope than Pendo

**Best for:** Teams that want in-app feedback collection and satisfaction surveys without a full analytics platform.

See how it compares: [Quackback vs Sleekplan](/compare/quackback-vs-sleekplan).

## 7. Frill

[Frill](/compare/quackback-vs-frill) is a simple, focused feedback board tool. You get a public board where users submit and vote on ideas, a basic roadmap view, and a changelog. There are no AI features, no in-app analytics, and no complex prioritization frameworks. It does one thing and keeps it straightforward.

![Frill feedback board interface](/blog/best-pendo-alternatives/frill.webp)

For indie developers, solo founders, or very small teams, Frill is one of the easiest tools to get running. Setup takes minutes. The pricing is flat: $25/mo for the Startup plan, $49/mo for the Business plan. No per-user billing, no MAU-based tiers, no sales process. You know exactly what you're paying.

The limitation is scope. Frill doesn't offer integrations with tools like Jira, Linear, or Zendesk on the entry plan. The changelog is basic. There are no AI features for duplicate detection or sentiment analysis. If you're coming from Pendo, you'll notice what's missing. But if Pendo was overkill, Frill may be exactly the right size.

**Key features:**
- Feedback board with voting and custom statuses
- Public roadmap view
- Changelog
- SSO on Business plan and above
- Integrations: Zapier, webhooks (Startup). Jira, Slack, and more on Business.
- Custom domain and branding

**Pricing:** Startup at $25/mo (50 ideas). Business at $49/mo (unlimited). Growth at $149/mo. Enterprise from $349/mo.

**Pros:**
- Flat-rate pricing — no per-user surprises
- Simple to set up and operate
- Clean, uncluttered UI
- No sales process required

**Cons:**
- Limited integrations on the entry plan
- No AI features
- No self-hosting, no open source
- Less active development compared to alternatives
- No duplicate detection or post merging

**Best for:** Indie hackers and small teams that want a simple, flat-rate feedback board with no complexity.

See how it compares: [Quackback vs Frill](/compare/quackback-vs-frill).

## Comparison table

Here's how all seven alternatives stack up against Pendo on the features that matter for feedback workflows.

| | Pendo | Quackback | Canny | Productboard | UserVoice | Featurebase | Sleekplan | Frill |
|---|---|---|---|---|---|---|---|---|
| **Starting price** | ~$10k+/year | Free | Free (25 tracked users) | $15/maker/mo | ~$16k/year | Free (1 seat) | Free (1 seat) | $25/mo |
| **Open source** | No | Yes (AGPL-3.0) | No | No | No | No | No | No |
| **Self-hosting** | No | Yes | No | No | No | No | No | No |
| **AI features** | Yes (analytics-focused) | Yes (built in) | Autopilot (all plans) | Credits (250/maker/mo) | Limited | Fibi ($0.49/resolution) | Starter plan+ | No |
| **Changelog** | No | Yes | Yes | No | No | Yes | Yes | Yes |
| **Public pricing** | No | Yes (free) | Yes | Yes | No | Yes | Yes | Yes |
| **MAU/user limits** | MAU-based billing | None | 25 tracked (Free) | None (Spark) | Custom | None on free | None | None |

## How to choose

Start with your actual requirements. Most teams switching from Pendo are doing so because the price-to-value ratio is off — they're using the feedback module and not much else.

**If cost is the priority:** Quackback is free to self-host with no MAU limits. Among hosted options, Sleekplan ($13/mo) and Frill ($25/mo) are the most affordable. Both have transparent, flat-rate pricing with no sales process.

**If you want open source:** Quackback is your option. It covers the full feedback workflow — boards, roadmap, changelog, 25 integrations, AI, MCP server — and deploys with Docker. You own your data and your infrastructure.

**If you need enterprise-scale feedback:** UserVoice is the closest enterprise equivalent to Pendo's feedback module, without the analytics overhead. It's expensive, but it handles the complexity of large-scale feedback programs. Productboard is a better fit if you need strategic roadmapping tied to company objectives.

**If you want quick setup:** Featurebase, Sleekplan, and Frill all get you running in under an hour with no sales process. Canny is also fast and has the most polished onboarding among the established tools.

**If you need in-app feedback:** Sleekplan's widget-first design is the best choice for collecting feedback inside your product. Pendo's in-app approach is one of its genuine strengths — Sleekplan provides a focused version of that without the analytics platform.

**If you're migrating from Pendo:** The most common reasons teams leave Pendo are MAU-based pricing, analytics-first complexity, and long implementation timelines. Quackback addresses all three — it's free, focused on feedback, and deploys in under five minutes.

For a broader view of the feedback tool landscape, see [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026), [Open Source Feedback Tools](/blog/open-source-feedback-tools), and our [feedback tool pricing comparison](/blog/feedback-tool-pricing-comparison).

## Frequently asked questions

### What is the best free alternative to Pendo for feedback?

[Quackback](https://quackback.io) is the most full-featured free alternative for feedback and roadmapping. It's open source (AGPL-3.0), self-hosted, and includes feedback boards, voting, a public roadmap, a changelog, 25 integrations, SSO/OIDC, and built-in AI features. Among hosted tools, Featurebase and Sleekplan both offer limited free tiers that cover the basics.

### Is Pendo worth it for teams that only need feedback?

Rarely. Pendo's value comes from combining product analytics, in-app guides, and feedback in one platform. If you only use the feedback module, you're paying for two-thirds of the product you don't use. Most dedicated feedback tools — Canny, Featurebase, Quackback — cover feedback, voting, roadmaps, and changelogs at a fraction of the cost and with a simpler setup.

### Can I replace Pendo's in-app guides with a cheaper tool?

Pendo's in-app guide builder is a distinct product category from feedback tools. If you need in-app guides — onboarding flows, tooltips, announcements — you'll need a separate tool after leaving Pendo. Tools like Appcues or Userflow specialize in in-app guidance. The alternatives on this list focus on feedback collection and roadmapping, not in-app guide creation.

### How long does it take to switch from Pendo to a feedback-focused tool?

Most dedicated feedback tools — Canny, Featurebase, Sleekplan, Frill — take a day or less to set up. Quackback self-hosting takes under an hour with Docker. The main migration work is exporting your existing feedback data from Pendo and re-importing it. Pendo allows data export, though the process varies depending on your contract. The longer your Pendo history, the more data you'll need to move.

- [Introducing Quackback: open-source feedback with AI agents](https://quackback.io/blog/welcome): Quackback is an open-source feedback platform with AI agent access built in. Self-host it free or use Quackback Cloud. Voting, roadmaps, changelogs, MCP.

Published: 2026-02-09

Quackback is an open-source feedback platform. It gives you [voting boards](/features/voting), a [public roadmap](/features/roadmap), [changelogs](/features/changelog), and [a full set of integrations](/integrations), the same workflow that tools like Canny and UserVoice established, but open source and with AI agent access built in.

> **Quackback** is an open-source (AGPL-3.0) customer feedback platform with voting boards, public roadmaps, changelogs, and an [MCP server](/features/mcp) that lets AI agents triage and respond to feedback. Self-host it free with no feature gates, or run it on [Quackback Cloud](/pricing) without managing infrastructure. Cloud plans differ on seats and entitlements.

## Why feedback tools need an open-source alternative

UserVoice starts at $16,000 per year with annual billing. Canny's free plan caps at 25 tracked users, and meaningful features like PM integrations require their paid plans. Productboard is similar. These tools got the collection model right. But they're all closed-source, expensive at scale, and there's no option to self-host. No way to extend them. No path to complete data sovereignty for those who need it.

At the same time, development workflows are accelerating. AI agents help write code, review pull requests, and ship faster than ever. But customer feedback is still stuck in a manual loop. Triaging, responding, updating status, notifying voters when something ships. For most teams, that work doesn't scale.

[Plausible](https://plausible.io) brought open source to web analytics. [Cal.com](https://cal.com) did it for scheduling. [Formbricks](https://formbricks.com) did it for surveys. [PostHog](https://posthog.com) did it for product analytics. Feedback collection hasn't had an equivalent. Until now.

![Quackback feedback board](/blog/welcome/quackback-board.webp)

You can try it locally in under a minute:

```bash
git clone https://github.com/QuackbackIO/quackback.git
cd quackback && bun run setup && bun run dev
```

## Agents as part of the feedback loop

This is the part of Quackback that doesn't exist anywhere else.

Quackback ships with an [MCP server](/features/mcp), the same Model Context Protocol that Claude, Cursor, and Windsurf already support. Connect an agent and it gets real access to your feedback data. Not read-only. Not a summary. Actual ability to act.

An agent connected to Quackback can:

- **Search** across all feedback posts and changelogs
- **Triage** posts: update status, assign owners, add tags, write official responses
- **Create** new posts and changelog entries
- **Comment** and **vote** on behalf of your team

Every action is attributed. Every decision is auditable. When an agent triages a post, you see which agent did it, when, and what it changed. You stay in control. The agent handles the volume.

The practical effect: a solo founder or a team of three can respond to feedback like a team of ten. Posts that would sit unread for weeks get triaged in hours. Users who report bugs get a response the same day.

## Open source. Self-host. Own your data.

Quackback is [AGPL-3.0](https://github.com/QuackbackIO/quackback/blob/main/LICENSE) licensed. The code is public. You can read every line, audit every dependency, and run it on your own infrastructure.

Self-host with Docker or deploy in one click on Railway. Your feedback data stays in your PostgreSQL database. Not on my servers. Not behind an API you don't control.

No vendor lock-in. No feature gates.

## What ships today

**For your users:** Public feedback boards with voting, status tracking, nested comments, and official responses. A public roadmap so they can see what's planned, in progress, and shipped. A changelog that links back to the posts that requested each feature.

**For your team:** An [admin inbox](/features/inbox) with unified triage, filtering, bulk actions, and automatic deduplication. Two-way sync with your issue tracker so status stays current across tools. [SSO and OIDC](/features/sso) for enterprise authentication.

**For your stack:** Integrations including Slack, Linear, Jira, GitHub, GitLab, Asana, ClickUp, Intercom, Zendesk, HubSpot, Freshdesk, Salesforce, Discord, Teams, Notion, Monday, Trello, Shortcut, Azure DevOps, Zapier, Make, n8n, and Stripe. [Full API](/features/api) access, webhooks, and the MCP server for agents. Custom branding with your logo, colors, and domain.

## Pricing

The self-hosted version of Quackback is free and includes the core platform: feedback boards, roadmap, changelog, integrations, API, and MCP server. Everything you need to run your feedback loop.

Over time, I plan to introduce enterprise-specific features (things like audit logs, advanced SSO configurations, and team management controls) as part of a paid tier. I want to be upfront about that. Keeping Quackback sustainable means some features built for larger organizations will help fund development for everyone.

[Quackback Cloud](/pricing) is live for teams that don't want to run their own infrastructure. Paid plans are a flat workspace price from $29/mo on annual billing, with 5 seats on Pro. Portal users are free. Quinn is included on paid plans, with $10 top-up packs if you need more. There is a 14-day free trial with no card required. You get automatic updates, backups, and uptime monitoring, without managing your own servers.

## What's next

- **Import tools**: Migrate from Canny and UserVoice with your data intact
- **Agent workflows**: Automated triage, AI-powered deduplication, and feedback summarization so every post gets a response without manual effort

## Learn more

If you want to see how Quackback stacks up against existing tools, start with our [best customer feedback tools in 2026](/blog/best-customer-feedback-tools-2026) roundup or the side-by-side [comparison pages](/compare). For teams interested in self-hosting and data ownership, see our guide to [open source feedback tools](/blog/open-source-feedback-tools).

## Get involved

Quackback is on GitHub at [QuackbackIO/quackback](https://github.com/QuackbackIO/quackback).

I'd especially like feedback on the MCP server. Giving agents access to user feedback is new territory, and I'm shaping the interface based on how people actually use it. Follow the [MCP setup guide](/docs) to connect your agent, then tell me what's missing.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Is Quackback really free?

Yes. The self-hosted version of Quackback is free and open source under AGPL-3.0. It includes feedback boards, roadmaps, changelogs, integrations, the full API, and the MCP server. [Quackback Cloud](/pricing) adds managed hosting on paid workspace plans from $29/mo, with a 14-day free trial.

### How is Quackback different from Canny and UserVoice?

Quackback is open source and self-hostable, so you own your data and avoid feature gates. It also ships an MCP server that lets AI agents triage and respond to feedback. See [Quackback vs Canny](/compare/quackback-vs-canny) and [Quackback vs UserVoice](/compare/quackback-vs-uservoice).

### What does the MCP server let AI agents do?

The [MCP server](/features/mcp) gives AI agents real access to your feedback: search posts and changelogs, update status, assign owners, add tags, write official responses, and create posts. Every action is attributed and auditable, so you stay in control.

### Can I self-host Quackback?

Yes. Self-host Quackback with Docker or deploy in one click on Railway. Your feedback data stays in your own PostgreSQL database. The code is public under AGPL-3.0, so you can audit every dependency and run it on your own infrastructure.

### Does Quackback have a managed cloud?

Yes. Quackback Cloud is live now. Plans are billed per workspace from $29/mo with a 14-day free trial, and include automatic updates, backups, and uptime monitoring. See the [pricing page](/pricing) for current tiers.

- [Intercom Pricing in 2026: Plans, Seat Costs, and the Fin AI Add-On](https://quackback.io/blog/intercom-pricing): Intercom pricing breakdown for 2026: per-seat plan costs, Fin AI agent per-resolution pricing, add-ons, and when a separate feedback tool makes more sense.

Published: 2026-02-08

Intercom is a customer communications platform that combines live chat, a shared inbox, AI-powered support, and a help center. It sits at the intersection of customer support and engagement — not a pure ticketing tool like Zendesk, and not a product management platform. Teams use it to handle support conversations, run in-app messaging, and increasingly, to deflect volume with Fin, Intercom's AI agent.

Pricing has changed substantially over the past few years. Intercom moved to a seat-based model in 2023 and has layered Fin AI on top as a per-resolution add-on. What you pay depends on how many support seats you need and how much of your volume Fin handles.

![Intercom pricing plans and Fin AI costs](/blog/intercom-pricing/hero.webp)

> Intercom uses per-seat pricing: $29/seat/mo on Essential, $85/seat/mo on Advanced, and $132/seat/mo on Expert (annual billing). The Fin AI agent costs $0.99 per resolution on top of your base plan, so your bill scales with both headcount and support volume. If you need feature request tracking and a product roadmap alongside Intercom, [Quackback](/integrations/intercom) integrates directly — open source, free to self-host, with built-in AI.
>
> *Pricing last verified February 2026. Vendors may change plans and pricing without notice. Check Intercom's pricing page for the latest figures.*

## Intercom pricing plans

Intercom offers three plans for its core platform. All prices are per seat per month, billed annually. Monthly billing is available at higher rates.

| Plan | Price (Annual) | Key Features |
|------|---------------|--------------|
| **Essential** | $29/seat/mo | Shared inbox, live chat, basic automation, help center, messenger, email, in-app messages, basic reporting |
| **Advanced** | $85/seat/mo | Everything in Essential plus AI-powered workflows, custom bots, advanced automation, SLAs, assignment rules, CSAT surveys, multiple team inboxes, custom reports |
| **Expert** | $132/seat/mo | Everything in Advanced plus Workload management, real-time reporting dashboard, SSO/SAML, custom roles and permissions, advanced security, priority support |

**Essential** covers the fundamentals: a shared inbox, live chat via the Intercom Messenger, a help center for self-service, and basic automation rules. It is the entry point for teams that need a managed support inbox and customer-facing chat without the deeper workflow tooling.

**Advanced** is where most growing support teams land. It adds AI-powered workflows, custom bots that can handle conversations before routing to humans, SLAs, assignment rules, CSAT collection, and custom reporting. The workflow builder on this tier lets you automate handoffs, tagging, and escalations in ways the Essential plan does not support.

**Expert** adds the operational and security features that matter at scale: workload management for balancing queue distribution across agents, real-time dashboards, SSO/SAML, and granular role-based access control. SSO is locked to Expert — any team with a security policy requiring SSO must be on the $132/seat/mo plan.

## Fin AI agent pricing

Fin is Intercom's AI support agent. It reads your help center content and conversation history, handles inbound queries autonomously, and only escalates to a human agent when it cannot resolve the issue.

Fin is priced at **$0.99 per resolution**. A resolution is counted when Fin handles a conversation end-to-end without human intervention — typically when the customer's question is answered and the conversation closes without escalation.

Conversations that Fin starts but does not resolve (it escalates to a human) are not charged as resolutions. You pay for successful deflections, not attempts.

Here is how Fin costs scale by monthly resolution volume:

| Monthly Resolutions | Fin AI Cost | Notes |
|--------------------|-------------|-------|
| 500 | $495/mo | Low-volume support team |
| 1,000 | $990/mo | Mid-size team with moderate automation |
| 5,000 | $4,950/mo | High-volume or scaled operation |
| 10,000 | $9,900/mo | Large team with significant deflection |

The per-resolution model is straightforward to understand but harder to budget. Your Fin costs are directly tied to your support volume, which fluctuates. A product launch, a service incident, or seasonal demand can spike resolutions in a given month. Teams with variable support volume should build buffer into their Fin budget.

Fin is available on all three plans. You enable it on your account and connect it to your help center content. Resolution billing starts immediately when Fin begins handling conversations.

![Monthly cost breakdown for a 25-seat Intercom Advanced team showing Fin AI resolution costs stacking on top of per-seat base costs](/blog/intercom-pricing/intercom-seat-plus-ai-cost.webp)

## Per-seat costs at scale

Base plan costs grow linearly with seat count. Here is what each plan costs annually for common team sizes.

| Seats | Essential ($29/seat/mo) | Advanced ($85/seat/mo) | Expert ($132/seat/mo) |
|-------|------------------------|------------------------|----------------------|
| **5** | $1,740/yr | $5,100/yr | $7,920/yr |
| **10** | $3,480/yr | $10,200/yr | $15,840/yr |
| **25** | $8,700/yr | $25,500/yr | $39,600/yr |
| **50** | $17,400/yr | $51,000/yr | $79,200/yr |

These figures cover the base plan only. Add Fin AI resolutions on top to get the full picture. At 25 seats on Advanced with 1,000 monthly Fin resolutions, your combined annual cost is approximately $25,500 (seats) + $11,880 (Fin) = $37,380/yr.

## Add-ons and extras

Beyond the base plans and Fin AI, Intercom offers several add-ons that extend functionality at extra cost.

**Proactive Support Plus** adds advanced in-app messaging features: product tours, push notifications, checklists, and banners. This is relevant for teams that want to use Intercom for onboarding and in-product engagement, not just support. Pricing is not published publicly and is quoted based on MAU volume.

**Product Tours** is a specific add-on for building step-by-step in-app walkthroughs. It is available separately from Proactive Support Plus if you only need guided tours without the full messaging suite.

**WhatsApp** integration is available as an add-on on Advanced and Expert plans. It routes WhatsApp conversations into the shared inbox alongside other channels. There is a per-conversation charge from Meta that applies in addition to any Intercom fees.

**SMS** is another channel add-on. It allows outbound and inbound SMS through the Intercom inbox. Pricing is per message and varies by country.

**Additional seats** beyond the seats included in your plan are charged at the per-seat rate for your tier. If you are on Advanced and add a seat mid-contract, the additional seat is prorated for the remainder of your billing period.

The add-on model means your actual Intercom bill can differ meaningfully from the base plan price. Factor in which channels you need and whether Proactive Support or Product Tours fits your use case before committing to a plan.

## What Intercom does well

Intercom has built a strong platform for customer-facing communication. Its core strengths are well-established.

**Messenger and live chat.** The Intercom Messenger is polished and highly configurable. It handles live chat, automated bots, and self-service help center access in a single widget. It is one of the most widely recognized in-app support experiences in SaaS.

**Shared inbox.** The inbox consolidates conversations across channels — chat, email, WhatsApp, SMS — in one place. Agents can see the full conversation history, customer data, and context from your product or CRM without leaving the inbox.

**Fin AI agent.** Fin is among the better AI support agents available. It uses your help center and conversation data to resolve queries autonomously, and the per-resolution pricing aligns cost with value delivered.

**Help center.** Intercom includes a built-in help center for self-service content. You can publish articles, organize them into collections, and surface them automatically in the Messenger before a user starts a conversation.

**Automation and bots.** Custom bots and the workflow builder let you automate routing, tagging, escalation, and initial triage. Advanced and Expert plans unlock the deeper automation rules these workflows depend on.

**Customer data.** Intercom stores conversation history, user attributes, and behavior events. This context shows up in the inbox alongside conversations, so agents know who they are talking to and what they have done in your product.

## What Intercom doesn't do

Intercom is built for customer support and messaging. It is not a product management platform, and it does not try to be.

**Feature request tracking with voting.** Intercom has no structured way to capture, organize, and prioritize feature requests. Customers may mention requests in support conversations, but there is no built-in mechanism to surface, deduplicate, and rank them.

**Public roadmaps.** There is no customer-facing roadmap view where users can see what you are building and follow progress. Intercom does not publish or manage roadmap state.

**Changelogs.** Intercom does not have a product changelog — a structured record of what shipped and when, visible to customers. Announcing releases requires email campaigns or in-app messages built manually each time.

**Feedback-to-roadmap workflow.** The loop from "customer mentioned this in a support conversation" to "this is now a tracked feature request with votes and roadmap status" does not exist in Intercom. Support conversations generate signal, but there is no structured workflow to capture and act on that signal.

**Structured prioritization.** Intercom does not rank feedback, score requests, or give product teams a view of what customers want most. That workflow belongs in a separate product tool.

These gaps are not weaknesses — they reflect the product's intentional scope. Intercom is built for the support team, not the product team. The right answer is not to replace Intercom but to connect it to tools that cover what it does not.

## Pairing Intercom with a feedback tool

Intercom generates a large volume of product signal. Every support conversation contains potential feature requests, pain points, and workflow descriptions. Without a structured way to capture that signal, it stays trapped in the inbox.

[Quackback's Intercom integration](/integrations/intercom) bridges this gap. Support conversations can surface as feedback submissions in Quackback's boards. When a customer mentions a feature request in Intercom, that request flows into Quackback where it can be voted on, categorized, and tracked through to the [public roadmap](/features/roadmap).

The cost model is also different. Quackback is **open source** (AGPL-3.0) and **self-hosted free**, with a managed [Quackback Cloud](/pricing) option if you would rather not run it yourself. Adding product managers, founders, or stakeholders does not raise your bill the way Intercom seats do. AI analysis is **built in**, so you avoid the per-resolution metering that makes Fin costs hard to budget. For agentic workflows, the [MCP server](/features/mcp) lets AI tools read and act on your feedback directly.

The workflow is complementary by design. Your support team continues working in Intercom — they handle conversations, manage the inbox, and use Fin AI as they normally would. The Quackback integration runs alongside that workflow without requiring agents to switch tools. When a conversation contains a feature request, it is captured in Quackback automatically or with a single action from the agent.

On the product side, the team works in Quackback. They see incoming feedback from Intercom conversations alongside requests from other channels — your website feedback widget, email, direct submissions. Everything aggregates in one place. Requests can be reviewed, merged with duplicates, assigned roadmap status, and communicated back to customers through a public roadmap and changelog.

The support team stays in Intercom. The product team works in Quackback. The feedback from support conversations becomes structured input to product decisions. See [Quackback's feedback features](/features/feedback) for how the ingestion and tracking workflow operates.

If you are evaluating how Intercom fits into a broader toolset, see [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026) and [Feedback Tool Pricing Comparison](/blog/feedback-tool-pricing-comparison) for context on the wider category.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How much does Intercom cost per seat?

Intercom costs $29/seat/mo on Essential, $85/seat/mo on Advanced, and $132/seat/mo on Expert, all billed annually. Monthly billing costs more. Fin AI adds $0.99 per resolution on top of any plan, so a 10-seat Advanced team handling 500 Fin resolutions monthly pays roughly $16,140/yr combined.

### What is a Fin AI resolution and how is it billed?

A Fin AI resolution is a support conversation Fin handles end-to-end without a human stepping in, counted when the conversation closes after Fin's response. Each resolution costs $0.99. Conversations Fin escalates to a human are not billed. Because costs track support volume, monthly budgeting is harder than fixed-seat pricing.

### Does Intercom include SSO?

SSO/SAML is only available on the Expert plan at $132/seat/mo. Essential and Advanced do not include it. If your organization requires SSO for security or compliance, you must budget for Expert pricing across every support seat, a common cost driver for teams that start on Advanced.

### Does Intercom handle feature requests and product roadmaps?

No. Intercom is a messaging and support platform with no built-in feature request boards, voting, or public roadmaps. Support conversations generate product signal, but Intercom has no workflow to capture or prioritize it. Teams pair Intercom with a dedicated feedback tool like [Quackback](/integrations/intercom) to close that loop.

- [The Customer Feedback Loop: How to Close It and Why It Matters](https://quackback.io/blog/customer-feedback-loop): How to build and close customer feedback loops. Collect, analyze, act, and communicate — four stages that turn user input into product improvement.

Published: 2026-02-07

Most teams collect feedback. Few close the loop.

![The four stages of a customer feedback loop](/blog/customer-feedback-loop/hero.webp)

The pattern is familiar. You set up a feedback widget, launch a survey, or create a feature request board. Submissions pour in. Some get read. A few get discussed. But the person who submitted the idea rarely hears what happened to it. Did you build it? Did you decide against it? Did anyone even read it?

When users feel ignored, they stop contributing. The feedback dries up. You lose the most valuable input your product team has — direct signal from the people who use your product every day. Not because they stopped having opinions, but because they stopped believing those opinions mattered to you.

Closing the feedback loop fixes this. It means taking every piece of input through a full cycle: collection to analysis to action to communication. It turns feedback from a one-way channel into a conversation. And it is the single most reliable way to build a product culture where users actively help you make better decisions.

> **A customer feedback loop closes when users see their input reflected in your product.** You close it by carrying every piece of feedback through four stages: collect, analyze, act, and communicate. The communication stage is the one most teams skip, and it is the one that turns feedback into a conversation, lifts retention, and improves the quality of what users send you next.

## What is a customer feedback loop?

A customer feedback loop is a structured process for turning user input into product improvement and communicating that improvement back to the users who requested it. It has four stages.

**Collect** — Gather feedback from users through multiple channels. Boards, widgets, surveys, support conversations, interviews.

**Analyze** — Organize, categorize, and prioritize what you've collected. Find patterns. Separate signal from noise.

**Act** — Make product decisions based on what you learned. Build features, fix bugs, adjust priorities.

**Communicate** — Tell users what you did and why. Announce changes. Notify people whose requests were addressed. Explain decisions, including the ones where you said no.

The loop is the critical part. Without communication, you have a feedback funnel, not a feedback loop. Information flows in one direction — from users to your team — and nothing flows back. The loop closes when users see their input reflected in your product and your decisions.

This distinction matters more than it sounds. Teams that close the loop get more feedback, better feedback, and higher retention. Teams that don't close the loop slowly lose the trust that makes feedback programs work.

## The four stages

![Detailed customer feedback loop diagram showing collect, analyze, act, and communicate stages](/blog/customer-feedback-loop/stages-diagram.webp)

### Stage 1: Collect

Good collection meets users where they already are. No single channel captures everything, so you need a combination.

**Feedback boards** give users a dedicated space to submit ideas, browse existing requests, and vote on what matters most. A public [feedback board](/features/feedback) with [voting](/features/voting) turns collection into a collaborative process. Users discover that someone else has already requested their idea, so they vote instead of creating a duplicate. You get cleaner data and a clearer picture of demand.

**In-app widgets** capture feedback at the moment of experience. An embedded [widget](/features/widget) in your product lets users share thoughts without leaving the page they are on. The friction is minimal — a button click and a few sentences. The context is rich — you know which page they were on, what they were doing, and who they are.

**Surveys** provide structured, quantitative data. [NPS surveys](/tools/nps-calculator) track loyalty trends over time. CSAT surveys measure satisfaction after specific interactions. Keep surveys short and well-timed. Every additional question reduces your completion rate.

**Support conversations** are feedback whether you treat them that way or not. Every ticket about a confusing workflow, every chat asking how to do something, every email requesting a feature — these are data points. Integrating your support tool with your feedback system lets you capture this signal without asking your support team to manually copy and paste.

**Customer interviews** go deeper than any other method. A 30-minute conversation reveals context, motivation, and nuance that no survey can capture. Use them to explore problems you don't fully understand. For a deeper walkthrough of each channel, see the [complete guide to collecting customer feedback](/blog/collect-customer-feedback). If you want templates for phrasing your feedback requests across each of these channels, see [how to ask for customer feedback](/blog/how-to-ask-for-customer-feedback).

The goal in the collection stage is not to maximize volume. It is to create consistent, low-friction channels that produce high-quality input. A hundred thoughtful feature requests are more useful than ten thousand one-word survey responses.

### Stage 2: Analyze

Raw feedback is not useful until you find the patterns. A backlog of a thousand feature requests tells you nothing until you categorize, aggregate, and prioritize.

**Categorize every piece of feedback.** Tag it by type (feature request, bug report, usability issue), product area (onboarding, billing, analytics), and customer segment (enterprise, SMB, free tier). Consistent tagging lets you filter and slice the data. Without it, every question about "what are users saying about X" requires a manual search.

**Find patterns, not individual requests.** A single user asking for CSV export is an anecdote. Forty users asking for it is a pattern. Resist the urge to build based on one compelling request from a loud or important customer. Aggregate first. Patterns are what you act on.

**Use AI to accelerate analysis.** AI-powered duplicate detection catches requests that describe the same problem in different words. Sentiment analysis surfaces posts with strong negative or positive signals so you can prioritize responses. These features do not replace human judgment, but they reduce the manual work of sifting through hundreds of submissions. Quackback includes [AI analysis](/features/feedback) that runs over your structured feedback as it comes in.

**Prioritize with a framework.** Gut-based prioritization breaks down at scale. Use a structured approach like RICE (Reach, Impact, Confidence, Effort) to score and rank requests. The [RICE calculator](/tools/rice-scoring-calculator) helps you apply this framework consistently across your backlog. Structured prioritization makes your decisions defensible — when a stakeholder asks why you chose feature A over feature B, you have a clear rationale.

**Look for what users don't say.** Feedback is biased toward users who are engaged enough to give it. Analyze usage data alongside submitted feedback. Features with low adoption but no complaints might have discoverability problems. High-churn segments that never submit feedback might have needs you are not addressing.

### Stage 3: Act

Analysis without action is academic. This is where the feedback loop produces value — you change your product based on what you learned.

**Build what the data supports.** The features and fixes you prioritize should reflect the patterns you found in the analysis stage, not the most recent request or the loudest stakeholder. When your backlog is well-organized and consistently prioritized, deciding what to build next becomes a matter of reading the top of the list rather than debating in a meeting.

**Update your roadmap.** A [public roadmap](/features/roadmap) is both a planning tool and a communication tool. When you move a request to "Planned" or "In Progress," every user who voted for it sees that progress is happening. The roadmap creates accountability. If something sits in "Planned" for six months with no movement, that is visible — and it should prompt a conversation about whether the priority is real.

**Don't wait for perfection.** Some teams delay action because they want to build the complete solution. In feedback-driven development, shipping an 80% solution and iterating based on reactions is usually better than spending months on the perfect version. Users who requested a feature would rather see a good version soon than a perfect version eventually.

**Address bugs and usability issues quickly.** Not all feedback leads to new features. Some of the highest-impact actions are fixing bugs, improving confusing flows, and smoothing rough edges. These changes don't make headlines, but they compound. A product that reliably works well earns more trust than a product that ships flashy features on top of a broken foundation.

### Stage 4: Communicate

This is the stage most teams skip, and it is the stage that makes the entire loop work.

**Publish a changelog.** When you ship a feature, fix a bug, or make a meaningful change, announce it. A [changelog](/features/changelog) gives users a single place to see what has changed. It demonstrates momentum. It shows users that the product they rely on is actively improving.

**Notify voters and requesters.** When you resolve a feature request, the people who voted for it should hear about it. Automatic notifications close the loop at the individual level. The user who submitted a request six months ago gets an email saying it shipped. That user now knows their feedback led to action, and they are far more likely to give feedback again.

**Explain decisions, including the no.** Closing the loop does not mean building everything users ask for. It means responding to what they ask for. When you decide not to build a request, say so. Explain the reasoning. "We've decided not to build this because it conflicts with our direction on X" is a closed loop. Silence is not.

**Connect the change to the feedback.** When you announce a feature in your changelog, reference the feedback that drove it. "You asked for CSV export — here it is" lands better than a generic release note. It reinforces the connection between user input and product output. Users see that the loop is real.

Communication transforms your relationship with users from transactional to collaborative. Users stop seeing feedback as shouting into a void and start seeing it as a partnership. That shift changes the quality, volume, and tone of everything they share with you.

## Why closing the loop matters

The benefits of closing the feedback loop go beyond making users feel heard. They show up in metrics.

**Retention improves.** Users who see their feedback acknowledged and acted on stay longer. They have a reason to stay beyond the current feature set — they believe the product will keep getting better in ways that matter to them. Closing the loop is a retention mechanism that costs nothing to implement.

**Trust compounds over time.** Every closed loop builds credibility. When you consistently communicate decisions — both the yes and the no — users trust your prioritization process. They give you the benefit of the doubt when you say no to their request because they have seen you say yes to others. Trust makes every future product decision easier.

**Feedback quality increases.** Users who see their input lead to action submit better feedback. They write more detailed descriptions. They provide more context. They think harder about what they're asking for because they know someone will actually read it and consider it seriously. This creates a virtuous cycle: better feedback leads to better decisions, which leads to more trust, which leads to even better feedback.

**Internal alignment gets easier.** When product decisions are visibly connected to user feedback, internal debates become more productive. Instead of arguing about whose intuition is right, teams can point to the data. "Users are asking for this, here's the demand, here's the prioritization score" is a better starting point than "I think we should build this."

## Common mistakes

### Collecting without acting

The most common failure mode. You set up boards, widgets, and surveys. Feedback flows in. Your backlog grows. But nothing changes. No features get built based on feedback. No one responds to requests. The collection infrastructure becomes a monument to good intentions and broken promises. Users eventually realize that submitting feedback has no effect, and they stop.

### Waiting too long to close the loop

Some teams close the loop eventually — but six months after the feature ships. By then, the user who requested it has moved on, found a workaround, or churned. Timeliness matters. The connection between "I asked for this" and "they built it" weakens with every week that passes. Notify users as soon as the change ships, not when you get around to it.

### Only closing the loop for big features

Small fixes and improvements deserve communication too. If a user reported a confusing error message and you improved it, tell them. If someone flagged a bug and you fixed it, let them know. Closing the loop on small items demonstrates that you are paying attention to details, not just headline features. It also encourages users to report the small things, which is where a lot of product quality lives.

### Treating the loop as a one-time process

Feedback loops are continuous, not one-and-done. Some teams run a feedback initiative — a big survey, a round of interviews, a week of triaging the backlog — and then go quiet for months. Users learn the cadence and stop engaging between initiatives. Build a feedback loop that runs continuously, not in bursts. Always-on channels like [feedback boards](/features/feedback) and [in-app widgets](/features/widget) help, but only if someone is reviewing and responding to what comes in.

### Ignoring negative feedback

It is tempting to focus on feature requests and ignore complaints, criticism, and low satisfaction scores. Negative feedback is uncomfortable. It is also where the highest-leverage improvements often hide. A user who gives you a detailed explanation of why they are frustrated is giving you a gift. Acknowledge it. Act on it when appropriate. And close the loop by telling them what you did.

## Tools for feedback loops

Closing the feedback loop manually — tracking every request in a spreadsheet, sending individual emails when features ship, updating a static roadmap document — works at small scale. It does not work when you have hundreds or thousands of users submitting feedback across multiple channels.

Purpose-built tools automate the mechanical parts of the loop so your team can focus on the judgment parts: deciding what to build, how to prioritize, and what to communicate.

Look for a tool that covers all four stages in one place: collection (boards, widgets), analysis (AI-assisted categorization and deduplication), action (roadmap management), and communication (changelog with automatic notifications to voters). [Quackback](https://quackback.io) is one option that handles the full loop — boards and [widgets](/features/widget) for collection, [AI](/features/feedback) for analysis, a public [roadmap](/features/roadmap) for action, and a [changelog](/features/changelog) that notifies users when their requests ship. The key is that the loop closes without manual work, regardless of which tool you choose.

Quackback is open source (AGPL-3.0) and self-hosted for free, with a managed [Quackback Cloud](/pricing) if you would rather not run it yourself. Its [MCP server](/features/mcp) also lets you query and update feedback from an AI assistant, which is useful for closing the loop without leaving your editor. For a broader comparison of tools that support this workflow, see the [best customer feedback tools in 2026](/blog/best-customer-feedback-tools-2026) and how Quackback stacks up [against Canny](/compare/quackback-vs-canny).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How long should it take to close a feedback loop?

It depends on the feedback type. Bug reports often resolve within days; large feature requests can take weeks or months. Speed matters less than communicating at every stage: acknowledge on arrival, update the status when you prioritize, and notify the user when the change ships.

### What is the difference between an open and closed feedback loop?

An open feedback loop is one where user input flows in but nothing flows back, so users never hear what happened. A closed feedback loop completes the cycle by communicating the outcome to the people who contributed. "Closed" refers to communication, not to building every request.

### How do I measure whether my feedback loop is working?

Track feedback volume and quality over time, survey response rates, the share of items that get a status update within a set window (such as 7 days), and retention for users who submit feedback versus those who do not. Rising engagement signals the loop is creating value.

### What are the four stages of a customer feedback loop?

The four stages are collect, analyze, act, and communicate. You gather input across channels, find patterns and prioritize them, ship changes based on what you learned, and tell users what you did. The communicate stage is what closes the loop.

### What tools help you close the customer feedback loop?

Purpose-built feedback platforms automate the mechanical work: feedback boards and widgets collect input, AI categorizes and deduplicates it, a public roadmap tracks action, and a changelog notifies voters when requests ship. Quackback covers all four stages, with a deeper [user feedback guide](/blog/user-feedback-guide) on building the program.

- [Pendo Pricing in 2026: Plans, Costs, and Alternatives](https://quackback.io/blog/pendo-pricing): Pendo pricing plans in 2026. MAU-based pricing, plan limits, hidden costs at scale, and focused alternatives for teams that mainly need feedback features.

Published: 2026-02-06

Pendo is a product experience platform used by thousands of SaaS teams. Founded in 2013, it combines product analytics, in-app guides, and user feedback in a single platform. The appeal is consolidation: rather than running separate tools for analytics, onboarding, and feedback, you manage all three in one place.

That consolidation comes at a cost — literally. Pendo does not publish pricing publicly. Plans are quoted based on monthly active users (MAUs), and most teams report annual contracts in the range of $10,000 to $50,000+. For smaller teams or those primarily focused on feedback collection, this raises an obvious question: are you paying for features you'll actually use?

![Pendo pricing breakdown and plan comparison](/blog/pendo-pricing/hero.webp)

> Pendo does not publish pricing publicly. Plans are based on **monthly active users (MAUs)**, with most teams paying $10,000 to $50,000+ per year depending on MAU count and feature tier. A limited free plan covers up to 500 MAUs. If you mainly need feedback collection and roadmapping, focused alternatives like [Quackback](https://quackback.io) (free, open source) deliver that workflow without an MAU-based contract.

*Pricing information based on publicly available data and user reports as of February 2026. Pendo does not publish pricing — contact their sales team for exact quotes.*

## Pendo's pricing plans

Pendo offers four plan tiers in 2026. One is free with limited features. The rest are custom-quoted through sales.

| Plan | Price | MAU Limit | Key Features |
|------|-------|-----------|--------------|
| Free | $0 | 500 MAUs | Basic analytics, in-app guides (limited), NPS, 1 app |
| Growth | Custom | Custom | Full analytics, guides, feedback, roadmap, 1 app |
| Portfolio | Custom | Custom | Multiple apps, cross-product analytics, advanced segmentation |
| Premium | Custom | Custom | Session replay, data sync, advanced integrations, priority support |

The free plan covers up to 500 MAUs and is genuinely usable for small teams or internal tools. You get basic analytics, limited in-app guides, and NPS surveys. Once you exceed 500 MAUs or need features like the feedback module, public roadmaps, or integrations with your data warehouse, you move to a paid plan.

Growth is the first paid tier and covers the core product: full analytics, in-app guides, NPS, the feedback module, and roadmaps for a single app. Portfolio adds multi-app support and cross-product analytics — relevant for companies with multiple products or a platform with distinct modules. Premium adds session replay, advanced data sync, and dedicated support.

All paid plans are custom-priced through sales. You will not find a checkout button on Pendo's pricing page.

## How Pendo pricing works

Pendo's billing model centers on monthly active users. An MAU is any user who interacts with your product in a given calendar month. If 3,000 people open your app in January, you have 3,000 MAUs that month.

MAU counts determine your pricing tier. Higher MAU counts mean higher costs, and Pendo uses your peak or average MAU count as the basis for annual contract pricing. Unlike tracked-user models (such as Canny's), where historical interactions accumulate, Pendo's MAU model resets each month — but your contract is set annually based on your expected MAU range.

Paid plans require annual contracts. There is no monthly billing option for Growth, Portfolio, or Premium. You negotiate a contract based on your current MAU count with some headroom built in, and renew (or renegotiate) at the end of the year. If your product grows significantly mid-contract, you may be required to upgrade your tier or pay overage fees.

Enterprise features — advanced security, SSO, dedicated infrastructure — are negotiated as part of the contract. Pendo's sales process is thorough: expect multiple meetings, a product demo, and a procurement cycle that can take several weeks.

## Pendo pricing at scale

Pendo does not publish a pricing table, so the figures below are estimates based on publicly available user reports, G2 reviews, and industry data. Treat these as directional guidance, not official quotes.

| MAU Count | Estimated Annual Cost |
|-----------|----------------------|
| 500 | Free |
| 1,000 | $7,000–$12,000 |
| 5,000 | $15,000–$25,000 |
| 10,000 | $25,000–$40,000 |
| 25,000 | $40,000–$80,000+ |
| 100,000+ | $80,000–$200,000+ |

These estimates are for the Growth tier with a single app. Portfolio and Premium tiers carry additional costs. Add-ons such as session replay or advanced data sync are priced separately on lower tiers.

The wide ranges reflect the variability in Pendo's negotiated pricing. Two companies with the same MAU count may pay significantly different amounts based on contract length, negotiation leverage, and which features they need.

## What Pendo includes

Pendo is broad. The platform covers several distinct categories that most companies handle with separate tools.

**Product analytics.** Pendo tracks feature adoption, page views, session duration, retention cohorts, and funnel analysis. You can see which features users engage with, which they ignore, and how behavior differs across segments. This is the core of what Pendo does, and it does it well.

**In-app guides.** Walkthroughs, tooltips, lightboxes, and banners — all created with a no-code visual editor. You can trigger guides based on user behavior, segment, or lifecycle stage. This is how Pendo earns its "product experience" label.

**NPS and polls.** In-app surveys, NPS scoring, and targeted micro-surveys. Results feed back into Pendo's analytics so you can correlate sentiment with behavioral data.

**Feedback module.** A feedback board and voting system where users can submit and vote on feature requests. Feedback is visible to product managers alongside usage data. On paid plans, you can create a public roadmap.

**Roadmaps.** A visual roadmap linked to feedback votes. Product teams can prioritize based on vote counts and move items through planning, in-progress, and shipped stages.

**Session replay.** Available on Premium. You can watch recorded sessions to understand exactly how users navigate your product, including clicks, scrolls, and rage clicks.

**Integrations.** Salesforce, HubSpot, Zendesk, Slack, Jira, and others. Data sync with Snowflake and other data warehouses on higher tiers.

The breadth is genuine. Pendo is not padding a feature list — most of these capabilities work well. The question for each team is how many of them they actually need.

## Hidden costs to consider

The MAU-based annual contract is only part of what Pendo costs.

**Implementation takes weeks, not hours.** Installing the Pendo snippet is straightforward. Getting value from analytics requires tagging every feature you care about, which takes engineering time. Setting up guides, configuring segments, and integrating with your CRM is a multi-week project. Most teams report 2–6 weeks before Pendo is fully operational. Factor in your team's time alongside the subscription cost.

**MAU growth is unpredictable.** Your contract is priced based on an MAU estimate. If your product grows faster than expected — a successful launch, a viral moment, a new enterprise customer with thousands of users — you may exceed your contracted MAU ceiling. Pendo will typically require you to upgrade or pay overage fees. You cannot easily dial usage back down.

**Premium features are locked to higher tiers.** Session replay is a Premium feature. Advanced data sync requires Portfolio or Premium. If your initial evaluation of Pendo was based on a feature that lives in a higher tier than you purchased, you'll face an upgrade conversation at renewal.

**Annual contracts limit flexibility.** You commit for a year upfront. If you decide Pendo isn't the right fit after three months — the analytics aren't being used, the guides are underutilized — you're still paying through the end of the contract. There is no monthly billing option and no standard pro-rata exit.

**Professional services.** Pendo offers implementation services, guide design, and training through its professional services team. These are not included in the subscription and carry their own costs. For teams without dedicated resources to manage Pendo, professional services can add thousands to the first-year total.

## When Pendo makes sense

Pendo is well-suited to specific situations.

You are a mid-market or enterprise team that needs product analytics and feedback in one platform. The consolidation argument is strongest when you would otherwise pay for Mixpanel or Amplitude for analytics, Intercom or Appcues for in-app guides, and Canny or Productboard for feedback. Pendo collapses those subscriptions into one, which can be cost-effective at scale.

You have an existing Pendo investment. If your team already uses Pendo's analytics and guides, adding the feedback module is incremental. The data is already there; you're extending what you have rather than onboarding a new platform.

You need in-app guides alongside feedback. If your product requires guided onboarding, feature announcements, or contextual help — and you want those tied to the same analytics that tell you whether they worked — Pendo's integrated approach delivers something piecemeal tools cannot.

You have engineering resources for implementation. Pendo requires tagging. A team with dedicated product analytics engineering gets more out of Pendo than a team that installs the snippet and hopes the auto-capture is sufficient.

## When Pendo is overkill

Pendo's breadth is a liability when you only need part of it.

If your primary need is collecting user feedback, letting users vote on feature requests, publishing a roadmap, and communicating what ships, you're paying for analytics and in-app guides you may never use. A $15,000–$40,000/year contract for a feedback board is difficult to justify, especially at the early stages of a product when you're still validating whether the product fits the market.

Pendo's feedback module is not its strongest suit. It works, but it is not the center of the product — analytics and guides are. If feedback collection and roadmapping are your primary workflow, a focused tool built specifically for that job will serve you better.

The same logic applies to startups and small teams. The free plan (500 MAUs) is a genuine option, but the jump from free to paid is large. There is no $19/mo self-serve plan. You go from free to a sales conversation and an annual contract. That gap excludes a large portion of the market.

![Estimated annual Pendo cost scaling by monthly active users from free tier through 100K MAUs](/blog/pendo-pricing/pendo-mau-cost-scaling.webp)

## Cheaper alternatives to Pendo

If you primarily need feedback collection, feature voting, roadmaps, and changelogs, several tools deliver that workflow at a fraction of Pendo's cost — or for free.

### Quackback

[Quackback](https://quackback.io) is free, open source (AGPL-3.0), and self-hosted, with a managed [Quackback Cloud](/pricing) from $29/mo on annual billing if you would rather not run it yourself. It covers [feedback boards](/features/feedback), [voting](/features/voting), a [public roadmap](/features/roadmap), [changelogs](/features/changelog), and 25 integrations. AI features and SSO/OIDC are included free on every self-hosted installation, working with OpenAI-compatible providers. On Cloud, Quinn is included on paid plans, and SSO is self-serve on Enterprise. An [MCP server](/features/mcp) lets you query and triage feedback directly from your AI tools, which Pendo, Canny, and Productboard do not offer. Self-host with Docker or deploy on Railway. See the [full comparison of Quackback vs Pendo](/compare/quackback-vs-pendo).

### Canny

[Canny](/blog/canny-pricing) has a free plan (25 tracked users) and paid tiers starting at $19/mo. It covers feedback boards, voting, roadmaps, and changelogs. Onboarding takes minutes. The trade-off is tiered tracked-user pricing where costs increase as you cross user thresholds. Still a fraction of Pendo's entry price for teams that don't need analytics or in-app guides.

### Featurebase

[Featurebase](/compare/quackback-vs-featurebase) bundles feedback boards, a changelog, a roadmap, and a support inbox. A free plan exists (1 seat, limited features). Paid plans start at $29/seat/month. Lightweight and quick to set up. Closed source and hosted only.

### Productboard

[Productboard](/compare/quackback-vs-productboard) is a product management platform with feedback collection, roadmapping, and prioritization frameworks. Paid plans start at $19/maker/month. It is more structured than Canny or Quackback and better suited to teams with mature prioritization workflows. It does not include analytics or in-app guides.

### Comparison table

| | Pendo | Quackback | Canny | Featurebase | Productboard |
|---|---|---|---|---|---|
| **Starting price** | Free (500 MAUs) | Free (self-hosted) | Free (25 tracked users) | Free (1 seat) | $19/maker/mo |
| **First paid tier** | Custom (sales) | $29/mo (Cloud) | $19/mo | $29/seat/mo | $19/maker/mo |
| **Pricing model** | MAU-based (annual) | Workspace (Cloud) or free self-hosted | Tiered tracked users | Per seat | Per maker seat |
| **Self-hosting** | No | Yes (Docker) | No | No | No |
| **Open source** | No | Yes (AGPL-3.0) | No | No | No |
| **Feedback boards** | Yes | Yes | Yes | Yes | Yes |
| **Roadmaps** | Yes | Yes | Yes | Yes | Yes |
| **Changelog** | No | Yes | Yes | Yes | No |
| **Product analytics** | Yes | No | No | No | No |
| **In-app guides** | Yes | No | No | No | No |
| **Session replay** | Premium tier | No | No | No | No |
| **SSO** | Enterprise | Free self-hosted · Enterprise plan on Cloud | Business (custom) | $59/seat/mo plan | Enterprise |
| **AI features** | Limited | Quinn on paid Cloud · BYOK self-host | Autopilot (all plans) | $0.49/resolution | Limited |
| **MCP server** | No | Yes | No | No | No |
| **Annual contract required** | Yes | No | No | No | No |

For teams focused on the feedback and roadmap workflow, Quackback, Canny, or Featurebase will cover most needs at a significantly lower cost. For teams that genuinely need analytics, in-app guides, and feedback in one place, Pendo is a serious option — but the price reflects that breadth.

For a broader look at the category, see [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026), [Pendo Alternatives](/blog/best-pendo-alternatives), and [Feedback Tool Pricing Comparison](/blog/feedback-tool-pricing-comparison).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How much does Pendo cost?

Pendo does not publish pricing publicly. The free plan covers up to 500 MAUs. Paid plans are custom-quoted through sales based on your monthly active user count. User reports put Growth tier pricing around $7,000–$25,000 per year for 1,000–10,000 MAUs, with annual contracts required.

### Does Pendo have a free plan?

Yes. Pendo's free plan supports up to 500 MAUs and includes basic analytics, limited in-app guides, and NPS surveys for a single app. The feedback module, roadmap, and advanced analytics are restricted. Once you exceed 500 MAUs or need those features, you enter the custom-pricing sales process.

### What is Pendo used for?

Pendo is a product experience platform. Its core use cases are product analytics (feature adoption, retention, user behavior), in-app guides (walkthroughs, tooltips, onboarding flows), and user feedback (feature requests, NPS, polls, public roadmaps). B2B SaaS teams use it to combine these capabilities in one platform rather than separate tools.

### Is Pendo worth the cost for small teams?

Generally not. The gap between Pendo's free plan (500 MAUs) and a custom-quoted annual contract is large, with no self-serve middle ground. Small teams that mainly need feedback and a public roadmap get the core workflow cheaper from focused tools like [Quackback](https://quackback.io) (free, open source), Canny, or Featurebase.

- [User Feedback: The Complete Guide for Product Teams](https://quackback.io/blog/user-feedback-guide): Everything product teams need to know about user feedback. Types, collection methods, analysis frameworks, and how to build a feedback-driven product culture.

Published: 2026-02-05

Good product decisions start with user feedback. Not intuition, not competitor analysis, not the loudest voice in the room. What your users tell you — directly and indirectly — is the most reliable signal for what to build next.

![User feedback management lifecycle](/blog/user-feedback-guide/hero.webp)

Most product teams know this. The problem is execution. Feedback arrives through dozens of channels: support tickets, Slack messages, sales call notes, social media, app store reviews, NPS surveys, and in-app widgets. Without a system, it scatters across tools and inboxes. Patterns go unnoticed. Feature requests pile up with no way to gauge demand. Users who took the time to share their thoughts never hear back.

This guide covers what user feedback actually is, the types that matter, how to collect and analyze it, and how to build a feedback loop that turns raw input into better products.

![The feedback funnel from raw input to communicated output](/blog/user-feedback-guide/feedback-funnel.webp)

## What is user feedback?

User feedback is any qualitative or quantitative signal from users about your product. It includes what people say (feature requests, complaints, praise), what they do (usage patterns, drop-off points, support tickets), and how they feel (satisfaction scores, sentiment).

Some feedback is solicited. You ask for it through surveys, interviews, and feedback forms. Some is unsolicited. Users volunteer it through support channels, social media, and review sites. Both types carry signal, but they require different approaches to collect and interpret.

The distinction between qualitative and quantitative feedback matters. Quantitative feedback — NPS scores, CSAT ratings, usage metrics — tells you what is happening and how much. Qualitative feedback — open-ended comments, interview transcripts, feature request descriptions — tells you why. You need both. Numbers without context lead to wrong conclusions. Stories without scale lead to building for edge cases.

## Types of user feedback

Not all feedback is the same. Understanding the different types helps you collect each one deliberately and analyze it appropriately.

### Feature requests

Users telling you what they want your product to do. These range from vague ("it would be nice if it was faster") to specific ("add CSV export to the analytics dashboard"). Feature requests are the most common type of feedback product teams deal with, and the hardest to manage at scale. Without a system to capture, deduplicate, and prioritize them, they become noise.

### Bug reports

Something is broken and a user noticed. Bug reports are feedback about quality. They tell you where your product fails to meet the baseline expectation of working correctly. Treat them differently from feature requests — bugs are about what you already promised, not what you could build next.

### General satisfaction

How users feel about your product overall. This is typically measured through structured surveys. [NPS (Net Promoter Score)](/tools/nps-calculator) asks how likely users are to recommend your product. [CSAT (Customer Satisfaction Score)](/tools/csat-calculator) asks how satisfied users are with a specific interaction or experience. These scores are useful for tracking trends over time, less useful for deciding what to build.

### Usability feedback

Feedback about how easy or difficult your product is to use. This surfaces through user interviews, session recordings, support tickets ("I can't figure out how to..."), and usability testing. Usability feedback often reveals problems users have learned to work around — problems they might never report as bugs or feature requests.

### Churn feedback

What users tell you when they leave. Exit surveys, cancellation flows, and win/loss analyses capture this. Churn feedback is uniquely valuable because it comes from people who decided your product isn't worth paying for anymore. The reasons they give — too expensive, missing features, switched to competitor, no longer needed — are direct inputs for retention strategy.

### Praise and positive feedback

Users telling you what works. It is easy to dismiss positive feedback as less actionable than complaints. That is a mistake. Praise tells you what to protect. It reveals which features and experiences users value most. When you know what keeps people around, you can avoid accidentally breaking it during redesigns or deprioritizing it on your roadmap.

## How to collect user feedback effectively

The goal is not to maximize the volume of feedback. It is to build a system that captures representative signal from across your user base, with enough context to act on it.

Most teams default to one or two channels and end up with blind spots. A public feedback board captures feature requests from engaged users but misses the frustrations of users who never visit the board. NPS surveys track sentiment trends but tell you nothing about what to build. Support tickets reveal what is broken but not what is missing.

The right collection strategy layers channels by signal type:

**Continuous passive collection.** Always-on channels that capture feedback without requiring you to ask. In-app widgets, feedback boards with voting, and support ticket tagging fall into this category. These channels build up signal over time and are your primary source for prioritization data.

**Periodic structured collection.** Surveys (NPS quarterly, CSAT after key interactions) that measure specific dimensions at regular intervals. These give you trend data and benchmarks. Keep them short — every additional question reduces completion rates.

**Deep qualitative collection.** User interviews, sales call debriefs, and churned-user conversations. These are expensive but irreplaceable for understanding context, motivation, and workflow. Schedule them around specific product decisions, not on a fixed cadence.

**Ambient collection.** Social media mentions, app store reviews, community forums, and competitor comparison sites. You are not asking for this feedback. It exists whether you look at it or not. Monitor it for signals you would miss through direct channels.

The common mistake is treating all channels equally. Weight them differently based on what you are trying to learn. For feature prioritization, voting data from a feedback board is more useful than NPS scores. For retention strategy, churn interviews and support ticket patterns matter more than feature votes.

For a detailed breakdown of eight specific collection methods with implementation guidance, see the [guide to collecting customer feedback](/blog/collect-customer-feedback). For practical email and in-app templates, see [how to ask for customer feedback](/blog/how-to-ask-for-customer-feedback).

## How to analyze user feedback

Collecting feedback is the easy part. The hard part is making sense of it. A thousand feature requests in a spreadsheet are not useful until you find the patterns.

### Categorize and tag feedback

Every piece of feedback should be tagged by type (feature request, bug, usability issue), product area (onboarding, billing, reporting), and customer segment (enterprise, SMB, free tier). Consistent tagging lets you filter and aggregate. Without it, you are searching through raw text every time someone asks "what are our users saying about X?"

### Look for patterns, not individual requests

A single user asking for dark mode is an anecdote. Fifty users asking for it is a pattern. Resist the urge to build based on individual requests, no matter how articulate or how important the requester is. Aggregate feedback before making prioritization decisions.

This does not mean ignore outliers. Sometimes a single request reveals a fundamental gap. But the default should be to look for clusters.

### Use voting to gauge demand

Feature voting boards let your user base signal what matters most to them. Votes are an imperfect proxy for demand — they skew toward power users and people who happen to find the board — but they are far better than guessing. When a feature request has 200 votes and another has 3, that difference is meaningful.

Combine vote counts with qualitative data. A highly-voted request with detailed comments explaining use cases is a stronger signal than one with many votes but no context.

### AI-assisted analysis

Manual analysis does not scale. When you have thousands of feedback items across multiple channels, AI can handle the parts that are tedious for humans but straightforward for machines.

**Duplicate detection** identifies when multiple users report the same issue in different words. This prevents your backlog from inflating with redundant items and gives you accurate counts of how many users want a specific thing.

**Sentiment analysis** classifies feedback as positive, negative, or neutral automatically. This lets you monitor overall sentiment trends and flag negative spikes early.

**Summarization** condenses long comment threads and feedback clusters into key themes and actionable takeaways. Instead of reading 50 comments on a feature request, you get a summary with representative quotes.

Quackback's AI features handle all three — duplicate detection, sentiment analysis, and summarization — using your own OpenAI-compatible API key. The [MCP server](/features/mcp) also lets AI agents search your feedback, triage requests, and surface insights directly within tools like Claude, Cursor, or Windsurf. For a deeper look at how AI is changing feedback analysis, see our guide on [AI customer feedback analysis](/blog/ai-customer-feedback-analysis).

## Building a feedback loop

Collecting and analyzing feedback only matters if it changes what you build. A feedback loop is the system that connects user input to product output and back again. It has four stages. For a deeper dive into each stage with implementation guidance, see our guide on [the customer feedback loop](/blog/customer-feedback-loop).

### 1. Collect

Gather feedback from all channels into a single system. Feedback boards, in-app widgets, support integrations, and surveys should all feed into one place. The goal is a unified view of what your users are telling you, regardless of where they said it.

### 2. Prioritize

Decide what to build based on feedback volume, strategic alignment, effort, and impact. Not every popular request belongs on your roadmap. Some requests conflict with your product vision. Some are technically expensive for limited payoff. Use feedback as a major input, not the sole decision-maker.

### 3. Build

Ship the features, fixes, and improvements you prioritized. This stage is your normal product development process. The feedback loop doesn't change how you build — it changes what you choose to build and why.

### 4. Communicate

Tell users what you built and why. This is the stage most teams skip, and it is the most important for sustaining the loop. When users see their feedback resulted in a shipped feature, they give more feedback in the future. When they never hear back, they stop contributing.

A public [roadmap](/features/roadmap) shows users what you are planning and working on. It sets expectations and reduces duplicate requests for things already in progress. A [changelog](/features/changelog) announces what you shipped. Connect the two: when a feature moves from "planned" to "shipped," notify the users who requested it. That notification is the moment where feedback becomes a relationship.

Closing the loop also builds trust. Users who see their input acknowledged — even when the answer is "we considered this but decided against it" — respect the transparency. Silence is what kills feedback culture.

## User feedback best practices

**Separate collection from evaluation.** The person (or system) collecting feedback should not be filtering it. Capture everything first. Evaluate later. If your support team decides what is "real feedback" and what is not, you lose signal. A feature request that sounds impractical today might make sense after the next platform change.

**Respond, even briefly.** Even a one-line acknowledgment ("Logged this, thanks") tells the user their input was received. Automated responses work for initial receipt. Follow up with a human response when you make a decision about the request. The median time between a user submitting feedback and getting a response is a metric worth tracking. If it is measured in weeks, your users have noticed.

**Track velocity, not just volume.** The most useful feedback metric is not "how many requests did we receive" but "how quickly do requests move from submission to decision." A feature request that sits untouched for six months sends a message that feedback does not matter. Aim to triage new feedback within one week and make a disposition decision (build, defer, decline) within one quarter.

**Segment before you prioritize.** A feature request from a churning enterprise account, the same request from a trial user, and the same request from a power user who is not going anywhere each tell you something different. Attach user metadata (plan, revenue, tenure, usage frequency) to feedback at the point of collection so you can filter later without re-investigating.

**Make declining transparent.** Saying no is fine. Saying nothing is not. When you decline a request, publish the reason. "We are solving this problem differently with X" or "this conflicts with our focus on Y for the next two quarters" builds more trust than silence. Teams that do this consistently find that users continue contributing even when their specific requests are rejected.

## Frequently asked questions

### How do you measure the ROI of a user feedback program?

Track three things: feature adoption rates for feedback-driven features versus internally-driven ones, churn reduction among users whose feedback was addressed, and time-to-resolution for reported issues. Most teams find that features built from aggregated user feedback see higher adoption than features built from internal assumptions. You can also measure feedback loop velocity — the time from feedback submission to shipped feature — as a leading indicator of how well your system works.

### How much user feedback is enough?

There is no universal number. The right volume depends on your product's maturity and user base size. Early-stage products need deep qualitative feedback from a small number of users. Mature products need quantitative signals from a broad base to spot trends. The more important question is whether your feedback is representative. If you only hear from enterprise customers, you are blind to what your SMB users need. Diversify your channels to diversify your feedback sources.

### What is the difference between user feedback and user research?

User research is a structured discipline with specific methodologies — usability studies, A/B tests, jobs-to-be-done interviews, diary studies. User feedback is broader and often unstructured. Research is something you initiate. Feedback is something users give you, often unprompted. They complement each other. Feedback tells you what users want. Research helps you understand why they want it and whether building it would actually solve their problem.

### Which tools should product teams use to manage user feedback?

It depends on your team size, budget, and whether you need self-hosting. For a breakdown of the current landscape, see [the best customer feedback tools in 2026](/blog/best-customer-feedback-tools-2026). If open source and data ownership matter to you, the [open source feedback tools comparison](/blog/open-source-feedback-tools) covers the viable options. At minimum, you need a centralized place for feedback collection, voting to gauge demand, a public roadmap, and a changelog. Avoid managing feedback in spreadsheets or Slack — those systems break down fast.

- [Zendesk Pricing in 2026: Plans, Per-Agent Costs, and What to Watch](https://quackback.io/blog/zendesk-pricing): Zendesk pricing breakdown in 2026. Suite plans, per-agent costs, add-on expenses, and when a separate feedback tool makes more sense.

Published: 2026-02-04

Zendesk is the most widely used customer support platform in the world. Millions of support agents use it daily across companies of every size, from early-stage startups to large enterprises. The product has been around since 2007 and has grown into a broad suite covering ticketing, live chat, phone, email, a help center, and AI-powered automation.

The pricing reflects that scale. Zendesk's Suite plans are priced per agent per month, billed annually. Costs grow linearly with your team size, and a range of add-ons can meaningfully increase what you pay.

![Zendesk pricing plans breakdown](/blog/zendesk-pricing/hero.webp)

> Zendesk Suite starts at $55/agent/month billed annually and scales to $115/agent/month for Professional, with Enterprise priced through sales. Add-ons — Advanced AI, Workforce Management, Quality Assurance — can each add $35 to $50/agent/month on top. Zendesk handles support tickets well, but feature request tracking, public voting boards, and product roadmaps need a separate tool. [Quackback](https://quackback.io) integrates directly with Zendesk and is free to self-host.

*Pricing last verified February 2026. Vendors may change plans and pricing without notice. Check Zendesk's pricing page for the latest figures.*

## Zendesk Suite pricing plans

Zendesk's main offering is the Suite — a bundle that combines ticketing, messaging, live chat, voice, a help center, and AI features in one package. In 2026, Zendesk offers four Suite tiers.

| Plan | Price | Key Features |
|------|-------|--------------|
| Suite Team | $55/agent/mo (annual) | Ticketing, email, chat, social messaging, help center, basic reporting, 1 AI agent |
| Suite Growth | $89/agent/mo (annual) | Everything in Team + self-service portal, customer satisfaction ratings, multilingual support, multiple ticket forms |
| Suite Professional | $115/agent/mo (annual) | Everything in Growth + custom reporting, SLAs, CSAT surveys, skills-based routing, community forums |
| Suite Enterprise | Custom (sales) | Everything in Professional + custom roles, sandbox, advanced AI, dedicated support |

Suite Team is the entry point. It covers the essentials: a shared inbox, email ticketing, live chat, social messaging channels, a basic help center, and standard reporting. One AI agent is included. For small support teams that need a centralized place to handle customer requests, it delivers what you need.

Suite Growth adds self-service features: a customer portal, customer satisfaction (CSAT) ratings, multiple ticket forms, and multilingual support. If you support customers in more than one language or want customers to manage their own requests without involving an agent, Growth is the minimum viable tier.

Suite Professional is where custom reporting and SLA management arrive. Skills-based routing lets you direct tickets to agents based on expertise or language. Community forums give your users a place to ask questions publicly. This tier is common among teams with dedicated support operations and formal service level commitments.

Suite Enterprise is custom-priced through sales. It adds custom agent roles, a staging sandbox, advanced AI capabilities, and dedicated support from Zendesk.

## Per-agent pricing explained

Every support agent who handles tickets needs a paid seat. Zendesk's per-agent model means your costs scale directly with your team size.

At $55/agent/month on Suite Team, a team of 10 agents costs $550/month, or $6,600/year. At $115/agent/month on Suite Professional, the same team costs $1,150/month, or $13,800/year. There is no volume discount published on lower tiers — the price per agent stays flat regardless of how many seats you add.

| Team Size | Suite Team ($55) | Suite Growth ($89) | Suite Professional ($115) |
|-----------|------------------|--------------------|---------------------------|
| 5 agents | $275/mo | $445/mo | $575/mo |
| 10 agents | $550/mo | $890/mo | $1,150/mo |
| 25 agents | $1,375/mo | $2,225/mo | $2,875/mo |
| 50 agents | $2,750/mo | $4,450/mo | $5,750/mo |
| 100 agents | $5,500/mo | $8,900/mo | $11,500/mo |

Zendesk also offers Light Agents — collaborators who can view and comment on tickets internally but cannot respond to customers directly. Light Agents are included at no additional cost on Suite plans, which is useful for product managers, engineers, or account managers who need visibility into support without taking a full agent seat.

All Suite pricing is billed annually. Month-to-month pricing is available but at a higher per-agent rate. Zendesk does not publish the exact month-to-month premium publicly — plan for at least 20–30% more if you need flexibility.

## Add-on costs

Zendesk's base Suite plans cover the core support workflow, but several high-value capabilities require separate add-ons. These are the ones that most commonly appear in renewal conversations.

**Advanced AI — $50/agent/month.** Zendesk's Advanced AI add-on includes intelligent triage (automatic intent, sentiment, and language detection), agent copilot (suggested replies, conversation summaries, next-step recommendations), and enhanced macro suggestions. This is separate from the basic AI agent included in Suite Team. For teams that want AI-assisted triage and drafting, this is the relevant add-on.

**Workforce Management — $35/agent/month.** Forecasting, scheduling, and real-time adherence tools for managing agent capacity. Relevant for teams large enough to need formal workforce planning — typically 25+ agents.

**Quality Assurance — $35/agent/month.** Automated conversation review, CSAT scoring analysis, and agent coaching workflows. Helps support managers identify quality issues without manually reviewing every ticket.

**Zendesk Voice.** Phone support is available as a consumption-based add-on within Zendesk Talk. You pay per minute for inbound and outbound calls in addition to your Suite subscription. Costs depend heavily on call volume and geography.

If a 25-agent team on Suite Professional adds Advanced AI and Quality Assurance, the all-in cost is $115 + $50 + $35 = $200/agent/month — $5,000/month total, or $60,000/year. Add Workforce Management and it reaches $235/agent/month, or $70,500/year for 25 agents.

## Zendesk pricing at scale

The table below shows monthly costs across plan tiers at common team sizes, without add-ons.

| Team Size | Suite Team | Suite Growth | Suite Professional |
|-----------|------------|--------------|--------------------|
| 10 agents | $550/mo | $890/mo | $1,150/mo |
| 25 agents | $1,375/mo | $2,225/mo | $2,875/mo |
| 50 agents | $2,750/mo | $4,450/mo | $5,750/mo |
| 100 agents | $5,500/mo | $8,900/mo | $11,500/mo |

These are the base costs before add-ons. Most teams at 25+ agents operating a serious support function end up on Professional or higher. Teams that adopt Advanced AI add $50/agent/month on top of that. At 50 agents on Professional with Advanced AI, the monthly cost is $8,250 — nearly $100,000/year.

## What Zendesk does well

Zendesk's strength is omnichannel support. It handles email, live chat, social messaging (Twitter/X, Facebook, Instagram, WhatsApp), phone, and web forms through a single agent workspace. Agents see the full conversation history across channels in one place without switching between tools.

The help center is a full knowledge base with multilingual support, article versioning, and a customer-facing portal. Community forums are available on Professional and higher. The reporting suite is solid, and custom dashboards on Professional let you build exactly the views your team needs.

Zendesk's marketplace has over 1,500 integrations. Salesforce, HubSpot, Jira, Slack, Shopify, and nearly every major SaaS tool has a native connector or a well-maintained third-party app. This makes Zendesk a reliable anchor for a broader customer operations stack.

For teams whose primary workflow is resolving customer support tickets — handling volume, routing requests to the right agent, tracking resolution time, and measuring customer satisfaction — Zendesk does this better than almost any competing platform.

![Monthly Zendesk cost across Suite tiers at 5 to 100 agents, with add-on impact at 50 agents](/blog/zendesk-pricing/zendesk-per-agent-cost-at-scale.webp)

## What Zendesk doesn't cover

Zendesk is a support platform. It is not a product feedback tool.

There is no native feature request board. Customers cannot submit and vote on product ideas. There is no public-facing roadmap for sharing what you're building next. There is no changelog for announcing what just shipped.

This is by design, not an oversight. Zendesk's job is to help your support team resolve tickets efficiently. The workflow ends when the ticket closes. What happens to the underlying product feedback — the feature request buried in a conversation, the bug report that three different customers mentioned this month — is not something Zendesk tracks or organizes.

For support teams, this gap shows up in a specific way. Agents know which feature requests come up repeatedly, but there is no structured place to capture that signal. The information lives in ticket comments, internal notes, or spreadsheets someone maintains manually. It does not flow to product teams in any systematic form.

This is where a dedicated feedback tool becomes relevant — not as a replacement for Zendesk, but as an addition to it. For a full rundown of the tools built for this job, see [Best Zendesk Alternatives for Customer Feedback in 2026](/blog/best-zendesk-alternatives).

## Pairing Zendesk with a feedback tool

[Quackback](https://quackback.io) is built to work alongside Zendesk, not replace it.

Support stays in Zendesk. Feature requests, voting, roadmaps, and changelogs live in Quackback. The integration connects the two so the feedback signal that surfaces in support tickets has a place to go.

In practice, the Quackback sidebar widget appears inside the Zendesk agent interface. When a customer mentions a feature request in a support conversation, the agent can search Quackback directly, find the relevant feature request, and vote on the customer's behalf without leaving Zendesk. The customer's vote is attributed to them in Quackback, and the support ticket can be linked to the feature request for context.

On the product team's side, Quackback shows which feature requests have the most support, with each vote tied to a real customer. When a request ships, Quackback's changelog notifies every customer who voted. The loop closes without any manual coordination between support and product.

This is a different workflow from trying to track feature requests inside Zendesk with tags or custom fields. Tags tell you a topic came up — they do not give you a ranked list of what customers most want, tied to the customers who asked for it.

Quackback is [free to self-host](https://quackback.io) (open source, AGPL-3.0) and covers [feedback boards](/features/feedback), [voting](/features/voting), a [public roadmap](/features/roadmap), [changelogs](/features/changelog), and integrations including [Zendesk](/integrations/zendesk). Unlike Zendesk's per-agent model, everyone on your team can read and triage feedback. An [MCP server](/features/mcp) lets you query and update feedback from Claude or any AI client. A managed [Quackback Cloud](/pricing) is also available if you would rather not host it yourself.

For a broader look at the feedback tool category, see [Best Customer Feedback Tools in 2026](/blog/best-customer-feedback-tools-2026), [Best Feature Request Tools](/blog/best-feature-request-tools), and [Feedback Tool Pricing Comparison](/blog/feedback-tool-pricing-comparison).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How much does Zendesk cost per month?

Zendesk Suite starts at $55/agent/month billed annually, scaling to $115/agent/month on Professional. A team of 10 agents costs $550/month on Suite Team or $1,150/month on Professional. Add-ons such as Advanced AI ($50/agent/mo) are billed separately, and Enterprise pricing is quoted through sales.

### Does Zendesk have a free plan?

Zendesk does not offer a permanent free plan for its Suite product. A free trial is available. The entry-level paid plan is Suite Team at $55/agent/month billed annually. There is no self-serve free tier. If you are looking for a free tool for collecting feature requests and managing a product roadmap alongside Zendesk, [Quackback](https://quackback.io) is free to self-host and integrates with Zendesk.

### Does Zendesk handle feature requests and roadmaps?

Zendesk is a support platform, not a product feedback tool. It does not have native feature request boards, public voting, or product roadmaps. Support agents can tag tickets and add internal notes, but there is no structured system for capturing and prioritizing product feedback. Teams that need feature request tracking alongside Zendesk typically add a dedicated tool. Quackback integrates with Zendesk and is built specifically for this workflow.

### Is Zendesk worth the price?

For teams whose primary need is omnichannel customer support at scale, Zendesk's pricing is competitive relative to its capabilities. The breadth of channel support, the quality of the agent workspace, and the depth of the integration marketplace are genuine strengths. The cost adds up fast for larger teams, and add-ons like Advanced AI can push per-agent costs to $165–$200/month. Whether it is worth it depends on your team size, the volume and complexity of your support operations, and which features you actually use.

- [How to Collect Customer Feedback: 8 Methods That Work](https://quackback.io/blog/collect-customer-feedback): A practical guide to collecting customer feedback. Eight proven methods, when to use each, and how to turn feedback into product decisions.

Published: 2026-02-03

Every product team knows feedback matters. Few collect it well.

![Eight methods to collect customer feedback](/blog/collect-customer-feedback/hero.webp)

> To collect customer feedback, combine an **in-app widget** for in-context input with a public **feature request board** so users can vote on ideas. Layer on NPS and CSAT surveys, customer interviews, support ticket analysis, social and review monitoring, and sales call feedback to cover both quantitative demand and qualitative depth. The methods only pay off if you route everything into one system and close the loop on what you build.

The most common failure modes: you don't collect enough feedback, so decisions are based on gut instinct. You collect too much feedback but never act on it, so users stop giving it. Or you use the wrong channels, so you hear from the loudest users instead of the most representative ones.

Good feedback collection is systematic. You need the right methods for the right moments, a way to organize what comes in, and a process to turn insights into product decisions. This guide covers eight methods that work, when to use each, and how to avoid the mistakes that make feedback programs fail.

## 8 methods to collect customer feedback

### 1. In-app feedback widgets

In-app widgets are the lowest-friction way to collect feedback. Users stay inside your product. They don't need to open a new tab, find your feedback page, or remember to email you later. The context is fresh — they're reacting to something they just experienced.

A good widget lets users submit ideas, report problems, and vote on existing requests without leaving the page they're on. The feedback arrives with context: which page the user was on, what they were doing, and who they are.

In-app collection consistently produces higher response rates than email surveys or external forms. The reason is simple. You're asking for feedback at the exact moment the user has something to say.

The [Quackback widget](/features/widget) embeds directly into your product and connects submissions to your feedback board automatically. Users see existing requests and can vote instead of creating duplicates. Quackback is open source and self-hosted free, with a managed [Quackback Cloud](/pricing) option.

**Best for:** Continuous feedback collection from active users. Catching issues and ideas in the moment.

### 2. Feature request boards

A public feedback board gives users a dedicated place to submit ideas, vote on requests from other users, and track the status of their suggestions. It turns feedback collection from a one-way channel into a conversation.

Voting is what makes boards valuable. Instead of guessing which requests matter most, you see demand quantified. Ten users asking for the same integration in separate emails is noise. Ten votes on a single request is signal.

Public boards also reduce duplicate work. When a user searches the board and finds their idea already submitted, they vote on it instead of creating a new ticket. Your team spends less time triaging and more time building.

[Feedback boards](/features/feedback) with [voting](/features/voting) give you a structured way to capture demand. Users can follow requests and get notified when the status changes, which keeps them engaged over time.

**Best for:** Ongoing feature prioritization. Building a backlog informed by real user demand.

### 3. NPS surveys

Net Promoter Score surveys ask one question: "How likely are you to recommend this product to a friend or colleague?" Users respond on a 0-10 scale. The score categorizes them as detractors (0-6), passives (7-8), or promoters (9-10).

NPS is a trailing indicator. It measures loyalty and overall sentiment, not specific feature requests. The score itself is less useful than the follow-up question: "What's the primary reason for your score?" That open-ended response is where the actionable feedback lives.

Run NPS surveys quarterly or after major milestones. Don't run them too frequently — survey fatigue is real, and a declining response rate undermines the data. Use the [NPS calculator](/tools/nps-calculator) to compute your score and benchmark it against industry averages.

**Best for:** Measuring overall product sentiment over time. Identifying detractors before they churn.

### 4. CSAT surveys

Customer Satisfaction surveys measure how users feel about a specific interaction or experience. Unlike NPS, which captures general loyalty, CSAT is contextual. You ask "How satisfied were you with this experience?" right after a support conversation, onboarding flow, or feature interaction.

CSAT surveys use a 1-5 scale. Scores of 4 and 5 are considered satisfied. The metric is straightforward to calculate and easy for users to complete — most CSAT surveys take under five seconds.

The key is timing. Send a CSAT survey immediately after the interaction you want to measure. A survey sent two days after a support conversation captures a different (and less accurate) signal than one sent immediately after resolution.

Use the [CSAT calculator](/tools/csat-calculator) to compute your satisfaction percentage and track it over time.

**Best for:** Measuring satisfaction with specific touchpoints. Evaluating support quality, onboarding effectiveness, and feature usability.

### 5. Customer interviews

Interviews give you something surveys and boards cannot: depth. A 30-minute conversation with a user reveals context, motivation, and workflow details that no quantitative method captures.

The best interview subjects are users who recently churned, users who recently converted, and power users who use your product differently than you expected. Each group tells you something distinct. Churned users tell you what's missing. Recent converts tell you what convinced them. Power users tell you what to double down on.

Structure interviews loosely. Start with open-ended questions about their workflow and goals. Avoid leading questions. Don't ask "Would you use feature X?" — ask "How do you currently solve problem Y?" The former gives you a polite yes. The latter gives you insight.

Five interviews often surface patterns that thousands of survey responses miss. The trade-off is that interviews don't scale. They're expensive in time, and the sample is small. Use them to generate hypotheses, then validate those hypotheses with quantitative methods.

**Best for:** Understanding user workflows, motivations, and pain points. Exploring problems you don't fully understand yet.

### 6. Support ticket analysis

Your support team already collects feedback. Every ticket, chat conversation, and email contains signal about what's broken, confusing, or missing. Most teams treat support conversations as individual problems to solve. The opportunity is in the aggregate.

Tag support tickets by theme. Track which issues come up most frequently. Look for patterns in the language users use — if twenty users describe the same problem differently, that's a sign your product's mental model doesn't match theirs.

Support ticket analysis doesn't require any new tooling or user-facing changes. The data already exists. You just need a process to extract patterns from it. Start by reviewing the top ten ticket categories each month. Ask your support team which questions they're tired of answering. Those are your highest-impact improvements.

**Best for:** Identifying usability issues, documentation gaps, and recurring pain points. No additional user effort required.

### 7. Social media and review monitoring

Users say things on Twitter, Reddit, G2, and Capterra that they won't say to you directly. Social and review monitoring captures unfiltered feedback — complaints, praise, and comparisons with competitors.

This channel is particularly useful for understanding how users describe your product to others. The language they use reveals how they perceive your positioning, what they consider your strengths, and where they think you fall short.

Set up alerts for your product name, common misspellings, and competitor names. Review sites like G2 and Capterra are especially valuable because users write structured reviews that cover specific aspects of the product. A pattern of "great product but onboarding is confusing" across fifteen reviews is actionable data.

The limitation is selection bias. People who leave public reviews or post on social media are not representative of your entire user base. They skew toward the very satisfied and the very frustrated. Use this channel to surface issues you might otherwise miss, not as your primary source of truth.

**Best for:** Understanding public perception. Catching issues that users don't report directly. Competitive intelligence.

### 8. Sales call feedback

Your sales team hears every objection, every comparison, and every feature gap that stops a deal from closing. This is feedback from people who evaluated your product and decided it didn't quite meet their needs — or decided it did, despite specific gaps.

Create a lightweight process for sales reps to log the top reason a deal was lost or the top feature request from a won deal. Don't ask for detailed write-ups. A single field — "What was the primary objection or missing feature?" — is enough to start capturing patterns.

Lost deal analysis is especially valuable. If you're consistently losing to a competitor because of a specific integration or capability, that's a prioritization signal that no amount of user voting will surface. Your existing users don't know what your prospects need.

**Best for:** Understanding why prospects choose competitors. Identifying gaps in your product for new market segments.

## How to choose the right feedback method

No single method covers everything. Each has different strengths, and the best programs combine several.

![Feedback method comparison matrix](/blog/collect-customer-feedback/comparison-matrix.webp)

| Method | Best for | Effort to set up | Ongoing effort | Signal type |
|---|---|---|---|---|
| In-app widgets | Continuous collection from active users | Low | Low | Quantitative + qualitative |
| Feature request boards | Prioritizing features by demand | Low | Medium | Quantitative |
| NPS surveys | Tracking loyalty over time | Low | Low | Quantitative |
| CSAT surveys | Measuring specific interactions | Low | Low | Quantitative |
| Customer interviews | Deep understanding of user needs | Medium | High | Qualitative |
| Support ticket analysis | Finding recurring pain points | Low | Medium | Qualitative |
| Social media monitoring | Public perception and competitive intel | Medium | Medium | Qualitative |
| Sales call feedback | Understanding prospect objections | Low | Medium | Qualitative |

Start with the methods that match your stage. Early-stage products benefit most from customer interviews and an in-app widget. As you grow, add a feature request board to scale feedback collection beyond conversations. NPS and CSAT surveys layer on once you have enough users to make the data statistically meaningful.

## Turning feedback into action

Collecting feedback without acting on it is worse than not collecting it at all. Users who submit ideas and never hear back stop contributing. Over time, your feedback channels go silent — not because users have nothing to say, but because they've learned that saying it doesn't matter.

**Prioritize ruthlessly.** Not every request deserves a response, but every request deserves consideration. Group requests by theme. Weight them by frequency, user segment, and strategic alignment. A request from five enterprise customers is different from the same request from five free-tier users. AI can speed up the grouping: Quackback's AI features are built in, and the [MCP server](/features/mcp) lets you query and triage feedback directly from your own tools.

**Close the loop.** When you build something a user requested, tell them. When you decide not to build something, explain why. Closing the loop is the single most effective way to keep users engaged with your feedback program. Users who see their input lead to action become repeat contributors.

**Communicate changes publicly.** A public roadmap shows users what you are working on and what is coming next. It reduces "when will you build X?" questions and builds confidence that feedback is heard. A changelog announces what you shipped and notifies users who voted for those features. Together, they complete the feedback loop: request, prioritize, build, announce.

**Review regularly.** Set a cadence — weekly or biweekly — to review incoming feedback as a team. Don't let requests pile up for months. The faster you triage, the faster you can act, and the more responsive your product feels to users.

## Common feedback collection mistakes

**Asking for feedback everywhere but acting on it nowhere.** Multiple feedback channels create the illusion of listening. If you have a feedback widget, a support inbox, a Slack channel, and a feature request board, but no process to consolidate and prioritize across them, you'll miss patterns and frustrate users who submit the same request in multiple places.

**Surveying too often.** Survey fatigue is real. If users see a popup every time they log in, they stop responding — or worse, they give low-quality answers just to dismiss the prompt. Be intentional about when and how often you ask. NPS once a quarter. CSAT immediately after specific interactions. In-app widgets always available but never intrusive.

**Only listening to the loudest users.** The users who submit the most feedback are not necessarily representative of your user base. Vocal users tend to be power users with specific, sometimes niche, needs. Balance their input with data from broader channels like NPS surveys and support ticket analysis. Look at who isn't giving feedback, too — silent churn is the most expensive kind.

**Treating all feedback equally.** A feature request from a $50,000/year enterprise account and a request from a free-tier user carry different weight. That doesn't mean you ignore the free-tier user, but your prioritization framework should account for business impact. Segment your feedback by user type, plan, and revenue.

**Never explaining why you said no.** Saying no to a request is fine. Ignoring it is not. Users respect transparent prioritization. When you explain that a request doesn't align with your current focus, or that you're solving the underlying problem a different way, users understand. When you say nothing, they assume you don't care.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How often should I collect customer feedback?

Cadence depends on the method. Keep in-app widgets and feature request boards always-on. Run NPS surveys quarterly. Trigger CSAT surveys immediately after the interaction you measure. Schedule customer interviews monthly or around milestones. Aim for continuous input without overwhelming users — declining response rates mean you are asking too often.

### What is the best way to collect feedback for a SaaS product?

Start with two channels: an in-app feedback widget and a public feature request board with voting. The widget captures feedback in context; the board lets users vote on requests, giving you qualitative input and quantitative demand. Layer on NPS, support analysis, and interviews as you grow. See our [best customer feedback tools guide](/blog/best-customer-feedback-tools-2026).

### How do I get more users to give feedback?

Reduce friction. The easier it is to submit feedback, the more you get. An in-app widget beats a separate feedback page. A one-click vote beats a multi-field form. Beyond mechanics, show users that feedback leads to action. Publish a roadmap so they can see priorities. Ship a changelog that references their requests. When users see the loop close, they contribute more. For a broader framework on building a feedback program, see our [user feedback guide](/blog/user-feedback-guide).

### Should I use multiple feedback collection methods at once?

Yes, but consolidate them into a single system. Running five feedback channels that feed into five separate tools creates fragmentation. You lose the ability to see patterns across channels, and users get inconsistent experiences. Pick a primary system — like a [feedback board](/features/feedback) — and route input from other channels (support tickets, sales calls, social mentions) into it. That gives you multiple collection points with a single source of truth for prioritization.

- [AI Survey Analysis: How to Analyze Survey Results With AI](https://quackback.io/blog/ai-survey-analysis): How to use AI to analyze open-ended survey responses at scale. Sentiment analysis, topic clustering, and ready-to-use prompts for ChatGPT and Claude.

Published: 2026-02-01

You have 500 open-ended survey responses. Reading them all takes a full day. Identifying patterns across them takes another. By the time you have findings, the moment has passed — the roadmap meeting happened, the decision was made without the data, or the follow-up survey is already in the field.

AI does that work in seconds. Not perfectly, and not without your judgment — but fast enough that you can iterate on your analysis the same afternoon you export the data.

![AI survey analysis workflow from raw responses to insights](/blog/ai-survey-analysis/hero.webp)

The shift here is not about replacing researchers or product managers. It's about removing the bottleneck between collecting responses and understanding them. When analysis takes a day, you do it once. When it takes seconds, you can slice the data ten different ways, validate your interpretations, and share findings the same day you close the survey.

## What is AI survey analysis

AI survey analysis means using large language models (LLMs) to read, categorize, and summarize open-ended survey responses at scale. It applies the same understanding that makes ChatGPT or Claude useful in conversation to the task of processing hundreds or thousands of text responses automatically.

The key word is open-ended. Closed-ended questions — rating scales, multiple choice, checkboxes — are easy to analyze with basic statistics. Open-ended questions like "What's the biggest thing holding you back?" or "What would you tell a colleague about our product?" require reading comprehension. That's where AI earns its place.

AI survey analysis is not a replacement for human judgment. The model reads and categorizes. You decide what the categories mean, which themes matter, and what to do about them. The analysis augments your thinking — it handles the volume so you can focus on interpretation.

For a broader look at how this fits into your feedback workflow, see our guide to [AI customer feedback analysis](/blog/ai-customer-feedback-analysis).

## What AI can do with survey data

### Sentiment analysis

AI classifies each response as positive, negative, or neutral — and modern models can go further, detecting frustration, enthusiasm, resignation, or uncertainty within a single response. This lets you filter your data by emotional tone before you start reading.

For survey analysis, sentiment is most useful as a triage layer. If you have 500 responses and want to understand what's driving negative sentiment, you can filter to the 120 negative responses and analyze those specifically, rather than reading all 500 to find the pattern.

### Topic clustering

Topic clustering groups responses by theme without you defining the categories in advance. You give the model 500 responses and it returns a structured list of themes — "integration requests," "pricing concerns," "onboarding friction" — with the responses that belong to each group.

This is the most valuable capability for large volumes of data. Instead of reading responses and building a taxonomy manually, you get a working draft of the theme structure automatically. Your job is to review the clusters, rename them where needed, and merge or split any that don't reflect your understanding of the data.

### Keyword extraction

Keyword extraction surfaces the concepts that appear most frequently across your responses. Terms like "slow," "missing," "confusing," or "love" signal what users are focused on. You see the vocabulary your users actually use, which is useful for communicating findings back to users in their own words.

Keyword extraction is a fast first pass. It does not capture meaning — a response saying "I love that it's slow" and a response saying "it's too slow" would both contribute "slow" to the keyword list. Use it alongside sentiment analysis for more accurate signal.

### Duplicate detection

Surveys often produce dozens of responses that express the same idea in different words. "The onboarding took too long," "setup was confusing," and "I didn't understand how to get started" are all the same theme. AI detects semantic similarity — it understands that these responses are related even though they share no keywords.

Identifying duplicates early means you are not counting the same feedback multiple times when you report on volume. It also makes clustering cleaner, because you are working with distinct ideas rather than repeated variations of a small number of themes.

### Summary generation

AI can compress hundreds of responses into a concise summary that captures the main themes, supporting quotes, and distribution of opinions. Instead of attaching a spreadsheet to your findings deck, you share a structured summary with representative examples.

Good summaries include three things: the dominant themes, the minority views that deserve attention, and direct quotes from responses. Quotes matter because they bring the voice of the respondent into the analysis — stakeholders respond differently to data with faces on it.

### Trend detection

If you run surveys at regular intervals — quarterly NPS, monthly satisfaction checks, post-release surveys — AI can compare results across waves and flag emerging themes. A topic that appears in 5% of responses in Q3 and 18% in Q4 is worth investigating, even if it never surfaces in your top-five themes.

Trend detection requires consistent question wording and structured data across waves. It's the most valuable capability for teams with longitudinal data, and the one that most manual analysis processes miss entirely.

## How to analyze survey results with AI

### Step 1: Export your data

Export responses to CSV or plain text. Most survey tools — Typeform, Google Forms, Tally, SurveyMonkey — support CSV export. You want one column per question and one row per respondent.

If you are analyzing one question at a time (recommended), create a separate file or copy just that column's responses.

### Step 2: Clean the responses

Remove blank responses, test submissions, and anything under five words. Standardize the format: one response per line, no quotation marks wrapping the text if possible. Remove any personally identifiable information before passing data to an external AI system.

Cleaning takes five minutes and significantly improves output quality. Garbage in, garbage out applies more to AI analysis than to almost anything else.

### Step 3: Choose your analysis type

Decide what you need before you write a prompt. Sentiment classification, topic clustering, keyword extraction, summarization, and comparison analysis each require different prompts. Do not ask for everything in one request — you get better results from focused, specific prompts than from broad "analyze this" instructions.

### Step 4: Run the analysis

Paste your responses into ChatGPT, Claude, or your AI tool of choice alongside your prompt. For larger datasets, you may need to process responses in batches of 50-100 at a time, depending on context limits.

For tools with API access, you can automate this step and process all responses in a single script. The prompts in the next section work for both manual and automated analysis.

### Step 5: Interpret results

Read the output critically. Check whether the categories make sense. Look for themes the AI may have lumped together that your domain knowledge tells you are distinct. Note what the AI missed or misclassified.

The output is a draft, not a final analysis. It gives you a structured starting point that would have taken hours to produce manually.

### Step 6: Validate with spot-checks

Pick 20-30 responses at random and check whether the AI's classifications match your own judgment. If sentiment is wrong on 1 in 10 responses, that's a 10% error rate — acceptable for many use cases, but worth noting in your findings. If topic clustering puts clearly unrelated responses in the same bucket, adjust your prompt and re-run.

Validation is not optional. Presenting AI-generated analysis without checking it is how confident-sounding errors end up in stakeholder decks.

## Example prompts for survey analysis

### Categorize responses into themes

Use this when you want to understand the main topics across a large set of open-ended responses.

```
You are analyzing open-ended survey responses. Here are [N] responses to the question: "[Your question here]"

[Paste responses, one per line]

Identify the 5-8 most common themes across these responses. For each theme:
- Give it a concise name
- Write a one-sentence description of what it covers
- List the response numbers that belong to it
- Note the approximate percentage of total responses it represents

Return the themes ranked by frequency, most common first.
```

### Extract sentiment with confidence scores

Use this when you need to triage responses by emotional tone before doing deeper analysis.

```
Classify the sentiment of each survey response below as Positive, Negative, or Neutral. Also provide a confidence score from 1-5 (1 = uncertain, 5 = highly confident).

Format your response as a table with columns: Response Number | Sentiment | Confidence | Brief reason

Responses:
[Paste responses, numbered 1, 2, 3...]
```

### Summarize top themes with representative quotes

Use this to produce a shareable summary of findings for stakeholders who will not read the raw data.

```
Here are [N] responses to the survey question: "[Your question here]"

[Paste responses]

Produce a structured summary with:
1. The 5 most prominent themes, ranked by frequency
2. For each theme: a 2-3 sentence description of what respondents are saying
3. 2-3 direct quotes from the responses that best represent each theme (preserve exact wording)
4. A note on any minority views that appear in fewer than 10% of responses but deserve attention

Keep the summary concise enough to fit in a slide or a short document section.
```

### Compare responses between user segments

Use this when you have survey data from two different groups and want to understand how their responses differ. This is particularly useful for [qualitative vs quantitative feedback](/blog/qualitative-vs-quantitative-feedback) analysis workflows.

```
I have open-ended survey responses from two user segments responding to the same question: "[Your question here]"

Segment A ([describe who they are]):
[Paste Segment A responses]

Segment B ([describe who they are]):
[Paste Segment B responses]

Compare the two segments:
1. What themes appear in both segments?
2. What themes are unique to Segment A?
3. What themes are unique to Segment B?
4. How does the sentiment differ between the two segments?
5. What is the single most important difference in how these groups responded?
```

### Identify feature requests vs bug reports vs praise

Use this when analyzing support surveys, post-purchase surveys, or NPS follow-up questions where responses mix different types of feedback.

```
Classify each response below into one of four categories:
- Feature request: The respondent wants something that does not currently exist
- Bug report: The respondent is describing something that is broken or not working as expected
- Praise: The respondent is expressing satisfaction or appreciation
- Other: None of the above

For each response, provide: Response number | Category | One-sentence summary of the specific item

Responses:
[Paste responses, numbered]

After the classifications, provide a count of how many responses fall into each category.
```

### Extract top keyword concepts

Use this as a fast first pass when you want to see the vocabulary your respondents are using before doing deeper analysis.

```
Read these [N] survey responses and extract the 20 most significant concepts or keywords across all of them.

[Paste responses]

For each keyword or concept:
- List the term
- Note approximately how many responses mention it
- Indicate whether it appears in a positive, negative, or neutral context most often

Group the keywords by theme if natural groupings are apparent.
```

## AI survey analysis tools

### Quackback

[Quackback](https://quackback.io) is built for ongoing feedback collection and analysis rather than one-time survey processing. It includes built-in sentiment analysis, duplicate detection, and AI summaries for every piece of feedback on your board. You connect your own LLM API key, so there are no per-use charges from Quackback.

Where Quackback is particularly useful for survey workflows is the [MCP server](/blog/mcp-server-feedback-management), which lets AI agents in Claude, Cursor, and other tools interact with your feedback data directly. If you run regular surveys and want to track themes over time, Quackback gives you a structured environment that manual prompt-based analysis does not. For [NPS survey](/blog/nps-survey-template) follow-up responses or [customer satisfaction survey](/blog/customer-satisfaction-survey-template) open-ends, the ongoing analysis workflow fits well.

### ChatGPT and Claude

The prompts in this post work directly in ChatGPT or Claude's web interface. Paste your responses, add your prompt, and get structured output in seconds. This is the right approach for one-time analyses or teams that do not yet have a dedicated feedback tool.

The limitation is scale. Free and standard tiers have context window limits that constrain how many responses you can process at once. For large surveys, you will process responses in batches and combine the outputs manually. Claude's extended context window (up to 200K tokens on paid plans) handles larger batches than most alternatives.

### MonkeyLearn

MonkeyLearn is a text analysis API that offers pre-trained sentiment and topic classification models, plus the ability to train custom classifiers on your own data. It integrates with Zapier, Make, and most survey tools directly.

The trade-off is setup time. Pre-trained models work reasonably well out of the box, but getting high accuracy on domain-specific feedback usually requires training a custom model — which requires labeled training data. MonkeyLearn is a good choice for teams with recurring, high-volume analysis needs who want a more automated pipeline than manual prompting.

### Thematic

Thematic is a purpose-built survey analysis tool designed specifically for open-ended response analysis. It identifies themes automatically, tracks them across survey waves, and produces structured reports with trend data. Pricing is higher than general-purpose AI tools, but the workflow is more polished for survey-specific use cases.

Thematic is worth evaluating if you run large-scale surveys regularly (thousands of responses per wave) and need presentation-ready output rather than raw analysis you format yourself.

## Limitations of AI survey analysis

AI survey analysis is useful, but it is not infallible. Understanding the limitations helps you use it well rather than trust it blindly.

**Nuance requires human review.** AI models handle direct, literal feedback well. They struggle with sarcasm, irony, and responses where the meaning depends on cultural or organizational context. A response like "great, another update that breaks my workflow" reads as negative to a human but may be misclassified by a model that weights "great" positively. Review a sample of classifications yourself before presenting findings.

**Sample size matters.** Topic clustering on 50 responses produces noisy, over-broad categories. The same analysis on 500 responses produces meaningful, stable themes. AI amplifies the signal in your data — if there is not much signal, the output will not be useful. There is no substitute for sufficient response volume.

**Prompt engineering affects quality.** The prompts in this post are a starting point, not finished tools. The quality of AI output depends heavily on how you frame the task, how much context you provide, and how specifically you define what you want. Expect to iterate on prompts before you get output you are comfortable sharing.

**Categorizations can be wrong.** AI assigns responses to categories based on pattern matching, not understanding. A response about "slow customer support" and a response about "slow load times" might both be classified under "performance" if your prompt is not specific about what performance means in your context. Check the edges of every category.

**Do not skip validation.** The most common mistake with AI analysis is presenting the output as findings without checking it. Spot-check a random sample of every analysis before you share it. A 5-10% error rate is acceptable in many contexts; finding that rate after presenting findings is not.

## Frequently asked questions

### Can AI analyze survey responses accurately?

For straightforward sentiment classification and topic clustering, modern LLMs produce reliable results — typically 85-95% accuracy on clear, direct feedback. Accuracy drops on sarcasm, nuanced language, and responses that require domain knowledge to interpret correctly. The practical approach is to use AI for the first pass and validate with a manual spot-check of 20-30 responses. If the error rate is acceptable for your use case, proceed. If not, refine your prompt and re-run.

### How many survey responses do I need for AI analysis to be useful?

AI analysis adds the most value at scale, but there is no hard minimum. Even 50 responses benefit from AI sentiment classification and keyword extraction. Topic clustering becomes meaningful around 100-150 responses, where natural themes start to emerge with enough examples to be reliable. Trend detection across survey waves typically requires at least 200 responses per wave to produce stable results. Below 50 responses, manual reading is usually faster and more accurate than AI analysis.

### Is it safe to paste survey responses into ChatGPT or Claude?

It depends on what the responses contain and what your privacy commitments are to respondents. If responses contain personally identifiable information (names, email addresses, company names), remove that before pasting. Check whether you promised anonymity in your survey consent language. OpenAI and Anthropic both offer options to opt out of using your data for model training — check the settings in your account and review the terms of service for your plan. For sensitive surveys (healthcare, HR, legal), use API access with a data processing agreement in place, or run a local model.

- [Marketing Roadmap: Template and 5-Step Framework (2026)](https://quackback.io/blog/marketing-roadmap): A practical guide to building a marketing roadmap. Align campaigns with product launches, track initiatives, and communicate plans across teams.

Published: 2026-01-29

Most marketing teams operate in a constant state of reaction. A product launch moves up two weeks, a competitor drops a new feature, a conference slot opens. Without a roadmap, every shift creates chaos. With one, it creates a conversation.

![Marketing roadmap planning illustration](/blog/marketing-roadmap/hero.webp)

> A **marketing roadmap** is a strategic plan that maps your marketing initiatives across a timeline, connecting business goals to the campaigns, content, and events that support them. To build one, define goals tied to business objectives, map campaigns to product milestones, prioritize by impact, assign owners and timelines, then share with stakeholders and review monthly. The result keeps marketing aligned with product instead of reacting to it.

A marketing roadmap is the document that turns strategy into a sequence of coordinated actions. It shows what you are doing, when you are doing it, and why it matters to the business. It keeps campaigns aligned with product milestones, gives stakeholders visibility, and helps your team say no to the right things.

This guide covers what a marketing roadmap includes, how to build one step by step, and how to keep it useful after the first week.

## What is a marketing roadmap?

A marketing roadmap is a strategic plan that maps your marketing initiatives across a timeline. It connects high-level business goals to the specific campaigns, content, events, and channel strategies that support them.

It is not a task list. A task list tells your team what to do today. A roadmap tells them where they are headed this quarter and why.

Think of it as the bridge between your annual marketing strategy and your weekly execution. The strategy says "increase product-qualified leads by 40%." The roadmap says "launch a comparison content series in Q2, run a webinar campaign in Q3, and sponsor two industry events in Q4." The task list says "write the first comparison post by Friday."

A good marketing roadmap does three things:

- **Aligns marketing with product and sales.** When your product team ships a feature, marketing should already have launch assets ready. When sales needs new collateral, it should already be in the pipeline.
- **Creates shared understanding.** Leadership, product, sales, and marketing all see the same plan. Disagreements happen early, not the week before launch.
- **Forces prioritization.** You cannot do everything. A roadmap makes trade-offs visible and deliberate.

Marketing roadmaps work at different time horizons. Some teams plan quarterly. Others maintain a rolling six-month view. Annual roadmaps exist but tend to break down after the first quarter. Start with the shortest horizon that gives your team enough lead time to execute well.

## What to include in a marketing roadmap

Every marketing roadmap looks different, but the effective ones share a common structure. Here are the elements worth including.

**Campaigns and initiatives.** These are the major efforts your team will run. A product launch campaign, a brand awareness push, a seasonal promotion, a content series. Each one should have a clear objective, a start and end date, and an owner.

**Content calendar.** Blog posts, case studies, whitepapers, videos, social media series. Map these to your campaigns so content supports broader goals rather than existing in isolation. If you are running a product launch campaign, the content calendar should include posts that build anticipation, explain the feature, and show it in action.

**Product launches and milestones.** Your marketing roadmap should reference your [product roadmap](/features/roadmap) directly. When the product team plans to ship a feature, marketing needs lead time for positioning, messaging, launch emails, and documentation. Misalignment here is one of the most common reasons marketing feels reactive.

**Events and partnerships.** Conferences, webinars, co-marketing campaigns, community events. These have long lead times and fixed deadlines, so they anchor the rest of your timeline.

**Channel strategy.** Which channels you will invest in and when. Paid search, organic content, email, social, partnerships, community. Not every channel runs at full capacity all the time. Your roadmap should reflect where you are concentrating effort in each period.

**Goals and KPIs.** Every initiative on the roadmap should connect to a measurable outcome. Traffic, leads, signups, pipeline, revenue. If you cannot explain how a campaign moves a number, question whether it belongs on the roadmap.

## How to build a marketing roadmap

### Step 1: Define marketing goals aligned to business objectives

Start with what the business needs. Not what marketing wants to try.

If the company goal is to enter a new market segment, your marketing goals might include building awareness in that segment, generating qualified leads from target accounts, and creating positioning that resonates with a new buyer persona.

If the company goal is to reduce churn, your marketing goals might focus on customer education, onboarding content, and feature adoption campaigns.

Write down three to five marketing goals for the period. Each one should trace directly to a business objective. If you find yourself writing goals like "increase social media followers," ask what business outcome that serves. If the answer is unclear, cut it.

### Step 2: Map campaigns to product milestones

Pull in your product team's roadmap and [changelog](/features/changelog). Identify every feature launch, major update, and milestone on their timeline. Then map your marketing campaigns to support them.

For each product milestone, define:

- **Pre-launch:** Teaser content, beta access campaigns, landing page updates
- **Launch day:** Announcement email, blog post, social campaign, press outreach
- **Post-launch:** Case studies, how-to content, feature adoption emails

This is where most marketing teams fall short. They learn about a product launch a week before it ships and scramble to put together a blog post. Building your marketing roadmap alongside the product roadmap eliminates that scramble.

If your product team publishes a public roadmap or changelog, use those as your source of truth. When a feature moves from "planned" to "in progress," that is your signal to start preparing marketing assets. When it moves to "shipped," your launch campaign should already be ready to go.

### Step 3: Prioritize by impact

Marketing teams are idea factories. The constraint is never "what could we do?" but "what should we do this quarter?" Prioritization separates a useful roadmap from a wish list.

Score each initiative by expected impact on your goals, confidence in that estimate, and effort to execute. The [RICE scoring framework](/tools/rice-scoring-calculator) works well here. A webinar series that reaches 500 prospects with high conversion confidence and moderate effort scores higher than a brand video that reaches 10,000 people with low conversion confidence and high effort. The numbers make the decision obvious.

Rank your initiatives by score. Draw a line where your team's bandwidth runs out. Everything above the line goes on the roadmap. Everything below goes on a backlog for future consideration.

### Step 4: Assign ownership and timelines

Every initiative on your roadmap needs an owner and a timeline. Not a team. A person.

The owner is not necessarily doing all the work. They are responsible for making sure the work gets done, dependencies are managed, and the initiative ships on time. If no one owns it, it will not happen.

For timelines, define:

- **Planning window:** When strategy and messaging are finalized
- **Production window:** When assets are created and reviewed
- **Launch date:** When the campaign goes live
- **Review date:** When you assess results and capture learnings

Work backwards from launch dates. If a product feature ships on March 15, and you need two weeks of production time and one week of planning, your planning window starts February 22. Put that on the roadmap.

Be honest about your team's bandwidth. A roadmap with twelve simultaneous campaigns and a team of three is not ambitious. It is fiction.

### Step 5: Share with stakeholders and iterate

Marketing roadmaps fail when they stay inside marketing. A campaign planned without input from product, sales, or customer success will miss context that makes it better (or reveals that it is unnecessary).

Share your roadmap with product, sales, customer success, and leadership. The goal is not to get approval on every line item. The goal is to surface conflicts, dependencies, and opportunities early.

Product might tell you a launch date moved. Sales might flag that a particular segment needs collateral sooner. Customer success might point out that a feature you planned to market is actually causing support tickets. All of this is useful information that makes your roadmap better.

Review the roadmap on a regular cadence. Monthly works for most teams. Quarterly reviews are too infrequent because the roadmap drifts from reality. Weekly reviews are too frequent and turn strategic planning into status updates.

At each review, ask three questions:

1. What shipped since the last review, and what did we learn?
2. What changed in the business, product, or market that affects our plan?
3. What do we need to add, remove, or reprioritize?

![Marketing roadmap timeline showing campaign phases aligned to product milestones and quarterly KPIs](/blog/marketing-roadmap/campaign-phases-timeline.webp)

## Marketing roadmap template

Here is a simple template to get started. Adjust columns to match your team's workflow.

| Initiative | Goal | Owner | Channel | Start | Launch | Status |
|---|---|---|---|---|---|---|
| Q2 product launch campaign | 500 signups | Sarah | Email, blog, social | Apr 1 | Apr 22 | Planning |
| Comparison content series | 2,000 organic visits/mo | Alex | Blog, SEO | Apr 15 | May 1 | Not started |
| Customer webinar series | 50 qualified leads | Jordan | Webinar, email | May 1 | May 20 | Not started |
| Industry conference sponsorship | 200 booth conversations | Sarah | Events | Jun 1 | Jul 15 | Confirmed |
| Feature adoption email sequence | 30% feature activation | Alex | Email | Apr 22 | May 5 | Blocked on product |

Add a row for each initiative. Keep it at a level of detail that is useful in a stakeholder meeting. Detailed task breakdowns belong in your project management tool, not on the roadmap.

## Marketing roadmap examples

### Product launch roadmap

A product launch roadmap centers everything around a ship date. Work backwards from launch to schedule pre-launch teasers, landing page updates, beta invitations, press outreach, launch day announcements, and post-launch content.

For a SaaS product launching a new feature, this might span four to six weeks. Two weeks of pre-launch content and landing page preparation. Launch week with the announcement blog post, email blast, and social campaign. Two weeks of post-launch case studies, tutorials, and feature adoption emails.

The key is connecting marketing back to the product milestone. When the feature ships, your marketing campaign should already be in motion.

### Content marketing roadmap

A content marketing roadmap plans your publishing calendar around topics, keywords, and funnel stages. It maps content to campaigns and business goals rather than publishing for the sake of publishing.

Start by identifying the topics that support your current quarter's goals. Group them into clusters. Schedule production so you publish consistently without burning out your writers. Track each piece from ideation through publication and promotion.

A quarterly content roadmap might include ten blog posts, two case studies, one whitepaper, and a webinar. Each piece ties to a specific campaign or keyword target. Each has an owner, a deadline, and a distribution plan.

### Brand awareness roadmap

A brand awareness roadmap focuses on reaching new audiences and establishing recognition in your market. It typically spans six to twelve months and emphasizes consistency over individual campaigns.

This roadmap might include a conference sponsorship strategy, a thought leadership content series, a partnerships program, and a community building effort. The metrics are different from direct response: share of voice, branded search volume, social mentions, and press coverage.

Brand awareness roadmaps require patience. Results compound over months, not days. The roadmap keeps the team committed to the strategy when short-term metrics look flat.

## Tools for marketing roadmaps

You can build a marketing roadmap in a spreadsheet. Many teams do, and it works fine for small teams with simple plans.

As your team grows, dedicated tools help. Common project management platforms like Asana, Monday, Notion, and Linear offer timeline and roadmap views that work well for marketing planning. They handle assignments, dependencies, and status tracking.

If your marketing roadmap needs to stay tightly aligned with your product roadmap, consider a shared roadmap tool that both teams reference. [Quackback](/features/roadmap) is built for this: it is open source and self-hosted or run on [Quackback Cloud](/pricing), so your whole marketing team can share it. When marketing and product share a single source of truth for what is planned, in progress, and shipped, alignment happens by default rather than by meeting.

Quackback also ships an [MCP server](/features/mcp), so your marketing team can query the product roadmap directly from an AI assistant. Ask "what features ship next quarter?" or "what changed since the last release?" and get answers from the live roadmap without booking time with product. That turns the roadmap from a static document into a source your launch planning can interrogate on demand.

For communicating shipped work to your audience, a public [changelog](/features/changelog) bridges the gap between internal roadmap updates and external announcements. When a feature ships, the changelog entry becomes the foundation for your marketing launch content. Blog posts, emails, and social updates all reference the same announcement.

The specific tool matters less than the habit. Pick something your team will actually update, and review it regularly. For roadmap tooling options, see our guide to [best public roadmap tools](/blog/best-public-roadmap-tools) and [best changelog tools](/blog/best-changelog-tools).

If you're building roadmaps for other functions, see the [technology roadmap guide](/blog/technology-roadmap) for engineering-focused planning or the [IT roadmap guide](/blog/it-roadmap-guide) for infrastructure and compliance.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How often should you update a marketing roadmap?

Review a marketing roadmap monthly. Monthly reviews give you time to see results from recent campaigns while staying responsive to changes in the business or market. Update status and dates between reviews so it stays current. Daily updates mean it is too detailed; quarterly ones mean it is not embedded.

### What is the difference between a marketing roadmap and a marketing plan?

A marketing plan defines overall strategy: target audience, positioning, messaging, budget, and goals. A marketing roadmap translates that strategy into a timeline of specific initiatives. The plan answers "what and why." The roadmap answers "when and in what order." Teams need both, but reference the roadmap week to week.

### How do you handle roadmap changes when priorities shift?

Keep a ranked backlog of initiatives that did not make the cut, then swap one in when a priority drops off. When a priority changes, update the roadmap immediately and tell stakeholders why. If you cancel a campaign for a launch, say so explicitly so the roadmap matches the work.

- [Technology Roadmap: A Complete Guide for Product Teams](https://quackback.io/blog/technology-roadmap): How to create a technology roadmap that aligns engineering with product goals. Includes templates, examples, and a step-by-step process.

Published: 2026-01-28

A technology roadmap is one of the most misunderstood documents in software organizations. Teams confuse it with a product roadmap. Or they treat it as a list of tools they want to adopt. Or they build one, file it away, and never look at it again.

![Technology roadmap planning illustration](/blog/technology-roadmap/hero.webp)

Done well, a technology roadmap gives your engineering team a shared plan for how the platform evolves. It connects technical decisions to business outcomes. It makes trade-offs visible before they become emergencies. And it keeps your stack from drifting into something nobody planned for.

This guide covers what a technology roadmap is, how it differs from a product roadmap or an [IT roadmap](/blog/it-roadmap-guide), and a step-by-step process for building one that actually gets used.

## What is a technology roadmap?

A technology roadmap is a strategic document that outlines how your technology platform will change over time. It covers decisions about your tech stack, architecture, infrastructure, and developer tooling, organized into phases with clear milestones.

Unlike a task list or sprint board, a technology roadmap operates at a higher altitude. It answers questions like:

- When do we migrate from the monolith to services?
- What does our database strategy look like in 12 months?
- Which platform investments will reduce deployment time by half?
- Where are we accumulating technical debt that will slow feature delivery?

The audience is your engineering team, but also your product managers, designers, and leadership. Everyone should be able to look at your technology roadmap and understand where the platform is headed and why.

A good technology roadmap has three properties. It is time-bound (organized into phases or quarters). It is outcome-oriented (each initiative ties to a measurable result). And it is maintained (updated at least quarterly, not left to rot).

## Technology roadmap vs product roadmap

These two documents serve different purposes. Confusing them leads to misaligned priorities and frustrated teams.

**Product roadmap:** What you are building for users. Features, improvements, new capabilities. It is organized around user problems and business goals. The audience includes product managers, designers, sales, marketing, and leadership.

**Technology roadmap:** How you are building and evolving the underlying platform. Architecture changes, infrastructure upgrades, tooling improvements, technical debt reduction. The audience is primarily engineering and technical leadership, though product and business leaders benefit from visibility.

Here is a simple way to think about the distinction:

| | Product roadmap | Technology roadmap |
|---|---|---|
| Focus | User-facing features | Platform and infrastructure |
| Driven by | Customer needs, market opportunity | Engineering capacity, scalability, risk |
| Audience | Cross-functional | Primarily engineering |
| Time horizon | Quarters to a year | 6 months to 2 years |
| Success metric | Adoption, revenue, satisfaction | Performance, reliability, velocity |

The two roadmaps should inform each other. If the product roadmap calls for real-time collaboration features, the technology roadmap needs to account for WebSocket infrastructure. If the technology roadmap includes a database migration, the product roadmap should plan for a feature freeze during the transition.

Teams that only maintain a product roadmap tend to defer technical work until it becomes urgent. Teams that only maintain a technology roadmap risk building a platform that doesn't serve the product. You need both.

A [marketing roadmap](/blog/marketing-roadmap) is a third variant, focused on campaigns, launches, and content. All three roadmaps should share the same planning cadence so they stay in sync.

## How to create a technology roadmap

Building a technology roadmap is a six-step process. It does not require specialized software. A document, a spreadsheet, or a shared board will work. What matters is the thinking behind it.

### Step 1: Assess your current tech stack

Start with an honest inventory of what you have. Document your languages, frameworks, databases, hosting providers, CI/CD pipeline, monitoring tools, and third-party services. Note versions. Note ownership (which team maintains what).

This assessment should answer two questions: What is the current state of our technology? And where are the boundaries between systems?

Do not skip this step. Teams that jump straight to planning often discover mid-execution that they misunderstood their own architecture. Dependencies that seemed simple turn out to be tangled. Services that seemed independent share a database.

Write it down. A diagram helps, but a clear list works too.

### Step 2: Identify technical debt and risks

Every codebase accumulates technical debt. Some of it is intentional (you shipped fast to hit a deadline). Some of it is accidental (nobody noticed the coupling until it was deeply embedded).

Catalog the debt. Talk to your engineers. They know where the pain is. Common categories include:

- **Outdated dependencies.** Libraries or frameworks that are multiple major versions behind, approaching end of life, or no longer maintained.
- **Scaling bottlenecks.** Components that work at current load but will fail at 2x or 10x. Database queries that degrade under volume. Services that cannot be horizontally scaled.
- **Security risks.** Unpatched vulnerabilities, weak authentication patterns, secrets management gaps.
- **Developer experience friction.** Slow builds, flaky tests, manual deployment steps, poor local development environments.
- **Architectural coupling.** Systems that should be independent but share state, databases, or deployment pipelines.

Rank these by impact and urgency. Not all debt needs immediate attention. Some debt is fine to carry for another year. Other debt is actively slowing your team or exposing you to risk.

### Step 3: Align with product and business goals

A technology roadmap that ignores the product roadmap will lose organizational support. Engineering leadership has to connect technical initiatives to outcomes that product and business stakeholders care about.

For each initiative on your roadmap, answer: What does this enable? Some examples:

- Migrating to a CDN reduces page load time, which improves conversion rates.
- Adopting feature flags lets the product team run A/B tests without engineering support.
- Breaking apart the monolith lets teams ship independently, reducing release bottlenecks.
- Upgrading the search infrastructure supports the product roadmap item for advanced filtering.

If you cannot articulate why a technical initiative matters to the business, reconsider whether it belongs on the roadmap right now.

### Step 4: Prioritize initiatives

Engineering teams consistently underestimate how long platform work takes, which makes prioritization critical. You cannot afford to sequence incorrectly.

The [RICE scoring model](/tools/rice-scoring-calculator) (Reach, Impact, Confidence, Effort) works for technology roadmap items, not just product features. Score "migrate to read replicas" the same way you would score a feature: how many services does it affect (Reach), how much does it improve performance or reliability (Impact), how sure are you about the estimates (Confidence), and how many person-months does it take (Effort).

Beyond RICE, apply these lenses:

- **Dependencies.** Some initiatives unblock others. Map the dependency graph and sequence accordingly. A database migration might need to precede the service extraction that depends on it.
- **Risk reduction.** Initiatives that reduce the probability or blast radius of outages often deserve priority over feature-enabling work. If a single-point-of-failure takes down your product twice a quarter, that is your top priority regardless of what RICE says.
- **Reversibility.** Prefer reversible decisions over irreversible ones when priority is unclear. Adopting a new framework for one service is reversible. Rewriting your data model is not.

Avoid prioritizing based on enthusiasm alone. The thing your team is most excited about is not always the thing that matters most.

![Technology roadmap with infrastructure, platform, and application layers showing dependencies and sequencing](/blog/technology-roadmap/tech-roadmap-layers.webp)

### Step 5: Define phases and milestones

Organize your prioritized initiatives into phases. Three to four phases over 12 months is a reasonable structure. Each phase should have:

- A clear theme (e.g., "Foundation" or "Scale" or "Developer experience")
- Two to five initiatives
- Measurable milestones (not just "done" but a specific outcome like "p95 API latency under 200ms" or "deploy pipeline runs in under 5 minutes")
- A rough timeline (quarter, not exact dates)

Resist the urge to plan too precisely. A technology roadmap is a strategic document, not a sprint plan. If your milestones include specific Jira tickets, you have gone too deep.

Leave buffer. Technical work is harder to estimate than feature work because you are often changing systems while they are running. Budget 20-30% more time than your initial estimate.

### Step 6: Share and collect feedback

The biggest risk to a technology roadmap is that it stays inside engineering. Product managers make commitments that conflict with it. Leadership allocates budget without knowing about it. Designers plan features that depend on infrastructure changes they have never seen.

Present the roadmap at a cross-functional planning meeting. Walk through the phases, explain why each initiative matters to the product, and flag where engineering needs coordination from other teams. Post it somewhere product managers can reference it when planning their own roadmap.

Some teams also make their technology roadmap visible to customers through a [public roadmap](/features/roadmap). This builds trust, especially when users can see that you are investing in reliability or performance.

Collect feedback after sharing. Engineers closest to the systems will catch gaps. Product managers will flag conflicts with their priorities. Schedule a review two weeks after publishing to incorporate that input.

The roadmap is not final once published. It is a living document that improves through input.

## Technology roadmap template

Here is a minimal template you can adapt. Start simple. Add complexity only when you need it.

| Phase | Initiative | Goal | Success metric | Target quarter |
|---|---|---|---|---|
| Foundation | Upgrade Node.js to v22 LTS | Reduce security exposure, access new APIs | All services running v22 | Q2 2026 |
| Foundation | Centralize logging | Single pane of glass for debugging | All services shipping logs to Datadog | Q2 2026 |
| Scale | Migrate primary DB to read replicas | Handle 3x current read traffic | Read queries served by replicas, primary load reduced 60% | Q3 2026 |
| Scale | Implement CDN for static assets | Reduce origin load, improve global latency | p50 asset load time under 80ms globally | Q3 2026 |
| Velocity | Adopt feature flags | Decouple deploys from releases | Product team can toggle features without eng support | Q4 2026 |
| Velocity | Parallelize CI pipeline | Faster feedback loop for developers | CI runs complete in under 4 minutes | Q4 2026 |

You can maintain this in a spreadsheet, a Notion doc, or a purpose-built roadmap tool. The format matters less than the discipline of keeping it current.

## Technology roadmap examples

Three common technology roadmap patterns that product teams encounter.

### Example 1: Monolith to microservices

A B2B SaaS company has a Rails monolith. It works, but deploys take 45 minutes, a bug in billing brings down the entire application, and two engineering teams step on each other constantly.

Their technology roadmap:

- **Q1:** Extract the billing service. It has the clearest domain boundary and the highest blast radius when it fails.
- **Q2:** Build a shared authentication layer so extracted services can verify users without calling back to the monolith.
- **Q3:** Extract the notification service. Reduce coupling between feature teams.
- **Q4:** Establish service mesh and observability. Distributed tracing across all services.

Each phase delivers a concrete improvement. Teams can ship billing changes without deploying the whole application after Q1. The monolith does not disappear in one quarter. It shrinks gradually.

### Example 2: Frontend framework migration

A product team is running an aging Angular.js application. The framework is end-of-life. Hiring is difficult because candidates do not want to work with it. The component library is brittle.

Their technology roadmap:

- **Q1:** Adopt a micro-frontend shell. New features are built in React. Existing pages stay in Angular.js.
- **Q2:** Migrate the three highest-traffic pages to React. Measure performance improvement.
- **Q3:** Migrate remaining pages. Retire the Angular.js build pipeline.
- **Q4:** Consolidate the design system. Shared component library for all React surfaces.

The key decision here is the strangler fig pattern: new code uses the new framework, old code migrates page by page. No big rewrite. No feature freeze.

### Example 3: Platform scalability

A consumer app is growing 40% quarter over quarter. The database is a single PostgreSQL instance. Background jobs run on the same server as the API. The team has already hit capacity limits twice, both times on weekends.

Their technology roadmap:

- **Q1:** Add read replicas. Route all read-heavy queries (dashboards, reports, search) to replicas.
- **Q2:** Separate background job processing onto dedicated workers. Introduce a job queue (Redis-backed).
- **Q3:** Implement connection pooling and query optimization. Target 50% reduction in average query time.
- **Q4:** Evaluate horizontal scaling options. Prepare for sharding or a managed database service if growth continues.

Each quarter addresses the next bottleneck. The team is not over-engineering for scale they do not have yet. They are staying one step ahead of the growth curve.

## Tips for maintaining your technology roadmap

A roadmap is only useful if it stays current. Here is how to keep it alive.

**Review quarterly.** Set a calendar reminder. At the start of each quarter, review what shipped, what slipped, and what changed. Update the roadmap accordingly. This is also the right time to re-prioritize based on new information.

**Connect to user feedback.** Technical decisions affect users even when users cannot see the infrastructure. If your customers are reporting slow load times, that validates the CDN initiative on your roadmap. If support tickets mention downtime, that supports the reliability work. Closing the loop between user feedback and technical investment helps justify the work to stakeholders.

**Keep it visible.** Pin it in your engineering Slack channel. Reference it in sprint planning. When someone asks "why are we doing this?" point to the roadmap. Visibility creates accountability.

**Accept that it will change.** A production incident that reveals architectural fragility can reprioritize your entire Q3 plan overnight. A key hire joining the team might unlock an initiative you deferred. The roadmap should adapt. What should not change frequently is the strategic direction. Individual initiatives may move between quarters. The overall trajectory should stay stable.

**Own it.** Assign a single person (usually a VP of Engineering, CTO, or Staff Engineer) as the owner. They are responsible for updates, quarterly reviews, and cross-functional communication. Without an owner, the roadmap drifts.

## Frequently asked questions

### How often should you update a technology roadmap?

Review it quarterly. Make minor updates as needed between reviews, but a full reassessment every three months keeps it aligned with business reality. Avoid updating it so frequently that it loses strategic coherence. If your roadmap changes every sprint, it is not a roadmap. It is a backlog.

### What tools should you use to build a technology roadmap?

Start with whatever your team already uses. A Google Doc, a Notion page, or a simple spreadsheet works for most teams. If you want to make it visible to non-engineering stakeholders or customers, consider a dedicated roadmap tool like [Quackback](https://quackback.io) that provides status updates and a [shareable public view](/features/roadmap) without maintaining a separate document. For more options, see our guide to [best public roadmap tools](/blog/best-public-roadmap-tools).

### How does a technology roadmap differ from an IT roadmap?

A technology roadmap focuses on your product's tech stack, architecture, and engineering platform. An [IT roadmap](/blog/it-roadmap-guide) typically covers internal infrastructure: corporate networks, employee devices, SaaS tool procurement, security compliance, and identity management. In smaller companies, these overlap. In larger organizations, they are maintained by different teams with different stakeholders.

- [IT Roadmap: How to Build One That Actually Gets Used](https://quackback.io/blog/it-roadmap-guide): How to build an IT roadmap that gets used. Templates, examples, and a step-by-step process for IT leaders planning infrastructure and security.

Published: 2026-01-27

Most IT roadmaps fail. Not because the technology decisions are wrong, but because the roadmap itself never leaves the slide deck it was born in. It gets presented once, filed somewhere in SharePoint, and ignored until the next planning cycle.

![IT roadmap planning illustration](/blog/it-roadmap-guide/hero.webp)

The failure modes are predictable. The roadmap is too vague to be actionable. It lists technologies instead of outcomes. It isn't connected to business goals, so leadership doesn't care. Or it's treated as a static document instead of a living plan, so it's outdated within weeks.

A good IT roadmap does three things: it communicates priorities to the business, it sequences work so the team knows what to build and when, and it evolves as conditions change. This guide covers how to build one that does all three.

## What is an IT roadmap?

An IT roadmap is a strategic document that maps IT initiatives to business objectives over a defined time horizon. It shows what the IT organization plans to do, why each initiative matters, and roughly when it will happen.

It is not a project plan. A project plan details tasks, assignees, dependencies, and deadlines for a single initiative. A roadmap operates one level up. It shows the portfolio of initiatives and how they relate to each other and to the business.

Think of it this way: the roadmap answers "what are we investing in and why?" The project plan answers "how are we executing this specific investment?"

IT roadmaps serve multiple audiences. Engineering teams use them to understand priorities and plan capacity. Business leaders use them to see how IT spending connects to revenue, risk reduction, or operational efficiency. Finance uses them to forecast budgets. And the IT leadership team uses them to make trade-off decisions when new requests come in.

The best IT roadmaps are readable by non-technical stakeholders. If your roadmap requires a glossary to interpret, it's not doing its job.

## Types of IT roadmaps

Not all IT roadmaps cover the same ground. The scope depends on what your organization needs to communicate and coordinate. Here are the most common types.

**Infrastructure roadmap.** Covers hardware, networking, data centers, and core systems. Typical initiatives include server refreshes, network upgrades, storage migrations, and disaster recovery improvements. Time horizons tend to be longer (12-36 months) because infrastructure changes are expensive and disruptive.

**Security roadmap.** Focuses on reducing risk and achieving compliance. Initiatives include zero trust architecture rollouts, endpoint detection and response deployments, SOC 2 or ISO 27001 certification, vulnerability management programs, and identity governance projects. Security roadmaps often have external deadlines (regulatory requirements, audit dates) that constrain sequencing.

**Application modernization roadmap.** Tracks the migration of legacy applications to modern architectures. This might mean moving monoliths to microservices, migrating from on-premises databases to managed services, or replacing end-of-life software. These roadmaps need to account for business continuity, since the systems being modernized are usually the ones the business depends on most.

**Cloud migration roadmap.** Specifically focused on moving workloads from on-premises to cloud infrastructure (or between cloud providers). Initiatives are typically grouped into waves based on complexity, risk, and dependency. A cloud migration roadmap needs to track cost implications, since cloud spending can surprise organizations that don't model it carefully.

**Digital transformation roadmap.** The broadest type. Covers organization-wide technology changes that affect how the business operates. This might combine elements of all the above types, plus initiatives around data analytics, automation, employee experience, and customer-facing technology. Digital transformation roadmaps require the most cross-functional alignment because they touch every department.

You don't need to pick just one. Many IT organizations maintain a high-level roadmap that spans all categories, with detailed sub-roadmaps for each domain.

## How to build an IT roadmap in 5 steps

### Step 1: Audit your current state

Start with an honest assessment of your current IT landscape. Most IT leaders overestimate how well they know their own environment until they try to write it down.

Document your existing systems, their age, their maintenance burden, and their alignment with current business needs. Identify technical debt. Map dependencies between systems. Note which systems have upcoming end-of-life dates or expiring vendor contracts.

Talk to the teams that operate these systems daily. They know where the pain is. They know which systems fail at 2 AM, which integrations are held together with scripts nobody understands, and which workarounds have become permanent fixtures.

The audit doesn't need to be exhaustive on day one. Focus on the systems that matter most to the business and the ones that carry the most risk. You can fill in gaps as you go.

### Step 2: Define goals tied to business objectives

Every initiative on your roadmap should trace back to a business objective. "Upgrade to Kubernetes" is not a goal. "Reduce deployment time from 4 hours to 15 minutes to support faster product iteration" is.

Work with business leaders to understand their priorities for the next 12-18 months. Common business objectives that drive IT initiatives include:

- **Revenue growth:** Requires scalable infrastructure, faster feature delivery, better customer-facing systems.
- **Cost reduction:** Drives consolidation, license optimization, cloud cost management, automation of manual processes.
- **Risk reduction:** Motivates security investments, compliance programs, disaster recovery, and redundancy.
- **Operational efficiency:** Leads to workflow automation, system integrations, and self-service tooling.
- **Market expansion:** Demands multi-region infrastructure, localization support, and performance at scale.

Frame every initiative in terms of the business outcome it supports. This is how you get budget approval, and it's how you defend priorities when someone asks why their pet project isn't on the roadmap.

### Step 3: Prioritize initiatives

IT teams typically face 3-4x more requests than they can deliver in a given quarter. The roadmap's job is to sequence them, not to promise everything at once.

Use a structured framework to prioritize. The [RICE scoring framework](/tools/rice-scoring-calculator) works well for IT roadmaps:

- **Reach:** How many people or systems does this initiative affect?
- **Impact:** How significant is the improvement? (Scored on a scale, e.g., 0.25 to 3.)
- **Confidence:** How certain are you about the estimates? (Percentage.)
- **Effort:** How many person-months will this take?

RICE produces a numeric score for each initiative, which gives you a defensible starting point for prioritization conversations. It won't make the decisions for you, but it surfaces the trade-offs clearly.

Other factors that influence sequencing:

- **Dependencies.** Some initiatives unlock others. Network upgrades might need to precede cloud migration.
- **External deadlines.** Compliance requirements, vendor contract expirations, and end-of-life dates are non-negotiable.
- **Quick wins.** Small initiatives with disproportionate impact build momentum and credibility.
- **Risk.** High-risk initiatives might need earlier starts to allow for contingency.

### Step 4: Set timelines and milestones

Convert your prioritized list into a time-based plan. Most IT roadmaps use quarterly granularity for the near term (next 2 quarters) and half-year or annual granularity for the outer horizon.

Don't over-specify. Initiatives planned for Q3 next year don't need week-by-week breakdowns. You'll replan them when they get closer. The further out the timeline, the less precise it should be.

Define milestones for each initiative. Milestones are checkpoints that let you and your stakeholders know whether things are on track. Good milestones are:

- Observable. You can tell whether they've been reached without asking the project lead.
- Meaningful. They represent actual progress, not just activity.
- Time-bound. They have a target date.

Examples: "Production traffic migrated to new load balancers by end of Q2." "SOC 2 Type II audit completed by September." "Legacy CRM decommissioned after data migration verification."

Build in buffer. IT projects routinely take longer than estimated. If your roadmap has zero slack, a single delay cascades through everything. Plan at 70-80% capacity and you'll have room to absorb surprises.

### Step 5: Communicate and iterate

An IT roadmap that only your team sees is just a backlog with dates. The value comes from shared visibility.

Present it to business leadership quarterly. Post it on an internal wiki or portal where anyone affected by IT decisions can reference it. When a department head asks "when is the SSO rollout happening?" they should be able to check the roadmap instead of pinging you on Slack.

Collect feedback from stakeholders. Finance might flag budget constraints you missed. Operations might tell you that the ERP migration conflicts with their peak season. Product might reveal that their upcoming launch depends on infrastructure you planned for Q4. The best roadmap processes include a structured way for stakeholders to flag new needs and challenge priorities, rather than relying on hallway conversations.

Update the roadmap monthly with your leadership team, and share quarterly updates with the broader organization. When priorities shift, update the roadmap and communicate the change. A roadmap that doesn't change is either perfect (unlikely) or ignored (more likely).

## IT roadmap template

Here's a simple template you can adapt. Start with a spreadsheet or table, then graduate to specialized tooling as your roadmap matures.

![IT roadmap template with quarterly timeline](/blog/it-roadmap-guide/template.webp)

| Initiative | Category | Priority | Timeline | Owner | Status |
|---|---|---|---|---|---|
| Zero trust network rollout | Security | P1 | Q1-Q2 2026 | Sarah Chen | In Progress |
| Legacy ERP migration | App Modernization | P1 | Q2-Q4 2026 | Mike Torres | Planning |
| Cloud cost optimization | Infrastructure | P2 | Q1 2026 | Priya Patel | In Progress |
| SOC 2 Type II certification | Security | P1 | Q1-Q3 2026 | Sarah Chen | In Progress |
| Data warehouse migration to Snowflake | Infrastructure | P2 | Q3-Q4 2026 | Alex Kim | Not Started |
| CI/CD pipeline modernization | App Modernization | P3 | Q4 2026 | Dev Platform Team | Not Started |
| Endpoint detection and response | Security | P2 | Q2 2026 | Sarah Chen | Planning |
| Customer portal performance overhaul | App Modernization | P2 | Q2-Q3 2026 | Frontend Team | Not Started |

Add columns as needed: estimated cost, business objective alignment, dependencies, risk level. But don't over-engineer it. A roadmap that's easy to read and maintain beats a complex one that's always out of date.

## IT roadmap examples

### Example 1: Cloud migration roadmap

A mid-size financial services company migrating from co-located data centers to AWS. The roadmap spans 18 months and is organized in waves:

**Wave 1 (Q1-Q2):** Non-critical internal tools. HR portal, internal wiki, dev/staging environments. Low risk, builds cloud operations muscle.

**Wave 2 (Q3-Q4):** Customer-facing applications. Trading dashboard, account management portal. Requires performance testing, failover planning, and regulatory review.

**Wave 3 (Q1-Q2 next year):** Core systems. Transaction processing, risk calculation engines, data warehouse. Highest complexity, requires parallel-run period before cutover.

Each wave includes milestones for architecture review, security assessment, migration execution, performance validation, and legacy decommission. The roadmap also tracks a parallel workstream for cloud operations readiness: training, runbook creation, monitoring setup, and incident response process updates.

### Example 2: Security compliance roadmap

A healthcare SaaS company pursuing HITRUST certification while strengthening its security posture. The roadmap runs 12 months:

**Q1:** Gap assessment against HITRUST CSF. Deploy SIEM solution. Implement MFA across all systems. Begin vendor risk assessment program.

**Q2:** Remediate top-priority gaps from assessment. Deploy endpoint detection and response. Implement data loss prevention controls. Complete security awareness training for all employees.

**Q3:** Conduct internal audit. Remediate findings. Begin HITRUST assessor engagement. Implement automated compliance monitoring.

**Q4:** Complete HITRUST validated assessment. Establish continuous monitoring program. Build automated evidence collection for ongoing compliance.

### Example 3: Infrastructure refresh roadmap

A retail company modernizing aging infrastructure to support e-commerce growth:

**Q1-Q2:** Replace end-of-life network switches and firewalls. Upgrade core database servers. Implement infrastructure-as-code for all new deployments.

**Q3:** Migrate from monolithic load balancers to distributed ingress controllers. Deploy container orchestration platform. Implement centralized logging and observability.

**Q4-Q1 next year:** Migrate primary workloads to containerized deployments. Implement auto-scaling for e-commerce platform ahead of peak season. Decommission legacy virtualization cluster.

## Common mistakes

**Treating the roadmap as a commitment, not a plan.** Roadmaps are strategic communication tools, not contracts. When leadership treats every item as a promise, the IT team stops putting anything on the roadmap that carries uncertainty. The result is a roadmap full of safe, incremental work that doesn't move the needle. Set expectations that the roadmap will change. That's a feature, not a failure.

**No connection to business outcomes.** A roadmap full of technology names (Kubernetes, Terraform, Snowflake) without business context is meaningless to stakeholders. Every initiative should answer "so what?" in terms the business cares about: revenue, cost, risk, speed, or customer experience.

**Planning too far out in too much detail.** Detailed plans for work 12 months away are fiction. Use a "zoom lens" approach: high detail for the current quarter, moderate detail for the next quarter, directional themes for the rest of the year. This reduces the overhead of replanning when priorities shift.

**Ignoring capacity constraints.** A roadmap with 20 P1 initiatives and a team of 8 engineers is not a plan. It's a wish list. Be honest about capacity. If everything is a priority, nothing is. Force the hard conversations about what gets cut or deferred.

**Never updating it.** The number one reason IT roadmaps get ignored is that they're stale. If the roadmap doesn't reflect current reality, people stop looking at it. Schedule regular reviews and treat the roadmap as a living document.

## Tools for IT roadmaps

The right tool depends on your audience and how you use the roadmap.

For sharing IT plans with stakeholders outside the IT organization, a dedicated roadmap tool works well. Tools like Quackback, Productboard, or Aha let you publish a roadmap that stakeholders can view and comment on, which is particularly useful when your IT roadmap includes initiatives that affect other departments.

For project execution within the IT team, tools like Jira, Asana, Linear, or Monday.com handle task-level tracking, sprints, and assignments. These are complementary to a roadmap tool. The roadmap shows the strategic view. The project management tool shows the execution detail.

For visualization, tools like Miro, Lucidchart, or even well-formatted Google Sheets can work for teams that want maximum flexibility in how they present the roadmap.

If you're building roadmaps for other functions, see the [technology roadmap guide](/blog/technology-roadmap) for product and engineering-focused roadmaps, or the [marketing roadmap guide](/blog/marketing-roadmap) for go-to-market planning.

## Frequently asked questions

### How often should you update an IT roadmap?

Review it monthly with your IT leadership team. Update it quarterly for broader stakeholder communication. And revise it immediately when a major change happens: a budget cut, an acquisition, a security incident, or a significant shift in business priorities. The cadence matters less than the consistency. Pick a rhythm and stick to it.

### What's the difference between an IT roadmap and a technology roadmap?

An IT roadmap focuses on the IT organization's plans: infrastructure, security, internal systems, compliance, and operational technology. A technology roadmap is broader and often product-focused: it covers the technology decisions that affect what you build for customers. In practice, the two overlap significantly, especially in software companies where the IT infrastructure and the product infrastructure are the same thing.

### How far out should an IT roadmap plan?

12 to 18 months is the sweet spot for most organizations. Long enough to show strategic direction. Short enough that the plan is still credible. Infrastructure-heavy roadmaps sometimes extend to 24-36 months because hardware procurement and data center changes have long lead times. But even then, only the first 6 months should have detailed plans. Everything beyond that is directional.

- [Best Feedback Widgets for Your Website in 2026](https://quackback.io/blog/feedback-widget-tools): Comparing the best feedback widgets for websites and web apps. Embeddable tools for collecting user feedback without leaving your product.

Published: 2026-01-25

The best feedback comes from users who are already in your product. A feedback widget removes the friction of switching tabs, finding a form, or remembering to email you later. Instead of redirecting users to a separate page, you bring the collection point to them — embedded directly in your app or site.

The result is higher response rates, better context (you know exactly which page or feature they were on), and feedback that arrives structured rather than buried in an inbox.

![Feedback widget examples for websites and web apps](/blog/feedback-widget-tools/hero.webp)

## What is a feedback widget

A feedback widget is an embedded UI element that lets users submit feedback without leaving your app. It sits inside your product rather than behind a separate URL.

Common widget types include:

- **Floating button** — a persistent button, usually in the bottom corner, that opens a feedback panel on click
- **Slide-in panel** — a drawer that slides in from the side of the screen
- **Modal** — a centered overlay triggered by a button or user action
- **Inline form** — a form embedded directly into a page or section
- **Contextual prompt** — a targeted question shown after a specific action, like completing onboarding or submitting a ticket

Most tools in this comparison offer at least the floating button and slide-in panel. Some add contextual triggering, screenshot capture, or integration with your existing feedback board.

## Why use a feedback widget

A standalone feedback form requires users to navigate away, remember the URL, or hunt for a link in your footer. Most of them do not bother. A widget removes every step between "I have a thought" and "I submitted it."

Widgets also capture context automatically. They know which page the user was on, which account they belong to, and what they were doing. That context would otherwise require you to ask for it, which reduces response rates further.

Compared to email surveys or NPS campaigns, in-product widgets tend to produce higher response rates because the feedback moment aligns with the user's natural workflow. The friction is lower, and the signal arrives when the experience is still fresh.

Finally, most feedback widgets deliver structured data. Instead of an email saying "the thing doesn't work," you get a categorized report with page URL, user ID, and a screenshot — information your team can act on without follow-up.

![Four feedback widget types compared: floating button, slide-in panel, modal, and inline embed](/blog/feedback-widget-tools/widget-types-compared.webp)

## 8 feedback widgets compared

*Pricing last verified January 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

### 1. Quackback

**Overview:** Quackback is an open-source feedback platform with an embeddable widget. The widget connects directly to a full feedback management system: voting boards, a public roadmap, a changelog, and 25 integrations. Users can submit new requests or vote on existing ones without leaving your app.

The widget includes built-in duplicate detection. When a user submits a request that matches an existing one, Quackback surfaces the similar post and lets them vote on it instead of creating a fragmented duplicate. That keeps your vote counts accurate and your feedback board clean.

**Key features:**
- Embeddable floating button and slide-in panel
- Users can submit new feedback or vote on existing requests from within the widget
- AI duplicate detection prevents fragmented feedback
- Connects to full feedback platform: boards, roadmap, changelog, 25 integrations
- Anonymous submission support
- Custom branding and theming
- MCP server for AI agents to triage and respond to feedback

**Pricing:** Free and open source (AGPL-3.0) to self-host. Or let us run it: Quackback Cloud is fully managed (backups, updates, and uptime handled) from $29/mo on annual billing, with a 14-day free trial, no card required.

**Pros:**
- Widget is backed by a complete feedback management platform
- AI deduplication keeps vote data accurate
- Open source — you own your data and the code

**Cons:**
- Newer project than some established alternatives
- Self-hosting requires running your own infrastructure (or a one-click deploy on Railway)

**Best for:** Teams that want an embeddable widget connected to a full feedback management system, with no vendor lock-in.

---

### 2. Sleekplan

**Overview:** Sleekplan is a widget-first feedback tool. It was built around the in-app embed rather than a standalone portal. The widget includes feedback boards, a roadmap, a changelog, and NPS/CSAT satisfaction surveys — all accessible from a single floating button in your app.

Paid plans include AI features ("Sleek Intelligence") for summarization and analysis. The Starter plan at $13/month adds the roadmap, surveys, and 1,000 AI credits. Business at $38/month unlocks post merging, user segmentation, and conditional surveys.

**Key features:**
- Floating button widget with feedback board, roadmap, changelog, and surveys
- NPS and CSAT surveys embedded in the widget
- Impact scoring beyond raw vote counts
- AI-powered features on paid plans (summarization, analysis)
- 12 integrations: Jira, Linear, Azure DevOps, Slack, Intercom, ClickUp, GitHub, Zapier

**Pricing:** Free Indie plan (1 seat, limited features). Starter at $13/month. Business at $38/month. Enterprise is custom.

**Pros:**
- Widget-first design with all features accessible in one embed
- Affordable starting price
- Includes satisfaction surveys alongside feedback collection

**Cons:**
- Post merging and user segmentation require the Business plan ($38/month)
- Free plan lacks roadmap, surveys, and AI
- Standalone portal is less polished than the widget
- No self-hosting

**Best for:** Teams that want a widget-centric feedback experience with built-in satisfaction surveys at a low starting price.

See how it compares: [Quackback vs Sleekplan](/compare/quackback-vs-sleekplan).

---

### 3. Canny

**Overview:** Canny is a feedback board platform that offers a widget as an add-on to its core product. The widget lets users submit new requests and vote on existing ones from inside your app, with all data flowing into your Canny board.

Canny's Autopilot AI discovers implicit feedback from support conversations in Intercom, Zendesk, Help Scout, and Gong — attributing those interactions as votes on relevant feature requests. The pricing model shifted in May 2025 to tracked-user billing: anyone who submits or votes through the widget becomes a tracked user.

**Key features:**
- Embeddable widget for submission and voting
- Autopilot AI discovers votes from support tool conversations
- Vote-based prioritization scoring
- Public and private roadmaps
- Changelog with email notifications
- Integrations: Jira, Linear, Slack, HubSpot, Salesforce (Business plan)

**Pricing:** Free plan (25 tracked users). Core from $19/month. Pro from $79/month. Business is custom.

**Pros:**
- Mature platform with large user base
- AI-powered feedback discovery from support conversations
- Clean submission and voting experience

**Cons:**
- Every widget user becomes a tracked user, increasing costs as adoption grows
- No anonymous submissions (users must authenticate)
- Jira integration requires Pro ($79/month)
- No self-hosting

**Best for:** Existing Canny users who want to add in-app submission and voting to their feedback boards.

See how it compares: [Quackback vs Canny](/compare/quackback-vs-canny).

---

### 4. Userback

**Overview:** Userback focuses on visual feedback: screenshot capture, annotation tools, and session replay. When users click the widget, they can draw directly on the screen, highlight problem areas, and attach recordings. That context is automatically attached to every report.

The tool is aimed at design and QA workflows. Reports include browser info, screen resolution, and OS automatically. Session replay lets your team see exactly what the user was doing before they submitted the report.

**Key features:**
- In-app widget with screenshot and annotation tools
- Session replay attached to feedback reports
- Video feedback recording
- Custom feedback categories and workflows
- Integrations: Jira, GitHub, Trello, Asana, Slack, Zapier, and more
- User identification and custom metadata

**Pricing:** From $49/month for up to 3 team members.

**Pros:**
- Visual feedback with annotations and session replay gives deep context
- Automatic technical metadata (browser, OS, resolution)
- Strong integration set for development teams

**Cons:**
- Focused on visual bug reporting rather than feature requests or voting
- Higher starting price than most widget-only tools
- No open source or self-hosting

**Best for:** Design and UX teams that need annotated screenshot feedback and session replay alongside standard text submissions.

---

### 5. Marker.io

**Overview:** Marker.io is a bug reporting widget built around screenshot annotations. It integrates tightly with project management and issue tracking tools, sending annotated bug reports directly to Jira, GitHub, Trello, or Asana as formatted issues.

The widget sits in your app or site and captures browser metadata automatically. Users can highlight, blur, or annotate the screenshot before submitting. Reports arrive in your issue tracker pre-formatted, reducing the manual work of converting feedback into actionable tickets.

**Key features:**
- Screenshot annotation widget with highlight, blur, and drawing tools
- Direct integration with Jira, GitHub, Trello, Asana, ClickUp, and Monday.com
- Automatic browser, OS, and resolution metadata
- Console log capture for JavaScript errors
- Custom feedback forms and categories
- Guest reporting (no account required for submitters)

**Pricing:** From $39/month for up to 3 team members.

**Pros:**
- Strong integrations with development tools create properly formatted issues
- Automatic technical metadata reduces back-and-forth with reporters
- Guest reporting means external stakeholders can report without accounts

**Cons:**
- Purpose-built for bug reporting, not feature requests or general feedback
- No voting or roadmap features
- No self-hosting

**Best for:** QA and development teams that want structured bug reports flowing directly into their issue tracker.

---

### 6. Hotjar

**Overview:** Hotjar takes a different angle. Rather than a submission widget, it combines feedback tools (polls, surveys, incoming feedback) with behavioral analytics (heatmaps, session recordings, funnels). The feedback widget sits alongside usage data, so you can correlate what users say with what they actually do.

The Feedback tool lets users rate pages and leave comments using a simple thumbs-up/thumbs-down widget or a multi-step survey. The Surveys product handles longer-form questions. Both integrate with the heatmap and session data in the same dashboard.

**Key features:**
- In-product polls and surveys with visual targeting
- Incoming feedback widget for ratings and open-ended comments
- Heatmaps, click maps, and scroll maps
- Session recording and replay
- Funnel analysis and form analytics
- Integrations: Slack, HubSpot, Segment, Google Analytics

**Pricing:** From $32/month. The free plan includes limited sessions and heatmaps. Feedback features are available on paid plans.

**Pros:**
- Combines feedback collection with behavioral data in one platform
- Targeted surveys based on user behavior and page triggers
- Large user base and mature product

**Cons:**
- Not a feedback management platform — no voting boards, roadmaps, or changelogs
- Focused on UX research rather than product feedback workflows
- Per-session pricing can escalate on high-traffic sites
- No self-hosting

**Best for:** UX research teams that want to combine qualitative feedback with behavioral analytics in a single tool.

---

### 7. Doorbell.io

**Overview:** Doorbell.io is a lightweight feedback widget that does one thing: collect text feedback from users and send it somewhere. Users click the widget, type their feedback, and optionally attach a screenshot. That's it. Reports land in your inbox or get forwarded to Slack, Trello, or GitHub.

It covers the minimal use case without the overhead of a full feedback platform. There are no voting boards, no roadmaps, no changelogs, and no prioritization. Just a simple form in your app.

**Key features:**
- Lightweight floating button widget
- Optional screenshot attachment
- Email and Slack notifications
- Integrations: Slack, Trello, GitHub, Jira, Asana, Basecamp
- Custom feedback categories
- User identification via JavaScript snippet

**Pricing:** From $29/month. Pricing scales by number of apps.

**Pros:**
- Simple to set up and use
- Low overhead for teams that only need basic collection
- No complexity to learn

**Cons:**
- No voting, roadmap, changelog, or prioritization
- Feedback lands in your inbox rather than a structured system
- Limited compared to full feedback platforms
- No self-hosting

**Best for:** Teams with minimal needs who want a simple, low-overhead widget and are comfortable managing feedback in email or Slack.

---

### 8. Featurebase

**Overview:** Featurebase bundles feedback boards, a changelog, a roadmap, a help center, and a support inbox into a single product. The widget surfaces all of these from a floating button in your app. Users can submit feedback, browse the changelog, or search help articles without leaving your product.

Their AI agent, Fibi, automatically resolves customer questions using context from your help articles and feedback posts. At $0.49 per AI resolution, costs are usage-based. The free plan covers one seat with limited features.

**Key features:**
- Widget with feedback submission, changelog, roadmap, and help center access
- Unified support inbox with live chat, email, and ticketing
- Fibi AI agent ($0.49/resolution) for automated question resolution
- In-widget surveys: NPS, CSAT, multiple choice
- Voter segmentation by plan and company (paid plans)
- 12 integrations: Linear, Jira, GitHub, ClickUp, Slack, Intercom, Zendesk, HubSpot

**Pricing:** Free plan (1 seat, limited features). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- All-in-one widget covering feedback, changelog, help center, and support
- AI agent handles question resolution automatically
- Clean, polished widget experience

**Cons:**
- Per-seat pricing adds up for larger teams
- AI resolutions at $0.49 each can become significant at volume
- Post merging and user segmentation locked to higher tiers
- No self-hosting

**Best for:** Small teams that want a widget covering feedback, support, and help center access in a single embed.

See how it compares: [Quackback vs Featurebase](/compare/quackback-vs-featurebase).

---

## Comparison table

| Tool | Widget type | Voting | Screenshots | Analytics | Starting price |
|---|---|---|---|---|---|
| **Quackback** | Floating button, slide-in | Yes | No | Yes | Free (open source) |
| **Sleekplan** | Floating button | Yes | No | Paid plans | $13/month |
| **Canny** | Floating button, slide-in | Yes | No | Yes | Free (25 tracked users) |
| **Userback** | Floating button | No | Yes (annotations + replay) | Yes | $49/month |
| **Marker.io** | Floating button | No | Yes (annotations) | No | $39/month |
| **Hotjar** | Floating button, inline | No | No | Yes (heatmaps) | $32/month |
| **Doorbell.io** | Floating button | No | Optional | No | $29/month |
| **Featurebase** | Floating button | Yes | No | Paid plans | $29/seat/month |

## How to choose

The right widget depends on what you want to do with the feedback after it arrives.

**Feedback-only vs. full platform.** Doorbell.io and Marker.io collect feedback and route it to your inbox or issue tracker. That is the full workflow. If you want users to vote on existing requests, see a roadmap, and get notified when features ship, you need a platform with a widget on top — Quackback, Canny, Sleekplan, or Featurebase.

**Bug reporting vs. feature requests.** If your primary use case is bug reports from QA or stakeholders, Marker.io and Userback offer annotation tools that general-purpose widgets do not. If you want to collect and prioritize feature requests, tools with voting boards are a better fit.

**Standalone vs. integrated.** Some teams already have a feedback board and just need a widget to feed it. Others are starting from scratch and want the widget and the board to be the same product. Starting from scratch generally means choosing a tool where both are built together rather than bolting them on separately.

**Pricing model.** Per-seat pricing (Featurebase, Canny's tracked-user model) means costs grow as your team or user base grows. Flat-rate pricing (Sleekplan, Doorbell.io) is more predictable. Open source (Quackback) eliminates the recurring cost entirely if you are willing to self-host.

**Customization.** Most widgets let you change colors and add your logo. Fewer let you control the layout, trigger behavior, or CSS deeply. If matching your product's design system is important, check how much customization each tool allows before committing.

## Implementation tips

**Placement.** Bottom-right is the default position for most tools and carries less visual weight than bottom-left, which users associate with live chat. It is visible without blocking primary UI. If your app has a persistent right sidebar, consider bottom-left or a contextual inline trigger instead.

**When to show.** A persistent floating button works for general feedback. Contextual triggers — showing the widget after a specific action — produce higher-quality, more relevant submissions. Show a targeted prompt after a user completes onboarding, exports a file, or cancels a subscription. The feedback you get is directly tied to that experience.

**What to ask.** Keep it short. One or two questions at most. "What were you trying to do?" and "What got in your way?" produce more actionable feedback than "How would you rate this feature?" Open-ended questions surface problems you did not think to ask about.

**Avoid survey fatigue.** If you show a prompt every session, users start ignoring it. Rate-limit your contextual prompts. Show them once per experience, not once per visit. Let users dismiss without penalizing them — repeated prompts after dismissal create negative associations with your brand.

**Test on mobile.** Most widgets are designed and tested on desktop. If your users are on mobile, verify that the widget does not cover primary content, that it is easy to dismiss, and that the form inputs work on a small screen.

## Frequently asked questions

### What is a feedback widget?

A feedback widget is an embedded UI component that lets users submit feedback without leaving your app or website. It typically appears as a floating button that opens a form, panel, or modal when clicked. Unlike a standalone feedback form on a separate page, a widget captures feedback in context — while the user is actively in your product. Most widgets automatically attach the current URL, user ID, and browser metadata to every submission.

### How does a feedback widget differ from a feedback board?

A feedback widget is the collection point — the UI element your users interact with. A feedback board is where that feedback lives, gets organized, and gets acted on. Some tools are widget-only and route submissions to your inbox or issue tracker. Others include both: the widget collects feedback, and the board (with voting, roadmap, and changelog features) is where you manage it. Tools like Quackback, Canny, and Featurebase include both. Tools like Doorbell.io and Marker.io are widget-only.

### Can users vote on feedback through a widget?

Some tools support this. Quackback, Canny, Sleekplan, and Featurebase let users submit new requests or upvote existing ones directly from the widget. When a user starts typing a request, the widget surfaces similar existing posts and offers a one-click vote instead of a duplicate submission. This keeps vote counts consolidated and your feedback board accurate. Tools focused on bug reporting (Marker.io, Userback) and lightweight collection (Doorbell.io) do not include voting.

For a broader look at feedback collection strategies, see our guides on [how to collect customer feedback](/blog/collect-customer-feedback), [how to ask for customer feedback](/blog/how-to-ask-for-customer-feedback), and the [best customer feedback tools in 2026](/blog/best-customer-feedback-tools-2026). If you are evaluating whether Quackback fits your needs, see the [feedback features overview](/features/feedback).

- [Best Idea Management Software in 2026: 10 Tools Compared](https://quackback.io/blog/idea-management-software): Comparing 10 idea management tools in 2026. Features, pricing, and use cases for collecting, organizing, and prioritizing ideas from customers and teams.

Published: 2026-01-22

Ideas come from everywhere. Slack messages, support tickets, sales calls, user interviews, your own backlog. Without a system, most of them disappear. The good ones get buried in threads. The same idea surfaces three times from different people. Nothing connects to what actually gets built.

Idea management software gives you a structured place to collect, evaluate, and act on ideas — from customers, employees, or both. This guide compares ten tools across the full idea lifecycle: collection, organization, evaluation, prioritization, implementation, and communication.

![Idea management software comparison overview](/blog/idea-management-software/hero.webp)

> For most product teams, [Quackback](https://quackback.io) is the strongest option: open source, free to self-host, available as a managed cloud, with AI triage and a full feedback-to-roadmap workflow. Canny and Featurebase are the best hosted alternatives for teams that want a SaaS product without infrastructure overhead. Enterprise teams running formal innovation programs should look at IdeaScale or Brightidea.
>
> *Pricing last verified January 2026. Vendors may change plans and pricing without notice. Check each vendor's pricing page for the latest figures.*

![The idea lifecycle: collect, organize, evaluate, prioritize, build, and communicate in a continuous loop](/blog/idea-management-software/idea-lifecycle.webp)

## What is idea management software?

Idea management software helps organizations collect, evaluate, and act on ideas from customers, employees, or other stakeholders. It replaces ad-hoc channels — email inboxes, Slack threads, spreadsheets — with a structured process that every idea moves through.

The idea lifecycle has six stages. Collection is where ideas enter the system: through submission forms, integrations with support tools, or direct capture from conversations. Organization groups ideas by theme, product area, or status. Evaluation lets stakeholders vote, comment, or score ideas against criteria. Prioritization uses that data to surface the ideas worth building. Implementation connects accepted ideas to development workflows. Communication closes the loop, notifying the people who submitted or supported an idea when something changes.

Good idea management software handles all six stages. Most tools handle some of them well and leave gaps in others. The right choice depends on where your ideas come from, how your team evaluates them, and how tightly you need to connect feedback to your development process.

## What to look for

**Idea collection channels.** Ideas should be easy to submit from wherever your users and teams already are. Look for submission forms, in-app widgets, integrations with support tools (Intercom, Zendesk), and the ability to submit ideas on behalf of users. The more friction there is in submission, the fewer ideas you collect.

**Voting and prioritization.** A voting system surfaces demand, but raw vote counts are rarely enough. Look for tools that let you weight votes by customer segment, revenue, or other signals. Scoring frameworks like RICE (covered in our [RICE framework guide](/blog/rice-framework-explained)) bring consistency to prioritization decisions. See our [feature voting tools comparison](/blog/best-feature-voting-tools) for more on what good voting looks like.

**Categorization and tagging.** Ideas need to be organized to be useful. Tags, categories, and custom fields let you group related ideas and filter by product area, customer segment, or priority. Without this, a large idea backlog becomes as hard to navigate as the Slack thread it replaced.

**Status tracking.** Every idea should have a status that reflects where it is in the lifecycle: open, under review, planned, in progress, shipped, or declined. Status changes should trigger notifications to submitters and voters.

**Public-facing portal.** A public board where customers can submit ideas, vote on others, and see what is planned builds trust and reduces duplicate requests. Privacy controls matter too — some ideas should stay internal.

**Analytics.** Trend data on idea volume, vote velocity, and topic clusters helps product managers understand where demand is growing. [AI-powered feedback analysis](/blog/ai-customer-feedback-analysis) can surface patterns that manual review misses.

**Integrations.** Accepted ideas need to connect to your development workflow. Native integrations with Jira, Linear, and GitHub, plus communication tools like Slack, are the minimum. A REST API or webhooks let you build custom connections.

**Pricing model.** Idea management tools price in several ways: per seat, per tracked user, per board, or flat rate. Open-source tools let you self-host at a fixed infrastructure cost. Understand how costs scale before you commit.

## 1. [Quackback](https://quackback.io)

**Best for:** Product teams that want an open-source tool covering the full idea lifecycle — collection, voting, roadmap, changelog, and AI triage — without vendor lock-in.

Quackback is an open-source idea management platform licensed under AGPL-3.0. Users submit ideas through [feedback boards](/features/feedback), where each post collects votes, nested comments, and sentiment data. Ideas move through statuses from open to planned to shipped, visible on the public roadmap and announced via the changelog. The code is open and auditable, and your data stays in your own PostgreSQL database.

The AI layer is what separates Quackback from other tools in this category. Duplicate detection catches redundant ideas at submission time. Merge suggestions identify related posts with reasoning your team can accept or dismiss in one click. Sentiment analysis flags frustrated submitters. Post summaries surface key quotes and suggest next steps. AI is built in, with no add-on tier.

The [MCP server](/features/mcp) is unique among idea management tools. It implements the Model Context Protocol, supported by Claude, Cursor, and Windsurf. An AI agent can search your idea backlog, triage incoming posts, write responses, create changelog entries, and merge duplicates. Every action is attributed and auditable.

**Key features:**
- [Feedback boards](/features/feedback) with voting, categories, tags, and nested comments
- AI duplicate detection and merge suggestions
- Sentiment analysis and post summaries for faster triage
- [Feature voting](/features/voting) with anonymous mode supported
- Status tracking with automatic voter notifications
- Public roadmap and changelog
- [MCP server](/features/mcp) for AI agent access
- 25 integrations including Slack, Linear, Jira, GitHub, Intercom, Zendesk, and Salesforce
- SSO/OIDC, webhooks, and full REST API

**Pricing:** Free and open source (AGPL-3.0). Self-host at no cost, or use [Quackback Cloud](/pricing) for a managed option from $29/mo, with a 14-day free trial.

**Pros:**
- Covers the full idea lifecycle from collection through communication
- AI triage built in at no extra cost
- MCP server enables AI agents to act on ideas directly
- Free to self-host under AGPL-3.0
- Open source means no surprise pricing changes or paywalled features

**Cons:**
- Self-hosting takes more effort to set up than a hosted SaaS tool
- Smaller integration marketplace than the longest-running enterprise suites

---

> **Start collecting and organizing ideas with Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## 2. [Canny](/compare/quackback-vs-canny)

**Best for:** Mid-size SaaS teams that want a hosted idea board with AI-powered feedback discovery from support channels.

Canny has been in this space since 2017. It covers the core workflow: users submit ideas through a public board, your team tracks them with statuses and categories, and voters get notified when things change. The AI suite, Autopilot, is the standout feature — it discovers ideas buried in support conversations across Intercom, Zendesk, Help Scout, and Gong, then creates posts automatically.

The pricing model changed in May 2025 from per-admin to tiered pricing based on tracked users. A tracked user is anyone with a post, vote, or comment attributed to them. Costs auto-upgrade when you cross tier thresholds, making cost forecasting harder as your product grows. Several customers have reported unexpected increases after this change.

For teams that want a hosted solution and can manage the scaling costs, Canny is a mature product with a large user base and a good integration ecosystem. The concern is pricing predictability at scale. See our [Quackback vs Canny comparison](/compare/quackback-vs-canny) for a full feature-by-feature breakdown.

**Key features:**
- Feedback boards with categories, statuses, and internal notes
- Autopilot AI discovers ideas from support conversations automatically
- Smart replies and comment summarization
- Public and private roadmaps linked to ideas
- Changelog with email notifications
- Integrations with Jira (Pro+), Linear, Slack, HubSpot, and others

**Pricing:** Free plan (25 tracked users). Core from $19/mo. Pro from $79/mo. Business is custom pricing.

**Pros:**
- Mature product with a large user base and good documentation
- AI extracts ideas from support tools, reducing manual capture work
- Solid integration ecosystem for routing ideas to development teams

**Cons:**
- Tracked-user pricing makes costs unpredictable at scale
- Auto-upgrades when you exceed tracked user thresholds
- Jira integration locked to Pro ($79/mo)
- No self-hosting option
- Removing "Powered by Canny" branding requires the Business plan

## 3. [Aha! Ideas](/compare/quackback-vs-aha)

**Best for:** Large product organizations that need structured idea scoring, approval workflows, and a dedicated ideas portal alongside a broader product management suite.

Aha! Ideas is the standalone version of Aha!'s idea management module. It provides a customer-facing ideas portal where users submit and vote on ideas, plus an internal layer with scoring models, category management, and workflow routing. Ideas move through configurable stages, and your team can score them against weighted criteria before promoting the best ones to your product roadmap.

The depth of configuration sets Aha! apart from simpler tools. You can define custom scoring formulas, route ideas to specific reviewers based on category, and merge duplicate submissions. The integration with the broader Aha! product suite means accepted ideas can become initiatives or features with a single click. The trade-off is complexity — Aha! Ideas is designed for organizations with formal product processes, not teams looking for a quick-to-deploy feedback board.

Pricing is per-user and positions Aha! in the enterprise tier. For smaller teams or those who only need idea collection, the cost and overhead are hard to justify.

**Key features:**
- Customer-facing ideas portal with voting and status updates
- Custom scoring models with weighted criteria
- Configurable workflow stages and approval routing
- Idea merging and duplicate management
- Integration with Aha! Roadmaps, Strategy, and Develop products
- White-label portal with custom domain and branding
- Integrations with Jira, Azure DevOps, Salesforce, Slack, and more

**Pricing:** Ideas Essentials from $39/user/month, Ideas Advanced from $59/user/month, billed annually with a three-user minimum. Enterprise pricing is custom. *(Verified January 2026 against [aha.io/ideas/pricing](https://www.aha.io/ideas/pricing).)*

**Pros:**
- Deep scoring and workflow configuration for formal idea processes
- Tight integration with Aha! product suite for teams already using it
- Enterprise-grade security and compliance capabilities

**Cons:**
- High per-user cost puts it out of reach for smaller teams
- Significant complexity for teams that just want a voting board
- No open source or self-hosting option
- Steep learning curve

See how it compares: [Quackback vs Aha!](/compare/quackback-vs-aha).

## 4. [Productboard](/compare/quackback-vs-productboard)

**Best for:** Product teams that need to connect customer ideas to strategic prioritization frameworks and driver-based roadmaps.

Productboard is a full product management platform. It captures ideas as "insights" from Intercom, Zendesk, Salesforce, email, and Slack, and links them to features in a prioritization matrix. The insights portal aggregates every customer who asked for the same thing in one place, so your team can see the breadth of demand before deciding what to build.

The differentiator is strategic prioritization. You can score ideas against custom drivers — revenue impact, user reach, effort — and build roadmaps tied to company objectives. If your team needs to connect raw customer ideas to a formal product strategy process, Productboard provides that layer. If you need a straightforward idea board with voting, it is more than you need. See our [Quackback vs Productboard comparison](/compare/quackback-vs-productboard) for a detailed breakdown.

**Key features:**
- Insights portal captures ideas from support, sales, and email
- Feature prioritization with custom scoring frameworks (RICE, weighted, custom)
- Driver-based roadmaps tied to company objectives
- AI included via credits (250/maker/month) for summarization and semantic search
- Integrations with Jira, Azure DevOps, Slack, Salesforce, Zendesk, and Intercom

**Pricing:** Spark at $15/maker/month (annual) or $19/maker/month (monthly). Enterprise is custom.

**Pros:**
- Connects ideas to strategic prioritization and scoring
- Aggregates demand across support, sales, and email into one view
- AI included in the base plan via credits
- Enterprise-grade security and compliance

**Cons:**
- Per-maker pricing grows with team size
- AI credits (250/maker/month) may be limiting for heavy users
- Overkill if you only need idea collection and voting
- No self-hosting

## 5. IdeaScale

**Best for:** Large organizations running formal innovation programs with campaigns, workflows, and governance requirements.

IdeaScale is built for enterprise-scale idea crowdsourcing. Rather than a continuous feedback board, it structures idea collection around campaigns — time-bounded initiatives where employees or customers submit ideas on a specific topic. Ideas move through configurable pipeline stages: submission, review, refinement, selection, and implementation. Each stage can have its own reviewers, scoring criteria, and required fields.

The scale of IdeaScale's customer base — government agencies, large corporations, and nonprofits — reflects where it fits. If you are running a company-wide innovation challenge or a regulated public engagement process, IdeaScale has the governance features to support it. If you are a product team collecting customer feedback, the overhead of campaign management and multi-stage workflows is more than you need.

Pricing is custom and positions IdeaScale firmly in the enterprise market. There is no self-serve signup or published pricing tier.

**Key features:**
- Campaign-based idea collection with time-bounded challenges
- Multi-stage pipeline with configurable review and scoring workflows
- AI-assisted idea analysis and clustering
- Public and private idea communities
- Gamification features (points, leaderboards, badges) for engagement
- Reporting and ROI tracking for innovation programs
- Integrations with Microsoft Teams, Slack, Jira, and others

**Pricing:** Custom pricing. No public tiers. Contact sales.

**Pros:**
- Built for enterprise-scale innovation programs and campaigns
- Strong governance and workflow configuration
- Handles both employee innovation and customer feedback programs

**Cons:**
- No transparent pricing; requires a sales process
- Campaign-based model is a mismatch for continuous product feedback
- Significant setup and administration overhead
- Not suitable for small teams or startups

## 6. UserVoice

**Best for:** Enterprise support and product teams that need revenue-weighted prioritization and CRM-driven idea management at scale.

UserVoice pioneered the customer feedback category and still targets enterprise teams. The platform handles idea submission through a customer-facing portal, internal idea capture from sales and support teams, and revenue-weighted prioritization by connecting to Salesforce or HubSpot. You can distinguish "twelve enterprise accounts worth $2M want this" from "80 free-tier users want this."

The price reflects the positioning. UserVoice starts at roughly $16,000 per year with custom pricing based on feedback volume and integrations. There is no self-serve option and no public per-seat pricing. A 30-day free trial is available, but the sales process is required for any paid plan. For teams with the budget, the revenue-linked prioritization is genuinely useful. For everyone else, the cost is prohibitive.

**Key features:**
- Customer-facing idea portal with voting and status updates
- Internal idea capture from sales, support, and product teams
- Revenue-weighted prioritization linked to Salesforce or HubSpot ARR data
- Validation product ($199/mo) for microsurvey-based product research
- Enterprise security: SAML SSO, custom SLAs, compliance features
- Integrations with Salesforce, Zendesk, HubSpot, Slack, and Jira

**Pricing:** Starting at approximately $16,000/year. Custom pricing based on feedback volume and integrations. Annual billing required. *(Verified January 2026; UserVoice does not publish tiered pricing.)*

**Pros:**
- Revenue-linked prioritization connects ideas to business impact
- Internal capture keeps sales and support feedback in the same system
- Enterprise compliance and security features

**Cons:**
- Pricing excludes most teams outside enterprise budgets
- No self-serve signup or transparent pricing tiers
- Interface feels dated compared to newer tools
- No self-hosting

See how it compares: [Quackback vs UserVoice](/compare/quackback-vs-uservoice).

## 7. Featurebase

**Best for:** Small to mid-size teams that want idea collection, changelog, and roadmap in one lightweight hosted tool with a free plan entry point.

Featurebase bundles feedback boards, a changelog, public roadmap, help center, and customer support inbox in a single product. The premise is that many ideas start as support conversations — a customer asks "can I do X?" and your team realizes X does not exist. Featurebase keeps the support conversation and the resulting idea connected.

The free plan is available but limited to one seat. Growth starts at $29/seat/month. Their AI agent, Fibi, can resolve customer questions and submit ideas to your boards on behalf of customers, at $0.49 per resolution. Post merging and user segmentation — both important for managing idea volume — are locked to higher tiers.

**Key features:**
- Feedback boards with voting, categories, and user segmentation (paid)
- AI agent captures ideas from support conversations ($0.49/resolution)
- Post merging to consolidate duplicate ideas (paid tiers)
- Unified support inbox with live chat, email, and ticketing
- Changelog and public roadmap
- 12 integrations: Linear, Jira, GitHub, ClickUp, Slack, Intercom, Zendesk, HubSpot

**Pricing:** Free plan (1 seat, limited features). Growth at $29/seat/month. Professional at $59/seat/month. Enterprise at $99/seat/month.

**Pros:**
- Captures ideas from support conversations automatically
- Keeps the support-to-idea pipeline in one product
- Modern interface with a relatively low entry price

**Cons:**
- Per-seat pricing adds up for larger teams
- AI resolutions at $0.49 each can become significant at volume
- Post merging and segmentation locked to higher tiers
- No self-hosting or open source

See how it compares: [Quackback vs Featurebase](/compare/quackback-vs-featurebase).

## 8. Frill

**Best for:** Indie hackers, solo founders, and small SaaS teams that want a minimal, affordable idea board with roadmap and changelog.

Frill is a lightweight feedback tool that covers the basics: a public idea board where users submit and vote on ideas, a roadmap view, and a changelog. Setup takes minutes. The interface is clean. There are no complex workflows or scoring systems — ideas come in, you organize them, and you publish what you are building.

The appeal is simplicity and price. At $25/month, Frill is affordable for early-stage products where you want a professional-looking feedback board without the overhead of more complex tools. The trade-off is depth. There is no duplicate detection, no AI triage, no user segmentation, and limited integrations. If your idea volume grows beyond what one person can manually manage, you will outgrow Frill.

**Key features:**
- Public idea board with voting and custom statuses
- Roadmap view grouped by status
- Changelog with subscriber notifications
- Embeddable widget for in-app idea collection
- Custom domain and branding
- Integrations with Slack, Zapier, and a REST API

**Pricing:** Startup at $25/mo (50 ideas). Business at $49/mo (unlimited). Growth at $149/mo. Enterprise from $349/mo.

**Pros:**
- Simple to set up and use
- Affordable entry price for early-stage products
- Covers the core idea-to-roadmap workflow
- Embeddable widget for in-app collection

**Cons:**
- No duplicate detection or idea merging
- No AI features
- Limited integrations compared to larger platforms
- No self-hosting

See how it compares: [Quackback vs Frill](/compare/quackback-vs-frill).

## 9. Brightidea

**Best for:** Corporate innovation teams running structured idea pipelines across large organizations with governance, reporting, and ROI tracking requirements.

Brightidea is an enterprise innovation management platform that has been in the market since 1999. It structures idea collection through what it calls a "pipeline" — a series of stages that each idea moves through from submission to implementation. Each stage has its own form, reviewer assignment, scoring criteria, and approval requirements.

The platform is designed for organizations running multiple simultaneous innovation programs across different business units. You can run an employee suggestion box, a product innovation challenge, and a process improvement program in parallel, each with its own pipeline and governance. Reporting tracks the number of ideas implemented and their estimated business value. Pricing is custom and enterprise-tier.

**Key features:**
- Pipeline-based idea management with configurable multi-stage workflows
- Campaign management for time-bounded innovation challenges
- Idea scoring, evaluation, and approval workflows
- Portfolio tracking across multiple innovation programs
- ROI and implementation tracking
- Integrations with Jira, Microsoft Teams, Salesforce, and others
- Enterprise security: SSO, SCIM provisioning, data residency options

**Pricing:** Custom pricing. Contact sales. No public tiers.

**Pros:**
- Built for complex, multi-program enterprise innovation management
- Strong pipeline and governance configuration
- Long track record with enterprise customers

**Cons:**
- No transparent pricing; requires a lengthy sales process
- Significant setup and administration overhead
- Overkill for product teams wanting a feedback board
- Interface is dated compared to modern tools

## 10. Nolt

**Best for:** Small teams that want the simplest possible idea collection board with predictable flat-rate pricing.

Nolt gives you a clean board where users submit ideas, vote on them, and leave comments. Custom statuses track each idea through your process. A basic roadmap view groups ideas by status. Setup takes under ten minutes.

The flat pricing is the main appeal. Essential is $29/month for one board (billed annually) with no tracked-user billing and no per-seat scaling. You know what you will pay regardless of how many users submit ideas. The concern in 2026 is stagnation — Nolt has seen minimal product updates since 2022. There is no duplicate detection, no changelog, no AI, and no bulk editing. If your idea volume grows, manual triage becomes the bottleneck.

**Key features:**
- Idea board with voting, custom statuses, and comments
- Roadmap view grouped by status
- SSO, private boards, and password-protected boards
- Custom domain and branding
- Integrations: Slack, Discord, Jira, Linear, Asana, Trello, GitHub, Zapier (Pro plan)

**Pricing:** Essential at $29/month for one board (annual). Pro at $69/month for five boards. Enterprise is custom.

**Pros:**
- Quickest setup of any tool on this list
- Flat pricing regardless of idea or user volume
- Clean, user-friendly interface

**Cons:**
- No duplicate detection — similar ideas pile up without consolidation
- No changelog to notify submitters when ideas ship
- Minimal product updates since 2022
- Per-board pricing multiplies costs across multiple products
- No self-hosting or AI features

See how it compares: [Quackback vs Nolt](/compare/quackback-vs-nolt).

## Comparison table

| Feature | Quackback | Canny | Aha! Ideas | Productboard | IdeaScale | UserVoice | Featurebase | Frill | Brightidea | Nolt |
|---|---|---|---|---|---|---|---|---|---|---|
| **Public portal** | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| **Voting** | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| **Roadmap** | Yes | Yes | Yes | Yes | No | No | Yes | Yes | No | Yes |
| **Changelog** | Yes | Yes | No | No | No | No | Yes | Yes | No | No |
| **AI triage** | Yes (built in) | Yes | No | Via credits (250/maker/mo) | Yes | No | Via agent ($0.49/resolution) | No | No | No |
| **Duplicate detection** | Yes (AI) | Yes (AI) | Manual | Manual | Yes | No | Paid tiers | No | No | No |
| **Open source** | Yes (AGPL-3.0) | No | No | No | No | No | No | No | No | No |
| **Self-hosting** | Yes | No | No | No | No | No | No | No | No | No |
| **MCP / agent access** | Yes | No | No | No | No | No | No | No | No | No |
| **Dev integrations** | Jira, Linear, GitHub + 20 more | Jira (Pro+), Linear | Jira, Azure DevOps | Jira, Azure DevOps | Jira | Jira, Zendesk | Jira, Linear, GitHub | Zapier, API | Jira | Jira, Linear (Pro) |
| **Starting price** | Free | $19/mo | $59/user/mo | $15/maker/mo | Custom | ~$16k/year | $29/seat/mo | $25/mo | Custom | $29/mo |

## Frequently asked questions

### What is the difference between idea management software and a feedback tool?

The difference is mainly emphasis. Feedback tools focus on continuous customer input about an existing product: bugs, feature requests, satisfaction signals. Idea management software adds structured evaluation, scoring, and campaign-based collection for both product feedback and broader innovation. Many tools serve both. See the [best customer feedback tools in 2026](/blog/best-customer-feedback-tools-2026).

### How do you prioritize ideas once you have collected them?

Start with voting data to surface demand, then layer in customer segment, attached revenue, and strategic fit. Frameworks like RICE (Reach, Impact, Confidence, Effort) add consistency; see our [RICE framework guide](/blog/rice-framework-explained). AI tools like [Quackback](https://quackback.io) automate duplicate detection, sentiment analysis, and cluster summaries.

### What should I look for in an open-source idea management tool?

Look for self-hosting, data ownership, and code transparency. [Quackback](https://quackback.io) is the most full-featured open-source option: feedback boards, voting, roadmap, changelog, 25 integrations, and built-in AI, with your data in your own PostgreSQL database or a managed cloud. See [open-source feedback tools](/blog/open-source-feedback-tools) and [self-hosted feedback tools](/blog/self-hosted-feedback-tools).

### Do I need idea management software if I already use a project management tool?

Yes, they solve different problems. Project tools like Jira or Linear track committed work: tickets, sprints, tasks. Idea management software handles the fuzzy front end of capturing and evaluating ideas before they become work. Most idea tools, including [Quackback](https://quackback.io), integrate with [Jira](/integrations/jira) and [Linear](/integrations/linear) so accepted ideas flow into your workflow.

- [How to Announce Product Updates (10 Real Examples, 2026)](https://quackback.io/blog/product-update-announcement): How to announce product updates that users actually read. Ten real examples, a copy-pasteable template, and distribution strategies that work.

Published: 2026-01-18

You shipped a feature. Now you need people to know about it. The hard part is not the announcement itself — it is getting users to read it, understand it, and actually use what you built.

Most product update announcements fail because they describe what changed, not why it matters. "We added bulk export" tells users nothing. "Export all your data in one click — no more downloading records one by one" tells them exactly what they gain. The framing determines whether your announcement gets read or ignored.

![Product update announcement examples across different channels](/blog/product-update-announcement/hero.webp)

> To announce a product update that users read, lead with the benefit instead of the feature name, include a short visual, and publish across the channels your users already use — a changelog page, in-app widget, email, and community. The framing decides whether the announcement drives adoption or gets ignored, so write "what can you do now" before "what changed."

## Why product announcements matter

A well-executed product update announcement does more than inform — it drives behavior. When users understand what changed, they adopt the feature. Adoption reduces support tickets because users find the solution before they open a request. It also builds trust: customers who see a steady stream of improvements believe the product is worth staying with.

Announcements also close the [customer feedback loop](/blog/customer-feedback-loop). When a user submits a feature request, votes on a roadmap item, or files a bug report, they are investing in your product. Publishing an announcement that connects the shipped work back to that input shows users their feedback had an effect. That connection — "you asked, we built it" — is one of the most effective retention signals available to a product team.

Done consistently, announcements also create an internal artifact. Your team accumulates a visible record of what shipped, when, and why. New hires, investors, and sales teams can see momentum without digging through code commits.

## 10 real product update examples

### 1. Linear

Linear's changelog entries are short and benefit-first. Each entry leads with a single sentence that names what changed and what users can now do. Below that is a GIF showing the feature working — no static screenshots, no walls of text. The GIFs do the explaining so the copy does not have to.

**What works:** The visual does the heavy lifting. Users understand in under ten seconds whether the update applies to them.

**Key takeaway:** Match your format to how your users consume information. If your product is visual, your announcements should be visual.

### 2. Stripe

Stripe's release notes are written for developers. Each entry includes the exact API version, the change type (breaking, non-breaking, deprecated), and a migration path when needed. There is no marketing language — just the technical detail developers need to decide whether to act.

**What works:** Stripe respects its audience's time. Developers can scan for the version number and read only what affects them.

**Key takeaway:** Know who is reading. Developer-facing products need technical specificity. Consumer-facing products need plain language.

### 3. Notion

Notion publishes a "What's New" page that reads more like a friendly product newsletter than a changelog. The tone is conversational, updates are grouped by theme, and many entries include embedded demos you can interact with inline. The page is updated regularly rather than versioned.

**What works:** The embedded demos lower the barrier to trying new features. You do not have to navigate away — you see it working right there.

**Key takeaway:** If your product has a lot of casual users, a lower-friction format with embedded media outperforms a technical changelog.

### 4. Vercel

Vercel uses two tiers. Major releases get a full blog post with context, architecture decisions, and performance data. Minor updates go into a changelog with shorter entries. The two formats serve different audiences: engineering leaders read the blog posts, developers scan the changelog.

**What works:** Not every update deserves the same treatment. Investing editorial effort where it matters most — major releases — makes those announcements land harder.

**Key takeaway:** Build a tiered announcement strategy. Save long-form for the updates that move deals and retain power users.

### 5. GitHub

GitHub's changelog blog publishes detailed technical write-ups for every meaningful update. Entries often include before-and-after comparisons, API references, and links to the relevant documentation. The tone is authoritative but not dry — each post explains the reasoning behind the change.

**What works:** GitHub has a highly technical, opinionated user base. Users do not just want to know what changed — they want to understand why. The reasoning builds credibility.

**Key takeaway:** If your users are technically sophisticated, share the thinking behind decisions. It signals that you take their craft seriously.

### 6. Figma

Figma's announcements lean heavily on video. Major feature releases come with narrated walkthroughs that show the feature being used in a realistic design workflow, not a contrived demo. The storytelling centers on designer problems — "you've been dealing with this friction for years" — before showing the solution.

**What works:** Figma sells to a visual audience that values craft. Video announcements match the medium to the message.

**Key takeaway:** Use the format your audience already consumes. Designers watch videos. Developers read documentation. Match accordingly.

### 7. Slack

Slack surfaces new features inside the product itself through tooltips and modals that appear at the right moment — when you hover over a new button, or when you open a feature that has been updated since your last session. The announcement finds you; you do not have to find it.

**What works:** In-app announcements reach users when they are already in context. The relevance is immediate.

**Key takeaway:** For features that live inside a specific workflow, in-app announcements beat email. The user is already there.

### 8. Intercom

Intercom uses in-app banners that target specific user segments. A banner for a new reporting feature only shows to users on plans that include reporting, who have logged in within the past 30 days, and who have not already seen it. The targeting is precise enough that the announcements feel relevant rather than spammy.

**What works:** Untargeted announcements train users to ignore them. Targeted announcements feel like useful information.

**Key takeaway:** Segmentation is the difference between an announcement that drives adoption and one that trains users to dismiss your notifications.

### 9. Loom

Loom sends a monthly email digest that groups multiple small updates under a single subject line. Instead of sending a separate email for every minor improvement, they batch them and send one. The email is scannable — each update gets a headline, one sentence, and a link.

**What works:** Frequent small updates do not need individual announcements. Batching them reduces notification fatigue while keeping users informed.

**Key takeaway:** Cadence matters. A monthly digest for incremental improvements respects your users' inboxes.

### 10. Cal.com

Cal.com is open source, and their changelog reflects that. Updates are published publicly with community context — references to GitHub issues, contributor credits, and links to the discussions that shaped the decision. The community can comment directly.

**What works:** For an open-source product, the community is part of the product team. Announcements that invite discussion strengthen that relationship.

**Key takeaway:** If your users are also contributors, your changelog can be a forum, not just a notice board. [Quackback](/features/changelog) takes the same open-source approach — it is AGPL-3.0 and self-hostable, so your changelog, roadmap, and the feedback behind it stay on infrastructure you control.

## Product update announcement template

Use this structure for any update, from a minor bug fix to a major release. Copy it, fill in the blanks, and adjust the length to match the significance of the change.

```
## [Benefit, not feature name]
Example: "Export all your data in one click" not "Bulk export released"

**What changed**
One or two sentences describing the specific change. Be concrete.
Example: "You can now export all your records as a CSV or JSON file from the
Settings page. Previously, export was limited to 100 records at a time."

**Why it matters**
One sentence on the user benefit.
Example: "If you run regular data backups or work with external tools, this
removes the manual workaround entirely."

**How to use it**
Step 1: Navigate to Settings > Data > Export
Step 2: Choose your format (CSV or JSON)
Step 3: Click Export — your file downloads immediately

[Link to full documentation]

[Screenshot or GIF placeholder — show the feature in action]

---
Was this update useful? [Leave feedback] [thumbs up] [thumbs down]
```

The headline is the most important line. Users scan headlines before deciding whether to read. A benefit-first headline — "Export all your data in one click" — answers the user's first question: "Does this affect me?" A feature-name headline — "Bulk export released" — does not.

![A single product update distributed across five channels: changelog, email, social, community, and in-app widget](/blog/product-update-announcement/multi-channel-distribution.webp)

## Distribution channels

Where you publish matters as much as what you write. Each channel reaches a different audience in a different context.

**Changelog page**
A public changelog page is your permanent record. It is indexed by search engines, linkable from support tickets, and discoverable by users who want to see whether the product is actively maintained. Every update should appear here. The downside is that users have to find it — it does not reach them. When we built Quackback's own changelog, we tied each entry back to the [feedback](/features/feedback) and [roadmap](/features/roadmap) items that prompted it, so readers see the request, the vote, and the shipped result on one page — the "you asked, we built it" loop made concrete.

**In-app widget or notification**
In-app announcements reach users when they are actively using your product. They work best for features that are relevant to the current context. The risk is notification fatigue: if you push every minor update in-app, users will start dismissing them without reading. Reserve in-app for updates that are genuinely relevant to the user's current plan or workflow. [Quackback's changelog feature](/features/changelog) lets you embed a widget that surfaces updates inside your product without building a custom notification system. It is open source and self-hostable, so you keep ownership of the changelog and the feedback behind it.

**Email**
Email reaches users who have not logged in recently — exactly the audience you want to re-engage with a significant update. It works well for major releases and monthly digests. The downside is deliverability and inbox competition. Keep subject lines specific and avoid "Product Update" as a subject line — it is one of the fastest ways to get ignored.

**Social media**
Twitter/X, LinkedIn, and Bluesky work for announcements that have broad appeal or are significant enough to attract attention beyond your current user base. Major releases, open-source milestones, and story-driven updates perform well. Minor bug fixes do not.

**Community channels (Slack, Discord)**
If you have a community, announce there. Community members are your most engaged users. They are also the most likely to give you immediate feedback on whether the update solved their problem. Direct the conversation — post the announcement, ask a specific question, and stay in the thread.

For a structured approach to choosing and combining channels, the [best changelog tools comparison](/blog/best-changelog-tools) covers tools that handle multi-channel distribution.

## Best practices

**Lead with the benefit.** Every announcement should answer "what can I do now that I could not do before?" before explaining how the feature works. Users do not care about implementation details — they care about what changes for them.

**Include a visual.** A GIF or screenshot reduces the cognitive load of understanding a new feature. Users do not have to navigate to the feature and explore — they can see it working in ten seconds and decide whether to try it.

**Keep it scannable.** Use short paragraphs, headings, and bullet points. Most users will not read every word. Design your announcement so they can extract the key information in a scan.

**Link to documentation.** Your announcement is an introduction, not a manual. Point users to the documentation where they can get the full picture. If the feature is complex, a "getting started" guide link is more useful than a detailed how-to in the announcement itself.

**Ask for feedback.** End every announcement with a way for users to respond — a thumbs up/down, a comment box, or a direct reply link. This signals that you care whether the update was useful, and it gives you data on whether the feature landed. For a complete approach to closing the loop, see the guide on [building a customer feedback loop](/blog/customer-feedback-loop).

**Maintain a consistent cadence.** Users who know to expect updates — weekly, biweekly, or monthly — are more likely to read them than users who receive announcements unpredictably. Cadence signals that the product is actively maintained.

For teams building a repeatable release notes workflow, the [release notes template](/blog/release-notes-template) covers the full structure from draft to publish.

## Publish your next update with Quackback

Quackback turns the loop in this guide into a workflow: collect feedback, prioritize it on a public roadmap, ship it, and announce it through a built-in [changelog](/features/changelog) and in-app [widget](/features/widget). It is open source (AGPL-3.0) and self-hostable, and the [MCP server](/features/mcp) lets you publish changelog entries straight from your existing tools or an AI assistant. With 25 integrations and SSO/OIDC, it fits the stack you already run.

---
> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)
---

## Frequently asked questions

### How long should a product update announcement be?

Match the length to the significance of the change. A minor bug fix needs one sentence and a changelog link. A major release warrants a few short paragraphs: what changed, why it matters, how to use it. If you pass 300 words, you are writing documentation, not an announcement.

### How often should you publish product updates?

A consistent cadence matters more than a specific frequency. Many SaaS teams publish minor updates weekly and major announcements monthly. Small, frequent updates signal that the product is alive and improving, so do not wait for something "significant enough." Silence between major releases is a retention risk.

### Should every update get its own announcement?

No. Batch minor updates into a digest instead of announcing every small change. The rule of thumb: if the update changes what a user can accomplish, it deserves its own announcement. Under-the-hood changes like performance or refactoring belong in a batch digest or technical changelog.

- [Free Product Roadmap Template for Google Sheets (2026 Guide)](https://quackback.io/blog/google-sheets-roadmap-template): A free product roadmap template for Google Sheets: the exact columns to use, conditional formatting tips, setup steps, and when to outgrow a spreadsheet.

Published: 2026-01-12

Not every team needs a dedicated roadmap tool. If you're early-stage, running a small product, or just getting started with structured planning, a spreadsheet is often enough. It's free, everyone already knows how to use it, and it requires no onboarding.

This post gives you a free product roadmap template for Google Sheets that you can recreate in minutes. It also covers how to set it up, how to maintain it, and when you have outgrown it.

![Product roadmap template for Google Sheets](/blog/google-sheets-roadmap-template/hero.webp)

> A **product roadmap template for Google Sheets** is a single spreadsheet with one row per feature and columns for Feature, Description, Status, Priority, Quarter, Owner, Category, Feedback count, and Notes. Copy the column structure below into a new sheet, add conditional formatting to the Status column, and share it with your team. It is free, needs no onboarding, and works well for early-stage products until your team, backlog, or stakeholder count grows.

## Why use Google Sheets for your roadmap

Google Sheets has a few real advantages over dedicated roadmap software, especially early on.

It costs nothing. You don't need to evaluate vendors, negotiate contracts, or convince finance to approve a new tool. If your team uses Google Workspace, Sheets is already there.

Everyone knows how to use it. You won't spend time training stakeholders or waiting for people to figure out a new interface. Filtering, sorting, conditional formatting — these are skills most people already have.

Sharing is straightforward. You can share a link with view or comment access. Stakeholders can see the roadmap without creating an account. External collaborators can leave comments without being added to your workspace.

For early-stage teams or small products with a short backlog, Sheets handles the job. The limitations only start to show when your team, your backlog, or your stakeholder count grows significantly.

![Google Sheets roadmap template layout with columns for Feature, Status, Priority, Quarter, Owner, and Feedback count](/blog/google-sheets-roadmap-template/spreadsheet-layout.webp)

## What's in the template

The template is a single sheet with one row per item and the following columns:

| Feature | Description | Status | Priority | Quarter | Owner | Category | Feedback count | Notes |
|---|---|---|---|---|---|---|---|---|
| CSV export | Export any table to CSV with one click | Planned | Must | Q2 2026 | Sarah | Core product | 47 | Needed for enterprise tier |
| Dark mode | Full dark theme across all views | In Progress | Should | Q1 2026 | Tom | UI | 83 | Design complete, in dev |
| Slack integration | Post status updates to a Slack channel | Planned | Should | Q3 2026 | Sarah | Integrations | 31 | Waiting on API docs |
| Bulk edit | Select and update multiple records at once | Won't Do | Could | — | — | Core product | 12 | Revisit in H2 |
| Onboarding checklist | Interactive checklist for new users | Done | Must | Q4 2025 | James | Growth | 19 | Shipped Nov 2025 |
| API rate limit dashboard | Show usage and limits in account settings | Planned | Could | Q3 2026 | Tom | Developer | 8 | Low priority for now |

The **Status** column uses four values: Planned, In Progress, Done, Won't Do. These map to the actual lifecycle of a feature without introducing ambiguity.

The **Priority** column follows MoSCoW notation — Must, Should, Could, Won't. If you're not familiar with the framework, the [MoSCoW guide](/blog/moscow-prioritization) covers how to apply it to feature planning.

The **Feedback count** column is worth including even if it starts at zero. It forces you to connect roadmap items to actual user demand rather than internal assumptions. As you collect feedback, update this number. It becomes a fast signal for which items deserve more attention.

## How to set it up

**Step 1: Duplicate the template.** Open the template, go to File > Make a copy, and save it to your own Drive. Rename it something like "[Product] Roadmap — 2026."

**Step 2: Customize the columns.** Delete any columns you don't need. If you don't have owners yet, remove that column. If you track work in sprints rather than quarters, replace the Quarter column with a Sprint column. The goal is a structure that reflects how your team actually works, not an idealized version.

**Step 3: Add conditional formatting for Status.** Select the Status column, go to Format > Conditional formatting, and assign colors to each value. A common scheme: green for Done, yellow for In Progress, blue for Planned, gray for Won't Do. This makes the sheet scannable at a glance without having to read every cell.

**Step 4: Share with your team.** Use the Share button to give your team edit access and stakeholders view or comment access. If you want a version stakeholders can reference without accidentally editing it, publish it as a web page via File > Share > Publish to web.

**Step 5: Set a weekly update cadence.** Block 15 minutes each week to update statuses, add new items, and archive completed work. A roadmap that isn't updated becomes noise. The cadence doesn't need to be long — it just needs to be consistent.

## Tips for maintaining it

**Update it weekly.** Stale roadmaps breed distrust. If stakeholders check the sheet and find items that shipped three weeks ago still marked "In Progress," they stop relying on it. Fifteen minutes on a Monday morning is enough to keep it accurate.

**Archive shipped items.** When features are done, move them to a second sheet called "Archive" rather than deleting them. This preserves your history without cluttering the main view. You can always filter the main sheet to hide Done items, but having a clean archive is useful for planning retrospectives and tracking velocity over time.

**Link to feedback sources.** Use the Notes column to link to feedback threads, support tickets, or user interviews that motivated each item. When someone asks "why is this on the roadmap," you want to point to evidence, not recall it from memory.

**Keep it under 50 items.** A roadmap with 200 rows is a backlog, not a roadmap. If your sheet grows past 50 active items, prune it. Move low-priority items with no near-term plan to the archive. Mark speculative items as Won't Do. A shorter roadmap forces clearer decisions about what actually matters now.

## When to upgrade to a dedicated tool

Google Sheets works until it doesn't. Here are the signs it's no longer enough.

**Multiple stakeholders are editing simultaneously.** Sheets handles concurrent editing poorly for structured data. When three people update the same rows during a planning meeting, you end up with conflicts, accidental overwrites, and no audit trail.

**You need a customer-facing roadmap.** A shared Google Sheet is not a good public roadmap. It exposes your internal notes, lacks the structure customers expect, and gives you no control over what gets shown. For a customer-facing roadmap, you need a dedicated tool — see the [best public roadmap tools](/blog/best-public-roadmap-tools) for options.

**You want to connect feedback directly to roadmap items.** In Sheets, the "Feedback count" column is a number you update manually. It has no connection to actual feedback data. When you want votes, comments, and feature requests to automatically inform your roadmap, a spreadsheet becomes a bottleneck.

**You need automated notifications.** Sheets has no way to notify users when an item's status changes. If you're managing customer expectations around specific features, you need tooling that can communicate updates automatically.

**You're managing more than 100 active items.** At that scale, the filtering and sorting capabilities of Sheets start to feel limiting. You need tagging, saved views, and smarter filtering to keep the signal clear.

When you hit those limits, [Quackback's roadmap feature](/features/roadmap) is worth looking at. It connects directly to your [feedback board](/features/feedback), so vote counts and user comments surface alongside roadmap items without manual updates. You can publish a customer-facing roadmap that users can view and interact with, and they get notified when the status of items they care about changes.

Quackback is open source (AGPL-3.0) with a managed cloud option. Built-in AI triage and an [MCP server](/features/mcp) let you query feedback and roadmap data from your own tools. If you would rather not run it yourself, the [pricing page](/pricing) covers the cloud tiers.

For more context on what to look for in a roadmap tool, see [product roadmap examples](/blog/product-roadmap-examples), the [agile roadmap guide](/blog/agile-roadmap), and the [Quackback docs](/docs). If you are weighing dedicated tools, compare [Quackback vs Productboard](/compare/quackback-vs-productboard) and [Quackback vs Canny](/compare/quackback-vs-canny).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Is a Google Sheets roadmap good enough for a real product?

For early-stage products and small teams, yes. A Google Sheets roadmap works well when your backlog is short, your team is small, and your planning process is still evolving. Spreadsheets stop scaling once your stakeholders, items, or feedback sources grow, but until then a maintained sheet does the job.

### How is a roadmap different from a backlog?

A backlog is a full list of everything you might build, organized for engineering to pull from. A roadmap is a strategic view of what you plan to build, why, and roughly when. Roadmaps are shorter, higher-level, and time-bound. A list of 200 items is a backlog.

### How often should I update a Google Sheets roadmap?

Once a week is usually enough. Updating status more often makes the sheet feel unstable, since stakeholders cannot track daily shifts. A Monday morning pass over all active items is a good habit. When something significant changes mid-week, update it then and tell your team directly.

- [12 Product Roadmap Examples for SaaS Teams (With Analysis)](https://quackback.io/blog/product-roadmap-examples): Real product roadmap examples from SaaS companies. Public roadmaps, internal roadmaps, and different formats analyzed with what makes each effective.

Published: 2026-01-06

Every PM has seen a roadmap. Gantt charts that stretch to infinity. Notion pages with three outdated quarters. Spreadsheets that only one person understands. Most roadmaps communicate nothing useful to anyone.

A good roadmap does something harder. It tells your team and your users what you are building, in what order, and why — without committing to a schedule you cannot keep. These 12 examples, drawn from real SaaS companies and internal planning formats, show what that looks like in practice.

![Product roadmap examples showing different formats](/blog/product-roadmap-examples/hero.webp)

> A good product roadmap communicates what you are building, in what order, and why — without promising a fixed schedule. The strongest examples (Linear, Notion, GitHub, Cal.com, Raycast) share five traits: clear priorities, realistic scope, items tied to user feedback, intent rather than commitments, and detail matched to the audience. Public roadmaps lean on kanban or changelog formats; internal ones use Now/Next/Later, quarterly themes, or outcome-based planning.
>
> *Company roadmap formats last verified May 2026. Public roadmaps change often — check each link for the current layout.*

## What makes a good product roadmap

A good product roadmap is a prioritized, audience-appropriate view of what a team is building and why, communicating direction without committing to a fixed delivery schedule. Most roadmap problems come from conflating intent with commitment, or from showing the same roadmap to everyone regardless of audience.

A good product roadmap has five properties:

**Clear priorities.** Your most important work is obviously most important. Users and stakeholders should not have to ask what matters most this quarter.

**Realistic scope.** The roadmap reflects your actual capacity. A roadmap that includes everything is a roadmap that plans nothing. Cut ruthlessly.

**Tied to user feedback.** Items on the roadmap trace back to real user problems. Requests with vote counts. Support tickets with patterns. Qualitative interviews. The roadmap is not your engineering team's wishlist — it is your response to what users actually need.

**Intent, not commitments.** A roadmap communicates direction. It is not a contract. "We plan to build X in Q2" is different from "X will ship May 15." The best roadmaps make this distinction explicit.

**Appropriate detail for the audience.** Your board gets a theme-level view. Your engineering team gets a quarterly breakdown. Your users get a kanban with statuses. Showing the wrong level of detail to any audience creates confusion and unrealistic expectations.

With those criteria in mind, here are 12 examples worth studying.

![Three roadmap formats compared side by side: timeline, kanban, and Now/Next/Later](/blog/product-roadmap-examples/roadmap-formats-compared.webp)

## Public roadmap examples

Public roadmaps are a different challenge from internal ones. You cannot hedge with "TBD" columns or internal jargon. Every status and every label is a message to a customer who may be evaluating you against a competitor.

### 1. Linear

Linear's public roadmap uses a clean kanban layout with three columns: Planned, In Progress, and Done. Each card shows a title and a one-line description. No estimated dates. No priority scores. No feature explanations beyond what the title communicates.

What works here is the restraint. Linear commits only to what they can show without caveats. The Done column does most of the credibility work — it shows a long history of shipped work, which is more convincing than any promise about the future. The In Progress column is always short, which signals that Linear does not overload their pipeline.

**Format:** Three-column kanban
**Audience:** Existing users and potential customers
**Detail level:** Minimal — title and one line per item
**What it communicates:** We ship consistently, we have clear priorities, we don't overpromise

### 2. Notion

Notion does not publish a traditional roadmap. Instead, they lead with a "What's new" page — a reverse-chronological changelog of shipped features. The implied message is: judge us on what we have built, not on what we say we will build.

This is an honest approach for a company at Notion's scale. Their feature velocity is high enough that a changelog tells the product story more convincingly than a kanban with speculative planned items. The tradeoff is that users who want to know whether a specific missing feature is coming have no place to look.

**Format:** Changelog-first, no traditional roadmap
**Audience:** Existing users, power users
**Detail level:** High on shipped features, zero on future plans
**What it communicates:** We ship fast. Check back often.

### 3. GitHub

GitHub's public roadmap is a GitHub repository — literally a collection of GitHub Issues with labels, milestones, and a project board. Users can react to issues with emoji, leave comments, and link their own issues to the roadmap items.

The format is clever because GitHub's core user is a developer who lives in GitHub. The roadmap meets the audience where they already are. It is also genuinely interactive: GitHub product managers respond to comments, which turns the roadmap into a two-way communication channel. The community-driven nature gives users a sense of influence, even when their requests aren't directly on the board.

**Format:** GitHub Issues with project board
**Audience:** Developers and technical users
**Detail level:** Medium — issues include context, but estimates are rare
**What it communicates:** We build in the open. Your input reaches us directly.

### 4. Cal.com

Cal.com is open source, which makes radical transparency the natural choice. Their public roadmap lives on a GitHub board and is visible alongside their codebase. Anyone can see what is being built, submit pull requests, and contribute directly to items on the roadmap.

The result is a roadmap that is genuinely community-driven. Feature priorities shift based on who shows up and contributes. This works well for an open-source project where contributors are also users. It is harder to replicate for closed-source products where the community cannot directly influence velocity by writing code.

**Format:** GitHub project board, open to community
**Audience:** Developers, contributors, self-hosters
**Detail level:** High — issues include acceptance criteria and technical context
**What it communicates:** This is your product too. Build what you need.

### 5. Plausible

Plausible's roadmap is a simple list grouped by status: Done, In Progress, and Planned. Each item has a title and links to a corresponding GitHub issue or feedback thread. The list is short — rarely more than a dozen items across all three statuses.

The short list is deliberate. Plausible is a small team with a focused product. A long roadmap would be dishonest about their capacity. Linking items to GitHub issues also closes the loop between the public roadmap and the underlying work, so users can follow progress without relying on status updates.

**Format:** Simple status-grouped list with issue links
**Audience:** Privacy-focused users and small teams
**Detail level:** Minimal — title and status only
**What it communicates:** We know what we are building. We're not pretending otherwise.

### 6. Resend

Resend combines their changelog and roadmap on a single page. Recent changelog entries sit at the top. A short "Coming soon" section sits below. The whole thing is minimal, developer-focused, and updated frequently.

This format works because Resend's audience — developers building email infrastructure — cares more about what shipped yesterday than what might ship next quarter. The changelog-first layout reflects that. The "Coming soon" section avoids dates and commitments while still giving users a signal about direction.

**Format:** Changelog + short planned section
**Audience:** Developers and technical users
**Detail level:** High for shipped items, low for planned ones
**What it communicates:** We move fast. Here's proof.

### 7. Raycast

Raycast uses a community-driven roadmap with voting. Users submit feature requests, upvote the ones they care about, and watch the roadmap to see what gets prioritized. The Raycast team responds to requests, closes duplicates, and explains decisions in comment threads.

What makes Raycast's approach work is the quality of the engagement. The team does not just collect votes — they explain why highly-voted items did or didn't make the roadmap. That transparency builds more trust than a silent vote count would. Users feel heard even when their request doesn't ship.

**Format:** Voting board with active team engagement
**Audience:** Power users, extension developers
**Detail level:** Medium — request title, vote count, team response
**What it communicates:** Your votes shape what we build. We'll tell you why we made each call.

### 8. Canny's own roadmap

Canny builds feedback and roadmap software, so their own roadmap is a live demonstration of their product. It uses their voting board and kanban roadmap exactly as their customers would. Feature requests with vote counts feed directly into a public roadmap with statuses.

The dogfooding aspect is intentional. Prospects can see the product in action before signing up. The roadmap also shows items in Canny's own backlog that were requested by Canny users, closing the loop between customer feedback and product direction. If you are evaluating roadmap software, seeing how the vendor uses their own tool is useful signal.

[Quackback](/compare/quackback-vs-canny) takes the same closed-loop approach but is open source (AGPL-3.0) — you can self-host it free or run it on Quackback Cloud, and inspect the code that powers your public roadmap.

**Format:** Canny voting board + kanban roadmap (their own product)
**Audience:** Customers and prospects evaluating the tool
**Detail level:** Medium — vote counts, statuses, request detail
**What it communicates:** We use what we sell. Here's what we're building next.

## Internal roadmap examples

Internal roadmaps serve a different purpose. They align your team, not your customers. The audience is people who need to understand priorities, dependencies, and trade-offs to do their jobs well.

### 9. Now / Next / Later

The Now/Next/Later format divides work into three buckets: what the team is actively building, what they will build next, and what they intend to build eventually. There are no dates. No quarter labels. Just three columns that reflect relative priority.

**When to use it:** Early-stage teams, fast-moving products, situations where quarterly planning feels premature. Also useful when you want to share direction without locking in a timeline.

**Pros:**
- Forces triage. If everything is "Now," the format breaks.
- Survives disruption. Pivots don't require the whole roadmap to be rebuilt.
- Easy to explain to any audience, including non-technical stakeholders.

**Cons:**
- No time information, which frustrates teams that need to sequence work against external commitments.
- "Later" can become a graveyard for ideas no one will revisit.
- Hard to use for cross-functional coordination where timing matters.

### 10. Quarterly theme-based roadmap

The quarterly theme-based format groups work into named strategic themes for each quarter. Instead of a list of features, you communicate intent: Q1 is about onboarding, Q2 is about retention, Q3 is about enterprise readiness. Individual features live inside themes, but the theme is the unit of communication.

**When to use it:** Series A and beyond, when you have enough track record to plan by quarter and enough complexity to need a common language across teams.

**Pros:**
- Aligns cross-functional teams around shared goals rather than individual features.
- Makes it easier to say no. "That doesn't fit our Q3 theme" is a clearer answer than "we're too busy."
- Survives scope changes within a quarter — if a feature gets cut, the theme still holds.

**Cons:**
- Themes can be vague enough to mean everything and nothing.
- Engineers may not connect their daily work to the theme without explicit mapping.
- Quarterly cadence can feel slow for fast-moving products.

### 11. Timeline with swimlanes

The timeline format lays work across a calendar on horizontal swimlanes — one lane per team or product area. This is the closest thing to a traditional Gantt chart, but organized around teams rather than individual tasks.

**When to use it:** Multi-team organizations where coordination across engineering, design, marketing, and infrastructure matters. Useful for planning launches that require simultaneous work from multiple groups.

**Pros:**
- Makes dependencies visible at a glance.
- Supports capacity planning across teams.
- Useful for external communication with enterprise customers who want delivery windows.

**Cons:**
- High maintenance overhead. Timeline roadmaps go stale faster than any other format.
- Creates false precision. A bar on a Gantt chart looks like a commitment even when it isn't.
- Not useful for early-stage teams or products where scope changes weekly.

### 12. Outcome-based roadmap

The outcome-based roadmap organizes work around metrics rather than features. Instead of "Build SSO," the roadmap says "Reduce enterprise deal friction: target 20% reduction in sales cycle length." The features that might contribute to that outcome appear as options, not commitments.

**When to use it:** Product-led growth teams, mature products where the connection between features and outcomes is well-understood, and organizations that have moved past the "build everything on the backlog" phase.

**Pros:**
- Forces clarity on why you are building each thing.
- Keeps the team focused on impact rather than output.
- Survives feature changes — if a different feature achieves the same outcome, the roadmap is still valid.

**Cons:**
- Requires a culture that is comfortable with uncertainty about implementation.
- Hard to explain to stakeholders who want to know exactly what will ship.
- Needs reliable analytics to measure whether outcomes are being achieved.

## Roadmap formats compared

| Format | Best for | Flexibility | Stakeholder clarity | Maintenance effort |
|---|---|---|---|---|
| Public kanban (Linear-style) | User-facing transparency | Medium | High | Low |
| Changelog-first (Notion-style) | Fast-shipping teams | High | Low | Low |
| GitHub Issues | Developer audiences | High | Medium | Medium |
| Voting board (Raycast-style) | Community-driven products | High | High | Medium |
| Now / Next / Later | Early-stage teams | Very high | High | Very low |
| Quarterly theme-based | Series A+, multi-team | Medium | High | Medium |
| Timeline with swimlanes | Cross-functional coordination | Low | Very high | High |
| Outcome-based | Growth-stage, metrics-driven | High | Medium | Medium |

Flexibility refers to how easily the format accommodates changes in scope or timing. Stakeholder clarity refers to how quickly someone unfamiliar with your roadmap can understand priorities. Maintenance effort refers to how much ongoing work is required to keep the roadmap accurate.

No single format is best for every team. Most teams use a combination — an internal outcome-based roadmap for planning, a quarterly theme view for leadership, and a public kanban for customers.

## How to build your own roadmap

The format is the last decision, not the first. Start with the inputs.

**Step 1: Collect feedback.** Your roadmap should reflect what your users actually need, not what your team assumes they need. Use a [feedback board](/features/feedback) to capture requests, votes, and comments. Look at support ticket patterns. Run user interviews. Read your NPS responses. The goal is a clear picture of where your users are struggling.

**Step 2: Prioritize.** With a list of candidates, apply a structured scoring method. The [RICE framework](/blog/rice-framework-explained) — Reach, Impact, Confidence, Effort — is a good starting point. It forces you to estimate each factor separately, which surfaces trade-offs that gut feeling obscures. Sort your candidates by score and use the result as a starting point for conversation, not a final answer.

**Step 3: Group into themes.** Individual features are hard to communicate at the roadmap level. Group related features into themes that describe the user problem you are solving. "Reduce time to first value" is a better roadmap item than a list of eight onboarding improvements. Themes also make it easier to absorb scope changes — if one feature in a theme gets cut, the theme still makes sense.

**Step 4: Choose your format.** Match the format to your audience and your planning maturity. Early-stage teams should default to Now/Next/Later. Teams with quarterly planning cycles should use a theme-based format. Teams sharing with customers should use a public kanban. Don't use a timeline unless you have the coordination overhead that justifies the maintenance cost.

**Step 5: Set a review cadence.** A roadmap reviewed once and never updated is worse than no roadmap — it creates false expectations. Set a recurring review: monthly for the Now column, quarterly for Next and Later. Assign someone to own updates. If that person leaves, the roadmap dies.

**Step 6: Share and close the loop.** Publish your public roadmap where users can find it. Link it from your product, your docs, and your support channels. When items ship, notify the users who requested them. [Quackback's roadmap feature](/features/roadmap) handles this automatically — every item on the roadmap links back to its source feedback, and voters get notified when their request ships via the changelog.

The loop matters. Users who see their feedback acted on become advocates. Users who submit feedback into silence stop submitting feedback. Closing the loop is what separates a roadmap from a planning document.

If you want to see what this looks like in practice, the [best public roadmap tools](/blog/best-public-roadmap-tools) guide compares tools that make the public-facing side easier to maintain. For teams building an [agile roadmap](/blog/agile-roadmap), the format considerations are somewhat different — the agile context demands formats that absorb change without requiring a full rebuild each sprint.

Roadmaps for specific contexts like [technology roadmaps](/blog/technology-roadmap) and [marketing roadmaps](/blog/marketing-roadmap) follow similar principles but have their own audience and timing considerations worth understanding separately.

---

> **Try Quackback** — open source with a managed cloud option. Build a public [roadmap](/features/roadmap) where every item links back to its source [feedback](/features/feedback), and voters get notified through the [changelog](/features/changelog) when their request ships. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How often should you update a product roadmap?

Keep the Now column current at all times, review the Next column monthly, and review the Later column or strategic themes quarterly. Fast-moving products benefit from monthly reviews across the whole roadmap. The key is a fixed cadence, not reactive updates after someone notices the roadmap is wrong.

### Should you share a roadmap with customers?

Most SaaS teams should publish some version of a public roadmap. It reduces "when is this coming?" support volume, builds trust with users who can see their feedback being acted on, and differentiates you from competitors who hide their direction. The caveat is that you should only publish what you are reasonably confident you will build. A public roadmap full of items that never ship is worse than no roadmap at all.

### What is the difference between a roadmap and a backlog?

A backlog is an unordered or lightly ordered list of all potential work, often hundreds of items. A roadmap is a curated, prioritized view of what you have committed to building and when, usually tens of items. The roadmap is a communication tool; the backlog is a planning artifact.

### How do you handle requests that don't make the roadmap?

Close the loop with the users who submitted them. A brief explanation — "we're focusing on X this quarter" or "we don't have a timeline for this yet, but we're tracking demand" — is better than silence. Tools like [Quackback](/features/feedback) let you set statuses on feedback items and notify voters automatically, so you're not manually emailing everyone who upvoted a feature that didn't make the cut. Users appreciate honesty about priorities far more than vague reassurances.

- [Agile Roadmap: How to Build a Flexible Product Roadmap (2026)](https://quackback.io/blog/agile-roadmap): How to build an agile product roadmap that adapts to feedback and changing priorities. Includes a now/next/later template, examples, format types, and common mistakes to avoid.

Published: 2025-12-30

Traditional roadmaps promise dates. Agile roadmaps promise direction. That distinction matters the moment reality changes, and reality always changes.

A fixed-date roadmap built in January is obsolete by March. A competitor ships a feature you hadn't planned for. A user segment you thought was secondary turns out to be your best customers. A technical constraint surfaces that shifts three months of work. Teams that built their roadmap around calendar commitments spend the rest of the year defending a plan that no longer reflects what they know.

![Agile roadmap with now, next, later columns](/blog/agile-roadmap/hero.webp)

> An **agile roadmap** is a flexible, outcome-focused plan that communicates product direction through themes and rough time horizons rather than fixed features and release dates. It is built around now/next/later horizons and updated each cycle as user feedback and evidence come in. Use it to communicate direction and learn, not to lock in a delivery schedule that will be wrong by the time you reach it.

An agile roadmap treats planning as an ongoing process, not a one-time event. It is a tool for communicating direction and learning from feedback, not for locking in a delivery schedule that will be wrong by the time you reach it.

## What is an agile roadmap?

An agile roadmap is a flexible, outcome-focused plan that evolves as your team learns. It describes where you are going and why, organized around themes and goals rather than specific features and release dates.

It is not a Gantt chart. Gantt charts encode dates, dependencies, and sequences with a level of false precision that most product work cannot support. It is not a commitment calendar. A roadmap that promises feature X in Q3 treats planning like a contract, which creates the wrong incentives.

An agile roadmap answers different questions:

- What are we focused on right now?
- What comes next once current work is done?
- What are we considering for later, once we understand more?
- What user outcomes are we trying to achieve?

The format varies, but the underlying principle is consistent: the further out you plan, the less specific you should be. Near-term work is concrete. Future work is intentionally rough.

## Agile roadmap vs traditional roadmap

The difference between an agile and a traditional roadmap is not just format. It reflects a different theory of how product development works.

Traditional roadmaps assume that requirements are knowable upfront, that estimates are accurate, and that the world stays stable long enough to execute the plan. Agile roadmaps assume the opposite: that you will learn things as you build, that the market will shift, and that the plan needs to accommodate that.

![Agile roadmap vs traditional roadmap comparison](/blog/agile-roadmap/comparison.webp)

| | Traditional roadmap | Agile roadmap |
|---|---|---|
| Timeframe | Fixed quarters and annual plans | Rolling horizons (now/next/later) |
| Detail level | Feature-specific with acceptance criteria | Theme or outcome level, details emerge later |
| Flexibility | Low — changes require re-planning | High — review and adjust each cycle |
| Stakeholder communication | Status against a committed plan | Direction, priorities, and what you are learning |
| Date commitments | Specific release dates per feature | Rough time horizons, not hard dates |
| Driven by | Initial requirements | Ongoing feedback and evidence |

Neither approach is universally wrong. Some work genuinely requires fixed dates: regulatory deadlines, hardware dependencies, contractual launch windows. The issue is applying date-driven planning to product work that does not need it and losing the flexibility to respond when things change.

For most product teams building software, an agile roadmap is a better fit. You are making decisions under uncertainty, and your planning method should account for that.

## Types of agile roadmaps

There is no single agile roadmap format. Different structures suit different teams and contexts.

### Now/Next/Later

The most common agile roadmap format. Work is organized into three time horizons without fixed dates attached:

- **Now:** What the team is actively working on. This is concrete — specific problems, clear scope, work in progress.
- **Next:** What comes after current work is complete, assuming priorities don't change. Reasonably well-defined, but not scheduled.
- **Later:** Things you want to address eventually. Intentionally vague. The further out an item, the less you know about it.

Now/Next/Later works well for teams that need to communicate priorities without overpromising on dates. It manages stakeholder expectations honestly: "we're working on this now, and this is what we're thinking about next."

### Theme-based

Work is grouped by strategic objective rather than time horizon. Themes might be things like "Improve onboarding," "Expand enterprise capabilities," or "Reduce churn." Each theme contains a collection of initiatives that contribute to that goal.

Theme-based roadmaps are useful when you want to communicate the strategic intent behind what you're building. They make it easier for stakeholders to see how individual features connect to larger goals.

### Outcome-based

Instead of organizing by features or themes, outcome-based roadmaps are organized by the metrics you want to move. "Reduce time to first value from 7 days to 2 days." "Increase monthly active usage from 40% to 60%." "Reduce support tickets per user by 30%."

Features appear in service of outcomes, not as ends in themselves. This is the format most aligned with a product-led approach. It forces the team to connect their work to measurable results and to stay open about which specific features will achieve those results.

### Sprint-level

A sprint plan that shows what the engineering team is working on in a specific two-week cycle. This is appropriate for engineering team communication, not for external stakeholders or executives.

The mistake teams make is treating the sprint plan as their roadmap. Sprint plans are too granular and too short-term to communicate product direction. A roadmap that changes every two weeks is not a roadmap. Use sprint-level views internally, and use a higher-altitude format for everyone else.

## How to build an agile roadmap

Building an agile roadmap is less about the format and more about the inputs and the discipline to keep it current.

### Step 1: Define product vision and goals

Start with the destination. Before organizing work into now/next/later, you need to know what you're moving toward. If you are still defining the shape of the plan itself, our guide to [what a product roadmap is](/blog/what-is-a-product-roadmap) covers the fundamentals. What does success look like for your product in 12 to 18 months? What outcomes matter most to your users? What does your company need to achieve?

Without a vision, the roadmap becomes a prioritized list of requests with no connecting thread. Each item might be reasonable in isolation, but together they don't add up to anything. Your vision is the filter through which requests, ideas, and opportunities get evaluated.

Write it down in concrete terms. "We help small SaaS teams understand what their users want and close the loop publicly" is more useful than "we build a feedback platform." The more specific your vision, the more useful it is as a decision-making tool.

### Step 2: Collect and prioritize feedback

Your roadmap should reflect what you know about your users, not just what your team thinks is important. Systematic feedback collection gives you evidence to back up prioritization decisions and surfaces problems you would not have found otherwise.

The [RICE framework](/blog/rice-framework-explained) is a structured way to score and compare items in your backlog. It weighs Reach (how many users are affected), Impact (how much it moves the needle), Confidence (how sure you are), and Effort (how much work it takes). Scoring feedback items through RICE helps you move from instinct-based prioritization to evidence-based prioritization. If RICE feels heavy for your stage, [MoSCoW prioritization](/blog/moscow-prioritization) and a [prioritization matrix](/blog/prioritization-matrix-template) are lighter alternatives.

Your [feedback board](/features/feedback) is the right place to collect this input continuously. Users who vote, comment, or submit requests are giving you signal about what matters to them. When you see 40 users requesting the same thing, that is stronger evidence than one vocal customer requesting something in a sales call.

### Step 3: Group into themes or outcomes

Once you have collected and prioritized feedback, look for patterns. Multiple related requests often point to the same underlying problem or opportunity. Grouping them into themes helps you see the strategic shape of your backlog.

"Users want better notifications," "users want email digests," and "users want to know when their issues are resolved" might all point to the same theme: keeping users informed about status, which is the core of a healthy [customer feedback loop](/blog/customer-feedback-loop). The theme is what goes on the roadmap. The specific features are what you figure out once you've committed to solving the problem.

This grouping step also helps you say no. If a request doesn't fit any theme you've defined, and the themes connect to your product vision, you have a principled reason to deprioritize it.

### Step 4: Set rough time horizons

Assign work to time horizons, not specific dates. Now is what you're actively doing. Next is what comes after. Later is the queue.

Resist the pull toward quarters. Quarterly planning is often just date-driven planning with extra steps. The moment you write "Q3" next to a feature, stakeholders start treating it as a commitment. If you can't avoid quarters for organizational reasons, use ranges: "H2 2026" communicates less false precision than "Q3 2026."

Later items should deliberately stay vague. You don't have enough information yet to make detailed plans about work that is three or four cycles away. Treat later as a holding area, not a promise.

### Step 5: Review and adapt each cycle

The discipline that makes an agile roadmap actually agile is the regular review. At the end of each sprint or cycle, ask: What did we learn? What changed? Does the roadmap still reflect our best current thinking?

This review should be short and structured. Did items in "now" complete? Do the items in "next" still make sense given what you learned? Has new evidence come in that should reprioritize "later"?

Move things. Remove things. Add things when strong evidence supports it. The roadmap is a living document. If it hasn't changed in three months, either you have exceptional planning skills or you're not updating it when you should be.

## Agile roadmap template

Here is a simple now/next/later template you can adapt. The key columns are theme (the strategic goal), specific items under that theme, current status, and the evidence supporting the priority.

| Theme | Items | Status | Evidence |
|---|---|---|---|
| Onboarding | Guided setup flow, welcome email sequence | In progress | 12 support tickets/month on setup, 8% drop-off at step 3 |
| Notifications | Digest emails, in-app status updates | Next | 67 votes on feedback board, most-requested category |
| Integrations | Slack integration, Zapier connector | Next | 34 votes, 3 enterprise prospects blocked on this |
| Reporting | Usage analytics dashboard, export to CSV | Later | 18 votes, no urgency from current users |
| Mobile | Native iOS app | Later | 5 votes, low signal for now |

Status options: In progress, Next, Later, Won't do. Keep the "Won't do" category. It communicates deliberate decisions, not just gaps.

Update this table every sprint. If an item has been in "Next" for three cycles without moving, either pull it into active work or move it to "Later" with an honest assessment of why.

## Common mistakes

**Over-committing to dates.** The most common roadmap mistake. Once a date is attached to a feature, it becomes a commitment in stakeholders' minds even if you said it was an estimate. Agile roadmaps use time horizons for a reason. Defend that choice.

**Not connecting to user feedback.** A roadmap built from internal opinions drifts from user reality. If you can't point to user evidence for each item on your roadmap, that is a sign the roadmap is being driven by assumptions rather than signals. Connect every theme to concrete feedback.

**Treating the roadmap as a contract.** A roadmap is your current best thinking about priorities given what you know now. It is not a legal commitment. Teams that treat it as one stop updating it honestly, because every change feels like a failure. Change is information, not failure.

**Never saying "won't do."** A roadmap without a "won't do" category is a prioritized list, not a strategy. Saying no to things is as important as saying yes. If everything is on the roadmap eventually, the roadmap doesn't help anyone understand your focus.

**Building in isolation.** Roadmaps built by product managers without input from engineering, design, customer success, or users tend to have the wrong priorities and unrealistic scopes. The roadmap should reflect the team's collective understanding, not a single person's opinion.

## Tools for agile roadmapping

Most teams start with a spreadsheet or a Notion doc. That works fine when the team is small and the audience is internal. As your roadmap becomes something you share externally, the limitations show up quickly. A static document doesn't reflect real-time status, doesn't connect to user feedback, and doesn't give users a way to engage with your plans.

Purpose-built roadmap tools solve those problems. They maintain status automatically, link roadmap items to votes and comments on your feedback board, and give users a public view that builds trust.

[Quackback's roadmap feature](/features/roadmap) connects directly to your feedback board. When users vote on a request, that signal is visible alongside the roadmap item. When you move something to "in progress" or "shipped," users who voted get notified. The loop between user feedback and what you're building is closed in one place rather than managed across separate tools. When we built Quackback's own roadmap, this is the workflow we wanted for ourselves: the votes that justify a theme sit right next to the theme.

A few things matter for the way an agile roadmap actually gets used:

- **An [MCP server](/features/mcp).** Your roadmap and feedback data are accessible to AI agents over the Model Context Protocol, so you can ask an assistant "what is in Next and why" and have it read the real signal behind each item.
- **Open source and self-hostable.** Quackback is open source under AGPL-3.0 and free to self-host, with a managed [Quackback Cloud](/pricing) option if you would rather not run it yourself.

Slack is the most common place teams discuss roadmap changes, so the [Slack integration](/integrations/slack) pushes new votes and status changes into a channel as they happen.

For a comparison of other options, see our guide to [best public roadmap tools](/blog/best-public-roadmap-tools) and our [Quackback vs Productboard](/compare/quackback-vs-productboard) breakdown for a roadmap-heavy alternative. For more worked examples, see [product roadmap examples](/blog/product-roadmap-examples).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is the difference between an agile roadmap and a product backlog?

A product backlog is a prioritized list of work items at the task or story level. An agile roadmap operates at a higher level — themes, outcomes, and rough time horizons. The backlog is an input to the roadmap, not the roadmap itself. If your roadmap looks like a backlog with a lot of rows, you are probably too detailed.

### How often should you update an agile roadmap?

Review it every sprint or cycle and make minor updates as needed. Do a more thorough reassessment every quarter: review what shipped, what changed in your understanding of user needs, and whether the themes still connect to your product vision. The cadence matters less than the consistency.

### How do you communicate an agile roadmap to stakeholders who expect dates?

Acknowledge the tension directly. Explain that time horizons are more honest than specific dates for work where estimates are uncertain, and that the roadmap reflects current priorities rather than a delivery schedule. Stakeholders often accept this framing when they understand that date commitments on uncertain work lead to worse outcomes — delays get hidden rather than surfaced early.

### Can agile roadmaps work for teams with fixed release cycles?

Yes. The now/next/later structure is compatible with fixed release schedules. "Now" maps to the current release. "Next" maps to the following one. "Later" is the queue beyond that. The key difference is resisting the urge to overpromise on the contents of future releases before you know what will actually fit.

- [Bug Report Template: 5 Free Templates for Dev Teams](https://quackback.io/blog/bug-report-template): Free bug report templates for QA, development, and customer-reported issues. Includes templates for Jira, GitHub Issues, and general use.

Published: 2025-12-23

A bad bug report wastes more time than the bug itself. "It doesn't work" tells your team nothing. Your developer now has to track down the reporter, ask clarifying questions, attempt to reproduce the issue blind, and hope they find the right environment. That's an hour of lost work before anyone has looked at code.

Good bug reports are self-contained. They give the next person everything they need to reproduce, understand, and fix the problem without any back-and-forth.

![Bug report template with structured fields for reproduction steps](/blog/bug-report-template/hero.webp)

The templates below cover five scenarios: general development, QA testing, customer-reported issues, GitHub Issues, and Jira. Copy the one that fits your workflow and adapt it to your team's needs.

## What makes a good bug report

A good bug report is reproducible, specific, and includes enough environment detail that someone who has never seen the bug can reproduce it from your description alone.

Reproducibility is the foundation. If your developer cannot reproduce the bug, they cannot fix it. Vague reports like "the page crashed" or "checkout didn't work" fail this test. A good report describes the exact sequence of steps that reliably triggers the issue.

Specificity means including the what, not just the that. Not "the button doesn't work" but "clicking the Submit button on the /checkout page with an empty cart triggers a 500 error instead of the expected validation message."

Environment details matter because bugs are often context-dependent. A bug that appears in Safari 17 on macOS but not in Chrome may point to a CSS rendering issue. A bug that appears in production but not in staging may point to a configuration difference. Without environment information, your team is guessing.

Severity and priority belong in every report. Not all bugs are equal. A crash on the sign-up page blocks new users entirely. A misaligned icon on the settings page does not. Clear severity labels help your team triage without reading every report in full.

![Bug report template structure showing fields for title, severity, steps to reproduce, expected vs actual behavior, environment, and screenshots](/blog/bug-report-template/template-structure.webp)

## Simple bug report template

This template works for any bug, in any codebase, submitted by any member of your team. It covers the essentials without requiring specialized knowledge.

```markdown
## Bug Report

**Title:** [Short, specific description of the bug]

**Severity:** Critical / High / Medium / Low

---

### Steps to reproduce

1. Go to [URL or screen]
2. [Action taken]
3. [Next action]
4. [Continue until bug occurs]

### Expected behavior

[What should happen when you follow the steps above]

### Actual behavior

[What actually happens — be specific about error messages, incorrect output, or unexpected state]

### Environment

- **OS:** [e.g. macOS 14.4, Windows 11, Ubuntu 22.04]
- **Browser:** [e.g. Chrome 124, Safari 17.4, Firefox 125] (if applicable)
- **App version / build:** [e.g. v2.3.1, build #4502]
- **Device:** [e.g. Desktop, iPhone 15 Pro] (if applicable)

### Screenshots / video

[Attach or link to any visual evidence. Include console errors if relevant.]

### Additional context

[Any other information that might help: recent changes, frequency of occurrence, whether the bug is consistent or intermittent]
```

This template is intentionally lean. It forces the reporter to think through the minimum information needed for reproduction. For most bug reports, this is sufficient.

## QA bug report template

QA teams need more structure. A bug found during testing has additional context: the test case that exposed it, the build it was found in, and whether it's a regression. This template captures that information systematically.

```markdown
## QA Bug Report

**Title:** [Short, specific description of the bug]

**Severity:** Critical / High / Medium / Low
**Priority:** P1 / P2 / P3 / P4

**Test case ID:** [e.g. TC-204]
**Build version:** [e.g. v2.4.0-rc.1, build #5018]
**Date found:** [YYYY-MM-DD]
**Found by:** [Tester name]

---

### Is this a regression?

- [ ] Yes — previously working, broken in this build
- [ ] No — new functionality, never worked
- [ ] Unknown

**Last known good build (if regression):** [e.g. v2.3.1, build #4902]

### Test environment

| Environment | Value |
|-------------|-------|
| OS | [e.g. Windows 11 22H2] |
| Browser | [e.g. Chrome 124.0.6367.82] |
| Device | [e.g. Desktop / iPhone 15 / Samsung Galaxy S24] |
| Test environment | [e.g. Staging, QA, UAT] |
| Network | [e.g. VPN, corporate proxy, standard broadband] |

### Steps to reproduce

1. [Preconditions: account type, test data, permissions required]
2. [Step 1]
3. [Step 2]
4. [Continue until bug occurs]

### Expected behavior

[What the test case expects to happen]

### Actual behavior

[What actually happened — include full error messages, incorrect values, or unexpected state]

### Reproducibility

- [ ] Always (100%)
- [ ] Often (>50%)
- [ ] Intermittent (<50%)
- [ ] Rare (occurred once)

### Affected environments

| Environment | Affected? |
|-------------|-----------|
| Development | Yes / No / Not tested |
| Staging | Yes / No / Not tested |
| Production | Yes / No / Not tested |

### Attachments

- [ ] Screenshot(s)
- [ ] Screen recording
- [ ] Console log
- [ ] Network log (HAR file)
- [ ] Test data used

### Notes

[Additional observations, related tickets, workarounds discovered]
```

The regression check is particularly important. Knowing that a bug was working in the previous build narrows the search significantly — your developer can focus on what changed between the last good build and the current one.

## Customer-reported bug template

Customers are not developers. They don't know what a stack trace is, they can't tell you their browser version without help, and they shouldn't have to. A customer-facing bug template should be as simple as possible while still capturing the information your team needs.

```markdown
## Something not working? Tell us what happened.

**What happened?**
[Describe what went wrong in your own words]

**What did you expect to happen?**
[What were you trying to do, and what did you think would happen?]

**When did this happen?**
[e.g. Today around 2pm, last Tuesday, every time I try to do X]

**How often does this happen?**
- [ ] Every time I try
- [ ] Sometimes
- [ ] Only happened once

**What were you using?**
- [ ] Computer (Windows)
- [ ] Computer (Mac)
- [ ] iPhone / iPad
- [ ] Android phone or tablet
- [ ] Other: ___________

**Screenshot**
[If you can, attach a screenshot of the problem. It helps us find and fix it faster.]

**Your email (optional)**
[So we can follow up with you directly when it's fixed]
```

Keep the customer template short. Every additional field reduces completion rates. The goal is to capture enough to reproduce the issue internally — your support team can follow up for more detail if needed.

If you use a feedback tool, this template can feed directly into your [feedback board](/features/feedback) so reports are visible to your team without manual routing.

## GitHub Issues bug template

GitHub supports structured issue templates via YAML. Place this file at `.github/ISSUE_TEMPLATE/bug_report.yml` in your repository. It renders as a form in the GitHub UI, which significantly improves report quality compared to freeform markdown.

```yaml
name: Bug Report
description: Report a bug or unexpected behavior
title: "[Bug]: "
labels: ["bug", "triage"]
assignees: []

body:
  - type: markdown
    attributes:
      value: |
        Thank you for taking the time to report a bug. Fill out as much detail as you can.
        Before submitting, please search existing issues to avoid duplicates.

  - type: textarea
    id: description
    attributes:
      label: What happened?
      description: A clear description of the bug.
      placeholder: Describe what went wrong.
    validations:
      required: true

  - type: textarea
    id: reproduction
    attributes:
      label: Steps to reproduce
      description: Exact steps to reproduce the behavior.
      placeholder: |
        1. Go to '...'
        2. Click on '...'
        3. Scroll down to '...'
        4. See error
    validations:
      required: true

  - type: textarea
    id: expected
    attributes:
      label: Expected behavior
      description: What did you expect to happen?
    validations:
      required: true

  - type: textarea
    id: actual
    attributes:
      label: Actual behavior
      description: What actually happened? Include error messages verbatim.
    validations:
      required: true

  - type: input
    id: version
    attributes:
      label: Version
      description: What version of the software are you running?
      placeholder: e.g. v2.3.1
    validations:
      required: true

  - type: dropdown
    id: os
    attributes:
      label: Operating system
      options:
        - macOS
        - Windows
        - Linux
        - iOS
        - Android
        - Other
    validations:
      required: true

  - type: dropdown
    id: browser
    attributes:
      label: Browser (if applicable)
      options:
        - Chrome
        - Firefox
        - Safari
        - Edge
        - Not applicable
        - Other

  - type: dropdown
    id: severity
    attributes:
      label: Severity
      options:
        - Critical — app crash, data loss, security issue
        - High — major feature broken, no workaround
        - Medium — feature partially broken, workaround exists
        - Low — minor visual or UX issue
    validations:
      required: true

  - type: textarea
    id: context
    attributes:
      label: Additional context
      description: Screenshots, logs, or any other relevant information.

  - type: checkboxes
    id: checklist
    attributes:
      label: Checklist
      options:
        - label: I have searched existing issues and this is not a duplicate
          required: true
        - label: I have tested this on the latest version
          required: false
```

The YAML format enforces completeness. Required fields cannot be skipped, dropdown fields prevent inconsistent entries, and the checklist reminds reporters to search for duplicates before submitting.

## Jira bug template

Jira uses structured fields rather than freeform markdown. The template below maps to standard Jira issue fields. Your Jira admin can configure a Bug issue type with these fields as defaults, or you can paste the description block into a Jira text field using the Jira markup format.

```
Summary: [Short, specific description — used as the issue title]

Issue Type: Bug

Priority: Blocker / Critical / Major / Minor / Trivial

Labels: [e.g. regression, frontend, api, mobile]

Components: [Relevant components or services]

Affects Version: [e.g. v2.3.1]

Environment:
  OS: [e.g. macOS 14.4]
  Browser: [e.g. Chrome 124]
  Build: [e.g. build #5018]
  Environment: [Production / Staging / QA]

---

h2. Description

[Brief description of the bug and its impact on users or the system]

h2. Steps to Reproduce

# Go to [URL or screen]
# [Action]
# [Action]
# Observe [the bug]

h2. Expected Behavior

[What should happen]

h2. Actual Behavior

[What actually happens — include exact error messages]

h2. Workaround

[If a workaround exists, document it here so affected users can be informed]

h2. Attachments

[Link to or attach screenshots, recordings, logs, or HAR files]

h2. Related Issues

[Link to any related bugs, feature requests, or support tickets]
```

Jira's field-based structure means some information lives outside the description. Make sure your team consistently uses the Priority and Labels fields — bulk filtering by label is far faster than reading through individual descriptions when triaging a backlog.

## Bug report vs feature request

Not everything that feels like a bug is one. The distinction matters because bugs and feature requests are handled differently, prioritized differently, and routed to different parts of your workflow.

A bug is behavior that deviates from what was specified or expected. If the login button throws a 500 error, that's a bug. If the export function produces a malformed CSV, that's a bug. The product is not doing what it's supposed to do.

A feature request is a desire for behavior the product was never designed to have. "I wish I could export to Excel" is a feature request, not a bug — the export function may be working exactly as designed. "The dark mode toggle doesn't persist between sessions" could be either, depending on whether persistence was part of the original spec.

The practical test: if you can point to documented behavior or a user's reasonable expectation that is being violated, it's a bug. If you're asking for something new, it's a feature request.

Misclassifying requests leads to poor prioritization. Bug fixes typically carry more urgency than feature development — a bug that blocks users needs to be fixed before you build new features. If feature requests get logged as bugs, your bug count becomes meaningless as a health metric.

For feature request handling, see the [feature request template](/blog/feature-request-template) and our guide to [the best feature request tools](/blog/best-feature-request-tools).

## Best practices for bug reports

**One bug per report.** Combining multiple issues in a single report makes it hard to assign, track, and close. If you found three bugs, file three reports.

**Always include reproduction steps.** A bug without reproduction steps is a complaint, not a report. Even if the issue seems obvious, write out the steps. What seems obvious to you may not be obvious to the developer who has never used that feature.

**Attach visuals whenever possible.** A screenshot or screen recording eliminates ambiguity. A console screenshot showing the exact error message is more useful than a typed transcription of it.

**Note severity clearly.** Don't leave severity to inference. A report that says "the dashboard is broken" could be anything from a cosmetic glitch to a full outage. Use a severity scale consistently and define it for your team.

**Include the environment.** OS, browser, and version aren't optional fields. A bug that appears in one environment and not another often points directly at the cause.

**Test on the latest version first.** Before filing a bug, verify it occurs on the current release. Bugs in older versions that are already fixed waste triage time. If you can't update, note the version you're on and why.

**Follow up when asked.** Developers often need more information. A bug report where the reporter goes silent after filing is a bug report that stays open. If someone asks for clarification, respond promptly.

For a broader look at how to build feedback processes that work, see the guide on [collecting customer feedback](/blog/collect-customer-feedback).

## Frequently asked questions

### What should I include in a bug report title?

The title should describe the specific behavior and the context in which it occurs. A good formula: `[Component] [action] [unexpected result]`. For example: "Checkout button throws 500 error when cart is empty" or "User avatar missing on mobile Safari after login." Avoid vague titles like "Bug on checkout page" or "Login issue" — these make triage harder and searching the backlog nearly impossible.

### How do I determine the severity of a bug?

Severity is about impact on users, not urgency from a business perspective. A common four-level scale: Critical (app crash, data loss, security vulnerability, or complete feature outage with no workaround), High (major feature broken with no workaround), Medium (feature partially broken or has a workaround), Low (cosmetic issue or minor inconvenience). Agree on definitions with your team before you start filing — inconsistent severity labels are almost as bad as no severity labels at all.

### What's the difference between severity and priority?

Severity describes the impact of the bug on the user. Priority describes the urgency with which your team needs to fix it. A critical bug in a feature used by 0.1% of users may have lower priority than a medium-severity bug that affects every new signup. Both fields belong on a bug report because they answer different questions. Severity is set by the reporter based on impact. Priority is set by the team based on what needs to be fixed first given current resources and context.

- [Feature Request Template: 4 Free Templates for Product Teams](https://quackback.io/blog/feature-request-template): Free feature request templates for product teams. Simple, detailed, internal, and customer-facing templates with best practices for tracking requests.

Published: 2025-12-16

Feature requests arrive everywhere: Slack, email, support tickets, sales calls. Without a template, half of them are missing the context you need to evaluate them. A request that says "can you add dark mode" gives you almost nothing — you don't know who wants it, how many users it affects, or how it compares to everything else on your roadmap.

A template fixes that. It standardizes what you capture, makes prioritization possible, and gives your team a shared language for talking about user needs.

![Feature request template with structured fields](/blog/feature-request-template/hero.webp)

> A **feature request template** is a standardized form that captures the same fields for every incoming request — what the user wants, why they want it, who is affected, and what they do today instead — so a team can compare and prioritize requests fairly. This guide includes four copyable Markdown templates: simple, detailed, internal, and customer-facing.

The right template depends on who is submitting the request and where. A public feedback form needs to be short. An internal product spec needs to be thorough. The templates below cover both ends of that spectrum, plus everything in between.

## Why you need a feature request template

A feature request template enforces a consistent structure on every request that arrives. When there is no standard format, every request looks different. Some include a detailed use case. Others are a single sentence. The inconsistency makes it impossible to compare requests fairly or estimate their impact.

A template does three things. It standardizes intake so requests arrive with the same structure every time. It captures context — who wants this, why they want it, what they do today instead — that you need to prioritize intelligently. And it makes the process repeatable so your team spends less time chasing clarification and more time building.

Templates also set expectations. When users see a structured form, they understand that you take requests seriously and have a process for evaluating them. That builds trust, even when you say no.

![Feature request form fields: what, why, current workaround, and priority](/blog/feature-request-template/request-form-fields.webp)

## Simple feature request template

Use this for lightweight intake — a shared doc, a Notion page, or a basic form. It covers the minimum you need to evaluate a request without overwhelming the submitter.

```markdown
## Feature Request

**Title:** [Short, descriptive name for the feature]

**Submitted by:** [Name, role, or team]

**Date:** [YYYY-MM-DD]

**Description:**
What do you want the product to do? Describe the feature in one to three sentences.

**Use case:**
When would you use this? Walk through the specific situation that prompted this request.

**Priority:**
[ ] Nice to have
[ ] Would significantly improve my workflow
[ ] Blocking me from using the product effectively

**Additional context:**
Links, screenshots, or examples from other products (optional).
```

This template works well for small teams where requests come from a handful of internal stakeholders. It keeps things fast — most people can fill it out in two minutes. As your team grows and request volume increases, you will want more detail.

## Detailed feature request template

When you need to prioritize across a large backlog, the simple template is not enough. This version adds the business context that makes prioritization frameworks like [RICE](/blog/rice-framework-explained) and ICE work.

```markdown
## Feature Request

**Title:** [Short, descriptive name for the feature]

**Submitted by:** [Name, role, or team]

**Date:** [YYYY-MM-DD]

**Description:**
What do you want the product to do? Be specific about the behavior, not the implementation.

**Use case:**
Describe the specific situation that prompted this request. Include the job to be done.

**Number of affected users:**
How many users does this affect? Include data if you have it (e.g., support ticket volume, survey responses, sales call mentions).

**Business impact:**
What happens if this is not built? Does it affect retention, expansion, or acquisition?
[ ] Reduces churn risk
[ ] Enables upsell or expansion
[ ] Unblocks sales deals
[ ] Improves user satisfaction
[ ] Other: ___

**Current workaround:**
What do users do today instead? How painful is it?

**Acceptance criteria:**
How would you know this request has been fulfilled? What does "done" look like from the user's perspective?

**Priority:**
[ ] Low — nice to have
[ ] Medium — meaningful improvement
[ ] High — significant impact on retention or revenue
[ ] Critical — blocking users or deals

**Linked feedback:**
Links to support tickets, sales call notes, survey responses, or user interviews that mention this request.
```

The linked feedback field is particularly important. A feature request with five support tickets and three sales call references attached is categorically different from one person's opinion. That evidence is what separates a priority from a wish.

## Internal feature request template

When engineering or product teams are evaluating whether to build something, they need a different set of fields. This template adds technical feasibility and strategic alignment — the questions that determine whether a request makes it onto a roadmap.

```markdown
## Internal Feature Request / Product Spec

**Title:** [Feature name]

**Author:** [Name]

**Date:** [YYYY-MM-DD]

**Status:** [ ] Draft  [ ] Under review  [ ] Approved  [ ] Declined

---

### Problem statement
What problem does this solve? Write this from the user's perspective, not the product's.

### Proposed solution
Describe the feature at a high level. Avoid specifying implementation details unless they are constraints.

### User impact
- Target users:
- Number of affected accounts/users:
- Frequency of use (daily / weekly / occasionally):

### Business case
- Effect on retention:
- Effect on acquisition or sales:
- Revenue impact (if quantifiable):

### Strategic alignment
How does this map to current product priorities? Reference the relevant goal or OKR if applicable.

### Technical feasibility
- Estimated effort: [ ] Small (< 1 week)  [ ] Medium (1–4 weeks)  [ ] Large (1–3 months)  [ ] XL (3+ months)
- Dependencies or blockers:
- Known technical risks:

### Alternatives considered
What other approaches were considered? Why was this solution chosen?

### Success metrics
How will you measure whether this feature achieved its goal after launch?

### Open questions
List anything that needs to be resolved before work begins.
```

The status field matters more than it looks. It lets everyone see at a glance whether a request is being evaluated, approved, or has been declined — and it avoids the situation where a request disappears into a backlog with no visible outcome.

## Customer-facing feature request form

Public-facing forms need to be short. The more questions you ask, the fewer requests you tend to get — most people will not invest more than a minute or two filling out a form for a feature they may never see built.

For a public feedback board or a form embedded in your product, keep it to three fields:

```markdown
## Request a Feature

**Title:**
Give your request a short, clear name. (e.g., "Export data to CSV", "Dark mode", "Slack integration")

**Description:**
Describe what you want and why it would help you. What are you trying to accomplish?

**Category:**
[ ] Integrations
[ ] Reporting and analytics
[ ] Notifications
[ ] UI and usability
[ ] Performance
[ ] Other
```

Do not ask for priority, business impact, or effort estimates on a public form. Users do not have that context, and asking for it signals that you do not understand their role. Let your team assign those fields internally after the request comes in.

What you should not include: email fields that are not pre-filled, open-ended questions about competitors, or any field that requires the user to think about your roadmap rather than their own problem. Keep the form focused on capturing the problem, not solving it.

For a dedicated feedback portal where users can submit requests and vote on existing ones, tools designed for this purpose handle the form automatically. See our comparison of [feature request tools](/blog/best-feature-request-tools) and [feature voting tools](/blog/best-feature-voting-tools) for options.

## Bug vs. feature request

The line between a bug and a feature request matters because they follow different processes. A bug is when the product does not do what it is supposed to do. A feature request is when the product works as designed, but the user wants it to do something more or different.

In practice, users often report bugs as feature requests and vice versa. "I can't export my data" might be a bug if export was supposed to work, or a feature request if export does not exist yet. Your intake process needs to handle the triage.

When you receive a request, ask: did we promise this behavior? If yes and it is broken, it is a bug. If no, it is a feature request. The response process is different — bugs typically go to an engineering queue with severity and urgency fields, while feature requests go through your prioritization process. For a complete bug reporting workflow, see our [bug report template](/blog/bug-report-template).

Some teams use a single intake form with a type field (`[ ] Bug  [ ] Feature request  [ ] Improvement`) to let submitters self-classify, with the understanding that your team will re-categorize if needed.

## How to organize and track requests

A template solves the intake problem. A tracking system solves the organization problem. Without both, requests are still getting lost — they are just arriving in a more consistent format.

**Spreadsheets** are a common starting point. A shared Google Sheet with columns for title, requester, date, status, priority, and impact gives you a searchable list. The problems emerge as volume grows: you cannot let users vote on requests, you cannot show them what is in progress, and you cannot close the feedback loop without manually emailing people. Spreadsheets also do not aggregate duplicates — the tenth person to request the same thing creates a tenth row rather than adding weight to an existing one.

**Dedicated tools** solve these problems. A purpose-built feedback tool lets users submit and upvote requests, automatically surfaces the most-requested items, and lets you communicate status changes to everyone who requested a feature when it ships. That last piece — closing the loop — is where most teams fall down.

[Quackback](/features/feedback) is built for exactly this workflow. Users submit requests through your public feedback board or an embedded [widget](/features/widget), upvote items they care about, and automatically get notified when the status changes. Your team sees requests ranked by votes and linked to the original submitter context. The [voting feature](/features/voting) surfaces demand across your entire user base, not just the users who are loudest in Slack.

Quackback is **open source** (AGPL-3.0), so the whole team can triage requests together. You can run the managed [Quackback Cloud](/pricing) or self-host it for free. AI triage and summarization are built in, and the [MCP server](/features/mcp) lets you query and update feedback directly from tools like Claude. When a request ships, the [changelog](/features/changelog) and [roadmap](/features/roadmap) close the loop with everyone who asked for it.

For a broader look at how to build a feedback process that feeds into your roadmap, see our guide on [building a customer feedback loop](/blog/customer-feedback-loop). If you are weighing alternatives, compare [Quackback vs Canny](/compare/quackback-vs-canny) and [Quackback vs Featurebase](/compare/quackback-vs-featurebase).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How detailed should a feature request template be?

Match the detail to who fills it out. Public-facing forms should stay at three or four fields, since longer forms tend to collect fewer requests. Internal stakeholders can handle a detailed template with business impact and affected-user counts. Use the simplest template that captures what you actually use when prioritizing.

### How do you prioritize feature requests once you have collected them?

Use a scoring framework. [RICE](/blog/rice-framework-explained) (Reach, Impact, Confidence, Effort) forces you to quantify what matters, and vote counts from a feedback board supply the Reach and Impact inputs. MoSCoW works for quick triage. The goal is a repeatable process, not deciding by whoever spoke up most recently.

### Should you respond to every feature request?

Yes, at minimum with a status update. Users who never hear back stop submitting requests. You do not have to build every feature, but acknowledge receipt, give an honest read on likelihood, and follow up on status changes. A dedicated feedback tool makes this practical once manual emails stop scaling.

- [Prioritization Matrix Template: How to Rank Features by Value and Effort](https://quackback.io/blog/prioritization-matrix-template): Free prioritization matrix templates for product teams. Value vs effort, 2x2 matrix, weighted scoring, and how to use feedback data to score features.

Published: 2025-12-12

You have 40 feature requests and capacity to build 5. Every stakeholder has a different top priority. Every item on the list sounds important in isolation. Without a structured approach, you either default to gut feel or you default to whoever pushes hardest.

A prioritization matrix turns that list into a defensible plan. It forces you to compare features on the same dimensions — value and effort being the most common — so that the ranking reflects trade-offs rather than opinions.

![Prioritization matrix with value vs effort quadrants](/blog/prioritization-matrix-template/hero.webp)

> A **prioritization matrix** ranks features by scoring them on shared dimensions — most often value and effort — so you compare trade-offs instead of opinions. Use a simple 2x2 quadrant (Quick Wins, Major Projects, Fill-Ins, Avoid) for fast triage, or a weighted scoring model when many features cluster together. Feed it real feedback data — vote counts, comment sentiment, and customer segment — so the scores reflect evidence, not gut feel.

## What is a prioritization matrix?

A prioritization matrix is a visual framework for comparing features across two or more dimensions. The most common dimensions are value (what you gain) and effort (what it costs). You score each feature on those dimensions, plot or sort the results, and use the output to decide what to build next.

The matrix doesn't make decisions for you. It surfaces trade-offs that are easy to miss when you're evaluating features one at a time. A feature that seems essential in isolation might look like poor value when you see it next to three alternatives that deliver comparable benefit at a fraction of the effort.

Prioritization matrices range from simple (a 2x2 quadrant diagram) to rigorous (a weighted scoring model with five or more criteria). The right level of complexity depends on your team's maturity and how much is at stake. Start simple. Add dimensions when the simpler version stops giving you the resolution you need.

## The 2x2 value vs effort matrix

The 2x2 matrix is the simplest form. You assess each feature on two dimensions — value and effort — and place it in one of four quadrants. The quadrant tells you what to do with it.

![2x2 prioritization matrix with Impact vs Effort axes](/blog/prioritization-matrix-template/2x2-matrix.webp)

**Quick Wins** (high value, low effort): Do these first. The return on investment is highest here. These are the features where the gain significantly outweighs the cost.

**Major Projects** (high value, high effort): Plan carefully. These are worth doing, but they require scoping, sequencing, and resource allocation. Don't let them crowd out Quick Wins in the short term.

**Fill-Ins** (low value, low effort): Do these if you have capacity. They are harmless and marginally useful, but they shouldn't take priority over Quick Wins or well-planned Major Projects.

**Avoid** (low value, high effort): Say no. These features cost a lot and return little. Explicitly putting them in the Avoid quadrant is more useful than leaving them in an ambiguous backlog.

### 2x2 matrix template

Use this table as a starting point. Rate each feature High or Low on each dimension, assign the quadrant, and record your evidence.

| Feature | Value | Effort | Quadrant | Next action | Evidence |
|---|---|---|---|---|---|
| Feature name | High / Low | High / Low | Quick Win / Major Project / Fill-In / Avoid | Do now / Plan / Defer / Cut | Vote count, interviews, data |

The Evidence column is the one most teams skip. Fill it in. When you revisit the matrix in three months, you need to know why you rated something High Value — not just that you did.

## Weighted scoring matrix

When the 2x2 isn't giving you enough resolution — for example, when most of your features land in the same quadrant — a weighted scoring matrix adds more structure. You evaluate each feature across multiple criteria, weight each criterion by its importance to your product strategy, score features 1–5 on each, and sum the results.

A typical set of criteria includes:

- **Value**: How much does this improve the experience for users who receive it?
- **Reach**: How many users does this affect?
- **Strategic alignment**: How well does this support your current product goals?
- **Confidence**: How certain are you about the value and reach estimates?
- **Effort**: How much engineering, design, and QA time does this require? (Lower effort = higher score, so invert this dimension.)

Weights reflect your priorities. A startup focused on acquisition might weight Reach heavily. A product optimizing retention might weight Value to existing users more. There is no universal weighting — set weights that reflect what your team is actually trying to accomplish right now.

### Weighted scoring matrix template

Assign weights that sum to 100. Score each feature 1–5 on each criterion. Multiply score by weight, sum the results.

| Feature | Value (×25) | Reach (×20) | Strategic Fit (×20) | Confidence (×20) | Effort score (×15) | Total |
|---|---|---|---|---|---|---|
| Feature A | 4 → 100 | 3 → 60 | 5 → 100 | 4 → 80 | 3 → 45 | 385 |
| Feature B | 2 → 50 | 5 → 100 | 3 → 60 | 2 → 40 | 4 → 60 | 310 |
| Feature C | 5 → 125 | 2 → 40 | 4 → 80 | 5 → 100 | 2 → 30 | 375 |

In the Effort column, a score of 5 means very low effort (fast to build), and a score of 1 means very high effort (slow and expensive). Invert the scale so that low effort contributes positively to the total.

The output is a ranked list. Features A and C are close — that's a signal to discuss, not to blindly follow the number. The framework gets you to the right conversation, not past it.

## How to estimate value

Value is the hardest dimension to score reliably. The most common mistake is conflating "this sounds important" with "this will move a metric we care about." Use concrete inputs wherever you can.

**Feedback data** is the most direct signal available. When users vote for a feature on your [feedback board](/features/feedback), you learn how many people want it and how urgently. Vote counts tell you about reach and demand. User comments tell you what problem the feature would solve and how much friction the current absence creates. A feature with 200 votes and comments like "I can't complete my workflow without this" has stronger evidence for high value than a feature a single enterprise customer mentioned on a call.

**Customer segment** matters for revenue impact. A request from 50 enterprise users on annual contracts may be worth more than 300 requests from free-tier users, depending on your business model. Weight your value score accordingly.

**Strategic alignment** is a distinct input from user value. A feature that supports your current acquisition strategy may be worth prioritizing even if relatively few users have requested it. A feature with 500 votes that doesn't align with your product direction might score lower than it appears at face value.

**Competitive necessity** is a special case. Some features don't create value — they prevent the loss of value. If a competitor ships something your users expect you to have, the cost of not building it is customer churn, not missed growth. These belong in the matrix with that framing explicit.

## How to estimate effort

Effort should reflect total work, not just engineering time. The most consistent mistake teams make is scoping only the backend implementation. A complete effort estimate includes design, frontend, QA, documentation, and any launch or migration work.

Express effort in person-weeks or person-months and keep the unit consistent across all features. One engineer for two weeks is 0.5 person-months. Two engineers, one designer, and a QA pass over four weeks is approximately 3.5 person-months. If your team uses story points, you can use those — but make sure the scale is calibrated and agreed on by the team.

Get estimates from the people who will do the work. PMs consistently underestimate effort, especially for features they are excited about. Engineering estimates are more accurate when the spec is clear, so don't ask for an estimate before the feature is defined well enough to understand scope.

Flag uncertainty. An effort estimate with low confidence should be noted. "2 person-months, but we haven't scoped the data migration" is more useful than "2 person-months" when that assumption may be wrong.

## Prioritization matrix template

This template combines the key columns from both the 2x2 and weighted scoring approaches. Use it as a starting point and adapt it to your team's criteria and weights.

| Feature | Value (1–5) | Effort (1–5) | Score | Quadrant | Evidence |
|---|---|---|---|---|---|
| Slack integration for notifications | 4 | 2 | 8 | Quick Win | 187 votes; mentioned in 12 support tickets |
| Onboarding checklist for new users | 5 | 3 | 8 | Quick Win | Retention data shows 3x improvement with guided setup |
| Advanced analytics dashboard | 3 | 5 | 6 | Major Project | Requested by 6 enterprise accounts; no vote data |
| CSV export for reports | 4 | 1 | 9 | Quick Win | 241 votes; users currently copy-pasting manually |
| Custom domain support | 3 | 4 | 7 | Major Project | 94 votes; required by 3 enterprise prospects |
| Dark mode | 2 | 2 | 4 | Fill-In | 45 votes; cosmetic preference, no workflow impact |
| AI-generated summaries | 2 | 5 | 4 | Avoid | Speculative; no user evidence; low confidence |
| Status page / public changelog | 3 | 2 | 6 | Quick Win | 112 votes; reduces "what's new?" support load |

In the Score column above, the numbers reflect a simple value minus effort calculation for illustration. In practice, use your actual scoring formula — either the weighted matrix or a custom formula your team agrees on. What matters is that every feature uses the same formula so the comparison is valid.

## Using feedback data to fill the matrix

The matrix is a framework. Feedback data is the input. Without real data, you are assigning scores based on opinion and recency bias. With it, you are scoring based on evidence.

**Vote counts** inform your Reach and Confidence scores. A feature with 200 votes has demonstrated demand. A feature with 5 votes has not. When you see low confidence scores on features with high internal enthusiasm and low external evidence, that is useful information — it means the team's assumptions haven't been validated.

**Comment sentiment** informs your Value score. Browse the comments on your highest-voted features and look for patterns. Are users describing blocked workflows, or are they describing preferences? "I have to export to Excel and reformat everything manually every week" is a different level of value than "it would be nice if the colors matched our brand." Comments give you the qualitative context that vote counts alone cannot.

**Customer segment** is often surfaced by who is voting. If your top requested feature is coming primarily from enterprise accounts, the revenue impact is different than if the same votes came from free users. Understanding who is asking, not just how many, sharpens your value estimates.

**Request frequency over time** tells you about urgency. A feature that has received 10–15 new votes every week for six months has sustained demand. A feature that received 100 votes in a spike and then went quiet may be less urgent than the raw count suggests.

A feedback tool that captures all four signals in one place removes most of the manual collection work. [Quackback](/features/feedback) surfaces vote counts, comment threads, and customer segment data on every request, and its [voting board](/features/voting) keeps the demand signal current. Because Quackback is open source, you can give every PM, engineer, and sales lead access to the same evidence. Its [MCP server](/features/mcp) also lets you query that feedback data from an AI assistant — useful when you want to summarize the top requests in a segment before a scoring session, without copying anything into a spreadsheet.

For more on how to turn feedback into prioritization inputs, see [how the RICE framework uses the same data](/blog/rice-framework-explained) and [how MoSCoW uses feedback to scope releases](/blog/moscow-prioritization). The matrix approach described here is complementary to both.

## Other prioritization frameworks

The value vs effort matrix is the simplest starting point, but it is not the only option. Here is a brief comparison of the frameworks most product teams reach for.

| Framework | Output | Best for | Main limitation |
|---|---|---|---|
| Value/Effort matrix | Quadrant placement | Visual triage, team alignment | Oversimplifies when many features cluster in one quadrant |
| [RICE](/blog/rice-framework-explained) | Numeric score | Comparing features objectively | Requires reliable data for Reach, Impact, and Confidence |
| [MoSCoW](/blog/moscow-prioritization) | Category buckets | Scoping releases with stakeholders | No ranking within a category |
| ICE | Numeric score | Fast lightweight scoring | No Reach component; less rigorous than RICE |
| Kano model | Satisfaction categories | Discovery and strategic thinking | Requires user research; no build order |
| Weighted scoring | Ranked list | When criteria importance varies | Setup overhead; weights can hide assumptions |

Use the 2x2 matrix when you need a fast, visual way to triage a large backlog. Move to weighted scoring when the matrix doesn't give you enough resolution. Use [RICE](/blog/rice-framework-explained) when you need a defensible numeric ranking across your entire backlog. Use [MoSCoW](/blog/moscow-prioritization) when you are scoping a specific release with stakeholders who need to align on what is in and what is out.

These frameworks are not mutually exclusive. Many teams use MoSCoW to define scope, the value/effort matrix for a quick first pass, and RICE to sequence the final build order. The combination reduces the weaknesses of any single method.

For a broader comparison of tools that support these workflows, see [best feature request tools](/blog/best-feature-request-tools) and [best feature voting tools](/blog/best-feature-voting-tools). If you are evaluating specific platforms, [Quackback vs Canny](/compare/quackback-vs-canny) and [Quackback vs Featurebase](/compare/quackback-vs-featurebase) break down how the boards differ, and the [docs](/docs) cover scoring fields and exports in detail.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How is a prioritization matrix different from a RICE score?

A prioritization matrix is a visual or tabular framework that positions features relative to each other on two or more dimensions. RICE is a specific scoring formula — (Reach × Impact × Confidence) / Effort — that produces a single number for each feature. The matrix is broader and more flexible. RICE is more precise and formula-driven. Many teams use both: a matrix for a quick visual overview and RICE for a detailed numeric ranking when the stakes are higher.

### How do you handle features that score the same?

When two features score identically or very close, the matrix has done most of its job — it has narrowed the decision to a genuine tie. Break the tie by looking at factors outside the scoring model: which feature has clearer scope, which one unblocks other work, which customer segment is asking for it, or which aligns better with your current product focus. A tie in the matrix means both are worth doing; the secondary question is sequencing, not selection.

### Should you involve stakeholders in scoring?

Yes. Scoring as a group surfaces disagreements that would otherwise become scope conflicts later. A gap between a PM's and an engineer's effort score usually reveals an unstated scope assumption. Keep the group small — five to eight people — with a facilitator to move the discussion forward.

### How often should you update the matrix?

Update it at the start of each planning cycle, typically quarterly. Between cycles, revise individual scores when significant new data arrives: a spike in feature votes, new user research findings, a change in team capacity, or a strategic pivot that shifts what "high value" means. Avoid the temptation to re-score weekly — the overhead erodes the framework's value. The matrix is most useful as a stable reference point within a planning horizon, not as a real-time dashboard.

- [Release Notes Template: Free Templates, Examples, and Best Practices](https://quackback.io/blog/release-notes-template): Free release notes templates for product, software, and internal teams. Includes real examples from top SaaS companies and best practices for writing release notes.

Published: 2025-12-09

Your users want to know what changed. Release notes tell them. Most teams write them badly, inconsistently, or not at all — which means users discover new features by accident, ask support about things that already shipped, and don't realize the product is improving.

Good release notes are not documentation. They are a communication layer between your team and your users every time you ship something. They build trust, reduce confusion, and close the loop with users who have been waiting for a fix or feature.

![Release notes template with sections for features, improvements, and fixes](/blog/release-notes-template/hero.webp)

> A **release notes template** is a reusable structure for communicating what changed in each product release. A good one groups updates into clear sections — new features, improvements, bug fixes, and known issues — so users can scan for what affects them. Lead with what users can now do, write in plain language, and link to documentation for detail.

This guide gives you four copy-pasteable templates — general, software, product, and internal — plus examples from companies that do it well and a set of practices that separate useful release notes from noise.

## What are release notes

Release notes are a structured summary of what changed in a product, service, or software system between one version and the next. They describe new features, bug fixes, improvements, and anything that might affect how users or developers work with the product.

They sit at the intersection of product and communication. A developer might write release notes for an API — detailing endpoint changes, breaking changes, and migration steps. A product manager might write them for customers — describing what users can now do and why it matters. Both are release notes. The audience and format differ, but the purpose is the same: tell people what changed and what they need to know.

Release notes also serve as a historical record. A well-maintained changelog tells the story of a product over time. New users can see how the product evolved. Existing users can trace when a behavior changed. Your team can audit what shipped and when.

![Anatomy of a release note: version heading, category badge, feature name, description, and documentation link](/blog/release-notes-template/anatomy-of-release-note.webp)

## General release notes template

This template works across most contexts. Use it as a starting point and cut whatever sections do not apply to your release.

```markdown
## [Version or Release Name] — [Date]

### New features

- **[Feature name]:** [One sentence describing what it is and what users can do with it.]
- **[Feature name]:** [One sentence describing what it is and what users can do with it.]

### Improvements

- [What changed and why it's better. Be specific — "faster" means nothing, "reduced load time from 4s to 800ms" does.]
- [What changed and why it's better.]

### Bug fixes

- Fixed: [What was broken and what it affected.]
- Fixed: [What was broken and what it affected.]

### Known issues

- [Issue description, who it affects, and any workaround.]

### Deprecations

- [What is being deprecated, the timeline, and what to use instead.]

---

[Link to full documentation] | [Link to upgrade guide]
```

Adapt the sections to your release. A small patch might only need "Bug fixes." A major version might use every section. The key is consistency: use the same structure every time so users know where to look.

## Software release notes template

This template is for engineering and developer-facing releases — APIs, SDKs, libraries, and CLIs. It adds technical detail that developers need: breaking changes, migration steps, and dependency requirements.

```markdown
## [Version] — [Date]

### Breaking changes

> These changes require action before upgrading.

- **[Change]:** [What changed, why, and what you need to update in your code.]
  - Before: `[old behavior or code snippet]`
  - After: `[new behavior or code snippet]`

### New features

- **[Feature]:** [What it does and how to use it.] See [docs link].
- **[Feature]:** [What it does and how to use it.] See [docs link].

### API changes

- Added: `[endpoint or method]` — [what it does]
- Changed: `[endpoint or method]` — [what changed and migration notes]
- Removed: `[endpoint or method]` — [use `[replacement]` instead]

### Improvements

- [Performance improvement with measurable details where possible.]
- [Developer experience improvement.]

### Bug fixes

- Fixed `[method or behavior]` returning `[wrong value]` when `[condition]`. ([Issue #123])
- Fixed memory leak in `[component]` under `[condition]`.

### Dependencies

- Updated `[dependency]` from `[old version]` to `[new version]`
- Dropped support for `[runtime/OS/version]`

### Migration guide

[Step-by-step instructions for upgrading from the previous version. Include code examples for any breaking changes.]

---

**Minimum requirements:** [Node 20+, Python 3.11+, etc.]
[Full changelog on GitHub] | [Migration docs]
```

For libraries and SDKs, lead with breaking changes at the top. Developers scan release notes before upgrading. If they miss a breaking change, it costs them hours of debugging. Make it impossible to overlook.

## Product release notes template

This template is for customer-facing release notes — what goes on your changelog page, in your in-app widget, or in your email announcement. It leads with benefits, not technical details. Users care about what they can now do, not how you built it.

```markdown
## [Release name or short summary] — [Date]

[One or two sentence summary of the release. What shipped and why it matters to users.]

### What's new

**[Feature name]**
[What users can now do. Lead with the outcome. "You can now export your data as CSV" not "We added CSV export."]

[Screenshot or GIF placeholder: show the feature in context]

**[Feature name]**
[What users can now do.]

### What's better

- [Improvement written from the user's perspective. What felt slow or broken that now works better.]
- [Improvement.]

### What's fixed

- [Bug fix written plainly. "Reports now load correctly when filtered by date range." Not "Fixed null pointer exception in report filter."]
- [Bug fix.]

---

[Link to full documentation] | [Give feedback on this release]
```

The screenshot placeholder matters. A single image of the new feature in context communicates more than three paragraphs of description. If you have design or marketing resources, make screenshots a non-negotiable part of your release notes workflow.

## Internal release notes template

Internal release notes are for stakeholders, not users. Leadership, sales, customer success, and support need to know what shipped, why, and what it means for their work. This template adds context that would not belong in a public changelog.

```markdown
## [Release name] — [Date]

**Owner:** [Team or individual responsible]
**Status:** Shipped to [percentage or cohort] of users

### What shipped

[Plain description of what went out. Link to the public changelog entry if applicable.]

### Why it shipped

[The business or customer context. What problem does this solve? Which feedback, support tickets, or metrics drove the decision to build this?]

### Who it affects

- **Customers:** [Which segments, plans, or regions see this change.]
- **Sales:** [Anything sales needs to know — new capabilities to pitch, pricing implications, objections this resolves.]
- **Support:** [Known issues, expected support volume, FAQ answers for common questions.]

### Metrics and rollout

- **Rollout:** [How it was deployed — full release, feature flag, gradual rollout by cohort.]
- **Success metrics:** [What you're watching. Activation rate, error rate, support ticket volume, etc.]
- **Rollback plan:** [How to revert if something goes wrong.]

### Links

- [Public changelog entry]
- [Design specs or Figma]
- [Engineering PR or deployment]
- [Support documentation]
```

Internal release notes are often skipped entirely. Teams ship, notify Slack, and move on. The problem is that institutional context disappears. Six months later, nobody remembers why a decision was made. A lightweight internal note captures that context in a findable place.

## Release notes examples

These companies have developed recognizable, consistent approaches to release notes. Studying what works helps you build a style that fits your team.

### Linear

Linear's changelog is tightly written and visually polished. Each entry opens with a short, declarative headline — "Issue templates," "Slack notifications," "Command menu improvements" — and expands into one or two paragraphs that explain the feature and the design thinking behind it. They include high-quality product screenshots for every significant feature. The tone is confident and direct, never marketing-inflected. What makes it effective: the writing matches the product's design sensibility. Users trust it because it reads like it was written by someone who understands how the product is used, not by a marketing team.

### Stripe

Stripe's release notes are organized by product area — Payments, Connect, Radar, Billing — and written primarily for developers. Every API change is documented with exact endpoint names, parameter changes, and migration notes. Breaking changes are flagged at the top. The tone is technical and precise. What makes it effective: Stripe's users are engineers who need to know exactly what changed so they can update their integrations. The notes give them exactly that, nothing more.

### Notion

Notion publishes release notes in-app and on a public changelog. Their format uses a simple two-column layout: feature name on the left, description on the right. Entries are brief — usually two or three sentences — with links to documentation for more detail. They rarely explain why a feature was built; they focus on what users can now do. What makes it effective: the brevity respects the user's time. Users scan the list, find what's relevant to them, and click through if they want to learn more.

### Vercel

Vercel's changelog is also a marketing channel. Entries are longer, include video walkthroughs for major features, and often include technical depth for developers alongside product-level summaries. They distinguish between "Changelog" (product updates) and "AI News" (model and AI-related releases). What makes it effective: the entries are genuinely informative. The technical depth gives developers confidence, and the video format makes complex features accessible. They commit the resources to do it well.

### GitHub

GitHub publishes a detailed monthly changelog digest alongside individual release notes. The monthly format lets them group smaller updates that wouldn't warrant standalone posts. Individual entries for significant features include screenshots, code examples, and links to documentation. They also tag entries by feature area — Actions, Copilot, Security, etc. — so users can filter for what's relevant. What makes it effective: the tagging and filtering. GitHub has a huge surface area. Helping users navigate to the updates that matter to their workflow is as important as the writing itself.

### Figma

Figma's release notes lean into the visual nature of the product. Every significant feature ships with a polished demo GIF or short video embedded directly in the entry. The writing is short — often a single paragraph — because the visual does most of the work. They also have a dedicated "What's new" panel in the product itself, surfacing the most recent updates inline. What makes it effective: showing, not telling. For a design tool, a three-second GIF of a new feature communicates more than any written description.

## Release notes best practices

### Lead with what users can do, not what you built

"You can now filter reports by date range" is more useful than "We added date range filtering to the reports module." The first tells users what's possible for them. The second tells them what you did. Write from the user's perspective.

### Use plain language

Avoid internal jargon, ticket numbers, and implementation details in customer-facing notes. "Fixed a race condition in the WebSocket handler" means nothing to a non-technical user. "Fixed a bug that caused messages to sometimes appear out of order" tells them what was broken and what's better.

### Be specific about improvements

Vague claims undermine credibility. "Improved performance" tells users nothing. "Reduced dashboard load time by 60% for accounts with more than 10,000 records" tells them what changed and whether it affects them.

### Include visuals for significant features

A screenshot or GIF answers the question "what does this look like?" before users have to open the product. For customer-facing notes, treat visuals as required for any new feature, not optional.

### Link to documentation

Release notes are not documentation. For anything complex, include a link to the relevant docs. Users who want to go deep can follow the link; users who just want to know what changed have what they need in the note itself.

### Separate audience-specific notes

A developer and a business user reading the same changelog have different needs. If your product spans technical and non-technical users, consider separate sections or separate channels — public changelog for users, API changelog for developers, internal notes for your team.

### Maintain a consistent cadence

Release notes published at random intervals signal that the product is moving unpredictably. A regular cadence — weekly, bi-weekly, or tied to sprint cycles — builds the expectation that updates will come and are worth reading. Users who know to expect updates will check for them.

### Connect release notes to the feedback that drove the work

When a feature ships because users asked for it, say so. "This was one of your most-requested features" acknowledges the feedback. Even better: notify the users who specifically requested it. Closing that loop turns feedback contributors into advocates. This is where a connected [feedback and changelog](/features/feedback) system earns its keep — when your release notes live next to the [voting](/features/voting) and feedback that drove the work, the auto-notify happens without anyone exporting a list.

### Keep an internal draft before the public release

Write a draft before the feature ships, not after. Waiting until a feature is in production adds delay and often means release notes are rushed. A draft written during development gives you time to review, improve, and coordinate the announcement with other teams.

### Use a changelog tool instead of manual docs

A Google Doc, Notion page, or GitHub wiki works until it doesn't. Dedicated [changelog tools](/blog/best-changelog-tools) give you a structured editor, in-app widget delivery, email subscriptions, RSS feeds, and analytics. The overhead of maintaining a manual changelog compounds over time. A tool reduces it. If you would rather not hand your release history to a closed platform, [Quackback's changelog](/features/changelog) is open source (AGPL-3.0) and self-hostable, so you keep ownership of the data.

## How to distribute release notes

Writing good release notes is half the work. Getting them in front of the right users is the other half. Here are the main distribution channels and when to use each.

**Changelog page.** A public URL that lists all your releases in reverse chronological order. It is the canonical source of truth for what has shipped. Every other channel should link back to it. The limitation: users have to seek it out. It doesn't reach users who aren't already looking.

**In-app widget.** A small notification or badge inside your product that surfaces recent updates. It reaches users while they're actively using the product, which is when new feature announcements are most relevant. The limitation: users can dismiss or ignore it, and it works best for short, scannable entries rather than detailed notes.

**Email.** Email works well for significant releases or monthly roundups. It reaches users who aren't currently active in the product and allows longer-form content with images. The limitation: open rates vary, and a high email cadence leads to unsubscribes. Reserve email for releases that genuinely warrant attention.

**Slack or team messaging.** Posting to a shared Slack channel works well for internal teams and developer communities. It is fast and conversational. The limitation: Slack is ephemeral. Messages get buried. It is a notification channel, not a record.

**Social.** Twitter, LinkedIn, and developer communities like Hacker News or Product Hunt work well for major releases. They can reach new audiences beyond your existing user base. The limitation: the audience is cold. Social announcements work better for product milestones than routine releases.

[Quackback's changelog](/features/changelog) handles the page, widget, and email channels from one place. When you publish a release, it automatically notifies users who voted or commented on the relevant feedback posts — no manual list management required. The [customer feedback loop](/blog/customer-feedback-loop) closes automatically. Quackback is open source (AGPL-3.0) and self-hostable, and the [MCP server](/features/mcp) lets you draft release notes from feedback inside your AI tools. See the [best changelog tools](/blog/best-changelog-tools) comparison for a full breakdown of the alternatives, or read how Quackback stacks up against [Canny](/compare/quackback-vs-canny) and [Featurebase](/compare/quackback-vs-featurebase).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is the difference between release notes and a changelog?

Release notes and changelog are often used interchangeably. In practice, release notes tend to refer to the document published with a specific version or release, while a changelog is the ongoing, cumulative record of all releases. A changelog is made up of individual release notes entries. Both serve the same purpose: communicating what changed and when.

### How long should release notes be?

As short as the release allows. A minor patch might be two or three bullet points; a major release might run several paragraphs with screenshots. There is no fixed length, but shorter is better. If a routine release runs past 400-500 words, the extra detail belongs in documentation.

### How often should you publish release notes?

Publish whenever you ship something meaningful to users — for most teams, at least every two weeks, tied to sprint or release cycles. If you ship continuously, batch updates into a weekly or bi-weekly digest. Aim for a cadence users can predict, since irregular notes signal an unpredictable product.

- [Free Product Roadmap Templates for 2026 (5 Formats)](https://quackback.io/blog/roadmap-template): Free product roadmap templates in five formats: now/next/later, timeline, theme-based, outcome-based, and kanban. Download and customize for your team.

Published: 2025-12-05

A roadmap template gives you structure without forcing you into a specific tool. You can start with a markdown table or a spreadsheet, run planning cycles with your team, and upgrade to dedicated software only when you have a clear reason to. Most teams move faster by starting simple.

This post covers five roadmap formats, each with a copy-pasteable template. Pick the one that fits your current situation, customize the columns, and start planning.

![Five product roadmap template formats](/blog/roadmap-template/hero.webp)

## How to choose a roadmap format

No format is universally correct. The right one depends on three factors: who reads it, how much flexibility you need, and how far out you're planning.

**Audience.** Executives want to see priorities and timelines. Engineers need enough detail to estimate and sequence work. Customers need clarity on what's coming without seeing your internal deliberation. A format that works for weekly standups often fails in a board meeting.

**Flexibility.** If your priorities shift every few weeks, a quarterly timeline will feel outdated almost immediately. The now/next/later format handles uncertainty better because it doesn't commit to specific dates. If your org runs on quarterly planning cycles, a timeline format is easier to defend to stakeholders.

**Planning horizon.** Longer horizons reward theme-based or outcome-based formats because they don't lock you into specific features you can't yet define. Shorter horizons — the next six to twelve weeks — suit kanban or now/next/later.

For a deeper breakdown of roadmap types and how to choose between them, see [what is a product roadmap](/blog/what-is-a-product-roadmap).

![Now/Next/Later roadmap with three columns showing prioritized features and vote counts](/blog/roadmap-template/now-next-later-columns.webp)

## Template 1: Now / Next / Later

The now/next/later format organizes your roadmap into three time buckets rather than calendar dates. "Now" is what your team is actively building. "Next" is what you'll tackle after current work ships. "Later" is everything else that's on your radar but not yet committed.

This format is well-suited to early-stage products, fast-moving teams, and situations where stakeholders understand that priorities can change. It's honest about uncertainty without abandoning structure.

The "Evidence/Votes" column is worth including from the start. It forces you to connect each item to actual user demand — a number from your feedback board, a count of support tickets, or a note linking to user research. Without it, roadmaps tend to drift toward internal pet projects.

```
| Theme         | Item                      | Status      | Evidence/Votes |
|---------------|---------------------------|-------------|----------------|
| Onboarding    | Interactive setup guide   | Now         | 84 votes       |
| Core product  | CSV export                | Now         | 61 votes       |
| Integrations  | Slack notifications       | Next        | 47 votes       |
| Core product  | Bulk edit                 | Next        | 33 votes       |
| Developer     | Public API v2             | Later       | 29 votes       |
| Growth        | Referral program          | Later       | 18 votes       |
```

Copy this table into your internal wiki, Notion, or a Google Doc. Update the Status column each planning cycle. Archive items when they ship rather than deleting them — you'll want the history when you look back at what drove decisions.

For teams using agile sprints, this format pairs naturally with sprint planning. See the [agile roadmap guide](/blog/agile-roadmap) for how to connect sprint cadences to the now/next/later buckets.

## Template 2: Timeline (Quarterly)

The quarterly timeline maps your roadmap to calendar quarters. Each row is an initiative; each column is a quarter. Status indicators show where each item stands.

This format is the standard for cross-functional planning and executive reporting. It answers the question stakeholders most often ask: "when is this shipping?" It works best when your team has a reasonably stable planning horizon and when you need to coordinate work across multiple teams or functions.

The tradeoff is rigidity. Quarterly commitments are easy to make and hard to keep when priorities shift. Use this format when the dates actually mean something — not as aspirational targets, but as coordinated commitments your engineering team has bought into.

```
| Initiative              | Q1 2026    | Q2 2026    | Q3 2026    | Q4 2026    |
|-------------------------|------------|------------|------------|------------|
| SSO / SAML              | In Progress| Done       | —          | —          |
| Mobile app (iOS)        | —          | In Progress| Shipping   | —          |
| API v2                  | Planned    | In Progress| Done       | —          |
| Data export center      | —          | Planned    | In Progress| Done       |
| Audit log               | —          | —          | Planned    | In Progress|
| Multi-workspace support | —          | —          | —          | Planned    |
```

For status indicators, keep it simple: Planned, In Progress, Shipping (imminent), Done. Avoid custom statuses that require explanation. The more a stakeholder has to ask what a status means, the less useful the roadmap becomes.

## Template 3: Theme-Based

A theme-based roadmap groups initiatives under strategic themes rather than individual features. The themes represent the areas of the product you're investing in — Retention, Growth, Platform, Developer Experience — and the initiatives underneath each theme are the concrete bets you're making to move those areas forward.

This format is best for communicating strategy. When a CEO or investor asks how you're thinking about the next year, a list of features tells them almost nothing. A set of four themes with clear goals and supporting initiatives tells them how you're thinking about the business.

It also keeps your team anchored to outcomes during planning. If an initiative doesn't fit any theme, that's a signal to either define a new theme or cut the initiative.

```
| Theme              | Initiatives                          | Status      | Goal                         |
|--------------------|--------------------------------------|-------------|------------------------------|
| Retention          | In-app onboarding checklist          | In Progress | Reduce 30-day churn by 15%   |
| Retention          | Automated health score alerts        | Planned     | Reduce 30-day churn by 15%   |
| Growth             | Referral program                     | Planned     | Add 200 signups/month        |
| Growth             | Public roadmap (customer-facing)     | In Progress | Add 200 signups/month        |
| Platform           | Multi-workspace support              | Planned     | Support enterprise accounts  |
| Platform           | Role-based access control            | In Progress | Support enterprise accounts  |
| Developer          | Public API v2                        | In Progress | 3rd-party integrations       |
| Developer          | Webhooks (all events)                | Planned     | 3rd-party integrations       |
```

Review themes at each planning cycle, not just individual initiatives. If a theme has been "Planned" for two quarters with no active work, it's either not a real priority or it's blocked by something that needs to be addressed directly.

## Template 4: Outcome-Based

An outcome-based roadmap organizes work around metrics you want to move, not features you want to ship. Each row is a metric. The initiatives column lists the bets you're making to shift that metric. Status tracks where the work stands.

This format is common on product-led teams that think in terms of activation rates, retention curves, and NPS scores rather than release schedules. It keeps the conversation anchored on impact — not on whether a feature shipped on time, but on whether it moved the number it was supposed to move.

The discipline this format requires is that you have to define the metric before you plan the initiative. If you can't state what you're trying to measure, you're not ready to commit the work to the roadmap.

```
| Metric              | Target          | Initiatives                            | Status      |
|---------------------|-----------------|----------------------------------------|-------------|
| Activation rate     | 60% (from 41%)  | Onboarding checklist, email sequence   | In Progress |
| 30-day retention    | 70% (from 58%)  | In-app health alerts, digest emails    | Planned     |
| NPS                 | 45 (from 31)    | Support SLA improvements, docs refresh | In Progress |
| Time-to-value       | < 5 min         | Setup wizard, sample data              | Planned     |
| Expansion revenue   | +25% NRR        | Usage-based upsell prompts, seat mgmt  | Planned     |
| API adoption        | 40% of accounts | API v2, better auth flow, SDKs         | In Progress |
```

When a quarter ends, review each row: did the metric move? By how much? What worked? This turns the roadmap into a learning artifact, not just a planning document.

## Template 5: Kanban (Status Columns)

A kanban roadmap organizes items by their current status: Planned, In Progress, Shipped. Each cell in the table represents an item in that state.

This format works well for public roadmaps and for teams that want a simple, transparent view of what's moving. Customers can see at a glance what you're working on and what has recently shipped. You don't need to explain quarter labels or theme hierarchies — the status is self-evident.

The tradeoff is that it doesn't communicate priorities or timelines well. If customers want to know when a specific feature will ship, a kanban roadmap doesn't answer that question. It tells them the current state, not the future date.

```
| Planned                      | In Progress               | Shipped                   |
|------------------------------|---------------------------|---------------------------|
| Audit log                    | SSO / SAML                | Dark mode                 |
| Multi-workspace support      | API v2                    | CSV export                |
| Referral program             | Mobile app (iOS)          | Email digests             |
| Custom domains               | Onboarding checklist      | Slack integration         |
| GDPR data export             | Public roadmap            | Two-factor authentication |
```

For a public roadmap, filter this view before sharing it. You don't want internal experiments or speculative items visible to customers. Keep only items that are actively planned or in progress, and ship to the "Shipped" column promptly when work is done.

## Tips for using roadmap templates

**Update on a fixed cadence.** A weekly 15-minute update is enough for most teams. Pick a day — Monday morning works well — and make it a habit. Stale roadmaps breed distrust. When stakeholders check the roadmap and find items that shipped three weeks ago still marked "In Progress," they stop relying on it.

**Archive shipped items rather than deleting them.** Keep a separate sheet or section for archived items. The history matters when you're doing planning retrospectives, writing changelogs, or trying to understand how long work actually takes versus how long you thought it would.

**Link to feedback data.** Every roadmap item should have a source. Add a column or note that links to the feedback thread, support tickets, or user interviews that motivated it. When someone asks why something is on the roadmap, point to evidence. This also helps when you're deprioritizing something — you can explain what you chose over it and why.

**Don't over-detail.** Roadmaps are not specs. A row should be enough to communicate what the initiative is and roughly why it matters. If a cell requires a paragraph of explanation, the roadmap has become a requirements document. Keep descriptions short and link to separate docs for the detail.

**Review at each planning cycle.** At the start of each quarter or sprint cycle, review every row on the roadmap. Cut items that have been "Planned" for more than two cycles without any active work. Promote items from "Later" to "Next" only if you have a realistic plan to resource them. A roadmap that grows without pruning becomes noise.

## When to move to a dedicated tool

Templates work until they don't. Here are the signs you've outgrown a spreadsheet or a markdown table.

**You have more than 50 active items.** Filtering and sorting in a table becomes slow and error-prone. You spend more time maintaining the structure than planning the product.

**Multiple stakeholders need to update it simultaneously.** Shared docs handle concurrent edits poorly for structured data. When three people update the same rows during a planning meeting, you get conflicts and accidental overwrites with no audit trail.

**You want a public roadmap customers can interact with.** A shared Google Sheet is not a good public roadmap. It exposes internal notes, offers no control over visibility, and gives customers no way to vote or comment. A dedicated tool handles the separation between internal and public views.

**You want feedback connected directly to roadmap items.** In a template, the "votes" or "feedback count" column is a number you update by hand. It has no connection to your actual feedback board. When you want user votes, comments, and feature requests to surface automatically alongside roadmap items, a template becomes a bottleneck.

[Quackback's roadmap feature](/features/roadmap) connects your roadmap directly to your feedback board. Vote counts update automatically as users interact with your board. When an item's status changes, subscribers get notified. You can maintain a private internal view and a clean public-facing roadmap from the same data.

For more context on what to look for when you're ready to upgrade, see [best public roadmap tools](/blog/best-public-roadmap-tools) and [product roadmap examples](/blog/product-roadmap-examples).

## Frequently asked questions

### Which roadmap template is best for a small startup?

Now/next/later is usually the right starting point. It doesn't require you to commit to specific dates, which is honest when your team is small and priorities shift frequently. It's also easy to share with investors and early customers without a lot of explanation. Once you have a stable planning cadence and a larger team, you can migrate to a quarterly timeline or theme-based format.

### How is a roadmap template different from a backlog?

A backlog is a full list of everything you might build, organized for engineering to pull from. A roadmap is a strategic view of what you plan to build, why, and roughly when — oriented toward stakeholders and communication. If your roadmap has 200 items, it's functioning as a backlog. Keep the roadmap to the work you've committed to or are actively considering for the near term.

### Can I use these templates for a public roadmap?

The kanban template (Planned / In Progress / Shipped) works best for public-facing use because it's simple and self-explanatory. Before sharing any template publicly, remove internal notes, cut speculative items, and review what you're signaling about unshipped work. If you want customers to be able to vote on items or receive status notifications, a dedicated tool handles that better than a static table.

### How often should I update a roadmap template?

Once a week is enough for most teams. Status changes more frequently than that can make the roadmap feel unstable — stakeholders don't have time to track daily shifts. A Monday morning update that reflects the current state of all active items is a reasonable habit. If a significant change happens mid-week (a feature ships, a priority changes), update it then and notify your team directly rather than expecting them to check on their own.

### What's the difference between theme-based and outcome-based roadmaps?

Theme-based roadmaps organize work by product area or strategic focus: Retention, Growth, Platform. Outcome-based roadmaps organize work by the metric you're trying to move: activation rate, NPS, revenue. Theme-based formats are easier to communicate to mixed audiences. Outcome-based formats are more rigorous and better suited to teams that have established metrics and want to tie planning directly to measurable results. For a broader overview of both approaches, see [product roadmap examples](/blog/product-roadmap-examples) and the [Google Sheets roadmap template](/blog/google-sheets-roadmap-template) for a simpler implementation.

- [Customer Satisfaction Survey Template: Questions and Examples](https://quackback.io/blog/customer-satisfaction-survey-template): Free customer satisfaction survey templates with CSAT questions, scoring formulas, and distribution strategies. Includes CSAT vs NPS comparison.

Published: 2025-12-02

You need to know if users are satisfied. The problem is that most feedback mechanisms are slow, indirect, or noisy. CSAT surveys solve this. One focused question, sent at the right moment, tells you exactly how a user felt about a specific experience — in under five seconds.

The CSAT score is a rate, not a feeling. It is something you can track, segment, and act on. This guide explains how CSAT works, when to use it over NPS or CES, and gives you four copy-pasteable templates for the most common scenarios.

![Customer satisfaction survey template with CSAT scoring](/blog/customer-satisfaction-survey-template/hero.webp)

> A **customer satisfaction survey template** is a reusable set of questions that measures how satisfied a user was with a specific interaction, feature, or experience, scored as CSAT. The core question is "How satisfied are you with [product / support / onboarding]?" on a 1-5 scale, where satisfied responses (4s and 5s) divided by total responses give your CSAT percentage. This guide includes four copy-pasteable templates for support, onboarding, product, and post-purchase surveys, plus timing and analysis guidance.

## What is a CSAT survey

A CSAT (Customer Satisfaction Score) survey asks users how satisfied they were with a specific interaction, feature, or experience. The core question is:

> "How satisfied are you with [product / support interaction / onboarding]?"

Users respond on a 1-5 scale, where 1 is very dissatisfied and 5 is very satisfied. Some teams use a 1-10 scale or even a three-point scale (unhappy, neutral, happy). The 1-5 scale is the most common and benchmarkable.

**The formula:**

> CSAT = (number of satisfied responses / total responses) × 100

Satisfied responses are typically defined as scores of 4 or 5. If 80 out of 100 respondents gave a 4 or 5, your CSAT score is 80%.

CSAT is intentionally narrow. It measures a moment, not a relationship. That specificity is what makes it useful — you know exactly what the score refers to and when the experience happened. A CSAT survey sent immediately after a support ticket closes tells you whether that ticket was resolved well. It does not tell you whether the user will recommend you to a colleague next month. That is a different question.

![Comparison of CSAT, NPS, and CES scales, questions, and use cases](/blog/customer-satisfaction-survey-template/csat-nps-ces-comparison.webp)

## CSAT vs NPS vs CES

These three metrics are often conflated. They measure different things and belong at different points in the user journey.

| Metric | What it measures | Core question | Scale | When to use |
|---|---|---|---|---|
| CSAT | Satisfaction with a specific interaction | "How satisfied were you with...?" | 1-5 | After support, onboarding, feature use, purchase |
| NPS | Overall loyalty and likelihood to recommend | "How likely are you to recommend us?" | 0-10 | Quarterly, post-onboarding, relationship tracking |
| CES | Effort required to complete a task | "How easy was it to...?" | 1-7 | After self-service flows, support, complex tasks |

**Use CSAT** when you need a verdict on a specific touchpoint. Did the support agent resolve the issue? Was onboarding clear? Did the checkout flow work?

**Use NPS** when you want to understand overall loyalty and track it over time. See the [NPS survey template guide](/blog/nps-survey-template) for templates and scoring formulas.

**Use CES** when you suspect friction is the problem. If users are dropping off during a specific workflow, CES tells you whether the effort required is the cause.

Most teams benefit from running all three — but at different times and for different purposes. Running a CSAT survey every month and an NPS survey every quarter gives you both the granular interaction data and the long-run loyalty trend.

## Core CSAT questions

### The primary question

> "How satisfied are you with [your support experience / your onboarding / [Product Name]]?"

Scale: 1 (Very dissatisfied) — 2 (Dissatisfied) — 3 (Neutral) — 4 (Satisfied) — 5 (Very satisfied)

Keep the label on both ends of the scale visible. Users should not have to guess which end is positive.

### Follow-up questions

The primary question gives you the score. Follow-up questions tell you what to do with it. Use one or two follow-ups — not all of them.

**"What was the main reason for your rating?"**
An open text field after the rating. This single question captures the most actionable qualitative signal you will collect. It is especially valuable for low scores (1-3) where the gap between "what went wrong" and "how to fix it" is widest.

**"What could we have done better?"**
Works well after a low or neutral score. It is forward-looking, which makes it easier for users to answer than "what went wrong," which can feel accusatory.

**"Was your issue fully resolved?"** (Yes / No / Partially)
Specific to post-support surveys. The CSAT score tells you whether the interaction felt good. This tells you whether the problem is actually gone.

**"How would you rate the speed of our response?"** (1-5)
Useful if response time is a known pain point or SLA metric. Separates quality of resolution from speed of resolution.

**"How likely are you to contact us again with a question?"** (1-5)
A proxy for confidence. If users are not sure they would reach out again, your support experience may feel unreliable even when the individual ticket resolved well.

**"Which part of the experience could we improve?" (select all that apply)**
A multiple-choice follow-up makes it easy to respond quickly. Offer options like: Speed, Clarity of communication, Technical expertise, Friendliness, Resolution quality. Add an "Other" option with a text field.

**"May we follow up with you about your experience?"** (Yes / No)
If a user gives a 1 or 2 and says yes, that is a direct invitation for a personal conversation. These conversations produce more insight than any survey.

## CSAT survey templates

### Post-support interaction

Send within two hours of a ticket being marked resolved. Response rates drop significantly after 24 hours.

> **Question 1:** "How satisfied were you with the support you received today?" (1-5)
>
> **Question 2:** "Was your issue fully resolved?" (Yes / No / Partially)
>
> **Question 3:** "What could we have done better?" (open text, optional)

Keep this one short. Users have already spent time dealing with a problem. The shorter the survey, the higher the completion rate.

---

### Post-onboarding

Send 3-5 days after a user completes the core onboarding flow. Early enough that the experience is fresh; late enough that they have had a chance to encounter the product on their own.

> **Question 1:** "How satisfied are you with your onboarding experience?" (1-5)
>
> **Question 2:** "Which part of the onboarding experience, if any, could be clearer?" (open text)
>
> **Question 3:** "Did you feel confident using [Product] after completing setup?" (Yes / Somewhat / No)
>
> **Question 4:** "What was most helpful during onboarding?" (open text, optional)

Onboarding CSAT is one of the earliest churn signals available. A score below 70% warrants a direct look at your onboarding flow and, if possible, a follow-up conversation with the lowest-scoring users.

---

### Product experience (after using a feature)

Send after a user has meaningfully engaged with a specific feature — for example, after they export their first report, publish their first update, or complete a key workflow for the first time.

> **Question 1:** "How satisfied are you with [Feature Name]?" (1-5)
>
> **Question 2:** "Did [Feature Name] do what you expected?" (Yes / Mostly / No)
>
> **Question 3:** "What would make [Feature Name] more useful for you?" (open text)

Feature-level CSAT helps you prioritize improvements. If a feature that drives activation has a CSAT below 60%, that is a higher-priority fix than a low score on a rarely-used edge case. Pair this with usage data to understand the relative weight of each feature's satisfaction score.

---

### Post-purchase

Send within an hour of a completed purchase or plan upgrade. The experience of signing up and paying is a distinct step that often creates friction separate from the product itself.

> **Question 1:** "How satisfied were you with the checkout and signup experience?" (1-5)
>
> **Question 2:** "Was there anything that made the process harder than expected?" (open text)
>
> **Question 3:** "How confident do you feel about the plan you chose?" (Very confident / Somewhat confident / Not sure)

Post-purchase CSAT isolates the commercial experience from the product experience. A user can love your product and still have had a frustrating upgrade process. Catching that frustration early gives you a chance to address it before it colors their view of everything else.

---

## When to send CSAT surveys

Timing is as important as the questions themselves. A well-written survey sent at the wrong moment produces low-quality data.

**After support ticket resolution.** Send within two hours of closing the ticket. This is the highest-response-rate moment for post-support CSAT because the experience is immediate.

**After onboarding completion.** Not on day one. Day one is setup friction, not product satisfaction. Send after the user has completed the core flow and had a short time to work independently.

**After key feature milestones.** Trigger a survey the first time a user completes a meaningful action in a feature. This captures genuine first-use impressions without interrupting repeat usage.

**After purchases and plan changes.** Upgrades, downgrades, and new purchases all involve decision-making that users have opinions about. Survey within 60 minutes.

**Avoid stacking surveys.** If a user just completed an NPS survey, hold off on CSAT for at least two weeks. Survey fatigue is real and affects both response rates and the quality of answers. For more on [collecting customer feedback](/blog/collect-customer-feedback) without overwhelming users, including timing and channel strategies, see the full guide.

**Mid-week, mid-morning for email.** If you are distributing via email, Tuesday through Thursday between 9am and 11am local time consistently produces the highest open and response rates. Avoid Mondays and Fridays.

**In-app at natural pause points.** Show the survey after a task is completed, not during one. Interrupting an active workflow produces resentment, not useful data.

## How to analyze CSAT data

### Calculate your score

Apply the formula: (number of 4s and 5s / total responses) × 100. Your score is a percentage, not an average of the raw ratings. This matters because a 3 does not count as "half satisfied" — it counts as not satisfied.

Track this score over time. A weekly or monthly chart tells you whether specific changes — a new support process, an updated onboarding flow, a feature improvement — moved satisfaction in the direction you intended.

### Segment by cohort and context

A single aggregate CSAT score hides meaningful differences. Segment your data by:

- **Survey type** — post-support scores behave differently from post-onboarding scores
- **User plan or tier** — enterprise users may have different expectations and experiences
- **Feature** — if you survey per feature, which features have the lowest scores?
- **Time period** — did scores change after a release or an outage?

Segmentation turns a number into a diagnosis. An aggregate CSAT of 75% tells you little. A CSAT of 75% overall but 52% for users on the free plan tells you something specific to investigate.

### Track trends, not snapshots

A single survey cycle is a snapshot. The value of CSAT comes from consistency over time. Run surveys at regular intervals, use consistent question wording, and keep your scoring formula the same so that month-over-month comparisons are valid.

When a score drops sharply, look for what changed around that time. A score that declines gradually over several months often points to a product quality issue or growing competition. A sudden drop usually has a specific cause — a bad release, a support process failure, a pricing change.

### Combine with qualitative feedback

The score tells you where to look. The open-text responses tell you what you are looking at. Route qualitative CSAT responses into your [feedback board](/features/feedback) alongside feature requests and support insights. When five users with scores of 1 or 2 all describe the same problem, that is a pattern you can act on — not just a number to watch.

[Quackback](/) is built for exactly this. It is open source, so your CSAT comments and the rest of your feedback stay on infrastructure you control. Every support agent and product manager can read and respond to low-score comments. Its [AI clustering](/features/feedback) groups similar responses, and its [MCP server](/features/mcp) lets you query satisfaction themes directly from your assistant. You can [self-host for free](/pricing) or run it on Quackback Cloud.

For more on the difference between measuring at scale and interpreting meaning, see the guide on [qualitative vs quantitative feedback](/blog/qualitative-vs-quantitative-feedback).

## Improving your CSAT score

### Close the feedback loop

Every user who gives a 1 or 2 and leaves a comment should receive a personal reply. Not a form response — a message that references what they said and explains what you are doing about it. This is the highest-leverage action you can take with CSAT data. Users who feel heard often revise their view before you have shipped a single fix.

For users who gave a 3, a brief check-in asking if there is anything you can help with goes a long way. The neutral group is often more recoverable than the dissatisfied group, and they represent a large share of your respondents.

### Act on low scores systematically

Low CSAT scores are signals, not incidents. Build a process around them. When a ticket gets a 1 or 2, who sees that? What happens next? If the answer is "nothing, unless someone checks the dashboard," you are leaving the most actionable data you have untouched.

Route low-score alerts to the relevant team — support lead, product manager, or account manager — within the same business day. The longer the gap between the bad experience and the follow-up, the less likely you are to recover the relationship.

### Follow up with dissatisfied users

Beyond the automated follow-up, invite users who consistently score low to a short conversation. These are your most informative users. They have tried your product, run into something that did not work, and told you about it. That is rare. Treat it as an opportunity, not a complaint to manage.

A 20-minute call with a dissatisfied user will surface more specific, actionable insight than 200 survey responses from satisfied ones. Satisfied users often have vague praise. Dissatisfied users usually know exactly what they want. Building this practice into your [customer feedback loop](/blog/customer-feedback-loop) ensures low CSAT scores consistently produce improvements rather than just reports.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is a good CSAT score?

For most SaaS products, a CSAT score above 75% is generally considered good and above 85% strong, while scores below 60% suggest a persistent problem. Benchmarks vary by industry, so your own historical trend is the most reliable comparison.

*CSAT benchmark ranges are general industry rules of thumb, last reviewed May 2026.*

### How many questions should a CSAT survey have?

Two to three questions is the right target for most contexts. The primary satisfaction question, one open-text follow-up, and optionally one structured follow-up (yes/no or multiple choice). Surveys longer than three questions see a noticeable drop in completion rate. Keep the survey short enough that a user can finish it in under a minute.

### How is CSAT different from NPS?

CSAT measures satisfaction with a specific interaction at a point in time. NPS measures overall loyalty and likelihood to recommend. Use CSAT after discrete interactions like support, onboarding, and purchases. Use NPS to track relationship health over time. See the [NPS survey template](/blog/nps-survey-template) for details.

### How often should I send CSAT surveys?

Send CSAT surveys as close to the relevant event as possible, not on a fixed schedule. Send within two hours of a resolved ticket and within a few days of onboarding. Run periodic product surveys quarterly. Avoid surveying the same user more than once per month across all types combined.

- [50 User Interview Questions for Product Teams (With Templates)](https://quackback.io/blog/user-interview-questions): User interview questions organized by category. Opening questions, problem discovery, feature validation, and a structured interview template.

Published: 2025-11-25

Surveys tell you what. Interviews tell you why. You can see from your analytics that users drop off during onboarding — but only a conversation tells you they couldn't find the import button, or that they didn't understand what the product was for until week two.

Most product teams don't run enough interviews. They're time-intensive, qualitative, and harder to scale than a survey. But no amount of quantitative data fully replaces talking to your users.

![User interview question categories for product teams](/blog/user-interview-questions/hero.webp)

## Why run user interviews

A well-run interview gives you something no dashboard can: context. You learn not just what a user does, but why they do it, what they tried before, and what's still getting in their way. That context turns feature requests from noise into signal.

Interviews complement your quantitative data. Your [feedback board](/features/feedback) tells you which requests have the most votes. An interview tells you the story behind those votes — the actual workflow, the real frustration, the workaround someone built because your product doesn't quite cover it.

They're also the fastest way to catch assumptions before they become shipped features. Thirty minutes with five users will surface more product risk than months of internal debate.

## Before the interview

**Who to recruit.** Start with users who are already engaged. Voters on your feedback board have already expressed a preference — they're primed to have opinions. Support ticket submitters have encountered friction and can speak to it specifically. NPS detractors are uncomfortable to talk to, but they're the most valuable conversations you can have. If you want to understand churn, talk to recently churned users.

**How long.** Keep interviews to 30 minutes. It's enough time to cover meaningful ground without exhausting either party. If a conversation runs longer, let it — but don't schedule more than 30.

**Prepare a guide, not a script.** Write your questions in advance, but treat them as a guide. Good interviews follow the conversation. If a user mentions something unexpected and interesting, pursue it. You can return to your guide after.

**Get consent.** Ask permission to record before you start. Explain that the recording is for your own notes and won't be shared publicly. Most users agree. If they don't, take notes instead. You can use AI tools afterward to transcribe and summarize recordings, which makes synthesis much faster.

![Interview question funnel from broad context to ideal outcome](/blog/user-interview-questions/interview-question-funnel.webp)

## Opening questions

The first few minutes set the tone. Your goal is to build rapport, get the user talking comfortably, and understand who they are before you ask anything specific about your product.

1. **Tell me a little about your role.** Understanding a user's job, team size, and responsibilities gives you context for everything they say afterward. A solo founder and a VP at a 500-person company use the same product very differently.

2. **How did you first hear about us?** This reveals your acquisition channels from the user's perspective and often surfaces word-of-mouth or use cases you didn't anticipate.

3. **How long have you been using the product?** Tenure shapes perspective. A new user's struggles are usually about onboarding. A long-tenured user's complaints are usually about depth and scalability.

4. **What does a typical day at work look like for you?** This broad question surfaces the workflow context your product lives in. You'll hear about adjacent tools, competing priorities, and time constraints that explain user behavior.

5. **What were you using before you found us?** The answer reveals their baseline expectation and what they were willing to tolerate before switching. It also tells you who your real competition is.

6. **What made you decide to try the product in the first place?** This is the job-to-be-done question in disguise. What situation prompted the search? What were they hoping to solve?

7. **Walk me through how you currently use the product.** Let them narrate their workflow unprompted. The gaps between what they describe and what you expected will often be the most useful thing you hear in the entire interview.

## Problem discovery questions

This section gets to the core of what's hard for users, independent of what your product currently does. Resist the urge to jump to solutions. Your job here is to understand the problem deeply.

1. **What's the biggest challenge you face with [problem area] right now?** Open the floor. Don't name specific features — let them describe the problem in their own words.

2. **Can you walk me through the last time that happened?** Specific stories are more reliable than general opinions. A user's account of a recent incident is more accurate than their abstracted summary of a recurring frustration.

3. **How are you solving that problem today?** The current workaround tells you more than the stated problem. A user who built a Zapier workflow around your missing integration is showing you exactly what they need.

4. **What have you already tried?** Users often exhaust several solutions before reaching yours. Understanding what they tried and why it didn't work sharpens your understanding of the problem's constraints.

5. **How often does this come up?** Frequency is a rough proxy for priority. Daily friction is worth more attention than a quarterly edge case.

6. **Who else on your team is affected by this?** Some problems are individual. Others are team-wide. Team-wide problems carry more urgency and often represent larger budget authority.

7. **What does it cost you when this goes wrong?** Quantify the impact where you can. Time lost, deals affected, user frustration communicated to leadership — these details matter when you're prioritizing.

8. **What frustrates you most about how you handle this today?** Frustration is a strong signal. Ask directly, and give users permission to be honest.

9. **If you could change one thing about how this works, what would it be?** This is deliberately open-ended. Don't constrain the answer to your product. You want to hear what they actually want.

10. **If you could wave a magic wand and change anything about this part of your work, what would you change?** The magic wand framing removes the user's implicit filter of "what's realistic to ask for." The unconstrained answer often reveals the most important underlying need.

## Product feedback questions

Now zoom in on your product specifically. These questions surface what's working, what's confusing, and what's close to being right but isn't quite there yet.

1. **What do you like most about the product?** Start positive. You'll hear what's load-bearing — the things you cannot afford to change without breaking something users rely on.

2. **What's the most valuable thing the product does for you?** Different from what they like most. This surfaces utility versus preference. Sometimes what users value most is not what they enjoy most.

3. **What's the most confusing part of the product?** Confusion is often silent. Users figure out workarounds and never report them. Asking directly surfaces friction that doesn't show up in support tickets.

4. **Is there anything that consistently slows you down?** Slow doesn't mean broken. This question catches the workflows that work, but not as well as they should.

5. **Have you ever gotten stuck and not known what to do next?** If yes, ask them to walk you through it. These moments reveal gaps in your onboarding, navigation, and in-product guidance.

6. **What almost made you stop using the product?** This question surfaces near-churn moments. The honest answers here are the most valuable feedback you'll get on retention.

7. **How would you describe the product to a colleague who's never used it?** Their language is your copy. If they use words you don't use, that's a gap between your messaging and their mental model.

8. **Is there anything you expected the product to do that it doesn't?** Expectation gaps are both a product problem and a marketing problem. Some can be closed with features. Others can be closed with better onboarding or messaging.

9. **What would make you recommend this to someone else?** The answer is usually a missing capability or a confidence threshold they haven't crossed yet.

10. **If the product disappeared tomorrow, what would you miss most?** This is the retention version of the value question. The answer tells you what's truly irreplaceable versus what users could live without.

## Feature validation questions

Use these when you want to test a specific idea or direction before committing to it. The goal is to validate the problem the feature solves, not sell the feature itself.

1. **I'd like to describe something we're thinking about building. Can I get your reaction?** Frame it as a thought, not a commitment. You want honest skepticism, not polite enthusiasm.

2. **If we built [feature], how would that change your workflow?** Concrete impact is more useful than a general thumbs up. If they can't describe a change to their workflow, the feature may not solve a real problem.

3. **How would you use this in your current setup?** Adoption is contextual. What sounds useful in the abstract may not fit into how they actually work.

4. **What questions or concerns would you have about this?** Open the door to objections. Users often hold back concerns unless you explicitly invite them.

5. **What's more important to you: [A] or [B]?** Forced trade-offs reveal true priorities better than asking users to rate options. Everyone wants everything — this forces a choice.

6. **Would you pay for this separately if it were an add-on?** Willingness to pay is a harder test than willingness to use. It filters for genuine value.

7. **How much would you expect to pay for this?** Don't offer a number first. Let them anchor. The answer tells you how they perceive the feature's value relative to your existing pricing.

8. **If this existed today, would it have changed your decision to sign up?** This framing helps you understand whether the feature affects acquisition, not just retention.

9. **Are you solving this problem another way right now? Would you give that up?** Switching cost reveals the depth of commitment to the current solution. High switching cost means the new feature needs to be substantially better, not just marginally better.

10. **What would need to be true about this for it to be something you'd use every week?** This question surfaces the conditions under which the feature actually delivers value. The answer often reveals scope gaps or dependencies you hadn't considered.

## Prioritization questions

Use these to understand what matters most to users when they have to choose. These work well near the end of an interview when you've already established the user's workflow and pain points.

1. **If you could only keep three features of the product, which would you keep?** This forces prioritization from the user's perspective. Patterns across interviews reveal your most defensible capabilities.

2. **What's missing that would make the product significantly more useful for you?** "Significantly" is doing work here. You're asking for impact, not just wish list items.

3. **What would make you switch to a competitor tomorrow?** This surfaces your most vulnerable gaps. The honest answer is often something specific and buildable.

4. **What would make you impossible to poach — a user competitors could never win over?** The inverse of the above. This reveals what would create deep lock-in and loyalty.

5. **If you had to choose between [faster performance] and [new feature X], which matters more?** Substitute real options relevant to your product. Concrete trade-offs yield more useful answers than abstract ranking exercises.

6. **What's the one thing we're not doing that we should be?** Open-ended, direct, and hard to dodge. Users often surprise you here.

7. **Is there anything on our current roadmap you're particularly looking forward to?** If they've seen your public roadmap, their answer tells you what's resonating. If they haven't, this is a good moment to share it and get a live reaction.

8. **If you were the product manager, what would you build next?** Role-switching gives users permission to be bold. The answers are not directives, but they often contain a clear signal worth unpacking.

## Closing questions

Don't rush the close. The last few minutes of an interview often produce the most candid responses — the things users held back until they felt comfortable enough to say.

1. **Is there anything else you think we should know?** The open door. Some users have been waiting the whole conversation to say something specific. Give them the space.

2. **Is there anyone else you think we should talk to — on your team or outside it?** Referrals from existing interview participants reach people you wouldn't find through your normal recruiting channels.

3. **Would you be open to us following up if we have more questions?** Most users say yes. This keeps the relationship open without committing to a specific follow-up.

4. **We're planning to [build X / redesign Y / change Z]. Would you be willing to review it before we ship?** Beta testers and early reviewers are more valuable when recruited from users with relevant context. This is the right moment to ask.

5. **Can we share what we build based on what you told us today?** This is a commitment to close the loop. Users who expect to hear back are more invested in your product's direction. Honor it.

## Interview template

Use this as your guide. Adapt based on what comes up — but keep an eye on the time.

---

**Total time: 30 minutes**

**Introduction (5 minutes)**

Introduce yourself and explain the purpose of the interview. Ask for consent to record if relevant.

> "I'm going to ask you some questions about your work and how you use our product. There are no wrong answers — I'm trying to understand your experience, not test you. Feel free to be honest, including about things that aren't working."

Use questions 1–3 from Opening questions to warm up.

---

**Discovery (10 minutes)**

Understand their workflow, the problems they face, and their current situation.

Use questions 4–7 from Opening questions, then move into Problem discovery questions 1–5.

Follow the conversation. If they mention a specific pain point, go deeper before moving on.

---

**Product feedback (10 minutes)**

Get their honest reaction to your product and any specific features or directions you want to validate.

Use Product feedback questions 1–5 and Feature validation questions 1–4, selecting those most relevant to your current priorities.

---

**Close (5 minutes)**

Wrap up, cover anything outstanding, and set expectations for next steps.

Use all five Closing questions. Don't skip question 1 — users often share the most useful thing in the final minute.

---

## After the interview

Synthesize your notes within 24 hours while the conversation is still fresh. If you recorded, use a transcription tool to get a text version and pull the key quotes.

Tag themes as you go: workflow friction, missing features, onboarding confusion, competitive gaps. Consistent tagging across interviews lets you spot patterns that a single conversation can't reveal. If five users in a row mention the same workaround, that's a priority signal — not an anecdote.

Feed what you learn into your feedback system. Interview insights belong alongside your feature requests and support data, not in a separate doc that only you can find. When a user articulates a problem that matches ten open requests on your [feedback board](/features/feedback), that's a merge and a bump in priority. Tools like [Quackback](/features/feedback) let you capture, tag, and connect feedback from multiple sources — so interview findings don't get siloed from your other signal.

For more on building a system that makes qualitative feedback actionable, see the [user feedback guide](/blog/user-feedback-guide) and our guide on [qualitative vs quantitative feedback](/blog/qualitative-vs-quantitative-feedback).

## Frequently asked questions

### How many user interviews do you need before you can draw conclusions?

Five interviews is the commonly cited threshold for uncovering most major themes in a given user segment. That number comes from Jakob Nielsen's usability research and holds up reasonably well in practice. The caveat is segmentation: five interviews with enterprise users tells you nothing about what SMB users need. Run five per segment you're trying to understand, then look for where patterns overlap and where they diverge.

### What's the difference between a user interview and a usability test?

A user interview explores beliefs, behaviors, and experiences. A usability test observes users attempting specific tasks in your product. Both are qualitative methods, but they answer different questions. Interviews are better for understanding motivation and context — why someone does something. Usability tests are better for diagnosing interface problems — where something breaks down. For feature validation and problem discovery, start with interviews. For evaluating a specific design or flow, move to usability testing. For a broader view of how qualitative methods fit into your feedback program, see our guide on [how to ask for customer feedback](/blog/how-to-ask-for-customer-feedback).

### How do you avoid leading the user during an interview?

Ask open-ended questions and resist the urge to fill silence. "What did you think of that?" is better than "Did you find that confusing?" The second question suggests the expected answer. When a user gives a short answer, follow up with "Can you tell me more about that?" rather than offering a hypothesis for them to confirm. The most common mistake interviewers make is steering toward validation of their existing beliefs. Your job is to hear something you didn't expect — design your questions and your listening posture to make that possible. You can also record and review your own interviews to catch patterns in how you ask questions.

- [Product-Market Fit Survey: Questions, Templates, and the 40% Rule](https://quackback.io/blog/product-market-fit-survey): How to run a product-market fit survey: the Sean Ellis test, the 40% rule, follow-up questions, a copy-paste template, and how to interpret your results.

Published: 2025-11-18

Most startups guess at product-market fit. They look at retention curves, revenue growth, or how often users come back. Those signals matter, but they are lagging indicators. By the time your retention curve tells you something is wrong, you have already lost the users who could have told you why.

There is a survey that measures PMF directly. It asks one question, it has a clear benchmark, and it takes less than a day to set up.

![Product-market fit survey with the 40% benchmark](/blog/product-market-fit-survey/hero.webp)

The method comes from Sean Ellis, who coined the term "growth hacker" and ran growth at Dropbox, Eventbrite, and LogMeIn. After surveying hundreds of startups, he found a consistent pattern: companies that had achieved PMF shared one trait. At least 40% of their users said they would be "very disappointed" if they could no longer use the product. Companies below that threshold consistently struggled to grow.

> A **product-market fit survey** asks users one diagnostic question — "How would you feel if you could no longer use [Product]?" — with four answer options. Your PMF score is the percentage who answer "Very disappointed." The **40% rule**, from the Sean Ellis test, says that 40% or higher signals product-market fit, and below 40% means you do not have it yet.

## What is a product-market fit survey

The PMF survey is a short questionnaire built around a single diagnostic question. Unlike NPS, which measures loyalty, the PMF survey measures dependency. It asks users to imagine the product disappearing and report how that would feel.

The core insight is that users who would be "very disappointed" to lose a product are not just satisfied — they have integrated it into how they work. They have formed a habit. That is what PMF looks like at the user level. When enough of your users feel that way, you have something worth growing.

The survey is typically short: one core question, a handful of follow-ups, and nothing else. The goal is signal, not comprehensiveness.

![Bar chart showing the 40% rule: the "very disappointed" response must exceed 40% to indicate product-market fit](/blog/product-market-fit-survey/forty-percent-rule.webp)

## The core PMF question

The exact wording matters. Do not paraphrase it.

> "How would you feel if you could no longer use [Product]?"

Response options:

- Very disappointed
- Somewhat disappointed
- Not disappointed
- N/A — I no longer use [Product]

Your PMF score is the percentage of respondents who select "Very disappointed." If that number is 40% or above, you have PMF. Below 40%, you do not — at least not yet.

The "N/A" option is important. Users who have already churned skew your results downward. Their answers reflect a product they have already decided to stop using, which is useful information but not what this question is designed to capture. Filter them out when calculating your score.

Calculate your score like this: divide the number of "Very disappointed" responses by the total number of responses minus the "N/A" responses. Multiply by 100.

For example: 60 "Very disappointed" responses out of 130 total, with 10 "N/A" responses. Your score is 60 / (130 - 10) = 50%.

## Follow-up questions

The follow-up questions are where you get the information you need to act. The core question tells you your score. The follow-ups tell you what to do with it.

**What is the main benefit you get from [Product]?**

This surfaces how users actually perceive your value proposition, which is often different from how you describe it. The language users use to describe the main benefit is the language you should use in your marketing. It also tells you what you cannot afford to break.

**What type of person do you think would benefit most from [Product]?**

Ask users to describe your ideal customer. They know your product better than most prospects do, and their answers often reveal segments you have not fully considered. This is particularly useful if your score is high but varies across cohorts.

**How could we improve [Product] to better meet your needs?**

Open-ended. Let users write freely. The "very disappointed" group will give you ideas for strengthening an already strong product. The "somewhat disappointed" group — which is your most important cohort — will tell you exactly what is holding them back from full commitment.

**What would you use as an alternative if [Product] were no longer available?**

This reveals your real competitors, not the ones you think you have. Users may name a direct competitor, a workaround, a spreadsheet, or nothing at all. "Nothing" is a strong signal. "Spreadsheets" tells you the category is still being educated. A named competitor tells you where your differentiation needs to sharpen.

**How did you discover [Product]?**

Useful for attributing growth channels. If your highest-PMF users come from a specific channel or referral source, that channel is worth investing in. If they come from organic word-of-mouth, that is a signal PMF is already doing some of the growth work for you.

**Would you be willing to share more about your experience in a short call?**

Include a yes/no field with space for contact details. Users from the "very disappointed" segment who agree to a call are your best research subjects. Users from the "somewhat disappointed" segment who agree are your most valuable source of improvement ideas.

## PMF survey template

Here is a complete, copy-pasteable template.

1. How would you feel if you could no longer use [Product]?
   - Very disappointed
   - Somewhat disappointed
   - Not disappointed
   - N/A — I no longer use [Product]

2. What is the main benefit you get from [Product]?
   *(Open text)*

3. What type of person do you think would benefit most from [Product]?
   *(Open text)*

4. How could we improve [Product] to better meet your needs?
   *(Open text)*

5. What would you use as an alternative if [Product] were no longer available?
   *(Open text)*

6. How did you first discover [Product]?
   *(Open text)*

7. Would you be willing to share more in a short 15-minute call?
   - Yes — my email is: *(text field)*
   - No

Keep this order. The core question first. Open-ended improvement questions in the middle. The call request last. Respondents who make it to question 7 are already engaged — that is the right moment to ask for more.

## How to distribute your survey

**Who to send it to.** Target users who have experienced your core value proposition. That means users who have completed onboarding, used the product at least once in the past two weeks, and been active for at least a week or two. Brand-new users have not formed a real opinion yet. Churned users will give you useful churn data, but they will drag your PMF score down and obscure the signal from active users.

**When to send it.** Timing matters more than most teams expect. Too early and users have not formed a meaningful attachment. Too late and the users who churned — often the ones most disappointed — are already gone. For most SaaS products, 2-4 weeks after a user reaches a key activation milestone is the right window. That is when the habit is either forming or failing to form.

**How many responses you need.** Aim for a minimum of 40-50 responses before drawing conclusions. Below that, the math is fragile: at 50 responses, a single answer shifts your score by roughly 2 percentage points, so small samples move on noise. 100+ responses gives you a much more reliable reading, and it lets you segment the results meaningfully. If your user base is small, extend the collection window rather than reducing the threshold.

**Where to send it.** Email is the most reliable distribution channel for this survey. Send it from a named person — a founder or a product manager — not a generic address. A personal subject line like "Quick question about [Product]" consistently outperforms anything that sounds like a marketing blast. For products with strong in-app engagement, an [in-app widget](/features/widget) that triggers after a key action is an effective complement to email. In-app delivery captures users who are actively using the product and avoids the inbox entirely.

**How often to run it.** The PMF survey is a diagnostic, not a continuous tracking tool. Run it when you have made significant product changes, when you are trying to understand a new segment, or when you are preparing for a fundraise. Quarterly is reasonable for early-stage companies. Running it too frequently creates survey fatigue and produces results that are hard to compare across periods.

## How to analyze results

**Calculate the 40% benchmark.** Start here. Filter out "N/A" responses and calculate the percentage of remaining respondents who selected "Very disappointed." That is your score. Write it down before going further.

**Segment by cohort.** A single aggregate score hides important variation. Break your results down by: plan type (free vs. paid), user tenure (less than 30 days vs. more than 90 days), acquisition channel, and company size if you serve multiple market segments. You may find that PMF is strong among one segment and weak among another. That is not a failure — it tells you exactly where to focus.

**Read every open-ended response.** Do not summarize them with a word cloud or a spreadsheet formula. Read them. The "somewhat disappointed" responses are the most important. These users see value in your product but have not committed fully. Their suggestions tend to be specific and actionable. Group them by theme. The themes that appear most often across the "somewhat disappointed" group are your clearest product priorities.

This is where a dedicated [feedback system](/features/feedback) earns its place. Routing PMF responses into one [inbox](/features/inbox) lets you tag and theme them in context instead of in a spreadsheet, and connect each theme to your [roadmap](/features/roadmap). Quackback is open source, so you can route an entire user base through it. Its AI clustering groups similar open-ended answers, and the [MCP server](/features/mcp) lets you query the themes from your own tools.

**Compare "very disappointed" and "somewhat disappointed" language.** Look at how each group describes the main benefit. If there is a gap — if the "very disappointed" group uses specific, functional language and the "somewhat disappointed" group uses vague language — that gap often reveals an onboarding or activation problem. Users who get to the core value are loyal. Users who never fully get there are not.

**Tag the alternative tools mentioned.** Build a frequency table of alternatives cited. The most common alternatives define your competitive landscape from the user's perspective. If a tool you did not consider a competitor appears repeatedly, that is worth investigating.

## What to do with your results

**If your score is below 40%.** Do not panic and do not ignore it. Focus on the "somewhat disappointed" group — they are your most valuable resource. They see enough value to use your product but not enough to depend on it. Read every open-ended response from this group. Find the one or two themes that appear most consistently. Those themes are your near-term product priorities.

Do not try to convert "not disappointed" users. They are the wrong segment, the wrong use case, or both. Doubling down on users who do not find your product essential is how you end up with a product that is vaguely useful to everyone and essential to no one.

Also look at the "very disappointed" minority you do have. Even if they are only 20% of your respondents, they are telling you something works. Figure out what distinguishes them. What did they use the product for? How did they find it? What do they describe as the main benefit? That profile is your target customer.

**If your score is above 40%.** Shift your focus to growth. You have evidence that a meaningful portion of your users depend on your product. The priority now is getting more of the right users to that point of dependency. Use the "very disappointed" responses to sharpen your positioning — the language they use to describe the main benefit is often better marketing copy than anything your team will write. Use the alternative tools they mention to inform your competitive differentiation.

Continue to track the score over time. A score above 40% today can slip below it if you change your acquisition channels, expand to a new segment, or make significant product changes. Re-run the survey after major changes to verify you have not moved the product away from what made it essential.

**Close the loop.** Reply to users who left contact details and agreed to a call. Schedule those calls. Users who take time to fill out a survey and offer to talk further are your best research subjects. Treat that offer as a priority, not a nice-to-have.

## PMF survey vs NPS

These tools measure different things and serve different purposes.

The PMF survey is a diagnostic. You run it to determine whether you have achieved product-market fit — and if not, to understand what is preventing it. It is most valuable at early stages, when you are still defining your product and your market. Once you have PMF, you may run it periodically after major changes, but it is not a continuous tracking tool.

NPS is a tracking tool. It measures loyalty over time and helps you identify whether overall user sentiment is improving or declining. It is most useful once you have a stable product and a growing user base. It tells you how users feel quarter over quarter, not whether you have found your market.

Run the PMF survey to find your market. Run [NPS](/blog/nps-survey-template) to monitor your relationship with it.

The qualitative output from both surveys feeds the same place: your feedback system. For more on how to build that system, see the guide on [collecting customer feedback](/blog/collect-customer-feedback) and the broader [user feedback guide](/blog/user-feedback-guide).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How many responses do I need to trust my PMF score?

Aim for at least 40-50 responses before drawing conclusions. At that level, a single answer shifts your score by roughly 2 percentage points. Reach 100 responses to segment by cohort reliably. With a small user base, extend the survey window rather than lowering the threshold.

### Should I include churned users in the survey?

Filter churned users out of your PMF score by placing them in the "N/A" category. Their responses reflect a product they have already left — useful churn research, but not a measure of product-market fit. Run a separate [churn survey](/blog/qualitative-vs-quantitative-feedback) to understand why they left.

### What if my score is strong overall but weak in a specific segment?

A strong overall score with a weak segment means you have product-market fit in some parts of your market and not others. Identify the segment dragging the score down. If it is a strategic priority, treat its open-ended responses as a roadmap. If not, reconsider acquiring those users.

### How is the PMF survey different from a customer satisfaction survey?

A satisfaction survey asks how users feel about their experience, measuring quality. A PMF survey asks how users would feel if the product were taken away, measuring dependency. A product can be pleasant but not essential — rated highly for satisfaction yet "not disappointed" on a PMF survey.

- [What Is a Product Roadmap? The Complete Guide for Product Teams](https://quackback.io/blog/what-is-a-product-roadmap): What a product roadmap is, why it matters, and how to build one. Includes formats, examples, templates, and common mistakes to avoid.

Published: 2025-11-15

Every product team needs a roadmap. Most confuse it with a project plan or a feature list. A roadmap is neither.

A project plan tracks tasks and deadlines. A feature list is a backlog waiting for prioritization. A roadmap is something more deliberate: a strategic document that communicates where your product is going, why those things matter, and in what order you plan to get there. Getting that distinction right changes how your team plans, how your stakeholders communicate, and how your users perceive your product.

![Product roadmap with now, next, later format](/blog/what-is-a-product-roadmap/hero.webp)

![Flow from vision to strategy to roadmap to backlog, showing how broad direction narrows into specific work](/blog/what-is-a-product-roadmap/vision-to-backlog.webp)

> A **product roadmap** is a strategic document that communicates where your product is going, why those things matter, and roughly in what order you plan to build them. It is not a project plan (which tracks tasks and deadlines) or a feature list (an unprioritized backlog). The best roadmaps communicate intent and direction at the initiative level, not contractual ship dates.

## What is a product roadmap

A product roadmap is a strategic document that communicates the direction and priorities of a product over time. It answers three questions: where are we going, why does that matter, and roughly when will we get there.

Notice what is missing from that definition. A roadmap is not a task list. It operates at the initiative or theme level, not the subtask level. It is not a contract. The best roadmaps communicate intent and direction — not deadlines or promises. And it is not a comprehensive feature list. A roadmap is a curated, prioritized view of what your team has decided to focus on, which means it includes decisions about what you are not building.

The difference between a roadmap and a backlog is worth emphasizing. A backlog is an unordered or lightly ordered collection of everything you might build. A roadmap is a curated subset of that list, organized by priority and time horizon, designed to communicate a coherent story. Showing your backlog to a stakeholder or a customer is almost never useful. Showing your roadmap is.

At its best, a roadmap functions as a single source of truth for product direction. Engineers know what they are building next. Sales can set accurate expectations with prospects. Customers understand where the product is heading. Leadership can evaluate whether the product strategy is on track.

## Why product roadmaps matter

The practical value of a roadmap comes from five things it forces your team to do.

**Align on priorities.** Without a roadmap, every team member is working from their own mental model of what matters most. Those mental models diverge over time. A roadmap makes the prioritization explicit so the whole team rows in the same direction.

**Communicate direction to stakeholders.** Executives, investors, sales teams, and customer success managers all have questions about product direction. A roadmap gives them a single place to get answers without requiring the product team to run individual update meetings every week.

**Force trade-off decisions.** A roadmap with finite lanes forces you to choose. Every item you add to Now must displace something. That constraint is uncomfortable, but it produces better decisions than a prioritization-free list where everything is equally important.

**Connect user feedback to product decisions.** A roadmap grounded in real feedback demonstrates to your team — and to your users — that product decisions are evidence-based, not arbitrary. When engineers and designers can trace a roadmap item back to user requests and vote counts, they have better context for the work and more confidence in the direction.

**Reduce "why are we building this?" questions.** These questions are a tax on every planning meeting and engineering sprint. When your roadmap is clear and well-maintained, the answer is visible to everyone. That clarity compounds over time: teams with good roadmaps spend more time building and less time relitigating decisions.

## Types of product roadmaps

There is no single correct roadmap format. The right format depends on your team's planning maturity, your audience, and how predictable your product development is. Here are the five most common formats.

### Now / Next / Later

The Now/Next/Later format divides the roadmap into three columns: what the team is actively building, what they plan to build next, and what they intend to build eventually. There are no dates. No quarters. Just three buckets that reflect relative priority.

This is the most flexible format. It absorbs disruption well — when priorities shift, you move cards between columns rather than rebuilding the whole plan. It also forces genuine triage. A team that puts everything in the Now column quickly realizes the format has broken down.

Now/Next/Later works best for early-stage teams, fast-moving products, and situations where quarterly planning feels premature. It is also a good format for public-facing roadmaps because it communicates direction without creating date commitments you may not be able to keep. For a deeper look at applying this format in an agile context, see the guide on [agile roadmaps](/blog/agile-roadmap).

The main limitation is that the format carries no time information. Teams that need to sequence work against external commitments — a product launch, a conference, an enterprise contract — will find it insufficient on its own.

### Timeline-based

The timeline format lays initiatives across a calendar using monthly or quarterly date ranges. This is the closest relative to a traditional Gantt chart, but organized at the initiative level rather than the task level.

Timeline roadmaps are best for cross-functional coordination. When engineering, design, marketing, and infrastructure all need to deliver work simultaneously for a launch, a timeline makes dependencies visible at a glance. They are also useful when enterprise customers or partners need delivery windows for integration planning.

The significant drawback is maintenance overhead. Timeline roadmaps go stale faster than any other format. A bar on a calendar looks like a commitment even when it isn't, which creates false precision and mismatched expectations when dates slip.

### Theme-based

The theme-based format groups work into named strategic goals rather than chronological buckets. Instead of a feature list, the roadmap communicates intent: "Q2 is about reducing time to first value" or "H2 is focused on enterprise readiness." Individual features appear inside themes, but the theme is the unit of communication.

This format is particularly effective for executive communication and board presentations. Themes translate naturally to business outcomes — retention, growth, platform stability — without requiring the audience to infer strategy from a list of features.

Theme-based roadmaps also survive scope changes better than feature lists. If one feature in a theme gets cut or delayed, the theme still communicates the right intent. Teams can adjust implementation without invalidating the roadmap.

### Outcome-based

The outcome-based roadmap organizes work around metrics rather than features. Instead of "Build SSO," the roadmap says "Reduce enterprise deal friction: target 20% reduction in sales cycle length." The features that might deliver that outcome are listed as options, not commitments.

This format is most effective for product-led growth teams and organizations that have moved past the "build everything in the backlog" phase. It forces clarity on why each initiative exists. If you cannot articulate the outcome a feature is meant to drive, that is a signal to reconsider whether it belongs on the roadmap.

The challenge with outcome-based roadmaps is that they require a culture comfortable with uncertainty about implementation. Stakeholders who want to know exactly what will ship by when will find this format frustrating.

### Kanban-style

The kanban format organizes items by status: Planned, In Progress, Done. This is the most common format for public-facing roadmaps because it communicates where things stand without requiring date commitments. Linear, Plausible, and dozens of other SaaS companies use this format for their public roadmaps.

For a full comparison of tools designed for public roadmaps, see the [best public roadmap tools](/blog/best-public-roadmap-tools) guide.

### Format comparison

| Format | Best for | Flexibility | Audience |
|---|---|---|---|
| Now / Next / Later | Early-stage, agile teams | Very high | Team + customers |
| Timeline-based | Cross-functional coordination | Low | Internal, enterprise |
| Theme-based | Executive communication | Medium | Leadership, board |
| Outcome-based | Product-led growth teams | High | Internal |
| Kanban-style | Public-facing transparency | Medium | Customers |

## What to include in a product roadmap

A roadmap should be opinionated about what it contains. The temptation is to add detail until the roadmap becomes a project plan. Resist it.

**Include these elements:**

- **Goals and themes.** One or two sentences explaining the strategic direction behind the roadmap. What problem are you solving at the business level?
- **Initiatives.** The units of meaningful work. Not tasks, not subtasks. "Redesign onboarding flow" is an initiative. "Write copy for onboarding step 3" is a task that belongs in a project management tool.
- **Time horizons.** Rough bucketing — Now/Next/Later, or quarterly groupings — that communicate relative priority and sequence without creating false precision.
- **Status indicators.** A simple signal — Planned, In Progress, Shipped — that tells anyone reading the roadmap where each item stands.
- **Links to user feedback and evidence.** If an item is on the roadmap because 200 users requested it, that context belongs on the roadmap. It validates the decision and helps engineers understand the user problem they are solving.

**Exclude these elements:**

- **Task-level detail.** Tasks belong in your project management tool, not your roadmap. Once a roadmap includes subtasks and assignees, it has become a project plan and loses its usefulness as a communication tool.
- **Exact deadlines.** Specific ship dates belong in sprint plans, not roadmaps. Deadlines on a roadmap create the impression of a contract that does not exist, and they become liabilities when timelines slip.
- **Resource allocation.** Who is working on what and how many hours it will take is not roadmap-level information. Keep it out.

## How to build a product roadmap

Building a roadmap from scratch follows a consistent sequence. The format is the last decision, not the first.

### Step 1: Define your product vision and goals

Before you can prioritize, you need a clear picture of where the product is going over the next 12 to 18 months. What does success look like? What are the two or three most important outcomes you are trying to drive? Write these down explicitly. They will serve as a filter for every prioritization decision that follows.

Without this foundation, a roadmap becomes an ordered list of whatever your loudest stakeholders requested most recently. That is not a strategy.

### Step 2: Collect and synthesize feedback

A roadmap grounded in user feedback makes better bets than one built on internal assumptions. Collect feedback through a [feedback board](/features/feedback) where users can submit requests and vote on existing ones. Supplement that with support ticket patterns, NPS survey responses, and qualitative interviews.

Look for signal in the aggregate. One feature request from one user is a data point. A hundred requests from users with similar profiles who are all running into the same friction is a direction. For a structured approach to this process, the [guide to collecting customer feedback](/blog/collect-customer-feedback) covers methods and tools in detail.

### Step 3: Prioritize with a framework

With a list of candidates, apply a structured scoring method to reduce the influence of recency bias and internal politics. The [RICE framework](/blog/rice-framework-explained) — Reach, Impact, Confidence, Effort — scores each initiative on four factors and produces a comparable ranking.

Alternatively, [MoSCoW prioritization](/blog/moscow-prioritization) — Must have, Should have, Could have, Won't have — is faster to apply and works well for sprint-level planning or when you need to communicate priorities to stakeholders who are not familiar with quantitative scoring.

Use the output as a starting point for conversation, not a final answer. Scoring models are decision aids. The team still needs to make the final call, informed by context the model cannot capture.

### Step 4: Group into themes or time horizons

Individual features are hard to communicate at the roadmap level. Group related items into themes that describe the user problem you are solving. "Improve team collaboration" is a better roadmap item than a list of seven small features. Themes also make the roadmap more resilient — if one feature in a theme gets cut, the theme still conveys the right intent.

If you are building a timeline or quarterly roadmap, assign grouped themes to time horizons at this stage. Be conservative. Under-promising and over-delivering is a better outcome than the reverse.

### Step 5: Choose your format

Match the format to your audience and your planning maturity. If you are early-stage and moving fast, default to Now/Next/Later. If you have a quarterly planning cadence and multiple teams, use a theme-based format. If you are sharing a roadmap with customers, use a public kanban.

Avoid timeline formats unless you have the organizational maturity and coordination overhead that justifies the maintenance cost.

### Step 6: Share and iterate

A roadmap nobody reads is a planning document that happened in a meeting. Publish it where your team and users can find it. Link it from your product, your docs, your support portal. When items ship, notify the users who requested them.

Set a review cadence and stick to it. Monthly reviews for the Now column. Quarterly reviews for Next and Later. Assign a specific person to own updates. A roadmap that drifts from reality is worse than no roadmap — it creates false expectations for everyone relying on it.

## Product roadmap examples

The best way to understand what good roadmaps look like is to study real ones. Here are four format examples worth noting.

**Linear's public kanban** uses three columns — Planned, In Progress, Done — with minimal card detail. The Done column does most of the credibility work by showing a long history of shipped items. Linear commits only to what they can show without caveats. The restraint is intentional.

**GitHub's repository-based roadmap** is a GitHub project board built from GitHub Issues. The format meets developers where they already are. Users can react to issues, leave comments, and link their own issues to roadmap items. It turns the roadmap into a two-way communication channel.

**A quarterly theme-based internal roadmap** groups work into named strategic goals — Q1: onboarding, Q2: retention, Q3: enterprise readiness — with features nested inside each theme. This format aligns cross-functional teams around shared outcomes rather than individual features.

**An outcome-based roadmap** replaces feature names with metric targets. "Reduce activation drop-off" appears where a feature list would otherwise be. Features that might contribute to that outcome are listed as options, not commitments. This format works best for product-led growth teams where the connection between features and metrics is well understood.

For a detailed analysis of 15 real roadmap examples across all these formats, see the [product roadmap examples](/blog/product-roadmap-examples) guide.

## Public vs internal roadmaps

Not all roadmaps serve the same audience. The distinction between public and internal roadmaps matters more than most teams realize.

An internal roadmap is a planning tool. It can include rough estimates, open questions, dependencies, and in-progress thinking. It is allowed to be messy because its audience — your team — has context to interpret it correctly.

A public roadmap is a communication tool. It represents your product to users who may be making purchasing decisions based on what they see. Every label and every status is a message to a customer who may be evaluating you against a competitor.

**Benefits of a public roadmap:**

- Reduces "when is this coming?" support volume by giving users a self-serve answer.
- Builds trust with users who can see their feedback reflected in product priorities.
- Creates accountability — teams with public roadmaps tend to keep them more current.
- Differentiates you from competitors who hide their direction entirely.

**Risks to manage:**

- Over-commitment. Items on a public roadmap create expectations. If items sit in "Planned" for 18 months without moving, that erodes trust faster than having no roadmap.
- Competitor visibility. Detailed public roadmaps reveal your strategic direction to competitors. Theme-level communication is usually safer than feature-level detail.
- Inflexibility. Users who see specific features on a public roadmap can become attached to those exact features, which makes pivoting harder.

**How to share safely:**

- Use themes and outcomes rather than specific feature names where possible.
- Show status, not estimates. "In progress" communicates something useful without creating a date commitment.
- Limit the "Planned" column to items you are genuinely committed to building in the near term. Move speculative items to a separate feedback board rather than a public roadmap lane.
- Link roadmap items back to their source feedback so users can see the demand behind each decision.

For a detailed comparison of tools that support public roadmaps, see the [best public roadmap tools](/blog/best-public-roadmap-tools) guide.

## Common roadmap mistakes

Most roadmap failures follow a predictable pattern. These are the mistakes worth watching for.

**Treating the roadmap as a contract.** Sales teams sometimes share roadmaps with enterprise prospects as implicit commitments. Engineers sometimes treat timeline entries as deadlines. When the roadmap is treated as a contract, it stops being updated honestly, and teams start managing the roadmap appearance rather than the underlying product reality.

**Adding too much detail.** Once a roadmap includes subtasks, assignees, and story point estimates, it has become a project plan. The overhead of keeping it current increases dramatically, and the signal-to-noise ratio drops. Keep the roadmap at the initiative level.

**Never saying no.** A roadmap that says yes to everything is not a strategy. The value of a roadmap comes precisely from its constraints. If your Later column never gets reviewed and pruned, it becomes a graveyard for ideas that nobody will build — and its presence creates false expectations.

**Building in isolation.** A roadmap built entirely from internal assumptions rather than user feedback tends to prioritize the features that are loudest internally, not the ones that matter most to users. Grounding roadmap decisions in feedback — vote counts, support patterns, interview notes — produces better bets and creates a defensible rationale for every decision.

**Not updating it.** A roadmap reviewed once and never touched again is worse than no roadmap. It creates false expectations for anyone who checks it. Assign ownership and set a recurring review cadence. If no one is responsible for keeping it current, it will drift.

**Confusing output with outcome.** A roadmap that lists features is measuring output. A roadmap organized around outcomes — metrics, user problems, business goals — measures what actually matters. Teams that optimize for output can ship a lot and still miss their goals. Teams that optimize for outcomes stay connected to the work's purpose.

## Roadmap tools

Your tool choice should follow your format choice, not precede it. Choosing a tool before deciding what kind of roadmap you need leads to over-engineering.

**Spreadsheets** are underrated for early-stage teams. A well-structured spreadsheet with columns for initiative, theme, time horizon, and status handles the Now/Next/Later format effectively. See the [Google Sheets roadmap template](/blog/google-sheets-roadmap-template) for a ready-to-use starting point.

**Dedicated roadmap tools** — Productboard, Aha!, Jira Product Discovery — add structured views, integrations, and collaboration features that become valuable as team size and planning complexity grow. The overhead of setting them up and maintaining them is not worth it for teams of under ten people.

**Feedback-connected roadmaps** close a loop that dedicated roadmap tools often miss. When your roadmap is disconnected from your feedback board, you end up manually justifying prioritization decisions that should be self-evident from vote counts and user demand. [Quackback's roadmap](/features/roadmap) connects directly to the [feedback board](/features/feedback) so every roadmap item links back to the requests and votes that drove it. When an item ships, users who voted for it are notified automatically via the [changelog](/features/changelog) — no manual email required. Quackback is open source (AGPL-3.0) and self-hosted for free, with a managed [Quackback Cloud](/pricing) option. The whole team can read and update the roadmap, and an [MCP server](/features/mcp) lets you query roadmap and feedback data directly from your AI tools.

For teams managing different kinds of roadmaps across departments, the [technology roadmap guide](/blog/technology-roadmap), [IT roadmap guide](/blog/it-roadmap-guide), and [marketing roadmap guide](/blog/marketing-roadmap) cover format and process considerations specific to those contexts.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### How often should you update your roadmap?

The Now column — whatever the team is actively building — should reflect current reality at all times. Review the Next column monthly. Review the Later column quarterly. If your product is moving fast, monthly reviews across the full roadmap are appropriate. The key is a fixed cadence rather than reactive updates when someone notices the roadmap is wrong.

### Should your roadmap have dates?

For internal roadmaps, rough quarterly buckets are useful for coordination without creating false precision. For public roadmaps, dates create commitments you may not be able to keep. Status labels — Planned, In Progress, Done — communicate progress without the liability of a specific date. If you do include dates, use ranges ("Q3 2025") rather than specific days.

### What's the difference between a roadmap and a backlog?

A backlog is an unordered collection of everything you might build, often hundreds of items. A roadmap is a curated, prioritized subset, organized by theme and time horizon to communicate a coherent strategic story. The roadmap is a communication tool; the backlog is a planning artifact.

### Should you make your roadmap public?

Most SaaS teams should publish some version of a public roadmap. It reduces support volume, builds trust, and differentiates you from competitors who hide their direction. The caveat is that you should only publish items you are reasonably confident you will build. A public roadmap full of items that never ship erodes trust faster than having no roadmap. Use themes rather than specific feature names to preserve flexibility while still communicating direction.

### How do you handle stakeholder requests that don't fit the roadmap?

Acknowledge the request and explain the trade-off directly: "That is not in the current roadmap because we are focused on X this quarter." Log it in your feedback board for the next planning cycle. If the request recurs, that frequency is signal. A clear no with context beats vague reassurance.

### What's the difference between a product roadmap and a project plan?

A project plan operates at the task level: assignees, deadlines, dependencies, and resources. It answers who is doing what, and when. A product roadmap operates at the initiative level. It answers what you are building, in what order, and why. A roadmap informs project plans but does not replace them.

- [Qualitative vs Quantitative Feedback: What to Collect and When](https://quackback.io/blog/qualitative-vs-quantitative-feedback): The difference between qualitative and quantitative feedback. When to use each type, how to combine them, and tools that handle both.

Published: 2025-11-11

There are two types of feedback. Most product teams collect one well and neglect the other. The result is either a spreadsheet of numbers with no context, or a pile of comments with no way to gauge scale.

Both types matter. Knowing when to use each — and how to combine them — is one of the more practical skills in product management.

![Qualitative vs quantitative feedback comparison](/blog/qualitative-vs-quantitative-feedback/hero.webp)

> **Qualitative feedback** captures what users say in their own words and explains *why* something is happening; **quantitative feedback** captures structured numbers like ratings and vote counts and shows *what* is happening and at what scale. Use quantitative data to find what to investigate and qualitative data to understand it. The strongest feedback programs collect both in one place, so a vote and the comment behind it sit together.

## What is qualitative feedback?

Qualitative feedback is open-ended. It captures what users say in their own words: free-text survey responses, support tickets, interview transcripts, feature request descriptions, and comments on a feedback board.

The strength of qualitative feedback is context. A user who writes "I gave up on the export flow because it kept timing out and I couldn't tell if my data was saved" tells you something no rating scale can. You know what broke, where in the flow it broke, and what the emotional consequence was.

The weakness is scale. Reading and categorizing hundreds of open-ended responses takes time. Without a system for tagging and summarizing, qualitative feedback piles up in inboxes and spreadsheets where it never gets used. [AI-assisted analysis](/blog/ai-customer-feedback-analysis) is changing this — automated categorization, sentiment analysis, and summarization now make qualitative data tractable at volumes that would have been impractical to analyze manually.

## What is quantitative feedback?

Quantitative feedback is structured and measurable. It includes NPS scores, CSAT ratings, feature vote counts, star ratings, and Likert scale survey responses. It produces numbers you can track over time and compare across segments.

The strength is that it scales effortlessly. A thousand users can each submit a rating in seconds, and you can aggregate those ratings instantly. Trends become visible. You can spot when satisfaction drops, which features have the most demand, and how different user segments compare.

The weakness is that numbers carry no explanation. A drop in your NPS from 42 to 31 tells you something went wrong. It does not tell you what. A feature with 200 votes tells you people want it. It does not tell you why, for whom, or whether building it the way you are imagining would actually solve their problem.

![Qualitative vs quantitative feedback side-by-side comparison](/blog/qualitative-vs-quantitative-feedback/qual-vs-quant.webp)

## Qualitative vs quantitative feedback: a comparison

| | Qualitative | Quantitative |
|---|---|---|
| **Format** | Open text, transcripts, comments | Ratings, scores, counts, scales |
| **Collection methods** | Interviews, open survey fields, support tickets, feedback comments | NPS surveys, star ratings, vote counts, Likert scales |
| **Analysis approach** | Tagging, thematic coding, AI summarization | Aggregation, trend tracking, segmentation |
| **Strengths** | Rich context, surfaces root causes, reveals unexpected issues | Scalable, comparable over time, easy to prioritize |
| **Weaknesses** | Hard to analyze at scale, harder to benchmark | Lacks context, can mislead without follow-up |
| **Best for** | Understanding why, discovery, post-churn interviews | Tracking trends, validating hypotheses, gauging demand |

## When to use qualitative feedback

Use qualitative feedback when you need to understand why something is happening, not just that it is.

**Early-stage discovery.** Before you have a clear problem definition, qualitative feedback is your primary tool. Interviews, open-ended surveys, and informal conversations reveal what users actually struggle with — often things you would not have thought to ask about directly.

**Understanding root causes.** When your metrics signal a problem, qualitative feedback explains it. If your activation rate drops, reading support tickets and talking to recent churned users will surface the actual friction point faster than any A/B test.

**Identifying unmet needs.** Users often request features without articulating the underlying need. Qualitative feedback — especially interviews — lets you dig past the request to the job they are trying to get done. "Can you add Zapier integration?" might reveal a workflow gap that a different feature would solve better.

**Post-churn interviews.** When users cancel, their reasons are worth understanding in depth. Exit surveys help, but a 20-minute conversation with a churned user yields insights that a multiple-choice cancellation form never will. The candor of someone who has already left is rare and useful.

For more on methods that surface this kind of insight, see the [complete guide to collecting customer feedback](/blog/collect-customer-feedback).

## When to use quantitative feedback

Use quantitative feedback when you need to measure, compare, or track something over time.

**Tracking trends.** A single NPS score tells you little. A quarterly NPS trend tells you whether satisfaction is improving or declining and whether specific changes you shipped had an effect. Quantitative data only becomes meaningful when you have enough of it to see a pattern.

**Prioritizing features by demand.** When you have ten open feature requests and capacity for two, vote counts give you an objective signal for where to focus. A request with 300 votes is not automatically more important than one with 20 — but the gap is a real data point that belongs in your prioritization discussion. [Feature voting](/features/voting) lets users surface what matters to them without requiring a survey or interview.

**Benchmarking satisfaction.** Standardized metrics like NPS and CSAT are designed for comparison — against your own history, against industry benchmarks, and across different user segments. You cannot benchmark qualitative feedback in the same way. See the [NPS survey template guide](/blog/nps-survey-template) for how to run these surveys effectively.

**Validating hypotheses.** If you believe a new onboarding flow improves activation, quantitative data lets you confirm it. If you think a specific user segment is less satisfied, NPS segmented by plan type or tenure shows whether you are right. Qualitative feedback surfaces the hypothesis; quantitative feedback tests it.

## How to combine both types

The most useful feedback programs use quantitative data to identify what to investigate, and qualitative data to understand why.

A practical workflow: your quarterly NPS drops four points. Quantitative data flags the problem and lets you narrow it to a specific cohort — say, users on your free plan who signed up in the last 90 days. You then run targeted interviews or add an open-ended follow-up question to that cohort's next survey. The qualitative data explains what changed in their experience and what they needed that they didn't get.

The same pattern works for feature prioritization. Vote counts on a [feedback board](/features/feedback) tell you which requests have the most demand. But before you commit to building a highly-voted feature, read the comments. The top-voted request might have 200 votes but ten different underlying use cases, each requiring a different solution. The qualitative context changes how you scope the work.

Feature boards that combine [voting](/features/voting) with comment threads are the most efficient format for this. Users signal demand with a vote and explain their specific situation in the comment. You get the aggregated quantitative signal and the qualitative context in one place, without running a separate research process.

[Quackback](/) is built around this. It is an open-source feedback board (AGPL-3.0) you can self-host for free or run as a managed [cloud](/pricing) instance, and it pairs votes with comment threads so both feedback types land in one tool. Built-in AI summarizes long comment threads, and an [MCP server](/features/mcp) lets you query both your quantitative and qualitative feedback from tools like Claude.

For a deeper look at building a system that handles both, see the [user feedback guide](/blog/user-feedback-guide) and the guide on [how to ask for customer feedback](/blog/how-to-ask-for-customer-feedback).

## Common mistakes

**Only collecting one type.** Teams that rely entirely on NPS scores miss the context behind them. Teams that only run interviews have rich insights but no way to gauge how widely they apply. Both approaches leave gaps that cost you in product decisions.

**Analyzing qualitative data manually at scale.** Reading 500 support tickets by hand to find patterns is slow, inconsistent, and demoralizing. At that volume, themes get missed and recency bias takes over — you remember what you read last week, not what you read three months ago. Use tagging systems and AI-assisted summarization to handle volume without losing signal.

**Ignoring the context behind numbers.** A CSAT score of 3.2 out of 5 on your onboarding flow is information. The reason it is 3.2 is what you need to know. Quantitative metrics should trigger qualitative investigation, not end the conversation.

**Treating votes as the full picture.** Feature vote counts reflect who uses your feedback board, which skews toward engaged power users. A request with 50 votes from users who each represent $500 MRR may be more important than one with 300 votes from users on a free plan. Segment your quantitative feedback the same way you would any other data.

**Collecting feedback without closing the loop.** Users who submit feedback and never hear back stop submitting. This applies to both types. Acknowledge requests. Publish what you are building and why. Notify users when something they voted for ships. The feedback you get from a user who knows their input matters is better than feedback from someone who expects silence.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Is one type of feedback more important than the other?

Neither is more important — they answer different questions. Quantitative feedback tells you what is happening and at what scale. Qualitative feedback tells you why. Treating one as a substitute for the other leads to bad decisions. A mature feedback program uses both, with each type triggering the right analysis.

### How do I get qualitative feedback without running expensive interviews?

You do not need a formal research program. Open-ended fields on your NPS or CSAT survey add context with almost no extra effort. Comment threads on a feature voting board give qualitative signal at scale without scheduling. Support tickets you already receive become research assets once you tag them systematically.

### How many responses do I need before quantitative feedback is reliable?

For most statistical comparisons, around 100 responses per segment is a reasonable floor; below that, outliers distort the average. If your user base is small, extend the collection window or combine survey periods. For qualitative feedback, aim for thematic saturation — when new responses stop introducing new themes.

- [Voice of the Customer (VoC): How to Build a Program](https://quackback.io/blog/voice-of-customer): Build a Voice of the Customer program that drives product decisions. Covers collection methods, analysis frameworks, metrics, and closing the loop.

Published: 2025-11-08

Every customer has opinions about your product. Most of them never reach your product team.

![Voice of the Customer program with collect, analyze, act stages](/blog/voice-of-customer/hero.webp)

> A **Voice of the Customer (VoC)** program is a structured, continuous process for collecting customer signals across all channels, finding patterns in them, and turning those patterns into product decisions. It goes well beyond surveys: support tickets, feature requests, NPS responses, in-app feedback, sales objections, and churn interviews all count. To build one, centralize every channel into a single system, tag and quantify the feedback with voting and sentiment, report to stakeholders on a regular cadence, and close the loop with the customers who gave the input.

The user who hit a confusing workflow and quietly moved on. The churned customer who switched to a competitor because a missing integration made your product impractical. The power user who figured out a workaround for something you could fix in a day. These people had useful things to tell you. Without a system to capture that input, it disappears.

A Voice of the Customer program creates systematic channels between customers and the people who build the product. Not a quarterly survey. Not a suggestion box that nobody reads. A continuous, structured process for collecting, analyzing, and acting on the full range of customer signals — and communicating back to the customers who gave them.

## What is Voice of the Customer (VoC)?

Voice of the Customer is a structured approach to understanding customer needs, expectations, and experiences across all touchpoints. It is not synonymous with surveys. Surveys are one input. VoC is the full system.

Every signal your customers generate counts: support tickets, feature requests, NPS responses, in-app feedback, sales call objections, social media mentions, churn interviews, and direct conversations. A mature VoC program captures all of these, routes them into a unified system, finds patterns, and turns those patterns into decisions.

The goal is not to collect feedback for its own sake. The goal is to close the gap between what customers experience and what your product team knows. Without a VoC program, that gap is filled by whoever is loudest internally — the executive who talked to one enterprise customer, the sales rep pushing a deal-specific feature, the engineer who built something they personally wanted. With a VoC program, decisions are grounded in the actual distribution of customer needs.

## Why VoC matters for product teams

**Reduces guessing.** Product decisions made without customer data are hypotheses. VoC replaces guesses with evidence. When you can show that 80 customers have requested the same workflow improvement, the conversation shifts from "I think we should build this" to "here's what the data supports."

**Surfaces unmet needs before churn.** Customers rarely announce they are about to leave. They stop engaging, submit a final frustrated support ticket, and then disappear. A VoC program catches these signals early. Sentiment trends, declining engagement with your feedback board, patterns in support volume — these are leading indicators of churn that a reactive approach misses entirely.

**Prioritizes with evidence.** Feature backlogs without demand data are unsorted. VoC gives you the signals to rank requests by frequency, revenue impact, and customer segment. That makes prioritization decisions defensible. When you say no to a request, you can explain why, which maintains trust even when you don't build what someone asked for.

**Builds customer trust.** Customers who see their input acknowledged — even when the answer is no — stay engaged with your product longer. They give better feedback. They become advocates. The act of listening, systematically and visibly, signals that your roadmap is shaped by their reality.

**Aligns cross-functional teams.** Product, support, sales, and success teams all interact with customers, but rarely share what they learn. VoC creates a common language and a shared data source. When everyone is looking at the same customer signals, internal debates become more productive and less political.

## VoC collection methods

A VoC program is only as good as its collection channels. Each method captures a different type of signal. The strongest programs combine several.

### Feedback boards and voting

A public [feedback board](/features/feedback) gives customers a dedicated place to submit ideas, vote on requests from others, and track the status of their suggestions. The key mechanism is [voting](/features/voting): instead of every user submitting the same request independently, they vote on an existing post. You get clean demand data rather than a pile of duplicates.

Feedback boards work because they make customer input visible. A user who searches the board and finds their idea already submitted understands that others share the problem. A product team that sees 120 votes on a single request has a clearer picture of demand than one that received 120 separate emails about it.

Quackback provides feedback boards and voting as its core functionality. Users can submit requests, vote, comment, and follow updates. Your team can triage, tag, merge duplicates, and update statuses. It handles this layer of the VoC stack well.

### Support ticket analysis

Your support team is already collecting feedback. Every ticket about a confusing workflow, every chat asking how to accomplish something, every email requesting a feature — these are data points. The difference between a support operation and a VoC channel is whether you aggregate and analyze what comes in.

Tag tickets by theme. Track which issues surface most frequently. Look for language patterns: if fifteen users describe the same problem in different words, your product's mental model probably doesn't match theirs. Quackback integrates with [Zendesk](/integrations/zendesk) and [Intercom](/integrations/intercom), so support conversations can feed directly into your feedback board without requiring your support team to manually copy and paste.

### NPS and CSAT surveys

NPS surveys ask customers how likely they are to recommend your product. CSAT surveys measure satisfaction after specific interactions. Both produce quantitative scores you can track over time — but the most valuable output is the open-ended follow-up question, where customers explain their rating in their own words.

Quackback does not run surveys. If you need NPS or CSAT infrastructure, you will need a separate tool (more on the full stack below). What feedback boards and survey data do together is more useful than either alone: surveys tell you how customers feel, boards tell you what they want. Used together, you can segment board data by NPS score, prioritize fixes for detractors, and validate that shipped features are moving sentiment in the right direction. For survey templates, see the [NPS survey template](/blog/nps-survey-template) and [customer satisfaction survey template](/blog/customer-satisfaction-survey-template).

### Customer interviews

Interviews give you depth that no other method produces. A 30-minute conversation with a churned customer reveals context, motivation, and workflow detail that no survey can capture. The best interview subjects are users who recently churned, users who recently converted, and power users who use your product in unexpected ways.

The key is to avoid leading questions. Ask "how do you currently handle X?" rather than "would you use feature Y?" The former reveals the actual problem. The latter produces polite agreement that tells you nothing useful. For a set of questions that work across different interview contexts, see the [user interview questions guide](/blog/user-interview-questions).

Five good interviews often surface patterns that hundreds of survey responses miss. Use them to generate hypotheses, then validate with quantitative data from your feedback board and surveys.

### In-app feedback widgets

An embedded feedback widget captures input at the moment of experience. The user hits a frustrating flow and can submit a report without leaving the page. Context is high — you know what they were doing, where they were, and who they are. Friction is low — a button click and a few sentences.

In-app collection consistently produces higher response rates than email surveys or external forms because you are asking for feedback exactly when the user has something to say. Submissions from an in-app widget can route directly to your feedback board, keeping everything in one place for analysis.

### Sales and CS call notes

Your sales team hears every objection that stops a deal from closing. Your customer success team hears every frustration from customers who are about to churn. Both groups generate valuable VoC data that rarely reaches the product team in a structured form.

Create a lightweight process for logging what comes up on calls. A single field — "What was the primary objection or missing feature?" — captures enough to identify patterns. Lost deal analysis is especially useful: your existing users cannot tell you what your prospects need. Sales calls can.

### Social media and review sites

G2, Capterra, Reddit, and social platforms capture feedback from customers who won't submit it through official channels. This input is unfiltered. Users on review sites describe what they actually think, including complaints and comparisons with competitors that they would soften in a direct conversation.

Set up alerts for your product name and competitor names. Review patterns on G2 and Capterra for recurring themes. This channel skews toward the very satisfied and very frustrated, so treat it as a signal source rather than a primary truth. When ten reviews in a row describe confusing onboarding, that is worth investigating even if your in-app feedback board is silent on the topic.

### Churn exit interviews

Customers who leave are your most honest source of feedback. They have nothing to gain from being polite, and their decision to cancel was made after weighing your product against their alternatives. Churn interviews surface competitive gaps, missing features, and usability problems that retained customers may have adapted to or given up on reporting.

Keep churn interviews short — five to ten minutes. Focus on two questions: what prompted the decision to cancel, and what would have needed to be true for them to stay. The answers are often more specific than you expect.

## How to analyze VoC data

Collecting feedback creates a backlog. Analysis turns that backlog into insight. Raw volume is not useful until you find the patterns.

**Theme identification.** Group feedback by recurring topic. "Export doesn't work," "CSV export is broken," and "I can't get my data out" are all the same theme. Tag consistently across all channels so you can query across them. Without consistent tagging, every question about "what are users saying about X" requires a manual search.

**Sentiment tracking.** Sentiment analysis classifies feedback by emotional signal — positive, negative, frustrated, urgent. Quackback runs automated sentiment analysis on incoming feedback, so your team can surface the most frustrated users without reading every post. A feature request from a user exploring possibilities is different from the same request from a user threatening to cancel. Sentiment context changes prioritization.

**Volume and frequency analysis.** A single request is an anecdote. Forty requests about the same problem is a pattern. Resist building based on one compelling request from an important customer. Aggregate first, then decide. Track how request volume changes over time — a sudden spike in tickets about a specific workflow often signals a regression or an emerging use case.

**Segmentation.** Not all feedback carries equal weight. A request from five enterprise accounts is different from the same request from five free-tier users — not because free-tier users matter less, but because the business implications differ. Segment by customer type, revenue tier, plan, and tenure. Patterns that look weak in aggregate may be strong within specific segments.

For more detail on the AI tools available for feedback analysis and how they compare, see [AI customer feedback analysis](/blog/ai-customer-feedback-analysis). For a framework on when to use qualitative versus quantitative signals, see [qualitative vs quantitative feedback](/blog/qualitative-vs-quantitative-feedback).

## Building a VoC program

A VoC program is not a tool. It is a process. Tools support the process, but they do not replace the need for consistent habits and clear ownership.

### Step 1: Identify where feedback already exists

Before setting up new channels, audit what you already have. Support tickets, sales call notes, existing surveys, social mentions — feedback is almost certainly flowing somewhere already. Map the current sources, identify who owns each one, and assess how much of what comes in actually reaches the product team.

Most teams discover that feedback is fragmented across a dozen places with no single person responsible for aggregating it. That is the problem a VoC program solves.

### Step 2: Centralize into one system

Pick a primary system and route all channels into it. A feedback board works well as the hub because it creates a shared, searchable backlog that the whole team can see. Support integrations pipe in ticket themes. In-app widget submissions land directly in the board. Sales call notes get logged as internal posts.

The goal is a single source of truth for customer signals. Fragmented tools create fragmented analysis. When feedback lives in ten places, patterns are invisible. When it lives in one place, they surface.

### Step 3: Tag and categorize consistently

Define a tagging taxonomy before you start. Product area, feedback type (feature request, bug, usability, question), and customer segment are the minimum. Apply tags consistently to every item, including items ingested from other channels.

Consistent tagging is what makes analysis possible later. If you tag ad hoc, you will not be able to query "all feedback about the billing flow from enterprise customers" six months from now. The upfront investment in taxonomy pays off at scale.

### Step 4: Quantify with voting and sentiment

Tags tell you what feedback is about. Voting tells you how much it matters. Sentiment tells you how customers feel about it. Together, these signals give you a prioritization basis that is far more defensible than gut instinct.

A feature request with 200 votes and high negative sentiment is different from one with 200 votes and neutral sentiment. The first represents customers who are actively frustrated by the absence of the feature. The second represents customers who would appreciate it. Both are worth building — but the first is more urgent.

### Step 5: Report to stakeholders regularly

Schedule a regular cadence — weekly or biweekly — to review the top themes, surface emerging signals, and share findings with product, design, and engineering. This is where VoC data moves from a feedback tool into the product decision process.

Reporting does not need to be elaborate. A short summary of the top five themes by volume, the five highest-voted open requests, and any significant sentiment shifts is enough to keep the team oriented. The goal is to make customer signals a routine input to planning, not a quarterly event.

### Step 6: Close the loop

When you ship a feature that came from customer feedback, tell the customers who asked for it. When you decide not to build something, explain why. Closing the loop is what turns a feedback collection system into a VoC program. It is also the step most teams skip.

For a detailed walkthrough of how to close the loop effectively, see the [customer feedback loop guide](/blog/customer-feedback-loop).

## VoC metrics

Tracking a few metrics keeps your VoC program honest and gives you a way to demonstrate its value internally.

**Feedback volume.** The number of feedback items received per week or month across all channels. Rising volume generally means users trust that their input matters. Declining volume is a warning sign.

**Response rate.** For surveys and outreach, the percentage of users who respond. Declining rates suggest survey fatigue or loss of trust in the process. Review your frequency and timing if rates drop.

**Time to first response.** How long it takes to acknowledge a new feedback item with a status update or comment. Users who submit feedback and hear nothing are likely to disengage. A short time to first response signals that the team is paying attention.

**Time to close the loop.** The elapsed time from when feedback is submitted to when the user is notified of a decision — whether that decision is to build, decline, or defer. This metric tracks the health of the full cycle, not just the collection layer.

**Feature request coverage.** The percentage of shipped features that originated from or were validated by customer feedback. If your team is regularly shipping features with no connection to customer signals, your VoC program is not informing product decisions.

**NPS and CSAT trend.** If you are running surveys, track these scores over time. The goal is not a single number — it is a trend. Rising scores alongside a maturing VoC program suggest that closing the loop is working.

## Common VoC mistakes

### Only using surveys

Surveys are one input. A VoC program built entirely on quarterly surveys misses the majority of customer signal. Passive channels — feedback boards, support ticket analysis, social monitoring — capture the customers who would never complete a survey. Surveys are good for structured, quantitative questions. They are bad at capturing the unscripted, specific feedback that drives the most valuable product improvements.

### Not closing the loop

Collecting feedback without communicating decisions back to customers is the most common failure mode. Users submit ideas, hear nothing, and eventually stop engaging. The feedback volume drops. The team interprets this as "users don't have feedback," when the reality is that users concluded their feedback was pointless. Closing the loop — even to say no — keeps the channel open.

### Cherry-picking feedback

It is tempting to highlight the feedback that confirms what the team already wants to build and downweight the rest. This undermines the entire purpose of a VoC program. If you are going to act on customer signals, you need to look at the full distribution, including the patterns that challenge your current direction.

### Ignoring detractors

Negative feedback is uncomfortable. It is also often the most actionable. A customer who gives you a 3 out of 10 and writes three paragraphs about what went wrong is giving you specific, high-value signal. Dismissing that input because it is critical is a systematic way to miss your highest-leverage improvements.

### Treating VoC as a one-time project

Some teams run a feedback initiative — a big survey, a round of interviews, a week of triaging the backlog — and then go quiet for months. Users learn the cadence and stop engaging between initiatives. VoC is a continuous process, not a project with a start and end date. The infrastructure, the habits, and the reporting cadence all need to be always-on.

## Tools for VoC

A complete VoC stack typically involves several tools working together. Here is an honest breakdown of the categories and what each handles.

**Survey tools** cover NPS, CSAT, and structured questionnaires. Typeform and SurveyMonkey are the most widely used. They handle survey design, distribution, response collection, and basic analysis. They do not handle feature requests, voting, or public roadmaps.

**Feedback collection and prioritization tools** handle feature boards, voting, in-app widgets, duplicate detection, and roadmap management. Quackback and [Canny](/compare/quackback-vs-canny) are the main options in this category. Quackback handles the collection and prioritization layer well: public boards, voting, sentiment analysis, integrations with [Zendesk and Intercom](/integrations/zendesk) for support ticket ingestion, and a [changelog](/features/changelog) for closing the loop. It does not run surveys, build NPS dashboards, or cluster themes across qualitative data at scale. It is the right tool for the collection and prioritization layer of VoC — not a full VoC platform.

What sets Quackback apart in this category is the licensing and access model. It is open source under AGPL-3.0, so you can self-host the full program for free or run it on [Quackback Cloud](/pricing). You can add your whole product, support, and success team to the VoC process. It runs automated sentiment analysis on incoming feedback so you can surface frustrated users without reading every post. And an [MCP server](/features/mcp) lets you query your feedback data directly from AI assistants — useful when you want to ask "what are enterprise customers asking for this quarter?" without building a report by hand.

**Qualitative analysis tools** process large volumes of open-ended text. Dovetail and Thematic specialize in analyzing interview transcripts, survey verbatims, and support tickets at scale. These tools handle the analysis layer that sits between raw qualitative data and actionable insight. They are most useful once your feedback volume exceeds what your team can manually categorize.

Most product teams at the growth stage need: one survey tool, one feedback collection tool, and a consistent process for sharing findings across teams. The qualitative analysis tools become worth the cost once volume makes manual analysis impractical.

For a broader comparison of tools in this space, see the [best customer feedback tools in 2026](/blog/best-customer-feedback-tools-2026) and the guide to [collecting customer feedback](/blog/collect-customer-feedback).

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### What is the difference between VoC and customer feedback?

Customer feedback is any single input a customer gives you, such as a support ticket or feature request. Voice of the Customer is the program that systematically collects, organizes, and acts on that input across all channels. Feedback is the raw material; VoC is the process around it.

### How is VoC different from market research?

Market research studies target markets, often including people who are not yet customers, and answers who you should sell to. Voice of the Customer focuses on existing customers and their experience with your actual product, answering what the people using it today need. Both are useful for different questions.

### Do I need a dedicated VoC team?

Not at the start. A small product team can run a functional VoC program with a feedback board, a support integration, and a weekly review meeting. Dedicated VoC roles make sense at larger organizations where signal volume exceeds what product managers can synthesize. Early on, clear ownership matters more.

### How do I get buy-in to start a VoC program?

Start with a small demonstration. Run a one-month pilot: set up a feedback board, route support tickets into it, and present the top five patterns at the next planning meeting. Once the team sees customer signals informing a real decision, the case for investing usually makes itself.

### How do I handle conflicting VoC signals?

Treat conflicting signals as segmentation data, not a problem to resolve. When enterprise customers want one thing and SMB customers want another, that reveals a strategic trade-off. Segment your VoC data consistently so you can see whose voice is behind each signal, then prioritize based on your current focus.

- [MoSCoW Prioritization: The Method Explained (2026 Guide)](https://quackback.io/blog/moscow-prioritization): Learn the MoSCoW prioritization method: how to sort features into Must, Should, Could, and Won't have to scope sprints, align stakeholders, and plan releases.

Published: 2025-11-04

Feature prioritization is hard. Every sprint has more candidates than capacity, and every stakeholder has a different view of what matters most. MoSCoW gives you a simple, structured way to sort the essential from the optional before those debates start.

The method doesn't require a spreadsheet or a formula. It requires a shared vocabulary and a willingness to say no — at least for now.

![MoSCoW prioritization framework with four categories](/blog/moscow-prioritization/hero.webp)

> **MoSCoW prioritization** sorts features into four buckets — Must have, Should have, Could have, and Won't have (this time) — so a team agrees on what a release contains before planning starts. Musts are non-negotiable; Won'ts are explicitly out of scope. Use it to scope and align, then pair it with a numeric method like RICE to sequence the work inside each bucket.

## What is MoSCoW prioritization?

MoSCoW is a prioritization method that sorts features into four categories: Must have, Should have, Could have, and Won't have. The name is an acronym formed from the first letter of each category, with the vowels added to make it pronounceable.

The method was created by Dai Clegg at Oracle in 1994 and later formalized as part of the Dynamic Systems Development Method (DSDM) agile framework. It was designed specifically for time-boxed delivery — situations where the scope must be adjusted to meet a fixed deadline or release window.

The core idea is simple. Not everything in your backlog is equally important. MoSCoW forces you to make that explicit before planning begins, rather than discovering it mid-sprint when the team runs out of time.

## The four categories explained

### Must have

Must-haves are non-negotiable. The product, release, or sprint does not work without them. If a Must is not delivered, the outcome is a failure.

When evaluating whether something is a Must, ask: would the product be unusable or unshippable without this? Would it violate a legal requirement, contractual obligation, or critical safety standard? If the answer is yes, it is a Must.

Must-haves typically account for around 60% of the total effort in a sprint or release. If your Musts already consume more than that, you need to either extend scope (add resources or time) or recategorize some items.

**Examples:**
- User authentication before launching a product with user accounts.
- A payment flow before going live with a paid tier.
- Compliance with GDPR data deletion requirements before launch in the EU.
- Core API endpoints a partner integration depends on for a committed launch date.

The discipline with Musts is resisting the urge to inflate them. When everything feels essential, nothing is. Treat "Must" as a high bar, not a default bucket.

### Should have

Should-haves are important but not critical. The product ships without them, but their absence is noticeable. Users may be frustrated or need workarounds, but the core experience holds.

Should-haves are often features that would be Musts in an ideal world with unlimited time — but given constraints, they can be deferred to the next release without breaking anything.

These typically account for around 20% of total effort. If a Should slips, the team should flag it and plan to address it soon. Repeatedly deferring the same Should-haves is a sign they should be promoted to Must for the next cycle.

**Examples:**
- Email notifications when a user's request changes status.
- A keyboard shortcut for a common action used by power users.
- Sorting and filtering options on a list view where users can currently scroll to find items.
- A confirmation dialog before a destructive action (where the action is still possible without it).

### Could have

Could-haves are nice to have. They improve the experience but have low effort relative to their benefit, or they're low stakes enough that skipping them causes minimal friction.

These are the first things to cut when the sprint is at risk. They're also where unexpected delight often lives — small touches that users appreciate even though they never explicitly requested them.

Could-haves also account for roughly 20% of effort. In practice, many Coulds never ship in the sprint they were planned for. That's by design. They act as a buffer: if the team has capacity, they pull Coulds forward; if not, they drop without consequence.

**Examples:**
- A hover tooltip explaining a setting that most users understand intuitively.
- Animated transitions between views.
- A "copy link" button on a record that users can also copy from the browser URL bar.
- An optional onboarding video for a feature that already has inline documentation.

### Won't have (this time)

Won't-haves are explicitly out of scope for the current sprint or release. "Won't" does not mean "never." It means "not now, and we've agreed on that."

This category is the most underused — and the most valuable. An explicit Won't list prevents scope creep, sets expectations with stakeholders, and reduces the background pressure on the team to somehow fit everything in.

When you write down what you're not doing, you make a decision. That decision is communicated, documented, and no longer an open question. The team can focus.

**Examples:**
- A mobile app when the team is shipping a web MVP.
- Multi-language support in a product's first international market before validating demand.
- An advanced analytics dashboard when you're shipping basic reporting first.
- A public API when internal integrations are not yet stable.

Revisit your Won't list at the start of each planning cycle. Items may move into Should or Must as the product matures or as user demand grows.

## MoSCoW vs other prioritization frameworks

MoSCoW is not the only way to prioritize. Here's how it compares to the alternatives most product teams use.

![MoSCoW vs RICE framework comparison](/blog/moscow-prioritization/comparison.webp)

| Framework | Output | Best for | Limitation |
|---|---|---|---|
| MoSCoW | Category buckets | Stakeholder alignment, sprint scoping | No ranking within buckets |
| [RICE](/blog/rice-framework-explained) | Numeric score | Comparing features objectively | Requires data for reliable inputs |
| ICE | Numeric score | Fast, lightweight scoring | No Reach component; less rigorous |
| Value/Effort | 2x2 matrix | Quick visual triage | Oversimplifies complex trade-offs |
| Kano model | Satisfaction categories | Strategic feature discovery | Requires user research; no build order |
| Weighted Scoring | Ranked list | When criteria importance varies | Setup overhead; can hide assumptions |

MoSCoW works best as a communication and scoping tool. It aligns teams and stakeholders on what a release contains before planning begins. It is not designed to rank features within a category — if you have 12 Musts and need to decide which three ship first, you still need a second method.

RICE is the better choice when you need a defensible, numeric ranking across your full backlog. The two frameworks are complementary: use MoSCoW to scope a release, then use RICE to sequence what you build within it.

Use ICE when you want the speed of a numeric score without the overhead of estimating Reach. Use a Value/Effort matrix for a quick visual triage during early brainstorming. Use the Kano model when you're doing discovery and want to understand how different feature types affect user satisfaction.

## How to run a MoSCoW session

### Step 1: List the features

Gather all candidate features for the release or sprint into a single list. This is your raw material. Include everything currently under consideration — don't pre-filter. If something is on someone's mind, it belongs in the session.

### Step 2: Involve the right stakeholders

MoSCoW requires input from anyone who has a stake in the outcome: product managers, engineering leads, designers, and relevant business stakeholders. Keep the group small enough to move quickly — five to eight people is usually the right size.

Assign a facilitator whose job is to keep the session moving and prevent any single voice from dominating. The PM typically fills this role.

### Step 3: Categorize collaboratively

Go through each feature as a group. For each item, ask: "Is this a Must, Should, Could, or Won't for this release?" Start with obvious Musts and Won'ts to anchor the conversation, then work through the contested items in the middle.

When there's disagreement, make it explicit. "You think this is a Must — what would break without it?" is a more productive question than debating in the abstract. Disagreements often reveal unstated assumptions about the product's goals or user expectations.

Set a time limit per item. No more than three to five minutes for contested features. If you can't resolve it quickly, park it and return at the end.

### Step 4: Validate with data

After the initial categorization, check your decisions against available data. Do vote counts on your feature backlog support the Must classifications? Are the features in your Should bucket the ones users mention most in support tickets? Is the effort estimate for each category consistent with the 60/20/20 guideline?

Data doesn't override the group's judgment — but it should inform it. A feature everyone assumed was a low-priority Could might have 200 votes on your feedback board. That's worth knowing before you finalize the list.

### Step 5: Document and communicate

Record every decision: the category, the rationale, and the evidence used. Distribute the output to the full team and any stakeholders who weren't in the room.

The Won't list is especially important to communicate. When a stakeholder asks about a feature they care about, "we discussed it and decided not to include it in this release because X" is a far better answer than silence or ambiguity.

## Using feedback data in MoSCoW

One of the weakest points in any MoSCoW session is the evidence base for decisions. Teams often categorize features based on gut feel, recency bias, or whoever spoke loudest in the last meeting.

Feedback data changes that.

Vote counts on your [feedback board](/features/feedback) directly inform Must and Should decisions. A feature with 300 votes from active users has a stronger claim to Must status than one mentioned twice in sales calls. Low vote counts on a feature you assumed was critical is a signal worth examining.

Support ticket frequency tells you what's causing friction right now. Features that resolve high-volume support issues belong in the Must or Should bucket — the data makes the case without debate.

User comments add qualitative signal to the quantitative. When users explain why they voted for something, you learn whether the underlying need is urgent or aspirational. "I can't complete my workflow without this" belongs in Must. "This would be convenient" belongs in Could.

Quackback's [voting feature](/features/voting) surfaces this data automatically. You can see vote counts, user comments, and request frequency in one place before your MoSCoW session starts. Instead of walking into a prioritization meeting with opinions, you walk in with evidence.

Because Quackback ships an [MCP server](/features/mcp), you can pull that same vote and comment data straight into an AI assistant during the session — ask it to draft a first-pass MoSCoW categorization from your live feedback, then have the group refine it. Quackback is open source (AGPL-3.0) and self-hosted, so every stakeholder in the room can have an account, and the categorized output can flow back into a public [roadmap](/features/roadmap). See the [docs](/docs) for setup.

For more on the tools that support this kind of workflow, see [best feature request tools](/blog/best-feature-request-tools) and [best feature voting tools](/blog/best-feature-voting-tools).

## MoSCoW template

Use this table to document the output of your MoSCoW session. One row per feature. Keep the rationale concise — one or two sentences is enough.

| Feature | Category | Rationale | Evidence |
|---|---|---|---|
| User authentication | Must | Product cannot function without login | Core requirement; no workaround |
| Email notifications on status change | Should | Users expect updates; workaround is manual refresh | 140 votes on feedback board |
| Keyboard shortcuts for common actions | Could | Useful for power users; standard users unaffected | Mentioned in 3 user interviews |
| Mobile app | Won't | Web-first release; mobile validated after web traction | Strategic decision; low current demand |

Copy this table into your planning documents, sprint retros, or roadmap documentation. The Evidence column is the one teams most often skip — and the one most worth filling in.

## Common mistakes

**Treating everything as a Must.** When your Must list covers 80% of the planned work, MoSCoW stops functioning as a prioritization tool and becomes a rubber stamp for the existing plan. Force the question: "What actually breaks if we don't ship this?" If the answer is "nothing immediately," it's not a Must.

**Skipping the Won't list.** Teams that don't document Won'ts leave scope undefined. Undefined scope expands to fill available time. An explicit Won't list is how you prevent features from quietly reappearing in the sprint after they were cut.

**Ignoring data.** MoSCoW sessions based purely on stakeholder opinion reproduce existing biases. Vote counts, support volume, and user comments are available for most products — use them to pressure-test categorizations before they're finalized.

**Setting it and forgetting it.** Categories that made sense at the start of a sprint may not make sense three weeks later. If engineering discovers that a Should has a dependency on an unplanned infrastructure change, it needs to be re-evaluated. Treat MoSCoW as a living document, not a one-time exercise.

**Not revisiting Won'ts across cycles.** Features in the Won't list should be reviewed at the start of each planning cycle. User demand changes. Product strategy evolves. A Won't from six months ago might be a Should today.

---

> **Try Quackback** — open source with a managed cloud option. Start free.
> [Get started](https://quackback.io) | [View on GitHub](https://github.com/quackbackio/quackback)

---

## Frequently asked questions

### Is MoSCoW only for agile teams?

No. MoSCoW originated in DSDM, an agile method, but the framework itself is format-agnostic. Waterfall teams use it to scope releases. Product teams use it for quarterly planning. Individual contributors use it to manage their own workloads. Anywhere you need to distinguish between essential and optional work, MoSCoW applies. The time-boxed delivery context it was designed for is common across methodologies, not exclusive to agile.

### How do you handle disagreements during a MoSCoW session?

Make the disagreement explicit and trace it to its root. If one stakeholder insists a feature is a Must and another says it's a Should, the disagreement usually comes down to different assumptions about users, the product's goals, or what "the product working" means. Ask each person to explain what breaks if the feature isn't included. That question surfaces the actual dispute — whether it's about user expectations, business commitments, or personal priorities — and makes it resolvable. If the group genuinely cannot agree, defer to the person with the clearest ownership of the outcome and document the dissent.

### Should you use MoSCoW or RICE?

Use both, for different purposes. MoSCoW is a scoping tool — it answers "what goes into this release?" RICE is a ranking tool — it answers "in what order do we build things?" Start a planning cycle with MoSCoW to agree on scope with stakeholders. Then use [RICE](/blog/rice-framework-explained) to sequence the work within each category. The two frameworks complement each other. MoSCoW without RICE leaves you with buckets but no build order. RICE without MoSCoW can produce a ranked list that includes items no one has agreed to ship.

### How many features should be in each category?

There is no fixed rule, but the 60/20/20 effort split is a useful guide. Musts should consume roughly 60% of available capacity, Shoulds and Coulds about 20% each. If your Musts already fill the sprint, you have no buffer — and real projects always need buffer. The category counts matter less than the effort distribution. Five Musts with equal effort split is fine. Fifteen Musts that collectively consume 90% of the sprint is a problem.

- [Value Hypothesis: What It Is and How to Test It](https://quackback.io/blog/value-hypothesis): What a value hypothesis is, how to write one, and how to test it with real user feedback. Includes templates, examples, and common mistakes.

Published: 2025-10-28

A value hypothesis is the core assumption your product rests on. It states who you're building for, what problem you're solving, and why someone would care enough to use what you built.

Get it wrong and everything downstream — your roadmap, your messaging, your go-to-market — is built on a faulty foundation.

![A value hypothesis framework diagram showing the relationship between customer, problem, and outcome](/blog/value-hypothesis/hero.webp)

Most teams skip this step. They move straight from idea to execution, treating the value assumption as settled when it hasn't been tested at all. The hypothesis only becomes visible when the product ships and nobody uses it.

## What is a value hypothesis?

A value hypothesis is a testable statement that describes the value your product delivers to a specific customer. It comes from the lean startup methodology, where Eric Ries distinguished between two types of assumptions teams need to validate before scaling: value and growth.

The value hypothesis answers: does this product create value for the people it's meant to serve? It is not a mission statement or a marketing tagline. It is a falsifiable claim — one you can design experiments around and update based on evidence.

A value hypothesis has three components: a customer, a problem or job-to-be-done, and a claimed outcome. Without all three, it's too vague to test.

![Value hypothesis versus growth hypothesis as two sequential validation steps](/blog/value-hypothesis/value-vs-growth.webp)

## Value hypothesis vs growth hypothesis

These two concepts are often confused, but they address different questions.

A **value hypothesis** asks: does anyone want this? Does the product solve a real problem for a real customer in a way they find valuable? This must be validated first.

A **growth hypothesis** asks: can we scale it? Can we find more customers like the ones who already value it, and can we acquire them sustainably? This is only worth testing once value is confirmed.

Trying to grow before validating value is one of the most expensive mistakes a product team can make. You scale a product nobody wants. You optimize acquisition channels before you've confirmed that the people you're acquiring actually get value from what you built.

Validate value first. Growth questions come second.

## How to write a value hypothesis

A reliable formula for writing a value hypothesis is:

**"[Target customer] will [use product/feature] because [it solves specific problem], resulting in [measurable outcome]."**

This structure forces precision. You can't fill it out meaningfully without knowing who your customer is, what problem you're solving, and what success looks like for them.

Here are examples across different product types.

**SaaS product (project management tool):**
"Freelance designers will use our time-tracking feature because tracking billable hours manually takes too long, resulting in more accurate invoices and fewer billing disputes with clients."

**Marketplace:**
"Independent landlords will list properties on our platform because tenant screening currently requires contacting multiple services, resulting in a qualified tenant placed in under two weeks."

**Developer tool:**
"Backend engineers at companies with multiple microservices will use our log aggregation API because debugging across distributed services is too slow with existing tools, resulting in a 50% reduction in mean time to resolution."

**Consumer app:**
"First-time home buyers will use our mortgage comparison tool because comparing lender offers is confusing and time-consuming, resulting in a more confident decision in less than 30 minutes."

Each of these is falsifiable. You can design tests around them, measure the claimed outcome, and update the hypothesis when evidence contradicts it.

## How to test your value hypothesis

Testing a value hypothesis does not require a finished product. Most of the best tests happen before you write a single line of code. Methods are ranked here roughly by effort.

### Fake door tests

A fake door test presents a feature or product to real users before it exists. You add a button, a menu item, or a landing page CTA and measure how many people click through. The "door" leads nowhere — usually a message explaining that the feature is coming soon, or a waitlist form.

Fake door tests measure intent. Clicks are a much stronger signal than survey responses because they require action, not just opinion. A 15% click-through rate on a feature you haven't built yet is meaningful data. A 1% rate is a signal to reconsider.

The limitation is that fake door tests measure demand without confirming that the product actually delivers value. They're a first filter, not a final verdict.

### Landing page and waitlist

Build a one-page description of the product and drive targeted traffic to it. Measure sign-up rate. The sign-up rate itself is a data point, but the more valuable output is the list of people who raised their hand. Talk to them.

A landing page validates that your value proposition resonates enough to prompt action. Combine it with an interview process and you get both a demand signal and qualitative insight into whether your framing matches how customers actually describe the problem.

### Customer interviews

Interviews are the most direct way to test a value hypothesis. You talk to the customers you've hypothesized about, present the problem framing, and listen carefully to whether it resonates.

Good interview technique matters here. You're not pitching — you're listening. You want to hear them describe the problem in their own words, explain what they currently do about it, and react to your proposed solution. Confirmation bias is the main failure mode: you hear what you want to hear and stop probing.

See a future post on user interview questions for a structured approach to getting honest signal from customer conversations.

### Feature voting

If you already have users, [feature voting](/features/voting) is one of the most efficient ways to test value hypotheses around specific capabilities. You describe a feature or improvement in plain language, publish it on your feedback board, and let users vote and comment.

Vote counts give you a demand signal. Comments give you qualitative context — users explain why they want the feature, which often reveals whether they're facing the problem you hypothesized or a different one entirely.

This approach validates demand before you commit engineering resources. It also creates a record you can refer back to when you're deciding how much confidence to assign to your estimates. A feature with 200 votes and 40 detailed comments is a much safer bet than one with three votes and no comments.

### PMF survey

A product-market fit survey tests whether your product is delivering value at the level your hypothesis claims. The core question, from Sean Ellis, is: "How would you feel if you could no longer use this product?" Users who answer "very disappointed" are your engaged, value-confirmed segment.

If fewer than 40% of your respondents say "very disappointed," your value hypothesis likely needs refinement — either you're targeting the wrong customer or the product isn't solving the problem as effectively as you assumed.

See a future post on PMF survey methodology for question wording, sampling, and how to interpret the results.

## Using feedback data to validate

Quantitative and qualitative feedback serve different roles in hypothesis validation.

Vote counts and engagement metrics act as demand signals. When a large share of your user base votes on a specific problem, that's evidence the problem is real and widespread. It adjusts your Confidence estimate upward when you're scoring work with a framework like [RICE](/blog/rice-framework-explained).

Qualitative feedback — comments, interview notes, open-ended survey responses — tells you whether your value framing is accurate. Users might be voting for something you described one way but wanting it for a completely different reason. That gap between your hypothesis and their actual motivation is critical information.

[Quackback's feedback board](/features/feedback) surfaces both signals in one place. You see vote counts alongside the comments users leave, which means you can distinguish between "many people want this" and "many people want this for the reason I think they do." Those are different validations, and you need both.

The goal is not to accumulate feedback. It is to update your hypothesis based on what the feedback reveals.

## What to do when your hypothesis is wrong

A failed value hypothesis is not a failed product. It is a signal to adjust your framing before investing more.

The first thing to check is whether you have the wrong customer. Often the problem is real, but you've been talking to the wrong segment. The people who actually experience the pain acutely are different from the ones you assumed.

The second thing to check is whether you have the wrong problem. Users might be experiencing friction in the area you hypothesized, but the specific pain point you identified isn't the one that matters most to them. Look at how users describe the problem in their own words. If their language doesn't match your hypothesis, update the hypothesis.

Pivot the value proposition, not the entire product. Most failed value hypotheses don't mean the product direction is wrong. They mean the framing was off, the target segment was too broad, or the claimed outcome didn't match what users actually care about.

Your [feedback data](/blog/collect-customer-feedback) is the fastest way to diagnose which of these is true. The comments users leave when they vote or submit feedback often contain the language you need to rewrite a sharper hypothesis.

## Frequently asked questions

### What's the difference between a value hypothesis and a value proposition?

A value hypothesis is an unvalidated assumption — it's what you believe to be true before you have evidence. A value proposition is the refined, validated version you communicate to customers once you have confirmation that the value is real. You test a value hypothesis to arrive at a value proposition.

### How many value hypotheses should you test at once?

One or two at a time. Testing more than that spreads your attention too thin and makes it hard to isolate which variable is responsible for what you observe. Pick your most critical assumption, design the smallest test that could falsify it, and move on to the next once you have a clear result.

### When should you abandon a value hypothesis?

When the evidence against it is consistent across multiple test methods and multiple customer segments. A single failed experiment isn't enough — test designs have flaws, and samples can be unrepresentative. If fake door tests, interviews, and a waitlist all point in the same direction, that's when you have enough signal to move on.

### How specific does a value hypothesis need to be?

Specific enough to be falsifiable. If you can't describe a test that would prove it wrong, the hypothesis is too vague. "Users will find this useful" is not a hypothesis. "Mid-market operations teams will reduce manual reporting time by 30% using this feature" is one — it names a customer, describes an outcome, and implies a measurement.


## Features

- [Feedback Boards](https://quackback.io/features/feedback): Collect and organize feature requests with public voting and threaded comments
- [Public Roadmap](https://quackback.io/features/roadmap): Share your product direction with a customizable public roadmap
- [Changelog](https://quackback.io/features/changelog): Announce shipped features with rich formatting and auto-notify voters
- [Embeddable Widget](https://quackback.io/features/widget): Lightweight feedback widget embedded directly in your product
- [Public Voting](https://quackback.io/features/voting): One-click upvoting with trending indicators and vote tracking
- [REST API](https://quackback.io/features/api): Full programmatic access with OpenAPI documentation
- [SSO & Enterprise Auth](https://quackback.io/features/sso): SAML, OIDC, OAuth providers, and role-based access control
- [Import & Export](https://quackback.io/features/import-export): Import from Canny or CSV, export any time, no vendor lock-in
- [AI Agent Integration (MCP)](https://quackback.io/features/mcp): Built-in MCP server for AI agent search, triage, and management
- [Admin Inbox](https://quackback.io/features/inbox): Triage inbox with advanced filtering, keyboard shortcuts, and bulk actions

## Glossary

- [Product Backlog](https://quackback.io/glossary/product-backlog): A product backlog is an ordered list of everything a product team believes it needs to build, fix, or improve. It serves as the single source of work for the development team and is continuously refined as user feedback, market conditions, and business goals evolve. The product owner maintains the backlog and decides priority.

What is a Product Backlog?
      A product backlog is the prioritized list of features, enhancements, bug fixes, and technical work that a product team plans to deliver. It is not a static document. It changes every sprint as new information arrives from users, stakeholders, and the market.
      The backlog is owned by the product owner or product manager. They decide what goes in, what comes out, and what order items appear in. Every item should tie back to a user need or business objective.
      A well-maintained backlog includes user stories, technical debt items, spike investigations, and bug reports. Each item has enough detail for the team to estimate and plan around it.

      Why It Matters for Product Teams
      Without a backlog, teams rely on memory and ad-hoc requests. Work gets lost. Priorities shift without rationale. The backlog creates transparency. Anyone on the team can see what is planned and why.
      A healthy backlog reflects real user demand. When you connect your backlog to customer feedback, you stop guessing which features matter most. You build what users actually ask for instead of what you assume they want.
      Backlogs also help teams say no. When everything is visible and ranked, it becomes clear that adding one item means deprioritizing another. This forces better trade-off decisions.

      How to Apply Product Backlog Management
      Start by collecting feature requests and feedback from your users in a central place. Tools like Quackback let users submit requests and vote on them, giving you demand signals before items ever reach the backlog.
      Groom the backlog regularly. Remove stale items. Break large epics into smaller stories. Re-rank based on new data. Most teams do this weekly or bi-weekly during backlog refinement sessions.
      Use a prioritization framework like RICE or MoSCoW to rank items objectively. Combine quantitative scoring with qualitative feedback from your users to decide what ships next.
      Keep the top of the backlog detailed and ready for development. Items further down can stay rough. Spending time refining items that may never get built is waste.

- [Jobs to Be Done](https://quackback.io/glossary/jobs-to-be-done): Jobs to Be Done (JTBD) is a framework for understanding why customers buy or use a product. Instead of focusing on demographics or features, JTBD asks what "job" the customer is trying to accomplish. A job is the progress a person seeks in a specific circumstance. Products succeed when they help customers complete their jobs better than alternatives.

What is Jobs to Be Done?
      Jobs to Be Done is a theory of innovation developed by Clayton Christensen and others. It reframes product decisions around customer motivation rather than product features. The central question is: what job did the customer hire this product to do?
      A "job" is not a task. It is the underlying progress someone wants to make. A person does not want a quarter-inch drill. They want a quarter-inch hole. And they probably want the hole because they want to hang a shelf, because they want an organized room. JTBD pushes you to understand the deeper motivation.
      Jobs have functional, emotional, and social dimensions. A project management tool might help someone track tasks (functional), feel in control (emotional), and demonstrate competence to their team (social).

      Why It Matters for Product Teams
      JTBD helps you avoid building features nobody uses. When you understand the job, you can evaluate whether a requested feature actually serves that job or is a distraction.
      It also helps you identify competitors you might not expect. If the job is "stay informed about project progress," your competitors include not just other tools but also email threads, Slack channels, and weekly standup meetings.
      Customer feedback becomes more useful through the JTBD lens. Instead of taking feature requests at face value, you dig into the underlying job. A request for "export to PDF" might really be about sharing progress with a stakeholder who does not have login access.

      How to Apply Jobs to Be Done
      Interview your users. Ask about the last time they used your product and what they were trying to accomplish. Focus on the context and motivation, not the features they used.
      Analyze your feedback data for patterns. Group feature requests by the job they serve, not by the feature category. You may find that ten different requests all point to the same unmet job.
      Write job stories instead of user stories. The format is: "When [situation], I want to [motivation], so I can [expected outcome]." This keeps the focus on the customer's world rather than the product's interface.
      Use tools like Quackback to tag and categorize feedback by job. When you can see which jobs generate the most demand, you can prioritize with confidence.

- [Product Discovery](https://quackback.io/glossary/product-discovery): Product discovery is the process of deciding what to build before committing engineering resources. It involves understanding user problems, generating solutions, and testing assumptions through prototypes and experiments. The goal is to reduce risk by validating that a solution is valuable, usable, feasible, and viable before full development begins.

What is Product Discovery?
      Product discovery is the research and validation work that happens before development. It answers the question: should we build this? While delivery is about building the product right, discovery is about building the right product.
      Discovery involves talking to users, analyzing feedback patterns, building prototypes, and running experiments. It is not a one-time phase. Modern product teams practice continuous discovery, where research happens every week alongside delivery work.
      Teresa Torres popularized the concept of continuous discovery habits: weekly touchpoints with customers, opportunity solution trees for mapping the problem space, and assumption testing to de-risk ideas before they reach the backlog.

      Why It Matters for Product Teams
      Building the wrong thing is the most expensive mistake a product team can make. Discovery reduces that risk. Instead of spending months on a feature that users ignore, you spend days validating whether it solves a real problem.
      Discovery also improves team alignment. When product, design, and engineering collaborate on understanding the problem, they make better decisions during delivery. Fewer surprises. Fewer pivots mid-sprint.
      Teams that skip discovery often rely on the loudest stakeholder or the most recent support ticket to set priorities. Discovery replaces gut feel with evidence.

      How to Apply Product Discovery
      Start with your existing feedback. Tools like Quackback give you a stream of real user problems and requests. Analyze patterns to identify the biggest opportunities.
      Create an opportunity solution tree. Map the desired outcome at the top, the opportunities (user problems) in the middle, and potential solutions at the bottom. This gives you a visual map of your option space.
      Run small experiments before building full features. Fake door tests, wizard-of-oz prototypes, and concierge MVPs all help you learn whether an idea has merit without writing production code.
      Make discovery a habit, not a project. Schedule weekly customer interviews. Review feedback trends every sprint. Keep a running list of assumptions to test.

- [Product Operations](https://quackback.io/glossary/product-operations): Product operations (product ops) is a function that supports product managers by streamlining processes, managing tools, and surfacing data. Product ops teams handle the operational work that enables PMs to focus on strategy and discovery. They standardize how feedback is collected, how experiments are tracked, and how insights flow between teams.

What is Product Operations?
      Product operations is a relatively new discipline that sits alongside product management. Where PMs focus on what to build and why, product ops focuses on how the product team works. It is the infrastructure layer that makes product management scalable.
      Product ops teams typically own three areas: data and insights (making sure PMs have the metrics and feedback they need), tools and processes (selecting and maintaining the product stack), and stakeholder communication (keeping engineering, sales, support, and leadership aligned).
      Not every company needs a dedicated product ops team. But as organizations grow beyond a handful of PMs, the operational overhead of managing tools, aggregating feedback, and standardizing processes becomes significant.

      Why It Matters for Product Teams
      Product managers spend a surprising amount of time on operational tasks: pulling data, configuring tools, writing status updates, and triaging support tickets. Product ops takes on that burden so PMs can spend more time on discovery and strategy.
      Product ops also creates consistency. When every PM uses the same feedback collection process and the same prioritization framework, it is easier to compare opportunities across teams and make portfolio-level decisions.
      Feedback is a key area where product ops adds value. They set up the systems that route customer feedback from support, sales, and social channels into a central repository. They maintain the tagging taxonomy. They generate reports on feedback trends.

      How to Apply Product Operations
      If you are starting a product ops function, begin with the biggest pain point. For most teams, that is feedback fragmentation. Customer insights are scattered across support tickets, Slack messages, sales call notes, and survey responses.
      Implement a feedback hub like Quackback that consolidates requests from all channels. Define a tagging structure that maps to your product areas. Set up regular feedback review cadences.
      Standardize your team's prioritization process. Pick a framework (RICE, ICE, or MoSCoW) and make sure every PM uses it. Product ops maintains the templates and ensures data quality.
      Build dashboards that give leadership visibility into what customers are asking for and how the team is responding. This creates accountability and helps secure resources for high-demand features.

- [Feature Parity](https://quackback.io/glossary/feature-parity): Feature parity means matching the functionality of a competing product or an existing version of your own product. Teams pursue feature parity during platform migrations, product rewrites, or when entering a market with established competitors. It is a strategic choice that balances meeting baseline expectations with the risk of building a copycat product instead of innovating.

What is Feature Parity?
      Feature parity is the state where two products (or two versions of the same product) offer equivalent functionality. The term comes up most often in three scenarios: migrating from one platform to another, rebuilding a legacy product, or competing with an established player in a market.
      Full feature parity is rarely the right goal. The old product accumulated years of edge-case features that few people use. Blindly replicating every feature wastes development resources on low-value work.
      Smart teams aim for functional parity on the features that matter most to users, then innovate beyond them. The key is knowing which features actually drive adoption and retention.

      Why It Matters for Product Teams
      Feature parity decisions affect timelines, team morale, and market positioning. If you set full parity as the bar for launching a new version, you may never launch. If you skip critical features, you lose users in the migration.
      Customer feedback is the best signal for which features need parity. Usage data tells you what people do. Feedback tells you what they would miss. The intersection of high usage and strong sentiment identifies your parity must-haves.
      Feature parity also matters when prospects compare your product to competitors. If your tool lacks a feature that every alternative offers, you need a clear reason why or a plan to close the gap.

      How to Apply Feature Parity Decisions
      Start by cataloging the features of the reference product. Map each feature to user feedback data: how often is it requested, how many users depend on it, and what happens if it is absent?
      Use a prioritization framework to rank parity features. Not every feature deserves equal effort. A RICE score can help quantify reach and impact relative to development cost.
      Communicate your parity roadmap to users. A public roadmap shows which features are coming and when. This reduces churn during migrations because users can see that their needs are acknowledged and planned.
      Collect feedback continuously during the transition. Use tools like Quackback to let users flag what is missing. Their real-time input is more reliable than any pre-migration analysis.

- [Backlog Grooming](https://quackback.io/glossary/backlog-grooming): Backlog grooming (also called backlog refinement) is the recurring practice of reviewing, updating, and prioritizing items in a product backlog. During grooming sessions, the team adds detail to upcoming stories, removes obsolete items, re-estimates effort, and reorders based on new information. It keeps the backlog healthy and sprint-ready.

What is Backlog Grooming?
      Backlog grooming is a regular meeting where the product team reviews the backlog and prepares items for upcoming sprints. The Scrum Guide renamed it "backlog refinement" in 2011, but both terms are widely used.
      During a grooming session, the team typically does four things: adds acceptance criteria to stories, splits large items into smaller ones, re-estimates effort based on new understanding, and re-prioritizes items based on current data.
      Grooming is not sprint planning. Sprint planning decides what goes into the next sprint. Grooming ensures there are enough well-defined items for sprint planning to draw from. Think of grooming as preparing ingredients and sprint planning as cooking the meal.

      Why It Matters for Product Teams
      Without regular grooming, backlogs become graveyards of half-formed ideas. Sprint planning slows down because the team spends time debating scope instead of committing to work. Velocity drops because stories are poorly defined.
      Grooming is also where customer feedback enters the development process. New feature requests, bug reports, and user insights should be reviewed during grooming and incorporated into backlog items. This keeps the backlog aligned with real user needs.
      Teams that groom well can plan sprints in 30 minutes instead of two hours. The preparation pays for itself in execution speed.

      How to Apply Backlog Grooming
      Schedule grooming sessions mid-sprint, not right before sprint planning. This gives the team time to research unknowns that come up during the session.
      Bring fresh feedback data to every grooming session. Pull the latest feature requests and vote counts from your feedback tool. Use this data to challenge existing priorities. A feature that had five votes last month might have fifty now.
      Use the INVEST criteria for stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable. If a backlog item does not meet these criteria, it is not ready for a sprint.
      Set a timebox. Grooming should take no more than 10% of your sprint capacity. For a two-week sprint, that is roughly one hour per week. Stay focused on the top of the backlog where items are most likely to be worked on soon.

- [Dual-Track Agile](https://quackback.io/glossary/dual-track-agile): Dual-track agile is a development approach where discovery and delivery run as parallel tracks within the same team. The discovery track focuses on understanding user problems and validating solutions. The delivery track builds and ships validated features. Both tracks operate continuously, with discovery feeding a stream of de-risked ideas into the delivery backlog.

What is Dual-Track Agile?
      Dual-track agile was popularized by Marty Cagan and Jeff Patton. It addresses a common failure mode in agile teams: building features without validating them first. In traditional agile, the backlog is treated as a to-do list. In dual-track agile, every item in the backlog has been through a discovery process.
      The discovery track produces validated backlog items. The delivery track turns those items into shippable software. Both tracks run in parallel within the same sprint cadence. Product managers and designers lead discovery. Engineers lead delivery. But the whole team participates in both.
      This is not waterfall with extra steps. Discovery and delivery happen simultaneously. While the team delivers features validated last week, they are discovering and validating ideas for next week.

      Why It Matters for Product Teams
      Teams that only do delivery build features based on assumptions. They ship fast but often ship the wrong things. Teams that only do discovery research endlessly without shipping. Dual-track agile solves both problems by running research and development in lockstep.
      Continuous user feedback is the fuel for the discovery track. Feature requests, support tickets, usage analytics, and interview insights all feed into discovery. Without a steady flow of user input, the discovery track runs dry.
      Dual-track agile also reduces waste. When you validate ideas before building them, you spend less time on features that users do not want. Engineering effort goes toward proven opportunities.

      How to Apply Dual-Track Agile
      Start by dedicating time to discovery. Even 20% of the team's capacity is enough to begin. Use that time for user interviews, prototype testing, and feedback analysis.
      Set up a feedback pipeline. Tools like Quackback collect feature requests and voting data that feed directly into your discovery track. Review this data weekly to identify the highest-demand opportunities.
      Use opportunity solution trees to structure your discovery work. Map customer outcomes to opportunities to solutions. Test the riskiest assumptions for each solution before moving it to the delivery backlog.
      Define clear criteria for when an idea is "discovery complete" and ready for delivery. This prevents half-validated ideas from entering sprints and causing scope churn.

- [Sprint Planning](https://quackback.io/glossary/sprint-planning): Sprint planning is the agile ceremony where the team decides what work to commit to in the upcoming sprint. The product owner presents prioritized backlog items, the team discusses scope and feasibility, and together they agree on a sprint goal. Effective sprint planning connects user feedback to concrete development commitments within a fixed timebox.

What is Sprint Planning?
      Sprint planning is a timeboxed meeting at the start of each sprint where the team selects items from the product backlog to work on. In Scrum, it answers two questions: what can we deliver this sprint, and how will we do the work?
      The product owner brings a prioritized backlog. The development team assesses capacity and selects items they can commit to completing. Together, they define a sprint goal that gives the sprint a coherent purpose beyond a list of tasks.
      For a two-week sprint, planning typically takes two to four hours. Shorter sprints need less time. The meeting should end with a clear sprint backlog and a shared understanding of what "done" means for each item.

      Why It Matters for Product Teams
      Sprint planning is where strategy meets execution. The decisions made here determine what users will see in two weeks. If planning is disconnected from user feedback, the team builds based on internal assumptions instead of real demand.
      Good sprint planning creates focus. The sprint goal prevents the team from being pulled in too many directions. It also creates accountability. The team commits to specific outcomes, not just activities.
      When sprint planning is informed by customer feedback data, the team can articulate why each item matters. "Users submitted 47 requests for this feature and it has the highest vote count" is more compelling than "the PM thinks this is important."

      How to Apply Sprint Planning
      Prepare before the meeting. The backlog should be groomed, with the top items well-defined and estimated. If you are scrambling to write acceptance criteria during planning, your grooming process needs work.
      Bring feedback data to the table. Share the top-voted feature requests, recent support ticket trends, and any relevant user interview insights. This grounds the conversation in evidence.
      Define a sprint goal that connects to user outcomes. Instead of "complete five stories," try "reduce the time users spend on manual data export." This keeps the team oriented toward impact rather than output.
      Leave buffer for the unexpected. Do not fill every hour of capacity. Teams that plan at 80% capacity handle interruptions and discoveries without breaking sprint commitments.

- [Definition of Done](https://quackback.io/glossary/definition-of-done): A definition of done (DoD) is a shared checklist of criteria that a product increment must meet before the team considers it complete. It typically includes code quality standards, testing requirements, documentation, and deployment readiness. For user-requested features, the DoD should also verify that the original user problem is actually solved.

What is Definition of Done?
      The definition of done is an agreement within the team about what "finished" means. It is not the same as acceptance criteria, which are specific to individual stories. The DoD applies to every piece of work the team delivers.
      A typical DoD includes items like: code is reviewed and merged, unit tests pass, the feature works in staging, documentation is updated, and the change is deployable. Some teams add items like accessibility checks, performance benchmarks, or security reviews.
      The DoD is a quality gate. Without it, different team members have different ideas about what "done" means. One developer might consider a feature done when the code compiles. Another might wait until it is tested in production. The DoD eliminates that ambiguity.

      Why It Matters for Product Teams
      A weak DoD leads to technical debt and user disappointment. Features get marked as complete but still have rough edges. Users encounter bugs that should have been caught. The team spends future sprints fixing yesterday's "done" work.
      For features that originated from user feedback, the DoD should include a step that verifies the original user need is met. It is possible to ship a feature that meets all technical criteria but fails to solve the problem users described. Checking back against the original request prevents this.
      The DoD also protects the team from external pressure to cut corners. When stakeholders push for faster delivery, the DoD gives the team a clear standard to point to.

      How to Apply Definition of Done
      Create the DoD as a team. Everyone who touches the work should agree on the criteria. Post it somewhere visible: a wiki page, a whiteboard, or the top of your project board.
      Include a feedback verification step for user-requested features. Before marking a story as done, check whether it addresses the original feedback. If the feature was requested in your feedback tool, review the original request and confirm the solution matches.
      Review and update the DoD regularly. As the team matures, the bar should rise. If you keep finding the same types of bugs in production, add a check for that scenario to the DoD.
      Use the DoD during sprint reviews. When demonstrating completed work, walk through the DoD criteria to show stakeholders that quality standards were met. This builds trust and reduces second-guessing.

- [Impact Mapping](https://quackback.io/glossary/impact-mapping): Impact mapping is a strategic planning technique that connects business goals to deliverables through a structured map. It works backward from a goal to identify actors (who can influence the outcome), impacts (how their behavior needs to change), and deliverables (what the team can build to create that change). It prevents teams from building features that do not connect to outcomes.

What is Impact Mapping?
      Impact mapping was created by Gojko Adzic as a lightweight strategic planning technique. It produces a visual map with four levels: Goal, Actors, Impacts, and Deliverables.
      The goal is the business objective you want to achieve (e.g., "increase monthly active users by 20%"). Actors are the people who can help or hinder that goal (e.g., new users, existing users, churned users). Impacts describe how each actor's behavior needs to change. Deliverables are the features or activities that could create those behavior changes.
      The map reads left to right as a hypothesis: "We believe that building [deliverable] will cause [actor] to [impact], which will contribute to [goal]." This makes the assumptions behind every feature explicit and testable.

      Why It Matters for Product Teams
      Most product teams have more ideas than capacity. Impact mapping helps you focus on the ideas that connect to business outcomes. If a feature does not trace back to a goal through a clear chain of logic, it probably should not be a priority.
      Impact mapping also helps teams avoid the "feature factory" trap. Instead of measuring success by the number of features shipped, you measure whether the expected impact actually occurred. This shifts the team's focus from output to outcome.
      Customer feedback enriches impact maps. User requests and complaints reveal which impacts are most important. If your feedback shows that users are churning because of a specific workflow gap, that impact gets prioritized on the map.

      How to Apply Impact Mapping
      Start with a clear, measurable goal. Avoid vague goals like "improve the product." Use specific metrics like "reduce time-to-first-value for new users to under 5 minutes."
      Identify your actors by reviewing your user base and feedback data. Who are the people whose behavior you need to change? Use your feedback tool to see which user segments submit the most requests or report the most issues.
      For each actor, brainstorm the impacts: what behavior change would move you toward the goal? Then identify deliverables that could create each impact. Each deliverable should be the smallest thing you could build to test whether the impact occurs.
      Revisit the map regularly. After shipping a deliverable, check whether the expected impact materialized. If not, adjust. Impact maps are living documents, not project plans set in stone.

- [Feature Prioritization](https://quackback.io/glossary/feature-prioritization): Feature prioritization is the process of deciding which features to build first based on impact, effort, user demand, and strategic fit. It uses structured frameworks like RICE, ICE, and MoSCoW to replace gut-feel decisions with repeatable scoring methods. Effective prioritization connects customer feedback data directly to development planning so teams build what users actually need.

What is Feature Prioritization?
      Feature prioritization is how product teams decide the order in which features get built. Every backlog has more ideas than the team can deliver. Prioritization is the discipline of choosing what ships next and what waits.
      Good prioritization balances four inputs: user impact (how many people benefit and how much), development effort (time and complexity to build), strategic alignment (does it move the product toward its vision), and user demand (how many customers are asking for it).
      Without a structured approach, prioritization defaults to whoever argues loudest in the room. Frameworks give teams a shared language and a repeatable process for making trade-offs.

      Common Prioritization Frameworks
      RICE scores features by Reach, Impact, Confidence, and Effort. It produces a numeric score that makes comparison straightforward. RICE works well when you have quantitative data on reach and impact.
      ICE is a lighter alternative that scores Impact, Confidence, and Ease. It trades precision for speed and works well for early-stage teams making rapid decisions.
      MoSCoW sorts features into Must have, Should have, Could have, and Won't have. It is less quantitative but useful for release planning where you need clear categories rather than rank order.
      The Kano model classifies features by their effect on user satisfaction: must-be features that users expect, performance features where more is better, and attractive features that delight. It helps you balance table-stakes work with differentiation.

      How to Prioritize with User Feedback
      The best prioritization starts with real demand signals. When users submit feature requests and vote on them in a tool like Quackback, you get quantitative evidence of what matters most to your audience.
      Combine vote counts with your chosen framework. Feed request volume into the Reach dimension of RICE. Use sentiment from feedback comments to inform the Impact score. This turns subjective opinions into defensible decisions.
      Review your prioritization regularly. User needs change. A feature that ranked low six months ago might surge in demand after a market shift. Keep your scoring current by pulling fresh feedback data into every planning cycle.

- [RICE Framework](https://quackback.io/glossary/rice-framework): The RICE framework is a quantitative scoring model for prioritizing features and projects. It evaluates each item on four dimensions: Reach (how many users it affects), Impact (how much it moves a key metric), Confidence (how certain you are in your estimates), and Effort (how much time it takes to build). The formula produces a single score that enables objective comparison across competing ideas.

What is the RICE Framework?
      RICE was developed by Intercom as a way to prioritize product work without relying on intuition alone. Each feature or project gets scored across four factors, and the formula produces a single number for comparison.
      Reach measures how many users the feature will affect in a given time period. Impact estimates the degree of change for each user, typically on a scale from minimal to massive. Confidence captures how sure you are about your Reach and Impact estimates. Effort is the total person-months (or person-weeks) required to ship.
      The formula is: RICE Score = (Reach x Impact x Confidence) / Effort. Higher scores indicate better return on investment. The score is not a final answer but a starting point for discussion.

      Why RICE Connects to User Feedback
      RICE is only as good as its inputs. Without real data, teams guess at Reach and Impact. User feedback closes that gap. When you have a feedback tool that tracks how many users request a feature and how urgently they describe the need, you can populate Reach and Impact with evidence instead of assumptions.
      Vote counts map directly to Reach. If 200 users voted for a feature, you have a concrete number. Comment sentiment and the language users employ help calibrate Impact. A request described as "blocking my workflow" signals higher impact than "nice to have."
      Confidence improves as you gather more data. A feature with 50 votes and detailed user comments deserves higher confidence than one mentioned in a single sales call.

      How to Apply RICE Scoring
      Start by listing the features you are considering for the next quarter or release. For each one, estimate Reach using your analytics and feedback data. Pull request counts and vote totals from your feedback tool to ground the number.
      Score Impact on a consistent scale. Many teams use 3 (massive), 2 (high), 1 (medium), 0.5 (low), 0.25 (minimal). Apply the same scale across all items to keep comparisons fair.
      Set Confidence as a percentage. Use 100% when you have strong data, 80% for moderate evidence, and 50% when you are speculating. This penalizes items where you are unsure, pushing you to gather more feedback before committing resources.
      Estimate Effort in person-months. Include design, development, testing, and documentation. Then calculate the score and rank your list. Use tools like Quackback alongside a RICE calculator to streamline the process.

- [ICE Framework](https://quackback.io/glossary/ice-framework): The ICE framework is a lightweight scoring model for prioritizing features and experiments. Each item is rated on three dimensions: Impact (how much it moves a key metric), Confidence (how certain you are in the estimate), and Ease (how simple it is to implement). ICE trades the granularity of RICE for speed, making it ideal for teams that need quick prioritization decisions without extensive data.

What is the ICE Framework?
      ICE was popularized by Sean Ellis in the growth hacking community as a fast way to rank experiments and feature ideas. Each item gets a score from 1 to 10 on three dimensions: Impact, Confidence, and Ease.
      Impact measures how much the feature or experiment will move your target metric. Confidence reflects how sure you are about the Impact estimate. Ease captures how quickly and cheaply you can ship it. The ICE score is the average or product of the three numbers.
      ICE is intentionally simple. It does not require the detailed Reach estimates that RICE demands. This makes it faster to apply but less precise when comparing features that affect different audience sizes.

      When to Use ICE Over RICE
      ICE works best when you need to triage quickly. If your team evaluates dozens of ideas per week, spending time on detailed RICE estimates for every one is impractical. ICE lets you do a first pass in minutes.
      It also works well for growth experiments where Reach is roughly constant. If you are testing changes on your signup page, every experiment reaches the same audience. Impact and Ease become the meaningful differentiators.
      For high-stakes roadmap decisions where multiple stakeholders need to agree, RICE's additional rigor may be worth the extra effort. Many teams use ICE for initial screening and RICE for final prioritization of the top candidates.

      How to Apply ICE Scoring
      List your candidate features or experiments. For each one, assign a score from 1 to 10 for Impact, Confidence, and Ease. Be consistent with your scale across items. A 7 for Impact should mean the same thing regardless of the feature.
      Ground your scores in user feedback data where possible. Features with high vote counts and strong user sentiment deserve higher Impact and Confidence scores. Features that are easy to validate through a quick prototype score higher on Ease.
      Calculate the ICE score by multiplying the three numbers (or averaging them, depending on your team's convention). Rank the list and focus on the top items. Review and re-score regularly as new feedback arrives.
      Quackback's voting and feedback data gives you a concrete foundation for Impact and Confidence scores, reducing the subjectivity that can undermine ICE's simplicity.

- [MoSCoW Method](https://quackback.io/glossary/moscow-method): The MoSCoW method is a prioritization technique that sorts requirements into four categories: Must have (critical for launch), Should have (important but not essential), Could have (desirable if time permits), and Won't have (explicitly excluded for now). It is widely used in agile and project management to set clear expectations about scope and delivery.

What is the MoSCoW Method?
      MoSCoW was created by Dai Clegg while working at Oracle. The acronym stands for Must have, Should have, Could have, and Won't have. The "o" letters are added to make it pronounceable and have no meaning.
      Must-have items are non-negotiable. The product cannot ship without them. Should-have items are important and add significant value, but the product is still viable without them. Could-have items are nice to have and will be included only if time and resources allow. Won't-have items are explicitly out of scope for the current release but may return later.
      MoSCoW works best for release planning and scope management. It forces teams to make binary decisions about what is in and what is out, reducing the ambiguity that leads to scope creep.

      Why MoSCoW Works for Product Teams
      MoSCoW's strength is its simplicity. Stakeholders understand the four categories intuitively. You do not need to explain scoring formulas or weighting models. A feature is either a Must or it is not.
      It also creates explicit alignment. When the team and stakeholders agree that a feature is a "Won't have this time," that decision is documented. It prevents the feature from sneaking back into scope mid-sprint.
      Customer feedback helps you categorize accurately. If users consistently describe a feature as essential to their workflow, it is a Must have. If it comes up occasionally but users have workarounds, it is a Should or Could have. Feedback data replaces opinion with evidence.

      How to Apply MoSCoW
      Start with your list of candidate features for the next release. Review each one against your user feedback data. Pull vote counts and request frequency from your feedback tool to understand demand.
      Categorize each feature through a team discussion. Use the rule of thumb that Must-have items should consume no more than 60% of available capacity. This leaves room for Should-have items and buffers for the unexpected.
      Document the categorization and share it with stakeholders. Make the Won't-have list visible. This transparency builds trust because stakeholders can see their requests are acknowledged even when they are deferred.
      Combine MoSCoW with a quantitative framework when you need more granularity within categories. Use RICE to rank items within the Must-have bucket, for example. Tools like Quackback give you the demand data to make both the categorical and rank-order decisions.

- [Kano Model](https://quackback.io/glossary/kano-model): The Kano model is a framework for classifying product features based on their relationship to customer satisfaction. It defines five categories: must-be (expected basics), one-dimensional (more is better), attractive (unexpected delighters), indifferent (no impact), and reverse (actively unwanted). The model helps teams balance investments between table-stakes functionality and differentiating features.

What is the Kano Model?
      The Kano model was developed by Professor Noriaki Kano in the 1980s. It maps the relationship between feature implementation and customer satisfaction on a two-dimensional graph. The key insight is that this relationship is not linear for all features.
      Must-be features are baseline expectations. Users do not get excited when they work, but they get frustrated when they are missing. Think of login functionality or data export. One-dimensional features have a linear relationship: the better the implementation, the more satisfied users are. Performance and speed often fall here.
      Attractive features are the surprises that delight users. They do not expect them, so their absence causes no dissatisfaction, but their presence creates outsized positive reactions. These are your differentiation opportunities.

      Why It Matters for Product Teams
      The Kano model prevents a common mistake: spending all your effort on attractive features while neglecting must-be basics. If your must-be features are broken or missing, no amount of delighters will save user satisfaction.
      It also explains why some highly requested features do not move satisfaction metrics after launch. If users already expect the feature (must-be), delivering it just removes dissatisfaction. It does not create delight. Understanding this distinction helps you set realistic expectations for the impact of each feature.
      Feature categories shift over time. Today's attractive feature becomes tomorrow's one-dimensional expectation. Real-time collaboration was once a delighter in document editors. Now it is expected. Regular feedback collection helps you track these shifts.

      How to Apply the Kano Model
      Run a Kano survey by asking users two questions for each feature: how they feel when the feature is present and how they feel when it is absent. The combination of answers places the feature into one of the five categories.
      Analyze your existing feedback for Kano signals. Feature requests described with frustration or urgency ("I can't work without this") suggest must-be features. Requests framed as wishes or ideas ("it would be cool if") often indicate attractive features.
      Use Quackback to collect and categorize this feedback at scale. Tag requests by Kano category and track how the distribution changes over time. This gives you a living map of where to invest.
      Balance your roadmap across categories. Ensure must-be features are solid before investing heavily in attractive ones. Use one-dimensional features as your steady improvement engine. Reserve capacity for at least one attractive feature per release to maintain differentiation.

- [Release Notes](https://quackback.io/glossary/release-notes): Release notes are documentation that describes the changes, improvements, and fixes included in a software release. They inform users about what is new, what has changed, and what has been fixed. Well-written release notes close the feedback loop by showing users that their requests were heard and acted upon, building trust and encouraging continued engagement.

What Are Release Notes?
      Release notes are a written summary of changes in a product update. They typically cover new features, improvements to existing features, bug fixes, and known issues. They serve as the primary communication channel between product teams and users about what has shipped.
      Good release notes are more than a changelog. A changelog is a technical log of changes. Release notes translate those changes into user-facing language that explains what the change means for the reader. They answer "what does this mean for me?" rather than just "what changed?"
      Release notes can live on a dedicated page, in an email, in an in-app notification, or all three. The format matters less than the consistency. Users should know where to look and trust that updates appear regularly.

      Why Release Notes Matter
      Release notes close the feedback loop. When a user requests a feature and you ship it, the release note is your opportunity to say "you asked, we built it." This drives re-engagement and shows users that their feedback has impact.
      They also reduce support volume. When users can read about changes themselves, they submit fewer "what happened?" tickets. Clear notes about breaking changes or workflow modifications prevent confusion.
      Release notes build product credibility. A steady cadence of updates signals an active, responsive team. Prospects evaluating your product look at release history to gauge momentum and reliability.

      How to Write Effective Release Notes
      Lead with the user benefit, not the technical implementation. Instead of "refactored the query engine," write "search results now load 3x faster." Users care about outcomes, not architecture.
      Group changes by type: new features, improvements, and fixes. Use short paragraphs or bullet points. Include screenshots or short videos for visual changes. Link to documentation for features that need explanation.
      Reference the feedback that inspired each change when appropriate. "Based on your requests, we added bulk export" validates the feedback process. Tools like Quackback connect feature requests to your changelog so users can see their ideas come to life.
      Publish on a consistent schedule. Whether you release weekly, bi-weekly, or monthly, users should know when to expect updates. Consistency builds the habit of checking your release notes.

- [Digital Suggestion Box](https://quackback.io/glossary/digital-suggestion-box): A digital suggestion box is an online tool that replaces the physical suggestion box with a structured feedback collection system. It allows users, customers, or employees to submit ideas, feature requests, and improvement suggestions through a web interface. Modern digital suggestion boxes include voting, categorization, and status tracking, evolving into full feedback management platforms.

What is a Digital Suggestion Box?
      A digital suggestion box is the online evolution of the physical box that sat in office hallways. Instead of dropping paper slips into a container, users submit feedback through a web form or dedicated platform. The concept is the same: give people a channel to share ideas and concerns.
      Early digital suggestion boxes were simple web forms that emailed submissions to a product manager. Modern versions have evolved into feedback boards with public voting, categorized topics, status updates, and two-way communication between teams and submitters.
      The shift from physical to digital solves the core problem of traditional suggestion boxes: visibility. In a physical box, suggestions disappear into a void. Digital tools let submitters track what happens to their ideas.

      Why Physical Suggestion Boxes Fail
      Physical suggestion boxes suffer from three problems. First, there is no accountability. Submissions are anonymous and untracked, so it is easy for them to be ignored. Second, there is no prioritization. Every slip of paper looks the same regardless of how many people share the concern. Third, there is no feedback loop. The person who submitted an idea never learns whether it was read, considered, or acted upon.
      Basic digital forms inherit the same problems if they lack structure. An email form that sends suggestions to a shared inbox is only marginally better than a physical box. The submissions still pile up without prioritization or follow-up.
      Effective digital suggestion systems add the missing layers: voting to surface popular ideas, categorization to organize them, and status tracking to close the loop.

      How to Build a Modern Suggestion System
      Replace your suggestion box with a structured feedback board. Tools like Quackback give you a public-facing board where users submit ideas, vote on each other's suggestions, and follow status updates from "under review" through "shipped."
      Enable voting so you can see which ideas have broad support versus niche interest. This turns your suggestion system into a prioritization tool. The most-voted ideas rise to the top, giving your product team clear demand signals.
      Close the loop on every submission. Even if you decline an idea, explain why. Users who feel heard continue contributing. Users who feel ignored stop submitting. A feedback tool with status updates and notifications automates this communication.
      Support both public and private submissions. Some feedback is sensitive. Give users the option to submit privately while keeping the majority of suggestions visible to the community for voting and discussion.

- [Idea Management](https://quackback.io/glossary/idea-management): Idea management is the systematic process of collecting, evaluating, and implementing ideas from users, employees, or stakeholders. It goes beyond simple suggestion collection by adding structure for scoring, prioritizing, and tracking ideas through a pipeline from submission to delivery. Effective idea management connects user creativity to product execution.

What is Idea Management?
      Idea management is the discipline of turning raw ideas into actionable product work. It covers the full lifecycle: capturing ideas from multiple sources, organizing them into themes, evaluating their merit, prioritizing the best ones, and tracking them through implementation.
      It differs from simple feedback collection in the same way that a kitchen differs from a grocery store. Collecting feedback gives you ingredients. Idea management is the recipe, the cooking process, and the quality check before the dish reaches the table.
      Organizations practice idea management at different scales. A startup might use a single feedback board. An enterprise might run structured innovation programs with formal evaluation committees. The principle is the same: give ideas a path from concept to reality.

      Why Idea Management Matters
      Without a system, ideas get lost. They live in email threads, Slack messages, meeting notes, and individual memories. When planning time arrives, the team works from whatever they can remember rather than the full set of inputs. Good ideas fall through the cracks.
      Idea management also prevents the loudest-voice problem. When ideas are collected and voted on systematically, quiet users with great suggestions get equal visibility. The best ideas rise based on merit and demand, not on who has the most political influence.
      It creates a virtuous cycle. When users see their ideas acknowledged, evaluated, and sometimes shipped, they submit more. The quality and volume of input increases over time, giving your product team a richer signal to work with.

      How to Build an Idea Management Process
      Start with a central collection point. Use a tool like Quackback to create a feedback board where users can submit ideas, describe the problem they face, and vote on submissions from others. This consolidates input that would otherwise scatter across channels.
      Define an evaluation workflow. New ideas should move through stages: submitted, under review, planned, in progress, and completed (or declined). Each stage has clear criteria and an owner. This prevents ideas from sitting in limbo indefinitely.
      Score and prioritize regularly. Use frameworks like RICE or ICE to evaluate ideas objectively. Feed voting data and feedback sentiment into your scores. Schedule a monthly or quarterly review to reassess priorities as new data arrives.
      Close the loop with contributors. Notify users when their idea changes status. Share the reasoning behind decisions to decline ideas. Celebrate shipped ideas by linking them to the original suggestion. This transparency keeps the idea pipeline flowing.

- [Feature Request](https://quackback.io/glossary/feature-request): A feature request is a user suggestion for new functionality or an improvement to an existing product. Feature requests represent raw demand signals from the people who use your product daily. Feedback tools organize, deduplicate, and rank these requests so product teams can identify patterns and prioritize what to build next based on real user needs rather than internal assumptions.

What is a Feature Request?
      A feature request is a suggestion from a user, customer, or internal stakeholder asking for new functionality in a product. Requests range from small UI tweaks to entirely new capabilities. They arrive through support tickets, feedback boards, sales calls, social media, and in-app prompts.
      Not every feature request is worth building. The value of a request depends on how many users share the need, how urgent the problem is, and how well it aligns with the product strategy. A single request is an anecdote. A pattern of similar requests is a signal.
      The best product teams treat feature requests as research data. Each request reveals something about how users think about the product, where they hit friction, and what outcomes they are trying to achieve. The request itself may not be the right solution, but the underlying problem is almost always worth understanding.

      Why Feature Requests Matter for Product Teams
      Feature requests are the most direct form of product feedback. Unlike usage analytics, which show what people do, requests show what people wish they could do. They expose gaps between the product you built and the product your users need.
      Ignoring requests leads to churn. When users feel unheard, they look for alternatives. When they see their requests acknowledged and acted on, they become invested in the product's success. Feature requests are also a retention tool disguised as a feedback channel.
      Requests also help teams avoid building in a vacuum. Without external input, roadmaps tend to reflect internal priorities and pet projects. A steady stream of user requests grounds product decisions in reality and gives teams evidence to justify their priorities to stakeholders.

      How to Manage Feature Requests Effectively
      Centralize all requests in one place. When requests are scattered across email, Slack, and spreadsheets, patterns are invisible. A dedicated feedback tool like Quackback collects requests from every channel and lets users vote on the ones that matter most to them.
      Deduplicate and categorize incoming requests. Many users describe the same need in different words. Group similar requests together and tag them by product area, user segment, or job-to-be-done. This turns individual voices into measurable demand.
      Respond to every request, even if the answer is no. Acknowledge receipt, explain your reasoning, and update the status as it progresses. Close the loop when you ship a requested feature by notifying everyone who asked for it.
      Use request data to inform prioritization. Feed vote counts and request frequency into your scoring framework. A feature requested by 200 users with detailed use cases deserves higher priority than one mentioned once in a stakeholder meeting.

- [Feature Voting](https://quackback.io/glossary/feature-voting): Feature voting is a mechanism that lets users upvote feature requests to signal demand. It transforms qualitative feedback into quantitative data by showing exactly how many people want a specific capability. Voting surfaces the features with the broadest user appeal and gives product teams a defensible way to prioritize their roadmap based on actual user demand rather than guesswork.

What is Feature Voting?
      Feature voting allows users to cast votes on feature requests submitted by themselves or others. Each vote signals that a user wants a particular feature to be built. The result is a ranked list of requests ordered by demand, giving product teams a clear view of what their user base cares about most.
      Voting systems are typically embedded in public or private feedback boards. Users browse existing requests, upvote the ones they care about, and optionally add comments explaining their use case. This creates a self-organizing queue of product ideas ranked by community interest.
      Voting is not a substitute for product judgment. A feature with 500 votes still needs to be evaluated for strategic fit, technical feasibility, and business impact. But voting data removes the guesswork from the demand side of the equation. You know the need is real because users told you so.

      Why Feature Voting Matters for Product Teams
      Product managers are constantly asked to justify their priorities. Voting data gives them evidence. Instead of saying "we think users want this," they can say "247 users voted for this feature, and here are their use cases." This changes the conversation from opinion to data.
      Voting also reduces bias. Without structured feedback, the loudest voices win. The enterprise customer who emails the CEO gets their feature prioritized over the silent majority. Voting democratizes input by giving every user an equal signal.
      For users, voting creates a sense of ownership. When someone votes for a feature and later sees it shipped, they feel heard. This emotional connection drives loyalty and reduces churn. Users who participate in shaping a product are less likely to leave it.

      How to Run Feature Voting Effectively
      Set up a feedback board where users can submit and vote on ideas. Tools like Quackback make this straightforward with public boards, upvoting, and status tracking built in. Keep the board visible and easy to access from within your product.
      Encourage participation. Link to the voting board from your app, support responses, and release notes. The more users who participate, the more representative the data becomes. A board with ten voters is a focus group. A board with a thousand voters is a survey.
      Combine vote counts with qualitative context. Read the comments on high-vote requests to understand the why behind the numbers. Two requests with 100 votes each might represent very different levels of urgency depending on the use cases described.
      Update request statuses publicly. Mark items as under review, planned, in progress, or shipped. When users see that voting leads to action, they continue participating. A stale board with no status updates quickly loses engagement.

- [Feedback Board](https://quackback.io/glossary/feedback-board): A feedback board is a public or private forum where users submit, discuss, and vote on product feedback. It acts as a structured channel between a product team and its users, replacing scattered emails and support tickets with a single visible space. Feedback boards organize suggestions by status and popularity, making it easy to see what users want most and what the team is working on.

What is a Feedback Board?
      A feedback board is a dedicated space where users can submit ideas, report issues, and vote on suggestions from other users. Boards are typically organized by category or product area, with each post showing its vote count, discussion thread, and current status.
      Public boards are visible to anyone. They let potential customers see what existing users are asking for and how the product team responds. This transparency builds trust and can even influence purchase decisions when prospects see their needs already being discussed.
      Private boards restrict access to logged-in users or specific customer segments. They are useful for enterprise products where feedback may contain sensitive information or where you want to segment input by plan tier or user role.

      Why Feedback Boards Matter for Product Teams
      Without a board, feedback lives in email inboxes, support tickets, Slack channels, and spreadsheets. It is fragmented, hard to search, and impossible to quantify. A board consolidates all of that into a single source of truth.
      Boards also reduce duplicate work. When a user submits a request that already exists, they can vote on it instead of creating a new ticket. This deduplication gives you accurate demand data and saves your support team from fielding the same request repeatedly.
      For product managers, a well-maintained board is a living document of user needs. It replaces periodic surveys with continuous feedback. You do not need to ask users what they want. They are already telling you, in their own words, every day.

      How to Set Up a Feedback Board
      Choose a tool built for the job. Quackback provides feedback boards with voting, status tracking, and categorization out of the box. Avoid repurposing issue trackers or project management tools. They were not designed for user-facing feedback and create friction for non-technical users.
      Define categories that match your product areas. Keep the list short enough that users can find the right one quickly. Too many categories create confusion. Too few make it hard to filter and analyze feedback later.
      Promote the board actively. Add links from your app, help center, and onboarding emails. Train your support team to redirect users to the board when they submit feature requests through tickets. The goal is to make the board the default place for product feedback.
      Maintain the board consistently. Update statuses when features move through your pipeline. Archive completed or declined items. Respond to comments. A feedback board that feels abandoned will stop generating useful input.

- [Voice of the Customer](https://quackback.io/glossary/voice-of-the-customer): Voice of the Customer (VoC) is a research methodology for capturing customer needs, expectations, and preferences. It involves collecting feedback through surveys, interviews, support interactions, and feedback boards, then analyzing that data to understand what customers truly value. VoC programs turn scattered user input into structured insights that drive product, marketing, and support decisions.

What is Voice of the Customer?
      Voice of the Customer is a systematic approach to understanding what your customers need and expect from your product. It goes beyond collecting individual pieces of feedback to building a comprehensive picture of customer sentiment, priorities, and pain points.
      VoC data comes from multiple sources: surveys (NPS, CSAT, CES), customer interviews, support ticket analysis, feedback board submissions, social media mentions, and usage analytics. Each source captures a different dimension of the customer perspective. Surveys measure satisfaction. Interviews reveal motivation. Feedback boards surface demand. Together, they form a complete view.
      The goal of VoC is not just to listen but to act. A VoC program without a mechanism for turning insights into product decisions is an expensive listening exercise. The value comes when customer input directly shapes what you build and how you prioritize.

      Why Voice of the Customer Matters for Product Teams
      Product teams that operate without VoC data are guessing. They build features based on internal assumptions and stakeholder opinions rather than evidence from the people who actually use the product. VoC eliminates that gap.
      VoC also aligns the organization. When product, engineering, marketing, and support teams all have access to the same customer insights, they make consistent decisions. Sales stops promising features that are not on the roadmap. Support stops escalating requests that have already been considered and declined.
      VoC data improves retention. When you understand why customers leave and what would make them stay, you can address root causes rather than symptoms. A customer who churns over a missing feature could have been saved if that need had been surfaced and addressed earlier.

      How to Build a Voice of the Customer Program
      Start by establishing feedback channels. Set up a feedback board with Quackback to capture feature requests and product ideas. Deploy NPS or CSAT surveys at key touchpoints. Schedule regular customer interviews. Each channel serves a different purpose, and you need all of them.
      Centralize your data. Pull feedback from every channel into a single repository where it can be tagged, categorized, and analyzed. Fragmented feedback is invisible feedback. You cannot act on insights you cannot see.
      Analyze for patterns. Individual requests are anecdotes. Patterns across hundreds of requests are evidence. Look for themes by product area, customer segment, and urgency level. Quantify how many users are affected and how strongly they feel about each issue.
      Close the loop. Share VoC findings with the broader team in regular review sessions. Feed insights into your prioritization framework. Notify customers when their feedback results in a product change. This last step is what separates a VoC program from a suggestion box.

- [Customer Feedback Loop](https://quackback.io/glossary/customer-feedback-loop): A customer feedback loop is the continuous cycle of collecting feedback from users, analyzing it for patterns, acting on the insights by building or improving features, and then communicating those changes back to the users who provided the input. Closing the loop is what separates companies that listen from companies that just collect data. It turns feedback into a relationship-building mechanism.

What is a Customer Feedback Loop?
      A customer feedback loop has four stages: collect, analyze, act, and communicate. You gather input from users through surveys, feedback boards, support tickets, and interviews. You analyze that input to find patterns and priorities. You act on the highest-impact insights by building features or fixing problems. Then you tell the users who gave feedback what you did about it.
      Most teams are decent at the first two stages. They collect feedback and they analyze it, at least informally. The breakdown happens at stages three and four. Insights sit in reports that nobody reads. Features ship without anyone notifying the users who requested them.
      The loop only works when it is actually a loop. If feedback goes in but nothing comes back out, users stop contributing. They assume nobody is listening. Closing the loop is what sustains the flow of useful input over time.

      Why Closing the Loop Matters
      Closed feedback loops drive retention. When a user requests a feature and later receives a notification that it shipped, they feel valued. That moment of recognition creates emotional loyalty that no marketing campaign can replicate.
      Closing the loop also improves feedback quality. Users who see their input leading to action invest more effort in future submissions. They provide more detail, more context, and more thoughtful suggestions because they know the input is being used.
      Teams that close the loop build a reputation for listening. This reputation attracts more feedback, which gives the team better data, which leads to better product decisions. It is a virtuous cycle. The opposite is also true. Teams that ignore feedback develop a reputation for being unresponsive, and users stop bothering to share their thoughts.

      How to Build an Effective Feedback Loop
      Set up a centralized feedback collection system. Tools like Quackback let users submit requests, vote on ideas, and track progress. When all feedback lives in one place, nothing falls through the cracks.
      Establish a regular cadence for reviewing feedback. Weekly or bi-weekly sessions where the product team reviews new submissions, identifies trends, and connects insights to roadmap items. Make this a standing meeting, not an afterthought.
      Use a public roadmap and changelog to communicate what you are building and what you shipped. A roadmap shows users that their feedback is being considered. A changelog shows them that action was taken. Together, they complete the loop.
      Automate notifications whenever possible. When a feature request moves to "planned" or "shipped," automatically notify everyone who voted for it. This scales the closing-the-loop process without requiring manual effort for every update.

- [Net Promoter Score](https://quackback.io/glossary/net-promoter-score): Net Promoter Score (NPS) is a customer loyalty metric based on a single question: "How likely are you to recommend this product to a friend or colleague?" Respondents answer on a 0-10 scale. Those scoring 9-10 are promoters, 7-8 are passives, and 0-6 are detractors. NPS is calculated by subtracting the percentage of detractors from the percentage of promoters, yielding a score between -100 and +100.

What is Net Promoter Score?
      Net Promoter Score was introduced by Fred Reichheld in a 2003 Harvard Business Review article. It measures customer loyalty with one question: how likely are you to recommend us on a scale of 0 to 10? The simplicity of the question is its strength. It is easy to deploy, easy to answer, and easy to track over time.
      Respondents fall into three groups. Promoters (9-10) are loyal enthusiasts who will keep buying and refer others. Passives (7-8) are satisfied but unenthusiastic. They are vulnerable to competitive offers. Detractors (0-6) are unhappy users who can damage your brand through negative word of mouth.
      The NPS formula is straightforward: subtract the percentage of detractors from the percentage of promoters. If 60% of respondents are promoters and 20% are detractors, your NPS is 40. Passives are not included in the calculation but still matter for overall customer health.

      Why NPS Matters for Product Teams
      NPS gives product teams a longitudinal measure of customer sentiment. Tracking NPS over time reveals whether product changes are improving or degrading the user experience. A rising NPS after a major release confirms you built the right thing. A declining NPS is an early warning that something needs attention.
      The follow-up question is where NPS becomes actionable. After the numerical score, ask "what is the primary reason for your score?" The open-ended responses reveal specific product issues, missing features, and unmet needs that the number alone cannot communicate.
      NPS also segments your user base. Promoters are candidates for case studies, referrals, and beta programs. Detractors need immediate outreach to understand and resolve their issues before they churn. This segmentation helps teams allocate attention where it has the most impact.

      How to Use NPS Effectively
      Send NPS surveys at consistent intervals, typically quarterly. Avoid surveying after positive events like a successful onboarding because it inflates scores. You want a representative sample of your user base, not a cherry-picked one.
      Always include a follow-up question. The score tells you how users feel. The follow-up tells you why. Analyze the text responses for patterns, then feed those patterns into your product prioritization process.
      Combine NPS with other feedback channels. NPS captures sentiment at a single point in time. A feedback board captures ongoing demand signals. Together, they give you both the temperature of your user base and the specific actions that would raise it.
      Act on detractor feedback quickly. Reach out to detractors personally when possible. Understand their issues and demonstrate that you are working on them. Converting a detractor into a promoter has outsized impact on both your score and your retention rate.

- [Customer Satisfaction](https://quackback.io/glossary/customer-satisfaction): Customer satisfaction (CSAT) measures how well a product or service meets customer expectations. It is typically assessed through post-interaction surveys where users rate their experience on a scale. Common satisfaction metrics include CSAT scores, Net Promoter Score, and Customer Effort Score. High satisfaction correlates with retention, expansion revenue, and positive word of mouth.

What is Customer Satisfaction?
      Customer satisfaction is a measure of how well your product meets or exceeds what users expect from it. It is not a single metric but a concept captured through several measurement approaches. The most common is the CSAT survey, which asks users to rate their satisfaction on a scale, typically 1-5 or 1-7, after a specific interaction.
      Satisfaction is relative. A user's expectations are shaped by previous experiences, competitor products, and the promises your marketing makes. Meeting expectations produces satisfaction. Exceeding them produces delight. Falling short produces frustration that drives churn.
      CSAT differs from NPS in scope. CSAT measures satisfaction with a specific interaction or feature. NPS measures overall loyalty and willingness to recommend. Both are useful, but they answer different questions. Use CSAT for tactical insights and NPS for strategic trends.

      Why Customer Satisfaction Matters for Product Teams
      Satisfied customers stay longer, buy more, and refer others. Dissatisfied customers leave and tell people about it. The economics are straightforward: acquiring a new customer costs five to seven times more than retaining an existing one. Satisfaction is the lever that tips the balance.
      For product teams specifically, satisfaction data reveals where the product is strong and where it falls short. Low CSAT scores on a particular feature tell you exactly where to focus improvement efforts. High scores confirm that your design decisions are landing well.
      Satisfaction also predicts churn before it happens. A user whose satisfaction drops from a 5 to a 3 over two quarters is at risk, even if they have not canceled yet. Tracking satisfaction trends lets you intervene proactively rather than react to cancellation notices.

      How to Measure and Improve Satisfaction
      Deploy CSAT surveys at key moments: after onboarding, after support interactions, and after major feature releases. Keep surveys short. A single question with an optional comment field gets higher response rates than a 20-question form.
      Complement survey data with continuous feedback from a feedback board. Surveys tell you how satisfied users are. Feedback boards tell you what would make them more satisfied. The combination gives you both the diagnosis and the prescription.
      Analyze satisfaction by segment. Overall CSAT can mask problems. Your enterprise customers might be satisfied while your small business users are struggling. Break the data down by plan tier, tenure, and feature usage to find where satisfaction gaps exist.
      Act on the findings. The fastest way to improve satisfaction is to fix the issues users are already telling you about. Use a tool like Quackback to identify the most-requested improvements, then prioritize them in your next sprint. Notify users when their reported issues are resolved to reinforce the relationship.

- [Customer Effort Score](https://quackback.io/glossary/customer-effort-score): Customer Effort Score (CES) is a metric that measures how easy it is for customers to accomplish a specific task with your product or support team. It is typically captured through a post-interaction survey asking users to rate their agreement with a statement like "the company made it easy for me to handle my issue." Lower effort correlates strongly with customer loyalty and repeat purchases.

What is Customer Effort Score?
      Customer Effort Score was introduced by the Corporate Executive Board (now Gartner) in a 2010 Harvard Business Review article. The core finding was that reducing customer effort is a stronger predictor of loyalty than delighting customers. Users do not need to be wowed. They need things to work without friction.
      CES is measured with a single question: "To what extent do you agree with the following statement: [Company] made it easy for me to [complete task]." Users respond on a 1-7 scale, where 1 is strongly disagree and 7 is strongly agree. The score is the average of all responses.
      CES is most effective when tied to a specific interaction. Ask it after a support ticket is resolved, after a user completes onboarding, or after they use a new feature for the first time. This specificity makes the results actionable because you know exactly which experience generated the score.

      Why Customer Effort Score Matters for Product Teams
      High-effort experiences drive churn. Research shows that 96% of customers who have a high-effort interaction become disloyal, compared to only 9% of those with low-effort experiences. Effort is the friction between a user and the value your product delivers.
      For product teams, CES highlights usability problems that other metrics miss. A feature might have high adoption (people use it) and decent CSAT (they are not unhappy) but still require too much effort. CES catches the features that work but are harder than they should be.
      CES is also useful for measuring the impact of UX improvements. If you redesign a workflow to reduce steps, CES tells you whether the redesign actually reduced perceived effort from the user's perspective. Usage data alone cannot capture that subjective experience.

      How to Use CES Effectively
      Deploy CES surveys at moments where effort is relevant: after completing a task, after a support interaction, or after navigating a complex workflow. Do not send CES surveys randomly. The question only makes sense in context.
      Segment your CES data by task type and user cohort. Onboarding effort may differ from daily-use effort. Power users may find things easy that new users struggle with. Breaking down the data reveals where to focus your effort-reduction work.
      Combine CES with qualitative feedback. When a user rates their effort as high, ask a follow-up question about what was difficult. Feed those responses into your product backlog as usability improvements. Use your feedback board to track whether other users share the same friction point.
      Set targets and track trends. A CES of 5 out of 7 might be your baseline. Aim to reach 6 within two quarters by shipping specific improvements. Monitor whether scores rise as you reduce friction in the areas users identified as problematic.

- [Public Roadmap](https://quackback.io/glossary/public-roadmap): A public roadmap is a product roadmap shared externally with customers, showing planned, in-progress, and completed features. It gives users visibility into what the team is building and why. Public roadmaps build trust by demonstrating that user feedback influences product direction. They also reduce inbound support questions about when specific features will ship.

What is a Public Roadmap?
      A public roadmap is a view of your product plan that is visible to customers and sometimes to the general public. Unlike internal roadmaps used for sprint planning and resource allocation, a public roadmap communicates intent without exposing implementation details or internal timelines.
      Public roadmaps typically organize items into columns: under consideration, planned, in progress, and completed. Each item includes a title, brief description, and sometimes the number of users who requested it. The format is deliberately simple because the audience is users, not engineers.
      The purpose is transparency. Users want to know whether the feature they need is on the horizon. Prospects want to know if the product is moving in the right direction. A public roadmap answers both questions without requiring anyone to file a support ticket or schedule a call with sales.

      Why Public Roadmaps Matter for Product Teams
      Public roadmaps reduce the most common support question: "when will you build X?" When users can check the roadmap themselves, they stop asking your support team. This frees up support resources and gives users a better experience.
      Roadmaps also build trust. When users see that their feature requests appear on the roadmap, they believe the company is listening. When they see items move from "planned" to "completed," they trust the team to follow through. This trust translates directly into retention.
      For product teams, a public roadmap creates healthy accountability. When you commit to something publicly, you are more likely to deliver it. The roadmap also forces clarity about priorities. If you cannot explain why something is on the roadmap to a customer, you may need to rethink whether it belongs there.

      How to Maintain an Effective Public Roadmap
      Use a tool designed for public-facing roadmaps. Quackback connects your feedback board directly to your roadmap, so users can see their requests progress from submitted to planned to shipped. This integration closes the feedback loop automatically.
      Keep the roadmap at the right level of abstraction. Share themes and features, not technical tasks. "Improved search with filters" is appropriate. "Refactor Elasticsearch index mapping" is not. Users care about outcomes, not implementation.
      Avoid committing to specific dates unless you are highly confident. Use time horizons like "this quarter" or "next quarter" instead. Missed deadlines on a public roadmap damage trust more than no dates at all. If a timeline changes, update the roadmap and communicate why.
      Review and update the roadmap regularly. Remove items that are no longer planned. Add new items as priorities shift. A roadmap that has not been updated in months signals that the team has stopped communicating, which is worse than not having a roadmap at all.

- [Changelog](https://quackback.io/glossary/changelog): A changelog is a chronological record of product updates, new features, bug fixes, and improvements shared with users. It serves as both a communication tool and a historical reference for what has changed in a product over time. Well-maintained changelogs keep users informed, demonstrate momentum, and close the feedback loop by showing that user input leads to real product changes.

What is a Changelog?
      A changelog is a log of changes made to a product, presented in reverse chronological order. Each entry describes what changed, when it changed, and sometimes why. Changelogs can be public-facing (for users) or internal (for the team). The most valuable changelogs are the ones users actually read.
      Product changelogs differ from developer changelogs. A developer changelog lists code-level changes between versions. A product changelog describes changes in user-facing language. "Added CSV export to reports" is a product changelog entry. "Refactored ReportService to support multiple output formats" is a developer changelog entry.
      Good changelog entries answer three questions: what changed, who benefits, and how to use it. A brief description, a mention of the user problem it solves, and a link to documentation or the feature itself. No jargon. No implementation details. Just what the user needs to know.

      Why Changelogs Matter for Product Teams
      Changelogs close the feedback loop at scale. When you ship a feature that was requested by users, the changelog entry is your opportunity to say "you asked for this, and we built it." This recognition keeps users engaged with your feedback process.
      Changelogs also drive adoption of new features. Users cannot use what they do not know about. A well-distributed changelog ensures that every improvement you ship reaches the people who would benefit from it. Email digests, in-app notifications, and a dedicated changelog page all serve this purpose.
      For the product team itself, a changelog creates accountability and visibility. It is a running record of what the team delivered. When stakeholders ask what the team shipped last quarter, the changelog is the answer. It also helps the team reflect on velocity and focus areas.

      How to Write and Maintain an Effective Changelog
      Publish consistently. Whether you update the changelog weekly, bi-weekly, or with every release, stick to a cadence. Inconsistent publishing trains users to stop checking.
      Write for your users, not for your team. Use plain language that describes the benefit, not the technical change. Lead with the outcome. "You can now filter reports by date range" is better than "Added DateRangeFilter component to ReportView."
      Categorize entries. Group changes into new features, improvements, and bug fixes. This helps users quickly find what is relevant to them. A user looking for a fix to a known issue should not have to read through a list of new features to find it.
      Connect your changelog to your feedback board. Tools like Quackback let you link changelog entries to the original feature requests. When a user sees that a feature they voted for has shipped, they receive a notification. This automated loop keeps users invested in providing feedback because they see the direct results.

- [User Story](https://quackback.io/glossary/user-story): A user story is a short description of a feature written from the end user's perspective, typically following the format "As a [user], I want [goal], so that [benefit]." It captures what a user needs and why, without prescribing how to build it. User stories keep development teams focused on delivering value rather than completing tasks.

What is a User Story?
      A user story is a lightweight way to capture a product requirement from the perspective of the person who will use the feature. The standard format is: "As a [type of user], I want [goal], so that [benefit]." This structure forces you to think about who needs the feature, what they need, and why it matters.
      User stories are not specifications. They are placeholders for a conversation. The story itself is intentionally brief. The detail comes from discussion between the product owner, designers, and developers during backlog grooming and sprint planning.
      Good user stories follow the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, and Testable. A story that meets all six criteria is ready for development. One that does not needs more refinement.

      Why User Stories Matter for Product Teams
      User stories shift the conversation from "what should we build" to "what problem are we solving for the user." This distinction matters. A feature request like "add CSV export" becomes "As a team lead, I want to export my data to CSV, so that I can share weekly reports with stakeholders who do not have login access."
      When stories are grounded in real user feedback, they carry more weight during prioritization. You are not guessing what users want. You have evidence. A story backed by dozens of user requests is harder to deprioritize than one based on an internal hunch.
      User stories also make acceptance criteria easier to define. When you know who the user is and what outcome they expect, you can describe what "done" looks like in concrete terms.

      How to Write Better User Stories
      Start with your feedback data. Review the feature requests your users have submitted. Each request is a candidate for a user story. Look for patterns where multiple users describe the same need in different words.
      Use tools like Quackback to collect and organize feedback by theme. When you can see that 30 users have asked for variations of the same feature, writing the story is straightforward. The users have already told you the "who," "what," and "why."
      Keep stories small. If a story takes more than one sprint to complete, split it. Large stories hide complexity and make estimation unreliable. Break them into vertical slices that each deliver a usable piece of functionality.
      Pair every story with acceptance criteria before it enters a sprint. The criteria define the specific conditions the feature must meet. Without them, developers and product owners may have different definitions of "done."

- [Product-Market Fit](https://quackback.io/glossary/product-market-fit): Product-market fit is the point where a product satisfies strong market demand. It means you have found a group of users who need what you have built and are willing to pay for it, recommend it, or depend on it. Measuring product-market fit requires combining quantitative signals like retention and NPS with qualitative feedback about why users stay or leave.

What is Product-Market Fit?
      Product-market fit is the stage where your product meets a real need in a market large enough to sustain a business. Marc Andreessen described it as "being in a good market with a product that can satisfy that market." You know you have it when users adopt your product without heavy persuasion, retention is strong, and word-of-mouth drives growth.
      The most commonly cited test is Sean Ellis's survey question: "How would you feel if you could no longer use this product?" If 40% or more of users answer "very disappointed," you likely have product-market fit. Below that threshold, you have more work to do.
      Product-market fit is not a one-time achievement. Markets shift, competitors emerge, and user expectations evolve. You need to monitor it continuously through feedback loops and usage data.

      Why It Matters for Product Teams
      Before product-market fit, every investment in growth is premature. Spending on marketing, scaling infrastructure, or expanding the team amplifies a product that users do not yet need. After product-market fit, those investments compound.
      Feedback data is the clearest signal of where you stand. If users consistently request features that extend your product's core use case, that is a sign of fit. If they request features that would turn your product into something fundamentally different, they may not be your target market.
      Teams that track product-market fit over time can detect regression early. A spike in churn, a drop in NPS, or a shift in feedback themes can all indicate that fit is weakening before revenue metrics show it.

      How to Measure and Maintain Product-Market Fit
      Run the Sean Ellis survey regularly. Ask new users after they have had enough time to experience your product's value. Track the percentage of "very disappointed" responses over time.
      Analyze your feedback for sentiment patterns. Tools like Quackback let you see what users are asking for and how they feel about your product. A feedback board full of enhancement requests is healthier than one full of complaints about basic functionality.
      Segment your users. Product-market fit can be strong in one segment and weak in another. Break down your NPS scores and feedback themes by user type, company size, or use case. Double down on the segments where fit is strongest.
      Treat product-market fit as a metric, not a milestone. Review it quarterly alongside retention, engagement, and revenue. When the signals diverge, investigate before they become trends.

- [North Star Metric](https://quackback.io/glossary/north-star-metric): A north star metric is the single metric that best captures the core value your product delivers to customers. It aligns every team around one measurable outcome that reflects real user value, not just business revenue. The right north star metric correlates with long-term growth because it measures whether users are getting what they came for.

What is a North Star Metric?
      A north star metric is a single number that your entire product team rallies around. It captures the moment when users get value from your product. For Spotify, it might be time spent listening. For Slack, it might be messages sent within a team. For an e-commerce platform, it might be completed purchases per active buyer.
      The north star metric is not revenue. Revenue is a lagging indicator that reflects past decisions. The north star metric is a leading indicator that predicts future growth. When users get value, retention improves, word-of-mouth grows, and revenue follows.
      A good north star metric has three properties: it measures value delivered to users, it is a leading indicator of business success, and it is actionable by the product team. If the team cannot directly influence the metric through product decisions, it is the wrong one.

      Why It Matters for Product Teams
      Without a north star metric, teams optimize for different things. Engineering cares about uptime. Marketing cares about signups. Sales cares about deals closed. The north star metric gives everyone a shared definition of success.
      It also helps with prioritization. When you evaluate feature requests, you can ask: will this move the north star metric? If the answer is unclear, the feature probably does not deserve top priority. This creates a consistent filter for backlog decisions.
      Customer feedback helps you validate whether your north star metric reflects real value. If users report high satisfaction but the metric is flat, the metric may be measuring the wrong thing. If the metric is growing but feedback is negative, something is broken.

      How to Find and Track Your North Star Metric
      Start by identifying the core action that signals value delivery. What does a successful user do in your product? Analyze usage patterns and correlate them with retention. The action most predictive of long-term retention is your best candidate.
      Validate the candidate with feedback data. Use tools like Quackback to see what users say about the experience around that core action. If users praise the feature associated with your metric, you are on the right track. If they ignore it, reconsider.
      Break the north star metric into input metrics that different teams can own. If your north star is "weekly active projects," inputs might include new project creation rate, project completion rate, and team invitation rate. Each sub-team optimizes their input.
      Review the metric monthly at a company level. Share trends, highlight wins, and discuss risks. The north star metric works only when the entire organization understands it, trusts it, and acts on it.

- [Acceptance Criteria](https://quackback.io/glossary/acceptance-criteria): Acceptance criteria are the specific conditions that a user story or feature must satisfy to be considered complete. They define the boundaries of a feature in testable terms, ensuring the development team and product owner agree on what "done" means. Well-written acceptance criteria prevent scope creep and reduce rework by making expectations explicit before development begins.

What are Acceptance Criteria?
      Acceptance criteria are a set of conditions that a feature must meet before the team marks it as complete. They answer the question: how will we know this works? Unlike the definition of done, which applies to all work, acceptance criteria are specific to an individual user story or task.
      The most common format is Given-When-Then. "Given I am a logged-in user, when I click the export button, then a CSV file downloads containing my project data." This format makes criteria unambiguous and testable.
      Acceptance criteria are not a design specification. They describe what the feature should accomplish, not how it should look or be implemented. This gives the development team room to choose the best technical approach while still meeting the stated requirements.

      Why Acceptance Criteria Matter for Product Teams
      Without acceptance criteria, every team member carries a different mental model of what the feature should do. Developers build based on assumptions. QA does not know what to test. The product owner rejects work that meets the developer's interpretation but not theirs. This cycle wastes time and erodes trust.
      Acceptance criteria also create a direct link between user feedback and delivered features. When a user requests a capability, the acceptance criteria should reflect the user's stated need. If the criteria are met but the user's problem is not solved, the criteria were wrong, not the implementation.
      Clear criteria make estimation more accurate. Developers can assess complexity based on concrete requirements instead of vague descriptions. Fewer surprises during development means more predictable sprints.

      How to Write Effective Acceptance Criteria
      Start with the original user feedback. If the feature was requested through a tool like Quackback, read the original request and the comments from other users who upvoted it. Their descriptions of the problem are raw material for your criteria.
      Write criteria in plain language. Avoid technical jargon that non-developers cannot parse. The criteria should be understandable by anyone on the team, including designers, QA, and stakeholders.
      Keep the list focused. Three to seven criteria per story is a healthy range. If you have more, the story is probably too large and should be split. Each criterion should be independently testable.
      Review criteria with the development team before the sprint starts. They may spot edge cases or technical constraints that change the scope. This conversation is cheaper during grooming than during development.

- [Continuous Discovery](https://quackback.io/glossary/continuous-discovery): Continuous discovery is the practice of regularly talking to users and incorporating their feedback into product decisions, rather than doing research only at the start of a project. It involves weekly customer touchpoints, structured opportunity mapping, and rapid assumption testing. The goal is to maintain a constant flow of user insight that informs every sprint.

What is Continuous Discovery?
      Continuous discovery is a mindset and set of practices for staying connected to your users throughout the product development cycle. Teresa Torres coined the term "continuous discovery habits" to describe a structured approach: talk to customers every week, map opportunities visually, and test assumptions before committing to solutions.
      Traditional product research happens in phases. A team conducts interviews at the beginning of a project, writes a requirements document, and then builds for months without further user input. Continuous discovery replaces this with an ongoing loop where research and delivery happen in parallel.
      The core activities are weekly user interviews, opportunity solution trees for mapping the problem space, and small experiments to validate assumptions. None of these require large budgets or dedicated research teams. Any product team can adopt them.

      Why Continuous Discovery Matters for Product Teams
      Products fail when teams lose touch with their users. The longer the gap between user conversations and development decisions, the greater the risk of building the wrong thing. Continuous discovery closes that gap by making user insight part of every week.
      It also improves prioritization quality. When you hear from users regularly, you develop an intuition for what matters most. That intuition, combined with quantitative data from feedback tools, makes backlog decisions faster and more accurate.
      Teams that practice continuous discovery spend less time debating opinions in meetings. Instead of arguing about what users want, they reference recent conversations and data. Evidence replaces speculation.

      How to Build a Continuous Discovery Practice
      Start by scheduling one user interview per week. You do not need a formal research plan. Pick a user who recently submitted feedback or made a purchase and ask them about their experience. Even fifteen minutes yields useful insight.
      Set up a feedback collection system that runs without manual effort. Tools like Quackback let users submit requests, vote on ideas, and leave comments at any time. This creates a passive stream of discovery data that supplements your active interviews.
      Build an opportunity solution tree. Place your desired outcome at the top, user opportunities in the middle, and potential solutions at the bottom. Update it weekly based on new interview insights and feedback trends. This keeps your team aligned on the problem space.
      Test assumptions before building features. If a solution idea requires a major development investment, find the cheapest way to learn whether it will work first. A prototype, a landing page test, or a concierge experiment can validate demand in days instead of months.

- [Product Strategy](https://quackback.io/glossary/product-strategy): Product strategy is the high-level plan that connects your product vision to execution. It defines who your target users are, what problems you solve for them, how you differentiate from competitors, and what outcomes you aim to achieve. A strong product strategy turns user feedback and market insight into a focused roadmap instead of a scattered list of features.

What is Product Strategy?
      Product strategy is the set of choices that guide what your product will and will not do. It sits between the product vision (the long-term aspiration) and the product roadmap (the near-term plan). Without strategy, the vision stays abstract and the roadmap becomes a disconnected wish list.
      A product strategy typically answers four questions: Who are your target users? What problem do you solve better than anyone else? How do you win against alternatives? What outcomes will you measure to know you are succeeding?
      Strategy is about saying no. Every feature request, market opportunity, and stakeholder demand competes for limited resources. Strategy gives you a framework for deciding which ones align with your direction and which ones do not.

      Why Product Strategy Matters for Product Teams
      Without a strategy, product decisions default to whoever speaks loudest. The sales team pushes for enterprise features. Support pushes for bug fixes. Executives push for shiny new capabilities. A clear strategy gives the product team authority to prioritize based on evidence and direction.
      Strategy also aligns cross-functional teams. When engineering, design, marketing, and sales all understand the strategic focus, they make better independent decisions. Engineers choose architectures that support the strategic direction. Marketing messages the right value propositions.
      User feedback is the reality check for any strategy. If your strategy says you serve mid-market SaaS companies but your feedback is dominated by enterprise requests, either your strategy or your positioning needs to change. Feedback data keeps strategy honest.

      How to Build and Execute a Product Strategy
      Start with user research. Review your feedback data to understand who your most successful users are and what they value. Tools like Quackback show you which features generate the most demand and which user segments are most engaged.
      Define your strategic pillars. These are the three to five themes that will guide your roadmap for the next year. Each pillar should connect to a measurable outcome. "Reduce onboarding friction" is a pillar. "Build a dashboard" is a feature.
      Translate pillars into a roadmap. Each quarter, select the initiatives that best advance your strategic pillars. Use your north star metric and user feedback to validate that you are investing in the right areas.
      Communicate the strategy broadly and revisit it regularly. Share it with the entire company so everyone understands the direction. Review it quarterly against your feedback data and market conditions. Strategy is not static. It evolves as you learn.

- [Value Hypothesis](https://quackback.io/glossary/value-hypothesis): A value hypothesis is a testable assumption about why customers will use your product. It states the specific value a user will receive and the evidence that would prove or disprove it. Validating the value hypothesis early prevents teams from building products that work technically but fail to solve a real problem users care about.

What is a Value Hypothesis?
      A value hypothesis is a statement about the value your product will deliver to users. It typically follows this structure: "We believe [target users] will [use this product/feature] because [it delivers this value]." The hypothesis is not a wish. It is a claim that can be tested with evidence.
      Eric Ries introduced the concept in The Lean Startup alongside the growth hypothesis. The value hypothesis asks whether the product delivers value to users. The growth hypothesis asks how new users will discover the product. Both need validation, but the value hypothesis comes first.
      A value hypothesis forces you to be specific about who benefits and how. "Users will love this feature" is not a hypothesis. "Product managers who receive more than 50 feature requests per month will use automated categorization to save two hours per week on triage" is a hypothesis you can test.

      Why Value Hypotheses Matter for Product Teams
      Most product failures are not engineering failures. They are value failures. The team builds something that works but nobody needs. A value hypothesis makes the risk explicit before you invest development resources.
      Value hypotheses also improve team alignment. When the hypothesis is written down, everyone on the team understands what success looks like. Designers design for the stated value. Engineers architect for the stated use case. QA tests against the stated outcome.
      User feedback is the primary tool for validating value hypotheses. If your hypothesis says users will adopt a feature because it saves time, and your feedback shows users ignoring it or requesting something different, the hypothesis is invalidated. That is not failure. That is learning.

      How to Test a Value Hypothesis
      Write the hypothesis before building anything. Be explicit about the target user, the expected behavior, and the value they will receive. Include a falsification criterion: what evidence would prove this hypothesis wrong?
      Run the cheapest experiment that generates useful evidence. Before building a full feature, test the hypothesis with a prototype, a survey, or a concierge MVP. Ask users directly whether the proposed value resonates with them.
      Use your feedback tool to gather validation data. With Quackback, you can post a proposed feature and let users vote on it before you build it. High vote counts and supportive comments are evidence that the value hypothesis has merit. Silence or negative feedback is evidence that it does not.
      Track outcomes after launch. The value hypothesis is not fully validated until users are actually experiencing the promised value in production. Monitor adoption, retention, and feedback for the feature. If the metrics support the hypothesis, invest further. If they do not, pivot.

- [Customer Experience](https://quackback.io/glossary/customer-experience): Customer experience (CX) is the total perception a customer forms about a brand based on every interaction across the entire relationship. It spans marketing, sales, onboarding, product usage, and support. CX is shaped by both deliberate design choices and the gaps between them. Companies that treat CX as a system rather than a department consistently outperform on retention and growth.

What is Customer Experience?
      Customer experience is the sum of every interaction a person has with your company. It starts before the first purchase and extends well beyond it. CX includes the clarity of your pricing page, the speed of your onboarding, the reliability of your product, and the helpfulness of your support team.
      CX is not the same as customer service. Customer service is one touchpoint within the broader experience. A company can have excellent support agents but still deliver a poor overall experience if the product is frustrating to use or the billing process is confusing.
      The best CX programs treat every customer interaction as a data point. They measure sentiment, track effort, and identify patterns that reveal where the experience breaks down.

      Why It Matters for Product Teams
      Product teams own a large share of the customer experience. The features you build, the bugs you fix, and the workflows you design all shape how customers perceive your product. Every release either improves or degrades CX.
      Feedback is the most direct signal you have about customer experience. When users submit feature requests, report bugs, or vote on ideas, they are telling you exactly where the experience falls short. Teams that systematically collect and act on this feedback close experience gaps faster than teams that rely on intuition.
      CX also affects acquisition. Satisfied customers refer others. Dissatisfied customers share their frustrations publicly. Your product decisions ripple outward through word of mouth and review sites.

      How to Apply Customer Experience
      Start by mapping the customer journey from first touch to ongoing usage. Identify the moments that matter most: onboarding, first value, upgrade, and support interactions. Measure satisfaction at each stage.
      Use a feedback tool like Quackback to collect input directly from users at every stage. Feature requests reveal unmet needs. Bug reports highlight friction points. Vote counts show you which improvements would move the needle for the most people.
      Connect your feedback data to product decisions. When you prioritize a feature, tie it back to a CX gap. When you ship a fix, notify the users who reported it. This creates a feedback loop where customers see that their input drives real changes.
      Review CX metrics regularly. Track trends in satisfaction scores, feedback volume by category, and the ratio of new requests to resolved ones. Improvements in these metrics confirm that your product decisions are improving the overall experience.

- [Customer Retention](https://quackback.io/glossary/customer-retention): Customer retention is the ability of a company to keep its existing customers over a given period. It measures how many customers continue using and paying for a product rather than leaving for a competitor or canceling entirely. Retention is driven by product value, customer experience, and the ongoing match between what users need and what you deliver.

What is Customer Retention?
      Customer retention measures the percentage of customers who stay with your product over time. A company that starts the quarter with 1,000 customers and ends with 950 has a 95% retention rate. The inverse of retention is churn.
      Retention is not just about preventing cancellations. It includes expanding usage within existing accounts, increasing engagement, and deepening the relationship between the customer and the product. A retained customer who barely uses the product is still at risk.
      For SaaS companies, retention is the single most important growth metric. Acquiring a new customer costs five to seven times more than keeping an existing one. Small improvements in retention compound into significant revenue gains over time.

      Why It Matters for Product Teams
      Product teams have more influence over retention than any other function. The features you build, the bugs you tolerate, and the experience you design determine whether users stay or leave. Marketing brings customers in. Product keeps them.
      Feedback-driven product development is the highest-leverage retention strategy. When you build what users ask for, they stay. When you ignore their requests, they look for alternatives. It is that direct.
      Retention problems often appear as patterns in feedback data long before they show up in churn numbers. A spike in complaints about a specific workflow is an early warning sign. Teams that monitor feedback trends can intervene before users leave.

      How to Apply Customer Retention
      Measure retention cohort by cohort. Track how different groups of customers behave over their first 30, 60, and 90 days. Look for drop-off points that indicate where the experience fails.
      Connect your retention data to your feedback data. Use Quackback to see which feature requests come from your most engaged customers versus those at risk of churning. Prioritize the requests that protect your highest-value accounts.
      Close the loop with customers. When you ship a feature that was requested, notify the people who asked for it. This reinforces the relationship and demonstrates that you listen. It turns a transactional product into a partnership.
      Build a retention review into your sprint cadence. Each cycle, review which shipped features addressed retention risks and which open requests remain unresolved. This keeps retention visible as a product priority rather than a metric someone else owns.

- [Churn Rate](https://quackback.io/glossary/churn-rate): Churn rate is the percentage of customers who stop using a product or cancel their subscription within a given time period. It is calculated by dividing the number of customers lost during the period by the number at the start. A high churn rate signals product-market fit problems, unmet user needs, or competitive pressure that requires immediate attention.

What is Churn Rate?
      Churn rate measures customer attrition. If you start the month with 500 customers and lose 25, your monthly churn rate is 5%. The formula is simple: customers lost divided by customers at the start of the period, expressed as a percentage.
      There are two types of churn. Voluntary churn happens when customers actively cancel. Involuntary churn happens when payments fail or accounts expire without renewal. Both matter, but they require different interventions.
      For subscription businesses, even small changes in churn rate have outsized effects on revenue. Reducing monthly churn from 5% to 4% does not sound dramatic, but it significantly extends average customer lifetime and increases lifetime value.

      Why It Matters for Product Teams
      Churn is the clearest signal that your product is not meeting expectations. Every churned customer represents a failure to deliver enough value to justify continued use. Product teams need to treat churn as a feedback mechanism, not just a finance metric.
      The most common product-related churn drivers are missing features, poor usability, unresolved bugs, and failure to keep pace with competitors. All of these are visible in customer feedback before they become churn events. A user who requests a feature three times and gets no response is already on the path to leaving.
      Reducing churn is almost always more valuable than increasing acquisition. A product that retains well can grow efficiently. A product with high churn is filling a leaking bucket.

      How to Apply Churn Rate
      Calculate your churn rate monthly and track the trend. A rising churn rate demands investigation. A stable or declining rate confirms that product investments are working.
      Segment your churn data. Look at which customer types churn most, at what stage in their lifecycle, and after which events. This reveals patterns that aggregate numbers hide.
      Cross-reference churn with feedback. Use Quackback to see whether churned customers had unresolved feature requests or bug reports. If the same issues appear repeatedly among former customers, those are your highest-priority fixes.
      Run exit surveys or cancellation feedback flows to capture the reason behind each departure. Combine this qualitative data with your quantitative churn metrics to build a complete picture of why customers leave and what you can do about it.

- [Knowledge Base](https://quackback.io/glossary/knowledge-base): A knowledge base is a self-service library of articles, guides, FAQs, and documentation that helps users solve problems without contacting support. It reduces support ticket volume, speeds up resolution for common issues, and improves the overall customer experience. An effective knowledge base is searchable, well-organized, and continuously updated based on real user questions.

What is a Knowledge Base?
      A knowledge base is a centralized collection of help content. It typically includes how-to articles, troubleshooting guides, FAQs, video tutorials, and API documentation. Users access it through a help center, an in-app widget, or search engines.
      Knowledge bases serve two audiences. External knowledge bases help customers find answers on their own. Internal knowledge bases help support agents resolve tickets faster by providing standard responses and procedures.
      The best knowledge bases are living documents. They evolve based on what users actually search for, which articles get the most views, and which support tickets keep recurring despite existing documentation.

      Why It Matters for Product Teams
      A well-maintained knowledge base reduces the volume of repetitive support tickets. This frees up support teams to focus on complex issues and frees up product teams from being pulled into support escalations.
      Knowledge base analytics reveal product usability problems. If an article about a specific workflow gets thousands of views, that workflow is probably confusing. The most-read help articles are a map of your product's friction points.
      Product teams should treat knowledge base gaps as feedback signals. When support agents repeatedly answer questions that have no documentation, those gaps indicate either missing help content or product design that needs simplification.

      How to Apply Knowledge Base
      Audit your support tickets to identify the most common questions. Write articles that address the top twenty recurring issues. This alone can deflect a meaningful percentage of incoming tickets.
      Structure your knowledge base around user tasks, not product features. Users search for "how to export data," not "export module documentation." Organize content by what people are trying to accomplish.
      Use feedback data from Quackback to identify topics that need documentation. When users submit requests or questions through your feedback boards, check whether a help article could address the need. Sometimes the answer is better documentation rather than a new feature.
      Measure effectiveness by tracking deflection rate, article helpfulness ratings, and the percentage of support tickets that could have been self-served. Update articles based on user feedback and changing product functionality.

- [Self-Service](https://quackback.io/glossary/self-service): Self-service is the practice of enabling customers to find answers, resolve issues, and complete tasks without human assistance. It includes knowledge bases, FAQ pages, community forums, in-app help widgets, and automated troubleshooting flows. Effective self-service reduces support costs, improves response times, and gives users the autonomy they prefer.

What is Self-Service?
      Self-service means giving users the tools and information to help themselves. Instead of submitting a ticket and waiting for a reply, a customer can search a knowledge base, browse a community forum, watch a tutorial, or use an in-app guide to solve their problem immediately.
      Research consistently shows that most customers prefer self-service over contacting support. They want answers now, not in four to eight business hours. Self-service meets that expectation when the content is comprehensive and easy to find.
      Self-service is not a replacement for human support. It handles the predictable, repetitive questions so that human agents can focus on complex, high-value interactions that require judgment and empathy.

      Why It Matters for Product Teams
      Self-service success depends heavily on product design. If your product is intuitive, users need less help. If workflows are confusing, no amount of documentation compensates for poor UX. Product teams should view high self-service usage as both a success metric and a diagnostic tool.
      Self-service content also generates valuable data. Search queries reveal what users struggle with. Article bounce rates indicate content gaps. Failed searches point to terminology mismatches between your product and your users' mental models.
      Product teams benefit directly when self-service works well. Fewer support escalations means fewer interruptions. Fewer "how do I do X" tickets means the team can focus on building new capabilities instead of explaining existing ones.

      How to Apply Self-Service
      Start with the data you already have. Pull your top support ticket categories and create help content for each one. Prioritize by volume. The goal is to deflect the most common questions first.
      Make self-service discoverable. Embed help links in your product where users are most likely to get stuck. Context-sensitive help that appears at the right moment is far more effective than a standalone help center.
      Use Quackback to collect feedback on your self-service experience. Let users report when an article did not answer their question or suggest topics that need coverage. This turns your help content into a continuously improving resource driven by real user needs.
      Measure self-service effectiveness with deflection rate, search success rate, and time-to-resolution. Compare these against support ticket trends to confirm that self-service investments are actually reducing the load on your team.

- [Help Desk](https://quackback.io/glossary/help-desk): A help desk is a system for managing, tracking, and resolving customer support requests. It provides a centralized inbox where support agents receive tickets, assign them, track status, and measure performance. Modern help desks integrate with product tools so that support conversations inform feature prioritization and bug fixes.

What is a Help Desk?
      A help desk is software that organizes customer support interactions into a manageable workflow. Customers submit requests via email, chat, web forms, or social media. The help desk converts those requests into tickets, routes them to the right agents, and tracks them through to resolution.
      Core help desk features include ticket management, agent assignment, priority levels, canned responses, and reporting dashboards. More advanced systems add automation rules, SLA tracking, customer satisfaction surveys, and integrations with other business tools.
      The help desk serves as the front line of customer communication. Every ticket is a data point about your product, your documentation, and your user experience.

      Why It Matters for Product Teams
      Help desk data is a goldmine for product teams. Support tickets reveal bugs that automated testing missed, workflows that confuse users, and features that customers expect but do not have. Ignoring this data means ignoring a direct line to user pain.
      The most effective product teams have a structured process for routing relevant support insights to the product backlog. Not every ticket becomes a feature request, but patterns in ticket volume and categories should influence prioritization.
      Help desk metrics also provide a proxy measure for product quality. A spike in tickets after a release suggests a regression. A steady decline in tickets about a specific area confirms that recent improvements are working.

      How to Apply Help Desk
      Set up a feedback pipeline from your help desk to your product team. Tag tickets by product area and issue type. Generate weekly or bi-weekly reports that surface the top themes.
      Connect your help desk data with your feedback collection. When a support conversation reveals a feature gap, create a corresponding entry in Quackback so other users can vote on it. This converts individual complaints into visible product demand.
      Use help desk analytics to measure the impact of product changes. After shipping a fix for a commonly reported issue, track whether ticket volume for that category drops. This closes the loop between product work and support outcomes.
      Train support agents to distinguish between issues that need a support response and issues that need a product change. Clear escalation paths ensure that product-relevant feedback reaches the people who can act on it.

- [SLA (Service Level Agreement)](https://quackback.io/glossary/service-level-agreement): A service level agreement (SLA) is a commitment that defines the expected level of service a company will provide, including response times, resolution targets, and uptime guarantees. SLAs set measurable standards for support quality and create accountability between the company and its customers. They are common in B2B and enterprise contracts.

What is a Service Level Agreement?
      A service level agreement is a formal or informal commitment about the quality and timeliness of service a customer can expect. In support contexts, SLAs typically define first response time (how quickly a customer hears back), resolution time (how quickly the issue is fully resolved), and availability (uptime percentage).
      SLAs can be external (promised to customers in contracts) or internal (targets the team sets for itself). External SLAs often carry financial penalties for violations. Internal SLAs drive operational discipline without contractual consequences.
      Common SLA tiers are based on issue severity. A critical production outage might have a 15-minute response target. A minor UI issue might have a 24-hour target. The severity definitions and corresponding targets should be documented and agreed upon.

      Why It Matters for Product Teams
      Product quality directly affects SLA performance. A buggy release generates more tickets, which strains response times. A reliable product with clear documentation keeps ticket volume low, making SLA targets easier to hit.
      When support consistently breaches SLAs for a specific product area, that is a signal to the product team. It means users are hitting problems faster than support can resolve them. The fix is not just more agents. It is a better product.
      SLA data also helps product teams prioritize bug fixes. A bug that triggers SLA breaches in enterprise accounts has a measurable business cost. This makes the case for prioritizing the fix over new feature work concrete and defensible.

      How to Apply SLA (Service Level Agreement)
      Define SLA tiers that match your customer segments and product complexity. Do not promise response times your team cannot sustain. Start conservative and tighten targets as your processes mature.
      Monitor SLA compliance by product area. Use your help desk reporting to identify which features or workflows generate the most SLA-threatening tickets. Share this data with your product team as input for prioritization.
      Use Quackback to track the feature requests and bug reports that originate from SLA breaches. When a pattern emerges where the same issue causes repeated SLA violations, escalate it as a product priority. This connects support operations to product planning with concrete data.
      Review SLA performance after every product release. Track whether new features or fixes improve or degrade support metrics. This feedback loop helps the team understand the real-world impact of their work on customers and on the support team.

- [First Response Time](https://quackback.io/glossary/first-response-time): First response time (FRT) is the duration between a customer submitting a support request and receiving the first meaningful reply from a human agent. It is one of the most important support metrics because it directly affects customer satisfaction. Faster first responses signal that a company values its customers, even when the full resolution takes longer.

What is First Response Time?
      First response time measures how long a customer waits after submitting a request before they get a reply. The clock starts when the ticket is created and stops when an agent sends the first substantive response. Automated acknowledgments ("We received your request") typically do not count.
      FRT is measured in minutes, hours, or days depending on the support channel and company norms. Live chat benchmarks are under two minutes. Email support benchmarks range from one to four hours for B2B SaaS. Social media expectations fall somewhere in between.
      FRT matters because it sets the tone for the entire support interaction. A fast first response builds confidence. A slow one creates frustration that colors the rest of the experience, even if the resolution is excellent.

      Why It Matters for Product Teams
      Product teams affect first response time more than they realize. A product with clear UX and good documentation generates fewer tickets, which means agents have more capacity to respond quickly. A confusing product floods the queue and pushes FRT up.
      When FRT spikes after a release, it usually means the release introduced confusion or bugs that users cannot resolve on their own. Product teams should monitor FRT alongside their own release metrics as an early indicator of quality issues.
      Product decisions can also directly improve FRT. Better in-app guidance, clearer error messages, and more intuitive workflows all prevent tickets from being created in the first place. The fastest response is the one the customer never needed.

      How to Apply First Response Time
      Track FRT by channel, severity, and product area. Aggregate numbers hide important details. You might hit your overall target while customers with critical issues wait too long.
      Identify which product areas generate the most tickets with slow response times. These are candidates for product improvements that would reduce support load. Share this data with your team as part of regular prioritization discussions.
      Use Quackback to capture feedback about specific product pain points before they become support tickets. When users can submit feedback and track its status through a public board, they feel heard even without a support interaction. This reduces ticket volume and gives agents more time to respond quickly to genuine support needs.
      Set FRT targets by ticket priority and review them monthly. If you consistently miss targets for a specific category, investigate whether the root cause is a staffing issue, a process issue, or a product issue. Often it is the product.

- [Customer Advisory Board](https://quackback.io/glossary/customer-advisory-board): A customer advisory board (CAB) is a selected group of customers who provide strategic feedback on product direction, market trends, and company decisions. Unlike open feedback channels, a CAB offers curated, in-depth input from your most engaged or representative customers. It builds stronger relationships while giving the product team high-quality directional signals.

What is a Customer Advisory Board?
      A customer advisory board is a formal group of customers invited to share feedback, validate product direction, and discuss industry trends with your team. CABs typically include 10 to 20 members who represent different segments, use cases, or company sizes.
      CAB members meet quarterly or semi-annually, either in person or virtually. Sessions are structured around specific topics: upcoming features, market shifts, competitive dynamics, or strategic priorities. The goal is candid conversation, not sales pitches.
      CABs differ from focus groups. Focus groups are one-time research events. Advisory boards are ongoing relationships that deepen over time. Members develop context about your product and roadmap, which makes their feedback more informed and actionable.

      Why It Matters for Product Teams
      Open feedback channels capture volume. Advisory boards capture depth. A CAB member can explain the business context behind a feature request in a way that a one-line submission cannot. Both signals are valuable, and they serve different purposes.
      CABs also help validate roadmap decisions before you commit resources. Presenting a proposed direction to a group of experienced customers reveals blind spots, surfaces objections, and sometimes confirms that you are on the right track. This is cheaper than building the wrong thing.
      The relationship itself has value. CAB members become advocates. They feel invested in your product's success because they helped shape it. This translates into stronger retention, higher willingness to reference, and organic word-of-mouth.

      How to Apply Customer Advisory Board
      Select members who represent your core segments. Include a mix of power users, newer customers, and different company sizes. Avoid stacking the board with only your happiest customers. You need honest feedback, not validation.
      Prepare structured agendas for each meeting. Share context about the topics in advance so members arrive with informed opinions. Leave time for open discussion, but keep the session focused on decisions you actually need input on.
      Combine CAB insights with broad feedback data. Use Quackback to collect feedback from your entire user base, then bring the top themes to your advisory board for deeper exploration. The board adds qualitative depth to the quantitative signals your feedback tool provides.
      Follow up after every session. Share what you heard, what you plan to do about it, and what changed as a result. CAB members who see their input reflected in the product stay engaged. Members who feel ignored stop attending.

- [Closed-Loop Feedback](https://quackback.io/glossary/closed-loop-feedback): Closed-loop feedback is the practice of following up with customers after they provide feedback to let them know what action was taken. It completes the feedback cycle by connecting input to outcome. Most companies collect feedback. Few close the loop. Teams that do see higher satisfaction, stronger retention, and more willingness from customers to share future input.

What is Closed-Loop Feedback?
      Closed-loop feedback means that when a customer gives you input, you eventually tell them what happened as a result. If they reported a bug, you let them know when it is fixed. If they requested a feature, you notify them when it ships. If you decided not to build something, you explain why.
      The "loop" has three stages: collect, act, and communicate. Most teams handle the first two. They gather feedback and make product decisions based on it. The third stage is where the loop breaks. Customers submit feedback and never hear back.
      Closing the loop does not require individual responses to every piece of feedback. It can happen through public changelogs, status updates on feature requests, or automated notifications when a request moves through your pipeline.

      Why It Matters for Product Teams
      Closed-loop feedback directly affects future feedback quality. When customers see that their input led to a real change, they are more likely to provide detailed, thoughtful feedback in the future. When they feel ignored, they stop contributing.
      It also reduces duplicate requests. When users can see that a feature is already planned or in progress, they do not need to submit it again. This saves time for both customers and the team that triages incoming feedback.
      Closing the loop is a retention mechanism. Customers who feel heard are measurably less likely to churn. The act of communicating "we built this because you asked" creates a sense of partnership that no marketing campaign can replicate.

      How to Apply Closed-Loop Feedback
      Start with your highest-impact channel. If you have a public feedback board, make sure every request has a visible status: under review, planned, in progress, or completed. Status changes should trigger notifications to voters and submitters.
      Publish a changelog that references customer feedback. When you ship a feature, mention that it was requested by your users. Use Quackback to maintain a public changelog that connects releases to the feedback that inspired them. This makes the loop visible to everyone, not just the person who submitted the request.
      Set a process for declining requests. Not every idea will be built. When you decide against a request, update its status and optionally explain the reasoning. Customers respect a clear "no" more than indefinite silence.
      Measure loop closure rate. Track the percentage of feedback items that receive a status update or response within a defined timeframe. Treat unclosed items as a backlog to be worked through, just like your product backlog.


## Optional

- [Contact](https://quackback.io/contact): Sales and support contact information