Cutover — going live with BetterReviews

Last updated: May 23, 2026

This page uses “cutover” as the noun (matching the URL slug and the in-app audit log). UI labels like Turn on BetterReviews and Confirm — turn it on are rendered verbatim in bold where they refer to specific buttons.

What cutover does

When you install BetterReviews, the app runs in evaluation mode — imports come in, you can try the chat, and you can browse your library, but no review request emails go out and no weekly digest lands in your inbox. That’s deliberate: you should be able to evaluate the tool on your own time without sending a single customer-facing email.

Cutover is the single explicit action that takes you from evaluation mode to live. One click flips two flags atomically:

  • collection_enabled: false → true — schedules new review request emails based on your /collect settings.
  • digest_enabled: false → true — opts you in to the weekly summary email.

Both flags flip in the same database transaction. If anything fails (a billing check, a network glitch), neither flips — you don’t get a half- cut-over state where collection is on but the digest is silent.

Before you cut over

The /cutover page is a 4-item checklist. Three items are blocking; one is optional and lives below the checklist.

  1. Disable your old review platform’s collection. If you imported from Okendo / Judge.me / Yotpo / Loox, turn off review-request email sending on the source platform first. Otherwise customers may get duplicate emails. The checklist links to platform-specific instructions based on what we detected in your imported library.

  2. Switch remaining product pages to the BetterReviews widget. The checklist’s Open theme editor button drops you into Shopify’s theme editor with the BetterReviews app block pre-selected. Add it wherever your old platform’s block sits, and remove the old block.

  3. Turn on BetterReviews. Click the primary CTA, review the cohort preview in the modal (queued count, first send time, daily cap), then click Confirm — turn it on. The page reloads to the success state.

  4. (Optional, below the checklist) Connect Slack for weekly digests. This is post-cutover work — connecting Slack later doesn’t affect the cutover itself.

What flips

  • review_settings.collection_enabled → true
  • review_settings.digest_enabled → true

A row lands in platform.settings_audit_log with actor merchant:<store_id>:cutover so the cutover intent is recognizable in forensics even after subsequent settings changes.

What does NOT flip

  • Auto-moderation preset. If you have it set to manual (the default), it stays manual after cutover. To change the preset, visit /collect and use the auto-moderation modal there.
  • Theme colors, brand voice, customer reply-to email. These are separate settings that cutover doesn’t touch.
  • Your imported reviews. Cutover affects future emails and the digest. Imported reviews remain available as before.
  • require_marketing_consent. New stores default to false (transactional treatment — review-request emails go to every customer, not just marketing-opted-in ones; matches Klaviyo / Loox / Okendo industry practice). Cutover doesn’t touch this setting. If your legal team requires the stricter SUBSCRIBED-only rule, flip the Require marketing consent toggle in Collect → Request audience. See Marketing consent for the regulatory rationale.

What happens at flip

  1. The cohort warmup state initializes (if not already provisioned by an earlier /collect enable). New stores start with a daily cap of 50 review-request emails, ramping up automatically over the first 2 weeks.
  2. The EnableCollectionWorker Oban job enqueues. It paginates your recent Shopify orders and builds the queue of review-request emails based on your trigger event and delay days settings.
  3. The first send lands no earlier than the time shown in the modal’s “First send” line, throttled by your daily cap.
  4. The next weekly digest will include your store going forward.

Reversing cutover

There’s no “cut back” button by design — cutover is meant to be a one-way commitment. To pause sending, use Collect → Review collection to flip collection_enabled off. A confirmation modal shows how many pending requests will be cancelled; click Disable collection to confirm. That bulk-cancels every pending review-request email and stops new ones from scheduling.

The weekly digest can be toggled independently from /collect settings without going through /cutover again.

Partial cutover

If you previously flipped collection_enabled on via /collect but never turned on the digest, the /cutover page detects this and shows an info banner — “Collection is already on. One step left.” Only the digest flips when you confirm; the cohort already exists from the prior flip, and we don’t re-paginate Shopify or re-enqueue emails (which would risk double-sending).

Troubleshooting

  • 402 “Your subscription isn’t active” — you can’t cut over with a cancelled, frozen, or pending subscription. Visit /billing to reactivate.
  • 409 “BetterReviews is already live for this store” — both flags are already on. Refresh the page; you should see the success state.
  • 422 “Set a reply-to email” — visit your Settings → Support tab in the BetterReviews admin and add a reply-to email before cutting over.
  • 422 “We couldn’t read your store timezone” — this is rare; it means Shopify didn’t return a timezone for your shop on connect. Reach out to support@betterreviews.app and we’ll fix it.

FAQ

Does cutover send retroactive emails for old orders? No. The cohort the EnableCollectionWorker builds respects your trigger event + delay days + a 90-day recency cap. Orders that already fulfilled more than ~90 days ago are marked skipped instead of queued.

Does cutover touch my imported reviews? No. Imports remain exactly as they were. Cutover only changes future behavior.

What if I refresh the page during confirmation? You’re safe. The two-step server confirm uses two distinct routes — the preview-fetch route never writes, and the commit route requires its own POST. Refreshing the page (or double-submitting the form) cannot accidentally trigger a cutover.

Can my team flip cutover without me knowing? The cutover writes a merchant:<store_id>:cutover audit row. If you have founder-dashboard access you can see who triggered each cutover event.