The Data-Source Onboarding Playbook: Sample Test to Verified Backfill

You bought a new people-and-company data feed and now have to bring it into your system of record without creating duplicates, overwriting good fields, or importing records you cannot lawfully use. This playbook is for the RevOps, recruiting-ops, or data owner answerable for how the data was gathered. It runs the new source from a controlled sample test through a staged, segment-by-segment backfill, with a written field-ownership map, dedup rules, and a measured match-rate and coverage lift signed off before you touch a live record.

Every other operations guide handles data that already lives in your system: refreshing it, grading it, merging an acquired book. This is the distinct one-time job of standing up a brand-new external feed from first sample to full cutover. Do it in order and you never improvise over production data.

Why onboarding a new feed is its own job, not just an import

Onboarding a new data source is a gated procedure that ends in a signed go or no-go, not a file upload. The reason it needs its own method is that a feed's quality is unknowable from vendor marketing and only becomes visible when you test it against your own list and measure two numbers that trade off against each other.

Practitioners agree on this point: the only trustworthy test is a bake-off on your own records. Run the same 1,000-record list through five vendors and you get five different winners, because no provider tops both quality and coverage at once. Broad databases carry stale records, which lifts match rate and drops accuracy. Verified databases drop coverage to keep accuracy high. That trade-off is by design, which is why the sign-off gate must measure match rate and accuracy separately and never as a composite.

The other reason this is a real job is that the damage from doing it casually is irreversible. A Salesforce merge cannot be undone, the deleted records skip the Recycle Bin, and the merged record keeps Chatter from the principal only and the Created Date of the oldest record. A backfill that "worked" can still erase engagement history. So the work is front-loaded into tests and dry runs, and production is touched last, one segment at a time.

What "good" looks like: the numbers that clear each gate

A good result is a measured before-and-after on your own sample, not a vendor benchmark. There is no universal pass line to borrow, because a truly independent, methodology-disclosed third-party test of enrichment match rates barely exists. You set thresholds per source against your baseline.

Use published benchmarks only as reference points for what is achievable. The gap between them is the whole argument for staging carefully.

The lift from about 49% to up to 94% company match is the difference between scoring half your database and nearly all of it. Models, routing, and scoring built on a single feed silently run on half the data. That is the case for a waterfall - an enrichment stack that cascades unmatched records from one provider to the next and stops at the first match to save credits. But the range is blended, and the blended number is exactly where the failure hides, which the failure-modes section covers in full.

Measure five numbers at the gate and treat each as independent: match rate by record type, accuracy from a hand-verified sub-sample, coverage lift by segment, cost per verified record, and duplicate rate. The duplicate rate matters because more than 25% of records in the average database already contain duplicate data, so you need a pre-import baseline to detect regression.

Build the control sample before you talk price

The control sample is the single most important artifact in this playbook, and it must over-weight the worst part of your database. Vendors are strongest on clean, US, mid-market records, so a sample skewed toward those flatters everyone and tells you nothing.

Pull 100 to 1,000 records, sized to your patience and how many vendors you are comparing. The composition is what counts. If you want to enrich only leads missing phone number and job title, that scope is your baseline: pull a sample of leads that have no phone and no title. Then add a known-truth seed set of your own colleagues, customers, and contacts whose accuracy you can confirm by hand. Without the seed set you can measure match rate but not accuracy.

Lock the CSV so every vendor gets the identical file, and document the critical fields you are scoring. Freezing the file is what makes the comparison valid.

Run the procedure in order

Run these eight stages in sequence. Compliance clearance can run parallel to the bake-off, but staging, dedup, and backfill are strictly ordered because each depends on the artifact the previous stage produces.

A tight version of the bake-off fits in three days: day one, pull 500 real records; day two, run them through two free tiers; day three, score match rate and per-field fill rate. Insert a vendor match-rate report step first if you want their self-reported number to compare against your measured one.

Score the bake-off: match, accuracy, and cost per verified record

Score three separate numbers, because a match on its own tells you almost nothing. A match only means the vendor holds a record. It does not mean the record is any good.

The three numbers to record for every vendor:

• Match rate, by record type, so company and contact are scored separately rather than blended.
• Accuracy, from a random 50 records hand-checked against a primary source. This is the number that separates a database that holds a record from one that holds a correct record.
• Cost per verified record, which divides the price by the accurate matches, not the raw matches.

Check email specifically. A provider that returns an email without validating syntax, domain, and mailbox hands you bounces, so confirm the vendor verifies rather than merely appends. Phone is the weakest field across the board and where cheap APIs fall apart fastest, so if phone is what you are buying, weight the sample and the score toward it.

Clear compliance before the data lands, not after

Provenance is inherited liability, not a vendor checkbox. The moment you connect an enrichment feed, the vendor's compliance posture becomes yours, so compliance clearance is a gate that stands before the import, not a footnote after it.

For EU and UK personal data the load-bearing document is a Legitimate Interest Assessment, a documented evaluation of three tests - purpose, necessity, and balancing - that you complete before relying on legitimate interest as your lawful basis. It takes roughly two to three hours to produce and it cannot be written without knowing where each record came from. That is why you require a per-record provenance document from the vendor. Article 14 of GDPR forces you to inform any person whose data you obtained from a third-party source at the time of first contact, so "we do not know the source" is not a defensible answer to an access request.

Collect this evidence from the vendor before onboarding:

• A signed Data Processing Agreement.
• A clear data provenance document showing where records originate.
• Confirmation of hosting location.
• The cross-border transfer mechanism for any EU or UK records - whether the provider relies on Standard Contractual Clauses or an adequacy decision.

Two retention facts to encode in the load. ICO and CNIL set a maximum retention of three years from last contact for prospecting data, so stamp an acquisition date on every imported record. And GDPR data subject requests must be actioned within 30 days, extendable to 90, which only holds if you can trace a record back to its source. Refolk gives every returned record a stated origin across public LinkedIn, the public GitHub graph, and the open web, which is the provenance a legitimate interest assessment needs to stand up.

Map field ownership before you stage a single row

Assign survivorship per field, not per record, because a new feed will hold some fields better than yours and some worse. Modern master data management assigns ownership by field, not by record, and platforms that operationalize the golden record - the single reconciled version of a record - do it with field-level rules. The golden record is the version that survives conflict resolution.

Pick one winner rule for each field. The common inputs are source priority, completeness, recency, and verification status. Three rules cover most fields:

The rule that saves you is preserve-manual: manually authored values override consolidated ones, so a hand-corrected phone number is never clobbered by a bulk feed. The default in tools that document this is that manually added changes are prioritized, otherwise the most recent value wins. Add one safeguard on top: the most recent verified update survives, so a low-quality or stale source cannot beat a trusted value.

Overwrite mode has no way to express write NULL, so a blank source field silently erases a good production value.

Choose the staging merge mode that matches the source. Use upsert plus overwrite for a source sending a mix of new and changed records where empty source fields should not clear production values. Use overwrite-with-sentinel only when a user genuinely needs to blank a field, because default overwrite cannot express a deliberate NULL.

Stage, validate, and dry-run the merge

Everything runs against a staging table first, and no data touches production until it has passed. A staging table is a permanent intermediate table where raw data lands before it is validated, transformed, and loaded. Rows that fail validation get flagged with an error code so you can see exactly which checks failed rather than losing the batch.

Give the staging table metadata columns for batch ID, source file, and a processed flag, then run schema, format, date, currency, picklist, and dedup validation. The Salesforce and Zoho sandboxes mirror production for this, though note a Zoho constraint: records added in the Sandbox cannot be deployed to production, so use the sandbox to prove the logic, not to stage the real load.

Then design the merge carefully, because merge is where a clean onboarding quietly destroys value. Salesforce out-of-the-box matching considers name, email, and company for leads and contacts. Before any merge:

• Normalize phone and email so the matching keys actually match.
• Run in show-duplicates mode and review the duplicate report without writing anything.
• Export a full backup, because merge is irreversible and deleted records skip the Recycle Bin.
• Remember leads and contacts cannot be merged cross-object, so convert a lead to a contact before merging it with one.
• Know that the merged record inherits the oldest Created By and Created Date, and keeps Chatter from the principal record only.

The Salesforce UI merges up to three contacts at a time, so bulk cleanup needs tooling that preserves relationships and an audit trail rather than the native screen.

How this goes wrong: the failure modes to test against

The failure modes below are where a technically successful onboarding still leaves you worse off. Each has a false positive that looks like success and a specific check that catches it.

The one that fools experienced teams is the blended match rate. A stack can score 85% overall while missing an entire region or function. Agencies defaulting a US-strong provider onto EU lists watch coverage fall from around 55% to about 30%, invisible behind the headline number. Gate on segment-level lift, which is why the backfill is staged one segment at a time: you measure each segment on its own before you widen.

Sign off, roll back, and keep the source honest

The sign-off gate is a written go or no-go with the numbers attached, and a rollback plan for any missed threshold. The definition of done is that the critical workflow inputs reach the required completeness and freshness threshold before your workflow engine acts on them.

Keeping the source honest after cutover is its own discipline. Re-run the segment-level match and accuracy check on a fresh sample each quarter, because a feed that cleared the gate can drift as its underlying database ages. Watch the duplicate rate against your pre-import baseline as the first sign of a dedup rule that stopped working.

One last point on ownership. This competency is scarce even inside operations teams. In Refolk's index only 13 US profiles pairing a data-operations title with a Data Quality skill exist, so the person who owns this playbook is rarer than the tooling suggests.

The US pool is roughly 5.5 times the UK pool, and within the narrow US RevOps and marketing-ops slice, HubSpot appears about 4.3 times more often than Salesforce as a listed skill - directional given the small sample, but a reason to name the CRM this person will actually own before you hire. Make the data-quality ownership explicit in the role, because the field map, the survivorship rules, and the sign-off gate all depend on one accountable owner rather than a committee.