What is lead enrichment?

What is lead enrichment?

Lead enrichment is the process of adding data to a lead or contact record, from sources outside your own form or CRM, before a rep works it. A prospect fills in a name and a work email; enrichment appends the rest: job title, company size, industry, tech stack, verified phone, sometimes intent signals. The point of doing this before a rep opens the record is that the rep's first move (who gets it, how fast, what the opener says) should already be decided by the time they see it.

That's the part most explanations of enrichment skip. Enrichment is not a data-quality project. It's an input to two decisions that already exist on every sales team: routing (whose desk this lead lands on, and how urgently) and the first message (what the rep opens with, and whether they open at all). A field that doesn't move either decision is decoration, however complete it makes the record look.

The fields that change a decision, and the ones that just decorate the record

Run every field a vendor offers through one test: if this field were missing, would a rep, a routing rule, or a scoring model behave differently? If the honest answer is no, the field is cosmetic.

The pattern: the fields worth paying for are the ones your routing rules or your rep's opening line already reference. If your team doesn't route by industry, an industry field is free information with no job to do. Enrichment spend should follow the decision, not the other way around: decide what changes the first call or the routing rule, then buy only the fields that feed those decisions.

How enrichment actually runs: the waterfall

No single data provider covers a list on its own, and this isn't a marketing claim, it's the shape of the coverage problem. Clay's own benchmark of work-email providers, run against ground-truth verified data, found:

The mechanism behind that gain is called a waterfall: a predetermined sequence of providers, tried in order, where the search stops at the first one that returns a confident match. Clay describes it plainly in its own documentation: "Waterfalls allow you to utilize multiple data providers in a predetermined sequence, so you don't duplicate tasks or spend extra credits." The providers don't all run on every record. Each record walks the chain until something answers, then stops.

That's also why waterfalls are cheap relative to running every provider on every record. Clay's guide states the billing logic directly: "A waterfall does not cost the sum of its providers. It costs the path each record walks. A record stops at the first confident result, and you are billed only for the lookup that returns it, not for the cheaper sources above that ran and came back empty." Clay's own work-email waterfall runs a free "Infer Email" step first, constructing a likely address from a name and a domain, before any paid provider is touched, and only cascades into paid lookups if that guess fails.

There's also a quality-versus-coverage trade-off baked into which provider you put first. Clay's own comparison of two named email providers makes the point concretely: "Hunter returns the most trustworthy emails in the set and reaches barely half your contacts. Findymail reaches nine in ten and gives up two points of quality to do it." Put the higher-quality, lower-coverage provider first if a wrong email is expensive (it burns a sending domain's reputation); put the higher-coverage provider first if getting to volume matters more than precision on any single record.

A worked example: reordering the chain changes the bill, not the coverage

Clay publishes a worked illustration of exactly this trade-off, run over a batch of 100 records with five named providers at their listed per-lookup prices:

"Ran on" is Clay's own term for the count, and it means queried, not resolved: every record hits Icypeas first, the 48 Icypeas can't resolve fall through to Enrow, and only 14 of those fall through Enrow to Hunter, Findymail and Wiza. Run in that order, the chain returns 94% usable coverage across the 100 records for a total of $39, because each record only pays for the lookups it actually reaches, and the pricier providers at the bottom only ever see the handful nobody cheaper could match. Clay's own framing of the exercise: "Reorder the chain over 100 records: coverage holds, the bill moves." Swap the order and the coverage number barely changes, because the same five providers are still in the chain, but the bill moves, because more records now walk further down a more expensive path before they stop. This is the concrete case for building the waterfall cheapest-and-most-common-first, then falling back to narrower, pricier providers only for what's left.

Treat that $39-per-100 figure as an example of the mechanism, not a benchmark to expect on your own list. Your own list's mix of clean corporate emails versus small, obscure domains will move both the coverage and the price.

Common mistakes

• Enriching before deduplicating. A duplicate record enriched twice pays twice for the same fields and usually ends up with two different, conflicting versions of "current job title." Deduplicate the identity fields first; see crm-deduplication-one-field for the one field that actually determines whether two records are the same lead.
• Buying phone numbers nobody calls. On Apollo, a verified mobile adds 8 credits on top of the 1 credit for demographics and email, and phone waterfall enrichment runs 8 to 25 credits against 1 to 4 for email waterfall enrichment (more on the exact numbers below). Clay's own guide calls mobile phone the hardest field to enrich, with quality and coverage lower on any single source than for work email. If your reps' first touch is email or LinkedIn and stays that way for the first three attempts, a verified mobile number is a cost with no job attached to it until later in the sequence, if at all.
• Treating enrichment as a one-time job instead of a decay problem. A title, a company size, and a tech stack are all true on the day they're captured and start going stale immediately. A record enriched once at import and never refreshed slowly drifts back into the same routing errors enrichment was bought to prevent; see crm-hygiene-measure-your-decay-rate for how to measure that drift.
• Letting export credits double the bill. Apollo's own FAQ states plainly: "You consume export credits whenever you export a contact outside of Apollo. For example, when you use CSV, CRM, or Person API enrichment and sync the data to any system outside Apollo, like Outreach or Salesloft." Enriching inside a platform and then pushing every record into your CRM is two separate charges, not one.
• Scoring on a field with no named source. A "buying intent" number that doesn't say what behavior it's built on is not information a rep can act on differently than a coin flip. If the vendor won't say what the score measures, it isn't a routing input.

Tools grouped by job

Three different jobs get called "enrichment," and they're priced and built differently.

Waterfall and multi-provider enrichment (build your own chain):

Clay lets you sequence any combination of third-party providers per field, control the order, and pay only for the lookup that resolves each record, per the mechanism above. It's the right tool when you need control over which provider runs first, want to mix providers for cost or quality reasons, or need enrichment fields that no single platform sells natively (an example a Clay guide gives: cascading a work-email lookup across more than 100 providers in sequence). The tradeoff: you build and order the chain yourself, field by field, and Clay's own docs don't state which plan tier is required to use waterfalls, so check that against your own plan before assuming access.

Per-field API enrichment (a fixed provider, priced per field returned):

Apollo enriches through its own API and charges by what the lookup actually returns, not by the record. Its own documentation states the mechanism directly: "People enrichment: 1-9 credits per person, charged only if credit-consuming data is found: 1 credit for demographics/email; +8 credits if mobile phone is returned." Organization enrichment is a flat 1 credit. Waterfall-style enrichment inside Apollo carries a wider range: "Email waterfall enrichment typically uses 1 to 4 credits, but some vendor configurations or successful higher-cost matches may result in 20+ credits. Phone waterfall enrichment typically uses 8 to 25 credits, but some configurations may result in 45+ credits." Notably, "Endpoints that create, update, list, or manage records consume 0 credits," so moving data around inside Apollo is free; only the actual lookup is metered. The tradeoff against Clay: Apollo's waterfall runs on its own configured vendor mix, not a chain you build and reorder field by field yourself, so you get less control over which provider answers a given lookup. Apollo also does not publish, on the pages fetched for this post, the dollar cost of one credit at each of its plan tiers, so treat the credit counts above as relative weights, not as a dollar figure until you check your own plan.

Native CRM enrichment (whatever your CRM appends automatically):

HubSpot enriches contacts and companies against its own commercial dataset plus third-party and public sources, matched on first name, last name and work email for a person, or domain for a company, per its own documentation. It's off by default and requires Super Admin permissions to turn on. HubSpot answers the cost question directly on its own product page: "Data enrichment is included in all paid plans with HubSpot's Smart CRM, no additional cost, no extra tools, and no integrations needed." That makes native enrichment the cheapest default of the three, and the one with the least control: you get HubSpot's provider mix and match logic, not a choice of which provider runs first, and no visibility into which underlying source answered a given field. Compare that trade-off against hubspot-vs-pipedrive if the CRM choice itself is still open.

The practical split: use native CRM enrichment for the baseline fields on every record, reach for Apollo when you need a specific field (a verified mobile, a firmographic detail) on a defined list, and reach for Clay when the job is building a repeatable, ordered chain across several providers for a field your CRM or a single API doesn't reliably resolve on its own.

Related terms

• Waterfall enrichment: the sequenced, stop-at-first-match provider chain described above.
• Data decay: the rate at which enriched fields go stale after they're captured. See crm-hygiene-measure-your-decay-rate.
• Lead routing: the rule set that decides which rep a lead reaches, which enrichment exists to feed with better inputs.
• Speed to lead: how fast a routed, enriched lead actually reaches a rep. See speed-to-lead.
• Revenue operations KPIs: the reporting layer that should catch it when enrichment spend stops earning its cost. See revenue-operations-kpis-your-crm-cannot-calculate.

If your team is paying for fields nobody routes on, or routing on fields nobody enriches, that's usually a symptom of a sales process built in pieces rather than as one system.

If you want a second pair of eyes on your own setup, Salestruct runs a free diagnostic.