CRM Enrichment: Filling the Fields Your Own Records Are Missing
CRM enrichment, or record enrichment, fills gaps in records you already own rather than in a list you just bought. The work is mostly policy: which key you match on, which key you write back on, and which fields a provider is allowed to overwrite. Buy it on accuracy you sampled yourself, not on the coverage rate a vendor publishes.
Key takeaways
- Every enrichment job has two keys: an external one you match on, and your own record id you write back on. Losing the second lands correct values on wrong rows.
- Coverage is easy to compute and gets quoted; accuracy needs manual checking and is what you are actually buying. A confidently stale field is worse than an empty one.
- Enriching a record does not make it findable. Write the segment query first, list the fields it needs, and enrich against that rather than against blank cells.
- Keep provider values in their own fields with an explicit promotion rule, so a bad write never silently replaces something a rep learned on a call.
CRM enrichment is the practice of appending missing or outdated attributes to records that already exist in your CRM, using an external data source. A record sits there with an email address and a company name, and enrichment fills in the job title, the headcount band, the industry, the primary domain, sometimes a direct dial. The defining feature is the starting point: the rows already exist and someone already owns them, which is what separates the job from enriching a purchased list before it is ever loaded.
That distinction is the reason the term exists separately from enrichment in general. Enriching a fresh file is a transaction with no history behind it, so whatever the provider returns simply becomes the row. Enriching your own CRM is an argument between two sources. The record in front of you was created by a rep who spoke to the person, or by a form that person filled in themselves, and the provider's answer might be better or might be eighteen months old. Deciding which one wins, field by field, is most of the work. The term was needed because teams that treated the job as a bulk import discovered afterwards that they had overwritten things they knew to be true.
CRM enrichment is also written as CRM data enrichment, and the two spellings name one job: appending missing or outdated attributes to records that already exist in your CRM, from an external source.
Record enrichment and the missing email
Record enrichment is the same job seen one row at a time: a record that exists, the fields it is missing, and an outside source asked to fill them. The case most teams meet first is a CRM list where the missing field is the email address itself, which is record enrichment with the usual join key removed, because the field you would normally match on is the one you are looking for.
To backfill missing emails on a CRM list, match on the person's full name plus the company's domain, never on a company name alone. Run finders in sequence, cheapest first, and verify every returned address before it is written, because a finder produces a candidate and only a verifier tests it. Write the result to a provider field under fill-if-empty, so it can never replace an address the person gave you themselves.
Two results need a rule before the run rather than after it. An address on a domain that accepts every recipient cannot be confirmed by any server check, and what that result does and does not tell you is worked through in CEO email addresses. A record whose person has left the company needs a different fix, because the missing email is a symptom of a stale row, and enriching it confidently only hides that.
How CRM enrichment actually works
Everything starts with the join key, which is the least discussed and most damaging part of the job. You have to tell the provider which record you mean, and you have four realistic options, each with different behaviour.
Lead intelligence is the category name vendors give this work bundled with scoring, routing and intent signals, and every part of that bundle inherits the join-key problem below, because a record matched to the wrong company is enriched confidently and wrongly.
Email is the strongest person-level key, because a mailbox belongs to one identity and carries no ambiguity. Company domain is the strongest company-level key for the same reason. Company name is the weakest by a wide margin: legal entities and trading names differ, punctuation and suffixes differ, and thousands of real companies share a name with a larger one. Your own CRM record id means nothing to the provider at all, but you still need it, because it is how the answer gets written back to the right row.
That gives every enrichment job two keys rather than one. You match on an external key and you write back on an internal key, and losing the second one is how correct values land on wrong records. The identity question underneath all of this is record matching, which this glossary covers separately, and it is worth reading before designing the write-back rather than after.
Records missing a field your segment query actually filters on.
Email for a person, domain for a company, never company name alone.
Cheapest source first, escalating only on a genuine miss.
Fill if empty, overwrite if stale, or never overwrite a human value.
The internal key, so the answer reaches the row it was asked for.
The second structural choice is timing. Batch backfill runs the whole table on a schedule, which is easy to reason about and easy to budget, and produces one large bill followed by values that begin ageing the moment they land. Continuous enrichment runs when a record is created or when a field changes, so spend tracks real activity and the value is fresh at the moment somebody needs it. The trade is that records nobody edits never get corrected, and per-record pricing on a trickle is usually worse than pricing on a block.
Then the write policy, which deserves a written rule rather than a default setting. Fill-if-empty is the safe baseline. Overwrite-if-stale sounds right and needs a per-field last-verified timestamp that most CRMs do not give you, so in practice it degrades into overwrite-always. Never-overwrite belongs on any field a human owns, which usually means anything a rep typed after a conversation. The most robust arrangement keeps provider values in their own fields and lets an explicit rule promote them, so both versions stay visible and a bad promotion is reversible.
| Write policy | Safe for | Goes wrong when |
|---|---|---|
| Fill if empty | Every field, as the baseline | A stale value is already there |
| Overwrite if stale | Fields with a last-verified date | There is no date, so it becomes overwrite-always |
| Never overwrite | Anything a rep typed after a conversation | Nobody marked which fields a human owns |
| Separate field and a promotion rule | Everything, where the CRM allows it | The rule has no owner |
Cost sits underneath all of it. Providers bill per record submitted or per record returned, and those are different numbers on the same job. Chaining several providers cheapest-first is the standard answer, and the arithmetic behind the ordering is set out in waterfall enrichment. Credit models vary enough between vendors that the same table can cost several times more depending on how the run is structured, which Clay's pricing model illustrates in detail.
How it is measured
The share of submitted records for which a provider returns the requested field is the match rate, and it is the number that decides what any of this costs per usable row. That measurement has its own entry in this glossary, and the important part of it applies here directly: a rate quoted by a vendor was computed on the vendor's sample, and the only figure that means anything is the one you compute on your own table.
Two other readings are worth taking from the same run, because neither is reported by default. The first is the disagreement rate, meaning the share of enriched rows where the provider returned something different from what your CRM already held. A very low disagreement rate on an old table usually means the provider is reading the same public source your records came from, which makes it a poor second opinion whatever its coverage looks like. The second is the fill-versus-change split: how much of the run filled genuinely empty fields and how much of it rewrote populated ones. Those two halves carry completely different risk, and a job report that merges them into a single count of records enriched hides the half that can damage you.
Some vendors sell those two halves as separate products and call the correcting one data enhancement, which names real work but not a second purchase, because correcting, standardising and de-duplicating what you already hold is data hygiene and it is scheduled rather than bought.
Where the textbook definition breaks
Enrichment is sold as coverage and bought as accuracy, and those are different numbers that nobody separates at purchase time.
Coverage is trivial to compute. Submit ten thousand rows, count how many came back with a value, publish the percentage. Accuracy requires somebody to check whether the returned value is true, one row at a time, against a source that is itself current. A provider returning a plausible but stale job title for ninety percent of rows scores exactly the same as a provider returning the correct title for ninety percent of rows. The number that ends up in the comparison spreadsheet is the one that is cheap to produce, and the number you actually care about is invisible unless you go and look.
The practical form of this is that stale enrichment is worse than empty enrichment, because an empty field announces itself and a wrong field does not. A blank title gets checked before somebody writes to that person. A confidently wrong title gets used.
| Coverage | Accuracy | |
|---|---|---|
| What it is | Share of submitted rows that came back with a value | Share of returned values that are correct today |
| Who can measure it | Anyone, instantly | Only you, on a sample checked by hand |
| Who quotes it | The provider | Nobody, unless you go and look |
| What moves it | A provider guessing more freely | The underlying facts changing |
The second break is more expensive and less obvious. Enriching a record does not make it findable, because the field that was missing is rarely the field your segmentation actually filters on.
The pattern repeats everywhere. A team looks at its CRM, sees thousands of half-empty rows, runs an enrichment project, and then discovers the campaign still cannot be built. The reason is that the ICP was written in terms the provider does not sell: companies running a particular piece of software, companies that opened an office in a given region, companies whose service mix matches a specific offer. Enrichment fills the fields the provider happens to have, and segmentation queries the fields your ideal customer profile is written in, and the overlap between those two sets is smaller than anyone expects before they check.
The correction is to reverse the order. Write the segment query first, list the fields it needs, and only then find out how many records are missing them. Guidance on writing that definition tightly enough to query against is in ideal customer profile. Doing it this way also shrinks the job, often dramatically, because a query usually needs four fields rather than forty.
What to do with it
Size the work from the query rather than from the blank cells. The number that matters is how many records are missing a field your target segment filters on, and that is almost always a fraction of the records that look incomplete.
Choosing a tool to clean CRM data therefore has a prior question attached: which fields your live queries actually filter on, because a tool pointed at everything is unbounded work and the same tool pointed at those fields is a finite job.
Buy on a sample you checked yourself. Submit a hundred rows, verify the returned values by hand against public sources, and use that result rather than any published figure. It takes an afternoon and it is the only accuracy measurement you will ever have. Do the same check again on a second sample once the contract is live, because coverage and accuracy drift in different directions over time.
Keep provider values and human values in separate fields, with an explicit promotion rule between them. Every team that skips this eventually overwrites something a rep learned on a call, and the version that was true is gone.
Log what you discarded, as well as what you wrote. When a run rejects a returned value because the field was already populated, or because the row failed a confidence threshold, record the reason. Without that log, a provider miss and a value you threw away yourself look identical in the final table, and you will re-buy the same rows later believing nobody ever found them.
Related terms and guides
Match rate governs the economics of everything on this page, and record matching governs whether the enriched value reaches the right row. Both have their own entries. Data decay explains why the fields you enrich today will be wrong later, and data hygiene covers the maintenance that answers it.
For the mechanics of chaining providers rather than committing to one, waterfall enrichment sets out the ordering logic and where the savings actually come from. For choosing among the tools themselves, best data enrichment tools for cold email teams is the current comparison, and Clay's pricing model is worth reading before any credit-based platform decision. On the write-back side, Apollo and HubSpot deduplication rules is the clearest worked example of what happens when two systems disagree about which record is which. And if your CRM's primary source of person data is LinkedIn rather than a provider, LinkedIn CRM covers what actually flows between the two and what does not.
If you would rather have a campaign built against a segment you defined, on a list enriched only where the query needs it, RevenueFlow builds and runs the outbound engine and is paid only for meetings that are actually attended. See if you qualify.
Frequently asked questions.
Frequently asked questions- What is the difference between CRM enrichment and list enrichment?
- List enrichment fills a fresh file where nothing is authoritative, so the provider's answer simply becomes the row. CRM enrichment updates records someone already owns, which means every field is a decision between an existing value and a new one. That overwrite policy, rather than the lookup itself, is where most of the work and most of the risk sit.
- How do I backfill missing emails on my CRM list?
- Match on the person's full name plus the company's domain, because the email you would normally match on is the missing field. Run finders in sequence, cheapest first, verify every returned address before it is written, and write it to a provider field under fill-if-empty so it never replaces an address the person gave you themselves.
- Which field should you match on?
- Email for a person and company domain for a company, because both are unique and unambiguous. Company name is the weakest key available: trading names differ from legal entities, punctuation and suffixes vary, and many real companies share a name with a larger one. Matching on name alone produces confident results that point at the wrong organisation.
- How do you tell whether an enrichment provider is any good?
- Submit a sample of your own rows and check the returned values by hand against public sources. Published match rates are computed on the vendor's sample rather than your list, and they measure coverage rather than correctness. A hundred rows checked manually gives you the only accuracy figure you will ever have for that provider on your data.