Clay playbook
Lead scoring in Clay: 3 patterns + when to add a sidecar
Every Clay table eventually grows a scoring column. Here are the three patterns that actually hold up — and the point at which each one starts to bend.
1. The formula column
Fastest to build, cheapest to run. Combine fit signals (employee count, industry, tech stack) into a weighted sum with a Formula column. Great for the first 1–2k rows.
Where it breaks: you can't rank a row against the rest of the table. A score of 73 means nothing unless you know whether that's the top decile or the median. Clay formulas operate row-local — they don't see siblings.
2. The AI column
Use an AI column to rate each lead 0–100 against a prompt. Surprisingly good for nuanced fit ("does their job description suggest budget authority?") — but non-deterministic, slow at scale, and you pay per row every time the table re-runs.
Where it breaks: drift. Re-running the same prompt next month produces a different distribution. You can't compare today's score to last quarter's.
3. The HTTP sidecar
Add a Clay HTTP API column that POSTs each row's score to an external store, then GETs back the rank, percentile, or top-N flag. The score itself still lives in Clay; the cross-row math lives in the sidecar.
This is what Tally does. One POST /v1/scores per row, one GET /v1/rank to pull the answer back. Ranking is deterministic, persists across runs, and supports tie policies (competition, dense, all-in, none).
Which one should you pick?
- Formula — under 2k rows, scoring rubric fits in one row.
- AI column — qualitative signals, you're OK with re-scoring monthly.
- Sidecar (Tally) — you need to route on rank or percentile, segment top-N, or compare across tables and time.