ListarProductsPricingToolsSign in

Triggering enrichment without burning credits

Updated

Wiring enrichment to "contact created" with no further condition is the default in every integration, and the most expensive. It pays for records that already have a mobile, for contacts outside your target, and repeatedly for the same people who cannot be found.

Five conditions cut the bill substantially, and none requires development. The difficulty is not technical: two of the five depend on a property your vendor does not deliver, which you have to write yourself.

The five conditions, by return

1. The record has no mobile yet. Obvious, and still the leading source of waste, because the default trigger does not look at what the record contains. Check both your enrichment property and the standard phone field your reps fill in by hand.

2. No attempt has already been made. The highest-return condition and the one needing the most modelling work. Without an enrichment status with at least three states, found, not found, not attempted, your workflow cannot tell a never-processed record from one processed with no result. So it retries on every record edit, and pays each time.

3. The contact is in your target. Enriching every new contact also enriches candidates, suppliers, partners, and people who downloaded a whitepaper from a country you do not sell into. Put the condition on what defines your target: company size, industry, country, role.

4. The contact has a reason to be called. A mobile is only worth buying if someone is going to dial it. If your sequence opens with two emails and the call only comes on day five for contacts who opened, enrich on day five. You will pay for a fraction of the volume.

5. The company is identified by a stable identifier. Not an economy condition but a yield one. An enrichment fired on a trade name alone fails more often than one fired on an official identifier, and a failure costs money depending on your vendor's policy.

Order the conditions deliberately

Conditions cost nothing to evaluate, enrichment costs. So put the most filtering first and the most expensive to compute last.

Order Condition Cost to evaluate
1 No mobile already Nil, a property read
2 No prior attempt Nil, a property read
3 In target Nil, property reads
4 Engagement signal reached Nil, but defers the trigger in time
5 Company identifier present Nil if you hold it, one call if you must resolve it

A setup that clears all five filters before spending typically enriches a fraction of contacts created, and those are the ones your reps will actually call.

Your vendor's billing policy changes everything

Before designing conditions, know what you pay for. The policies differ sharply between vendors and are rarely published in the same place as the prices.

Not charged on a miss. Some vendors state it explicitly: a lookup returning nothing costs nothing, and a landline returned instead of a mobile costs nothing either. That is the most favourable policy and it reduces the stakes of condition 2 without removing them, since a call with no result is still time and still a quota.

Charged per request, not per result. Others debit a credit per lookup. There, condition 2 is not an optimisation, it is the only protection against your invoice drifting mechanically upward.

The interface-versus-API case. At least one vendor charges nothing for a miss in its interface and a one-credit minimum for an API request that returns no results. If your CRM integration runs through the API, that is the behaviour that concerns you, and it is not the one that gets advertised.

The sync case. One vendor publishes that credits are charged for every new direct dial request regardless of the settings you enable. Another sells its CRM integration as a separate subscription, priced on the number of CRM records rather than in credits, and states that credits from the main subscription cannot be used to enrich the CRM.

Four questions to ask before wiring anything: am I charged when nothing is found, am I charged when the number reaches the wrong person, is the API's behaviour the same as the interface's, and does my subscription cover CRM usage.

Re-verification cadence

The other half of the subject, and the one you settle once.

Contact data decays. Published measurements put turnover at roughly one in eight per year among US sales leaders, and higher in fast-moving segments. A file enriched once and never revisited therefore loses a mechanical share of its value each quarter.

Three cadence rules that hold, without monitoring every record.

Re-verify before the calling block, not after the import. A verification done while you build the list has already aged by the time the rep dials. The useful re-verification is the one immediately before use.

Trigger on the event rather than the calendar. A detected job change, a company name change, an email that bounces: those are the signals that justify re-verification. A blanket monthly refresh of the whole base is expensive and misses the point.

Set an expiry per segment, not per base. Contacts in a high-turnover segment deserve a shorter window than a stable industry. The verified date on the record is what lets you compute it, which is one of the reasons that property exists.

The base-migration trap

A case that comes up often and whose cost is brutal.

You decide to enrich your existing base, you fire a job at forty thousand records, and the invoice arrives. In the vast majority of cases a share of those records is unusable: people who have left, companies that closed, duplicates, segments outside your target.

Always run a sample first. Three hundred records stratified like your base, enriched and called, give you the real hit rate and the cost per usable contact on your base. Scaling is a decision made on that number, not on a volume quote.

Download the test kit (.xlsx)

No form, no email required.

Where Listar sits

We deliver line type with every number. The date the cadence rules above run on is the enrichment date, which your workflow records when it writes the result back.

What you hold on your side: enrichment status and last attempt date. Those describe the state of your process rather than the data, so no vendor can write them for you. They are what carries condition 2, the highest-return of the five.

And a recommendation against our own immediate interest: do not wire enrichment to every contact creation, with us or anyone else. A setup that enriches a targeted fraction of your contacts produces more meetings per unit spent than one that enriches everything, and it survives longer.

FAQ

Should every new CRM contact be enriched? No. It is the default and the most expensive setting. Five conditions cut the spend substantially: no mobile already, no prior attempt, in target, with a reason to be called, and a company identified by a stable identifier.

Which condition returns the most? The absence of a prior attempt, because without it the workflow retries the same fruitless records on every edit. It requires an enrichment status with at least three states, which you have to model yourself.

Am I charged when the vendor finds nothing? It depends on the vendor, and sometimes on the route. Some charge nothing on a miss, others debit per request, and at least one charges nothing in its interface but a one-credit minimum on an API request with no results. Ask before wiring.

How often should numbers be re-verified? Before the calling block rather than after the import, on events rather than on a calendar, with an expiry set per segment. A blanket monthly refresh of the whole base is expensive and misses what matters.

How do I enrich an existing base without an invoice surprise? Start with a sample of three hundred records stratified like your base, enriched then called. The real hit rate and cost per usable contact on your own base are the only figures to scale on.

Does my enrichment subscription cover CRM usage? Not always. At least one vendor bills its CRM integration separately, on the number of records, and states that credits from the main subscription cannot be used for it.

Sources

All guides

Listar AI