$ man clay-wiki/enterprise-guardrails

Playsadvanced

Enterprise Account Guardrails

Batch enterprise separately. Isolate big accounts. Cap by domain.

Clay tool avatar

What This Play Does

Enterprise accounts break normal Clay workflows. A company with 50,000 employees can have 200 valid contacts across 15 personas. If you run standard enrichment on a table that mixes enterprise accounts with mid-market accounts, the enterprise rows consume disproportionate credits, overwhelm your enrichment pipeline, and create duplicate problems that are painful to clean up. Enterprise guardrails are a set of rules that isolate large accounts, cap enrichment per domain, and batch enterprise separately from everything else.

Why Enterprise Needs Isolation

When I say "always source enterprise contacts separately," I mean it. Here's what happens when you don't: 1. You import 500 contacts from various companies. 50 of them work at Microsoft. 2. Your email lookup runs on all 500. Microsoft contacts consume disproportionate credits because the same @microsoft.com domain gets processed 50 times. 3. Your persona qualification prompt returns 30 MATCHED personas at Microsoft alone. You now have 30 contacts routed to outreach at one company. 4. Your sales rep receives 30 "new leads" from the same account and immediately distrusts the system. Bigger batches need isolation. Enterprise accounts have more contacts, more personas, more data to process. If they run alongside mid-market accounts, they dominate the table and distort your metrics.
PATTERN

The Domain Cap Rule

Set a hard cap on contacts per domain. For most workflows, 5-10 contacts per company is the maximum you should enrich and route. The cap prevents: • Credit waste — you don't need 30 enriched contacts at one company • Rep overwhelm — sales can't meaningfully work 30 contacts at one account • Deliverability risk — sending 30 cold emails to the same domain flags you as spam Implement the cap in Clay using a formula column that counts contacts per domain. If count > cap, mark the excess rows as "skip — domain cap reached." Enrich and route only the top contacts by persona tier.
PATTERN

Batching Strategy

Enterprise batching follows this structure: 1. Separate enterprise accounts (1,000+ employees) from mid-market (100-1,000) and SMB (<100) 2. Run mid-market and SMB through your standard enrichment flow 3. Run enterprise through a dedicated flow with: • Lower contact cap per domain (5-7 vs 10-15 for mid-market) • Priority persona filtering (Tier 1-2 only, skip Tier 3+) • CRM lookup before any enrichment (enterprise accounts are most likely to already exist in pipeline) • Manual review step for accounts scoring 6-7 (enterprise NEEDS_RESEARCH accounts are worth the human time) The enterprise batch runs separately, often on a different schedule. Don't mix it with your daily on-demand enrichment.
ANTI-PATTERN

Never Enrich Accounts on a Contact Table

This is the most common mistake with enterprise accounts. You import a list of contacts, and some columns are company-level data (revenue, employee count, tech stack). You enrich those company columns on the contact table. Now you have 50 contacts from Microsoft, each with its own enrichment of Microsoft's data — 50 separate API calls returning the same information. The fix: always split to an account table first. Dedupe by domain. Enrich company-level data once per domain on the account table. Then source contacts from qualified accounts. The contact table pulls company data via lookup, not enrichment. This saves credits, prevents inconsistency, and keeps your architecture clean. This is THE pattern. Account table for accounts. Contact table for contacts. Lookup to connect them. Never the other way.
PRO TIP

MX Classification for Enterprise

Microsoft MX means enterprise. When you see "protection.outlook" or "outlook.com" in MX records, the account is running Microsoft 365 — which overwhelmingly means enterprise or upper mid-market. Use this signal in your guardrails: • Microsoft MX + 500+ employees → enterprise batch, LinkedIn outreach via HeyReach (can't deliver reliably to Microsoft from Google-only Instantly setup) • Google MX + any size → standard batch, email outreach via Instantly • Custom/self-hosted MX → enterprise batch, manual review (often government or highly regulated industries) MX classification isn't just about deliverability. It's a firmographic signal that tells you about the company before you even check their employee count.
ANTI-PATTERN

Common Mistakes

Running enterprise accounts through the same automation as mid-market. Every guardrail I described exists because someone (often me) learned the hard way. Enterprise accounts need their own table, their own caps, their own review process, and their own outreach cadence. Another mistake: setting the domain cap too high. If you cap at 25 contacts per domain, you haven't really set a cap. For enterprise outreach, 5-7 is the sweet spot — enough to hit the buying committee, not so many that you look like you're spamming the org chart.

related entries
Data Storage, Batching, and Rate-Limit-Safe EnrichmentAccount-First Enrichment and Credit EfficiencyTAM List BuildingProspecting Contact Cards
← clay wikicontent wiki →
ShawnOS.ai|theGTMOS.ai|theContentOS.ai