Client tracking: when a spreadsheet is enough, and when it isn't

A spreadsheet is enough while one person maintains it, the number of live engagements fits on one screen, and each client has exactly one thing happening at a time. It stops being enough when a second person needs to edit it, when a client can be at two stages at once, or when you start keeping notes that belong to a project rather than to a row. Those are the three thresholds. Everything else — feature comparisons, tool reviews, the sense that a real business would have a proper system — is noise.

The four jobs

Whatever you use, client tracking exists to answer four questions without you having to remember anything:

1. Who is waiting on me, and since when.
2. What have I promised, and by when.
3. What work is done but unpaid.
4. Where is the decision that explains why this looks the way it does.

A tool that answers all four badly is worse than a spreadsheet that answers three of them well. Judge candidates on these, not on their feature list.

What a spreadsheet is genuinely good at

It opens instantly, it has no learning cost, and every person you will ever work with already knows how to use it. You can restructure it in thirty seconds because there is no schema to migrate. Arithmetic — pipeline value, unpaid totals, average days to payment — is native, and in Google Sheets there is a full version history, which is more recovery than most database tools give you on a free plan.

It is also the only option that survives you losing interest. A spreadsheet neglected for six months is still readable. A half-built workspace in a database tool, with three views and a broken relation, is archaeology.

Where it quietly fails

Not with an error message. With a slow drift into being wrong:

• Two editors. The moment somebody else updates it, you get simultaneous edits, a duplicated row, and a version of the truth that depends on who refreshed last. Locked cells and named ranges hold this together for a while, then don't.
• One row per client, but several projects. People solve this by widening the row — Project 2 status, Project 2 fee — and the sheet becomes unfilterable. The correct fix is a second table with a relation, which is the point at which you are building a database in a spreadsheet.
• Nothing reminds you. A date in a cell does not chase anyone. Conditional formatting turns a cell orange, which works right up until the sheet has forty rows and everything is orange.
• Notes have nowhere to live. Call notes, scope changes and the reason you agreed to something end up in a cell comment, an email thread, and your head. Six months later a client asks why they were charged for a second round and the answer is not recoverable.
• No history per record. You can see that the sheet changed. Reconstructing what happened to one client, in order, is a different matter.

Where a database tool earns its cost

Notion, Airtable and the lighter CRMs all solve the same specific problems: one client record with many linked projects, several views over the same data (by stage, by owner, by overdue), a page of notes attached to the record rather than to a cell, and permissions so a collaborator can update their own rows without reformatting yours.

The costs are real and rarely mentioned in the comparison posts. There is a setup tax — a first version that takes an evening and a second version, three weeks later, that takes another, because the first schema was wrong. Free tiers are generally aimed at one person, so a second editor is usually the point at which you start paying per seat; check the current terms rather than trusting a comparison table. Arithmetic across records is more awkward than a spreadsheet formula. And you are now in a schema: adding a field is easy, changing what a field means across eighty existing records is not.

The lock-in question deserves an honest answer rather than a shrug. Exports exist, and they will give you back your rows. They will not give you back your views, your relations, your templates or your rollups. Assume that whatever you build, the structure stays in the tool and only the data leaves.

A ten-minute test

Open your current sheet and count:

• People who edit it. More than one → move.
• Live engagements. Under roughly fifteen, a sheet is fine. Past about twenty-five rows of things that are actually happening, scanning stops working.
• Clients with more than one open project. More than a couple → move, or split into two sheets before the row-widening starts.
• Times in the last month you looked something up in email instead of the sheet. More than three or four → the notes problem has already arrived.
• Things you missed — a follow-up, an invoice, a promised date. Two or more → the problem is reminders, and neither a spreadsheet nor a database fixes it on its own. A calendar entry does.

Zero or one trigger: stay, and spend the hour improving the sheet instead. Three or more: the sheet is already costing you more than the move would.

The migration that goes wrong

The common failure is starting the rebuild during a busy month, getting the new system to about seventy per cent, and then running both for "a couple of weeks". Both systems immediately become unreliable, because every update lands in whichever one was open. After a month people go back to the spreadsheet, and the conclusion drawn is that the tool didn't suit them.

What works better: pick a cut-off date. Migrate only the live engagements — not the archive, which can stay in the old sheet as a read-only file forever. Run the new system for one week with your real work in it, then delete the shortcut to the old one. If something is missing after a week, it was not load-bearing.

Build the smallest structure that answers the four questions. One clients table, one projects table, one relation between them, three views. Rollups, dashboards and automations can wait until you have used it for a month and know which ones you actually want.

For that starting structure, we sell a Freelance Client Operations Kit: a Notion workspace with linked client and project databases, the views described above already set up, and a PDF explaining how to adapt the fields. It needs a free Notion account, and it is deliberately small — if you want pipeline forecasting or invoicing built in, this isn't that.

If you stay in the spreadsheet, change four things

• Add a Next action column and a Next action date column. Sort by date. Most of what a CRM does for a solo freelancer is these two columns and the discipline to fill them.
• Add a Waiting on column with two values: me, them. It makes the "who is blocking this" question a filter rather than a memory exercise.
• Split project status from payment status. Conflating them is why work gets delivered and never invoiced.
• Move dated commitments into your calendar. The sheet records state; the calendar creates the interruption.

Related

• What belongs in a freelance proposal
• Structuring an SOP people actually follow
• Trackers and client systems in the shop: Client & Project Systems