PlaysbyMoat8
Back to the library
The workflow guideProduct & Engineering

Convert product reviews into a weekly action digest

Collect new product reviews and surface recurring problems, valued features, and requests that product owners can investigate.

5 implementation stepsIntermediate

How this works

Collect new product reviews and surface recurring problems, valued features, and requests that product owners can investigate. Use this to summarize new product reviews into themes that product owners can investigate. The digest should preserve sample size, duplicate handling and the difference between customer sentiment and verified technical problems.

Collect a dated review snapshot, calculate rating statistics with explicit denominators, and group praise, problems and requests. Retain representative evidence and translation caveats. Connect findings to owners and product metrics without treating a review sample as the full customer population.

Before you start

Review sources

Choose permitted stores, forms or review platforms and a fixed window.

Product taxonomy

Obtain feature areas and routing owners.

Rating rules

Define averaging, edited reviews and duplicate treatment.

Prepare the inputs

reviews
Required

ID, date, rating, text, locale and product version

Retain original text and distinguish new from edited reviews.

reporting_window
Required

start, end and timezone

Use one consistent cutoff.

routing_map
Required

topic and responsible product area

Unknown topics remain unassigned.

product_metrics
Required

optional comparable operational indicators

Do not infer causation from coincident trends.

Implementation, step by step

  1. Collect and reconcile

    • Import reviews and record source coverage and unavailable channels.
    • Deduplicate repeated records and preserve edits as versions.

    Checkpoint: The weekly sample is defined.

  2. Calculate rating measures

    • Compute counts, average and distribution using deterministic arithmetic.
    • Show the denominator and avoid comparing incompatible rating scales.

    Checkpoint: The numerical summary is reproducible.

  3. Group qualitative evidence

    • Classify praise, problems and feature requests by underlying topic.
    • Retain representative and contradictory examples, checking translations where needed.

    Checkpoint: Themes remain grounded in original reviews.

  4. Route investigation items

    • Connect recurring or severe issues to relevant product owners.
    • Separate customer-reported symptoms from verified root causes.

    Checkpoint: The digest has useful next questions.

  5. Review and publish status

    • Check counts, examples and prior follow-ups before preparing the final draft.
    • Track owner responses without automatically creating roadmap commitments.

    Checkpoint: The weekly brief includes coverage and open actions.

Decisions along the way

One user edits a review repeatedly

Count according to the approved rule and retain the latest versus prior text.

Translation is uncertain

Keep the original and flag the theme for review.

A severe issue appears once

Surface it with its limited evidence rather than hide it behind frequency.

What you will produce

weekly-review-digest.md

Markdown

An evidence-linked product review brief.

Include: rating_summary · praise · problems · requests · evidence · coverage

review-followups.csv

CSV

A queue for investigation and follow-up.

Include: theme · review_ids · owner · question · status

Check the result

  • Recalculate average ratings and denominators.
  • Verify representative examples match their themes.
  • Check duplicates and edited reviews are handled consistently.
  • Confirm no symptom is labeled a proven technical cause without evidence.

When something goes wrong

Source export is incomplete

State missing coverage and avoid a complete-week claim.

Rating scale changes

Separate the series or normalize only with an explicit rule.

Theme classifier merges unrelated complaints

Split the cluster and recount unique records.

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Request

Synthetic: summarize five new reviews.

Inputs

Ratings are 5, 4, 4, 2 and 1. Two low-rating reviews describe login trouble, but one is a duplicate export of the same review ID.

Expected result

Synthetic result: deduplicate first, calculate the rating from the remaining unique records and report one or two login observations according to actual IDs. Do not average five rows blindly.

Run a small pilot

Start small

Produce two weekly digests for one product and a fixed source set.

Record the baseline

Record analysis time and theme or counting corrections.

Agree success criteria

Agree rating accuracy and evidence quality before routine distribution.

Stop or revise

Stop trend claims when source coverage changes without a comparable basis.

Keep the scope clear

  • Review sentiment does not establish customer-wide prevalence or root cause.
  • The digest informs product investigation rather than automatically setting priorities.

Check before using

Check sample size, duplicates, translation, and rating calculation. Review sentiment alone cannot establish prevalence or technical root cause.

Business activities

  • Coordinate meetings and follow-ups
  • Plan products and business changes

Editorially adapted workflow; not independently tested.

FROM A RECIPE TO YOUR WORKFLOW

Bring the company context together.

This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.

For this recipe: Permitted review sources · Reporting window · Product ownership map

Start with one recurring task, agree which sources to use, and review the first result with your team.

Discuss this workflow

What does your team do?

Choose the recurring work you would like to improve.

A field guide, made for work.

Plays is a curated library of anonymized business workflows. Each recipe explains the inputs, steps, tools, and checks you can adapt to your team. These are editorial guides, not independently tested implementations.

When you share a company website, the guide may read a limited number of public pages on that website. Messages and retrieved page text are sent to our AI provider, NVIDIA, to recommend relevant workflows. Share a general description rather than confidential information.

Saved workflows and selected activities stay in this browser. Your chat history and selected company website are kept in this tab and cleared when you reload or start a new chat. The server does not store conversations. Live source monitoring is not enabled.

If you allow analytics, PostHog receives page views and actions such as workflow saves, skill downloads and link clicks. Random browser and session identifiers connect these actions without identifying you by name. Your choice and browser identifier expire after 90 days; sessions restart after 30 minutes of inactivity or 24 hours. We use local storage, not analytics cookies. Messages, company URLs, search text, full referrers and IP addresses are not sent. There are no person profiles or session recordings. You can decline or withdraw in Analytics settings; Do Not Track and Global Privacy Control keep analytics off.

Read the Plays Privacy Notice ↗