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.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.
What you own day-to-day
Wave gating sign-off
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.
Support coordination
Migration emails generate inbound — billing questions, “is this real” questions, occasional cancellation requests. The framework provides response templates; your support owner routes the volume.
Cohort review
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.
Internal comms
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.
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 IAP holdout is selected and managed by Recurr.
- Wave reports. Auto-generated post-wave, ready for your gating sign-off.
Wave rhythm
A typical wave cycle:| Day | Activity |
|---|---|
| Day 1 (Mon) | Recurr proposes wave cohort + copy; your team reviews |
| Day 2 (Tue) | Wave kicks off — emails send through scheduled window |
| Days 2–5 | Conversion accrues; support gets occasional inbound |
| Day 8 (next Mon) | Wave report lands in dashboard; gating decision |
| Day 9 (Tue) | Next wave ships (if gates clear) or pause + adjust |
How the four phases gate each other
Audit → Pilot
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.
Pilot → Migrate
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.
Migrate → Compound
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.
Compound — ongoing
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.
Safeguards that run quietly
The framework’s operational safeguards run by default without your team operating them:- Matched IAP 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.
- Risk-ordered cohorts — strongest cohorts go first; expansion outward is gated by data.
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.