Enrichment eligibility and moment-of-use enrichment
Control CRM data enrichment by intent and moment of use. Enrich handraisers first, govern provider waterfalls, and stop spending on records nobody will contact.
On this page
- Enrichment is not the same problem as accuracy
- Eligibility needs an explicit answer for every segment, not a default
- Moment-of-use beats a blanket schedule
- Let intent set the enrichment tier
- Write behavior needs its own rule, separate from eligibility
- GTM Lab: two records, one enrichment job
- Salesforce and HubSpot: what changes, what doesn't
- Enrichment eligibility checklist
- Where this connects
A nightly job that enriches every record in the database will happily spend credits refreshing disqualified leads, closed-lost contacts, and records nobody is going to call this quarter or ever. Enrichment spend scales with database size instead of with actual sales activity, which is exactly backwards: the records worth paying to keep fresh are the small, changing set someone is about to act on, not the entire population sitting quietly in the CRM.
Two decisions fix this: who is eligible for enrichment at all, and when an eligible record should actually be enriched.
Enrichment is not the same problem as accuracy
Before eligibility rules: enrichment fills gaps and refreshes stale fields. It doesn't validate what's already there, resolve which of two conflicting values is correct, or prove a record is otherwise trustworthy. A record can be fully enriched and still be a duplicate, still have the wrong lifecycle stage, still be reachable on a channel it shouldn't be. Treating "we enrich our data" as a data-quality strategy on its own conflates enrichment with the much larger set of problems this guide's other pages cover.
Eligibility needs an explicit answer for every segment, not a default
A blanket "enrich everything unless excluded" policy quietly enriches every new
segment that shows up later and nobody thought to exclude. Require every segment to
carry an explicit eligible: true or eligible: false, with a stated reason for
exclusions:
| Segment | Eligible | Reason |
|---|---|---|
| Active pipeline, open Opportunity | Yes | Directly supports an active sales motion |
| Recently handed off from Marketing | Yes | Fresh data matters most at the moment of first sales engagement |
| Disqualified or closed-lost | No | No planned future contact; enrichment spend produces no return |
| Long-dormant, no engagement in the defined window | No, until re-engagement | Refreshing a record nobody will act on is spend without purpose |
An "eligible unless excluded" default inverts this: it enriches the dormant and disqualified segments by default and requires someone to notice and add an exclusion after the fact, by which point the spend already happened.
Moment-of-use beats a blanket schedule
A record's data is freshest exactly when someone is about to use it, not on whatever fixed interval a nightly job runs. Trigger enrichment at the moments that actually matter:
- On creation: a new record enters the pipeline and needs baseline enrichment before anyone works it.
- On handoff: a record moves from one team to another (Marketing to Sales, for example) and the receiving team needs current data at that exact moment.
- On a specific action: a rep opens a record to work it, or adds it to a sequence, and enrichment runs just ahead of that action.
- Scheduled sweep, scoped to eligible segments only: a periodic refresh, but run only against the population already marked eligible, not the whole database.
This is the difference between "key records are always fresh when they're used" and "the whole database gets refreshed on a schedule regardless of whether anyone needs it." The first scales with sales activity. The second scales with database size.
Let intent set the enrichment tier
High-intent handraisers deserve the fastest and deepest enrichment because the next decision is expensive to delay or get wrong. Demo requests, contact forms, direct buying questions, and booked meetings can trigger immediate company and persona resolution before qualification.
Lower-intent records can use a cheaper path. Wait for repeated engagement, a handoff, or an explicit work action before calling paid providers.
| Intent tier | Example enrichment treatment |
|---|---|
| Handraiser | Resolve company immediately, run the approved provider waterfall, and retain provenance |
| Repeated meaningful engagement | Enrich the fields needed for fit and persona scoring |
| Single low-intent interaction | Use submitted and first-party data; wait for more evidence |
| Dormant or disqualified | Do not enrich until a documented re-entry event |
Business email domains make company resolution easier in mid-market and enterprise motions. A personal email may be ineligible for enrichment even when the record is kept for education or nurture. That is a qualification policy, not a claim that the person has no value.
AI can infer likely company, industry, or persona from identity and submitted context. Keep the inferred status visible and use a provider such as Clay or Apollo when the decision requires structured evidence or corroboration. A waterfall should stop once the required evidence is sufficient. Calling every provider produces more conflicts, not automatically more truth.
The lead-scoring system shows how enrichment fills unknown fit evidence without turning a missing value into a low score. For HubSpot, document score and provenance properties in the HubSpot context layer before a workflow depends on them.
Write behavior needs its own rule, separate from eligibility
Being eligible for enrichment doesn't mean an enrichment provider's value should overwrite whatever's already on the record. Enrichment should be allowed to fill genuinely empty fields automatically. A field with an existing value, especially one entered by a person, needs a separate conflict-resolution decision before enrichment is allowed to touch it. See conflict resolution and overwrite policy for that rule; this page only covers whether enrichment should run at all, not what it's allowed to write once it does.
GTM Lab: two records, one enrichment job
GTM Lab, a fictional B2B software company, has a nightly job proposed to enrich its full Contact population. Two records make the eligibility case concrete.
Eligible: a Ferrow Industrial contact newly handed off to Sales. The record was just accepted by Sales after Marketing's handoff, has no enrichment history, and is about to be worked. Under the eligibility rule, this segment (recently handed off) is eligible, and the trigger is on-handoff. Enrichment runs at the moment Sales picks it up, so the fields Sales actually looks at are current the moment they matter.
Ineligible: a batch of disqualified leads from a prior campaign. These records
were disqualified months ago with no planned future contact. Under the eligibility
rule, this segment is explicitly eligible: false, with the stated reason "no
planned future contact." The nightly job excludes them entirely; zero credits are
spent refreshing data nobody will look at.
Applying eligibility and moment-of-use triggers instead of a blanket nightly refresh is the same design decision I made in a production system, where it cut predicted enrichment credit use by more than 80%, from more than 50,000 to under 10,000 credits a month, while keeping the records that mattered fresh at the moment they were used. That is one company's measured result against its own prior baseline, not a guaranteed outcome of following this pattern.
This is otherwise a worked example. GTM Lab's specific segments and trigger choices are operating decisions, not a universal eligibility model.
Salesforce and HubSpot: what changes, what doesn't
Neither platform's native enrichment tooling ships a segment-eligibility model or moment-of-use triggers out of the box; most native and third-party enrichment integrations default toward either manual, on-demand enrichment or a broad scheduled sync. Building eligibility rules and trigger points on top of whichever enrichment provider you use, whether through platform automation (Salesforce Flow, HubSpot workflows) or a purpose-built rule layer, is the design work this page describes; check your specific provider's current documentation for what trigger granularity it natively supports before assuming you need custom automation to get moment-of-use behavior.
Enrichment eligibility checklist
- Every population segment has an explicit
eligiblevalue, not an implicit default. - Every ineligible segment has a stated reason.
- Enrichment triggers at meaningful moments (creation, handoff, specific action, or a sweep scoped to eligible segments only), not a blanket schedule against the whole population.
- Enrichment is treated as a spend-and-freshness control, not a data-accuracy guarantee.
- Write behavior for enrichment results is governed by a separate overwrite policy, not assumed from eligibility alone.
Where this connects
The spend side of this decision (caps, approval queues, kill switches) is covered in enrichment cost controls and approval queues. The write-conflict side is covered in conflict resolution and overwrite policy. Generated or AI-derived enrichment fields specifically carry additional risk covered in AI-generated CRM fields are not a source of truth.