When a spreadsheet stops being enough

A spreadsheet stops being enough at a predictable point: when more than one person updates the pipeline, when follow-up depends on somebody remembering, and when management numbers have to be compiled rather than read. For a solo founder with a handful of live conversations, a well-kept sheet is genuinely fine. Past roughly two salespeople or thirty simultaneous open deals, the sheet starts costing more than a CRM would — the cost is just hidden in missed follow-ups and unreliable numbers rather than a subscription line.

Why does the spreadsheet feel fine for so long?

Because it fails silently. A spreadsheet never sends an error message; it simply stops reflecting reality, one unlogged conversation at a time. The founder still recognises every row, so the sheet feels under control — but the control lives in the founder's memory, not in the sheet. The rows are a stock; the conversations, promises and stage changes flowing through the business each week are flows; and a static grid captures a flow only as often as a human copies it in. Seen through the lens of systems thinking for founders, the spreadsheet is a snapshot pretending to be a system.

The pretence holds until volume rises or a second person joins. Then versions fork, updates collide, and "the latest sheet" becomes a genuine question. Nothing announces the failure; deals just quietly stop being followed up.

What are the signals it is time to move?

Six show up repeatedly in 5–50-staff service firms:

1. Two or more people touch the pipeline. Concurrent editing, ownership and history are exactly what spreadsheets do worst.
2. Follow-up runs on memory. No next-action date on every open deal means deals age out invisibly. Most firms stop at two follow-up touches while deals typically need five or more — a sheet does nothing to close that gap.
3. Reporting means compiling. If the weekly numbers require an hour of copying and filtering, the reporting layer described in The MD Dashboard Blueprint cannot exist, because there is nothing structured for it to draw from.
4. History is invisible. The sheet shows a deal's current state, not what happened — who said what, when the last touch was, why it stalled.
5. The sheet has a single author. When one person's absence stops pipeline updates, the firm has a bus-factor problem wearing a filing problem's clothes.
6. Rows past roughly thirty open deals. Below that, a disciplined founder can hold the exceptions in their head; above it, nobody can.

One signal is a hint; three or more is a decision already made and not yet admitted.

What does a CRM actually add — mechanically?

Not prettier rows. Four capabilities a grid cannot provide:

• State plus history. Every deal carries its full trail: emails, calls, notes, stage changes, timestamps.
• Triggers. When a deal sits idle for 14 days, then a task fires to its owner; when a lead arrives, then it is assigned within minutes. A spreadsheet cannot act; a CRM can — and the first automations worth wiring in are the ones that compile the numbers, as in the weekly report that writes itself.
• Structure. Mandatory fields, controlled stage lists, one record per company. The disciplines that make numbers comparable are enforced by the tool rather than by nagging.
• Concurrency. Five people can work the same pipeline without forking it.

The mechanism of the move matters more than the software choice: when the stages are defined as verifiable events, then the sheet's columns map onto them; when a row has no activity in recent memory, then it is archived rather than imported; when the import lands, then the sheet is made read-only the same day. A CRM adopted alongside a still-editable spreadsheet loses — the sheet always wins on familiarity, and you end up maintaining both.

Which CRM — and how heavy?

Lighter than the market wants to sell you. A 5–50-staff service firm needs contacts, companies, deals, tasks, pipelines and an API — a category examined properly in choosing a CRM for a small B2B firm. What it does not need is an enterprise licence with features that go unused while the basics go unadopted. Adoption, not capability, is where CRM projects die; the tool must be easier than the sheet for the people logging calls, or they will drift back within a month.

Isn't this just moving the problem into different software?

Only if the move copies the old habits into the new tool. A CRM used as a prettier spreadsheet — free-text stages, optional fields, no triggers — fails identically and costs more. The point of the migration is to change the mechanics: data entered once at the moment it happens, follow-up driven by the system, numbers read rather than assembled. Get that far and the next layer becomes cheap — live reporting without a BI project, which is the subject of dashboards without the BI project.

The spreadsheet was never the problem; working from memory was. The move is worth making at the point where memory stops scaling — which arrives earlier than most founders think.

---

Next step: the Growth System Audit — £450, seven days, credited against any build — maps where your growth system leaks, including whether your pipeline records can support growth, and what to build first.