A Consent Ledger for Customer Texts: Storing Opt-Ins and STOPs So Every Automation Can Check Them

Description and use

A single consent ledger prevents messages to opt‑out customers, provides audit trails, and simplifies compliance across multiple automation tools.

Problem

In US small‑business texting automations, opt‑out information is scattered across multiple tools, causing accidental messages to customers who have opted out.

Outcome

Implementing a single consent ledger prevents accidental messages to opt‑out customers, provides audit trails, and simplifies compliance across multiple automation tools.

Workflow

• 1. Create a PostgreSQL table consent_events with columns for phone, channel, purpose, event, source, evidence, and timestamp.
• 2. Record every opt‑in or opt‑out as a new row; never update existing rows.
• 3. In each automation, call may_send(phone, channel, purpose) just before sending a message.
• 4. may_send retrieves the latest event for that phone/channel/purpose and returns true only if the last event is opt_in or if no event exists and the purpose is transactional with an active request.
• 5. Capture opt‑outs via inbound text matching FCC stop words or by staff entry, and record opt‑ins from forms with evidence IDs.
• 6. Normalize phone numbers to E.164 to avoid duplicate entries.
• 7. Use the ledger to audit message history and prove compliance.

Evidence

In US small‑business automations, texting consent tends to live in the texting tool and nowhere else.

Source

The fix is boring and effective: one consent ledger that every automation checks before sending.

Source

Every automation calls may_send right before sending, not when the job is queued.

Source

Inbound texts matching the standard opt‑out words (the FCC's list is stop, quit, end, revoke, opt out, cancel and unsubscribe; carriers and providers may recognise more) write an opt_out event for all purposes on that channel.

Source