There is exactly one moment when a purchased list is still somebody else’s problem, and it is the moment before it enters your CRM. After that it is your data. It will be filtered on, reported on, assigned to reps, dialled, exported into other systems and eventually cited in a meeting as though it came from somewhere trustworthy.
Ongoing list hygiene — the weekly and monthly routine that keeps a working file dialable — is a different discipline, covered in list hygiene for call centers. This page is about the import itself: the last checkpoint, and the one most teams skip because the CSV is right there and the reps are waiting.
Stage it. Everything else depends on this.
Load the vendor file into a staging table, a sandbox object, or at minimum a separate spreadsheet that is not your CRM. Do the inspection there. Import from staging into production as a second, deliberate step.
The reason is not caution for its own sake. It is that every check below is trivially reversible in staging and expensive-to-impossible in production, and you cannot know in advance which check is going to find something. Teams that stage routinely discover a broken column in ten minutes. Teams that import directly discover it in week three, in the form of a rep asking why every record in Maricopa County has the same phone number.
Nine checks before anything is mapped
- Row count against the invoice. The most basic reconciliation and the one nobody runs. If you paid for 40,000 records and the file has 38,412, find out why before you find out later.
- Fill rate per column. Count blanks in every field you intend to use. A column that is 30% empty is a filter that silently excludes a third of your list.
- Distinct-value sanity. Look at the top twenty values in each key column. One repeated phone number across thousands of rows, a single ZIP code covering half the file, a state field with 63 distinct values — all of these announce themselves here and nowhere else.
- Format damage. Leading zeros stripped from ZIPs and parcel identifiers, phone numbers rendered in scientific notation, dates flipped between day-first and month-first. Spreadsheets do this silently and it is not recoverable after the import.
- Encoding. Names with accents, apostrophes and ñ are the canary. If they arrive mangled, the whole file went through a bad conversion and the damage is not limited to the visible characters.
- Internal duplicates. Within the file itself, at household level rather than row level.
- Duplicates against what you already hold. The expensive one, covered below.
- Suppression. Run the file against your suppression list here, in staging, before it can reach anybody. Building a suppression list covers what belongs in that file and why importing around it is the most common way it gets bypassed.
- A physical spot check. Take ten rows at random and look up the addresses. Not a statistical test — a reality test. It catches whole categories of wrongness that no aggregate ever will.
Pick the dedupe key before you map a single field
Deduplication against existing CRM records is where imports do their real damage, because the failure is not a rejected row — it is a second record for a household you already own, holding different information, which two different reps will now work independently.
| Key | Why teams choose it | How it fails |
|---|---|---|
| Name | It is always present | Spelling, suffixes, married names, trusts. Matches things that are not the same person and misses things that are |
| Phone number | It looks unique | Changes constantly, is shared within households, and the same person arrives with a different number next quarter |
| It looks like an identity | Most people have several and use different ones per context | |
| Raw address string | It is in every file | Fails on abbreviations, unit formats and punctuation unless normalised first |
| Normalised property identifier | It is stable | Requires your CRM to have a field for it, which is the actual obstacle |
For homeowner data the property is the durable identity — the people and the phone numbers change, the parcel does not. The property data glossary explains what that identifier is and why it needs to be stored as text with its county attached.
Stamp the batch or you can never undo it
Three fields, written on every record at import time, and the whole thing becomes reversible:
- Batch identifier. Unique per import. This is the delete filter.
- Source. Which vendor, which order, which campaign. Six months later this is how you answer “which list is actually producing anything”.
- Import date. Every field in the record ages from here, and a rep looking at a two-year-old record should be able to see that it is two years old.
Those three fields also make vendor comparison possible for the first time. Without a source stamp, every list in your CRM performs the same, because you cannot tell them apart.
Map fewer fields than you were sent
Vendor files are wide because width is a selling point. Your CRM should be narrow, because every field you map is a field somebody will treat as true.
Import what you will act on: contact points, the identifiers, the qualifying attributes your campaign actually filters on, and the audit stamps above. Leave the rest in the staging copy, where it is retrievable and where nobody mistakes it for verified information.
Be especially careful with fields that arrive as a number and mean an estimate. Estimated equity, estimated income, a length-of-residence figure and a vendor confidence score all land in a CRM looking exactly like a measurement, and reps read them as one. If you import them, name the field so the estimate is visible in the label — homeowner data fields explained covers which fields those are and how to tell.
Test with 500 rows
Import a small slice first, through the real import path, into the real object. Then look at the imported records the way a rep will: open five of them, sort by each mapped field, run one of your standard views.
What you are hunting for is the failure that only appears after mapping — a date field that landed in the wrong column, a picklist that silently dropped values it did not recognise, an owner-assignment rule that put every record on one person, an automation that fired 500 welcome tasks. That last one is not hypothetical; it is the single most common unpleasant surprise of a first import.
Turn off automations for the load. Then turn them on deliberately, and watch the first small batch before releasing the rest.
Assign on purpose
An import with no ownership rule produces a large pool of records belonging to nobody, which is functionally the same as not having bought them. Decide the assignment before the load: by territory, by round robin, by campaign, or explicitly to a holding queue that somebody is responsible for working down.
The holding queue is an underrated option. It gives you a real answer to “how much unworked purchased data do we have”, which is a question most teams cannot answer and which usually has an uncomfortable answer.
What good looks like
A month after an import you should be able to say, quickly: how many records came in, from which vendor, what share have been touched, what the contact rate is on that batch specifically, and what it would take to remove it. A team that can answer those is a team that can decide whether to buy from that vendor again — what is a good contact rate covers how to define that measurement so batches stay comparable, and the skip tracing cost calculator turns it into a cost per conversation.
Disclosure: Scout Data is our product and we sell the kind of file this page tells you to be suspicious of. That is deliberate: every check here is one we would rather you ran on our deliveries than skipped. List Builder ships deduplicated against what you have already received and scrubbed before hand-off, which shortens the list above without replacing it.
Frequently asked questions
What is the most common mistake when importing a list into a CRM?
Importing it directly. Every other mistake on this page is downstream of loading a vendor file straight into the object your reps work, because that is the moment the file stops being reviewable and starts being your data. A staging pass costs an hour and is the difference between a bad batch you can delete and a bad batch you live with.
How do you deduplicate against records already in the CRM?
On a key that exists on both sides and does not change — which is almost never the phone number, and never the name. A normalised property identifier is the strongest option for homeowner data because it survives spelling, ownership changes and formatting. If your CRM does not store one, adding that field before the import is worth more than anything else on this list.
Should we import all the fields a vendor sends?
No. Import the fields you will act on and the fields you need to audit the batch, and leave the rest in the staging copy where you can go back for them. Every field you map becomes a field somebody filters on, a field that ages, and a field a rep reads as fact. A vendor’s confidence score dropped into a free-text box is worse than not having it.
How do you undo a bad import?
Only if you planned to. Stamp every imported record with a batch identifier, the source, and the import date before the load runs, and deletion becomes a filter. Without it you are reconstructing which records came from where by timestamp and hoping nobody edited anything, which in practice means the bad batch stays.