Clay Implementation

Clay is a research engine. Most teams run it as an expensive contact list.

We build waterfalls that stop at the first good answer, tables that only enrich rows worth enriching, and scoring that writes back into the CRM with its inputs attached.

Then we put an orchestration layer around it, because Clay is where the data comes from — not where the process should live.

Enrichment · Scoring · CRM write-back

Clay
n8n
HubSpot
Salesforce
RevPack · enrichment waterfall
Stops at first hit
Row in
Domain + name
P1 · cheapest
Hit rate 62%
Write · stop
Miss 38%
P2 · mid cost
Hit rate 44%
Write · stop
Remaining rows only
P3 · premium
Used on 21% of rows
Write · stop
Unresolved · logged, never silently dropped
Cost per resolved row, not per call
Cached · never re-bought
Where Clay bills go wrong

Credits are spent on rows that were never going to convert.

Enrich first, qualify later

Every row hits every provider before anyone checks whether it fits the ICP. Filter first and the same budget covers several times the volume.

Waterfall ordered by preference

Providers stacked by habit rather than measured hit rate and price, so the expensive one runs on rows the cheap one would have resolved.

The same data bought twice

No cache and no dedupe against the CRM, so last quarter's list gets re-enriched from scratch this quarter.

Clay asked to be the process

No retries, no dead-letter queue, no branching at scale. When a table becomes the workflow engine, failures are silent.

What we actually build

Four Clay builds, all measured per resolved row

Coverage reported per field, not per vendor. Cost reported per resolved row, not per call.

C-01 · Waterfalls

Provider order set by evidence

We measure hit rate and cost per provider on your data, then order the waterfall so the expensive one only sees rows nothing else could resolve.

C-02 · Gating

ICP fit before spend

Rows scored on cheap signals first — firmographics, domain checks, CRM dedupe — so credits are only spent on accounts worth contacting.

C-03 · Research

Claygent research with a schema

Prompted research constrained to a typed output and a source URL, so a human can check the claim instead of trusting a paragraph.

C-04 · Write-back

Into the CRM, with inputs attached

Scores and enriched fields written back with upsert keys and retries, so a re-run is a no-op rather than a duplicate. GTM automation.

Credit economics

Cost scales with rows, not with results

Per-row credit pricing means an unfiltered list of poor-fit accounts costs the same as a filtered list of good ones. That is the whole argument for gating.

Without gating
100%

of rows hit the full waterfall, including duplicates and accounts already in the CRM.

With gating
ICP only

Cheap checks first, premium providers last, cached results never re-bought.

What we report
Per field

Coverage and cost per resolved row, so the waterfall can be re-ordered on evidence next quarter.

On published pricing

Clay's own pricing page varies by toggle and changes often, so we do not quote it here. We will price your actual volume against current plans during the audit and show the working.

Where Clay stops

A data layer, not an orchestration layer

Job
Clay
Orchestration layer
Provider waterfalls
Native, best in class
Hand-built, slower
Research with sources
Claygent, typed output
Possible via API calls
Retries and dead letters
Not the model
Core capability
Branching at scale
Table-level, limited
Explicit paths
Version control
Manual snapshots
JSON export, git
Source: RevPack build log 2025–2026 · see also GTM automation
Questions we get asked

Clay, answered.

Is Clay better than Apollo?

They are different products. Apollo is a database with a sequencer attached — you buy its data. Clay is a research layer that queries many providers, including Apollo, and keeps the first good answer. If your coverage problem is one vendor's blind spots, Clay solves it; if you just need a decent list quickly, it is more machine than you need.

What does Clay actually cost to run?

Credits are consumed per row per enrichment, so cost tracks list size rather than results. Published plan prices change and vary by toggle, so we price your real volume during the audit rather than quoting a number here that dates badly.

Can Clay write into HubSpot on its own?

It can push data, yes. What it does not give you is an upsert key, a retry policy or a dead-letter queue — which is why we put the write behind an orchestration step. HubSpot implementation.

Do we need Clay if we already have n8n?

Only if data coverage is the problem. n8n can call providers directly, and for one or two sources that is simpler. Clay earns its cost when you want several providers in a measured order without maintaining that logic yourself.

Is AI-generated research trustworthy enough to act on?

Only when it is constrained. We require a typed output and a source URL for every researched field, and anything that drives an outbound message goes through a review queue before it is sent. See the Signal Engine.

Next step

Bring your last Clay bill and one real list.

We will measure coverage per field, show cost per resolved row, and tell you where the waterfall is spending money it does not need to.

Audit deliverables · RP-CLY-01
Coverage per field
D-01
Cost per resolved row
D-02
Waterfall re-order
D-03
CRM write-back plan
D-04