Importing contacts from a spreadsheet without making a mess

A clean import needs a spreadsheet with one row per customer, phone numbers in one format, a column for each field the CRM has (and no others), and a decision about consent before the file is uploaded. Duplicates are found before import, not after. Anything you would not want a new front-desk person to read is left out. Twenty minutes of preparation saves months of "which Maria is this".

Prepare the columns

Match the CRM's fields, no more: first name, last name, mobile, email, branch, source, and the industry handful. Delete the columns you will not use. A column called "notes2" with fifteen years of free text is not a field; decide whether it becomes notes on the timeline or nothing.

Phone numbers

The single biggest cause of import problems. Put every number in one format, ideally with the country code: +1 then ten digits. Strip spaces, brackets and dashes, or let the import tool do it and check its preview. Numbers with letters, numbers with too few digits, and "N/A" all need to go before import. Landlines are fine to keep, marked as such, but they will not receive texts.

Names

One first-name column, one last-name column. "Maria & Jose Gomez" is two customers or one household; decide. Titles, honorifics and nicknames go in a separate column or are dropped. Capitalisation: fix "MARIA GOMEZ" and "maria gomez" now, because the AI will use the first name as written.

Duplicates

Sort by phone number and look for repeats. Then by email. Then by name plus something else. Merge them in the spreadsheet before import, keeping the most recent details and combining notes. Importing duplicates and merging afterwards works but is slower and riskier. The import tool should also flag rows that match existing records and let you choose: skip, update, or create.

Consent

Importing a phone number does not import consent to text it. If the old system recorded consent, bring the column and the date. If it did not, the honest position is that these customers have not consented to marketing texts, and reminders should be confirmed at the next booking ("Can we text you reminders at this number?"). Do not import a list and start sending promotions to it.

What not to import

Card numbers. Social Security numbers. Medical detail in free-text columns. Passwords. Old internal comments about customers that you would not want read aloud. Anything from a list you bought. If it is sensitive and the CRM does not have a field for it, it does not belong in the CRM.

The dry run

Import ten rows first. Open them. Check names, numbers, branch, source. Send one test reminder to your own number from an imported record. Then import the rest. A dry run finds the column mapped to the wrong field before it is 3,000 records deep.

After the import

Set the source for imported records to "imported" with the date, so you can tell them from customers who came through the front door. Mark status as customer or inactive based on the last visit date, if you have it. Then let the AI and the conversations take over updating.

Frequently asked questions

What format should the file be?

CSV, UTF-8, one header row. Exports from spreadsheets and most old systems can produce this.

Can I import appointment history?

Some systems allow it; the value is the timeline ("last visit March"). If you can bring last-visit date and a service, do; a full history is rarely worth the cleaning.

What about customers who have asked not to be contacted?

Bring the opt-out as a column and make sure it imports as an opt-out, not as an empty consent. Check on the dry run.

What Frontiva does here

Frontiva's CRM imports CSV with column mapping and a preview of exactly what will be created and what matches an existing contact, checking phone and email against your contacts and against other rows in the file; nothing changes between preview and import. Import contacts, not consent: confirm texting consent at the next booking. See deduplicating customer records for the cleanup side.