Skip to main content
Operations uses the Retention pipeline as the owner roster. A new verified paid owner has two cards linked to the same CRM contact:
  • Onboarding → New — Paid tracks the setup work.
  • Retention → Onboarding in Progress keeps the owner visible from payment onward.
The existing payment workflow creates the onboarding card. The cloud onboarding engine independently verifies the payment, order, product and contact before ensuring one Retention card. This runs before CRM account provisioning and before the welcome messages. It does not require the owner to finish the form or join Slack.

​
Go-live handoff

After staff approves final QA and moves onboarding to Live — Onboarded, the engine records the completion date and advances the existing Retention card to Ramp (Days 0–30). It copies the verified customer CRM account and Slack channel mapping. An unprovisioned card must match the confirmed payment-time card receipt before the engine attaches the customer account. It verifies the handoff before marking onboarding won. The ramp clock starts at the recorded onboarding completion date, even if payment was weeks earlier. Older cards without that date retain their creation-date baseline. Real usage dates already on the card are preserved. Cards in Onboarding in Progress do not receive retention communications, usage updates, Slack-lapse tasks or churn-risk transitions. Creating the roster card does not enroll the customer in retention messaging.

​
Configuration and rollout

After deploying the reviewed implementation, pause the engine and let its current pass finish. Preserve the existing configuration, cutover, audience and receipts. Resolve the Operations Retention pipeline and stage IDs from the CRM and add the onboardingInProgress mapping. Do not reuse IDs from another account. Existing audience members keep their saved permissions. During cutover, review any new-paid members whose welcome is still pending and add the handoff allowance to those members too; preserve their payment requirement, mode and pause state. Members without the reviewed handoff allowance are excluded from early creation and continue through the existing welcome and go-live flow. The claim checks this again before writing. The verified-paid enrollment policy must allow ensure_retention_opportunity and W9-retention-activated. Preserve the other existing allowances. Set retentionAtPayment: true in the welcome policy, then re-enable the engine. The enable guard checks that the stage and paid handoff are configured together. Only newly scheduled eligible welcomes receive the payment-time action. This is not a historical backfill; reconciling earlier owners is a separate reviewed task. Do not add a second native workflow to create Retention cards in parallel. To stop new payment-time card creation, pause the engine, set retentionAtPayment to false, and resume. Keep the stage mapping and handoff allowance so existing onboarding cards can still advance at go-live. This does not delete or move cards.

​
Recovery

A complete search across all Retention statuses prevents duplicates. An existing closed or advanced card is preserved. If staff closes the exact receipted card before account provisioning, it can count as the preserved handoff without being reopened or assigned an account. Before completing onboarding, the engine reads the Retention card again; a staff change delays completion until the next pass. Multiple cards, an incomplete search, or a conflicting account mapping require staff review; the engine does not guess. An uncertain provider write keeps its durable claim and is not automatically retried. Review the CRM card and resolve that claim as applied or not applied using the existing engine recovery process before retrying. Never clear receipts just to force another send or card creation.