A more defensible way to compare data enrichment tools is to stop reading vendor pages side by side and instead run one fixed sample of your own records through each candidate, then score the results against six weighted criteria. Match-rate claims are produced on populations you will never see. A fixed sample of your own records (200 is a suggested size, not a magic number), scored with the same rubric for every tool, produces a number you can defend in a purchasing conversation.
This article gives you that rubric: a 100-point scorecard with fixed weights, a testing protocol built around one acceptance rule, and a worked illustrative example showing the arithmetic end to end.
Four architectures, not one category
"Enrichment tool" covers four different product shapes, and the shape determines what your evaluation should stress.
Lookup tools answer one query at a time against one dataset: give a domain, get firmographics. They are cheap to trial and easy to reason about, but coverage lives or dies on that single source, and gaps have no fallback.
Database platforms bundle a searchable universe of companies and people with export and filtering. Apollo, for example, positions company and person search for B2B prospecting. The evaluation question for this shape is whether the searchable population overlaps your actual market, not how large the database is in aggregate.
Orchestration layers sequence multiple sources per record: try source one, fall back to source two, verify the result, write it back. This is the waterfall enrichment pattern. Coverage is usually higher, but so is the configuration surface, and cost per record depends on how deep the waterfall runs before a field resolves.
CRM-native enrichment lives inside the system of record. HubSpot offers enrichment within its CRM as one example of this shape. The appeal is zero integration work; the constraint is that you inherit whatever sources and refresh behavior the CRM vendor chose.
Many teams end up combining shapes. That is fine. The scorecard below works per tool, so you can score a CRM-native option and an orchestration layer independently and decide whether the overlap justifies both. If you want the underlying concepts first, the glossary entries on data enrichment and contact enrichment define the terms this article assumes.
The 100-point scorecard
Six criteria, fixed weights, totaling 100. The weights encode a specific opinion: fit to your market matters more than any feature, and verification matters more than raw coverage, because an unverified field creates work rather than removing it.
| Criterion | Weight | What you are actually testing |
|---|---|---|
| Fit to your market | 25 | Match rate and field completeness on your sample, in your segments and regions |
| Verification | 20 | Whether returned fields pass an independent check, and whether the tool shows verification status |
| Freshness | 15 | Evidence of recency: last-updated signals, change detection, stale-record behavior |
| Integration | 15 | Effort to land results in your CRM, sheets or API without manual export cycles |
| Control | 15 | Field-level overwrite rules, approval gates, audit trail, provenance on every value |
| Usable cost | 10 | Cost per accepted record at your volume, not list price per credit |
Two notes on the weights. Control at 15 surprises people until the first bad overwrite: a tool that silently replaces a correct CRM value with a stale one destroys trust in the whole dataset, and knowing where each value came from is the point of data provenance. And usable cost sits at only 10 because cost per accepted record already depends on fit and verification; pricing it higher double-counts failure.
The protocol: one fixed sample, one acceptance rule
Build the sample. Pull 200 records from your CRM that represent the work you actually need done. Include your hard cases deliberately: small companies, non-US regions, recently funded accounts, records with only a name and domain. A sample of easy records tells you nothing.
Set one acceptance rule and apply it to every tool. For example: a returned field counts as accepted only if it passes an independent check you control. For emails, that means a mailbox verification step you run yourself, not the vendor's own status flag. For titles, it might mean spot-checking 30 records against public profiles. Be explicit that mailbox verification only estimates whether the address currently accepts mail, and the check can come back inconclusive. It does not confirm the person's current role, their fit, or any permission to contact them. Those are separate columns in your worksheet.
Run every tool against the same 200 records in the same week. Record, per tool: fields returned, fields accepted under your rule, time from upload to usable output in your CRM, and total cost consumed.
Score. Rate each criterion 0 to 5 based on what you measured, then compute weighted points as rating divided by 5, times the weight.
Worked example (illustrative)
The following is an illustrative example with two hypothetical, unnamed tools. The ratings are invented to demonstrate the arithmetic, not measurements of any real vendor.
A hypothetical RevOps team enriches inbound signups from mid-market European manufacturers. Tool A is a lookup-style product; Tool B is an orchestration-style product.
| Criterion | Weight | Tool A rating | Tool A points | Tool B rating | Tool B points |
|---|---|---|---|---|---|
| Fit to market | 25 | 4/5 | 20 | 5/5 | 25 |
| Verification | 20 | 3/5 | 12 | 4/5 | 16 |
| Freshness | 15 | 4/5 | 12 | 3/5 | 9 |
| Integration | 15 | 3/5 | 9 | 4/5 | 12 |
| Control | 15 | 2/5 | 6 | 4/5 | 12 |
| Usable cost | 10 | 4/5 | 8 | 3/5 | 6 |
| Total | 100 | 67 | 80 |
Check the arithmetic: Tool A is 20 + 12 + 12 + 9 + 6 + 8 = 67. Tool B is 25 + 16 + 9 + 12 + 12 + 6 = 80.
The interesting part is not the winner. Tool A scored higher on freshness and usable cost, so if this team's workflow were high-volume, low-stakes list hygiene, the weights themselves might deserve adjustment before the scores do. The scorecard makes that argument explicit instead of leaving it as a hallway opinion. For a team whose downstream step is lead scoring and routed outreach, the control gap on Tool A (2/5, no field-level overwrite rules in this hypothetical) would be disqualifying regardless of total score, because a bad overwrite corrupts the scoring inputs.
Tradeoffs and failure handling
Waterfalls hide cost variance. An orchestration layer that tries four sources per unresolved field can quietly double per-record cost on hard segments. Measure cost per accepted record on your hard cases specifically, and set credit ceilings before scaling volume.
CRM-native convenience can become lock-in on refresh behavior. If the CRM vendor's refresh cadence does not match your sales cycle, you cannot fix it from inside. Test how the tool behaves on a record you know changed recently.
Verification theater. A vendor status flag reading "verified" is a claim, not a check. Your acceptance rule exists so every tool is measured against the same independent standard.
Overwrite damage is not always reversible. Treat any bulk write to the CRM as potentially destructive. Prefer tools with approval-gated writes and provenance, and run the first sync against a sandbox or a tagged subset. This same discipline applies when enrichment feeds broader prospecting data infrastructure rather than a single CRM object.
Sample drift. If you rerun the evaluation next quarter, use a fresh sample of the same size and mix. Comparing a new tool's fresh-sample score against an old tool's stale-sample score is not a comparison.
FAQs
What is the difference between a lookup tool and an orchestration platform? A lookup tool answers single queries against one source. An orchestration platform sequences multiple sources and verification steps per record. Orchestration usually raises coverage on hard records but adds configuration work and variable per-record cost, which is why the protocol measures cost per accepted record rather than list price.
Why test on my own records instead of trusting published match rates? Published rates reflect the vendor's test population. Your industry mix, regions and record quality change outcomes materially. A fixed sample from your own CRM, run through every candidate under one acceptance rule, gives you a baseline where the numbers are directly comparable.
Does a verified email mean the person is a valid lead? No. Mailbox verification estimates whether an address accepts mail, and the result can be inconclusive. It does not confirm current role, ICP fit, intent or permission to contact. Score identity confidence and fit as separate criteria so an address that passes verification never masquerades as a qualified target.
Run the scorecard on real records
If you want to see how an objective-to-dataset approach handles the verification and provenance columns of this scorecard, sign up for AstroFabric and run a sample of your own records through an enrichment playbook with approval-gated writes turned on. Score what comes back under your own acceptance rule, the same way you would score anyone else.
Sources
Every playbook on this blog ships as a runnable mission.
Open a workspace and the playbook library is waiting - describe the outcome and the agents carry it end to end, on your plan's monthly credits.