review-analysis

# Review Analysis Turn messy reviews, complaints, and feedback into a short decision memo the team can actually act on. This skill is not just for “summarizing reviews.” Its real job is to help answer: - **What are people repeatedly saying?** - **What problems are actually frequent vs just loud?** - **Is the issue in the product, the messaging, the offer, shipping, or support?** - **What should the team fix first?** - **What can marketing, product, ops, and support each learn from the feedback?** ## Solves Review data is usually noisy and operationally useless in raw form: - hundreds of comments, but no pattern hierarchy; - teams confuse anecdotes with repeat problems; - product issues get mixed with bad expectation-setting; - strengths are underused because nobody clusters positive themes; - support, product, and growth teams all read the same reviews differently; - no one translates feedback into action priorities. Goal: **Turn unstructured feedback into pattern clusters, likely causes, and recommended next steps.** ## Use when Use when the user needs structured insight from customer feedback rather than a raw summary. Typical cases: - summarizing product reviews from marketplaces or app stores; - clustering repeated complaints; - identifying refund / return drivers; - extracting product strengths and buyer-loved features; - separating product quality issues from messaging or expectation mismatch; - turning review data into FAQ, copy, product, or support actions; - preparing a concise report for product, ops, CX, or marketing teams. ## Do not use when Do not use this skill when: - the user only wants sentiment labels with no explanation; - the task is broad social listening across the public web rather than a defined feedback set; - there is too little review data to identify meaningful patterns; - the user wants rigorous statistical causality rather than directional pattern analysis; - the task is support ticket workflow automation rather than insight extraction. ## Inputs Ask for the minimum useful analysis set: - review source(s) - product / service name - review text or feedback sample - date range, if relevant - market / platform, if relevant - whether focus should be on complaints, positives, refunds, retention, or all feedback - any business question to prioritize ## Workflow ### 1. Define the review set Clarify what is being analyzed: - marketplace reviews - app reviews - support complaints - refund / return notes - post-purchase survey responses - social comments collected into a feedback set ### 2. Normalize and cluster the feedback Group feedback into useful buckets, such as: - product quality / defects - expectation mismatch - shipping / logistics - service / support - pricing / value perception - feature gaps - usability / onboarding friction - trust / claim issues - delight drivers / positive strengths ### 3. Identify repeat patterns For each cluster, assess: - frequency - severity - confidence level - likely root cause - which team owns the problem Always distinguish: - **repeat pattern vs loud anecdote** - **product issue vs messaging issue** - **true defect vs wrong customer expectation** ### 4. Translate insight into action Recommend the next step clearly: - fix now - monitor - rewrite messaging - update FAQ - adjust offer or positioning - escalate to product / ops / support ## Output format Return a concise decision-ready report: 1. **Top patterns** - ranked by importance, not just by volume 2. **Evidence snippets** - short representative quotes or examples 3. **Likely root cause** - product / messaging / offer / shipping / support / unclear 4. **Severity / urgency** - high / medium / low, with short explanation 5. **Recommended action** - what should be done next and by whom 6. **Optional positives worth amplifying** - strengths to reuse in copy, PDPs, ads, or FAQs ## Quality bar A strong analysis should: - separate signal from noise; - keep evidence snippets short and representative; - distinguish product issues from expectation-setting issues; - avoid pretending root cause certainty is higher than it is; - identify actionable implications, not just themes; - help a real operator decide what to do next. ## What “better” looks like Good output should make it obvious: - what the main complaints are; - what the hidden strengths are; - which issues are operational vs messaging-driven; - what deserves immediate action; - what can be used to improve copy, FAQ, product decisions, or CX. ## Resources Read `references/output-template.md` for the standard report layout.