> ## Documentation Index
> Fetch the complete documentation index at: https://recurr.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# For operations

> Wave cadence, gating sign-offs, support coordination, and the day-to-day rhythm of a migration as it runs.

If you're the operations lead — RevOps, customer success, lifecycle, billing ops, or the role that owns *"how does this actually run on Tuesday at 10am"* — your job during a migration is the connective tissue between Recurr's campaigns and your internal teams.

## What you own day-to-day

<CardGroup cols={2}>
  <Card title="Wave gating sign-off" icon="circle-check">
    Each wave's results land in the dashboard with the next wave's recommendation. You review against the agreed thresholds, sign off, and the next wave ships. \~30 min per wave.
  </Card>

  <Card title="Support coordination" icon="headset">
    Migration emails generate inbound — billing questions, "is this real" questions, occasional cancellation requests. The framework provides response templates; your support owner routes the volume.
  </Card>

  <Card title="Cohort review" icon="users">
    Recurr proposes the cohort spec for each wave. You confirm it matches your read of the segment. Edge cases — opt-outs, comp accounts, internal users — get excluded on your call.
  </Card>

  <Card title="Internal comms" icon="megaphone">
    Heads-up to support, customer success, and any team that touches the subscriber relationship. The framework supplies a wave brief; you adapt it to your internal voice.
  </Card>
</CardGroup>

## What Recurr operates

You don't run:

* **Email cadence + send.** Recurr composes, schedules, and sends every migration email. Your role is review and approve copy at the start of each wave.
* **Campaign analytics.** Open / click / conversion / drop-off — all in the dashboard, no spreadsheets.
* **Cohort selection logic.** Recurr's models propose; your role is sanity-check, not build.
* **Holdout maintenance.** The matched store-billing holdout is selected and managed by Recurr.
* **Wave reports.** Auto-generated post-wave, ready for your gating sign-off.

## Wave rhythm

Each wave moves through four beats:

1. **Cohort + copy proposed** — Recurr drafts the next cohort spec and email copy; your team reviews
2. **Wave kicks off** — emails send through the scheduled window
3. **Conversion accrues** — support manages residual inbound; the dashboard tracks open / click / conversion in real time
4. **Wave report + gating decision** — your team signs off on the next wave, or the program pauses while the cohort spec adjusts

The program runs as 10 weekly waves, each moving roughly 10% of the addressable base in aggregate. Compressible to roughly four weeks on strong performance. If support volume spikes, the next wave can hold while the queue clears.

## How the four phases gate each other

<CardGroup cols={2}>
  <Card title="Audit → Pilot" icon="magnifying-glass">
    The audit (and Migration Review that follows) confirms the opportunity is real and the path is safe. The pilot doesn't kick off until that conversation lands.
  </Card>

  <Card title="Pilot → Migrate" icon="flask">
    Pilot data has to clear pre-agreed thresholds on retention, payback, billing health, and support load before the wider migration begins. If gates breach, the framework adjusts cohort spec or pauses.
  </Card>

  <Card title="Migrate → Compound" icon="diagram-project">
    Each migration wave gates the next on the same thresholds. Compound — new web acquisition layered onto the migrated base — begins as the migrated cohort stabilizes.
  </Card>

  <Card title="Compound — ongoing" icon="arrow-trend-up">
    Web acquisition continues year-over-year; retention safeguards continue to measure against the matched holdout. The book shifts from store-rail dependence to web-rail compound.
  </Card>
</CardGroup>

## Safeguards that run quietly

The framework's operational safeguards run by default without your team operating them:

* **Matched store-billing holdout** — comparison cohort kept on store billing; churn impact is measurable, not assumed.
* **Gated thresholds** — each wave's go/no-go runs on pre-agreed retention, payback, billing-health, and support-volume thresholds.
* **Auto-pause** — if thresholds breach mid-wave, the program pauses; the next wave doesn't ship until cause is understood.
* **Stratified-parallel cohorts** — every cohort starts in week one at a small allocation, and volume ramps wherever benchmarks clear.

You're not responsible for running these — they're the framework's default behavior. Your role is to know they exist when a CFO or customer success lead asks *"what if migration tanks retention?"*

## Escalation paths

If something goes sideways mid-wave:

* **Support spike** — the framework provides response templates; if volume exceeds normal capacity, Recurr can hold the next wave to let the queue clear.
* **Failed-payment cluster** — surfaced in the dashboard with Stripe diagnostics; Recurr's recovery layer typically handles, but a cluster signal can pause cohort expansion.
* **Unexpected refund pattern** — flagged in the dashboard; the next wave's cohort spec adjusts to exclude the affected segment.
* **Internal stakeholder concern** — escalate to Matt directly. The founder-led model means decisions don't queue behind a project manager.

[Pricing model →](/working-with/pricing-model)