How to Import a Lead List Into Your CRM Without Wrecking It

Nobody thinks of the import as part of the job. You get a file, you click Import, you start dialing. Ten minutes of admin at the front of a week of work.

But almost every ugly pipeline problem I have seen in an agent's CRM was created at import. Duplicate records dialing the same widow twice in a morning. A consent column that existed in the file and does not exist in the CRM, so there is nothing to produce if anyone ever asks. Phone numbers stripped of a leading digit by a spreadsheet. Two thousand contacts with no source tag, so six weeks later you cannot tell which batch was worth the money.

None of that shows up on day one. It shows up in month three as a vague sense that your CRM is a mess. This is the import process I would hand a new agent — eight steps, maybe twenty minutes for a list of a few thousand, and it holds up whether the file came from a vendor, a Facebook form, or a folder of your own old leads.

Step 1: Open the file and look at it before you import anything

Sounds obvious. Almost nobody does it. Open the CSV, scroll to the bottom, and scan the middle. You are looking for four specific things:

• Junk rows.A title row above the headers, a blank spacer row, a “TOTAL: 500 leads” row at the bottom. Each one becomes a contact named “TOTAL” with no phone number.
• Merged or split columns.A single “Name” column that is sometimes “Mary Ellison” and sometimes “Ellison, Mary” will produce first names like “Ellison,” which is what you will greet people with on the phone.
• Phone format chaos. Some rows with dashes, some with parentheses, some as raw digits, and a handful that Excel helpfully turned into scientific notation.
• Empty required fields. Rows with a name and no phone are not leads. Rows with a phone and no name are workable, but you should know how many you are getting.

Two minutes here saves an hour of cleanup later, because once bad data is inside the CRM it is mixed in with good data and you no longer have a clean file to re-import.

Step 2: Decide what a “lead” is in this file

Lead files are not always one row per person. Direct mail returns sometimes arrive one row per household. Aged files sometimes arrive one row per event — the same person appearing three times because they filled out three forms across two years.

If you import an event file as-is, you get three contacts for one person, and your dialer will cheerfully call them on three separate days from three separate records. That is the single fastest way to turn a warm lead into a complaint. Collapse to one row per phone number before importing, and keep the earliest and latest opt-in dates as separate columns.

Step 3: Normalize phone numbers as text

Phone numbers are not numbers. They are identifiers that happen to be made of digits, and every spreadsheet in existence will try to treat them as quantities — dropping leading zeros, rounding long strings, converting to scientific notation.

Before import, force the phone column to text and normalize to a single consistent format. Ten digits with no punctuation is the safest, or E.164 (+15551234567) if your source provides it. The formatting itself does not matter much; the consistency matters enormously, because your deduplication, your DNC scrubbing, and your suppression list all match on this value. If half your records store (555) 123-4567 and half store 5551234567, they will not match each other, and a number you suppressed last month can sail through as new.

This is also the step where you drop the obviously invalid: anything that is not 10 or 11 digits, anything that is all the same digit, anything starting with 555-01. They are not going to become valid later.

Step 4: Map the fields that actually matter

Most agents map three fields — first name, last name, phone — and let everything else fall on the floor. That is the expensive mistake, because two of the abandoned columns are the ones you will want most.

Source and opt-in date are the two everyone drops and everyone later wishes they had. Source is how you answer “is this batch working” without guessing. Opt-in date is how you answer “when did this person agree to be contacted” — which is a question with real consequences, and which the person asking will not accept a shrug for.

If you are unclear on what belongs in that record and how long to keep it, the anatomy of a TCPA consent record is the piece to read before your next import, not after your first demand letter.

Step 5: Deduplicate on phone, and merge rather than replace

Deduplicate on the normalized phone number. Not on the name — names arrive spelled inconsistently, and a mother and daughter in the same house frequently share one. Phone is the only field that reliably identifies the person you are about to dial.

Two kinds of duplicates matter, and they need different handling:

• Within the file. Collapse before import. Keep one row, preserve the earliest and most recent opt-in dates.
• Against contacts you already have. This is the one that hurts. If the CRM creates a second record, you now have one person with two call histories, two disposition states, and two places to look. The correct behavior is to attach the new source and date to the existing record and keep the history.

The reason cross-import dedupe matters so much is that every suppression you have ever applied lives on the existing record. Someone told you to take them off your list in March. In July their number shows up in a new batch. If that import creates a fresh contact with a clean slate, your do-not-call request has effectively been erased by a CSV — and the next call carries statutory damages of $500 to $1,500. This is exactly the failure mode that makes account-level suppression, rather than list-level suppression, non-negotiable.

Step 6: Scrub inside the CRM, before the first dial

Do the import, then scrub — not the other way around. Scrubbing a raw file before it enters the system only checks it against external lists. Scrubbing after import checks it against those plus everything you already know: your internal do-not-call list, numbers you marked disconnected, people who already bought from you.

The scrub is not one job. Federal DNC, state registries, your own internal list, and litigator flagging are four separate checks with four separate cadences, and the breakdown of what each one covers is worth reading in full if you have been treating them as a single step.

A practical rule: no new batch gets dialed on the same day it is imported unless the scrub has already run against it. That one habit costs you a few hours of impatience and removes the single most common way agents dial someone they should not have.

Step 7: Tag the batch so you can measure it later

Every import should carry a batch tag — source, vertical, and the date you loaded it. Something like fb-fe-2026-07-30 is enough. It takes ten seconds and it is the difference between running a business and running on vibes.

With batch tags you can answer, in one query, questions that are otherwise unanswerable: which source produces the highest contact rate, which one produces the most bad numbers, which one produces do-not-call requests at three times the rate of the others. Without them, every list blends into an undifferentiated pile and your only evidence is whichever call you happen to remember.

This is also how the aged stuff stays useful. A batch tagged and dated in July is a segment you can deliberately re-work in December, which is the entire premise behind a structured revival pass on your own old leads. An untagged pile is just a pile.

Step 8: Spot-check twenty records before you dial two thousand

Pull twenty contacts at random from the fresh batch and read them the way you would read them on a call screen. Does the first name look like a first name? Is the phone ten digits? Is the state populated? Is the source tag there? Did the opt-in date land in a date field or as the text string “7/14/2026” in a notes box?

Twenty records takes three minutes and catches essentially every systematic mapping error, because mapping errors are never subtle — a column mapped to the wrong field is wrong in all 2,000 rows. Catch it here and you re-import. Catch it on dial 400 and you have 400 dispositions and call logs tangled into bad records.

The three import habits that cause the most damage

1. Importing into a fresh, separate list every time

Agents do this because it feels tidy — one list per purchase, easy to see what came from where. What it actually does is fragment the person. The same contact ends up in four lists with four histories, and your suppression, your attempt cap, and your callback all live in whichever copy you happened to dial. Import into one contact database and use tags for separation.

2. Treating the CRM as the place the file goes to die

A lot of imports happen because the agent feels they should have the data somewhere, not because they plan to work it. Those batches sit untouched, age out, and quietly inflate the contact count until the CRM feels overwhelming to open. If a list is not going to be dialed within a week or two, tag it as parked at import so it does not pollute your working queue — and so you can find it deliberately later.

3. Importing a list you have not verified consent on

The import is the last cheap moment to ask the uncomfortable question: where did these people actually opt in, and to what? A file with no opt-in dates, no source URL, and a vendor who gets vague when you ask is a file that can cost far more than it cost. Aged co-registration data in particular is where agents get hurt, because the consent, if it exists at all, was given to somebody else for something else.

You do not have to become a lawyer about it. You do have to be able to say, for any number in your CRM, where it came from and when the person agreed to be called. If the answer is “it was in a spreadsheet someone sent me,” that is your answer to a complaint too — which is one of the structural reasons the spreadsheet stops working well before most agents give it up.

What good import tooling should do for you

Most of the eight steps above should not be manual. A CRM built for agents working phone lists ought to handle the mechanical parts, and it is fair to judge one on exactly this:

• Guess the column mapping.“Ph,” “Phone1,” “Primary Phone,” and “mobile” are all the same field. You should be confirming a mapping, not building one from scratch on every import.
• Normalize phone numbers on the way in, so dedupe and suppression match reliably regardless of how the source formatted them.
• Match against existing contacts and merge, preserving history and suppression rather than creating a parallel record.
• Refuse to dial an unscrubbed batch. The guardrail should live in the system, not in your memory at 9am on a Monday.
• Show you a preview of what will be created, updated, and skipped, before it commits.

If an import tool does none of that — if it is a raw column-matching screen that dumps rows in and wishes you luck — the twenty minutes of prep in this article is not optional. It is the only thing standing between you and a pipeline you stop trusting.