In this guide
- 1. Receive a manageable stream
- 2. Decide whether a public reply helps
- 3. Track ownership in your existing tool
- 4. Use the appropriate publishing path
- 5. Close the loop with evidence
- 6. App review triage playbook: severity, owner and next action
- 7. Copy a triage card into your ticket or team message
- 8. Worked example: a sign-in complaint becomes support work
Receive a manageable stream
Start with a notification Flow for low-star reviews of one listing. Connect the destination your support team already checks. Star ratings and source scope select the stream; your team classifies the issue after delivery.
Decide whether a public reply helps
An access problem may need a private support conversation. A verified fix may deserve a short public update. A feature request may need acknowledgement without a roadmap promise. Keep passwords and account details out of public responses.
Track ownership in your existing tool
Record the review link, app, issue, owner and next check in the helpdesk or issue tracker. ReviewBot does not automatically assign product action owners or generate a release investigation.
Use the appropriate publishing path
Use the store console for apps you control, or configure the separate eligible Reply-to-Review integration for Slack/Zendesk. ReviewBot replies are a paid per-Flow add-on. A public listing and a working alert connection are not permission to reply.
Close the loop with evidence
When an issue is resolved, confirm the fix, update the internal record and decide whether the public reply needs editing. Review a new sample afterward. Count completed follow-ups, not only alerts received.
App review triage playbook: severity, owner and next action
Use this example policy as a starting point for your support process. Adjust response targets to your staffed hours and incident policy. Your team performs this classification after ReviewBot delivers a review; the product does not assign severity from review text.
| Review describes | Suggested owner | Next action |
|---|---|---|
| App cannot open or core action fails | Support plus engineering | Check reproducibility and existing incidents; link evidence to one issue. |
| Payment or account access problem | Support | Move investigation to private support; keep account details out of public replies. |
| Feature request or usability friction | Product | Record the use case and representative review; avoid promising an unplanned feature. |
| A previously fixed problem | Support | Verify the fix is released before suggesting an update. |
| Praise with no unresolved issue | Community or product | Share selectively; obtain permission before using identifying quotes in marketing. |
Copy a triage card into your ticket or team message
One card should connect the original review, the owner and the next action. Link related reviews to the same issue so repeated reports provide context without becoming duplicate engineering tasks.
Worked example: a sign-in complaint becomes support work
Illustrative review: “After updating, I cannot sign in.” A low-star Flow delivers it to Zendesk. The agent checks for an existing incident, records the review link, and asks the customer to contact private support with troubleshooting details. If engineering confirms a fix, the agent links the released version to the ticket and updates the public response. Neither the diagnosis nor the follow-up is inferred automatically from the review.