How to Format a Lead CSV for CRM Import

Why CSV Format Errors Kill Your CRM Data Quality

Every sales team has lived through it: you spend hours building a lead list, export it to CSV, upload it to your CRM — and then watch the import wizard throw a wall of red errors. Or worse, the import succeeds silently but half your phone numbers are blank, every date field reads "1/1/1900," and the contact owner column somehow became the company name.

Bad data is not a minor inconvenience. According to research cited by IBM and Gartner, poor data quality costs the US economy an estimated $3.1 trillion annually. More directly relevant to your pipeline: over one-third of CRM users report losing revenue due to bad CRM data. That is not a formatting problem — that is a revenue problem wearing a formatting costume.

The root cause is almost always the same: lead CSV files are built for convenience rather than for CRM compatibility. Someone exports from Apollo.io, LinkedIn, or a scraping tool, tosses the raw file into an import wizard, and hopes for the best. The CRM either rejects the file outright or accepts it and quietly corrupts half the records.

This guide solves that problem completely. You will get the exact field names, data types, encoding rules, and per-CRM import limits you need to build a lead CSV that imports cleanly the first time — every time.

The core principle: a CRM-ready CSV is not just "data in a spreadsheet." It is a structured contract between your lead source and your CRM's data model. Every field name, data type, and character encoding decision either honors that contract or breaks it.

Immediate action: before you touch your next CSV, open it in a plain text editor (Notepad, TextEdit, VS Code) — not Excel — to see what is actually in the file. The raw bytes tell you things Excel hides from you.

---

The Universal CRM-Ready CSV Schema — Required and Optional Columns

No two CRMs use identical field names, but there is a universal schema that maps cleanly to every major platform with minimal transformation. The headers below are the recommended canonical names. Each section below lists the exact header string, data type, and validation rules.

Core Identity Fields

These fields are required. A record missing any of these is not a lead — it is a data fragment.

Critical point on phone numbers: store phone as a string field, never as a numeric column. Excel will strip leading plus signs and zero-pad international numbers if the column is formatted as a number. The E.164 format (+[country code][number], no spaces or dashes) is the only phone format accepted without transformation by HubSpot, Salesforce, Pipedrive, and Zoho. A US number should appear as +12025551234, not (202) 555-1234 or 202-555-1234.

Immediate action: run a find-and-replace on your phone column to remove all parentheses, spaces, and dashes, then prepend the country code with a plus sign. In Google Sheets, the formula ="+1"&SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(A2,"(",""),")",""),"-","") handles US numbers in one pass.

Company and Firmographic Fields

These fields give your CRM the context it needs to route, score, and segment leads correctly.

On industry picklists: every CRM maintains its own accepted values for the industry field. If you import "SaaS" into a CRM that only accepts "Software" or "Technology," the field will either be blank or throw a validation error. Pull the accepted values list from your CRM before building the CSV. In HubSpot, navigate to Settings > Properties > Industry to see the exact accepted strings.

Immediate action: open your target CRM and export a sample contact record. The exported CSV shows you the exact header names and accepted picklist values the CRM uses natively — reverse-engineer your import template from that file.

Lead Source and Scoring Fields

This is where most CSV guides stop short. Modern outbound workflows require lead scoring data, intent signals, and source attribution inside the CRM from day one — not as an afterthought. Without these fields, your CRM cannot segment by lead quality, attribute pipeline to channels, or trigger lead scoring automations.

Why lead_score belongs in your CSV: if you are building lead lists with a tool like GetLeadSnap, the export already includes enrichment signals. Including those signals in the CSV means your CRM's lead routing rules can fire immediately on import rather than waiting for a separate enrichment step. A lead scored 85 should hit a senior SDR's queue on import — not three days later after a manual review.

Immediate action: add a lead_score column to every CSV you export. Even a rough three-tier scoring (100 for ideal customer profile matches, 60 for partial matches, 30 for cold) gives your CRM the signal it needs to trigger the right sequences automatically.

Compliance and Consent Fields

This section is absent from virtually every other CSV import guide. That absence is a compliance liability. GDPR Article 30 requires organizations to maintain records of processing activities, and consent timestamps in your lead data are a core part of that audit trail. CCPA similarly requires that you be able to demonstrate when and how you obtained or processed a consumer's data.

The practical case for consent fields: beyond legal compliance, CRMs like HubSpot use the opt-out/unsubscribe flag as a hard block on email sends. If you import 5,000 leads without a do_not_contact column, and 200 of them are on your suppression list, those 200 will receive your first sequence before the duplication is caught. The reputational and deliverability damage from that error is much larger than the three minutes it takes to add the column.

Immediate action: before every import, cross-reference your CSV against your suppression list and set do_not_contact to TRUE for any match. Export your current unsubscribe list from your email platform as a reference file, then use VLOOKUP or a scripted dedup to flag matches.

---

Data Type Formatting Rules Per Field

The most common cause of silent import failures — where the file uploads but data is wrong — is a mismatch between the data type in your CSV and what the CRM expects. These rules are not suggestions; they are the difference between clean data and garbage data.

Phone Numbers — E.164 Format Explained

E.164 is the ITU-T international telephone numbering standard. Its structure is simple: a plus sign, then the country code (1-3 digits), then the subscriber number, with no spaces, dashes, parentheses, or extensions. Total length: maximum 15 digits excluding the plus sign.

Examples of the same US number in various formats, and which work:

Extensions should go in a separate column named phone_extension with a plain integer value.

Immediate action: use a formula or script to normalize all phone numbers to E.164 before export. In Python, the phonenumbers library handles this in two lines. In Google Sheets: ="+1"®EXREPLACE(A2,"[^0-9]","") strips all non-numeric characters and prepends the US country code.

Dates — ISO 8601 and CRM-Specific Exceptions

ISO 8601 (YYYY-MM-DD) is the only date format that imports correctly across all CRM platforms and all locale settings. The format MM/DD/YYYY fails in any CRM instance configured for a non-US locale — a European HubSpot portal will interpret 06/11/2026 as November 6, not June 11. The format DD/MM/YYYY causes the same confusion in reverse for US instances.

For datetime fields (consent timestamps, activity timestamps), use the full ISO 8601 datetime format: YYYY-MM-DDTHH:MM:SSZ, where Z indicates UTC. Example: 2026-06-11T14:30:00Z.

HubSpot exception: HubSpot's Create Date field is read-only and cannot be overridden via CSV import. Do not include a createdate column expecting to backfill historical dates — HubSpot will ignore it or throw an error. Use a custom date field named original_create_date instead.

Immediate action: if your CSV was built in Excel, use the TEXT() function to reformat date columns: =TEXT(A2,"YYYY-MM-DD"). This converts Excel's internal date serial numbers to ISO 8601 strings before export.

Picklist / Dropdown Fields — Matching Accepted Values

Every CRM maintains an enumerated list of accepted values for picklist fields: industry, lead status, lifecycle stage, contact type, country. If your CSV contains a value not in that list, the field will either be blank on import or trigger a row-level error.

The safest approach is to export a sample record from your CRM first, check the accepted values in the CRM settings, and build a mapping table that translates your source values to CRM-accepted values before import.

Common mismatches that cause silent failures:

Immediate action: build a VLOOKUP mapping table in Google Sheets that translates your raw source values to CRM-accepted values. Keep this as a reusable reference file so you do not repeat the mapping exercise for every import.

Boolean Fields and Multi-Value Fields

Boolean fields (do_not_contact, is_customer, email_verified) should use the plain text values TRUE and FALSE in all caps. Do not use 1/0, yes/no, or Y/N unless the CRM's documentation explicitly states those values are accepted. HubSpot accepts true/false (case-insensitive). Salesforce requires True/False with capital T/F. Pipedrive uses 1/0.

Multi-value fields (tags, lists, categories) present a different challenge. Some CRMs accept semicolon-separated values within a single cell (tag1;tag2;tag3). Others require separate columns for each value. Check your CRM's import documentation for the specific delimiter it expects.

Immediate action: for any boolean field, check your CRM's import documentation for its exact accepted syntax. When in doubt, TRUE/FALSE in all caps is the most broadly compatible option.

---

Encoding, Special Characters, and the UTF-8 BOM Problem

Encoding errors are the most invisible category of CSV problems because they do not throw import errors — they silently corrupt your data. A contact named "Müller" becomes "Müller." A company named "Café Solutions" becomes "Café Solutions." These corruption artifacts spread through your CRM and are nearly impossible to clean after the fact.

The standard: every CRM-ready CSV should be saved as UTF-8 encoded text. UTF-8 covers the full Unicode character set, meaning it handles accented Latin characters (á, é, ü, ñ), Cyrillic, Arabic, Chinese, and every other script without fallback characters.

The BOM problem: Microsoft Excel, when saving a CSV, often prepends a UTF-8 BOM (Byte Order Mark) — three invisible bytes (0xEF 0xBB 0xBF) at the very beginning of the file. These bytes are harmless to some parsers and catastrophic to others. The UTF-8 BOM is one of the leading causes of garbled first-column headers in CRM imports. When the CRM reads the BOM as part of the first header name, your "first_name" column becomes something like "first_name" with invisible characters, and the field mapping silently fails.

How to identify whether your file has a BOM: open the file in VS Code. In the bottom-right status bar, you will see either "UTF-8" (no BOM) or "UTF-8 with BOM." If it says "with BOM," click that indicator and select "Save with Encoding > UTF-8" to remove it.

Windows-1252 (ANSI) encoding is another common culprit. Excel on Windows saves CSV files in Windows-1252 by default when your system locale is set to English (US). This encoding handles the basic Latin alphabet but breaks on any character outside it. A spreadsheet with European names or Spanish company names saved as Windows-1252 will import with corruption artifacts.

The fix: always export from Google Sheets rather than Excel for CSV work. Google Sheets exports as UTF-8 without BOM by default. If you must use Excel, use the "Save As" dialog, select "CSV UTF-8 (Comma delimited)" — note: this is different from the plain "CSV (Comma delimited)" option, which saves as Windows-1252.

Special character handling in field values: commas, double quotes, and newlines within field values must be handled correctly. The RFC 4180 standard specifies that fields containing these characters must be enclosed in double quotes, and any double quote within the field must be escaped by doubling it (""). A company name like Smith, Jones & Associates must appear in the CSV as "Smith, Jones & Associates". Most export tools handle this automatically, but verify it if you are building CSVs programmatically.

Immediate action: open your CSV file in VS Code before every import. Check the encoding indicator in the bottom-right corner. If it shows anything other than "UTF-8" (without BOM), re-save with the correct encoding. This takes 30 seconds and prevents hours of data cleaning.

---

Pre-Import Cleaning Checklist (10-Point)

Run through this checklist before every CRM import, regardless of the source of your lead data. Each item prevents a specific category of import failure.

1. Validate email format. Every email address should match the pattern [email protected]. Remove records with missing @ signs, double dots, or missing TLDs. In Google Sheets: =ISNUMBER(FIND("@",A2)) flags rows without an @ sign as FALSE.

2. Normalize phone numbers to E.164. Strip all non-numeric characters and prepend the correct country code with a plus sign. Verify the resulting string is between 8 and 15 digits after the plus sign.

3. Convert all dates to ISO 8601. Search for any date formatted as MM/DD/YYYY or DD/MM/YYYY and convert to YYYY-MM-DD. Pay special attention to columns that Excel may have auto-formatted as dates.

4. Remove duplicate emails. Email is the primary deduplication key in most CRMs. Importing duplicate emails creates duplicate contacts that must be merged manually — a time-consuming cleanup task. In Google Sheets: Data > Remove Duplicates, selecting the email column.

5. Check for blank required fields. Every record must have at minimum an email address, or a first_name + last_name + phone combination depending on your CRM's required fields. Records missing required fields will fail silently or throw row-level errors.

6. Verify encoding — remove BOM if present. As described in the previous section: open in VS Code, check the encoding indicator, save as UTF-8 without BOM if needed.

7. Validate picklist field values. Cross-reference every picklist column (industry, lead_source, lead status) against your CRM's accepted values list. Flag any values not in the accepted list and remap them.

8. Confirm assigned_to values match active CRM users. If your CSV includes an assigned_to column, every value must be an email address that corresponds to an active user in your CRM. Deactivated users cause row-level assignment errors.

9. Cross-reference against suppression list. Pull your current unsubscribe/opt-out list and set do_not_contact to TRUE for any email address that appears on it. This prevents emailing suppressed contacts from the moment of import.

10. Audit row count before and after. Note the exact row count of your CSV before upload. After import completes, compare the CRM's imported record count against your pre-import count. Any discrepancy indicates silent failures that need investigation.

Immediate action: copy this checklist into a shared document and run through it as a team protocol before every import. The ten steps take less than 20 minutes for a list of 5,000 records and prevent problems that can take days to fix after the fact.

---

CRM-by-CRM Import Limits and Field Mapping

Each CRM has its own field naming conventions, import limits, and quirks. This section covers the five most widely used platforms.

HubSpot

Row limit: no documented hard cap on CSV imports, but HubSpot recommends a maximum of 100,000 rows per file. Files above this threshold frequently time out.

Key field mappings:

HubSpot quirks: the Create Date property (createdate) is read-only and will be ignored or rejected on import. HubSpot's property names are case-sensitive in some import contexts — use all lowercase. The industry field must match HubSpot's exact accepted values, which can be retrieved from Settings > Properties > Contact properties > industry.

Immediate action: download HubSpot's import template from your portal (Contacts > Import > Start an import > File from computer) — HubSpot generates a template with its exact property names pre-populated.

Salesforce

Row limit: Salesforce's Data Import Wizard supports up to 50,000 records per import. For larger files, use the Data Loader tool, which handles millions of records.

Key field mappings:

Salesforce quirks: Salesforce distinguishes between Leads (prospective contacts not yet in an account) and Contacts (people associated with an Account). Import to the Lead object first; convert to Contact after qualification. The LeadSource picklist values are configurable per org — pull your org's specific values before building the CSV.

Immediate action: in Salesforce Setup, navigate to Object Manager > Lead > Fields & Relationships > LeadSource to see your org's exact accepted values.

Pipedrive

Row limit: Pipedrive caps standard CSV imports at 50,000 rows per file. For larger imports, you must split the file or use Pipedrive's API.

Key field mappings:

Pipedrive quirks: Pipedrive uses "Persons" and "Organizations" as separate objects, not a unified Contact object. When importing, you map person fields and organization fields separately, and Pipedrive creates or links the Organization record automatically based on company_name. Boolean fields use 1/0 rather than TRUE/FALSE.

Immediate action: for imports over 50,000 rows, split your CSV using a free tool like CSVSplitter or write a simple Python script using the csv module to split by row count before uploading.

Zoho CRM

Row limit: Zoho CRM allows up to 30,000 records per import for the standard plan. Higher limits are available on Enterprise plans.

Key field mappings:

Zoho quirks: Zoho's duplicate check can be configured to match on email, phone, or both. Set this before import in the import wizard's deduplication settings. Zoho also supports a "Skip" or "Overwrite" conflict resolution mode — choose carefully based on whether you want new data to override existing records.

Immediate action: before a large Zoho import, run a test import with 50 records to validate field mappings and deduplication behavior before committing the full file.

Monday.com and Notion CRM

Neither Monday.com nor Notion CRM are purpose-built CRMs, but both are widely used as lightweight CRM replacements for small and mid-market teams.

Monday.com: supports CSV import into any board. Column headers in your CSV must match the exact column names in the Monday board — case-sensitive. There is no field mapping wizard; the match is purely by header name. Create your board columns first, then build your CSV to match those names exactly. Monday.com has no native deduplication on CSV import — duplicate rows create duplicate items.

Notion CRM: Notion's CSV import (available via the "Merge with CSV" option on a database page) maps columns by header name. Notion does not enforce data types — every column imports as rich text. This means E.164 phone numbers, ISO 8601 dates, and boolean values all import as plain text, which is acceptable for display but breaks any formula or filter that expects a typed value. For Notion, add a post-import step to convert date and phone columns to their native types manually.

Immediate action: for Monday.com, export a blank CSV from your board to use as the import template — this ensures perfect header alignment.

---

12 Most Common CSV Import Errors and How to Fix Them

These are the errors that appear most frequently across CRM support forums and import logs, with the exact fix for each.

Error 1: "Invalid email address format"

Cause: email contains spaces, double dots, or missing TLD. Fix: use a regex validator to flag malformed emails before import. Pattern: ^[^@]+@[^@]+\.[^@]+$ catches the most common cases.

Error 2: "Required field missing"

Cause: a required field (usually last_name or company in Salesforce) is blank for some rows. Fix: filter your CSV for blanks in required columns and either fill them with a placeholder ("Unknown") or remove the row.

Error 3: "Invalid picklist value"

Cause: an industry, lead_source, or status value does not match the CRM's accepted list. Fix: build a mapping table as described in the picklist section above. Rerun the substitution before every import.

Error 4: "Garbled first column header"

Cause: UTF-8 BOM in the CSV file. Fix: remove the BOM by re-saving as UTF-8 (without BOM) in VS Code or a similar editor.

Error 5: "Date format not recognized"

Cause: date formatted as MM/DD/YYYY or with slashes instead of hyphens. Fix: convert all dates to ISO 8601 (YYYY-MM-DD) using TEXT() in Google Sheets or strftime in Python.

Error 6: "Phone number invalid"

Cause: phone stored as a number, stripping leading plus sign or zero. Fix: ensure the phone column is formatted as text before export. In Excel: format the column as Text before entering values, or prepend a single quote to force text format.

Error 7: "Duplicate record — skipped"

Cause: a record with the same dedup key (usually email) already exists in the CRM. This is not always an error — it may be the correct behavior. Fix: decide before import whether you want to skip, overwrite, or merge duplicates, and configure the import wizard accordingly.

Error 8: "Assigned user not found"

Cause: the assigned_to email does not match an active CRM user. Fix: pull the active user list from your CRM and validate the assigned_to column against it before import.

Error 9: "Row count mismatch after import"

Cause: some rows failed silently. Fix: download the import error report immediately after every import — all major CRMs generate one. This report lists every row that failed and the specific reason.

Error 10: "Special characters corrupted"

Cause: file saved as Windows-1252 instead of UTF-8. Fix: re-export from Google Sheets as UTF-8, or convert using a tool like iconv on the command line: iconv -f WINDOWS-1252 -t UTF-8 input.csv > output.csv

Error 11: "Field exceeds maximum length"

Cause: a text field value is longer than the CRM's field length limit (e.g., Salesforce's standard fields cap at 255 characters). Fix: add a LEN() formula column to flag values over the limit and truncate them before import.

Error 12: "Boolean field rejected"

Cause: boolean field contains "yes"/"no" instead of the CRM's expected format. Fix: normalize boolean fields to the CRM's exact expected values (TRUE/FALSE for HubSpot, True/False for Salesforce, 1/0 for Pipedrive) using a SUBSTITUTE or IF formula.

Immediate action: after every import, immediately download the error report from the import wizard. Do not close the import confirmation screen until you have saved or noted the error report URL — some CRMs only retain import logs for 30 days.

---

Handling Partial Import Failures and Row-Level Errors

This is the scenario that no other guide addresses: you import 1,000 rows, and 800 succeed while 200 fail. What do you do with the 200 failed rows?

Step 1: Download the error report. Every major CRM generates a row-level error report after import. This report maps each failed row to a specific error reason. Download it immediately — do not navigate away from the import confirmation screen before doing so.

Step 2: Separate the failed rows. Use the row numbers in the error report to filter your original CSV and extract only the failed rows into a new file. In Google Sheets: add an index column to your original CSV, then use VLOOKUP or filter to pull only the rows whose index appears in the error report.

Step 3: Fix errors by category. Group the errors from the report by error type. All "invalid email" errors get fixed the same way; all "missing required field" errors get fixed the same way. Batch-fixing by error category is faster than fixing row by row.

Step 4: Re-run pre-import checklist on the corrected file. Before reimporting the fixed rows, run the full 10-point checklist. A row that failed for one reason may have a second problem that was masked by the first error.

Step 5: Reimport only the corrected rows. Do not reimport the full original file. Reimporting the full file risks creating duplicates for the 800 rows that already imported successfully. Import only the corrected subset.

Handling rollback scenarios: most CRMs do not support transactional rollback on CSV imports. If an import corrupts existing records (for example, an overwrite import that incorrectly updates 500 existing contacts), your options are: (1) use the CRM's recycle bin or audit log to restore overwritten values, (2) reimport the original data from a backup export, or (3) manually correct records using the error report as a guide.

The prevention approach: for imports that modify existing records (update/overwrite mode), always export a backup of the affected records from your CRM before running the import. Store the backup with a timestamp. If something goes wrong, you have a clean restore point.

Immediate action: build a simple import ticket template that records: date of import, source file name, row count, CRM destination, import mode (create/update/skip), error report filename, and final imported count. Keeping this log means you can audit any import in your history without relying on CRM-side logs that may expire.

---

Chunking Large Imports Beyond Platform Row Caps

When your lead file exceeds the CRM's row cap — 50,000 for Pipedrive, 30,000 for Zoho, or even HubSpot's practical 100,000 limit — you need a chunking strategy.

The chunking formula: divide your total row count by the platform limit, rounding up, to get the number of chunks. Add a buffer: use 80% of the stated limit per chunk to account for rows that may be near the limit edge. For a 200,000-row file going into Pipedrive: ceil(200,000 / 40,000) = 5 chunks.

How to chunk a CSV:

Option 1 — Google Sheets: if your file is under 500,000 rows, split it manually by copying row ranges to new sheets and exporting each as a separate CSV.

Option 2 — Python csv module: write a 10-line script that reads the original CSV and writes a new file every N rows, preserving the header row at the top of each chunk file.

Option 3 — Command-line tools: on Linux/Mac, the split command handles this natively. On Windows, PowerShell can do it: Get-Content input.csv | Select-Object -First 50001 | Out-File chunk1.csv -Encoding UTF8

Chunking sequence matters: when chunking an import that will update existing records, process chunks in sequence — not in parallel. Parallel imports of overlapping datasets can create race conditions where the same record is written by two import jobs simultaneously, resulting in corrupted data.

Between chunks, verify: after each chunk import, download the error report, confirm the row count in the CRM increased by the expected amount, and investigate any discrepancy before starting the next chunk. A systematic error in your CSV (like a malformed column that affects every row) will show up in chunk 1 — catching it there saves you from reimporting 4 more chunks.

Immediate action: if you regularly work with large lead files, write and save a reusable Python chunking script. Keep it in a shared team folder. The one-time investment of writing it saves hours on every large import going forward.

---

Downloadable CRM-Ready CSV Template

A template is worth more than a thousand words of documentation. The headers below represent the complete universal schema described in this guide. Copy this into a Google Sheet or Excel file, save it as UTF-8 CSV (without BOM), and use it as the base for every lead list you build.

Core Identity Block:

first_name, last_name, email, phone, phone_extension

Company and Firmographic Block:

company_name, job_title, industry, company_size, website, linkedin_url, city, state, country, postal_code

Lead Source and Scoring Block:

lead_source, lead_score, intent_signal, campaign_id, list_name, source_url, date_scraped, assigned_to

Compliance and Consent Block:

consent_status, consent_timestamp, consent_source, do_not_contact, gdpr_lawful_basis, data_source_region

Notes Block:

notes

This 26-column schema covers every field discussed in this guide. For a specific CRM import, you will typically use a subset of these columns — keep the ones your CRM supports, remove the ones it does not, and rename headers to match your CRM's exact property names.

Using the template with GetLeadSnap: when you export leads from GetLeadSnap, the CSV export uses standardized field names that align closely with this schema. The export includes company_name, email, phone, city, state, country, industry, and website by default — which means your import prep is reduced to adding the scoring and compliance columns and normalizing phone numbers to E.164.

Immediate action: create your own master template file from the column list above. Store it in a shared drive with the label "CRM-READY-TEMPLATE-[DATE]" and update it whenever you discover a new CRM-specific quirk. This becomes your team's canonical import standard.

---

FAQ

Q: Can I include custom fields in my CSV import?

Yes, but custom fields must be pre-created in your CRM before import. You cannot create new CRM fields via CSV import — you can only populate fields that already exist. Create your custom fields in the CRM's settings first, note the exact API name or display name, and use that as the column header in your CSV.

Q: Should I import to Leads or Contacts in Salesforce?

Import to the Lead object for net-new prospects who have not been qualified or associated with an account. Import to Contacts (linked to an existing Account) for people already in a qualified sales cycle. Mixing these creates data governance problems downstream.

Q: Why does my phone number show as scientific notation after opening in Excel?

Excel auto-formats long numeric strings as scientific notation (e.g., 1.22E+10). This is a display problem caused by the column being formatted as a number. To prevent it: before opening the CSV in Excel, use the Text Import Wizard (Data > From Text/CSV) and manually set the phone column to Text format. Better yet, do not open your import CSVs in Excel at all — use Google Sheets for editing.

Q: What is the safest deduplication strategy for large imports?

For large imports into an active CRM, use the "Skip duplicates" mode on first pass. This preserves existing data while adding net-new records. After reviewing the error report, decide which skipped records you actually want to update and create a smaller "update only" import file for those specific records, switching to "Update existing" mode. This two-pass approach gives you control without risking mass overwrites.

Q: How do I handle leads from multiple countries with different phone formats?

Normalize to E.164 before any country-specific processing. The country code is embedded in the E.164 format, so you can always parse it back out if needed. A UK mobile number in E.164 (+447700900123) is unambiguous; "07700 900123" is ambiguous without a country field.

Q: Can I import lead scores that will override my CRM's existing scoring model?

That depends on your CRM and your scoring setup. In HubSpot, if you are using HubSpot's native lead scoring, importing a lead_score value to a custom field will not affect the native score — they are separate properties. If you want imported scores to be used by your CRM's routing rules, map them to the specific score field your routing rules reference.

Q: How long should I keep import error logs?

Keep them for at least 12 months. Under GDPR Article 30, you need to be able to demonstrate your data processing activities. Import logs — including error logs — are part of that audit trail. Store them in a shared team folder with clear naming conventions (import_errors_YYYYMMDD_campaignname.csv).

Q: Is LinkedIn CSV export data CRM-ready out of the box?

No. LinkedIn's exported contact CSV uses its own field names (First Name, Last Name, Email Address, Company, Position), which require remapping. More importantly, LinkedIn CSV exports expire 72 hours after the export is triggered and must be downloaded within that window. Phone numbers and company websites are typically absent from LinkedIn exports, requiring enrichment before the data is CRM-ready.

---

Build CRM-Ready Lists From the Start

The most effective way to reduce import prep time is to use a lead source that exports in a CRM-compatible format rather than a raw data dump. If you are still spending hours reformatting every CSV you receive, that is a workflow problem as much as a technical one.

Tools like GetLeadSnap are built with CRM export in mind — standardized field names, phone numbers in a consistent format, and company data structured to map directly to HubSpot, Salesforce, and Pipedrive fields. That does not eliminate the need for the checklist above, but it compresses the prep work from hours to minutes.

Whichever lead source you use, the standard should be consistent: UTF-8 encoding without BOM, E.164 phone numbers, ISO 8601 dates, blank fields rather than placeholder strings, and a suppression check before every import. These are not advanced practices — they are the baseline for professional lead data operations.

The sales teams that win the data quality game are not the ones with the most sophisticated enrichment tools. They are the ones with the most disciplined import protocols. Build that discipline now, document it in a shared team protocol, and you will spend more time selling and less time debugging import errors.

Start building CRM-ready lead lists at GetLeadSnap.pro.