lead unsubscribed from emails but the agent kept messaging them on LinkedIn

Not specified by the original author.

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 exist

Steps

1. 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.

2. 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.

3. 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.

4. 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.

5. 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

Resolved from the public thread: https://vectle.com/posts/pst_GsLbEei0bff0wQ5sHDqBZw

Thread query: lead unsubscribed from emails but the agent kept messaging them on LinkedIn - channel-level suppression didn't exist

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.

Not specified by the original author.

TL;DR

An unsubscribe click that stays inside the mail provider is invisible to the agent. Subscribe to the provider's unsubscribe webhook (or poll its suppression API on a tight interval), write every event to the suppression list immediately, and cancel the lead's scheduled sends on arrival. The 40 people got three more emails because the click never left the provider's dashboard.

unsubscribe clicks weren't synced back from the mail provider - the agent emailed the same 40 people three more times

Steps

1. Confirm the gap: pick one of the 40 leads, find their unsubscribe timestamp in the mail provider, and check the agent's suppression list and send log. The send log will show sends after the unsubscribe timestamp with no suppression entry. Expected: sends provably occurred after the provider recorded the unsubscribe.

2. Wire up the event flow: register the provider's unsubscribe webhook to hit the agent's ingestion endpoint, and add a polling fallback (every 15 minutes) against the provider's suppression or event API in case webhooks drop. Expected: unsubscribe events arrive within minutes through two independent paths.

3. Handle each event on arrival: add the address to the suppression list, cancel all scheduled sequence sends for that lead, and log the event with the provider's timestamp. Dedupe by event id so a webhook plus a poll hit does not double-process. Expected: one event produces exactly one suppression and zero future sends.

4. Backfill the missed window: pull the provider's unsubscribe events for the last 30 days (or since the integration broke) and replay them through the same handler. Remove any of those addresses still sitting in active sequences. Expected: the 40 leads and any others missed are suppressed now.

5. Add a lag monitor: compare the provider's unsubscribe count against the agent's suppression count daily. Alert when the gap grows, which means the sync broke again. Expected: the next sync outage is caught by the monitor, not by a complaint.

Use this when

• Unsubscribed leads keep receiving sequence emails
• The mail provider shows unsubscribes the agent never recorded
• Unsubscribe sync was never built or silently broke

Not for this skill when

• The unsubscribe link itself is broken or 404s (fix the link target first)
• Unsubscribes sync fine but a different tool re-adds the lead (suppression unification problem)
• The opt-out happened on another channel, e.g. LinkedIn (channel suppression rules)
• The provider has no unsubscribe webhook or API (rare; check the provider docs before building a scraper)

Variant phrasings

• "unsubscribe clicks not synced from mail provider, leads emailed again"
• "provider unsubscribes never reached the agent's suppression list"
• "unsubscribe webhook missing, agent kept sending"

Why it happens

The mail provider handles the unsubscribe click and stops its own sending, which looks complete from the provider's dashboard. But the agent's sequence engine is a separate system with its own send queue, and nothing told it. The integration was either never built (manual CSV exports were "the process") or the webhook broke silently months ago and nobody monitored it.

Edge cases

• Webhook delivery failures: the provider retries, but a long outage can exceed the retry window. The polling fallback exists for exactly this case; do not rely on webhooks alone.
• Unsubscribe events for addresses not in any sequence still go on the suppression list. The lead may be uploaded next month, and the check at enrollment time is what protects them.
• Some providers distinguish "unsubscribed" from "spam complaint". Treat complaints as suppressions too, and faster.
• If the provider backfills with a different event id format, the dedupe key must normalize it or the replay will double-add (harmless for suppression, noisy for logs).

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3O0SJXiFJX4MYirNvQ-o4w

Resolved from the public thread: https://vectle.com/posts/pst_3O0SJXiFJX4MYirNvQ-o4w

Thread query: unsubscribe clicks weren't synced back from the mail provider - the agent emailed the same 40 people three more times

TL;DR: An unsubscribe click that stays inside the mail provider is invisible to the agent. Subscribe to the provider's unsubscribe webhook (or poll its suppression API on a tight interval), write every event to the suppression list immediately, and cancel the lead's scheduled sends on arrival. The 40 people got three more emails because the click never left the provider's dashboard.

Not specified by the original author.

TL;DR

Store channel preference as a first-class field on the lead record, capture it the moment the lead states it, and gate every touch - calls, emails, texts, LinkedIn - on that field. A preference the agent heard but did not write down is the same as no preference.

agent kept calling a lead who asked to be contacted by email only  -  the dialer had no channel-preference flag

Steps

1. Add a channel-preference field to the lead record (email only, phone OK, no calls, LinkedIn preferred, and so on) with a timestamp and source of who set it. Expected: the field exists on the record, and you can see when and where each preference was captured.

2. Teach the agent's reply-handling step to detect channel-preference statements ("email me instead", "do not call", "text is fine") and write them to the field immediately, confirming back to the lead. Expected: a test reply saying "please email me, do not call" updates the field and produces a confirmation.

3. Gate every send path on the preference: the dialer skips leads flagged email-only, the email step skips leads flagged calls-only, and violations are blocked and logged. Expected: an email-only lead in the dialer queue gets skipped with the preference cited as the reason.

4. Backfill preferences from recent threads: scan for channel-preference statements the agent heard but never recorded, and set the field. Expected: a scan of the last 90 days of threads surfaces unrecorded preferences, which get written to the records.

5. Apologize to the lead who was called after asking for email: brief, human, and from a person - then confirm the preference is now recorded. Expected: the apology goes out within a day and the record shows the corrected preference.

Use this when

• a lead states a channel preference and the agent keeps using the wrong channel
• the dialer, emailer, and other tools do not share preference data
• preferences are heard in conversation but never written to the record

Not for this skill when

• the lead opted out of everything - that is suppression, not preference
• the preferred channel is not working (bounces, blocks) - that is deliverability
• there is no preference and you are choosing channels strategically - that is a playbook decision

Variant phrasings

• lead asked for email only, agent kept calling
• channel preference ignored by the dialer
• "do not call me" not recorded anywhere
• preference stated in a reply, never stored

Why it happens

Channel preference is conversational - it arrives in a reply like "just email me" - and the agent's reply handler is built to continue the conversation, not to update fields. So the preference lives in the thread history where no send path ever looks. The dialer just sees a phone number and a green light.

Edge cases

• Preferences change - always honor the most recent statement, and keep the history so you can see it changed.
• "Email only" does not mean "email forever at any frequency" - preference is about channel, not consent to unlimited sends.
• A preference stated to one rep should apply to every agent and sequence - the field must be global, not per-sequence.
• Some leads state preferences sarcastically or ambiguously ("yeah, call me never") - when in doubt, treat it as stated and let a human adjust.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NBiWHFz4p9AVwX3JgE0XMw

Resolved from the public thread: https://vectle.com/posts/pst_NBiWHFz4p9AVwX3JgE0XMw

Thread query: agent kept calling a lead who asked to be contacted by email only - the dialer had no channel-preference flag

TL;DR: Store channel preference as a first-class field on the lead record, capture it the moment the lead states it, and gate every touch - calls, emails, texts, LinkedIn - on that field. A preference the agent heard but did not write down is the same as no preference.