How to Import Contacts Into a CRM From a Spreadsheet

To import contacts into a CRM from a spreadsheet: clean the file to one row per record and one column per fact, map each column to its field, import companies before the people who work there, run a small test batch, then import the rest. Skip the order and you get duplicate companies, orphaned contacts and garbled fields.

This covers contact, company and deal data moving in from a spreadsheet. For the rules a CRM uses to decide what counts as a duplicate and how records relate to each other, see how a CRM database is structured before you start; this guide assumes that model and doesn’t repeat it.

What should you clean up before you import contacts into a CRM?

An import reads your spreadsheet exactly as written, mistakes included. Fix these before you touch the CRM:

• One row per record. If a contact has two rows because they appear on two deals, that’s two records after import unless you consolidate first.
• Split combined columns. “First Last” needs to become two columns, First Name and Last Name, because most contact fields are separate.
• Standardize formats. One phone format, one date format, no mixed date orders (3/4/26 could be March 4 or April 3). Emails lowercase, without extra spaces.
• Remove blank required rows. A row with no name and no email imports as a nearly empty record that’s harder to find and merge later than to skip now.
• Delete merged cells and hidden rows. Both survive a save as a spreadsheet file and confuse an import that expects a flat grid.
• Save as CSV or Excel (.xlsx). Either works; CSV is safer across tools because it can’t carry hidden formatting or formulas that resolve differently on import.

Fifteen minutes here saves an afternoon of cleanup inside the CRM, where fixing a field means editing one record at a time instead of one spreadsheet cell.

How do you map spreadsheet columns to CRM fields?

Field mapping tells the import which spreadsheet column fills which CRM field. Most imports show your header row next to a dropdown of available fields and guess the obvious matches (Email to Email, Phone to Phone), leaving the rest for you to assign by hand.

A column with nowhere obvious to go has two honest options: skip it for now, or add a custom field before you import so the data has somewhere to land instead of getting silently dropped. Don’t map two spreadsheet columns to the same field: the second one usually overwrites the first, and which one “wins” depends on column order, not intent.

Why import companies before the people who work there?

A contact belongs to a company; a company doesn’t belong to a contact. Import contacts first, and a CRM that auto-creates the company from a text field will create one company per contact whose name is spelled even slightly differently: “Acme Inc.” and “ACME Incorporated” become two accounts instead of one, each with half the contacts. Import companies first, and every contact has a real account to attach to on arrival.

The relationship between these record types, and what makes two of them count as the same one, is covered in full in the CRM database guide linked above. The order below is the practical consequence of that structure, not a separate rule.

1. Companies (accounts). Owner: whoever is running the migration. Output: one account per real organization, with no duplicates from spelling variants.
2. Contacts. Output: each contact matched to its account by a shared column (a company name or ID that appears in both files).
3. Deals. Output: each deal matched to its contact and account the same way, plus amount, stage and close date if the sheet has them.
4. Activities or notes, if you’re bringing history. Output: past calls, emails or tasks attached to the record they belong to, dated correctly rather than dated “today” by default.

How do you run a test batch before the full import?

Pull twenty rows that represent the messiest parts of your data, not the cleanest twenty at the top of the file: a contact with no email, a company name with an ampersand or accent, a very long note, a duplicate you already know about, a row with every optional field blank. Import that batch alone.

Then check, before touching the other several thousand rows:

• Did every field map to where you expected, including the ones you assigned manually?
• Did the twenty rows create the right number of new records, not more?
• Did any row fail silently, accepted with a blank field where the sheet had a value?
• Does the known duplicate show up as a new record or get caught for review?

If the test batch looks wrong, delete those twenty records, fix the mapping or the source file, and test again. A mistake caught in twenty records is an edit; the same mistake found after five thousand is a cleanup project. Once the test batch is right, import the rest of the file the same way, in the same company-then-contacts-then-deals order.

What happens to duplicate contacts during import?

Most CRM imports run in create-and-update mode, often called upsert: a row that matches an existing record by email updates it, and a row that doesn’t creates a new one. That makes re-running the same file safe, since nothing doubles just because you imported it twice, but it only catches a duplicate that matches on the exact field you chose.

An import does not stop a genuine duplicate from being created if it doesn’t match that key: two different emails for the same person, or a name typed two ways, both come in as separate records. Finding those is a manual step today. After the import, open the Duplicates view and review what it flags by email or phone; merging two records into one is a decision you make, not something the import does for you. Configurable matching rules that catch more of this automatically are on the roadmap, not available yet.

What should you check once the import is finished?

• Record counts. Rows in the file should roughly match records created plus records updated; a gap usually means a mapping error, not a coincidence.
• A handful of records by hand. Open five imported contacts and confirm phone, email and account look right, including any accented or non-English characters.
• Required fields on new records. A record that’s missing an owner or a stage won’t show up where the team expects to find it.
• The Duplicates view. Scan it once, right after the import, while the batch is still easy to recognize.

Example: an 18-person industrial distributor in Toledo, Ohio (illustrative, not a real company) migrates from a shared spreadsheet with about 3,400 contacts across 900 companies. Company names were typed by six different people over five years: “Midwest Fabricating,” “Midwest Fab,” “Midwest Fabricating LLC.” Importing companies first and cleaning obvious variants in the sheet beforehand gets them to 860 real accounts instead of 900. The test batch catches one thing they’d missed: a “Preferred Contact Method” column nobody had mapped, which would have silently dropped for all 3,400 rows if they’d run the full file first.

How does this work in Senitix CRM?

In Senitix CRM, every plan, including Free, imports and exports contact, company and deal records as CSV or Excel files, with a preview of the mapping before the import runs. Imports can create new records, update existing ones, or upsert (matching on the field you choose) for standard modules. A connected mailbox and calendar bring in the emails and meetings a spreadsheet can’t carry; the integrations, import and export section of the feature catalog covers what connects natively and what runs through a registered app. For a Senitix-specific walkthrough of field mapping screen by screen, see importing your first batch into Senitix CRM.

If your contacts are still sitting in a shared spreadsheet today, our guide to where a Google Sheets CRM breaks covers the signs it’s time to move. When you’re ready, compare plans and start on Free: importing your existing file is one of the first things you can do once your workspace is set up.

Frequently asked questions

Can I undo a CRM import if something goes wrong?

Usually yes for records the import just created, since a batch typically carries an import ID or timestamp you can filter on and delete in bulk. It’s much harder to undo an update to existing records, because the import doesn’t keep the old value once it overwrites it. This is exactly why a small test batch matters more than a backup plan.

Should I use a CSV file or an Excel file to import contacts?

Either works with most CRMs. CSV is the safer default because it’s plain text, with no hidden formulas, merged cells or multiple sheets to confuse the import. Excel is fine if your file is simple; if you’ve had any formatting trouble, save a CSV copy from Excel or Google Sheets and import that instead.

Do I need to import every field at once?

No. Import the fields you need to run the business first (name, email, phone, account, deal stage) and add the rest in a second pass once the core records exist. A second import that updates existing records by email is a normal way to add fields you skipped the first time.

What if my spreadsheet has contacts with no company listed?

Decide on a placeholder before you import rather than after: something like “Unknown” or the contact’s own name as a temporary account, flagged so you can find and fix it later. An unmapped or blank company column usually means the contact imports with no account at all, which makes it harder to find during cleanup, not easier.