ReviewFold
Guide · Prioritisation
How to decide which app review complaints to investigate first
Forty complaints and one engineer is a scheduling problem, not a research problem. The useful output is not a ranked list of themes — it is one sentence saying what you will check next, and why that check is worth an hour.
01 · The wrong signal
Stars measure disappointment, not damage.
A one-star review can be a blocked workflow or a bad week for the reviewer. A three-star review can describe a bug that quietly loses data. Sorting by rating puts the second case below the first, every time.
Ratings are asked for at an emotional moment and answered in one tap. They are a reliable signal that something happened and an unreliable signal about what. The text under the rating is where the task is described, and that text is what you are actually triaging.
A working rule
Ignore the star until you have read the sentence. If the sentence does not name something the person was trying to do, it is not triageable yet — it is a mood. Set it aside rather than ranking it.
This is also why “how many people mentioned it” is a poor first sort. Volume tells you how many people bothered to write, which is shaped by prompts, release timing and store ranking as much as by the defect itself.
02 · The unit of triage
Rewrite each complaint as the task it blocked.
Themes are grouped by wording, and wording is not the same as work. Two themes can be one blocked task; one theme can hide three.
Take the review and finish this sentence: “this person was trying to ______ and could not.” If you cannot finish it, you do not yet know what to investigate — you know what they were angry about.
-
01
Write the task in verb form
“Export a report to email” is a task. “Sync is broken” is a symptom you have not located yet. The verb form tells you which part of the product to open.
-
02
Mark whether the task was blocked or slowed
Blocked means there was no way through. Slowed means there was a workaround the reviewer found or guessed. Blocked tasks usually outrank slowed ones, whatever the tone of the review.
-
03
Merge reviews that describe the same task
Now the count means something, because it counts tasks rather than adjectives. Ten reviews of one blocked task is a different fact from ten reviews of ten complaints.
03 · Before you believe it
Look for the second mention, then look for the counterexample.
One review is an anecdote. Two independent reviews of the same blocked task in the same sample is a fact worth an hour. A counterexample is what stops you from over-reading either.
A counterexample is a review that describes the same task working, or a detail that contradicts the first account — a different device, a different plan, a different store, an older version. Finding one does not kill the issue. It changes what you would test.
Worth writing down
- The second, independent mention of the same task
- Version, device or region when the reviewer states it
- A workaround someone invented under pressure
- A review that says the same task worked
Not evidence, whatever the tone
- Five reviews from one person, edited and reposted
- Anger with no task named
- “Everyone I know says…” with no detail
- Complaints about a build that is no longer current
Note the date on every review you quote. A blocked task from eight months ago is history; if it is still blocking people today, you should be able to find a recent mention, and if you cannot, that itself is the finding.
04 · Data you already own
Add what support and crash reports already know.
Reviews tell you what people chose to write in public. They say nothing about how many people were affected, or how often the attempt failed.
Before ranking anything, check the internal sources that answer the question cheaply: support tickets tagged with the same task, crash or error aggregates by version, and the release notes for the build in question. A single support ticket with steps to reproduce can outrank forty reviews.
Two things to record when you find them: whether the task failure is reproducible (can someone on the team trigger it on demand), and whether the impact is known (a number you can cite) or unknown (a gap you are choosing to accept for now). Writing “unknown” is more useful than inventing a percentage.
The trap
Review counts look like impact and are not. If the only number you have is “how many reviews mentioned it”, say so in the sheet and treat the ranking as provisional.
05 · The output
End with the next check, not the fix.
Choosing what to fix requires cost estimates you do not have yet. Choosing what to check requires an hour and a hypothesis.
For each task still on your list, write one sentence of the form: “I will check ______, and if ______ is true, this moves up.” That sentence is falsifiable, cheap, and it survives being handed to someone else — which a priority score does not.
- Check reproduction: can we trigger it on the current build, on the device in the review?Cheapest check, strongest signal. Do this first when the reviewer gave a device or version.
- Check the funnel: does the relevant step show a drop that matches the complaint window?Connects a review to behaviour without claiming causation.
- Check support: are there tickets describing the same task, in the same period?A second, independent channel is worth more than another review.
- Check the release: did anything change in that area, including pricing, copy or permissions?Many “bugs” are a changed default nobody announced.
If none of these checks would change your plan, the item is not a priority problem. It is a decision you are avoiding, and no ranking method will resolve it.
06 · The artefact
One row per blocked task, six columns.
This is a sheet you fill in by hand, not a feature of any tool — including ours. Keep it in whatever your team already opens; the point is that the reasoning is written down where a colleague can disagree with it.
| Blocked task | Original review | Repeat evidence | Reproducible | Impact | Next check |
|---|---|---|---|---|---|
| Export a report to email | Quote, date, store | 2 mentions, same week | Not tried yet | Unknown | Trigger on 4.2, iPhone 14 |
The first row shows what a filled entry looks like; the others are blank. “Impact: unknown” is a legitimate entry. If you cannot fill the last column, the row is not ready to be ranked. On a phone, the sheet scrolls sideways.
Six columns is deliberate. A seventh — priority, score, severity — invites arithmetic that the inputs cannot support. If two rows still look equally urgent after this, that is a conversation for your team, not a formula.
Limits
What this method cannot tell you.
Being explicit about the ceiling is what makes the method usable.
- It cannot size the problemReviews are a biased sample of people who chose to write. Nothing here converts a count into a number of affected users.
- It cannot price the fixKnowing what to investigate is not knowing what it costs to change. That estimate comes from engineering.
- It cannot rank across teamsA blocked onboarding task and a blocked export task are not comparable units, however neatly both fit this sheet.
- It cannot replace a support queueIf support already knows the top three issues, start there and use reviews to fill the gaps.
07 · Fit
When this is the wrong lens.
Use it when
- You have more complaints than capacity
- Reviews are your only public signal
- The list is long but nobody agrees on the top item
- You need to justify what you did not do
Skip it when
- Crashes or data loss are already confirmed
- One enterprise customer is paying for the fix
- You have fewer than five actionable reviews
- The decision is compliance or legal, not priority
This method sits after collection and before planning. If you have not yet gathered a sample to work from, the Google Play analysis method covers the reading step, and the monitoring routine covers how often to look. If the complaint reads like a feature request rather than a defect, the feature-request guide is the better entry point.
Current support, stated plainly
- Apple App Store: US and Canada. Google Play: US.
- Up to 200 recent public reviews per report.
- One app and one region per report; no cross-region merge.
- One tracked app per subscription: daily check, tracking page and a Monday email.
- A report is a snapshot you request, not a live feed.
- No severity scores, priority ranking or automated triage.
- Free preview shows themes and counts; the paid report adds excerpts, PDF and CSV.
Start with the text
Get the reviews behind the themes, then triage.
A report hands you the themes, the counts and the original reviews in one place. The ranking is still your judgement — that part does not automate well, which is why this page is a method rather than a feature.