Opt-Outs Don't Sync Across Your Tools

A customer who unsubscribes from your email tool is still on your SMS list, still in the CRM sequence, and still in whatever your booking system sends. Every tool in the stack stores its own consent flag, and none of them tell the others. Federal rules give you ten business days from receipt of the request to stop, and receipt means the moment the customer said stop in any reasonable manner, including channels and phrasings your automation never reads.

That gap between where the request lands legally and where it lands technically is the whole problem. It is not a compliance checkbox you forgot to tick. It is a data model that has consent stored in five places and no owner.

Why a customer who opted out keeps getting messages

Walk one real sequence. A customer replies STOP to an appointment reminder. The messaging vendor catches the keyword and blocks further texts to that number, and in Twilio's case any subsequent outgoing message from your account to that user fails asynchronously with error 21610. As far as your SMS workflow is concerned, this worked.

Nothing else in the stack heard anything. Two days later the marketing platform sends the "we miss you" campaign, because the contact record there was never touched. The CRM still has the lifecycle stage that puts the person on a rep's call list. The review request automation fires on job close. The customer now believes you ignored them, and they are right, because five of your six senders did.

The failure is structural. Opt-out state gets written wherever it was received, in that vendor's own schema, and every other sender reads a different copy. Mailchimp is explicit about this even inside a single account: its documentation says it treats all audiences in an account independently, and that unsubscribing from one audience opts the contact out of marketing email and SMS for that audience only. If one tool will not propagate an unsubscribe across its own lists, expect nothing across vendor boundaries.

What actually starts the ten business day clock

47 CFR 64.1200(a)(10) is short and it does not care about your architecture. Requests to revoke prior express consent "made in any reasonable manner must be honored within a reasonable time not to exceed ten business days from receipt of such request." The rule names seven words as reasonable per se when sent in reply to an incoming text: stop, quit, end, revoke, opt out, cancel, unsubscribe. It also states that senders covered by the rule may not designate an exclusive means to request revocation.

Read that last part again, because it is where most stacks break. Your vendor's parser recognizes a keyword list. The law recognizes any reasonable manner. A customer who replies "please take me off this list" has revoked consent and has not tripped a single keyword. A customer who tells your technician on site to stop texting has revoked consent, and the only record is in a person's memory. In both cases the ten business day clock is running and nothing in your system is counting it.

The email side runs a parallel clock. 15 U.S.C. 7704 requires a sender to honor an opt-out within ten business days, requires the opt-out mechanism to keep working for at least thirty days after the message went out, and makes it unlawful to sell, lease, exchange, or otherwise transfer that address afterward except as needed to comply. Two regimes, two channels, same deadline, and one customer who said it once.

Where each system records an opt-out, and what it does not stop

This is the table worth printing and taping to the wall. Run your own stack through it before you build anything.

Where the customer said it	What actually stops	What keeps running
Replies STOP to an SMS	Further SMS from that sender pool, at the messaging vendor	Email campaigns, CRM call tasks, voice dialers, any second messaging vendor, review requests
Clicks unsubscribe in a marketing email	That list or audience in that one platform	Other audiences in the same account, SMS, rep one-to-one email, transactional templates that are really marketing
Replies to a marketing email in plain words	Nothing automatic, until a person reads the shared inbox	Everything
Tells a rep on the phone or a tech on site	Nothing, unless the rep writes it into a structured field	Everything
Submits your preference center form	Whatever that form is wired to, as of the day it was wired	Any channel or tool added after the form was built, which is usually SMS
Opts out in a chat widget or booking flow	Whatever that widget writes back, often just a note field	Everything else

The pattern in the right-hand column is the point. Every row leaks, and the leak is always into a system that has no idea a clock started. Three of the six rows stop nothing at all without a human in the loop, and those are exactly the rows a keyword parser cannot see.

Build one consent record, and do not sync it

The fix is one place that owns consent, and a fan-out. Concretely:

Append-only consent events, never an updated flag. One table with identity keys (phone in E.164, normalized email, customer ID), channel, state, source, the received timestamp, and the raw text of the request. Never update a row in place. Opt-out is a latch, and you need the history to prove when the clock started.

Derive current state, do not store it. A view that resolves the events into contactable or not, per channel. Revoked wins. A later grant only overrides a revoke if it is a real documented opt-in with its own source record, not a CSV import or a form the customer filled out for something else.

Fan out in one direction only. Push from the record of record to each sender. Do not two-way sync consent between tools. A bidirectional sync will eventually push a stale subscribed flag from the tool that never heard about the STOP back over the tool that did, which is the exact conflict-resolution failure described in two-way syncs that overwrite good data. Resurrecting an opt-out is worse than any other sync bug because it is the one that generates a complaint.

Gate at send time, not at batch time. Every send node checks consent immediately before it sends. A batch assembled Monday and dispatched Thursday carries three days of stale consent, and those are business days off your ten. In n8n this is one HTTP request node in front of the send, and it is the cheapest insurance in the workflow. The same pre-send gate belongs in the enrichment and outreach paths of any customer acquisition system you run.

Capture the unstructured requests. Route the reply-to address of every automated message and your shared support inbox into the same intake, then classify replies for opt-out intent. This is one of the cases where a model earns its keep instead of a rule: the phrasings are open-ended, you want high recall, and you can send the uncertain ones to a person. The tradeoff is the same one covered in when to use AI instead of a rule. Bias the threshold toward over-capturing. A wrongly suppressed message costs you one email. A missed opt-out costs you a complaint and a documented violation.

Record the receipt time, not the processing time. Ten business days runs from receipt. If a request sat in a shared inbox for six days before your workflow saw it, you have four left, and only the receipt timestamp tells you that.

January 31, 2027 is a build deadline, not a reprieve

There is a part of 64.1200(a)(10) that is not yet in force. It requires treating a revocation made in response to one type of message as applying to all future robocalls and robotexts from that caller on unrelated matters. Revoke once, revoke everything. The FCC waived that provision and has now extended it twice, most recently in order DA 26-12, released January 6, 2026, which pushed the date to January 31, 2027.

Look at the stated reason for the delay. Organizations with multiple business units and disparate messaging systems could not operationally propagate a revocation across them. The regulator described your architecture problem and then gave you a date to fix it by.

Treat the date that way. Every other part of the revocation rule is already in effect, and the waiver changes nothing about the obligation to honor opt-outs you receive today. More to the point, the build is the same either way. A stack that can take one revocation and apply it to every channel is the same stack that stops the marketing platform from emailing someone who texted STOP last Tuesday. There is no separate revoke-all project to schedule for late 2026. There is the consent record you should have built already, and a deadline that now makes it easy to fund.

How to start

Run the reverse test this week, before you design anything. Pull five customers who opted out in the last ninety days, from whichever system caught it. For each one, open every system in your stack that can send a message and check whether they are still marked contactable. Count the systems that are wrong, and count the elapsed days since the opt-out landed. Five customers is enough. If the number is above zero, and it will be, you have measured your exposure in about an hour and you now know which integrations to build first.

Then build the consent table before you touch the tools. The order matters, because a fan-out with no record of record is just another sync. If you want a second set of eyes on where the leaks are in a stack you have already built, tell us what you are running and we will map it against the table above. The full build pattern, including the pre-send gate, is the kind of thing we ship as part of a workflow automation system.