Enrich the Records That Matter

A nightly job at GTM Lab enriches every record in the Contact population, including a batch of leads disqualified months ago and contacts on deals long since closed-lost. Nobody will ever call these records again. The job spends credits on them every night anyway, because “enrich everything” was easier to configure than deciding who actually needs it.

Enrichment isn't the same problem as accuracy

Enrichment fills gaps and refreshes stale fields. It doesn't validate what's already there or prove a record is otherwise trustworthy. A fully enriched record can still be a duplicate, still carry the wrong lifecycle stage, still be reachable on a channel it shouldn't be.

An explicit answer for every segment, and a real trigger moment

Give every population segment, meaning active pipeline, recently handed off, disqualified or closed-lost, and long-dormant, an explicit eligible: true or eligible: false, with a stated reason for exclusions, so no segment defaults into eligibility by accident. Then choose trigger moments, whether on-creation, on-handoff, or a sweep scoped only to already-eligible segments, instead of a blanket schedule against the whole database. A Ferrow Industrial contact just handed off to Sales enriches at the handoff moment, when the fresh data actually matters; the disqualified batch is excluded entirely, at zero credits spent.

I've made this exact trade, eligibility rules and moment-of-use triggers instead of a blanket nightly refresh, in a production system, where it cut predicted monthly enrichment credit use by more than 80%, from over 50,000 to under 10,000 credits. That's one company's outcome against its own prior baseline, not a guaranteed result of following this pattern.

Eligibility bounds the spend. A cap is what enforces it.

Scoping eligibility correctly shrinks the bill, but it doesn't put a ceiling on it. A trade-show import drops 800 newly-eligible contacts into the handoff queue on a Tuesday, every one of them legitimately eligible under the rules you just wrote, and the day's spend runs past its budget before anyone looks. A cap that reports the overage afterward is a receipt. A cap that is checked before each credit-consuming call is a control, and only the second one can still refuse.

Make the cap daily rather than monthly, so a bad morning costs a day instead of a quarter. When it binds, defer the excess to the next cycle rather than dropping it: a deferred request stays visible in a queue and runs when the cap resets, while a dropped one is a record nobody enriched and nobody knows about. Scope the kill switch to paid calls only, so stopping the spend doesn't also stop the free matching the rest of the system depends on. Keep the approval queue narrow enough that someone can actually clear it, which in practice means three conditions: a low-confidence result, a value that conflicts with one already on the record, and a reveal above a cost threshold. A queue nobody can keep up with gets bypassed, and a bypassed queue is worse than no queue, because it still appears in the diagram.

Name the owner before the cap binds, not during the quarter it blocks something urgent. Finance owns the limit, because it owns the budget. Revenue Operations reviews what the cap defers and what the queue flags, because it feels the constraint and can tell a real bottleneck from a busy week.

Carry this into your business

Enrichment spend should track how many records someone is about to act on, not how many records exist. If your enrichment bill grows every quarter regardless of pipeline activity, the missing piece is almost always eligibility rules.