The group label has to read correctly next to "Outreach" and "Campaigns" in the Revenue Recovery nav band, and it has to tell a shop owner that these are moments in a service relationship, not sales pushes.

The existing Outreach machinery is built for a different job. Every campaign today enrolls a prospect in an outboundLeads sequence, hands Retell a generated prompt, and lets the model write the opener. That is right for "we noticed your estimate is still open" and wrong for "Marcus is on the way". The design keeps the two apart on purpose so touchpoints cannot inherit sequence behaviour they should never have (retries across days, model-written openers, stop-on-reply semantics).

Why one transport, and why Retell rather than Twilio

The backend has no inbound Twilio SMS handler. A customer who answers a Twilio-sent en-route text with "is he still coming?" would be talking to nobody. Retell's SMS chat is the only path in the codebase where a reply lands somewhere (the session while it is open, the /retell-inbound-sms webhook after it closes), and the 2026-09-07 drill in SMS-BASELINE.md proved the exact-opener contract works. So every touchpoint goes out as a Retell SMS chat whose opener is the rendered template, and the reply mode only changes the prompt the agent is handed. The trade-offs are honest: no per-message delivery receipt, a chat session per send, and the fleet-wide shared sender number. Sender identity is decision 3 in section 09 and is shared with the rest of Revenue Recovery, not created by this design.

Ordered by where they fall in the job lifecycle, which is also how the Overview screen groups them. "Data source" is what v1 can actually see: ServiceTitan sends no webhooks, so job and appointment changes come from a five-minute poller; FieldEdge already delivers job.* events to /api/fieldedge/webhook. Abandoned call needs no CRM at all.

Default messages

Every template is editable per tenant. Variables are a per-touchpoint whitelist; a missing required variable suppresses the send with reason missing_variable rather than sending a blank. The opt-out footer is appended automatically the first time a tenant texts a given recipient.

Four screens, drawn with the Instrument tokens from globals.css and the primitives already in the tree: the two-tier nav band from RevenueRecoveryWorkspace, StatTile, the Quiet Slate SettingsCard / SettingsRow shell, and the shadcn Sheet. Numbers are illustrative.

Not shown: the Dashboard tab gets a small "Touchpoints" strip (sent / replied / booked / collected) under the existing source cards in a follow-up, once the activity data exists to draw it from.

Four ways in, one normalized event, one dispatcher. Everything that could double-text, text at 2 AM, or text someone who said STOP is decided in the dispatcher, which re-reads settings on every run so switching a touchpoint off also cancels what is already queued.

Reply modes, concretely

• Assistant. The agent gets a short prompt: what was sent, why, what it may do (book, reschedule, answer a payment question), and the tenant's existing global prompt overlay. It uses the same scheduling tools Outreach already uses. Bookings flow through the existing chat-end path, with a touchpointWrapup mirroring outboundLeadWrapup.
• Acknowledge and notify the office. The prompt allows one thing: thank the customer, tell them the office will follow up, and stop. Every reply of this kind fires the tenant's existing office notification (the notificationNumbers SMS path) with the customer's text quoted. No booking tools are exposed.
• STOP in either mode is detected by the existing detectChatOptOut and marks smsRecipientHealth; the event is closed with opted_out.

Three new root collections keyed the way the rest of Revenue Recovery keys things (settings by tenant phone, activity by generated id). Nothing new lands on numbers/{phone}, so the settings-field inventory contract is untouched. Types go in packages/types.

export type TouchpointKind =
  | "abandoned_call" | "job_update" | "tech_en_route" | "job_canceled"
  | "review_request" | "outstanding_balance" | "service_followup";

export type TouchpointReplyMode = "assistant" | "acknowledge";

// touchpointSettings/{businessPhoneNumber}
export type TouchpointSettings = {
  quietHours: { start: "08:00"; end: "20:00" };      // tenant tz from scheduleSettings.timezone
  dailyLimit: number;                                    // 200
  perCustomerWeeklyCap: number;                          // 3, en-route exempt
  optOutFooter: boolean;                                 // true; Archer-team editable
  reviewUrl?: string; paymentUrl?: string;
  ownsDroppedCallText: boolean;                          // suppresses legacy postcall text when true
  kinds: Record<TouchpointKind, {
    enabled: boolean; template: string; replyMode: TouchpointReplyMode;
    delayMinutes: number; options?: Record<string, unknown>;  // staleAfterMinutes, cadenceDays, floorCents…
  }>;
  updatedAt: string; updatedBy: string;
};

// touchpointEvents/{kind}_{businessPhone}_{entityKey}[_{step}]
export type TouchpointEvent = {
  kind: TouchpointKind; businessPhoneNumber: string; crm: "servicetitan" | "fieldedge" | "archer";
  customer: { name?: string; phone: string; customerId?: string };
  entity: { jobId?: string; appointmentId?: string; invoiceId?: string; callSid?: string };
  payload: Record<string, string | number>;              // techName, windowStart, balanceCents, oldStart, newStart…
  status: "scheduled" | "sent" | "replied" | "suppressed" | "canceled" | "failed";
  reason?: "quiet_hours" | "opted_out" | "suppressed_recipient" | "cap_reached" | "stale"
         | "missing_variable" | "kind_disabled" | "admin_disabled" | "frequency" | "provider_error";
  renderedMessage?: string; scheduledFor: string; sentAt?: string;
  retellChatId?: string; outcome?: { booked?: string; rescheduled?: boolean; paid?: boolean; officeNotified?: boolean };
  createdAt: string; updatedAt: string;
};

// touchpointRecipients/{businessPhone}_{customerPhone}  — the frequency ledger
export type TouchpointRecipient = {
  lastSentAt: string; sentKinds: Array<{ kind: TouchpointKind; at: string }>;   // trimmed to 30 d
  reviewRequestedAt?: string; footerSentAt?: string;
};

// touchpointCursors/{businessPhone} — ServiceTitan poller state: modifiedOn cursor + last-seen
// appointment {status, start} keyed by id, pruned once the appointment is Done or Canceled.

Indexes: touchpointEvents (businessPhoneNumber, createdAt desc), (businessPhoneNumber, kind, createdAt desc), (customer.phone, createdAt desc). The last one is what the inbound-SMS fallback reads.

Three findings from the code map shaped this design more than anything else. Touchpoints text existing customers about their own jobs, so the compliance bar is higher than for a lead follow-up, not lower.

• Opt-out is currently checked for one campaign type. processSequenceStep consults smsRecipientHealth only on the recap_follow_up branch. The touchpoint dispatcher checks it for every kind, fail-closed (a read failure returns 503 so Cloud Tasks retries, exactly as the recap branch does). Lifting the same check into the Outreach path is a separate, recommended PR.
• Quiet hours are enforced for two of ten campaign types. Touchpoints default to 8 AM – 8 PM in the tenant's timezone for every kind, with en-route as the one exception because a delayed en-route text is worse than none.
• Idempotency by id, not by memory. The ServiceTitan poller will see the same dispatch on consecutive runs, and FieldEdge redelivers on 503. Encoding the CRM entity in the event id makes both harmless without any dedup table.
• Stale events are canceled, not sent late. A dispatcher that wakes up after quiet hours re-reads the appointment or invoice before sending. "Marcus is on the way" at 8:01 AM about yesterday's 3 PM visit is the failure mode Podium users complain about most.
• No LLM before send. The legacy dropped-call text runs a model fill over {{variables}}. Touchpoints render with plain substitution; the only model call is in the reply session, where it already exists.
• Testing mode is honoured through the existing testingModeConfigs predicate, so a tenant in testing mode has touchpoints logged with suppressed: testing and nothing sent.

Each has a recommendation so a single "go with your recs" is a complete answer. Anything you change, I'll fold into the build.

Four PRs, each shippable and each dark until the Archer-team switch is on. Phase 1 puts the whole UI and the dispatcher in front of a pilot with the one touchpoint that needs no CRM.