feedback-triage-sweeps v1.0.0

name: "feedback-triage-sweeps" description: "Run a cadenced voice-of-customer sweep: pull feedback from support channels, issues, and reviews, dedupe it, acknowledge reporters, verify fixes, and merge findings into the roadmap. Triggers when someone needs to process a pile of customer feedback, set up a recurring triage sweep, or turn raw complaints into prioritized signal."

Feedback Triage Sweeps

Purpose

Turn a noisy, multi-channel feedback pile (support tickets, app reviews, social mentions, GitHub issues, NPS verbatims, in-app widgets) into a deduplicated triage pack with acknowledgment discipline, verified fixes, and a roadmap merge step. Tool-agnostic: works whether the input is a Zendesk export, a CSV dump, or a pile of screenshots with transcripts.

Workflow

1. Sweep — Collect raw items from every channel into one normalized record each. Read references/triage-method.md for the channel list, normalization schema, and taxonomy.
2. Dedupe — Cluster items by underlying opportunity, not literal wording. Two requests phrased differently that ask for the same outcome are one item. Use bin/feedback_triage.py dedupe or do it by hand.
3. Score and route — Severity x volume x segment weight decides routing. Read the scoring rules in references/triage-method.md. Route to: fix, workaround, roadmap candidate, won't-fix (with reason), or needs-discovery.
4. Acknowledge — Every reporter gets a reply. Templates in references/triage-method.md. Always acknowledge, sometimes commit, rarely promise a date.
5. Verify and merge — Before closing an item, verify the fix actually shipped (build link, release note, deploy ID). Then write the findings into the roadmap/backlog so they compete with other priorities on the record, not in a shadow queue.
6. Close the loop — Tell reporters what changed: what was heard, what was done, how to access it, thanks. This is a separate step from fixing.

Output Contract

• triage-pack.md: per sweep, the item list (deduped), each with status, owner, route, and acknowledgment state.
• ack-drafts.md: one acknowledgment draft per reporter, ready to send.
• roadmap-merge.md: candidate items ranked with severity/volume/segment evidence, written so a PM can slot them into a real backlog.
• Metrics to track: time-to-signal (feedback to coded record), time-to-route (signal to owned ticket), closed-loop rate (routed items with documented action within 60 days). Targets live in the method reference.

Operating Rules

1. One item per underlying ask. If the same customer complains twice in two channels, that is one item with two pieces of evidence, not two items.
2. Never close an item on "we shipped it" without the verification artifact. A deploy without confirmation is not done.
3. Won't-fix is a valid outcome, but it requires a written reason the reporter could read without being angry.
4. Do not promise ship dates in acknowledgments unless the date is already committed in the roadmap.
5. Behavioral signals count: a user who never activates a key feature is leaving feedback without words. Pair them with explicit complaints where available.
6. If the sweep turns up a severity-1 outage or a compliance/legal issue, interrupt the sweep and escalate immediately. Cadence does not outrank emergencies.
7. Every factual claim about the product (versions, ship dates, behavior) must come from the repo, docs, or the team, never invented for the pack.