Why a spreadsheet is a reasonable first CRM
Everyone already knows how to use one, it costs nothing, it needs no approval, and it can be restructured on a Tuesday afternoon when the process changes. For a business with a few hundred contacts and one or two people following up, those four properties beat every feature a real CRM offers.
It also forces a useful discipline. Writing the columns makes you decide what you track, and that decision is the same one you would pay a consultant for later. A business that has run a good sheet for a year arrives at a CRM project with a specification already written, which is why we never sneer at one.
The failure is not using a spreadsheet. The failure is using a spreadsheet badly, on a laptop, with no backup, while telling yourself it is temporary.
The three tab structure that works
Most homemade CRM sheets are one enormous tab with fifty columns, which is why they collapse. Three tabs, related by a stable identifier, survive far longer.
Tab one, Contacts. One row per person, and a person appears exactly once. This is the tab that stops duplicates, because every other tab points here rather than retyping a name.
| Column | Type | Why it earns its place |
|---|---|---|
| ID | Text, never reused | The join key. C001, C002. Never renumber, never sort this away |
| First name, Last name | Text, separate | Separate, always. Splitting later is painful and lossy |
| Company | Text | Keep spelling consistent with a dropdown, not with discipline |
| Email, Phone | Text | One each. A second email belongs in Notes, not in a new column |
| Source | Dropdown | The single most valuable column and the first one people skip |
| Owner | Dropdown of names | Every row has one. Blank owner means nobody is responsible |
| Created | Date | Entered by a shortcut, not by hand |
| Status | Dropdown | Lead, active, customer, lapsed, do not contact |
| Consent | Dropdown plus date | What they agreed to and when. You will be asked to prove it |
Tab two, Deals or Jobs. One row per piece of work, with a Contact ID column linking back. A contact can have five rows here and the contact details still exist once. Columns: deal ID, contact ID, what it is, value, stage, next action, next date, owner, created, closed, outcome reason.
Tab three, Activity. One row per interaction: date, contact ID, type, a one line note, who did it. Appended to, never edited. This tab is why you can answer what happened with this customer in March, and it is the tab people leave out, which is why most spreadsheet CRMs cannot answer that question.
Two supporting habits: a hidden Lists tab holding every dropdown, so options stay consistent, and protected ranges on the ID columns so a sort cannot destroy the relationships. Sorting a sheet with unprotected IDs is the classic way to lose a year of history in one click.
The formulas worth having, and the ones that waste a weekend
Four formulas do almost all the useful work. Everything past them tends to be craftsmanship you will not maintain.
- Overdue flag. A conditional format that turns a row amber when the next date is today and red when it is in the past. This one formula converts a list into a work queue, and it is the highest value thing in the sheet.
- Lookup of the contact name into the deals tab, so you read names rather than IDs. Read only, derived from the ID, never typed.
- A pipeline summary counting rows and summing value per stage, on its own tab. Five rows of output, and it is your Monday number.
- Days in stage, today's date minus the date the stage was last changed. The most diagnostic number in any pipeline, and the one commercial CRMs charge for.
What to avoid: elaborate dashboards with charts that need rebuilding every time a column moves, scripted email sending, and anything that relies on one person's add ons. We have seen a sheet with four hundred lines of script behind it, maintained by someone who had left. That is not a CRM, it is a hostage situation.
Also resist merged cells and colour as data. Colour is a signal for humans and invisible to every formula and every future import, so if a colour means something, it needs a column.
Keeping Excel like forecasting after you move
The thing sales managers miss most after leaving a spreadsheet is not the grid. It is the forecast: one tab where each deal has a value, a probability and a close month, and a total that updates as you type. Many CRMs make that harder than it was in Excel, which is a fair complaint.
It does not have to be. A forecast view in a CRM should behave like the sheet did: deals as rows, months as columns, editable values and probabilities inline, and a weighted total at the bottom. The difference is that the rows come from live deals instead of a copy someone pasted on Monday, and changes are recorded so you can see how the forecast moved over the quarter.
When we migrate a client off a spreadsheet, we rebuild their forecast tab first, with the same column order and the same names. People adopt a new system faster when the one screen they check every morning looks familiar.
Where every spreadsheet CRM fails
Five failures, all predictable, all arriving in roughly this order.
- Concurrency. Two people edit at once and one set of changes wins silently. Cloud sheets handle simple cases and still lose work when two people restructure the same region.
- No audit trail. Version history tells you a cell changed, not that a salesperson moved a deal to won on a date. When a number is disputed you cannot reconstruct why.
- No automation. Every follow up depends on a human reading a row. This is where the revenue leaks, quietly, and nobody can measure what was lost.
- Permissions are all or nothing. Anyone who can see the sheet can see margin, notes and salaries, and can also delete a thousand rows. Hiding a column is decoration, not security.
- It stops being usable on a phone. Once field staff or anyone outdoors needs it, the sheet is finished, whatever the row count says.
The row count at which this bites varies wildly, which is why row count is a bad trigger. A five hundred row sheet used by six people in the field fails long before a five thousand row sheet used by one person at a desk.
The signals that say move now
Six concrete triggers. Two or more together and the spreadsheet is now costing more than it saves.
| Signal | What it really means | Cost of staying |
|---|---|---|
| Three or more people edit weekly | Concurrency and permissions have no answer here | Lost edits, and arguments about them |
| You cannot answer what happened in March | No activity history | Disputes settled by the loudest memory |
| Follow up depends on somebody remembering | No automation layer | The largest and least visible cost |
| A copy has been emailed around | There are now several versions of the truth | Decisions made on stale data |
| Anyone needs it on a phone | The interface has run out | The field team keeps a second private system |
| It holds data you would not want leaked | Permissions are all or nothing | One misdirected share away from a problem |
Notice that none of the triggers is size. The question is never how many rows, it is how many people, how much history and how much of your follow up is running on memory.
Airtable, Notion and the middle ground
Between a sheet and a CRM sits a category that genuinely changes the calculation, and it deserves a fair hearing because we send clients there regularly.
What they fix. Real relationships between tables instead of lookup formulas, per field types that reject nonsense, several views of the same data for different people, forms that write directly into a table, and basic automations without scripting. That covers four of the five spreadsheet failures.
What they do not fix. Permissions remain coarse in most plans, so field level control is limited. Per user pricing arrives, and it arrives at a rate that surprises people once the whole team needs edit access. Performance degrades on large tables with many linked records. And you are back in somebody else's data model, with an export that flattens the relationships you spent months building.
The practical read: for a team of two to eight doing structured work that is not yet mission critical, these tools are excellent and cheaper than everything else on the table. Past roughly fifteen people who all need to edit, or the moment the data becomes regulated, the per seat cost and the permission ceiling both bite at once, and the comparison becomes a build. The costs sit side by side in what a custom CRM costs.
Personal and business development templates
Two other spreadsheet CRMs come up often enough to deserve their own layout, because neither looks like a sales pipeline.
A personal CRM template tracks a network rather than a funnel. The columns that matter are name, how you know them, last contact date, a target gap between contacts, and a computed next contact date. Sort by that last column and the sheet tells you who to message this week. That is the whole system, and it works for years.
A business development template tracks accounts rather than deals. Partnerships, referral sources and key accounts do not close once. They warm up and cool down. The useful columns are account, relationship owner, last meaningful touch, what was discussed, and the next agreed step. Add a tab that logs each touch with a date, and a simple count per account per quarter shows which relationships are being neglected.
Both outgrow a sheet at the same point as a sales pipeline: when more than one person edits it, or when you need reminders that arrive on their own.
Preparing a spreadsheet so the migration is dull
Whatever you move to, and whoever does it, these steps run first. Doing them yourself removes the most common line item from a migration quote.
- One header row, no merged cells, no colour carrying meaning. If a colour means something, add a column and fill it in before you go further.
- One value per cell. Two phone numbers in one cell, or a name and a company together, become one bad field in the new system and stay bad forever.
- Standardise the date format across every column, as a real date type rather than text. Mixed formats are the single most common cause of an import producing silent nonsense.
- Deduplicate on email, then on phone. Decide the rule yourself and apply it, because you know which of two records is the real one and no importer does.
- Split the one big tab into contacts, deals and activity if it is not already, keeping the IDs. This is the step that preserves history rather than flattening it.
- Count the rows in each tab and write the numbers down. That count is the only thing that proves the migration worked, and it is checked again on the other side.
- Export to CSV, one file per tab, in UTF-8, and open each one in a text editor to see what actually came out.
Half a day of this typically removes a thousand or more from a migration quote and, more usefully, removes the class of problem that is discovered three months later. It is the reason data migration is the cheapest thing we quote.
Importing contacts from a spreadsheet without making a mess
The import itself is where good preparation gets thrown away, so it is worth doing in a particular order.
Import contacts first and nothing else. Check the count, check ten records by hand against the source, and only then import deals, which reference the contacts by ID. Activity comes last, because it references both. Importing in the wrong order creates orphans that are tedious to reconnect.
Keep the original ID in a legacy field on every imported record. It costs nothing, and it means any question asked in the next three years about where this record came from has an answer. Every migration we run keeps this field, and clients use it more often than they expect.
Do not import everything. Contacts with no activity for three years and no consent record are a liability rather than an asset, and importing them means paying to store and process data you cannot lawfully use. Archive the file, import what is live, and note in writing what was left behind and why.
Finally, run last quarter's numbers on both systems and compare. If revenue by source does not reconcile, something did not come across, and finding that out in week one is a great deal cheaper than finding it out at year end.
What you should expect to gain
Moving off a spreadsheet is not mainly about features. Four things change, and they are worth naming so you can check whether you got them.
- Nothing goes quiet by accident. Every record has an owner and a dated next action, and a report exists that lists the ones that do not.
- History survives people. When someone leaves, their accounts have a readable record rather than a memory and a folder of emails.
- Permissions become real. Field staff see their work, managers see margin, and export is a separate logged action rather than a keyboard shortcut.
- Questions get answers. Revenue by source by month, average days in stage, win rate by person. All of them are one query instead of an afternoon.
If a proposed system does not deliver those four, it is a more expensive spreadsheet. That is the bar we hold our own builds to, and it is a fair bar to hold any vendor to. If your sheet is still working, keep it, keep it backed up, and come back when two of the six signals above are true.
The structure, drawn
Three tabs, one join key, and the rule that a contact exists exactly once. Everything else in this guide follows from that picture.
One extra tab is worth adding and is not drawn: a hidden Lists tab holding every dropdown option. Source, stage, status, owner, outcome reason. Point every dropdown at it, and your reporting stops splitting into Website, website and Web Site as three separate sources, which is the most common reason a spreadsheet cannot answer where customers come from.
