The fastest way to waste money on data enrichment is to buy “coverage” before defining what the enriched data is allowed to change.

A vendor can show impressive record counts, hundreds of attributes, refresh claims, intent signals, technographics, and contact details. None of that tells you whether the service will make your CRM more decision-useful.

The useful buying conversation starts somewhere else:

What decision will this field drive, where did the value come from, what happens when it conflicts with our CRM, and how do we stop a bad write before it spreads?

That is not theoretical. Apollo's current CRM enrichment documentation requires field mapping and lets teams choose Auto-fill versus Overwrite permissions. HubSpot's current enrichment and intelligence tooling exposes enriched data for qualification, routing, prospecting, and outreach. Forrester's March 2026 B2B data-provider evaluation assessed 11 significant marketing and sales data providers—another reminder that this is a real vendor category with materially different offerings, not a commodity API.

Use the checklist below before you sign.

1. Which exact fields are you buying us?

Do not accept “company and contact enrichment” as an answer.

Ask for the field list by object:

  • company;
  • contact;
  • lead;
  • location;
  • technology;
  • firmographic;
  • employment;
  • intent;
  • relationship;
  • compliance or suppression.

Then mark each field as one of three types:

Decision-critical — used for routing, scoring, territory, compliance, or account selection.

Workflow-useful — saves research time but does not automatically change ownership or eligibility.

Decorative — nice to display but does not change a decision.

If the vendor cannot explain its schema cleanly, implementation will be harder than the demo suggests.

2. Where does each field come from?

“Proprietary data” is not enough.

You need a source model, even if the vendor cannot expose every upstream provider.

Ask:

  • first-party, public, licensed, partner, modeled, or inferred?
  • company-level or contact-level?
  • one source or multiple sources?
  • observed fact or probabilistic inference?
  • when sources disagree, what wins?

For high-risk fields, provenance matters as much as coverage.

3. What is the date or freshness model for each field?

A job title can become stale faster than a company founding year.

Ask for refresh logic by field class, not one marketing number for the whole database.

Useful categories include:

Field type Freshness question
Job title how quickly are role changes detected?
Employee range how often is the company re-estimated?
Phone/email when was deliverability last checked?
Technology is it observed, inferred, or self-reported?
Location headquarters, billing address, operating site, or person location?

A “daily refreshed database” can still contain fields with very different update cycles.

4. What does your coverage percentage actually mean?

Coverage can mean:

  • record exists;
  • field exists;
  • field was refreshed recently;
  • field passed validation;
  • record is in the target geography;
  • record matches your ICP;
  • field can legally be used in your workflow.

Those are not the same thing.

Ask the vendor to define the denominator and numerator for every headline percentage.

5. Can we test against our own sample before buying?

This is one of the highest-value questions.

Build a test file with:

  • blank records;
  • stale records;
  • recently verified records;
  • subsidiaries;
  • acquired companies;
  • international companies;
  • contacts who changed jobs;
  • ambiguous domains.

Do not let the vendor choose only easy records.

6. How do you distinguish blank-fill from overwrite?

Apollo's documentation is unusually clear here: Auto-fill writes when the mapped CRM field is empty; Overwrite can replace existing values.

Your buying requirement should be equally explicit.

Ask whether permissions can be set:

  • per field;
  • per object;
  • per workflow;
  • by source;
  • by record segment;
  • by verification state.

A product that can enrich but cannot govern writeback may create more cleanup than value.

7. Can we protect human-verified values?

A sales rep may have spoken directly with the account yesterday. That verified information should not be overwritten tonight by a third-party estimate unless you intentionally allow it.

Ask whether you can create rules such as:

  • never overwrite rep-verified title for 90 days;
  • never overwrite strategic account tier automatically;
  • never overwrite legal entity name without review;
  • fill employee range only if blank;
  • route a conflict to a queue instead of writing.

8. What happens when two sources disagree?

Do not ask only about “accuracy.” Ask about conflict behavior.

A mature system should be able to:

  • preserve the original value;
  • show the proposed value;
  • identify the source;
  • mark a confidence or review state;
  • send the record to an exception queue.

If the answer is “our data is more accurate, so we overwrite it,” keep asking.

9. Do you expose history and provenance in the CRM?

HubSpot's current enrichment experience includes enrichment information within its record intelligence model. Whatever system you use, you should be able to answer:

Who changed this field, when, from what, to what, and why?

If not, debugging becomes guesswork.

10. What controls exist for real-time versus scheduled enrichment?

Real-time is useful for new inbound records. Scheduled enrichment is useful for stale databases. They solve different problems.

Ask:

  • what triggers real-time enrichment;
  • how often scheduled jobs can run;
  • whether credits differ;
  • whether filters can limit the job;
  • whether the job can be paused;
  • what happens if the vendor is unavailable;
  • whether partial failures retry automatically.

Do not buy “real-time” as a badge. Buy the cadence that matches the decision.

11. How are credits, limits, and overages calculated?

Ask for a worked example using your projected volume.

You want to know:

  • what consumes a credit;
  • whether failed lookups consume credits;
  • whether repeated refreshes consume credits;
  • whether contact and company enrichment are priced differently;
  • whether exporting or revealing fields has a separate cost;
  • whether real-time jobs create hidden usage spikes.

The cheapest headline price can become the most expensive workflow if every refresh costs again.

12. How do you handle duplicates and entity resolution?

Enrichment is dangerous when the system cannot tell whether “ABC Holdings,” “ABC US,” and “abc.com” are the same entity.

Ask how the vendor handles:

  • parent/subsidiary relationships;
  • legal entity versus brand;
  • multiple domains;
  • mergers and acquisitions;
  • aliases;
  • duplicate contacts;
  • recycled phone numbers or emails.

This is especially important if enrichment drives account ownership.

13. What geographies and languages are actually strong?

Global coverage claims can hide uneven depth.

Ask for sample-level results in the countries you care about. If your team sells in the U.S., Canada, Japan, Germany, and Singapore, test all five.

Also ask whether job titles, address formats, company registries, and phone validation behave differently by market.

14. How do privacy, suppression, and deletion workflows work?

This is a governance question, not a checkbox.

Ask how the vendor handles:

  • opt-out or suppression lists;
  • deletion requests;
  • do-not-contact status;
  • regional privacy requirements;
  • fields that should never be reintroduced after deletion;
  • audit records for suppression decisions.

Get the answer in writing if the data will enter automated outreach.

15. What is modeled or inferred rather than observed?

Some fields are estimates by design.

Employee count, intent, revenue bands, technologies, buying stage, or seniority can involve inference depending on the provider.

Ask the vendor to label inferred fields so your team does not treat them as verified facts.

16. How do we measure whether enrichment is working?

Do not use “database completeness” alone.

A better pilot measures:

  • eligible blank-fill coverage;
  • agreement with trusted values;
  • harmful conflict rate;
  • exception-queue rate;
  • manual research time saved;
  • routing corrections;
  • bounced contact reduction;
  • opportunity or meeting outcomes by enriched versus non-enriched cohorts.

The right metric depends on the decision the field drives.

17. What is the rollback plan?

This question exposes implementation maturity.

Ask:

  • can previous values be restored?
  • is there a change log?
  • can a bad batch be isolated?
  • can enrichment writes be paused instantly?
  • can the integration be disconnected without deleting history?
  • can one problematic field be disabled without stopping everything?

If rollback requires a database restore, you do not have a field-level control system.

18. What would make you tell us not to buy?

This is the best closing question.

A credible vendor should be able to describe cases where its product is a poor fit:

  • your target market is outside its strong coverage;
  • your CRM hygiene is too weak;
  • you do not have field ownership rules;
  • your use case needs primary research, not database enrichment;
  • your volumes are too small for the economics;
  • your compliance workflow cannot support the data.

If the answer is “we work for everyone,” assume the qualification process is incomplete.

The shortlist table to take into demos

Score each provider from 1–5 on the dimensions that matter to your workflow:

Dimension Weight Vendor A Vendor B Vendor C
Target-market coverage 20%
Decision-critical field quality 20%
Provenance/history 15%
Writeback controls 15%
Entity resolution 10%
Privacy/suppression workflow 10%
Cost at real volume 5%
Rollback/support 5%

Do not let a vendor win because it has more total fields. Weight the fields and controls that affect your actual decisions.

Next-step checklist

Before signing:

  1. name the 5–10 fields that matter most;
  2. define fill versus overwrite rules for each;
  3. prepare a deliberately difficult sample;
  4. agree on acceptance metrics;
  5. document suppression and privacy behavior;
  6. model the real credit cost;
  7. test conflict handling;
  8. test rollback;
  9. run a limited pilot;
  10. scale only after the pilot meets the field-level acceptance rules.

The buying principle is simple:

Data enrichment is not a purchase of more data. It is a purchase of external evidence plus the machinery to merge that evidence into your CRM safely.

The vendor you want is the one that makes disagreement visible and controllable—not the one that fills the most cells during the demo.

Sources

Related Reading