Multi-product SaaS: running 3 offers without cannibalizing domain reputation

The situation

The client was a vertical-specific B2B SaaS selling three related-but-distinct products:

Core platform — their flagship, mature, ~$80k ACV median.
Onboarding module — newer, $15k ACV median, often sold as an upsell but increasingly as a standalone entry point.
Analytics add-on — newest, $25k ACV median, mostly sold to existing customers but the team wanted to try outbound.

The growth team had run outbound for the core platform for two years. It was steady — 3.1% positive reply rate, ~110 meetings/month, a reliable pipeline contributor. They wanted to add outbound for products 2 and 3.

The first attempt, three months before I came in, had gone badly. The team had added both new product campaigns onto the existing sending domains. Within 4 weeks:

Core product reply rate dropped from 3.1% to 1.7%.
Onboarding module campaign hit 0.8% reply rate.
Analytics campaign hit 0.6%.
Gmail complaint rate spiked to 0.28%, approaching the problem threshold.

They paused everything. Three weeks of reputation recovery. Then they called me.

The brief was specific: “figure out how to run three distinct outbound programs simultaneously without them breaking each other.”

Why the first attempt failed

Two overlapping causes:

Cause 1 — Overlap in the prospect pool

The three products’ ICPs overlapped significantly. Roughly 40% of target companies for product 1 were also in product 2’s list, and 25% overlapped with product 3.

When each product ran its own sequence, some prospects received emails from all three in a single week. Those prospects reasonably concluded this was spray — and either unsubscribed across all three or reported as spam. The overlap was invisible to the team because each product had its own sequencer instance.

Cause 2 — Shared sending domains

All three campaigns sent from acme.com and its two lookalikes. Complaint rate aggregates at the domain level. So product 3’s higher complaint rate (because its campaign was less tested) dragged product 1’s established domain reputation down with it.

The team’s mental model: three campaigns, same infrastructure. Gmail’s model: one sender, behaving inconsistently. Gmail’s model is what determined inbox placement.

The rebuild architecture

Domain separation

First decision: each product gets its own sending infrastructure. Not a lookalike off the primary domain — a distinct domain family.

Final architecture:

Product 1 (Core Platform) → getacmeplatform.com, hello-acmeplatform.com, acmeplatform-team.com. Three lookalikes. All tied to product 1 only.
Product 2 (Onboarding) → acmeonboarding.com, onboarding-at-acme.com. Two lookalikes. Product 2 only.
Product 3 (Analytics) → acmeanalytics.io, analytics-acme.com. Two lookalikes. Product 3 only.

7 sending domains total. Every domain had its own DMARC record (all at p=reject, see DMARC setup for outbound), its own SPF with one include, its own warmup history.

Cost of this: 7 domains × $10/year registration + slightly more on the sending tool licensing (tiered per-domain). Total added infrastructure cost: ~$180/month. Trivial relative to the program revenue.

Prospect-pool deconfliction

The harder problem. We couldn’t just say “each product picks its own list” — the ICP overlap was real.

Solution: a shared master list with product assignment logic.

Every prospect company gets scored for fit against all three products at list build time.
A company scored 5/5 on product 1, 4/5 on product 2, and 2/5 on product 3 gets assigned to product 1’s campaign first.
If and only if product 1 concludes the sequence (all follow-ups exhausted, no positive reply, or explicit nurture-not-now reply), the company becomes eligible for product 2’s campaign 90 days later.
Product 3’s campaign runs against companies that scored highest on product 3 and are not currently being engaged by product 1 or 2.

Net effect: any given prospect is being touched by exactly one product’s outbound at a time. No overlap. Campaigns run in parallel globally, but sequentially per account.

Implementation: a shared prospect-management layer (Airtable-based initially, moved to a lightweight internal tool at month 4) that all three sequencers queried before adding a company to a send list. If the company was already “in flight” on another product, the campaign wouldn’t pick it up.

Messaging differentiation

Each product’s messaging had to be distinct enough that even in the rare case a prospect did receive emails across products (e.g. if one was missed by the deconfliction layer), they wouldn’t read as related.

Product 1: signed by the growth team lead. Long-form, consultative opener. Offer framed around strategic platform value.
Product 2: signed by the onboarding-team product lead. Short, tactical opener focused on one specific pain (onboarding friction). Never mentioned the core platform in the first email.
Product 3: signed by the analytics product lead. Data-forward opener with one specific customer benchmark. Framed as “analytics tooling” without referencing the broader platform.

Three distinct personas, three distinct value props, three distinct from: addresses. A prospect receiving all three in different months shouldn’t realize they’re from the same company until they clicked through to the website.

(A footnote on “shouldn’t realize” — we weren’t hiding the affiliation. Every email footer disclosed the parent company. The point was that each email read as standalone, not as a multi-product assault from one company.)

Shared reply ops layer

One piece was explicitly not separated: reply handling.

Each product’s campaign fed replies into a single shared reply ops channel, staffed by one reply-ops coordinator plus a backup. The coordinator knew all three products and could route replies correctly:

Positive reply to product 1 → routes to the product 1 AE assigned to that segment.
Positive reply to product 2 → routes to the onboarding-focused AE.
Positive reply to product 3 → routes to the analytics AE.
Cross-sell opportunity detected mid-conversation → escalated to the growth team lead.

Shared reply ops was the right call for three reasons:

Consistency of brand voice on replies. One coordinator ensured all replies felt like they came from the same parent company when it mattered.
Cross-sell signal capture. Prospects sometimes replied to one product’s email asking about another. The shared layer caught these; separate queues would have lost them.
Capacity sharing. Peak reply volumes on each product didn’t always coincide. One coordinator + backup could handle all three more efficiently than three separate reply handlers.

Months 1–2 — Rebuild and rewarm

Month 1 was entirely infrastructure and messaging work. No sends.

7 domains registered, DNS configured, SPF/DKIM/DMARC set.
Warmup started on all 7 domains in parallel (different accounts = different warmup histories, so reputation recovery was fresh across the board).
Prospect-pool deconfliction layer built and tested.
Messaging drafts written for each product (2 rounds each, landed on draft 2 for products 1 and 2, draft 3 for product 3).

Month 2 — staggered low-volume sends across all three programs:

Product 1 ramped first (it had historical muscle memory, and warmup was further along). 400 sends/week by end of month 2.
Product 2 started at 150 sends/week.
Product 3 started at 100 sends/week.

Reply rates in month 2:

Product 1: 3.4% positive (back to baseline, slightly better).
Product 2: 2.1% positive.
Product 3: 1.9% positive.

No complaint-rate issues. Sender reputations on all 7 domains trended up or held steady.

Months 3–5 — Scale and tune

By end of month 3, target volumes:

Product 1: 2,800 sends/week, 3.1% positive reply rate.
Product 2: 1,100 sends/week, 2.6% positive reply rate (after two rounds of copy iteration).
Product 3: 700 sends/week, 2.4% positive reply rate.

Combined, about 4,600 sends/week across the 7 domains. Each domain averaging ~650 sends/week — a healthy, sustainable load per domain.

Complaint rate across the portfolio: 0.07%, well below the 0.10% target.

Meeting volume:

Product 1: ~112 meetings/month (core program held its historical output).
Product 2: ~42 meetings/month (new revenue that didn’t exist before).
Product 3: ~22 meetings/month (new revenue that didn’t exist before).

Combined pipeline contribution vs. the single-program baseline (product 1 alone): 2.8x.

The unexpected find

In month 4, the data showed something useful: prospects who had previously been contacted by product 1 and said “not now, maybe next year” were converting to positive replies on product 2’s outreach at 2x the baseline rate.

Meaning: the prospect rejected the big platform sale (“we’re not ready for a full platform replacement”) but was receptive to a narrower offer (“we do need better onboarding tooling”).

The deconfliction logic was already routing these correctly — 90 days after product 1’s sequence ended, the same account became eligible for product 2. What was unexpected was the lift from the prior touch. Prospects remembered the company. When product 2 approached with a narrower offer, they were warmer.

We formalized this into the playbook: prospects who explicitly “nurture-not-now” on product 1 became a priority segment for product 2 outreach 90 days later, rather than just the default eligibility.

What was specific to this engagement

Three products with real overlap. A company with three genuinely unrelated products wouldn’t need the deconfliction layer. Their outbound would just run separately without concern.
Budget for 7 sending domains. Operationally annoying if the team couldn’t allocate someone to manage domain health across seven properties. Larger teams handle this fine; smaller teams might need to consolidate.
A shared reply-ops coordinator who could actually know three products. Requires training, requires judgment, requires capacity. Not every reply-ops role can do this well.

What was generalizable

For any multi-product company considering outbound on multiple products:

Separate the sending infrastructure, not just the sequencer. Domains are where reputation aggregates. One bad campaign on a shared domain poisons the well.
Deconflict the prospect pool. The same account in three sequences at once reads as spray, even if each campaign is individually excellent. Build the layer that prevents it.
Differentiate the messaging to the point a prospect wouldn’t detect affiliation. Same company, three distinct conversations, different senders. This is more work; skipping it makes the programs interfere.
Share the reply ops layer. Coordinators catch cross-sell signals that siloed reply handling misses.
Warmup is per-domain, not per-program. Each new product’s domain starts fresh. Plan for 3–4 weeks of warmup on each before target volume.

The honest caveats

Month 3 had a scare: a misconfiguration sent 80 prospects both a product 2 email and a product 3 email in the same week. We caught it via reply-ops cross-referencing — the coordinator saw three prospects reply to one and comment on the other. Fixed the deconfliction query, removed the affected prospects from both sequences, moved on. Nobody escalated to complaint.
The shared reply-ops coordinator initially miscategorized about 15% of replies in the first 3 weeks (wrong product, wrong AE). This dropped to under 3% by week 6 after training and a simple labeling guide.
The analytics product (3) never got to target reply rates. We shipped it at 2.4% and the team accepted that as the ceiling for now. Further lift would require copy work we deprioritized.
We didn’t measure what would have happened in a counterfactual where the company had consolidated into one bigger campaign and relied on the sales team to cross-sell. Possible that consolidation would have worked too. The portfolio approach worked; we can’t prove it was optimal.

When a multi-product setup is worth the overhead

The setup in this case study has real overhead — 7 domains, deconfliction logic, messaging across three voices, a reply-ops coordinator with broad product knowledge. That overhead is worth carrying if:

The products sell to meaningfully overlapping ICPs.
Each product can sustain a standalone outbound program on its own economics.
The team has capacity for the infrastructure work upfront.

If your “multi-product” setup is really “one product with features,” you don’t need this. Run one campaign, let the sales team pitch the relevant feature set based on the prospect’s needs.

If your products genuinely sell different things to different buyer personas, you do need this — or a lighter version of it. The cost of not doing it is the reputation damage the client’s team saw on their first attempt. Once that happens, recovery eats 3+ months of pipeline.

Worth planning around.