Cutover — going live with BetterReviews

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, you land on the Free plan — imports come in, your widget renders those reviews on your storefront, and you can moderate and change settings. What doesn’t happen before cutover: no review request emails go out and no weekly digest lands in your inbox. That’s deliberate: nothing customer-facing is sent on your behalf until you say so.

Cutover is the single explicit action that takes you from that state to live. It is not a billing gate — cutover works the same on the Free plan as on a paid one, and it never asks you to approve a charge. 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 missing prerequisite, 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 source platform collection.

   If you imported from Okendo / Judge.me / Yotpo / Loox / Feefo, 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. You are not asked to subscribe or approve a charge at any point — on the Free plan, requests go out with the classic review form, and shoppers get the AI chat until your first 50 AI conversations are used.

   One thing can interrupt this step. If we have no way to reach you — no notification recipient, no legacy support address, and no store owner email on file — turning collection on is blocked until you add one (see Managing notification recipients).

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

One more check before you uninstall the old app entirely: verify your Google stars. Run a few product pages through Google’s Rich Results Test and confirm the stars read from the BetterReviews widget. On a white-glove migration we run this check for you and tell you when it passes. Keep the old app installed until it does.

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). Sending starts at a low daily cap and grows as your real send volume grows — capacity is earned by healthy sending, not by waiting, so a store with steady low volume keeps a steady cap.
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.

AI review analysis is not part of cutover — it runs on every plan, from the moment reviews arrive.

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. (Turning collection off doesn’t cancel your subscription — to do that, see Cancelling your plan.) 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. It works on every plan, Free included, and can be turned on and off freely.

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

• 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” — add a customer-facing reply-to email before cutting over. New stores can set it inline during onboarding (the Start collecting step); otherwise it comes from your Shopify customer-facing Sender email (Settings → Notifications).
• 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.
• 422 “Add a notification email so we can reach you about reviews and customer support requests” — we have no verified notification recipient, no legacy support address, and no store owner email for your shop, so review-moderation pings and customer support forwards would go nowhere. Add one under Settings → Notifications (see Managing notification recipients), then cut over. The same 422 applies to turning collection on from Collect → Review collection.

FAQ

Does cutover send retroactive emails for old orders? No. The cohort we build respects your trigger event and delay days, and reaches back only as far as your delay window or your delivery-fallback window, whichever is longer — 14 days on the default settings (7-day delay, 14-day fallback). Orders whose trigger fired before that are marked skipped instead of queued. On very high-volume stores the scan is also bounded to your most recently updated orders, so the oldest end of that window may not be included.

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.