Clay Enrichment Waterfall

The problem

Enrichment credits are finite and most GTM lists burn them uniformly — a paid contact lookup fires on every row, and the team discovers afterwards that most of those rows were never going to buy. The cost is invisible because it shows up as a platform bill, not as a failed campaign.

The fix is ordering. If a free signal can tell you which rows are worth enriching, it has to run first, on the whole list, before a single credit is spent.

What was built

An eleven-column formula design that scores every imported row for velocity collapse, followed by a proposed four-step contact-finding waterfall where every step is conditionally gated on that score. No persistent Clay table or usage ledger is included.

The signal

The score is not "does this account fit the ICP" — it is "is this account in pain right now." A seller whose 30-day rating volume has fallen well below its own 90-day monthly average, while that 90-day average is itself at or below the 12-month average, is losing volume actively rather than simply being small.

m90_monthly    = d90 / 3
m365_monthly   = d12 / 12
qualifies      = lifetime >= 120 AND d90 >= 12 AND d12 >= 60
                 AND d30 < 0.6 × m90_monthly
                 AND m90_monthly <= m365_monthly
signal_score   = (0.60 × f_magnitude
                + 0.30 × recent_drop
                + 0.10 × f_reputation) × 10

qualifies is a formula rather than a provider lookup. It does not purchase a provider data point; actual platform Action accounting depends on the workspace and is not captured here.

The waterfall

A contact_source column records which step produced each result, so every contact in the table is auditable back to the method that found it. Nothing from step 4 is ever sent without human verification.

The consumption model

Measured in this build

• 20 rows scanned, 6 qualified — only those 6 ever entered the paid waterfall.
• No contacts were found for the six fictional people.
• This hit rate is artificially low because the synthetic people do not exist. It is not a claim about real-world match rates.

Not measured

The committed artifacts contain no workspace usage or billing export, so they do not establish Actions, Data Credits, external-provider charges, dollars spent or cost per qualified lead. Clay documents Actions and Data Credits as separate units; this case does not convert between them.

Hypothetical row-volume effect

If the same paid operation would otherwise run once on every row at a constant per-row consumption, gating 14 of 20 rows reduces eligible paid executions from 20 to 6, or 70 %. The earlier 350-credit versus 105-credit example was assumed arithmetic, not a measured bill. Actual savings require the table's usage ledger and usable-contact yield.

Verification

The scoring model ships as signal_score.py in the repo, reimplemented from scratch and verified to reproduce the committed baseline exactly — 20 scanned, 6 qualified, 4 in the beachhead segment, and all six scores matching to two decimal places, with the same decay-shape distribution. The Python implementation and the Clay formula translation are checked against each other rather than either being taken on trust.

python3 signal_score.py

Standard library only — no API key, no network, no dependencies.

What is real and what is not

• Real: the Python scoring logic, documented formula/waterfall design, one live enrichment request and the implementation that reproduces the baseline.
• Synthetic: every seller, person, domain and email — all .example.com, generated for this project.
• Modeled, not measured: the 70 % reduction in rows eligible for the paid path. No credit or dollar saving is established.
• Not claimed: no fabricated screenshots, and no production deployment.