Moving a Spreadsheet to a CRM? Decide What One Row Means

A spreadsheet can look ready for a CRM import while still mixing several kinds of record. One row might describe a person, another a new enquiry from the same person, and a third an order. Importing all three as contacts creates a different system from the one your staff intended.

Before choosing an import tool, agree what one row represents and what the destination should contain. The example below is synthetic planning data. It is not a report of a customer migration or a claim that a particular CRM accepts these fields.

Separate the person from the enquiry

A contact identifies a person or an agreed business contact. An enquiry records a particular request, its stage, assigned staff member and next action. The same person can have several enquiries. If a new request replaces the old request in one contact note, the team may lose the distinction between work already completed and work still open.

A company record may also matter when several contacts work for the same customer business. Decide whether company, contact and enquiry are separate objects in the chosen tool. Check its actual import and relationship capabilities before making a field map.

Work through four synthetic source rows

• R-001: Sample Contact A asks for a website proposal. Create or match the agreed contact, then preserve the website enquiry.
• R-002: Contact A later asks for maintenance. The matching contact may be the same, but this is a separate request with its own owner and next action.
• R-003: Sample Contact B shares the office phone used by A. A matching phone number alone is not enough to combine these people. Review the approved matching information.
• R-004: Sample Contact C has no phone or email in the source. Keep the source reference and send the row through the agreed review rule. Do not silently invent a contact detail or assume every destination permits the missing field.

Four source rows do not necessarily mean four contacts. Nor should an importer silently reduce the four requests to one. Record the intended contact and enquiry outcomes before testing. Where the business meaning is uncertain, a staff decision belongs in the exception list.

Compare these choices in the interactive four-row matching example. It uses fixed synthetic rows to show duplicate contact creation, an incorrect shared-phone merge and a reviewed plan; it does not import data into a CRM.

Write a field map with meaning, not just column names

For each column, record its meaning, destination, format and rule for missing or invalid values. A field labelled status could mean enquiry progress, order fulfilment or payment reconciliation. Those meanings should not be treated as interchangeable.

Dates need an agreed format. Keep identifiers and phone values in a representation that preserves meaningful leading zeros. Name the source that wins when two values disagree. Also identify notes, attached documents and historical activity that the destination cannot accept through the proposed method.

Keep a source reference beside each decision. A rejected row described only as “bad data” gives staff little chance to correct it. A reference, field, reason and assigned reviewer make the next action clearer.

Agree what happens on a second import

Ask the provider to demonstrate a repeat import in a test workspace. Should it update a known record, reject an already processed reference or create a new enquiry? The answer depends on the chosen data model and import method.

Test the intended matching field, a changed email, a shared phone, a blank identifier and a conflicting existing value. A file that imports once without an error message does not establish that a second run will avoid duplicates or preserve the correct relationships.

Reconcile source processing and destination objects separately

Start with source rows: which were processed, which were rejected and which still require review? Explain every row that did not complete its intended action. Then count destination objects using the agreed model. Contact merges, separate enquiries and linked companies can make destination counts differ from source-row counts.

Open representative records and check their relationships, dates, statuses, notes and ownership. A count that happens to match does not prove the contents are right. Keep the evidence and unresolved exceptions with the trial report, and name the person who decides whether the result is acceptable.

Plan the switch while staff still have work to do

Decide which system staff should edit during the move and how later changes will be brought across. Agree an editing pause or another controlled transition, the backup owner and the point at which staff start using the new system.

A recovery plan should explain who can authorise rollback and how changes made after the switch would be reconciled. Keeping an old export is only one part of that plan. Staff also need account access, an operating process and a contact for unresolved issues.

Take a short brief to the proposal discussion

Prepare the column list, record types, approximate volumes, required relationships and a few synthetic rows. Keep real customer exports and credentials out of a public enquiry form. Agree an appropriate transfer method when the actual project needs them.

The editable migration worksheet records field mapping, match rules, trial reconciliation and the switch. Read the data migration service scope for proposal questions, or the CRM workflow guide if the follow-up process itself is still undecided. A customer portal also needs clear customer ownership of any imported private records.