In defence of the spreadsheet, and how to tell when it has quietly stopped working

My favourite file name I have ever been sent by a client was Jobs2019_FINAL_v3_useTHISone.xlsx. It was 2024. It had six thousand rows, eleven tabs, one column that was colour coded in a system only the owner's wife understood, and it was, genuinely, running the entire business.

I want to be clear that I am not making fun of it. That file was an achievement. Somebody sat down one evening and built the exact thing their business needed, for nothing, in about two hours, and it worked for nine years. Most software costs more than that and does less. Every consultant who came in and said you need a proper system was, at the time, wrong.

But it had stopped working, and it took a while to explain how, because on the surface it was fine. Everything was in it. Nothing was lost. The owner could find any job from any year in about ten seconds, faster than most software would have managed.

Why the spreadsheet was the right call

Worth saying properly, because it explains why the replacement so often fails.

A spreadsheet costs nothing, needs no training, changes shape the same afternoon your business does, and never once tries to teach you a workflow somebody in a different industry invented. When your process changed, you added a column. That is a genuinely extraordinary property and almost no purpose built software has it.

Which is why replacing it with a big rigid platform usually goes badly. People end up with software that cannot express how they actually work, so they keep a shadow spreadsheet on the side for the real information, and now they have two systems and neither is true. I have walked into that more times than the original problem.

The signs it has stopped working

None of these is about the spreadsheet being untidy. They are all about what it costs you now.

• The same fact gets typed more than twice. Customer name in the spreadsheet, again in the invoice, again in the calendar, again in the text to the engineer. Every duplicate is a chance for two versions of the truth to exist.
• Only one person can safely edit it. If the answer to who updates it is always the same name, you do not have a system, you have a person, and that person cannot go on holiday.
• Reporting means an evening. If knowing what you turned over last month requires an hour on a Sunday with a calculator, you are not checking it monthly. You are checking it when you are worried, which is exactly when you most need to already know.
• You have stopped asking questions of it. This is the quiet one and it is the most expensive. Which jobs are most profitable, which source sends the best work, how long a certain job really takes. You could work all of that out from the file. It would just take three hours, so you never do, and you run the business on a hunch instead.
• There is a version problem. Two copies, one on a laptop and one in a shared drive, and a conversation about which is current.
• Something important lives only in someone's head. The colour codes, the reason that one row is bold, why the November total was adjusted.

If none of those apply, keep the spreadsheet. Genuinely. We have told people that on a first call and ended the conversation there, because we would rather do that than sell somebody four weeks of work to solve a problem they do not have yet.

The cost is not the typing

When people add up what the spreadsheet costs them, they count minutes of data entry. Ten minutes a day, an hour a week, call it fifty hours a year. Annoying, not fatal.

That is the small half. The expensive half is the decisions you are not making. A business that cannot cheaply answer which of these two kinds of work is actually worth doing will keep doing both, at the same ratio, for years. The lost money is not in the typing, it is in the shape of the business staying the same because the information required to change it is technically present but practically unavailable.

The second expensive half is reconciliation. Not entering data, but working out which of two disagreeing records is right. That is the thing that eats evenings, and it does not show up in anybody's estimate of how long admin takes.

We do not start by replacing it

The first thing we do is stop the duplicate typing, and we do it while the spreadsheet is still in charge.

That means the job gets recorded once, at the point it happens, and everything else fills itself in from that. The enquiry that came in this morning writes itself into the record. The completed job triggers the invoice. The invoice payment marks itself off. Nobody types a customer's address a second time.

Only once that is running do we care where the data lives, and by then the answer is usually obvious rather than a decision. The old file becomes the archive it always was, and the reports you used to build on a Sunday are simply there on a Monday morning, already assembled.

What the first fortnight actually looks like

Honestly, mostly it looks like us reading your spreadsheet and asking irritating questions about it.

Why is this row yellow. What does OTG mean in the status column. There are two Mrs Patels here, are they the same person. This job has no value against it, was it a warranty callback or did somebody forget. Why does the September total not match the bank.

That is not us being pedantic, or not only. Every one of those questions is a rule your business already runs on that has never been written down, and the new system needs to know it. You will find the process of answering them mildly uncomfortable, because a few of the answers turn out to be nobody knows. Better to find that out in week one with us than in month six with a customer.

Nothing goes live during this. Your team works exactly as they did. That is deliberate, and it is the same shape as the way we run every build: assemble it, test it against jobs that already happened, then switch it on and watch it for a week.

Keep the spreadsheet

Two reasons, and I mean this practically rather than sentimentally.

The first is that you should be able to get your data out at any moment, as a plain file, without asking anybody's permission. If a system cannot hand you a spreadsheet of everything it holds, you do not own your records, you are renting access to them. That is a question worth asking of every piece of software you pay for, including anything we build.

The second is that spreadsheets are still the best tool in the world for thinking. When you want to test a pricing change or work out whether a second van pays for itself, export it and go and play in a spreadsheet like a normal person. The point of retiring it is that it stops being the place your business is recorded. Not that it stops being useful.

Where this goes wrong

• When the real problem is that nobody agrees on the process. Software does not settle an argument about who owns what, it just encodes whichever side was in the room.
• When the spreadsheet is genuinely fine. Under about two hundred jobs a year with one person maintaining it, the honest advice is often to leave it alone and fix something else.
• When there are two shadow systems already. If the office has a spreadsheet and the field has a WhatsApp group and both are load bearing, expect the first month to be about people rather than data.
• When somebody's identity is tied to the file. It happens more than you would think, and it is not silly. Whoever built that thing kept the business alive with it, and a migration that treats it as a mess to be cleaned up will fail on those grounds alone.

The natural next thing, once records look after themselves, is the money side: estimates that chase themselves and invoices that do not need a reminder from you. That is quote to cash.