> ## 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.

# Onboarding notifications

> Payment welcome ownership, tracked links, and the existing onboarding funnel.

The payment welcome is prepared for the cloud runner. It remains disabled until staff
complete the deployment and workflow cutover. Signing an agreement alone does not
qualify a customer for this welcome.

## Payment welcome

The payment workflow continues to find or create the onboarding opportunity. Its
authenticated webhook identifies the payment transaction and opportunity. The app
independently verifies successful payment, the approved product, Operations Location,
and the matching contact before enrolling the welcome. Only payments and onboarding
records created after the configured cutover qualify; existing customers are not backfilled.

The cloud runner sends the welcome email first, then its companion SMS on a later
pass. Each is sent at most once per enrolled Operations contact. Both honor CRM
Do Not Disturb, channel availability, onboarding holds, and the recorded form-submission
date. The runner checks every ten minutes, so these are queued messages rather than
an immediate receipt. Payment receipts remain with the payment provider.

When Slack workspace onboarding is enabled, verified payment also queues the private
support channel before the CRM sub-account exists. The email and SMS wait for the
channel's CRM readback, assigned staff and a usable invitation. Until the reviewed
E1b cutover is activated, they preserve the signed workspace join link. After activation,
E1b carries that invitation following the form and account creation. The customer joins with their purchase email; FM Bot adds them to
the reserved channel. Later account linking reuses that same channel. Staff can help
in Slack while the CRM account is being prepared. See [Slack workspace setup](/staff/slack-workspace#from-payment-to-private-support).

The runner records provider acceptance, which is not proof of inbox delivery.
An uncertain send blocks further dispatch until staff review its receipt. The engine
can be paused and resumed without clearing that history.

## Email sender

When a paid-welcome policy is configured, later cloud emails use the same approved
sender name and email address, even when no welcome is due in that pass. For this
rollout that is **My Funding Machine \<[crmsupport@myfundingmachine.com](mailto:crmsupport@myfundingmachine.com)>**.
The assigned owner remains in the personal signature. Older configurations without
a welcome policy retain their existing sender behavior.

## Email logo

Onboarding email templates include the Funding Machine logo above the message. The
logo keeps its original proportions and includes a text alternative when images are
blocked. The paid welcome supplies the approved hosted logo directly. Later cloud
emails read the **Email Logo URL** custom value in Operations. Manually maintained
CRM templates need the same header published separately.

## Existing form and scheduling

**Complete the Form** uses a signed link associated with the paid Operations contact.
The app validates the link, reads that contact's current details, records the first
open, and redirects to the existing **Z - Onboarding Funnel** with name, email, and
phone prefilled. Links expire after thirty days and staff can pause or reissue them.

The survey, its questions, submission workflows, and compliance-call calendar handoff
remain in the CRM. The funnel's existing redirect supplies contact and agency
details to its configured calendar.

**Prefill does not force the survey to update a particular contact ID.** The CRM
still matches the submitted email and phone. A forwarded link or changed details
can affect that match. Ask the customer to use the details associated with the
purchase; resolve contact changes with staff. The app never marks the form complete
from a link click. Email scanners can open links too, so an open is only diagnostic.

Prefilled contact details appear in the destination URL and browser history. The
signed token stays on the app redirect URL and is not forwarded to the funnel.

## Notification ownership

E3 and its staff send-recap task are retired because customers receive the call
summary from Zoom. Call-completion tracking and the Final QA task remain unchanged.
This does not delete previously created CRM tasks or alter Zoom delivery settings.

### Form received and identity verification

**E1b — Your CRM account and next steps** sends once after the CRM records
**Onboarding Form Submitted**, including when KYC is already Verified or the open
onboarding opportunity has advanced to setup, Final QA, or Live.
It does not wait for day two or for a compliance-call booking. It runs on the next
eligible cloud pass once the customer's CRM account is linked, a valid Slack invitation is available, and this communication
is approved for the reviewed cohort. Holds, email Do Not Disturb, account mapping,
and the existing send ledger still apply. Closed onboarding opportunities do not receive it.

The email reminds customers about the separate CRM login email, then opens Funding Machine in that customer's CRM account and directs them, if not already verified, to
**Onboarding & Setup → Verify your identity**. The subscription cardholder completes
the existing secure Stripe flow. Photo ID and selfie collection stay in Stripe;
customers must not send identity documents through email or Slack. Already-verified customers see a completion confirmation instead of the ID instructions.

E1b includes a signed, customer-bound Slack invitation. Connected members instead
get a link to their existing support channel. Both require the scoped, active paid
onboarding record and matching channel. Missing, paused, expired, or mismatched
records leave E1b waiting without claiming a send; other eligible work can continue.
The reviewed `W3-slack-recovery` allowance creates one staff task to repair or
reissue access through the existing controls. Receipts are preserved, and E1b
retries when access is restored. Unsafe destinations still fail validation.
The FM bot welcomes members when they join their private channel.

Moving the invitation out of E1 and its payment SMS requires an explicit
`slackInviteInE1b: true` welcome-policy setting and a reviewed send-mode enrollment
policy allowing both E1b and its recovery task. Existing policies keep the welcome
invitation until that cutover. See [activation and rollback](/staff/onboarding-engine-rollout#post-form-slack-invitation-cutover).

## Reminder pacing and setup handoff

E1a asks for the current unfinished step: the form first, then the compliance call.
Form submission or an inbound reply restarts the reminder window. E1a is due after
two days, SMS after four, and a staff task after six, with at least 48 hours after
any recorded welcome, post-form email, or previous reminder. The staff task names
the unfinished step. This prevents overdue messages from catching up every ten
minutes. Imported or reviewed history without a send timestamp still prevents
resends but cannot establish a spacing interval; review those customers before activation.

E2 requires a recorded completed compliance call, the compliance checklist, and
verified identity. It provides one button to the setup workspace; technical setup
details live there. A booked call alone is not completion.

Before activation, reply to the authorized Kevin Hill test email and verify that
the reply reaches the intended team inbox/conversation. SMTP and provider acceptance
prove sending, not reply routing; this live check remains separate from code verification.

This email does not create a verification session or mark KYC complete. It also
does not cancel or replace a booked compliance call. E2 remains after verified KYC
and the completed compliance checklist. Activating E1b requires reviewing native
form-confirmation ownership and adding `E1b` to the intended cohort's communication
allowance; deploying templates alone does not enable it or enroll older customers.

### Retention and follow-up emails

E5a stays a personal week-one check-in sent by the owner after the existing staff
task. The E6 lost-access email is retired; internal staff recovery tasks remain.
The Slack invitation is in E1b, and a paid Slack upgrade is not needed.
E7 offers help with the next funding file; E8 offers a call with the team without
assuming the customer plans to cancel or promising a specific call length or outcome.
E9 helps restart setup and tells customers to keep any call already booked.

All email cards share the logo, navy header rule and footer, and mobile-friendly
width. Buttons use gold with navy text; supporting links use underlined navy text.
Personal check-ins emphasize replying rather than adding a competing button.
These copy changes preserve the existing send timing, owner tasks and safeguards.

### Compliance handoff and reminders

The training digest (E5) is removed for now, including the Monday send and the
day-three retention send. There is no weekly schedule to maintain. The personal
week-one check-in (E5a) remains, and E4 still links to guided training.
Existing digest settings and send history remain readable but do not trigger sends.

The go-live email (E4) confirms the application handoff, includes labeled website
and funding-application links, and uses one gold **Open guided training** button
for the first-file next step. It points to the Operations **Start Here URL** custom
value. Customers with pending phone setup or messaging verification are directed
to check **Onboarding & Setup** before calling or texting. It does not imply those
services are already enabled. The existing go-live prerequisites and send-once
tracking remain unchanged.

After the compliance checklist is complete and identity is verified, the setup
email gives the customer a short handoff and one **Open Funding Machine** button.
It opens Funding Machine inside their verified CRM account; the email directs them
to choose **Onboarding & Setup** there. The destination uses
the opportunity's Product Location ID, checked against the reviewed customer
mapping; a missing or mismatched account blocks the send. It never links to Operations
as the customer's account. Detailed Slack, website, phone, training, and call
guidance stays in the setup workspace, while the email highlights what to have ready
and reminds customers that texting requires messaging approval.

For reviewed **New — Paid** opportunities, the day-two email and day-four SMS
point to the next unfinished step. If the form has not been submitted, they link
to the onboarding form, even if a compliance call is already booked. Once the form
is submitted, they link to compliance-call booking. When both are complete, the
reminders stop. Each reminder sends at most once; completing the form does not
restart the email sequence. The email has one gold button, matching the welcome.

These reminders use the Operations form and compliance-calendar custom values.
Only the destination for the current step is required. The paid welcome continues
to use its signed, personalized form link.

| Notification or action | Trigger | Owner |
| - | - | - |
| Payment receipt | Provider confirms payment | Payment provider |
| Welcome email and companion SMS | Verified eligible payment after cutover | Cloud runner after activation |
| Existing agency welcome | Agreement document completed | Existing CRM workflow until cutover removes its email/SMS actions |
| Form processing and scheduling redirect | Existing survey submitted | Existing CRM funnel and workflows |
| Form-received account and Slack email | Recorded form submission, linked CRM account, valid Slack invitation, open onboarding opportunity | Cloud runner, once, for cohorts with E1b approved |
| Day-two kickoff email, day-four SMS, day-six staff task | New — Paid opportunity age; form and compliance booking still incomplete | Cloud runner, for its reviewed cohort |
| Compliance-complete email | Complete compliance checklist and verified identity, in Compliance or Setup In Progress | Cloud runner |
| Onboarding-call summary | Completed call | Zoom; no separate E3 email or cloud send-recap task |
| Go-live email | Final QA approval and shared go-live prerequisites | Cloud runner |

Moving the welcome does not automatically enable every later message. Later engine
communications still require their reviewed cohort, verified product-account mapping,
and communication allowances. See [Onboarding connections](/staff/onboarding-connections)
for the broader system ownership and rollout settings.


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