Scale Phase 6 Follow Up Sequence Guide

Workflow contract

What this automation must protect before it scales.

Use this guide before connecting live SMS, email, call tracking, CRM, Search Console, QuickBooks, Thumbtack, Angi, AI summaries, or portal-facing proof.

Owner

One owner drives the workflow

Automation ops owns trigger rules, message timing, failure review, CRM handoff, and client-safe status.

Risk

Keep the failure mode visible

The main risk is losing traceability when messages, tasks, CRM handoffs, and provider enrichment are not connected to the lead record.

Privacy

Separate internal raw data from portal proof

Raw call data, provider payloads, AI drafts, and private notes stay internal until a client-safe summary is approved.

Scale

Design for high-volume routing

Use normalized events, idempotency keys, retry windows, queue states, and summarized outcomes before adding more providers.

Baseline controls

Checks that apply to every workflow.

Define the trigger, source, owner, consent state, and duplicate rule before the automation runs.
Write all workflow outcomes to an internal log before showing anything in the client portal.
Use prepared MySQL reads and summarized records once real client data is connected.
Pause the workflow when provider freshness, data quality, or message compliance is uncertain.
Keep SMS, email, CRM, and provider credentials out of public files and generated pages.
Attach tasks, messages, notes, and CRM sync runs back to the lead or client record.
Measure response time, routed owner, booked outcome, and follow-up result for reporting.
Store AI output as a draft until a human or rule-based approval step marks it safe.
Make the rollback path clear before changing live sequences or message templates.
Retest desktop, mobile, admin, portal, and message copy after workflow changes.

Topic steps

Specific actions for this workflow.

Store portal-visible output as a reviewed summary, not raw transcript, payload, or internal note.
Verify desktop, mobile, admin, portal, and observability status after workflow changes.
Keep rollback paths and incident owners visible before enabling automation at scale.
Use idempotency keys and retry windows for webhooks, provider syncs, and CRM handoffs.
Normalize source, service type, contact method, consent, market, urgency, owner, and attribution before action.
Create an internal log entry before sending messages, creating CRM payloads, or publishing portal notes.
Run duplicate, spam, provider freshness, and data-quality checks before client-facing proof is created.
Route urgent or high-value leads to an owner task before any long nurture sequence starts.
Use approved message templates with channel, opt-out, response window, and escalation rules.

Workflow steps

Turn the page into an admin checklist.

Each step can become a task template, runbook item, delivery check, CRM mapping rule, or approval requirement.

Step 1

Workflow action

Store portal-visible output as a reviewed summary, not raw transcript, payload, or internal note.

Step 2

Workflow action

Verify desktop, mobile, admin, portal, and observability status after workflow changes.

Step 3

Workflow action

Keep rollback paths and incident owners visible before enabling automation at scale.

Step 4

Workflow action

Use idempotency keys and retry windows for webhooks, provider syncs, and CRM handoffs.

Step 5

Workflow action

Normalize source, service type, contact method, consent, market, urgency, owner, and attribution before action.

Step 6

Workflow action

Create an internal log entry before sending messages, creating CRM payloads, or publishing portal notes.

Step 7

Workflow action

Run duplicate, spam, provider freshness, and data-quality checks before client-facing proof is created.

Step 8

Workflow action

Route urgent or high-value leads to an owner task before any long nurture sequence starts.

Step 9

Workflow action

Use approved message templates with channel, opt-out, response window, and escalation rules.

Data hooks

Tables and runtime sources to connect later.

Keep public pages static; runtime reads and writes should happen in admin, portal, provider sync, or queue workers.

Runtime 1

approval_requests

Connect this source through admin or portal runtime only. Keep raw payloads internal and expose summarized, approved fields.

Runtime 2

incidents

Connect this source through admin or portal runtime only. Keep raw payloads internal and expose summarized, approved fields.

Runtime 3

audit_trail

Connect this source through admin or portal runtime only. Keep raw payloads internal and expose summarized, approved fields.

Runtime 4

portal_activity

Connect this source through admin or portal runtime only. Keep raw payloads internal and expose summarized, approved fields.

Runtime 5

crm_sync_payloads

Connect this source through admin or portal runtime only. Keep raw payloads internal and expose summarized, approved fields.

Runtime 6

sms_delivery_logs

Connect this source through admin or portal runtime only. Keep raw payloads internal and expose summarized, approved fields.

Runtime 7

email_delivery_logs

Connect this source through admin or portal runtime only. Keep raw payloads internal and expose summarized, approved fields.

Runtime 8

leads

Connect this source through admin or portal runtime only. Keep raw payloads internal and expose summarized, approved fields.

Outputs

Make every automation result traceable.

Traceable outputs make it possible to prove what improved after a client joined without exposing sensitive raw data.

Output 1