How agencies isolate suppression lists when two clients sell to the same ICP

Two clients. Same ICP. Overlapping titles, overlapping companies, sometimes the same person sitting in both sequences by accident.

That is when a shared "global suppression" becomes a trap. Client A gets an unsubscribe. Client B still needs a clean shot at a different offer. Or the reverse: Client B's spam complaint should never quietly erase Client A's warm reply thread.

Isolation is the point. So is compliance. You need both.

The failure mode

Agencies that scale past a few clients often land here:

• One sequencer account with tags instead of workspaces
• One master CSV of "do not contact" that every campaign imports
• Opt-outs that sync sideways into every client list

ProspectingManual's multi-client guide is blunt: shared infrastructure starts failing around three active clients because one complaint or blacklist event can touch everyone in the pool. Suppression is the quieter cousin of that failure. Cross-client contamination looks like "hygiene" until a buyer asks why you stopped emailing a contact who only opted out of a different brand.

Isolate first, then sync carefully

Treat each client workspace as its own suppression boundary:

1. Opt-outs, hard bounces, spam complaints, and legal holds for Client A live in Client A's workspace
2. Client B never inherits those rows by default
3. A human can promote a row into a shared agency blocklist only when the reason is agency-wide (hostile threat, known litigator, regulator request)

That matches how strong suppression architecture is described elsewhere: a registry you control, reason codes, and mirrors in every tool that can send. The agency twist is that the registry is scoped per client, not one soup for the whole book.

LeadHaste's framing helps: every sending tool should obey one control, and that control should survive vendor changes. For agencies, "one control" means one control per client, with an optional narrow shared layer for true agency-wide blocks.

What belongs in a shared agency blocklist

Keep this list short and boring:

• Explicit legal or regulatory holds that apply to your agency, not just one brand
• Addresses that filed a spam complaint against your agency infrastructure (mailbox or domain pool) rather than a single client's offer
• Known bad actors your counsel told you never to contact again

Do not dump every client unsubscribe into the shared list. That starves every other client that sells into the same ICP and creates a false sense of compliance theater.

Reason codes stop the next argument

Every suppression row needs at least:

• Email (normalized lowercase)
• Optional person or company key when available
• Reason: unsubscribe, hard_bounce, complaint, legal, client_request, agency_block
• Source system and timestamp
• Client workspace id

Reason codes let you answer the only question that matters in an audit: why is this address blocked, and for whom?

Mailflow Authority and Email Almanac both stress real-time or near-real-time sync into every sender. Agencies should add one more rule: sync stays inside the client boundary unless the reason is agency_block.

Same ICP, different product

When two clients sell into the same titles:

• Run separate workspaces, domains, and suppression lists
• Deduplicate enrollment across clients only when your contracts require it (some agencies promise "we will not pitch the same person for two clients in the same quarter")
• Document that promise as a business rule, not as a silent global unsubscribe

If Client A already has an open positive reply, do not let Client B's sequencer invent a second conversation. Pause B's enrollment for that person. That is orchestration, not suppression.

Prove isolation with a seed test

Once a month:

1. Suppress a seed address in Client A only
2. Confirm Client A's next campaign blocks it
3. Confirm Client B can still enroll the same seed (unless an agency-wide rule applies)
4. Diff each workspace's native suppression export against its registry

LeadHaste's advice applies here: seed a known address, then attempt a send from each tool. Any tool that lets it through is not reading the source of truth.

What GTM expects you to keep separate

GTM runs outbound in client-isolated workspaces with a compliance gate that refuses a send without a verdict and an unsubscribe URL. Suppression that survives purge is a product requirement, not a nice-to-have. The agency ops takeaway is the same: keep Client A's opt-outs from rewriting Client B's universe, and keep a thin shared blocklist only for true agency-wide risk.

If you are building that motion now, join the waitlist.

Sources

• https://prospectingmanual.com/cold-email/scaling/scaling-to-multi-client/
• https://leadhaste.com/blog/email-suppression-list
• https://mailflowauthority.com/email-automation/suppression-list-management
• https://reviewmyemails.com/emailalmanac/industry-standards-and-best-practices/data-hygiene-suppression-standards/cross-system-suppression-sync
• https://reviewmyemails.com/emailalmanac/automation-and-triggers/cross-system-automations/sync-suppression-lists-across-apps
• /workspace/trygtm/knowledge/product.md