Spreadsheet to CRM: when to move beyond Excel

It is worth being precise, because “get a CRM” is often sold as a cure for problems it does not touch. Four differences are real and structural.

History attaches to the person, not the file

In a spreadsheet, the call you had in March lives in a cell, a mailbox or someone's memory. In a CRM, it is on the contact's record, and anyone who opens that contact sees it without asking.

The next step is a thing, not an intention

A spreadsheet can hold a date in a column. It cannot tell you that the date has passed. Follow-ups only work when something is watching them for you.

The pipeline is a view, not a rebuild

Total open value by stage should be a page you open, not an hour of work you do on a Friday.

Ownership is explicit

Every record has one person responsible for it. Most spreadsheet failures are actually ownership failures wearing a spreadsheet costume.

This is the step people skip, and it is the one that decides whether the move works. A CRM does not fix messy data; it makes it permanent and gives more people access to it.

Work through the export in this order, in the spreadsheet, before importing anything:

1. Split names into first and last if they live in one column. Doing it later, record by record, is miserable.
2. Fix email addresses. A row without a valid email or phone is usually not a contact, it is a note.
3. Separate the company from the person. “Jane Chen, Acme Pty Ltd” in one cell becomes two records later.
4. Decide the one true row for each duplicate. Merge the useful detail into it and delete the rest now.
5. Normalise anything you intend to filter on — state, source, status. “NSW”, “N.S.W.” and “New South Wales” are three values to a computer.
6. Delete the dead. Contacts from a business that closed in 2019 are not history, they are noise.

The instinct is to migrate everything because it exists. Resist it. Every row you import is a row someone has to read, trust and maintain.

• Contacts you have never spoken to and cannot place. A purchased list is not a customer base.
• Formatting logic — colour coding, highlighted rows, strikethrough. That is meaning stored in appearance, and it does not survive an export. Turn it into a real field or let it go.
• Formula columns. Import the value, not the formula.
• Personal working columns nobody else understands.
• Anything you are keeping only because deleting it feels wasteful.

A smaller, trusted dataset gets used. A complete but doubtful one gets quietly abandoned, and the spreadsheet comes back.

Most spreadsheets are one flat sheet. A CRM separates that into records that relate to each other, and getting the shape right at the start saves a great deal of untangling.

Contacts are people

One row per human. Their email, their phone, their role.

Organisations are companies

The business they work for, held once. When three people at the same company are all in your pipeline, the company is the thing they have in common — not a repeated text value in three rows.

Deals are opportunities, and they are not people

This is the distinction spreadsheets cannot express and the one that matters most. A deal has a value, a stage, an owner and an expected close date. One company can have several. A contact who is not buying anything right now still belongs in your contacts — they just do not have an open deal.

• Importing everything on day one, then discovering the field mapping was wrong on ten thousand rows.
• Running both systems “for a while”. Two sources of truth means neither is trusted, and the spreadsheet usually wins because it is familiar.
• Recreating every spreadsheet column as a custom field, which rebuilds the old mess with more steps.
• Migrating in the busiest week of the quarter.
• Nobody owning it. If no single person is accountable for the move, it stalls somewhere near the end and stays there.

The reliable pattern is small and fast: import a sample of twenty rows, open them, check the mapping landed where you expected, fix it, then run the rest.

Migrations rarely fail at the import. They fail three weeks later, when one person is still updating the sheet, the CRM is half-current, and everyone quietly reverts to the thing that is up to date.

A few decisions in the first two weeks settle it.

Set a date and make the spreadsheet read-only

Not deleted — read-only, and clearly named as an archive. People need to know the old copy exists and that it is no longer the answer. Leaving it editable “just in case” guarantees it keeps being edited.

Make almost nothing mandatory

Pick the two or three fields you will genuinely report on and require those. Every extra required field is a reason to skip creating the record at all, and a skipped record is worse than a sparse one.

Update it during the work, not at the end of the week

Batch data entry on a Friday afternoon is the habit that kills CRMs, because it is the first thing dropped in a busy week. Logging the call while you are still on it takes a fraction of the time and is far more accurate.

Give the system a weekly job

Run one short pipeline review off the CRM — not off a rebuilt summary. If the CRM is the only place the review can happen, it stays current. If a spreadsheet is still produced for the meeting, the CRM has no purpose yet.

For completeness, since this is our guide: bizzMate imports contacts, organisations and deals from CSV, which is what every spreadsheet exports. You map your columns to fields during the import rather than reformatting the file to match us, and organisation rows that already exist are skipped rather than duplicated.

Contacts and deals import without a duplicate check, which is the honest reason the de-duplication step above is worth doing in the spreadsheet first. Leads are created in the app rather than imported — the duplicate warning there is on the create form.

Everything above applies whichever CRM you choose. The clean-up is the work; the import is the easy part.