lead unsubscribed from emails but the agent kept messaging them on LinkedIn - channel-level suppression didn't exist
Fixes the case where an SDR agent honors an email unsubscribe but keeps contacting the same person on LinkedIn or other channels, because opt-outs were stored per channel instead of per person. Use when unsubscribes, do-not-contact flags, or opt-outs leak across channels. Not for email-only suppression bugs, spam-filter deliverability problems, or per-channel unsubscribe link failures.
TL;DR
Build one global suppression list keyed on the person (email or lead id), and make every channel - email, LinkedIn, SMS, calls - check it before every touch. The fix is a single do-not-contact store plus a mandatory pre-send check in every outreach step; the channel-specific lists become downstream copies, not the source of truth.
lead unsubscribed from emails but the agent kept messaging them on LinkedIn - channel-level suppression didn't existSteps
Create a single suppression store (a table or a list in the CRM) with one row per person, keyed on the lead id or normalized email. Any opt-out from any channel writes here first, then fans out to the channel tools. Expected: you can look up one person and see every opt-out they have ever filed, no matter which channel it came from.
Add a mandatory suppression check at the top of every send path - email step, LinkedIn step, SMS step, dialer step. The check reads the global store, not the channel tool's local list. Expected: a suppressed lead returns a hard "do not contact" from the check and no channel step proceeds.
Backfill the global store from every channel tool's existing suppression or unsubscribe list, deduped by normalized email. Expected: the backfill count matches the union of the old per-channel lists, and spot checks find no missing names.
Sync opt-outs in both directions going forward: an unsubscribe recorded in the mailer writes to the global store, and the LinkedIn step reads the global store before each send. Expected: unsubscribe from email in the morning, and a LinkedIn send attempt that afternoon gets blocked with the suppression reason logged.
Log every suppression-blocked attempt with lead id, channel, and the opt-out source, and surface these in the agent's daily run report. Expected: the run report shows blocked attempts instead of silently skipping, so an operator can see the guardrail is actually firing.
Use this when
- a lead unsubscribes on one channel but outreach continues on another
- the suppression list lives inside one tool and other tools can't see it
- the agent treats "email opt-out" and "do not contact me" as different things
Not for this skill when
- unsubscribes fail inside a single channel (see the per-channel unsubscribe skills instead)
- the problem is deliverability, spam complaints, or blocklisted domains
- the lead never opted out and you just want fewer touches - that is pacing, not suppression
Variant phrasings
- cross-channel opt-out ignored: lead opts out of email, still gets LinkedIn InMails
- suppression list split across tools: mailer has its own list, dialer has another
- agent honors email unsubscribe but the LinkedIn sequence keeps running
- channel-level vs person-level do-not-contact mismatch
Why it happens
Suppression grew up per channel because each tool ships its own unsubscribe list, and the agent treats each channel step as an independent job. So the email step consults the mailer's list while the LinkedIn step consults nothing, and an opt-out in one universe is invisible in the other. The root fix is inverting the lookup: suppress the person, not the channel.
Edge cases
- A lead opts back in on one channel - decide your policy up front (re-opt-in usually clears only that channel, not the global flag), and log which choice was made.
- LinkedIn connection requests to someone who unsubscribed from email - treat "no contact" as global unless your policy explicitly carves out an exception.
- Suppression keyed on email breaks when the lead changes jobs - key on a stable lead id where possible, and carry the flag when records merge.
- Some tools cache their local suppression list - after a fan-out write, confirm the downstream list actually updated before the next send window.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_GsLbEei0bff0wQ5sHDqBZw