// Module 11 — Outbound Engagement
Reach your supporters proactively — with six gates between you and a compliance problem.
Reach out to your supporters first — with six checkpoints standing between you and a compliance mistake.
Most AI engagement platforms help you answer questions. LINAsystems also helps you start the conversation — with an outbound messaging layer that is default-off, human-approval gated, suppression-aware, and built on the same Twilio rail as the phone agent. Nothing auto-sends. Every message passes six checks before it moves.
Most AI platforms only help you answer questions people ask. LINAsystems can also start the conversation — through an outbound messaging system that's turned off by default, requires a person's approval, respects opt-outs, and runs on the same Twilio connection as the phone agent. Nothing sends itself. Every message has to pass six checks first.
← Back to the platform overview
// The safety model
Six gates. All six must hold before any message leaves.
Six checkpoints. Every single one has to pass before a message goes out.
Uncontrolled outbound is where compliance problems start. The send queue is architected so no message can escape unless every gate passes — and the default state of every gate is closed. Operators open gates deliberately; the system never assumes permission it wasn't given.
Sending messages without controls is where compliance problems usually start. The send queue is built so a message can't get out unless it passes every single checkpoint — and every checkpoint starts out closed. Your staff have to open each one on purpose; the system never assumes it has permission it wasn't actually given.
The six gates, in order: feature flag on → rail master on (SMS enabled / email provider configured) → task is human-approved (or autosend explicitly enabled) → under the daily send cap → not in quiet hours → recipient is not suppressed or opted out. All six. Every send.
The six checkpoints, in order: the feature is turned on → the channel is turned on (SMS enabled, or an email provider is set up) → a person has approved the message (or auto-send has been turned on for that case) → today's sending limit hasn't been reached → it isn't during quiet hours → the recipient hasn't opted out or been blocked. All six, every single message.
Feature flagSend Queue is off by default. An operator must explicitly enable it in the Command Center before the queue can process anything — adding the module to the system does not automatically send a single message.The Send Queue is off by default. A staff member has to turn it on in the Command Center dashboard before it can do anything — just adding this feature to the system doesn't send a single message on its own.
Rail masterA per-channel master switch — sms_enabled for SMS, an active provider for email. Both can be live in the system while the rail is off; flipping the rail is the operator's authorization to use that channel.A single on/off switch for each channel — one for SMS, one for email (which needs an active email provider set up). Both can be ready in the system while still switched off; turning the switch on is your staff's way of saying "yes, use this channel."
Human approvalEach queued task must be individually approved by a human operator before it can send — unless the operator has explicitly enabled autosend for a specific use case. The queue is review-first by design.Each message waiting in the queue needs a person to approve it before it can go out — unless staff have specifically turned on auto-send for that situation. Review comes first, by design.
Daily capA configurable ceiling on the total number of sends per day. Once the cap is reached, further sends are held (not dropped) until the next day — so a surge in queue depth can't run away overnight.A limit your staff set on how many messages can go out per day. Once that limit is hit, the rest just wait — they aren't lost — until the next day. So a sudden backlog can't turn into a flood of messages overnight.
Quiet hoursSends are held outside of configured operating hours. A task due at 11pm is queued, not sent, and picked up the next morning when the window opens — same task, no re-approval needed.Messages don't go out outside the hours your staff set. A message due at 11pm just waits in the queue instead of sending, and goes out the next morning when the hours open back up — the same message, with no need for a new approval.
Suppression listA per-recipient suppression and opt-out registry. Any address or phone number on the list is never reached, regardless of approval or rail status. SMS opt-outs are recorded automatically from inbound STOP replies.A list of people who should never be contacted, including anyone who has opted out. Anyone on that list never gets a message, no matter what else has been approved or switched on. If someone replies STOP to a text, they're added to this list automatically.
// Double-send safety
A crash strands a message toward not-sent, not toward duplicate.
If something crashes, a message gets stuck unsent — it never gets sent twice.
The send queue is designed for the failure mode that does real harm in outbound messaging: accidentally sending the same message twice. Every task is marked sending and persisted to disk before the rail call, then marked sent or failed after. If the process crashes between those two steps, the task is stuck at sending — a state the human operator can review — not silently re-queued. A re-run of the sweep never re-sends a task already in a terminal state.
The send queue is built to avoid the mistake that does real damage in outbound messaging: accidentally sending the same message to someone twice. Every message is marked "sending" and saved to disk before it actually goes out, and marked "sent" or "failed" right after. If something crashes in between those two steps, the message is stuck at "sending" — something a staff member can review — instead of quietly getting queued up again. Running the check again never re-sends a message that already reached a final state.
- Pre-mark before sending.Marked before it sends. The row is written to disk as
sending before the Twilio or email call goes out — so a crash produces a recoverable row, not a lost send. Each message is saved to disk as "sending" before the Twilio or email call actually happens — so if something crashes, you get a message you can recover, not one that's simply lost.
- Terminal states are final.Final states stay final.
sent and failed rows are never re-processed by the sweep — a re-run can't duplicate a completed send. Once a message is marked "sent" or "failed," it's never processed again — running the check again can't accidentally send it a second time.
- Crash = stranded, not re-sent.A crash means stuck, not resent. The design explicitly chooses the TCPA-safe failure mode: a message that couldn't be confirmed as sent is held for human review, not retried automatically. The system is built on purpose to fail safely: if it can't confirm a message actually sent, it holds it for a person to review instead of automatically trying again.
- 40-deep backups.40 backups kept. Every write to the queue store is atomic and keeps 40 rolling backups, consistent with every other stateful file in the platform. Every change to the queue is saved safely and keeps 40 backup copies, the same way every other important file in the platform works.
// SMS channel
Outbound SMS on Twilio — with opt-out compliance built in.
Text messages sent through Twilio — with opt-outs respected automatically.
The SMS channel is the same Twilio integration that powers the AI Phone Agent, extended to outbound messaging. Opt-out compliance isn't a separate add-on: inbound STOP replies are captured automatically, the sender is added to the suppression list immediately, and the suppression gate on every future send ensures they're never reached again — without any operator action.
Text messages use the same Twilio connection that runs the AI Phone Agent, just extended to also send messages out. Respecting opt-outs isn't a separate feature you have to set up: when someone replies STOP, it's captured automatically, they're added to the do-not-contact list right away, and every future message checks that list first — so they're never texted again, with no action needed from your staff.
- Twilio REST API.One Twilio account, both directions. Every outbound SMS goes through the same Twilio account as your phone agent — one integration, two directions. Every text you send out goes through the same Twilio account as your phone agent.
- STOP = instant opt-out.STOP means opted out, instantly. An inbound STOP reply from any number records an automatic opt-out, writes them to the suppression list, and blocks future sends to that number in the same sweep cycle. If anyone replies STOP, that's recorded as an opt-out right away, added to the do-not-contact list, and future texts to that number are blocked the very same cycle.
- Inbound SMS routing.Replies reach your team. Inbound messages beyond STOP — questions, replies, keyword responses — are routed through the system for operator review, not silently discarded. Any reply that isn't STOP — a question, a comment, anything else — is routed to your staff for review, instead of being quietly thrown away.
- Signature-verified inbound.Verified replies only. Inbound SMS webhooks from Twilio are cryptographically signature-verified, consistent with the phone agent's security model. Incoming text messages from Twilio are checked with a security signature, so the system can confirm they really came from Twilio — same approach used by the phone agent.
- Safe-by-default.Off until you turn it on. SMS is off by default (
sms_enabled off) — the capability is present but inert until an operator explicitly enables it. Texting is off by default — the feature is built in, but it does nothing until a staff member turns it on.
// Followup sequences
Automated follow-up — timed from the first contact, held by the same gates.
Automatic follow-ups — timed from the first contact, and held to the same checkpoints.
The Followup Producer generates timed follow-up tasks for supporters who expressed intent but haven't taken the next step — a volunteer inquiry with no follow-through, a donation question without a completion. Tasks are placed in the send queue, not fired directly, so every followup passes the same six-gate review as any other outbound message. Automation drives the timing; a human still approves the send.
The Followup Producer creates timed follow-up messages for people who showed interest but didn't finish the next step — like someone who asked about volunteering but never followed through, or started a donation but didn't complete it. These messages go into the send queue rather than going out directly, so every follow-up passes the same six checkpoints as any other message. The timing is automatic, but a person still approves the send.
- Intent-triggered.Triggered by interest. Follow-ups are generated from the intent signals that the supporter intelligence layer records — not from a static list or a calendar schedule. Follow-ups are created from the signs of interest the system already records — not from a fixed list or a calendar.
- Queue-first.Always queued first. Every generated followup lands in the send queue as a pending task — subject to human approval, quiet hours, suppression, and all other gates. Every follow-up lands in the send queue waiting for approval — subject to human approval, quiet hours, the do-not-contact list, and every other checkpoint.
- No direct fire.Never sends directly. The Followup Producer never calls the SMS or email rail directly; it only writes queue entries. The queue's safety model is the safety model for follow-ups. The Followup Producer never sends a text or email on its own — it only adds an entry to the queue. So follow-ups get the exact same safety checks as everything else.
- Configurable timing.You set the timing. The delay between the trigger event and the followup task is operator-configurable per use case. Your staff can decide how long to wait between the original action and the follow-up, for each situation.
// Delivery tracking
Every send is logged — status, channel, timestamp, and outcome.
Every message is logged — what happened, when, and how.
The delivery log records the outcome of every send attempt — sent, failed, held for quiet hours, or suppressed — in a structured log available in the Command Center. Operators can see exactly what went out, when, to whom (redacted to a contact ID in admin views), and what the rail returned. Failed sends surface in the Priority Action Center so they're not silently lost.
The delivery log records what happened to every message — sent, failed, held for quiet hours, or blocked — and it's all visible in the Command Center dashboard. Your staff can see exactly what went out, when, and to whom (shown as a contact ID rather than a phone number or email in the dashboard, to protect privacy), plus what response came back. Failed messages show up in the Priority Action Center so nothing gets lost quietly.
Statespending → approved → sending → sent / failed. Tasks held by quiet hours or daily cap stay in approved, not a separate limbo state — the next sweep cycle picks them up when the gate opens.A message moves through these stages: waiting → approved → sending → sent or failed. If it's held back by quiet hours or the daily limit, it just stays "approved" rather than getting stuck somewhere else — it goes out automatically once that checkpoint opens.
PII handlingDelivery log views redact recipient PII by default — operators see a contact ID, not a phone number or email address. Full details are available behind a gated, audit-logged view for authorized admin operators.By default, the delivery log hides personal details — staff see a contact ID, not an actual phone number or email address. The full details are available, but only behind a separate, logged view for authorized admins.
Failed sendsA task that fails at the rail (Twilio error, email bounce) is marked failed with the error string and surfaced in the Priority Action Center, so operators see it on next login.If a message fails to go through (a Twilio error or a bounced email), it's marked "failed" along with the error message, and shown in the Priority Action Center so your staff see it the next time they log in.
ExportableDelivery log data is exportable alongside the CRM, so campaign coordinators and compliance reviewers can audit the full send history without access to the admin console.You can export the delivery log along with the CRM data, so coordinators and compliance reviewers can check the full sending history without needing access to the admin dashboard.
// Editions & availability
Available as an add-on module.
Available as an add-on.
Outbound Engagement is an advanced add-on module for both the Campaign and Business editions. It ships inert in every install — architecturally present, not absent — and lights up only when you enable it; because it sends on your behalf, we turn it on deliberately. It isn't on the standard bundle sheet, so contact us to add it and we'll scope volume and pricing with you. Both editions share the same six-gate safety model; the messaging use cases differ:
Outbound Engagement is an advanced add-on for both the Campaign and Business editions. It comes built into every install but switched off — it's there, just not active — and it only turns on when you ask us to enable it; since it sends messages on your behalf, we turn it on deliberately, not automatically. It's not part of the standard pricing list, so contact us and we'll work out the volume and price with you. Both editions use the exact same six-checkpoint safety model; only the use cases differ:
Campaign
Supporter outreach
Volunteer follow-up, donor re-engagement, event reminders, and GOTV SMS — with human approval on every send and TCPA-safe opt-out compliance built in. Supporter segments and intent signals drive targeting; the queue and suppression list drive safety.
Following up with volunteers, re-engaging donors, event reminders, and get-out-the-vote texts — with a person approving every message and opt-out compliance built in. Supporter groups and signs of interest decide who gets targeted; the queue and the do-not-contact list keep it safe.
Business
Customer follow-up
Appointment reminders, support follow-ups, and re-engagement sequences — the same queue-first, human-approval model applied to a customer-service context. SMS opt-out compliance and quiet hours work the same way regardless of use case.
Appointment reminders, support follow-ups, and re-engagement messages — the same queue-and-approval model, just used for customer service instead. Opt-out compliance for texts and quiet hours work the exact same way no matter what you're using it for.
// Live demo
See the platform answering real questions right now
Watch it answer real questions, right now
The live demo runs the exact system that ships to customers — try it as a campaign or as a business.
This demo is the exact same system real customers get. Try it set up as a campaign or as a business.