Risk Flag AI Summary 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

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

Risk

Keep the failure mode visible

The main risk is creating client-facing proof from raw provider or AI data before a safe summary is approved.

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.

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.
Attach every message, AI draft, provider sync, and CRM handoff to the lead or client record.
Capture response time, booked outcome, lost reason, source coverage, and next action for reporting.
Pause the workflow when a provider credential, webhook, import, delivery, privacy, or compliance state is uncertain.
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.

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

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

Step 2

Workflow action

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

Step 3

Workflow action

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

Step 4

Workflow action

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

Step 5

Workflow action

Attach every message, AI draft, provider sync, and CRM handoff to the lead or client record.

Step 6

Workflow action

Capture response time, booked outcome, lost reason, source coverage, and next action for reporting.

Step 7

Workflow action

Pause the workflow when a provider credential, webhook, import, delivery, privacy, or compliance state is uncertain.

Step 8

Workflow action

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

Step 9

Workflow action

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

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