CRM enrichment is a lookup, not a migration
Enrichment gets sold as a one-time project: buy data, append it, done. But an appended field is a copy, and a copy starts ageing the moment it lands in the record. Most enrichment damage is not missing data - it is data that used to be true.
The two shapes
| Enrichment at request time | Bulk backfill | |
|---|---|---|
| When the value is produced | The moment you need it | Once, at project time |
| Age of the value at use | Seconds | Unknown - nobody stamps it |
| Cost model | Per contact requested | Per seat, whether you use it or not |
| Failure mode | A request that returns nothing | A full field that is wrong |
| What you end up owning | A call | A second database to maintain |
Where enrichment actually goes wrong
- The field is copied once and trusted forever. 23% of contacts change jobs every year (ZoomInfo 2025) and 40% of email addresses are dead within two years (NeverBounce). A field with no date on it cannot be audited.
- The bounce never travels back. A hard bounce is the freshest verification data your company owns, and it usually dies in the sending tool instead of updating the CRM.
- Two records fight. Manual edits, imports and enrichment all write the same field with no provenance, so nobody can say which value is the real one.
- The backfill becomes the source of truth. Once the exported list is what the team works from, the platform you pay for is the copy, not the original.
What to write back - and what to leave out
Write back only what you act on, and stamp it:
- The verified state -
valid,invalidorunknown. Not "has email", which is not a state anyone can act on. - The moment it was verified. A state without a timestamp is a rumour.
- Where the address came from - the page or profile it was found on. This is what lets a human sanity-check a row that looks odd.
Leave out the rest. A job title you never target, a phone number nobody calls and a company size that only the sales deck uses are payload, not data - and every one of them is another stale field to defend in a review.
One call, three outputs
TAPAC is built for the lookup shape. A search returns the contact, the source it was found in, and its SMTP state as of that call, verified inside the same request - so the value you paste into the record already carries its own provenance. There is no stored mailbox on our side and no bulk file to keep in sync.
npx -y @tapacapi/mcp # or hosted https://tapacapi.com/mcp # tapac_find_contacts -> contact + source + SMTP state, in one response # REST: POST https://tapacapi.com/v1/contacts/search
The three states, applied to a CRM
| State | What to do in the CRM |
|---|---|
valid | Contactable now. Store the timestamp next to it. |
invalid | Suppress, do not delete. The address may belong to a successor with a similar name - the record still tells you something. |
unknown | Route to a human-review bucket. Catch-all domains accept everything, so this is not a yes and not a no. |