Email-driven moderation

Last updated: May 13, 2026

When a customer review needs a decision, BetterReviews can email your CS team a notification with action buttons. Your team approves, replies, archives, or rejects directly from the email — no Shopify admin login required. This page covers how it works, how to turn it on, and the safety controls behind it.

This is for stores where a CS lead handles moderation and the founder doesn’t want to be the bottleneck — or for teams where most decisions happen in inbox or Slack rather than in the Shopify admin.

What email-driven moderation does

A review that doesn’t auto-publish (either because you’re on Manual or it scored below your preset threshold) lands in your Inbox stage chip. With email-driven moderation on, the same review also generates a notification email to your configured recipients. Each email shows:

  • The review (rating, body, photos, customer name, submit date)
  • Why it’s here (low rating, flagged for spam, etc.)
  • Buttons: Approve as-is, Approve & reply publicly, Reply privately, Archive

Clicking a button opens a confirmation page where the rep types their work email (constant-time matched against the recipient the notification was sent to) and submits. The review moves to the Emailed to CS stage on your dashboard immediately when the notification fires, and to Published or Archived when the rep confirms.

Screenshot of the notification email — manual capture, drop in here.

How to turn it on

Recipient management lives in the Notifications tab in your BetterReviews admin (Settings → Notifications). The mode toggle, auto-thank-you checkbox, and Invalidate-all panic button still live on the Collect page under “Email moderation.”

Recipients used to live on this page as well; we moved them to Settings → Notifications in May 2026 so the same address can be configured for review moderation AND customer support cascades from one place. The Collect page now only carries the per-store-mode settings.

Order matters — add and verify at least one recipient before flipping the toggle. Recipients have to click their one-time verification email before they’ll actually receive notifications. Without an active recipient, flipping the toggle on does nothing visible.

  1. Add recipients in Notifications — your CS team’s work emails. Each recipient receives a one-time verification email and clicks the link to confirm before they’re active. Cap of 5 active or pending recipients per store. For each recipient, pick which kinds of emails they get (Reviews moderation pings, Customer support cascade, or both — at least one is required).
  2. Enable email moderation — flip the toggle on (Collect → Email moderation). Notifications start firing for new reviews that need human attention.
  3. Choose a mode — Instant sends a notification per pending review (one email per review, deduplicated). Digest only silences per-review sends and is reserved for the upcoming digest worker.
  4. Auto thank-you message — kept on by default. When a rep approves a review from email, the merchant’s standard thank-you DM still fires through Shopify Flow. Turn it off if you want approvals from email to publish silently.

The rep can also skip the thank-you message for a single review by checking the “Skip the thank-you message for this review” box on the approval page — useful when the customer’s review is complaint-toned and a thank-you would feel tone-deaf.

Screenshot of the Collect → Email moderation settings panel — manual capture, drop in here.

How the recipient verification flow works

When you add a recipient email, BetterReviews sends them a one-time verification link with a 7-day expiry. The link opens a “Confirm this inbox” page; clicking the button flips the recipient row to active. Until they confirm, the row is pending verification and they don’t receive review notifications.

If they don’t click within 7 days, the row stays inactive — you can re-send a verification email from the settings panel, or revoke and re-add. Recipients can be revoked at any time without affecting anyone else.

The recipient’s email is stored encrypted at rest. In the admin you see a masked version (s••@msqc.com) so the full address never appears on a session-replay snapshot.

How the email-action confirmation flow works

Each email button is a signed, 24-hour, single-use token bound to:

  • The specific review
  • The merchant store
  • The action (approve / approve_reply / reply_private / archive / reject / mark_spam)
  • The recipient’s email hash

When the rep clicks the button, they land on a confirmation page. The page is GET-only (safe against email scanner prefetch) and shows the review’s content plus a preview of how it’ll appear on the storefront. The rep types their work email — we constant-time match it against the recipient hash baked into the token. If the email matches, the action fires. If not, the page surfaces “this link was sent to a teammate” with a hint of which inbox to use (s••@msqc.com).

The token consumes on success. A second click on the same email link lands on a “Someone on your team got there first” page (or “You already handled this review” if the same rep refreshed after success). No double-actions are possible.

If a teammate leaves or you suspect a phishing attempt, the admin settings panel has a red Invalidate all pending notification links button. One click immediately revokes every in-flight token for your store. New notifications mint new tokens; old emails are dead.

What the four actions do

  • Approve as-is — the review goes live on your widget. Same effect as approving from the dashboard. The standard auto-thank-you DM fires (unless you opted out per-review or globally). The confirmation page after clicking displays a final “Approve & publish” button so you can review before committing.
  • Approve & reply publicly — the rep types a public reply on the confirmation page. The review publishes with the reply attached underneath, attributed to your store name.
  • Reply privately — the rep types a private message that goes to the customer over email. The customer email carries a CAN-SPAM footer with an independent unsubscribe link (clicking it suppresses ONLY future private replies — review-request emails are unaffected). The review moves to On hold so it’s flagged for a follow-up call after the customer responds.
  • Archive — the review is hidden from your storefront but kept in your records. Restorable from the dashboard later.

Spam-flagged variant

When the AI flags a submission as likely spam (burner email, copy-pasted text, no order match), the notification email uses a different button layout: Reject and Mark as spam are surfaced as the primary buttons, since “approving” obvious spam doesn’t make sense and “archive” reads as too soft. The card preview is also dropped on that variant — preview frames prime publication, and the spam case shouldn’t.

The dashboard always carries the full action set regardless of which email variant fired. For normal pending reviews, use the dashboard if you need to Reject or Mark as spam — those aren’t primary email buttons in the non-spam variant.

Stage chips and email-driven flow

On the Reviews tab:

  • Inbox — reviews waiting on you (or your CS team) to action. Spam-flagged rows show a sub-counter (“Inbox 8 · 1 spam”) so junk is visible at a glance.
  • Emailed to CS — reviews that have been emailed to your CS team but aren’t yet handled.
  • Support — the parent chip for the support-routing cascade (reviews that look like a support ticket — refund request, broken item, complaint). Count is the sum of every sub-stage in the support pipeline (see below). Click in to see the substate breakdown as section headers.
  • Stale — needs your call — a subset of Support. These are reviews where the support cascade ran its full course (3 nudges over 9 days, OR the +5 day extension cap was reached) without a rep action. They show as a standalone chip even for digest-disabled merchants so the stalled pile is never invisible.
  • Published / Archived / Rejected — terminal states.

Support pipeline (4 sub-stages)

When the AI flags a review as a support issue, it doesn’t just notify — it runs a 3-stage cascade:

  1. Awaiting CS response — bundled email goes to your CS team’s inbox with three primary buttons: Approve & reply privately, Hold 5 days, Reject.
  2. On hold — if your rep clicks Hold, the review parks for 5 days. At the end of the hold window, a follow-up email lands with Approve / Reject / +5 more days.
  3. +5 days (final extension) — Hold can be extended up to 3 times. The 4th extension request lands as a [Final notice]-prefixed email with “+5 days (final extension)” copy on the button. After this, the row transitions to Stale automatically.
  4. Stale — if no rep ever clicks across the 9-day nudge cascade, the review parks here. Open it in the dashboard to publish, reject, or escalate.

Parent-chip-collapse rule

The Support parent chip shows the TOTAL count across all 4 sub-stages — never sub-counters in the chip header. Drill in to see the substate breakdown as section headers. The Stale chip is intentionally separate (and double-counted within Support) so digest-disabled merchants always have visibility into the cascade-stalled pile.

The dashboard remains the source of truth — you can always click in and moderate from there. Email-driven moderation is additive, not a replacement.

Safety controls

  • Per-recipient resend cap — 3 verification resends per recipient per day, plus 20 per store per day. Prevents accidental verification spam.
  • Append-only audit log — every email action records who clicked what (recipient email hash, not plaintext), when, and from what IP. The audit table is append-only at the database level; not even the merchant can edit it.
  • Suppression-list check — if a recipient’s address is on our hard-bounce or spam-complaint suppression list, notifications are silently dropped and the merchant alert thresholds fire.
  • Two-phase send ledger — Resend retries don’t inflate your 50/day notification ceiling. The ledger only counts successful sends.
  • Token revocation on demand — the Invalidate-all button covers the leave-immediately case. Per-recipient revoke covers the targeted case.

Limits

  • 5 recipients per store (active + pending verification combined).
  • 24-hour token lifetime — links expire and can’t be re-clicked beyond that.
  • 50 per-review notifications per store per day. Above this, additional pending reviews skip the per-review notification but still show in your dashboard Inbox.
  • Email-only for V1. Slack DM notifications and a daily digest variant are on the roadmap.