Importing Contacts From CSV Without Creating Duplicates

Oct 12, 2026

Most CRM data quality problems start on day one, with an import. A messy CSV becomes a messy database in about four seconds, and untangling it afterwards takes weeks.

Here is the procedure that avoids it.

Clean the File, Not the Database

It is far easier to fix a spreadsheet than a live CRM. Before you import anything:

Normalise the email column. Trim whitespace, lowercase everything, remove rows with obviously broken addresses. Email is almost always your best matching key and it only works if it is consistent.

Split combined name fields. If you have one “Name” column holding “Maria Schmidt”, decide now whether it becomes first and last name, and do the split in the spreadsheet where you can see the results.

Standardise the company names. “Acme Ltd”, “Acme Limited”, and “ACME LTD.” will create three companies. Sort by that column and scan it - the near duplicates cluster together and become obvious.

Fix the phone formats. Pick one convention, ideally international format with a country code, and apply it.

Delete the columns you will not import. Every field you are not going to map is a decision you have to make again during the import.

Choose a Matching Key Before You Start

A duplicate is created when the system has no way of knowing a record already exists. So decide what “already exists” means for your data.

Email address is the usual answer for contacts. It is unique in practice for individuals and it is the field most likely to be present in both the CSV and the CRM.

When a contact has no email - common for imported lead lists - decide in advance: either skip those rows, or accept that you will match them manually. Do not import them blind and sort it out later, because later never comes.

For companies, the matching key is usually the normalised company name or the website domain. Domain is better if you have it.

Import in Stages

Do not push 4,000 rows on the first attempt.

1. Import ten rows. Open them in Clientverse. Check that the fields landed where you intended, that accented characters survived, and that dates parsed correctly.
2. Fix the mapping if anything is wrong, and delete the ten test records.
3. Import a hundred. Check again, this time looking for the odd shaped rows - the contact with no last name, the company with a comma in the name.
4. Import the rest.

The check after step one catches encoding problems, which are the single most common import failure. If “Müller” arrives as “Müller”, stop, save the CSV as UTF-8, and start again. Fixing that after 4,000 rows is a find and replace across your whole database.

When Duplicates Appear Anyway

They will, because the same person appears as m.schmidt@acme.com in one list and maria@acme.com in another. No matching key catches that.

Deal with it as a scheduled cleanup rather than an emergency:

• Sort contacts by last name and scan for adjacent similar entries.
• Sort by company and look for the same person listed twice.
• When you find a pair, decide which record is the survivor - normally the one with more history attached - move anything worth keeping onto it, and delete the other.

Do this within a week of the import while you still remember the source data. After that the two records both accumulate notes and merging becomes a judgement call about which history matters.

Keep the Source File

Archive the original CSV somewhere with the date and where it came from. When something looks wrong in six months, the ability to check what was actually in the source file settles the question in a minute.

If the import is a full migration from another CRM rather than a contact list, the shape of the problem is different and the data migration service exists for exactly that.