Ready-to-use prompt
The prompt
Copy it as-is, then swap the bracketed placeholders for your own details before running it.
Role: You are a customer insight analyst working for an ecommerce team.
Context:
- Product: {{product_name}}
- Review text, including ratings where available: {{reviews}}
- Current product page claims: {{current_claims}}
- Return reasons if available: {{return_reasons}}
Task: Produce:
1. Praise themes, ranked by how often they appear, each with the count and two verbatim quotes
2. Complaint themes, ranked the same way, each with the count and two verbatim quotes
3. For every complaint theme, classify it as PRODUCT PROBLEM, EXPECTATION PROBLEM or LOGISTICS PROBLEM, with a one-line justification
4. Expectation problems mapped to the exact page claim that created them
5. Praise themes that are missing from the current page copy
6. A prioritised action list: copy change, product change, imagery change or policy change, each with the theme it addresses
Rules:
- Quote verbatim, never clean up or paraphrase a customer quote.
- Give approximate counts and state that they are approximate.
- Do not invent a theme that fewer than two reviews support, list singletons separately under OUTLIERS.
- Never soften a complaint theme.
Finish with: the single change that would remove the most complaints, and the evidence.Estimated results
Editor's note
Why this prompt matters
Customer reviews mix product performance, delivery failures and promises the product page did not keep. Reading them sequentially can leave your team reacting to the angriest reviewer rather than the most repeated, addressable problem. This prompt turns that mixed evidence into a ranked report for merchandising, product and CX teams.
Start with reviews for one product or clearly identified variant. Supply the page claims customers actually encountered, not just today's revised copy, and add return reasons if available. Keep review IDs and ratings attached so someone can trace each finding back to its source. Remove personal information before uploading.
The useful distinction is between changing the product and changing what shoppers expect from it. A leaking closure may need engineering work; a capacity misunderstanding may need clearer imagery. Neither diagnosis should be assumed from sentiment alone. Use the report to select changes worth investigating, then validate the leading recommendation against the underlying reviews and operational evidence.
Anatomy
Prompt engineering breakdown
Role
Evidence-focused customer analyst.
Context
Reviews anchored to claims and returns.
Goal
Prioritised, traceable product actions.
Constraints
Verbatim quotes, approximate counts, separate outliers.
Output format
Ranked themes, classifications and actions.
Why this structure works
Separates observations from proposed interventions.
What you'll get
Expected output
Worked example: a reusable lunch container
Consider a hypothetical seven-review sample, not a real customer dataset. Two reviewers praise cleaning, two describe leakage, two mention late arrival and one reports a cracked hinge. The supplied page claims include “Leakproof in any position” but say nothing about cleaning.
The report should show separate ranked praise and complaint lists. These illustrative excerpts demonstrate the required evidence format; production quotes must come directly from your supplied reviews.
| Theme | Approximate review count | Two verbatim quotes | |---|---:|---| | Praise: easy cleaning | 2 | “Sauce rinses straight off.” / “No scrubbing needed after lunch.” | | Complaint: leaks when tipped | 2 | “Soup leaked when it tipped over.” / “Fine upright, but it leaked sideways in my bag.” | | Complaint: late arrival | 2 | “Arrived three days after the delivery estimate.” / “Delivery missed the promised date.” |
The hinge complaint belongs under OUTLIERS, with its single supporting review, rather than becoming a ranked theme. All counts should be labelled approximate and count distinct reviews, not repeated mentions within one review.
Classification and actions
Leakage is provisionally a PRODUCT PROBLEM: reported performance contradicts the supplied promise. Engineering must establish whether the closure is defective or the promise exceeds intended performance. If upright-only use is confirmed, classify the mismatch as an EXPECTATION PROBLEM, mapped to the exact claim “Leakproof in any position.” Late arrival is a LOGISTICS PROBLEM, requiring delivery evidence rather than a container redesign.
Prioritise investigating the leakage promise and verifying closure performance. Correct unsupported copy immediately; add orientation imagery only if testing supports that restriction. Next, investigate delivery promises and carrier records. Finally, consider adding substantiated cleaning praise to the page.
The closing recommendation should identify one best-supported change, acknowledge tied counts here, and avoid claiming a proven reduction in complaints.
Under the hood
Why this prompt works
The Role frames the model as an analyst rather than a copywriter, making evidence and classification more important than persuasive language. Context connects {{product_name}} and {{reviews}} with {{current_claims}} and {{return_reasons}}. That comparison helps distinguish a reported failure from a mismatch between the offer and the customer's understanding.
The Task separates praise, complaints, claim mapping and actions so the answer cannot stop at a sentiment summary. Ranking exposes repetition; the classification gives teams a starting point for ownership without pretending that reviews establish root cause.
The Rules preserve uncomfortable evidence. Verbatim quotations remain auditable, approximate counts signal uncertainty, and the two-review threshold prevents isolated anecdotes from becoming established themes. OUTLIERS still deserve inspection, especially for safety concerns. The final single-change recommendation forces prioritisation, but its evidence should remain visible: review frequency alone cannot establish implementation cost, severity or likely impact.
Model fit
Best AI models for this prompt
ChatGPT
Useful for iterative theme reconciliation. Check quoted text against review IDs before requesting copy changes.
Claude
Useful for close reading of ambiguous complaints. Require explicit uncertainty where classification depends on missing specifications.
Gemini
A practical primary choice for large review files within available context limits. Verify coverage and reconcile chunk-level counts.
Grok
Useful for exploring competing interpretations of blunt customer language. Disable outside research where available; keep conclusions grounded in supplied reviews.
When to use
- Before rewriting a product page.
- During recurring SKU performance reviews.
- After a packaging or specification change.
- When return reasons need qualitative context.
When not to use
- Unredacted personal information is present.
- Safety complaints require specialist investigation.
- Too few reviews support recurring themes.
- Live order tracing is needed.
Get more from it
Pro tips
- 1
Retain stable review IDs.
- 2
Separate variants before counting.
- 3
Include every available rating band.
- 4
Keep returns and reviews separate.
- 5
Reconcile overlapping chunks by ID.
- 6
Verify quotation reuse permissions.
Don't ship this
Common mistakes
✗ Counting mentions as reviews.
Fix — Deduplicate within each theme.
✗ Inventing a triggering claim.
Fix — Mark unsupported mappings unresolved.
✗ Editing testimonial grammar.
Fix — Preserve the original wording.
People also ask
Frequently asked questions
Q.How many reviews do I need for this to be useful?
Around thirty as a floor, and it gets substantially better above a hundred. Below thirty you should simply read them; a model adds nothing except the risk of inventing a theme from two data points.
Q.What is an expectation problem?
A complaint caused by what your page promised rather than by the product itself. Those are fixed by editing a sentence, which makes them the cheapest returns reduction available to most stores.
Q.Can I use the quotes on my product page?
Usually yes for reviews left on your own store, subject to your terms and local rules. Keep them verbatim and attributed as your platform requires — edited quotes stop being evidence.