Clay for RevOps: Enriching Your CRM with Custom Data that Converts

Clay gives RevOps a way to fill the CRM with the fields that actually decide who gets worked: your own industry categories, revenue potential, buying signals, and validated contact data. It pulls from 150+ providers and AI research, writes back to Salesforce, Dynamics, or any CRM with an API, and keeps doing it as new records arrive. This page covers when to bring Clay in, what gets in the way, and the three plays to run first.

We are RevOps Shop, an official Clay partner. Our largest Clay build enriched 170,000 accounts in a single Salesforce org and now enriches about 800 new records a day in real time. We build in your Clay workspace, with your keys, so the work stays yours.

When should RevOps implement Clay?

Bring Clay in when a decision depends on data your CRM does not have. The most common moments are a CRM replatform or consolidation, a new territory or account capacity model, slow speed to lead, reps working the wrong accounts, a database full of personal emails, and contact data that is decaying with nobody watching it.

You are replatforming or consolidating CRMs. A migration is the cheapest moment to fix data. You are already mapping fields and deduping records. Enrich and normalize before the load, and the new CRM starts clean instead of inheriting ten years of guesses.

You are building a territory model or an account capacity model. Territories need a sizing field you trust. Employee count alone rarely works. At Chaos, enriched seat potential let the company split its sales team into an Inside tier (5 to 20 seats) and a Strategic tier (20+ seats), and Clay now fills that segment on every new account. Without the data, a capacity model is a spreadsheet of assumptions.

Speed to lead is slow. If a rep opens a new demo request and has to research the company and hunt for a phone number, minutes turn into days. At DealRoom, a high-intent form fill pushes the contact into a Clay phone waterfall, and the best available number is written back to the record before the rep sees the alert.

Reps are reaching out to the wrong accounts. When Elastic Path reviewed its fiscal year, every won deal was greenfield or a homegrown build. So targeting was narrowed to accounts showing those signals. Re-running 4,887 old ideal-customer accounts through the signal check left 543 worth targeting.

Your CRM is full of personal emails or unknown companies. 37% of Chaos customer accounts signed up with a personal email and no company attached. Nobody could route, size, or segment them.

Contact data is decaying and nobody owns it. People change jobs and emails die. Elastic Path enriched 12,461 suppressed contacts, found 7,246 job changes, and wrote 4,923 validated emails back to the CRM.

You bought Clay and it never got connected to the CRM. This is common. The tables work, but the data lives in Clay instead of in front of reps.

What roadblocks does RevOps hit when getting started with Clay?

The usual roadblocks are picking the wrong Clay plan, Salesforce sync details like external IDs and picklists, fear of overwriting good data, duplicates, Clay's 50,000-row table limit, and failures that happen silently. Each is solvable with design decisions made before the first sync.

The plan does not match the job. Clay's pricing page lists CRM integrations, webhooks and HTTP API calls on the Growth plan and above. Launch tables run up to 50,000 rows. Bulk enrichment of more than 50,000 records at once and Clay's API are Enterprise features. Check this before you design a real-time flow.

Salesforce sync details. Clay can import from Salesforce reports and list views, look up records (including with SOQL), and create, update or upsert them. Upsert needs an external ID field. Imports sync every 24 hours by default. Picklist values must match exactly, so AI output has to be normalized to your picklist before it writes. Use a dedicated integration user with field-level permissions limited to the fields Clay should touch.

Fear of overwriting good data. Reasonable. The fix is a field architecture where enriched values land in dedicated fields and Clay fills blanks but never overwrites what reps entered or what billing owns. At Chaos, company data writes to enriched fields so customer billing details are never touched.

Duplicates. If three people from one company sign up, you do not want three company lookups or three new accounts. Match on domain, email and LinkedIn URL before creating anything, and keep a shared company table so each company is enriched once.

The 50,000-row limit. Every Clay table caps at 50,000 rows, and each webhook source has its own 50,000-call limit. There is no warning beyond the counter. Plan the migration at 40,000 rows and finish it by 48,000.

Silent failures. When credits drop low, scheduled tables can skip cells without an error. Each data provider has its own credit balance that Clay does not show. Providers change their APIs. The symptom is a field that stops filling, not an alert.

No staging. Never point a webhook at your production CRM until the flow has run against a sandbox or a test object. Test on a small sample first.

Unclear ownership and keys. IT will ask who owns the Clay account, the AI keys and the data. Our answer is always the client. At DealRoom, the Clay account, scraping key and AI key are all owned by DealRoom. We build and maintain the workflows.

What benefits does RevOps see from using Clay?

RevOps teams get CRM fields that predict conversion, territories and tiers built on real potential, faster speed to lead, a cleaner database, and more control over data cost and vendors. Leadership also gets a truer picture of the customer base, which often changes strategy.

Fields that convert. DealRoom built a signal engine fed by four Clay workflows: acquisitions, M&A press releases, new hires, and job posts. Coverage grew from 1,300 to 18,500 companies, about 7,200 signals were generated in a quarter, and demo-to-SQL went from 10% to 20% in 90 days. No new hires were needed. We go deeper on signals in Clay for Sales.

Territories built on potential. Seat or deal potential per account turns a territory model from a guess into a sizing exercise.

Faster first touch. Enrichment happens before routing, so the record is complete when the rep opens it. At Chaos, a new order becomes a scored account in Salesforce in 12 to 14 minutes.

A cleaner database. Elastic Path re-validated about 12,000 emails and brought back 970 contacts that had been marked invalid. The same project removed 214 duplicate records.

Cost and vendor control. Across 200,692 records at Chaos, total data cost was $10,573, or $0.0527 per record, including AI, Clay credits and direct APIs. And when one provider changes, you reorder a waterfall instead of renegotiating a contract.

A truer picture of the business. Chaos leadership believed about 90% of customers were architecture, engineering and construction firms. The enriched data showed about half. That opened new growth segments.

What are the main Clay competitors for RevOps, and where do they fall short?

RevOps teams usually weigh Clay against ZoomInfo, Apollo, Cognism, Clearbit, CRM-native enrichment add-ons, Common Room, and building it in-house with a warehouse and scripts. The common shortfall is control: a fixed data model, one source of coverage, and write behavior you cannot fully govern.

From a RevOps seat, here is what matters most:

Can you define the field? Most vendors give you their industry and their size bands. If your territory model needs seat potential or a custom segment, you need a tool that computes it.

Can you control the write? Many native enrichment tools write straight into standard fields. Clay lets you decide the field, the condition, and whether it may overwrite.

What happens when coverage misses? No single provider covers everything. Clay reports that in its 2025 work email benchmark, no single provider cleared both 95% quality and 90% coverage. A waterfall tries the next source. A single vendor returns a blank.

What happens when a vendor changes? Clearbit was acquired by a CRM vendor in December 2023, shut down its free tools on April 30, 2025, and no longer offers its standalone API to new customers. Persana's standalone platform shut down on May 2, 2026 after it joined Rox. Teams that wired a single vendor straight into the CRM had to rebuild.

What about building it in-house? You can, with a warehouse, scripts and vendor APIs. You also take on the integrations, retries, rate limits and maintenance. Clay is the faster path for most teams, and it connects to data warehouses on the Growth plan and above if you want both.

Where does Clay fit in the RevOps stack?

Clay is the orchestration layer between your systems of record and your data sources. The CRM stays the source of truth for reporting. Clay reads records in, runs the waterfall and the AI steps, and writes governed values back to dedicated fields. Signals become their own records so you can count them over time.

We design every build around four kinds of data:

The events row is the one most teams miss. At DealRoom, PitchBook's public pages only show a company's five most recent acquisitions. If you overwrite one field each month, you lose history. Storing each acquisition as its own record, with the real deal date, is what makes "acquired something in the last 180 days" countable.

What are the 3 most important Clay plays for RevOps to run first?

Run these three first: governed CRM enrichment with custom fields, a revenue potential and tiering model that maintains itself, and enrichment at the moment of conversion for speed to lead. Together they fix who gets worked, in what order, and how fast.

Play 1: Governed CRM enrichment with custom fields

1. Pick the fields that change decisions. Usually a custom industry, a size or potential field, and validated contact data. Not fifty columns.
2. Build the waterfall cheapest first. Free and low-cost lookups run before expensive ones. AI only runs where vendors come back empty. At Chaos the waterfall used 11 to 14 providers, with Claygents and a custom AI scraper filling gaps.
3. Use deterministic scraping before AI judgment. DealRoom moved its industry classifier from an agent-only approach to scraping the website with Firecrawl and then classifying, after the agent-only version produced misclassifications and inconsistent re-runs.
4. Add confidence and keep blanks visible. Every AI answer gets a 1 to 10 confidence score. What you could not find is information too.
5. Normalize to your picklist and write to dedicated fields. Clean company names before lookups. Upsert on an external ID in Salesforce.
6. Backfill in batches, then go real time. Split large backfills across tables to stay under 50,000 rows. Then trigger enrichment from the CRM by webhook on new records.

Play 2: Revenue potential and tiers that maintain themselves

A territory or capacity model is only as good as the field it sorts on, and only stays good if accounts move between tiers automatically.

1. Define revenue potential your way. Chaos estimated potential seats from the number of people in target roles at each account, by industry. A one-seat Gmail signup turned out to be Parsons Corporation, with 16,500 employees and room for 407 seats.
2. Define tiers from your own deal history. DealRoom built three tiers anchored on acquisition activity, refined by industry and region, from an analysis of its 2025 deals.
3. Compute the tier, do not hand-assign it. Criteria re-evaluate when data changes. An assignment flow sets the tier when an account qualifies. A removal flow clears it when it stops qualifying. The result is a living target account map.
4. Allow overrides, with review. Reps can request a tier change through a field. Someone reviews before it applies.
5. Rebalance capacity from the data. With tiers filled on every account, you can count accounts per rep per tier and see where capacity is short.

Play 3: Enrichment at the moment of conversion

1. Trigger on high intent. A demo request or pricing form sets a flag that sends the record to Clay.
2. Enrich before routing. Company, size, custom industry and revenue potential land first, so routing rules have something to route on.
3. Run the phone waterfall. The best available number is written back before the rep opens the alert.
4. Give the rep context in the task. At DealRoom, every call task includes a "Before you dial" block with two peer customers in the prospect's industry and one relevant case study with a one-line highlight.
5. Validate email. Mark invalid emails so sequences skip them, and send invalid contacts back through Clay to find a new company or address.

How should RevOps communicate these plays to the team?

Roll out one play at a time, train each group for about 30 minutes before go-live, show reps the new fields inside the record they already use, give each rep one alert channel, and publish a simple map of which field comes from which workflow. Then measure whether signals actually get worked.

Here is the pattern DealRoom used to launch signal selling:

• One play per week. Acquisitions first, then the next signal the week after. Reps learned each playbook before the next one fired.
• A 30-minute training per signal type, before it went live.
• One alert channel per rep. These replaced a shared alert channel that generated noise without ownership.
• A task queue per signal type, so reps worked from one list instead of hunting through reports.
• A "signal worked" flag stamped when a rep logs a call or email, so managers can see which signals get followed up.

What each group needs to hear:

Write a one-page properties map that lists every enriched field and the workflow that writes it. When a field comes up blank in a real task, anyone can walk the map backward to the source.

How do you keep CRM enrichment healthy after launch?

Check row counts, credits, errors and scheduled runs on a fixed cadence. Most Clay failures are silent: a field stops filling and nobody notices until a rep opens a blank task. A short monthly checklist and three monitoring fields catch nearly all of it.

• Every two weeks: read row counts on high-volume tables. Plan a migration at 40,000 rows and finish it by 48,000.
• Every two weeks: check Clay credits and each provider's own dashboard.
• Monthly: filter each major table for errors and spot-check ten. If they all come from the same provider on the same column, that provider changed something.
• The day after each scheduled run: confirm it ran, new values landed in the CRM, and errors are near zero. If a run skips twice, open a support ticket with Clay.
• Always on: requested date, completed date and an open-request flag on each record, feeding a failure dashboard.

When a table hits the limit, duplicate it with a [2] suffix, drop deprecated columns, pause the original instead of deleting it, repoint the webhook, rewire anything downstream, and run a smoke test.

How much does it cost to implement Clay for RevOps?

We price by the play. Each play we build is a RevOps Sculpture: one play, built in your Clay workspace, on one object type, with one native integration included. Each RevOps Sculpture is $10,000. If more than 100,000 accounts are in scope, or you need a custom integration, we scope it with you.

Three RevOps Sculptures that fix who gets worked, in what order, and how fast:

How RevOps Sculptures are priced:

• One play per Sculpture. Each Sculpture is one play, built and running in your own Clay workspace.
• One object type per Sculpture. A Sculpture runs on one CRM object, such as accounts, contacts or leads. Enriching, deduplicating and standardizing both your accounts and your contacts is two Sculptures, $20,000.
• One native integration included. Your CRM, your marketing automation or sending tool, or your ad platform. Salesforce and Dynamics both have native Clay integrations. A custom integration, such as a CRM Clay can only reach through its API, is scoped separately.
• More than 100,000 accounts in scope? Pricing is scoped. Contact us.
• Clay plan requirements still apply. Some features, like CRM sync and webhooks, are listed on Clay's Growth plan and above.

See every Sculpture side by side on Implement Clay Today: Sales, Marketing, and RevOps Matrix.

Frequently asked questions

When should RevOps implement Clay?

When a decision depends on data your CRM does not have. Common triggers are a CRM migration or consolidation, a new territory or capacity model, slow speed to lead, reps working the wrong accounts, lots of personal emails, and decaying contact data.

Can Clay enrich Salesforce automatically?

Yes. Clay can import from Salesforce reports and list views, look up records, and create, update or upsert them. Upsert needs an external ID field. For real-time enrichment, Salesforce sends new records to a Clay webhook and Clay writes the results back.

Will Clay overwrite data in our CRM?

Only if you let it. We write enriched values to dedicated fields and set rules so Clay fills blanks but never overwrites rep-entered or billing data. Original data stays untouched, and enriched data is clearly labeled.

Which Clay plan do we need for CRM enrichment?

Clay's pricing page lists CRM integrations, webhooks and HTTP API calls on the Growth plan and above. Bulk enrichment of more than 50,000 records at once and Clay's API are listed under Enterprise. Check current plans with your Clay rep.

How do we handle Clay's 50,000-row limit?

Every Clay table caps at 50,000 rows, and each webhook source has its own 50,000-call limit. Split large backfills across tables, use a shared company table, and migrate busy webhook tables to a new table before they reach the cap.

How do we build a territory model with Clay?

Enrich every account with a revenue potential field you trust, such as potential seats by industry. Then compute tiers from that field and your own deal history, with flows that add and remove accounts automatically. Count accounts per rep per tier to balance capacity.

Can Clay help with speed to lead?

Yes. Trigger enrichment on high-intent form fills so company data, revenue potential and a phone number are on the record before routing. The rep opens a complete record instead of starting research. At Chaos, new orders become scored accounts in 12 to 14 minutes.

Who should own Clay, RevOps or marketing?

Both have a role. RevOps owns the CRM sync, field rules, monitoring and cost. Marketing owns the targeting logic and segments. One named owner should be accountable for table health.

What is a RevOps Sculpture?

A RevOps Sculpture is one RevOps play, such as enriching and deduplicating your CRM accounts or a self-maintaining tier model, built in your Clay workspace on one object type with one native integration included. Each one is $10,000. More than 100,000 accounts in scope is scoped separately.

Sources

• Chaos results: RevOps Shop Clay case study and the Chaos CMO presentation to TA Associates portfolio companies.
• Clay plans and limits: clay.com/pricing.
• Clay and Salesforce actions: Clay Docs, Salesforce integration.
• Clay 2025 work email benchmark: clay.com/guides/waterfall-enrichment.
• Clearbit tool shutdowns: clearbit.com/changelog.
• Persana and Rox: persana.ai migration guide.
• Common Room positioning: commonroom.io/compare/clay.
• Clay and Dynamics 365: Clay Docs, Dynamics 365 CRM integration.

Need help with Clay? Contact us.

We start with your CRM, your data and your process, then build in your Clay, with your keys. Salesforce, Dynamics, or any CRM with an API. IT signs off on everything. We work best with B2B companies with at least 100 employees.

Start with one Sculpture, or compare every Sculpture across sales, marketing and RevOps. Already on Clay and a play is not working? We can rebuild it as a Sculpture in your workspace.