10 Claude prompts that triage customer feedback weekly in 2026

Customer-feedback triage is the highest-volume, lowest-precision job on a PM's calendar — and the one where modern LLMs deliver the largest single-week gain. Ten Claude prompts plus a bonus anti-confirmation-bias quote-finder replace a 4–6 hour weekly review with a 45-minute chained workflow. Each prompt carries full text, design reasoning, a sample output, and a cadence.

<a href="https://www.anthropic.com/pricing?utm_source=aipromptshub&utm_medium=blog&utm_campaign=feedback-triage-tldr" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold"}}> Try Claude Pro for the chained workflow → </a>

Product teams ingest feedback from six or seven surfaces at once. The Productboard 2024 Product Excellence Report found PMs spend a median of 5.8 hours per week reading raw feedback, yet only 38% of teams report that the synthesis ever influences a roadmap decision. The signal-to-action gap is the problem; volume is not.

Two findings explain the gap. Nielsen Norman Group's qualitative-analysis research shows humans hold roughly 7 ± 2 distinct themes in working memory during a verbatim review — below the 30–60 themes in a typical weekly corpus. Themes outside the working set get rediscovered and never compound into action. The Pendo 2024 Feedback Maturity Benchmark reports the median time from request-appearing to roadmap inclusion is 11 weeks without LLM triage, 2.5 weeks with structured LLM workflows.

Sentiment classification with a modern LLM is now reliable enough to drive triage decisions, and in practice tends to agree with careful human labels far more often than keyword-only systems do — especially on the ambiguous, sarcasm-laden verbatims those systems miss. Anthropic's prompt engineering docs underscore that the reliability comes from structured outputs with explicit confidence flags — the pattern the prompts below use, so low-confidence cases route to a human rather than getting silently misclassified.

The ten prompts treat weekly triage as a pipeline: each does one thing well, accepts a defined input shape, emits a defined output shape that feeds the next. The chain runs against Sonnet 4.5 for high-volume steps and Opus 4.7 for synthesis-heavy steps — see Anthropic's model documentation.

Most teams cluster by feature area, which buries the underlying motivation. JTBD clustering (Christensen, *Competing Against Luck*, 2016) surfaces the progress the customer is trying to make.

**The prompt:**

``` You are a UX researcher clustering one week of product feedback by jobs-to-be-done. INPUT: a list of verbatims, each with source (support | nps | churn | review | in-product) and a customer segment if known. OUTPUT (JSON): { "clusters": [ { "job": "<one sentence in the form: When I __, I want to __ so I can __>", "verbatim_count": <number>, "segments_represented": [<list>], "sources_represented": [<list>], "representative_quote": "<verbatim, exact text>", "underlying_progress": "<the customer's broader goal — 1 sentence>" } ], "unclustered_count": <number>, "unclustered_reason": "<why the leftovers did not fit>" } Rules: - A cluster requires at least 3 verbatims with the same underlying progress. - The "job" field must follow the When/I want/so I can structure exactly. - Do not invent verbatims; the representative_quote must appear in the input verbatim. - The unclustered set is not a failure — name what they have in common, or say "no common pattern". ```

**Why it works:** The three-verbatim minimum prevents single-loud-customer clusters. The exact JTBD sentence structure forces synthesis past surface description. The "do not invent verbatims" rule is the load-bearing guardrail against quote hallucination — a failure mode flagged in Anthropic's tool use guidance.

**Sample output:** 200 verbatims cluster into 8 jobs. Largest cluster: *"When I onboard a new teammate, I want to grant scoped access without exposing billing, so I can keep procurement off my plate."* — 27 verbatims, 4 segments.

**When to use:** Every Monday morning on the prior week's corpus. Feeds prompts #2, #4, #7.

Raw positive/negative/neutral scores aren't enough when downstream action is "escalate to leadership." A confidence flag lets the reviewer skip 80% of the corpus and concentrate on the ambiguous 20%.

**The prompt:**

``` You are a sentiment analyst classifying product feedback verbatims. INPUT: a list of verbatims with source and customer segment. For each verbatim, output: { "verbatim": "<exact text>", "sentiment": "strongly_positive | positive | mixed | negative | strongly_negative", "confidence": "high | medium | low", "sentiment_drivers": [<list of 1-3 phrases lifted verbatim from the text>], "why_low_confidence": "<one sentence, or 'n/a' if confidence is high>", "sarcasm_suspected": true | false } Rules: - Confidence is "low" if the verbatim contains sarcasm cues, mixed signals in a single sentence, or fewer than 6 words of substantive content. - The sentiment_drivers must be exact substrings of the verbatim — no paraphrasing. - Sarcasm cue list: scare quotes around a positive word, exaggerated punctuation (!!!, ???), "just what I needed" patterns following a complaint. - If sarcasm_suspected is true, confidence cannot be "high". ```

**Why it works:** The explicit sarcasm cue list addresses the most common classifier failure on product feedback — sarcasm and mixed-signal verbatims are where naive sentiment scoring goes wrong most often. The verbatim-substring rule for drivers prevents paraphrase drift.

**Sample output:** 320 verbatims → 187 high-confidence, 96 medium, 37 low. Low-confidence rows route to a 12-minute human review queue; 16 sarcasm-suspected rows go first.

**When to use:** Nightly across new verbatims. Feeds prompts #5 and #9.

Urgent is not the same as negative. A negative verbatim about a longstanding minor annoyance isn't urgent; a positive verbatim hinting at a competitor switch is. This prompt forces the distinction.

**The prompt:**

``` You are a customer-success operator bucketing inbound feedback by urgency. INPUT: a list of verbatims with source, segment, and account ARR if known. For each verbatim, output: { "verbatim": "<exact text>", "urgency": "P0 | P1 | P2 | P3", "urgency_signals": [<list of phrases or facts that drove the rating>], "recommended_route": "exec_escalation | csm_immediate | support_24h | weekly_digest | no_action", "churn_risk_implied": true | false, "competitor_mention": "<competitor name or 'none'>" } Rules: - P0 requires at least one of: cited dollar amount of impact, explicit churn threat, security or compliance breach claim, or executive (VP+/CXO) sender. - P1 requires either churn_risk_implied=true OR competitor_mention != "none". - Do not assign P0 based on tone alone — the signal must be a concrete fact in the verbatim. - "no_action" is a valid recommendation; use it for thanks/praise that does not also surface a request. ```

**Why it works:** Tone-based P0 assignment floods leadership with angry-but-not-urgent verbatims. The concrete-fact gate eliminates the false positives.

**Sample output:** 412 verbatims → 7 P0, 38 P1, 154 P2, 213 P3. P0s route to a Slack channel watched by the on-call CSM; P1s land in the daily CSM digest.

**When to use:** Within 15 minutes of ingestion. P0 routing only works in real time.

The most valuable feature requests often hide inside positive feedback — a happy customer mentions, almost as an aside, the one thing that would have made the workflow perfect. Standard classifiers miss these because the verbatim reads positive.

**The prompt:**

``` You are a product researcher mining positive verbatims for hidden feature requests. INPUT: a list of verbatims previously classified as positive or strongly_positive. For each verbatim, output: { "verbatim": "<exact text>", "hidden_request_present": true | false, "extracted_request": "<the implicit feature request, in the customer's own framing if possible, or 'n/a'>", "request_strength_signal": "explicit_wish | implicit_workaround | aspirational | n/a", "is_existing_backlog_item": "unknown", "why_this_is_hidden": "<one sentence — what made this easy to miss>" } Rules: - Only return hidden_request_present=true if the verbatim contains language like "would be nice", "if only", "the one thing", "I wish", "workaround", "hack", or a description of manual labor the customer is performing around the product. - Do not infer feature requests from generic praise ("love it") or from feedback about existing major features. - The extracted_request must stay close to the customer's framing; do not jump to a solution. ```

**Why it works:** The explicit cue-phrase list is the surface marker for implicit requests in NN/g's qualitative research. Constraining the model to those cues prevents over-extraction.

**Sample output:** From 187 positive verbatims, 19 contain hidden requests. Strongest: *"Love how fast the search is — only wish I could save the filter combinations I use every Monday."* Extracted as *"Save and recall named filter combinations,"* signal: explicit_wish.

**When to use:** Weekly, against the positive subset from prompt #2. Feeds prompt #7.

NPS detractors (0–6) are the highest-information verbatims in any corpus, and the most likely to be reviewed last because they sting. This prompt generates a structured root-cause hypothesis the PM can validate or reject in seconds.

**The prompt:**

``` You are a customer research analyst generating root-cause hypotheses for NPS detractors. INPUT: a list of NPS responses with score (0-6 only), verbatim comment, account tenure in months, segment, and product-usage signal (active | declining | dormant) if known. For each detractor, output: { "score": <0-6>, "verbatim": "<exact text>", "primary_root_cause_hypothesis": "<one sentence — the most likely underlying cause>", "root_cause_category": "onboarding_gap | reliability_issue | missing_feature | pricing_friction | support_experience | product_complexity | competitor_pull | unclear", "secondary_hypothesis": "<alternative cause worth checking>", "falsification_test": "<the one piece of data that would disprove the primary hypothesis>", "confidence": "high | medium | low" } Rules: - Do not assume the cause stated by the customer is the actual root cause; their stated cause is data, not conclusion. - The falsification_test field is mandatory — every hypothesis must be testable. - If the verbatim is empty or vague ("just not for me"), category must be "unclear" and confidence "low". - Do not recommend solutions; the output is diagnostic only. ```

**Why it works:** The falsification_test field — adapted from Karl Popper via *The Lean Startup* — forces every hypothesis to be testable. The "customer-stated cause is data not conclusion" rule prevents rubber-stamping surface complaints.

**Sample output:** 28 detractors → 28 hypotheses. Largest cluster (11 of 28): onboarding_gap, with the falsification test *"If 14-day activation is above 60% for accounts <3 months old, this is wrong."* — a 5-minute PM query.

**When to use:** Weekly against the prior week's detractors. Pair with the dataset that would falsify each hypothesis.

Churn transcripts are dense, often contradictory, and usually read in isolation. This prompt synthesizes across a batch — the patterns no single interview can show.

**The prompt:**

``` You are a research lead synthesizing a batch of churn interview transcripts. INPUT: 4-12 churn interview transcripts. Each transcript has account context (ARR, tenure, segment) and a transcript body. OUTPUT: { "interview_count": <number>, "convergent_themes": [ { "theme": "<short label>", "description": "<one paragraph>", "appears_in_n_interviews": <number>, "representative_quotes": [<2-3 exact quotes from different interviews>] } ], "divergent_signals": [ { "theme": "<short label>", "description": "<one paragraph — what one or two interviews said that contradicts the convergent themes>", "appears_in_n_interviews": <number> } ], "segments_overrepresented": "<which segment dominates the convergent themes>", "what_we_did_not_learn": "<the gap — what these interviews could not tell us>" } Rules: - A convergent theme requires presence in at least 1/3 of the interviews. - The divergent_signals section is mandatory — never claim full agreement across interviews. - Quotes must be exact substrings of the transcript. - The what_we_did_not_learn section is a guard against synthesis overreach. ```

**Why it works:** The mandatory divergent_signals section breaks the consensus-narrative failure mode — the urge to flatten interviews into a tidy story. Christensen's churn-interview method explicitly calls for surfacing cases that don't fit.

**Sample output:** 8 interviews → 3 convergent themes (onboarding-without-CSM, missing SSO, renewal forgotten) plus 2 divergent signals (one customer wanted *more* complexity; one churned via acquisition, unrelated). Overrepresented segment: 10–50 seat accounts.

**When to use:** Month-end, against the month's churn batch.

Feature requests die between identification and specification. This prompt produces a 1-page draft the PM can edit in 20 minutes rather than write from scratch in 90.

**The prompt:**

``` You are a product manager drafting a spec from a clustered feature request. INPUT: - Cluster summary from prompt #1 or extracted_request from prompt #4 - 4-10 representative verbatims - Segments represented - Current workaround the customers describe (if any) OUTPUT: a one-page draft spec with these exact sections: 1. The job (in JTBD form: When I __, I want to __, so I can __) 2. Who is asking (segments and approximate population if known) 3. Today's workaround (what the customers do today) 4. Proposed scope — must-have (3-5 bullets) 5. Proposed scope — explicitly out (2-4 bullets) 6. Open questions (3-5 bullets the PM still needs answered) 7. Success metric (1 leading + 1 lagging) 8. Anti-goals (what we do not want to happen) Rules: - Do not commit to implementation details — this is a draft. - The "explicitly out" section is mandatory; it is the load-bearing scope guard. - Anti-goals must be specific and measurable (e.g., "no increase in p95 dashboard load time"). - Open questions must be questions, not assertions. ```

**Why it works:** The mandatory "explicitly out" and "anti-goals" sections borrow from Shape Up's pitch format (Basecamp, 2019). Specs that survive triage have explicit non-goals; specs that die in scope-creep don't.

**Sample output:** Draft spec for *Saved filter combinations.* Must-have: name, save, recall, share. Out: cross-tenant sharing, scheduled execution, version history. Success: 30% WAU using a saved filter within 4 weeks (leading); 5% reduction in median time-to-insight (lagging).

**When to use:** Within 48 hours of a cluster crossing the act-on threshold (volume + segment fit + revenue-at-stake).

Support debt is the bug that everyone routes to a workaround instead of fixing. Cost is invisible because each individual ticket gets resolved. This prompt makes the pattern visible.

**The prompt:**

``` You are a support operations analyst detecting recurring issues in the support corpus. INPUT: a list of support tickets from the trailing 90 days, each with: ticket_id, subject, body excerpt, resolution_summary, time_to_resolution. OUTPUT: { "recurring_issues": [ { "issue_label": "<short canonical name>", "ticket_count": <number>, "ticket_ids": [<list>], "common_resolution_pattern": "<workaround given each time, if any>", "is_resolved_by_a_workaround": true | false, "median_time_to_resolution_min": <number>, "estimated_support_hours_consumed": <number>, "bug_or_ux_failure": "bug | ux_failure | documentation_gap | ambiguous" } ], "top_3_to_fix_first": [<issue_label list — ranked by support_hours_consumed>], "summary": "<2-3 sentence summary>" } Rules: - Only flag issues with at least 3 tickets in the input. - The is_resolved_by_a_workaround flag is the critical signal — workaround-driven resolutions are the strongest support-debt evidence. - estimated_support_hours_consumed = ticket_count * median_time_to_resolution_min / 60. - Do not collapse genuinely distinct issues into one label; precision over recall. ```

**Why it works:** Workaround-driven resolution is the textbook support-debt fingerprint. Ranking by hours consumed (not ticket count) catches slow-but-frequent issues that count alone misses.

**Sample output:** 90 days of tickets → 6 recurring issues, 3 resolved by workaround. Top issue: *"SAML SSO logout doesn't invalidate the dashboard session — 14 tickets, median 28 minutes, 6.5 support hours in 90 days, classified bug."*

**When to use:** Monthly, trailing 90 days. Feeds the engineering bug-triage meeting.

The PM digest determines whether synthesis influences the roadmap. Most digests are too long, lead with volume not decision, and bury the asks. This prompt produces the version that gets read.

**The prompt:**

``` You are a product analyst drafting the PM weekly feedback digest. INPUT: - JTBD clusters from prompt #1 - Sentiment summary from prompt #2 (counts + low-confidence subset) - P0/P1 routes from prompt #3 - Hidden requests from prompt #4 - NPS root-cause hypotheses from prompt #5 - Support-debt items from prompt #8 (if this is end-of-month) OUTPUT: a digest with this exact structure: - Headline (1 line: the single most important thing this week) - Decisions to make this week (3-5 bullets, each ending with a named owner) - New patterns (2-3 bullets — clusters that grew or appeared) - Hypotheses to test (1-2 bullets — falsification test + owner) - What did NOT happen (1-2 bullets — patterns that stayed flat or shrank, naming them is a signal too) - Skim queue (the low-confidence verbatim count + a link) Rules: - Total length: 400 words or fewer. - Every "decision to make" must have a named owner; if the owner is unknown, write "UNASSIGNED" — do not guess. - The "what did NOT happen" section is mandatory — absence-of-pattern is information. - Do not lead with positive sentiment volume. ```

**Why it works:** The "what did NOT happen" section addresses confirmation bias at the digest level — the failure mode where the digest only reports patterns the author expected. The 400-word ceiling matches the read-the-first-paragraph reality of every executive inbox.

**Sample output:** A 380-word digest. Headline: *"Saved-filter request crossed the act-on threshold (19 hidden + 4 explicit, all enterprise)."* 3 decision bullets with owners. Notably absent: *"Pricing complaints stayed flat at 8 — the feared FLASH30 backlash has not materialized."*

**When to use:** Every Tuesday, against the prior week's outputs from #1–#5 and #8.

Executives don't read the PM digest. They read the 1-pager that reframes it in board language. This prompt produces it.

**The prompt:**

``` You are a chief of staff producing the executive 1-pager from the week's customer feedback. INPUT: - This week's PM digest from prompt #9 - Trailing 4-week sentiment trend - Trailing 4-week NPS - Top 2 P0 escalations - Revenue-at-stake estimate for the top 3 hidden requests (if known) OUTPUT: a 1-pager with this exact structure: - Headline status (one of: trending positive | mixed | trending negative | inflection) - Three things the executive team should know (each: claim + supporting number + so-what) - Two emerging risks (each: risk + leading indicator + owner) - One ask of the executive team (or "no ask this week") - The number that changed the most week-over-week Rules: - Maximum 250 words. - Lead with the honest assessment, not the optimistic one. - Every claim must cite at least one number from the input. - Do not use the word "exciting". - If there is no ask, say so explicitly; do not invent one. ```

**Why it works:** The single-ask pattern with explicit no-ask escape valve borrows from Amazon's six-pager culture — the format that survives is the one that doesn't pad. The honesty-over-optimism rule pushes against the LLM's documented optimism bias (Constitutional AI paper).

**Sample output:** 240-word 1-pager. Status: *mixed.* Three things: NPS held at 38, saved-filter crossed threshold, SSO support-debt accumulating. One ask: *"Approve the SAML logout fix next sprint — 6.5 support hours/90 days, growing."*

**When to use:** Tuesday afternoon after the PM digest is final. Send Wednesday morning.

Every synthesis above can drift into confirmation. The most valuable single prompt in the chain fights the drift.

**The prompt:**

``` You are an adversarial reviewer testing a synthesis claim against the raw verbatim corpus. INPUT: - A specific synthesis claim (one sentence) - The full verbatim corpus the claim was drawn from OUTPUT: { "claim": "<text>", "disconfirming_quotes": [ { "verbatim": "<exact text from the corpus>", "why_it_disconfirms": "<one sentence>", "source": "<source field from input>" } ], "disconfirming_quote_count": <number>, "adjusted_claim": "<the same claim, rewritten with the appropriate caveats — or 'claim holds as written' if there are zero disconfirming quotes>", "confidence_in_adjusted_claim": "high | medium | low" } Rules: - The goal is to find quotes that DISAGREE with the claim, not to confirm it. - Do not paraphrase quotes — exact substrings only. - Return at minimum 1 disconfirming quote if any exist in the corpus. - If the corpus genuinely contains none, the adjusted_claim is "claim holds as written" and confidence is "high". - If the corpus has many disconfirming quotes, the adjusted_claim must materially soften. ```

**Why it works:** This is the literal *"show me a quote that disagrees"* prompt. Disconfirming-evidence search is the cognitive move humans skip most often (Kahneman, *Thinking, Fast and Slow*, 2011) and the move LLMs perform reliably if instructed to. It pays for itself the first time it catches a wrong claim before it reaches the executive 1-pager.

**Sample output:** Claim: *"Customers love the new dashboard speed."* Three disconfirming quotes returned. Adjusted: *"Most customers praise the speed; a minority (3 of 41 mentions) reports the gain comes at the cost of stale data they manually refresh."* Confidence: medium.

**When to use:** Against every load-bearing claim in #9 and #10. Cheap to run; the highest-leverage cognitive guardrail in the chain.

<a href="https://www.anthropic.com/claude?utm_source=aipromptshub&utm_medium=blog&utm_campaign=feedback-triage-bias-prompt" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold",marginTop:"12px"}}> Run this prompt in Claude → </a>

The chain that replaces a 4–6 hour Monday-Tuesday triage with a 45-minute review:

1. **Sunday 8 p.m. (automated).** Run #2 across the week's verbatims. 2. **Monday 7:30 a.m. (automated).** Run #1, #3, #4, #5 in parallel. 3. **Monday 8:00 a.m. (10 min human).** Skim the low-confidence queue and P0 routes; approve or reroute. 4. **Monday 8:15 a.m. (automated).** Run #8 on the first Monday of the month. 5. **Tuesday 8:00 a.m. (automated).** Run #9, then the anti-confirmation-bias quote-finder against every load-bearing claim. 6. **Tuesday 8:15 a.m. (20 min human).** PM reviews the digest, adjusts claims that failed disconfirming check, finalizes owners. 7. **Tuesday 2:00 p.m. (automated → 15 min human).** Run #10, edit, send Wednesday morning.

Cost: 45 minutes of human time plus $3–$6 of token spend at current Sonnet 4.5 / Opus 4.7 pricing per Anthropic's pricing page. Replaces 4–6 hours of weekly review. Prompts #7 and #6 sit outside the weekly chain — #7 runs when a cluster crosses the act-on threshold, #6 runs month-end.

<a href="https://www.anthropic.com/pricing?utm_source=aipromptshub&utm_medium=blog&utm_campaign=feedback-triage-chain" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold",marginTop:"12px"}}> Start the chained workflow on Claude Pro → </a>

### Which Claude model should I use for feedback triage prompts?

Sonnet 4.5 is the default for high-volume per-verbatim classification (#2, #3, #4, #8) — fast, cheap, and reliable on structured classification with explicit confidence flags. Use Opus 4.7 for synthesis-heavy steps (#1, #6, #9, #10) where holding multiple themes in working context matters more than latency. See Anthropic's model selection guide.

### How accurate is Claude at sentiment classification on product feedback?

In practice it agrees with careful human labels far more often than keyword-only systems, and it handles the sarcasm and mixed-signal verbatims those systems consistently miss. The point of the confidence flag in prompt #2 is that you don't have to trust it blindly — ambiguous, low-confidence rows route to human review rather than getting silently misclassified.

### Will Claude hallucinate verbatim quotes?

Yes, unless constrained. Every quote-returning prompt includes an "exact substring of the input" rule. A hallucinated quote attributed to a real customer is the failure mode that destroys trust fastest. The Anthropic prompt engineering docs cover verbatim-grounding in detail.

### Can these prompts replace a human UX researcher?

No. The prompts replace reading and pattern-matching labor; they don't replace judgment about which patterns merit a roadmap response. The researcher validates synthesis claims (especially via the anti-confirmation-bias prompt) and decides which hypotheses to fund tests for — the division of labor NN/g recommends.

### How do I integrate these prompts with Productboard, Pendo, or Zendesk?

All three expose REST APIs that return verbatims in JSON. Pipe JSON into the prompt input shape, run the chain, post outputs back via Productboard notes, Pendo tags, or Zendesk internal notes. The Pendo 2024 benchmark reports teams using structured LLM workflows ship requests 4.4x faster than teams on platform-native AI alone.

### What if my feedback corpus is too large to fit in one Claude call?

Chunk the corpus by source (support, NPS, churn, in-product) and run #1–#5 independently per chunk. Run #9 against merged outputs. Sonnet 4.5's 200K context handles ~1,500–2,000 verbatims per call before chunking is required.

### Are the sample outputs synthesized or real?

Synthesized for illustration. Structure, constraint compliance, and confidence-flag behavior are representative of Sonnet 4.5 outputs with the prompts as written; specific numbers and quotes are illustrative.

- Clayton Christensen et al., *Competing Against Luck* (HarperBusiness, 2016). - Clayton Christensen, Know Your Customers' Jobs to Be Done (HBR, 2016). - Daniel Kahneman, *Thinking, Fast and Slow* (FSG, 2011). - Productboard 2024 Product Excellence Report. - Pendo 2024 Feedback Maturity Benchmark. - NN/g: How to Analyze Qualitative Data. - Anthropic prompt engineering documentation. - Anthropic Constitutional AI paper. - Anthropic model documentation. - Basecamp, *Shape Up* (2019).

---