# Review Response Ops

Pull newly posted product and store reviews, draft on-brand replies, and flag negative rating patterns for escalation before they damage seller reputation.

## When to use

- New reviews need a timely, on-brand reply across marketplaces or review platforms
- A run of negative ratings on one SKU or store location needs to be surfaced to a human
- Draft replies must be reviewed before posting, or auto-posted only for low-risk cases
- A refund, price change, or catalog edit is requested inside a review and needs gating

## Tools

- `http-get`
- `browser-navigate`
- `browser-extract`
- `http-post`
- `send-message`

## Playbook

1. Pull recent reviews with `http-get` against the review platform's REST API, e.g. GET `https://api.reviewplatform.com/v1/reviews?since=<timestamp>`, using the org's configured host Integration for auth.
2. If the platform has no read API for a given storefront, use `browser-navigate` to open the store's review dashboard page and `browser-extract` to pull review text, rating, reviewer name, and product reference from the rendered page.
3. Group extracted reviews by product SKU or location and compute rolling rating counts to detect a negative pattern (e.g. three or more 1-2 star reviews on the same SKU within 7 days).
4. For each review needing a reply, draft an on-brand response addressing the specific complaint or compliment, matching the org's tone guidelines.
5. Post approved low-risk replies (neutral or positive reviews, no refund/price ask) with `http-post` against the platform's reply endpoint, e.g. POST `https://api.reviewplatform.com/v1/reviews/{id}/reply`.
6. If a negative-pattern threshold is crossed on a SKU or location, use `send-message` to alert the assigned human with the SKU, rating trend, and sample review excerpts.
7. If a review requests a refund, price adjustment, or catalog change above the org-set threshold, do not act — instead create a human-gated approval task and use `send-message` to notify the reviewing human with full context.
8. If any review mentions safety, legal, or health claims about the product, always route to a human via `send-message` regardless of threshold.
9. Log each processed review's outcome (auto-replied, escalated, or gated) so later runs do not re-process the same review.

## Failure modes

- Review platform has no reply API and no reachable web form — stop and hand off to a human via `send-message` rather than guessing at an unsupported action.
- Extracted review text is truncated or ambiguous — do not draft a reply from partial context; re-fetch or escalate.
- A refund or price-change request is misread as a simple complaint — always check review text against the threshold rules before auto-replying, and gate anything ambiguous.
- Duplicate replies get posted because prior processing state wasn't checked — always verify a review hasn't already received a reply before posting.

## Done when

- All new reviews since the last run have either an on-brand reply posted or a logged reason they were skipped
- Any SKU or location crossing the negative-pattern threshold has a human alert sent with supporting detail
- Every refund, price-change, or catalog-write request found in a review is routed through a create-task approval, never executed directly