Importing a business list into your CRM without duplicates
Auspector ·
A CRM import is safe when one question is answered first: what makes two rows the same business? Our exports carry a stable per-record identifier, so a re-import updates existing rows instead of duplicating them — which is also what makes the weekly refresh cheap: a record you have opened before never costs a credit again. Match the columns, key on the identifier, and leave the merging of chain branches to your own account structure.
The one question that decides everything
Every import dialog eventually asks the same thing twice, in disguise: “create new records” or “update existing ones?” Answer it wrong and the same business appears twice — call history split, owner fields overwritten, reports doubled. The answer lives in one decision made before the first import: what field identifies a business. Decide that, and everything else is mechanics.
Step 1: match the columns to CRM fields
Most CRMs accept CSV or XLSX and walk you through mapping columns to their own fields. The export carries one row per business: name, category, address, city, district, phone, website, coordinates and the record identifier. Send name to account name, address to the street field, district to the area field, phone to the main phone — and the category, which is the record’s own and not merged, into whatever industry or tag field your CRM uses, as free text. Leave the coordinates column in if your CRM has a location field; it costs nothing and saves re-typing.
Step 2: choose the matching key
The matching key, in order of preference: the stable record identifier first. It is on every export, it never changes for a given business location, and a re-import against it updates the row rather than creating a second one. If your CRM cannot import an external identifier into a match field, fall back to what you have: the full address plus the name, or the phone number — each with a known weakness. Addresses get reformatted by importers; names carry legal suffixes; phones are shared by chains. That is why the identifier exists.
Step 3: re-import as an update, not an append
Treat the import as a refresh, not a one-off. New businesses arrive every day, so the practical rhythm is: export weekly, import against the identifier, and let existing rows take their updates while genuinely new rows appear once. Two cost notes make this sustainable: search and counting are unlimited, so checking what is new costs nothing; and a record you have opened before never costs a credit again — an export is an open, but only the first one for each record (pricing). The export step itself is stage six of building a lead list from new businesses.
Chains and shared phone numbers
One trap deserves its own paragraph: identical phone numbers across different rows. A chain can list one head-office number on forty branch records, and a service operator can cover many areas from one line. Do not merge those records in the CRM — each branch is a real place with its own address, and merging destroys exactly the field-team geography you imported. Phone repetition is a call-list problem, not a CRM-identity problem: dedupe by number when you build a call sheet, and let the identifier keep the accounts apart. What the numbers look like in each market is covered in the fill-rate explainer.