Feedback clustering

Usero groups duplicate and near-duplicate feedback into clusters automatically. When fifteen people report the same broken thing in fifteen different ways, they collapse into one cluster with a count, a severity, and the individual reports behind it. A cluster is the unit you act on: you read it, and you can open a single GitHub pull request that fixes the problem for everyone in it.

• Automatic grouping. Every feedback item, whatever the source (widget, API, imported GitHub issue, email, Slack), is classified and assigned to a cluster of similar reports. You do not run a batch job or maintain a tag taxonomy.
• Classification per item. Before clustering, each report is tagged for category (bug, feature request, praise, complaint), sentiment, an urgency score, and topics. That metadata is what powers the cluster's severity and ranking.
• A draft you read, not an action. Each cluster lists its members with the AI confidence that each one belongs, so a weak match is visible and you can ignore it. The grouping is a first pass at the themes, the same way an AI-authored PR is a first pass at the fix.
• A path to a fix. From a cluster you can open one GitHub pull request scoped to the open reports in it. The PR is a draft you review and merge yourself. Nothing auto-merges.

Clustering runs on its own, with no button to press:

1. Feedback arrives from any connected source and is created in your inbox.
2. It is classified by AI for category, sentiment, urgency, and topics. The classification runs on a flat-rate Claude Code container, not a metered per-token API, so it is on every plan.
3. It is matched to a cluster. Usero compares the meaning of the report against existing clusters and assigns it to the closest one, or starts a new cluster if nothing matches well enough. Matching is by meaning, not keywords, so "export does nothing," "can't download my report," and "CSV is broken" land in the same cluster despite sharing no words.
4. The cluster updates. Its member count, severity, urgency, and last-updated time reflect the new report. A membership records the AI confidence (0 to 100 percent) that the report belongs in that cluster.

New feedback is queued for processing as it comes in, and a periodic batch sweeps up anything still unclustered, so a cluster is usually ready by the time you next open the dashboard. You never trigger a run yourself.

Open a cluster from the dashboard or the insights view to see the full picture:

• Header. The cluster title, its lifecycle state (Active, Addressed, or Reopened), severity, category, an urgency score out of 100, and overall sentiment.
• Metrics. Open versus total reports, resolution progress, momentum over the last seven days (new versus resolved), and when the problem was first reported.
• Lifeline. A timeline of the cluster's history: first seen, PR drafted, PR merged, cleared, and reopened if the issue came back.
• Member table. Every report in the cluster, each with its rating, comment, page, the Match confidence that it belongs here, urgency, status (open or resolved), and date. Sort by confidence to spot weak matches, or by urgency to triage. A low-match row is a hint the grouping may be wrong, treat the confidence as a signal, not a verdict.

The lifecycle state is the at-a-glance signal: Active means open reports remain, Addressed means every report in the cluster has been resolved, and Reopened means a cleared cluster has picked up new reports (the fix did not hold).

A cluster is the natural unit to fix, because one change usually answers every report in it.

1. Make sure GitHub is connected. The cluster's Create PR button is disabled until a repo is selected; see the GitHub integration docs for the install and repo-selection steps.
2. On the cluster page, click Create PR. Usero creates the PR record, scopes the change to the cluster's open reports, and starts generating the fix in the background. You are taken to a status page that updates as it moves from queued to ready.
3. When it is ready, open the pull request on GitHub. The branch is named from the cluster, the body quotes the grouped feedback and links back to the cluster in your dashboard, and the diff is a first pass at the fix.
4. Review the diff like any other PR. Your CI runs on it, your reviewers comment, and you merge it through your own branch protection. Usero never merges for you.

The cluster PR is idempotent: clicking Create PR again returns you to the existing PR rather than opening a second one. After the PR merges, the cluster page offers to mark its open reports resolved and to email the reporters that their feedback was fixed, so you can close the loop in one place.

• GitHub integration (AI pull requests)
• Integrations overview
• Find your clientId