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

# Owner roster from payment

> Track new paid Funding Machine owners throughout onboarding and retention.

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.