Lesson 8 of 8 · 50 min

Capstone: multi-client outbound pipeline design

Timed system-design capstone: multi-tenant outbound control plane across ICP, enrichment, sequences, deliverability, reply ops, and attribution — with isolation, SLOs, failure modes, and an explicit hire rubric.

Assemble the factory for multiple tenants

Capstone: you are the GTM engineer for a small agency (or multi-product company) running outbound for three clients with isolated data, shared platform skills, and strict domain safety. Design the end-to-end system in interview time — ICP → enrich → sequence → deliverability → reply ops → attribution — with tenancy and SLAs. This lesson is a worked mock plus rubric, not new theory.
Prompt (use in mocks): “Design an outbound platform for an agency onboarding Client A (US fintech MM), Client B (EU vertical SaaS, GDPR-sensitive), Client C (US PLG tool with product-intent signals). Shared Clay-like enrichment, per-client sending fleets, HubSpot or Salesforce per client, one internal ops console. Walk through architecture, risks, and metrics.”
Time-box (45–50 min): 5 min clarify, 10 min control plane + tenancy, 10 min data/enrich/score, 8 min sequence+deliverability, 7 min reply+CRM, 5 min metrics/experiments, 5 min risks/Q&A. Narrate tradeoffs aloud — same rubric as SWE design loops.

Clarifying questions (say them)

  1. 01Volumes — contacts/week per client? meetings targets?
  2. 02CRM — each client brings HubSpot/SFDC or you host?
  3. 03Regions — data residency and legal basis for cold email?
  4. 04Channels — email only or multi-channel?
  5. 05Staffing — who handles positives, 24/7 or business hours?
  6. 06Success metrics — meetings, pipeline $, or retained client NPS?
  7. 07Constraints — budget caps for enrichment; existing domains?

Reference architecture

text
1MULTI-CLIENT OUTBOUND CONTROL PLANE23  [Tenant policy store]  icp_version, waterfall, sequence graphs,4                        domain fleets, SLA clocks, suppress lists5  [Identity + scoring]  per-tenant features; no shared person cache6                        across tenants without contract7  [Enrichment workers]  shared code, per-tenant API keys + credit meters8  [Sequence engine]     graph executor; stop on reply; rate limits9  [Send fleet mgr]      per-tenant domains/mailboxes; health scores10  [Reply ops]           classify → route to client owner map → CRM11  [Event bus]           enroll/sent/bounce/reply/meeting (tenant_id)12  [Warehouse views]     per-tenant dashboards + agency rollup (meta)1314  Hard rule: tenant_id on every row, key, and log line.
Shared code, isolated data and credentials. Agency rollup metrics must not expose Client A’s contact-level data to Client B users. RBAC on the ops console is part of the design, not an afterthought.

Per-client policy differences

text
1TENANT DIFFERENCES (examples)23  Client A fintech US:4    ICP strict; phone optional; catch-all discouraged; reply SLA 10m5  Client B EU SaaS:6    lawful basis review; softer volumes; richer suppress; geo routing EU7  Client C PLG:8    product-intent features; suppress active users; lifecycle co-exist910  Same engine, different policy documents + feature flags per tenant.

Worked spine — Client A happy path

Narrate once end-to-end: list import → score v2026-07 → enrich waterfall under $0.30 → validate → enroll arm → send under mailbox caps → positive reply → stop → task to AE in client HubSpot in 10m SLA → meeting booked → events to warehouse → weekly band calibration. Then name two failure injections: vendor outage; bounce spike.
  1. 01Vendor outage — skip provider, degrade coverage, alert, do not block forever.
  2. 02Bounce spike — throttle fleet, freeze enrolls, hygiene loop, client comms.
  3. 03CRM down — queue write-backs; do not stop acknowledging replies internally.
  4. 04Cross-tenant misconfig — page sev-1; key/namespace audit; customer notice process.
  5. 05Credit exhaustion — pause enrich for tenant; surface budget owner.

Capstone rubric

text
1CAPSTONE HIRE RUBRIC (score 1–4 each)23  1. Control plane clarity (states, events, tenant_id)4  2. ICP + scoring versioning and suppressions5  3. Enrichment waterfall economics + validation6  4. Sequence graph stops, capacity, HITL7  5. Deliverability architecture + incident response8  6. Reply ops SLA + CRM write-back idempotency9  7. Attribution honesty + experiment hooks10  8. Multi-tenant isolation + least privilege11  9. Metrics / SLOs / kill criteria12 10. Communication under timebox (waypoints)1314  Strong hire: ≥3 on most, no 1s on isolation or stop-on-reply.15  No-hire patterns: tool tour only; shared caches across clients;16  no bounce budget; Slack-as-SoR; single ROI decimal to board.

Interview narration script (condensed)

“I’ll design a multi-tenant control plane. Each client has policy: ICP version, waterfall, sequences, domains, CRM credentials. Shared workers execute with tenant-scoped keys. Contacts move discovered→scored→enriched→valid→sequenced→replied. Enrichment is a confidence waterfall with validation before send. Sequences stop on reply/bounce/unsub with backpressure to protect domain fleets. Reply ops classifies and assigns with SLA into the client CRM idempotently. We measure with event streams and experiments, not a single Lead Source field. Biggest risks: cross-tenant leakage and deliverability incidents — both get explicit runbooks.”

Drill: whiteboarding checklist

text
1BEFORE YOU END THE MOCK — CHECK23  [ ] Tenancy boundary drawn4  [ ] State machine or stages listed5  [ ] MVE fields + waterfall accept rule6  [ ] Stop-on-reply and booking stop7  [ ] Domain isolation from primary corp mail8  [ ] Bounce/complaint budgets + throttle9  [ ] Reply SLA + atomic owner10  [ ] Event list for attribution11  [ ] One experiment design12  [ ] Two failure modes + mitigations13  [ ] Explicit non-goals (what you won’t build yet)

Self-score exercise

Record yourself on the prompt for 40 minutes. Score the rubric honestly. Rewrite only the two weakest dimensions. Repeat with Client B GDPR constraints emphasized. Ship a one-page architecture note to your portfolio if you interview for GTM eng roles.

Failure injection table (practice saying these)

text
1FAILURE → DETECT → CONTAIN → RECOVER23  Cross-tenant key misconfig4    detect: audit log / canary contact5    contain: freeze affected workers; rotate keys6    recover: re-encrypt if needed; client notice runbook78  Bounce storm client A9    detect: rolling hard_bounce% alert10    contain: throttle A only; keep B/C sending11    recover: hygiene + ramp; RCA to client1213  CRM write-back lag14    detect: reply without task > SLA15    contain: secondary notify queue16    recover: replay idempotent events1718  Enrichment budget blowout19    detect: spend anomaly20    contain: circuit break tenant enrich21    recover: sample dry-run; fix list filters
  1. 01Q: How do you onboard a fourth client in a week? Tenant config templates, domain warmup checklist, CRM OAuth, ICP workshop → versioned score, seed list validation, dry-run sequence with internal seeds, then ramp. Timebox human work; automate the rest.
  2. 02Q: Shared enrichment credits or per-client? Per-client meters for cost attribution and noisy-neighbor control; shared volume discounts negotiated underneath without shared data caches.
  3. 03Q: What do you defer on day one? Exotic multi-touch MTA UI, fully automated phone, custom ML ranking — keep rules scoring, solid waterfall, stops, and reply SLA first. Depth before breadth.
After this track you should refuse Zapier-pile answers on principle: every outbound design starts from states, SLAs, tenancy, and error budgets. Pair with gtm-stack-automation when the interview goes deep on CRM objects, lifecycle stages, and RevOps governance — this track owns the outbound execution spine.
  1. 01Pass bar — tenancy + stops + bounce SLO + reply write-back named without notes.
  2. 02Strong — failure injections, experiment hooks, cost meters, explicit non-goals.
  3. 03No-hire — tool tour, shared PII cache, no kill criteria, Slack-as-SoR.
The capstone is not a tool demo. It is proof you can own reputation, data boundaries, and revenue ops as one system.
articleClay — GTM engineering resourcesClaydocsGoogle email sender guidelines (fleet baseline)GoogledocsSalesforce multi-tenant integration patterns (conceptual)SalesforcedocsHubSpot private apps / integration authHubSpot

Checkpoint

Agency design shares one Redis cache of emails across all clients for “efficiency.” Verdict?

AGood optimization — emails are public enough that tenancy is optionalBReject: per-tenant data isolation required; share code/workers not contact payloadsCAccept if encrypted with a single agency master key
Sign up free to answer and see why

Checkpoint

In the capstone mock, where should you spend the first five minutes?

AListing every SaaS tool you have used with pricing tiersBClarify volumes, CRM, regions/legal, channels, SLAs, success metrics — then sketch control planeCWriting email copy samples for three personas
Sign up free to answer and see why

Checkpoint

Client C PLG active users start receiving cold sequences. Which control failed?

ADeliverability only — spam filters should have caught itBSuppression sync from product/CRM into eligibility; outbound enrolled without active-user Z-bandCReply ops SLA — if they reply “already customer,” it’s fine
Sign up free to answer and see why

Checkpoint

You must pick one kill criterion for the whole multi-client platform’s automated throttle. Best default?

AOpen rate below 50% across any tenantBPer-tenant hard bounce or complaint budgets exceeded on rolling window → throttle that tenant’s fleetCAny single AE missing a reply SLA once
Sign up free to answer and see why

Checkpoint

Strong closing line in a GTM eng design interview?

A“So basically we’d just use Clay and Instantly like everyone else.”B“Control plane with tenant policies; waterfalls and sequences as workers; stop rules and bounce budgets; reply write-back; events for honest measurement — tools implement these boxes.”C“I didn’t have time for risks; the happy path is enough.”
Sign up free to answer and see why

Ready to run a 45-minute multi-client outbound system design mock against the capstone rubric?

New to itGetting thereConfident

Takeaways

  • Capstone = tenancy + full outbound spine + SLOs + honest metrics.
  • Shared workers, isolated data/keys; stop rules and bounce budgets non-negotiable.
  • Rubric beats tool lists; practice timed narration with failure injections.
  • Track complete: revisit weak lessons; pair with gtm-stack-automation for CRM depth.

Track complete. Schedule a mock on the multi-client prompt and re-score the ten-dimension rubric.

Sources

Free to read · better with Enzo

Learn it with Enzo

Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.

Continue with EnzoSign up free
Capstone: multi-client outbound pipeline design · GTM…