CRM vs spreadsheet for sales — when to switch (and why free CRM changed the math)

A spreadsheet does not break at a row count. It breaks the first time two people edit it at once, the first time the same person appears twice under different spellings, and the first time somebody asks what was actually sent to an account. Those three moments usually arrive well before 2,000 rows and long before any documented limit. The switch is not about volume, it is about concurrency, identity and evidence — and now that a genuinely free CRM tier exists, cost is no longer the reason to postpone it.

The documented limits are not what stops you

Start by removing the wrong reason, because it is the one everybody cites.

Microsoft's own specifications put an Excel worksheet at 1,048,576 rows by 16,384 columns, with a single cell holding up to 32,767 characters. Google's Drive help documentation states the ceiling for Sheets as "up to 10 million cells or 18,278 columns (column ZZZ) for spreadsheets that are created in or converted to Google Sheets", and applies the same limit to spreadsheets imported from Excel or CSV.

A sales team with 20,000 contacts and forty columns is using 800,000 cells. That is 8% of the Google Sheets ceiling and under 2% of Excel's row limit. You will never hit either. Performance degrades long before the limit — a sheet with heavy formulas gets sluggish in the low hundreds of thousands of cells — but sluggish is an annoyance, not a failure.

The real failures are structural, they arrive early, and none of them announces itself. That is the important property: a spreadsheet does not error when it loses your data. It just quietly holds a different value than the one you typed.

Failure mode one: two people, one truth

A spreadsheet's concurrency model is last write wins, and in a shared cloud sheet it does not even tell you a write happened.

The symptom is specific. A rep updates a lead's status to "meeting booked" at 14:02. A colleague, working from a copy they opened at 13:40, edits a different column on the same row and saves at 14:05. In Excel with a file copy, the second save overwrites the first entirely. In Google Sheets, cell-level merging saves you most of the time and fails in exactly the cases that matter — a filtered view, a sort applied while somebody else is typing, a paste of a block over a range that moved.

The version that costs money is the sort. One person sorts by company while another is midway through pasting a block of updated phone numbers. The paste lands on the rows that are now in those positions. Every number is now attached to the wrong person, no error appears, and the corruption is discovered weeks later by a rep calling the wrong company.

A database solves this by making the row the unit of update and giving it a stable identifier that is not its position. That is not a feature you can add to a sheet; it is the difference between a sheet and a database.

How to tell you are already here: you maintain a "master" copy and ask people to send you their changes, or you have ever restored a version from history to recover something. Both are workarounds for a concurrency model that has already failed.

Failure mode two: no identity, so no deduplication

A spreadsheet row has no identity beyond the text in it. That means the same person entered three ways is three people, and nothing in the tool disagrees.

The three ways are always the same three. The same address in different cases and with trailing whitespace. The same person under a work address and a personal one. And the same person from two sources — one from a conference list, one from an enrichment export, one typed by a rep from a business card.

A CRM handles this with a normalised key. Autocloz dedupes imports on the workspace plus the lower-cased email address, so [email protected] and [email protected] are one record. Its duplicate detection then groups existing records by three normalised keys — email, phone and LinkedIn URL — and reports which key matched so the interface can say why two rows are flagged together. Merging re-points every child row from the sources to the keeper: notes, tasks, attachments, list memberships, deals, activities, threads, sends and audit rows, all inside a single transaction, so a failure leaves the data exactly as it was rather than half-merged.

Try to build that in a sheet and you discover why it is not a formula. Normalising an email is a LOWER(TRIM()) and is easy. Deciding that a record with a phone number and no email is the same person as a record with an email and no phone is a join across three keys, and then merging their history means merging rows that have different notes in the same column, which a spreadsheet cannot do at all — it can only keep one.

How to tell you are already here: you have ever emailed the same person twice from two rows, or you keep a separate "do not contact" tab that you remember to check. Both are identity problems wearing different clothes. Cleaning a list properly is the procedure; the structural fix is a system with a key.

Failure mode three: no event log, so nothing to prove

This is the failure that has consequences beyond inconvenience.

A spreadsheet stores state, not events. It can hold a "last contacted" date, which somebody has to remember to type. It cannot hold the twelve messages that were actually sent, who sent them, from which mailbox, whether they were delivered, and what came back. So the question "what did we say to this account" has no answer that does not depend on somebody's memory and their sent folder.

That matters commercially — a rep taking over an account inherits a date rather than a relationship — and it matters legally. The EU General Data Protection Regulation requires controllers and processors to maintain records of processing activities under Article 30, and India's Digital Personal Data Protection Act, 2023, operationalised by the Digital Personal Data Protection Rules notified by the Ministry of Electronics and Information Technology on 13 November 2025, builds its consent framework on record-keeping obligations of its own. A spreadsheet column that says "consented: yes" is an assertion. A timestamped, append-only record of when consent was captured, through which form, and what the person was shown is evidence.

The difference surfaces the day somebody asks. A CRM writes an audit row naming the actor for every state-changing action, and a well-built one keeps an explicit deny-list of sensitive keys — session cookies, bearer and refresh tokens, SMTP and IMAP passwords, API keys — so the forensic record never becomes a credential store. That is a design decision a spreadsheet has no place to express.

How to tell you are already here: somebody has asked "did we already reach out to them?" and the honest answer was "let me check my sent folder". Or a customer has asked to be removed and you cannot demonstrate when they were added.

Autocloz's free plan covers 5 users and 10 mailboxes with 100,000 stored contacts, the activity log and the shared suppression list included — start free and import one list to see what the history looks like before you move the rest.

Failure mode four: nothing enforces a rule

A spreadsheet cannot refuse. It has data validation, which stops a typo in a dropdown, and that is the extent of its authority.

So every rule you have is a convention. Do not email anyone on the suppression tab. Do not contact the same account twice in a week. Do not call outside business hours in the recipient's country. Do not export the list. Each of those is enforced by people remembering, and people under quota pressure at 5pm on the last day of the month remember unevenly.

A CRM turns conventions into gates. A suppression entry blocks a send rather than being a tab somebody should have checked. A permission decides whether a person can export the database at all — in Autocloz that is a distinct toggle from the create permission that governs import, which is the specific control that lets a contractor add contacts without being able to take the book with them. A quiet-hours window refuses a dispatch rather than reminding somebody.

The distinction is between a rule you can follow and a rule you cannot break. Only the second survives a busy quarter, and the lead management process end to end is mostly a list of places where the difference matters.

The switch test, as a decision rule with thresholds

Switch when any two of these are true. One alone is survivable; two compound.

• More than one person edits the data. The concurrency failure above starts here, at exactly two.
• You outreach on more than one channel. A sheet can hold "emailed" or "called". It cannot hold a per-channel touch history with outcomes, so multichannel sequencing in a sheet is a fiction maintained by hand.
• You have missed a follow-up you intended to send. This is the cheapest signal available and the most reliable. A missed follow-up means the reminder lived in somebody's head.
• You have contacted the same person twice by accident. An identity failure has already happened; the next one is a matter of time.
• You need to answer a question about the past. Pipeline movement, source attribution, what happened to last quarter's list. A sheet holds the present state and overwrites the past.
• Somebody who is not the sheet's author needs to use it. The knowledge required to use a sheet correctly is usually in the head of the person who built it.
• You are past roughly 500 active leads with follow-ups pending. Not a technical limit. It is the point at which the manual bookkeeping exceeds what a person will actually keep up.

The counterweight, honestly stated: below all of that, a spreadsheet is genuinely better. A solo founder with 60 leads, one channel and a habit of checking a list daily is faster in a sheet than in any CRM, and switching early buys structure they do not need at the price of friction they will feel. The historical reason people delayed past that point was cost — a per-seat CRM at $30 a user meant a three-person team paid $1,080 a year to organise 400 contacts. A free tier capped on capacity rather than on days removes that argument, which is what changed. It does not make the sheet wrong for the solo case. What a CRM actually is is worth reading first if the answer to "should I switch" is still not obvious.

Moving the sheet across without losing history

The migration is where most switches fail, and it fails for a predictable reason: people import first and check afterwards.

The shape that works is two-phase, and it is worth insisting on regardless of tool.

Phase one, preview. Upload the file and get back three things before anything is written: the proposed mapping from your column headers to fields, a count of how many rows match a contact already in the system, and the first parsed rows so you can see what the mapping did to real data. Autocloz returns twenty rows for exactly this. Read them. The mapping error you catch here is the one you would otherwise find in 8,000 rows.

Phase two, commit. Confirm or adjust the mapping and write. Autocloz dedupes on the workspace and lower-cased email, skips matches by default, and updates them instead if you set update_existing. Rows without an email are reported as skipped rather than silently dropped, which is the behaviour you want — a silent drop is how 400 rows go missing without anybody noticing. Person and Company records are auto-created from name, company name and title columns where present, with Persons deduped by name and company so one import does not create duplicate people.

Six practical notes from doing this badly at least once:

1. Files cap at 50,000 rows. Split a larger export rather than trimming it.
2. Clean before you import, not after. Trim whitespace, lowercase emails, split full names if the target expects first and last separately. Validating addresses first also stops you importing a bounce problem — the email checker will do that pass on a list before it enters the system.
3. Import a 50-row sample first. Check every field on one record by hand, then delete it and run the real import. Twenty minutes that saves a re-import.
4. Decide what your custom fields are before importing, not while. Fields created ad hoc during an import are the ones nobody can name three months later.
5. Keep the original file. Not as a backup of the data, as a record of what the columns meant.
6. Export your mailboxes separately. The message history is not in the sheet, so it is not in the import. If you need it, it comes from the mailbox.

Once contacts are in, the pipeline is the part that has no spreadsheet equivalent worth preserving — defining sales pipeline stages is a fresh decision rather than a migration, and the deals and pipeline surface is where that structure lives. If you are comparing the destination against a conventional per-seat CRM, the Autocloz and Pipedrive comparison is the direct one.

What a CRM does not do better than a spreadsheet

It is not a better calculator. Territory modelling, quota scenarios, commission maths and any question you will ask once belong in a sheet, and exporting from the CRM to answer them is the correct workflow rather than a failure of the CRM.

It does not make a bad process good. A CRM records the process you have. If your qualification is inconsistent, you now have inconsistent qualification with timestamps on it.

It does not eliminate data entry, it relocates it. Activity capture is automatic for anything the system sent; anything that happened in a phone call, a corridor or somebody's personal inbox still has to be typed by a person, and the field that nobody fills in is empty in a CRM exactly as it was in a sheet.

It does not import what was never written down. The history you have is the history in the file.

And the audit trail is not complete by construction. Autocloz writes audit rows on a best-effort basis and deliberately swallows a failed audit write rather than failing the request that caused it, on the reasoning that a broken audit table should not stop somebody signing in. That is the right availability trade-off and the wrong assumption if you were treating the log as a complete legal record. If you need one, export it on a schedule rather than assuming it is exhaustive.