Name the brand and the review queue gets triaged before a word is written: which reviews get a public reply, which need private remediation, which must not be answered publicly at all, and which recurring product problem the replies are actually about.
Answering product reviews is one of 700+ pre-built Flows in Juma. Name the brand and the public review surfaces get read first: recent reviews across Trustpilot, Google and the brand's own product pages, the replies the brand has already posted, and each platform's published rules for what a business reply may and may not say.
What comes back is a branded PDF response playbook plus an editable CSV, one row per review. Every review is routed before it is answered: public reply only, public reply plus private remediation, or do not reply publicly and escalate. The escalation bar is printed rather than implied, so an injury, an adverse reaction, a counterfeit claim, a legal threat or a real data incident is pulled out of the queue instead of receiving a cheerful thank-you. Each reply carries its character count next to that platform's cap, and the rule it was checked against. Nothing promises a refund, credit, timeline or policy the brand has not published: where a reply would need one it comes back marked [NEEDS APPROVAL] rather than invented. Then the reviews are read as evidence, with recurring themes counted and split into product fixes, fulfilment fixes and listing-copy fixes with an owning team against each. Strategy, taste and judgment stay human: this is the queue a reputation lead approves, not a posting button.
Some reviews are not writing problems. An injury or physical safety claim, an adverse or allergic reaction, a counterfeit or tampered-goods claim, an explicit legal threat and a genuine data incident all need a named human before anything appears in public, and a friendly public reply under one of them is the outcome that ends up screenshotted. This step applies the bar strictly and hands back only the reviews that leave the reply queue, each with the trigger that pulled it, the team it routes to and the immediate action. Everything that does not meet the bar stays answerable, including complaints about data collection, which get a privacy-approved line rather than silence.
Apply the escalation bar to this queue and show me only the reviews that must not get a public reply, with the trigger, who each one goes to and the immediate action.
A reply that breaks platform policy gets removed, and a pattern of them puts the seller account at risk. The rules are not the same anywhere: Trustpilot bans including personal information and tying any incentive to a review, Amazon bans asking a customer to change or remove one, and published business-reply character caps differ or do not exist at all. This step re-checks every draft against the specific rule it has to clear, names that rule per reply, rewrites the ones that fail, and puts each reply's character count next to that platform's cap so the check is arithmetic rather than a feeling.
Re-check every reply against Trustpilot, Google and Amazon business-reply policy, name the rule each one was checked against, rewrite any reply that fails, and show each reply's character count next to that platform's cap.
Reviews are the cheapest defect report a brand ever receives, and replying to them one at a time throws that away. This step reads the queue as evidence: recurring complaints are grouped into named themes with a count and a share of the queue, and each theme is split by where the fix actually lives. A product fix goes to product quality, a fulfilment fix goes to delivery operations, and a listing-copy fix goes to the team that owns the page, because a complaint that the item runs small is often a dimensions block that never said so. Single-instance complaints sit in a separate watch list so the trend table stays honest.
Roll these reviews up into named themes with counts and shares, split each theme into a product fix, a fulfilment fix or a listing-copy fix, name the team that owns it, and put single-instance complaints in a separate watch list.
Most review queues are mostly positive, and the reply that earns the most is often the one under a five-star review that nobody bothers to write. A five-star reply names what the reviewer liked and adds something useful, a three-star reply answers the specific reservation instead of thanking the reviewer for mixed feelings, and a one-star reply acknowledges the failure without a defence and without inventing a remedy. This step produces the ladder as a rule set the team can hold future replies against: what changes at each rating, what stays constant, and which openings and closings are already used so nothing arrives as the same sentence five times.
Give me the tone ladder for this queue: what changes in the reply at five, four, three, two and one star, what stays constant, and a check that no two replies share an opening clause or a closing call to action.
A complaint that keeps coming back is often the page's fault rather than the product's. When several reviewers say an item runs small, arrives in more boxes than expected or needs a tool that was not mentioned, the cheapest fix is the copy, and it prevents the next batch of reviews rather than answering this one. This step takes every fix classed as listing copy and writes the actual replacement line, named to the page section it belongs in: the dimensions block, the what-is-included list, the care instructions or the delivery module. The result is copy a merchandiser can paste, not a recommendation to write some.
Take the listing-copy fixes and write the replacement lines, each one named to the product page section it goes into and the review theme it answers.
A Juma Project is a shared space where the team stores everything Juma needs to know about a client. Create one project per client, add context as you go, and Juma will use what's relevant every time the team runs a flow. For review replies the payoff is compounding: the voice profile and the theme counts carry from one week to the next, so the second run shows what is trending instead of counting from zero.
Review Response Policy
What the team is already approved to offer in public: the returns window, the replacement policy, the warranty terms, and anything a reply may never mention. This is the file that decides how much of the queue comes back postable. With it in the project, an approved remedy gets written into the reply; without it, every remedy comes back marked [NEEDS APPROVAL] for a human to fill in.
Brand Voice Guide
How the client sounds when they answer a customer in public: greeting, level of formality, the apology language legal has cleared, and what to avoid. Public replies are read by every future shopper on that page, so the voice matters more here than in most channels.
Product and Fulfilment Facts
Dimensions, materials, care instructions, assembly requirements, delivery windows and known supply constraints. These are what a reply cites instead of guessing, and they are what separates a real answer about a mattress firmness rating from a sympathetic paragraph that says nothing.
Each knowledge item takes a one-line description so Juma knows when to reach for it. Keep them plain and specific.
Yes. Name the brand and the URL and the public review surfaces get read directly: recent reviews on Trustpilot, Google and the brand's own product pages, plus the replies the brand has already posted. The playbook states how many reviews were found on each surface, so the sample is visible rather than assumed.
A CSV or an export from a review platform makes the run sharper, because it carries reviews that are not publicly indexed and it covers a period the team chooses. Paste one in and the same triage, policy check and rollup run against the fuller set.
A product description flow writes the listing. This one answers the reviews of it, and then feeds the listing-copy fixes back. The two meet at one point: when several reviewers report the same surprise, the replacement line for the dimensions block or the what-is-included list gets written here and handed to the page.
It is also distinct from a voice-of-customer analysis, which themes internal call quotes for the team to read. Everything in this flow is written to be posted in public under the brand's name, which is why the policy check and the escalation bar exist at all.
No. Nothing gets promised that the brand has not published: no refund, replacement, discount, credit, delivery date or policy outcome. Where a reply genuinely needs one, the draft carries [NEEDS APPROVAL: refund amount] in the reply text so a human decides, and the CSV flags that row.
Add a response policy to the project and the approved remedies get written in properly, which is what turns the marked rows back into postable copy.
Yes. The triage, the policy check, the character arithmetic and the theme rollup do not depend on the product being physical. On a software queue the fix classes land differently: more of the recurring themes resolve to a documentation or onboarding fix than to a fulfilment one, and the listing-copy fixes land on the category page rather than a dimensions block.
The same run works for a marketplace seller, a DTC brand, a retailer with on-site reviews and a SaaS vendor answering G2. Name the platforms and the rules for those platforms get applied.
The team does. Every reply arrives as a draft with its route, its policy rule and its character count attached so a reputation lead can approve or edit quickly, and anything routed to escalate never reaches a public reply at all without a named owner clearing it.
Juma augments the team, it doesn't replace it. The judgment about what a brand owes an unhappy customer stays with the people who own that relationship.
Name the client and their store URL, and Juma audits which collections already have supporting content and which have none, then returns a 90-day e-commerce content strategy with an editable calendar mapped to real collection URLs.
400+ marketing teams trust Juma. ChatGPT, Claude, and Perplexity know why. Ask them.
Ready when you are
Start typing a task and Juma will figure out the rest.
