Skip to content
NAFRU SCOUT
← All posts

3min read

Mapping the fields when a list moves into a CRM

A single CSV import can destroy months of collected context beyond recovery. Five fields that need a decision before the list is moved anywhere.

A patch panel in a network cabinet, coloured cables plugged into rows of numbered ports and gathered downward.
"Ethernet Patch Panel 20171121 130458" by Kbh3rd, CC BY 4.0, via Wikimedia Commons. Cropped to 3:2.

A list starts in a spreadsheet and at some point moves into a CRM. The move usually looks like a five-minute job: upload the CSV, map the columns, import. Months of accumulated context disappear on exactly that screen, because the CRM’s field list is not your spreadsheet’s field list and the default behaviour for any unmatched column is to be dropped without a word.

What you lose is the history, not the address

Name, phone and email have a counterpart in every CRM. They are not where the problem is.

What goes missing is this: which source you found the record through, which round you wrote in, which signal pushed it up the order, the record’s status, and the date of the last contact. None of those is a standard field. All of them are the data that sets the ordering for your next round.

When the source is gone, you find the same business six months later and evaluate it from scratch. That costs more than a duplicate does.

Five fields to decide on before moving

Each one either gets a home in the CRM or is given up deliberately.

Source. Where the record came from. It should be a value picked from a fixed list rather than free text, or within six months the same source will be sitting there under four different spellings.

Status. active, suspect, closed, not interested. Four values are enough, and this field is what decides who ends up on a sending list.

Priority score. A number you assign. Even if the CRM has its own scoring feature, keep yours in a separate field; theirs is measuring something else.

Last contact date. The CRM usually tracks this itself, but past contacts do not come across in an import and the field fills with today’s date. It needs carrying in a field of its own.

The finding. The observation that pushed the record up, one sentence. The personalised part of your message comes out of it.

A two-minute check before importing

Look at two things before you upload the CSV. Both are hard to correct afterwards.

The first is date format. 03/09/2026 is the third of September in one CRM and the ninth of March in another. Converting the column to ISO (2026-09-03) removes that ambiguity entirely.

The second is phone number format. A column that has lost its leading zero turned into a number on the way through a spreadsheet. Carry numbers as text, with the country code.

Pick the dedup rule before the import

Most CRMs offer “skip duplicates” or “merge” during an import and do the matching on email. In local business lists, email is empty on most records.

So the matching has to run on the phone number or the domain instead. If there is no such option, deduplicate on your own side before importing; merging inside a CRM is always more work.

Ten records first

Do not move five hundred records in one go. Import ten, open them in the CRM, and see with your own eyes that all five fields landed where they should.

If those ten go wrong, deleting them takes five minutes. If five hundred go wrong the same job stretches to a day, and some CRMs have no bulk undo at all.

Related posts

NAFRU Scout demo

Let's talk about your workflow.

Enter your details to request a demo.