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. 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>. 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 reviewedW3-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.
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 addingE1b 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.
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
for the broader system ownership and rollout settings.