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.