The 36-Hour Data Emergency That Taught Me How to Evaluate Enrichment Tools

It started at 4:47 PM on a Tuesday in November 2024. I was running the final spot-check on the enriched contact list for Q4's biggest outbound push—6,000 records, synced into Salesforce, queued in our cold email automation, scheduled to go live in 36 hours.

The first problem I caught was small. A person's email format looked off. Then I noticed a LinkedIn URL that didn't match the name attached to it. So I pulled a 500-record sample and ran a deeper validation.

The numbers were bad. 38% of the sampled records had issues—stale emails, people mapped to companies they'd left over a year ago, duplicates that our dedup logic never caught because the vendor's platform assigned different IDs to the same person. Extrapolated to the full list, that's more than 2,200 records I could not trust in front of the biggest campaign of the quarter.

I sat there for a minute. Then I said the sentence I've never lived down: "We might have to postpone."

Missing that deadline would have meant a lot of uncomfortable conversations with the VP of Sales. Sending the garbage anyway would have torched our domain reputation. Neither option looked good.

This is the story of the 24 hours that followed—and the evaluation framework that came out of it. The framework we should have had when we chose the vendor in the first place.

How We Ended Up With a Data Vendor We Didn't Understand

We picked the original enrichment platform back in March for the usual reasons. 300M+ contacts sounded impressive. The per-credit pricing was mid-range. The API docs looked thorough, and the LinkedIn extension seemed fine in the demo. The sales rep called us back within the hour.

We ran a pilot on 200 records, the sample came back clean, and we signed.

That pilot was the trap. "Most buyers focus on contact count and price per credit and completely miss data freshness and match logic," my friend in RevOps consulting told me when I called her in a panic at 7:30 PM. She wasn't wrong.

We never asked:

• When was this record last verified?
• What does "verified" actually mean in your system?
• How do you map a person to their current company?
• What's in the fine print around data refresh and API limits?

We assumed "enriched" meant "validated." Didn't verify. Turned out the pilot records had been freshly re-verified because they were part of a recent sales engagement. The rest of the database? Roughly a year old, give or take.

When I called the vendor's account rep that evening, she said, "All databases have some error rate. Your contract doesn't guarantee freshness." Technically, she was right. That's what made it sting.

The vendor failure in November 2024 changed how I think about data enrichment. One critical deadline missed, and suddenly the whole "bigger database" pitch felt hollow. In my role coordinating data operations for enterprise outbound, I'd spent years looking at the wrong metrics.

The 11 PM Decision Matrix

By 9 PM, we had three things: a spreadsheet, a list of alternative vendors, and no more time to argue. Our engineering lead joined the call with a bag of cold pizza. We started building an evaluation framework at 11 PM.

The first draft was chaos. We listed everything we could think of—data coverage, API docs, integrations, compliance, pricing. Then we reordered it by a single question: "What would have prevented this disaster?"

That changed the conversation completely. We weren't buying software anymore. We were betting a campaign on a data pipeline.

1. Data freshness over database size

The "bigger database is better" logic comes from an era when contact data changed slowly. Today, people change jobs every two to three years and companies pivot constantly. A database with 300M contacts is meaningless if a third of it was last verified in 2022.

New evaluation question: "Can you run a freshness report on a sample of records, segmented by last-verified date?" If a vendor can't or won't answer that clearly, walk away.

2. Match logic—the invisible killer

Here's the part nobody sees unless you're in the weeds: how does the vendor map a person to a company? Our old vendor had one person listed at three different companies, all marked "current." Their system was matching from fragmented web data, and it couldn't tell the difference between the person's old email and their current one.

Now I test with our own data. I'll take 50 contacts whose current employment we're certain about and see how accurately the vendor maps them. If the match rate drops, you'll know exactly where the cracks are.

3. API pricing transparency is a red-flag test

Here's where I learned the transparency lesson. Our old vendor looked cheap at the subscription level. But the API calls, the data refresh, the export—those had separate costs we discovered only after the first overage invoice.

FTC guidance on marketing requires that claims be truthful and not misleading. In my opinion, pricing should follow the same spirit. "The question everyone asks is 'what's your price per credit?' The question they should ask is 'what's NOT included in that credit?'"

When we looked at RocketReach that night, I opened the RocketReach pricing API page specifically. Rate limits were listed in plain text. Endpoint costs were spelled out per plan. No "contact sales to find out" wall. That level of transparency was a signal.

4. The LinkedIn extension consistency test

Here's a test I will never skip again: pull the same contact in the web app, then open the vendor's LinkedIn extension, and compare the two data points. If they don't match, the company is running two different databases—one for the extension and one for the API. Which one is the source of truth? The vendor probably doesn't even know.

We caught one of our shortlisted vendors doing exactly that. The extension showed a completely different email than the bulk export. Put another way: they had a split-brain problem.

RocketReach's LinkedIn extension, by comparison, showed the same data as the API. Consistent. Boringly consistent. That consistency became a hard requirement.

5. GTM automation integration is about workflow, not connectors

Every vendor says they integrate with Salesforce and Outreach. But the real question is: what does the data actually do once it's in your stack?

Our old vendor's data made it into Salesforce but never flowed into Outreach sequences. The SDRs ended up manually exporting and re-uploading lists—which means they also manually cleaned them, introducing more errors.

When evaluating for GTM automation, I now ask:

• Does enrichment push directly into our cold email automation sequences?
• How are records deduplicated when they merge into the CRM?
• Can we set up re-enrichment triggers when campaign events happen—reply, bounce, job change?
• How long does the average sync actually take?

6. "Verified" is a flexible word. Pin it down.

Under the FTC's CAN-SPAM rules, commercial email requires accurate header information, a clear opt-out, and no misleading subject lines. But CAN-SPAM doesn't test your contact data for you. The data you load into your automation is your responsibility—not your vendor's. So when a vendor says "verified email," ask exactly what that means.

Did their system receive a confirmation at the inbox level? Or did a bot just check the domain's syntax? There's a huge gap between those two, and if a vendor gets defensive when you ask, that's the answer you needed.

Testing the Shortlist at 2 AM

We pulled 200 of the worst records from our original list and ran them through three vendors. RocketReach was one of them. The results surprised us.

Only one vendor returned a freshness report that showed actual dates. Only one was willing to explain its match logic on a screenshot call at 2 AM. And only one gave us a test API key without a sales conversation first.

It wasn't the cheapest option. I'd argue it was the least risky—and when I looked at the total cost of what the old vendor had cost us in overtime, rework, and lost SDR confidence, the price difference was noise.

The Campaign Went Out. Barely.

The campaign launched Thursday morning, more or less on schedule. We rebuilt maybe 1,800 of the 6,000 records from scratch using the new vendor's data. I'm not 100% sure of the exact number—could be 1,600, I'd have to check the spreadsheet—but it was a lot.

Email deliverability landed in the range we'd planned. The reply rate didn't embarrass us. Nobody lost their job.

But the cost was real: a burnt-out team, a week of delayed pipeline work, and a bill for rush data credits we hadn't budgeted for. That's what the lack of transparency cost us.

What I'd Tell a RevOps Team Evaluating Data Enrichment Today

If your team is evaluating a data enrichment company for GTM automation, here's the priority order I'd use—the one we built over cold pizza at 11 PM:

1. Ask for last-verified dates, not database size. Total contacts is vanity. Freshness distribution is reality.
2. Test match logic with your own records. You'll learn more in 30 minutes than any demo will show you.
3. Read the API pricing page like a contract. It probably is one. Check rate limits, overage fees, and what counts as a "successful enrichment."
4. Compare the LinkedIn extension output to the API output. If they diverge, that's a red flag.
5. Follow the data all the way into your sequences. The value of enrichment is only realized in cold email automation if it flows there without manual steps.
6. Demand a written definition of "verified." If they won't put it in writing, assume it means "syntax check."

I'm not going to tell you which vendor to pick. But I will tell you this: the vendors who list all fees upfront—even when the total looks higher—usually cost less in the end. That's been my experience, and it's now the first thing I evaluate.

Take it from someone who spent a night eating cold pizza over a failing enrichment pipeline: ask the hard questions before you're in an emergency. Not during.