The safest automation policy is not “publish everything above three stars.” A star rating is useful, but review text can introduce a risk that the rating does not reveal.
Use an approval policy with two lanes: an eligible lane for routine feedback and a review lane for anything that needs judgment. FullReviews supports both: you can set an automatic-reply threshold and require human review for escalations or safety flags.
The eligible lane
Auto-publishing is usually reasonable when all of these are true:
- the review meets your chosen positive star threshold;
- its language is ordinary and non-sensitive;
- it does not name an employee;
- it does not request a refund, threaten legal action, or report a health or safety problem;
- the proposed reply follows the brand’s approved style.
Start with four and five stars only. After a manager reviews enough real examples, decide whether a different threshold is appropriate for the business.
The review lane
Require a person to approve the reply when any of these signals appears:
| Signal | Why it waits |
|---|---|
| Legal threat or refund request | A public reply can create a commitment or escalation risk. |
| Health or safety concern | The business may need to investigate before responding. |
| Aggressive or abusive language | A generic reply can make a difficult exchange worse. |
| Staff member named | The manager may need context and privacy judgment. |
| Low or mixed rating | The response may need a specific service-recovery action. |
| Unusual claim or factual dispute | Do not let a model invent an explanation. |
The first four are product-level safety flags in FullReviews. The last two are good operating rules even if no automated flag catches them perfectly.
Give approvers a small decision tree
When a reply is held, the reviewer should choose one of four actions:
- Edit and publish the draft.
- Replace it with a custom reply.
- Move the conversation offline with a named next step.
- Do not reply publicly.
That avoids a vague “approval inbox” that becomes another backlog.
Write rules that can be audited
Keep the policy in a short document. For each rule, state the trigger, the action, the owner, and the escalation deadline.
| Trigger | Action | Owner | Target |
|---|---|---|---|
| 4–5 stars, no safety flag | Publish on schedule | Automation | Same business day |
| Safety flag | Hold for approval | Manager | Review before publishing |
| 1–3 stars | Draft only | Manager | Reply after checking context |
| Allegation of harm | Stop automation | Owner or specialist | Investigate first |
The target is an internal operating goal, not a promise to reviewers.
Review the policy after launch
For the first two weeks, inspect every reply that published automatically. Record false positives (a reply that should have waited), false negatives (a routine reply held unnecessarily), and recurring edits. Update the threshold, prohibited language, examples, or schedule from that evidence.
See the full automatic-reply setup guide and the tool comparison for the questions to ask before adopting any workflow.