Customers

Lists, import and duplicates

Getting a spreadsheet in, keeping one person to one record, and asking the list a question.

The honest blocker on moving to any CRM is that your customers are in a spreadsheet somewhere. These three things are what makes that survivable: getting the file in, cleaning up what two sources disagree about, and then being able to ask the list something.

Import

A bad row never fails the file

Three thousand rows with one broken address import 2,999, and the one is reported with its line number so you can look at that line in your spreadsheet. All-or-nothing sounds safer and is worse: the import dies, nobody can tell which row killed it, and the file gets bisected by hand.

1
Inspect
Columns are matched to fields and you correct the guesses. The parser copes with what Excel actually writes — the invisible marker at the start of the file that stops Email matching Email, and the semicolons every comma-decimal locale uses instead of commas.
2
Plan
Every row is shown as it will be treated: created, matched to somebody already here, skipped, or refused with a reason. Nobody un-imports two thousand contacts, so this is where the decision gets made.
3
Apply
A duplicate is matched, never overwritten — what is already here is newer and more curated than a spreadsheet. Rows whose address is on the suppression list are skipped and said so.

Consent cannot be imported

There is no column that maps to one, on purpose. A consent record has to carry how it was obtained and the exact wording somebody was shown; a cell reading TRUE manufactures that evidence out of nothing, and the first time it matters is the first time you are asked to produce it.

Duplicates

Import and sync both create duplicates in ways that cannot be prevented at the door, so merging is not optional. Every pair is a suggestion with its reason attached, and nothing merges itself — two people genuinely share a name, an employer and a switchboard, and a scan acting on its own findings destroys one of them, discovered months later in a history containing a conversation that never happened.

Signal	How strong
The same LinkedIn profile	Certain — it belongs to one person and survives them changing jobs
The same mobile number	Likely
The same name at the same company	Likely
The same landline	Possible — a desk is not a person

The email address is deliberately not a signal for contacts: two records can never hold the same one, so a match is unreachable. What actually happens is one person under two addresses, which is why the signals above are the ones somebody carries between jobs.

A merge never widens permission to contact somebody

If either record says do-not-contact, the survivor does. It is the one mistake here with a statutory penalty attached.

A merge is not a delete. The record merged away keeps a pointer at the survivor, so a link pasted into an email months ago still lands somewhere sensible — and because one contact can hold only one address, that pointer becomes the record that this second address is also theirs. Which is usually why there were two records.

Segments

A saved question, not a saved answer. Nothing is materialised: a stored membership list is wrong the moment somebody logs a call, and invisibly so. A segment is a filter you name, share or keep to yourself, and it runs through the same engine the ordinary list does — so there is no second definition of what a contact list is.

An unfiltered segment is refused

It is everybody, under a name that promises otherwise.