How to Prepare a Prospect Spreadsheet for CRM Import

Before uploading a prospect file, decide what each row should create or update. The field map and test cases below help catch duplicate companies, incorrect branch matches, and broken contact associations before a full import.

Map spreadsheet fields to the CRM’s record types, confirm identifiers and update rules, clean the data, and test representative rows. Inspect the resulting records and associations before importing the full batch.

The test matrix specifies what should happen to new companies, existing records, shared-domain branches, and contact restrictions.

Decide which records you are creating or updating

Identify whether the file contains companies, locations, contacts, activities, or a mixture. Then determine how the CRM represents those objects and their relationships.

A spreadsheet with one row per branch may not map cleanly into a CRM where the company domain is the primary matching field. Several branches can share one domain while requiring distinct location records or another approved account structure.

Also distinguish creating new records from updating existing ones. The same file can behave differently depending on the import mode and the identifiers you include.

Read the destination requirements before changing the file

Use the current documentation for the CRM and the specific object you plan to import. Confirm supported file types, required fields, unique identifiers, field formats, and relationship rules.

For example, HubSpot's import documentation describes object-specific requirements and identifiers used to update records or avoid duplicates. A company domain and a full website page URL are not automatically interchangeable fields.

Do not transfer a rule from one CRM to another without checking it. Even within one product, creating companies, updating contacts, and associating records can require different information.

Preserve the original and create an import copy

Keep the reviewed source workbook unchanged. Create a separate import-preparation file so you can trace every transformed value back to the original record.

Retain your source IDs and the destination's record IDs when updating existing records. Make clear which is which; an internal spreadsheet ID is not automatically recognized as a CRM ID.

Record the intended import mode, source batch, date, and owner. This context becomes useful if you need to investigate an unexpected update later.

Build a field map

For each source column, specify the destination field, data type, transformation, and treatment of blanks. Remove or ignore fields that have no approved destination rather than guessing during upload.

A general company mailbox should not automatically create a fictional person. Decide how the destination should represent a role-based route before mapping it into a contact object.

Clean values for the destination

Review accidental spaces, inconsistent status labels, duplicate candidates, and incorrectly formatted dates. Preserve leading zeros and international phone notation where needed.

Keep missing values blank unless the destination explicitly requires another representation. Text such as Unknown in an email column can be interpreted as invalid data rather than a helpful note.

Use the destination's allowed values for select fields and ownership fields. Do not assume that an owner name in the spreadsheet matches an active user exactly. Confirm the mapping before applying it to many records.

The data cleanup checklist covers preparation, while duplicate review helps distinguish legitimate branches from repeated companies.

Confirm matching and overwrite behavior

Find out how the importer matches an incoming row to an existing record. Verify what happens when the identifier is missing, duplicated, or associated with conflicting values.

Check how blank cells and populated cells affect existing data. Do not assume blanks are ignored or that a newer file automatically preserves manual CRM edits. The actual behavior depends on the destination and import settings.

For multi-location companies, test the shared-domain case deliberately. If the CRM combines branches that should remain separate, change the model or identifier strategy before importing the full list.

Test a small representative batch

Use a permitted test environment or an approved small import that can be reviewed safely. Include the cases the full file actually contains: a new company, an existing company update, a branch sharing a domain, a contact association, and a blank optional value where relevant.

Define the expected outcome for each row before importing. Afterward, inspect the actual records, relationships, owners, restrictions, and important field values.

A successful upload message is not enough. Confirm that the intended record was created or updated and that no unrelated record was changed through an unexpected match.

Specify the expected result for each test row

Write down the outcome before uploading so the test can reveal an incorrect match:

HubSpot's current import guidance says blank import cells do not clear existing property values. Treat that as a HubSpot-specific rule, not a universal CRM behavior.

Keep the expected and actual results together. If a shared-domain test merges branches unexpectedly, correct the record model before importing more rows. A successful upload with the wrong associations is a failed test.

Reconcile results and investigate exceptions

Compare the number of source rows with records created, updated, rejected, or otherwise handled. Those totals may not match one-to-one when the import includes several objects or associations, so use the destination's object counts and your expected outcomes.

Review every rejected row and any unexpected merge. Keep an exception log with source ID, reason, and correction. Do not repeatedly upload the whole file while hoping the errors disappear.

If the test behaves correctly, preserve the tested mapping and settings for the full import. If you change the schema or matching rules, repeat the affected test cases before proceeding.

Import the full batch with a clear owner

Use the reviewed file and agreed settings. Keep the source snapshot, mapping, import identifier or report, and exception log together.

After the import, inspect representative records and the cases most likely to fail. Confirm that owners can see their work, relationships are correct, and contact restrictions remain in force.

Decide where future changes will be maintained. Once the CRM is the authoritative system, an old spreadsheet should not continue to generate conflicting status updates.

Keep collection and integration separate

Prospect can provide an Excel export of reviewed company records. Preparing that export for a CRM is a separate mapping and validation task, not an automatic live integration.

Start with a small sample and document the successful transformation. The next batch will be easier to prepare when the field meanings, matching rules, and exception process are already clear.

Related Questions

Can I import Prospect’s Excel file directly into any CRM?

Do not assume universal compatibility. Check the destination file requirements, object model, identifiers, and field mapping. Prepare and test a small import first, particularly when the file contains branches sharing a website.

Should I fill missing emails with placeholder values?

No. Preserve missing data honestly and follow the destination’s required-field rules. Placeholder addresses can create invalid contacts or misleading records. Keep the business in research if a required contact field is genuinely unavailable.

If the destination choice is still open, read the system comparison. For source-data organization, see managing the prospect list in Excel.