01 / START HERE
A useful way to approach it.
Reviews can raise questions about onboarding, support, and feature expectations. They describe reported experiences from a particular sample. Eight comments are not a representative survey of every customer; a recurring phrase does not establish how frequently a problem occurs across the market.
Use permitted, accessible review material or excerpts you are allowed to share. Remove unnecessary personal details before asking o1 to organize them. Record how you selected the sample and keep each theme connected to its source. This workflow drafts an analysis; it does not scrape restricted platforms, access private records, or prove a competitor's customer satisfaction level.
02 / THE PROCESS
Go from question to next step.
- 01
Define the question and the sample
Choose a specific question such as onboarding expectations for a particular product. Set a transparent collection rule: platform, date range, language, product version where known, and inclusion criteria. Include a range of experiences rather than selecting only complaints. Note what your rule might exclude before drawing any conclusions.
- 02
Prepare traceable, minimal excerpts
Assign each review an identifier and record its source link, date, and relevant excerpt. Preserve enough context to understand the reported experience while removing unnecessary personal information. Respect access restrictions and platform conditions. If you cannot access a review, do not ask the assistant to reconstruct its contents from a headline.
- 03
Build a coding scheme
Start with a few categories such as onboarding, reliability, support, price expectations, and feature fit. Allow one review to have multiple codes and retain an 'unclear' category. Ask for a short explanation for each code. Review a small batch manually before applying the categories to the rest of the sample.
- 04
Compare patterns and exceptions
Count coded mentions only within your collected sample and explain that themes can overlap. Read the strongest examples alongside contrary experiences. Separate a customer's stated issue from your interpretation of its cause. Different versions, use cases, or expectations may explain apparent disagreement, but do not invent those explanations when the review lacks context.
- 05
Translate themes into research questions
Use the ledger to prepare questions for your own customers or a product trial you conduct. A theme such as unclear setup might suggest testing whether your instructions explain prerequisites. Keep the source register and sample limitations with the summary. Avoid publishing a competitor accusation based on ambiguous or unverified review excerpts.
03 / YOUR STARTING POINT
A prompt you can make your own.
Replace the bracketed fields. Add only information you have permission to share. This is a reusable text prompt; it does not run a task from this page.
Analyze these permitted review excerpts: {{reviews}}. Research question: {{question}}. Sampling rule and limits: {{sampling_rule}}. Assign review IDs and code onboarding, support, expectations, and feature fit, allowing overlapping themes and unclear cases. Show source pointer, relevant wording, code, and cautious interpretation. Retain positive and contrary experiences. Any counts must refer only to this sample. Do not infer prevalence among all customers or invent causes. Finish with questions to investigate in our own customer interviews or trial.04 / SEE THE SHAPE OF IT
Illustrative review coding ledger
Fictional excerpts authored to demonstrate coding. They are not real customer reviews or evidence about an existing company.
| Review ID / excerpt | Code | Careful interpretation |
|---|---|---|
| R1: 'I missed the setup prerequisite' | Onboarding | The reviewer reports a missed requirement |
| R2: 'The setup checklist helped me' | Onboarding; positive | Contrary experience worth preserving |
| R3: 'The reply answered half my question' | Support | Unresolved issue; cause is unknown |
| R4: 'I expected a different export' | Expectations; feature fit | Check how the offer describes export |
The ledger identifies questions about setup and expectations while retaining disagreement. It does not turn four authored comments into a satisfaction measurement.
05 / KEEP YOUR JUDGMENT
What to watch before you use it.
Cherry-picking dramatic complaints
A memorable comment can dominate a small sample. Follow the stated collection rule and preserve contrasting experiences.
Counting codes as customers
One review may mention several themes. Explain overlapping counts and avoid making a sample tally look like a customer-wide percentage.
Guessing the root cause
A reported problem does not establish why it happened. Record possible explanations as questions unless the source provides relevant evidence.
06 / THE FINAL PASS
A little review goes a long way.
Your checks stay on this page. They do not approve or run a task.
07 / GOOD QUESTIONS
Before you begin.
How many reviews make a reliable sample?
There is no universal count that makes an opportunistic collection representative. The selection method, coverage, and question matter. Describe the sample honestly and use it to generate questions; do not claim market-wide prevalence just because the count grows.
Should I quote reviews in a public report?
Check permission, platform conditions, and the context of the quote before publication. A working analysis can retain source pointers and concise notes. Do not expose personal details or present an ambiguous complaint as an established fact about the product.
Can sentiment labels replace manual reading?
Labels can organize material, but they can miss mixed opinions, sarcasm, and context. Inspect the underlying excerpts, especially cases driving your conclusion. Keep uncertainty visible and revise the coding scheme when it does not fit the actual comments.