When a spreadsheet stops being good enough

Spreadsheets get unfairly maligned by software people. They are one of the most successful tools ever built: instantly available, endlessly flexible, and understood by everyone in your business without training.

Most spreadsheets should be left alone. But there is a point where one stops being a useful tool and becomes an operational risk, and it is worth knowing where that line is.

The warning signs

More than one person edits it at once. The moment two people are in the same file, you have a concurrency problem with no locking and no audit trail. Someone overwrites someone else’s row and nobody notices for a week.

It has become the system of record. If losing the file would genuinely hurt, and the only backup is whatever the cloud provider happens to keep, that is a business continuity issue wearing a familiar interface.

It is glued to another system by copy-paste. Data typed into one system and manually copied into the sheet is an integration that a person is performing by hand, badly, forever.

Nobody fully understands the formulas. Especially if the person who wrote them has left. A sheet with logic nobody can explain is a black box making business decisions.

Validation exists only in people’s heads. Nothing stops someone typing a date in the wrong format, a negative quantity, or a customer name three different ways. You find out at month end.

It has grown tabs the way a house grows extensions. Nine tabs, cross-linked, with one called “DO NOT DELETE”.

The cost is usually invisible

The reason this persists is that the cost never appears on any invoice. It shows up as time, in fifteen-minute increments spread across the week: reconciling two versions, chasing down which number is right, redoing something that was overwritten.

Twenty minutes a day is about 83 hours a year. At a loaded cost of $40 an hour, that is $3,300 annually, repeating forever, for one process. Most businesses have three or four of these running at once.

What to do about it, cheapest first

1. Fix the process before automating it. Write down the steps as they actually happen. Frequently this alone removes work, because someone notices two steps that cancel out or an approval nobody reads. Automating a bad process gives you a faster bad process.

2. Add validation where the sheet allows it. Data validation rules, locked formula cells, protected ranges. Free, takes an afternoon, and prevents a meaningful share of the errors.

3. Move to a proper tool if one exists. If the process is standard, someone sells software for it. A $30 a month product beats a $10,000 build every time the product actually fits.

4. Build the thin layer, not the whole system. This is the option people miss. You rarely need to replace everything. Often the fix is a small form that validates input and writes to the same place, or an integration that removes the copy-paste step. That is days of work, not months.

5. Build the application. Worth it when the process is genuinely yours, several people touch it daily, and errors cost real money.

What you gain, concretely

Not “digital transformation”. Specifically: two people can work at once without overwriting each other, bad data is rejected at entry rather than discovered at month end, you can see who changed what and when, and the thing that used to take twenty minutes takes none.

What you lose

Flexibility. A spreadsheet lets anyone add a column at 4pm on a Friday. Software does not, and that is mostly the point, but it is a real trade and worth naming before you make it.

Which is why the honest recommendation is usually to keep the spreadsheet for the exploratory, changing work, and build only the part that has stabilised and is costing you money.

If you want help working out which of your spreadsheets has crossed the line, describe what your team does every Monday.

Further reading

• Canada Digital Adoption Program