The spreadsheet is not the problem

Every operations team eventually holds the inquest. An order shipped twice, an invoice sat unpaid for 60 days, two people spent Friday afternoon reconciling numbers that should have matched, and the verdict lands on the master spreadsheet. Outgrown. Time for a proper system.

Sometimes that verdict is right; those cases are below. More often the spreadsheet is doing its job and the failure modes live in the process wrapped around it. A platform bought at that moment does not remove the confusion. It preserves it in a more expensive form.

The failure modes around the file

Take a bookings sheet in a 30-person firm. Three people update it, but nobody owns it, so the column added in March still has no agreed meaning in June. Sales key the same client details into the CRM, and every mismatch between the two becomes a coin toss over which version is true. Approval happens in an email thread; the sheet records only the outcome, so when a decision is challenged months later, somebody goes digging through inboxes. Anyone with the link can edit any cell. No history records who changed the price, or when, or why.

None of these are spreadsheet defects. Excel did not decide that two systems should hold the client's address, or that sign-off should live in a reply-all chain. Unclear ownership, duplicate entry, invisible handoffs, absent permissions, no audit trail, decisions in email: these travel. Move the process onto a new platform unchanged and you keep every one of them, now with licence fees, onboarding and an integrations backlog attached.

Map the workflow before you replace the tool

The instinct to swap the tool first is understandable, because a purchase feels like progress and mapping feels like homework. But a migration forces definitions: what each field means, who may change what, which states a job passes through. Do the defining while the process is still fog and the fog gets encoded, this time behind an API.

The cheaper order is to map first. Six questions do most of the work:

• Who starts the process, and what triggers them?
• What information does each step need, and where does it come from?
• Who checks the work, and what exactly do they check?
• Where does it fail today, and what does each failure cost?
• What must be auditable, and for whom?
• Which systems already hold the important data?

The answers tell the product what to become. Often they describe something cheaper than software: the sheet needs one named owner, one write path, and a note that says what each column means. That can be done by Thursday. If the answers instead describe concurrency, volume or compliance the format cannot carry, you now have a scope worth building against rather than a feeling.

Sometimes the spreadsheet really was the problem

The counterargument has famous evidence, and it deserves a fair hearing.

In October 2020, Public Health England lost 15,841 positive Covid-19 test results because its reporting pipeline pushed lab data through Excel's old .XLS format, which stops at 65,536 rows. Results beyond the ceiling silently disappeared, and around 48,000 close contacts went untraced during the second wave. Process discipline does not survive a file format with a hard ceiling being used as national infrastructure.

In 2012, JPMorgan's Chief Investment Office calculated value at risk through a chain of spreadsheets filled in by copying and pasting data from one to another, in the words of the bank's own task force report. One formula divided by a sum where the modeller intended an average, which muted measured volatility by a factor of two and lowered the reported risk. The model understated the exposure on a book that went on to lose more than $6 billion.

The research says these are not freak events. Intensive audits of 85 operational spreadsheets found errors in 94% of them, Raymond Panko reports, with cell error rates typically between 1% and 5%. Those rates sound survivable until they compound: chain a hundred dependent calculations together and a wrong bottom line becomes more likely than not.

So row limits, silent formula errors, version forks and single-file scale problems are real, and they belong to the tool.

A test for telling the two apart

Ask where the failure was born: in a cell, or in a handoff.

Tool failures are mechanical. They reproduce under the most disciplined team you can imagine: a hard row limit, a formula error nobody can see, five concurrent editors overwriting each other, a calculation chain too long to inspect by eye, a file emailed around until "final_v3_USE_THIS" is load-bearing. If your most careful operator, following the process exactly, still hits the incident, replace the tool.

Process failures are behavioural. They need the surrounding habits to reproduce: duplicate entry, unowned columns, approvals living in inboxes, handoffs nobody wrote down. A better tool inherits every one of them intact.

The practical version: take your last three incidents and ask, for each one, whether the same process running on better software would have prevented it. Be honest about the answers. Even the Public Health England case reads differently on inspection. The deeper fault was choosing a desktop file format as the pipe between lab systems and a national database, and the interim fix was to split the data across more spreadsheets. The tool failed, but a process decision put it there.

Our default position: a spreadsheet with a named owner, a single write path and a defined job is the right tool up to a handful of regular editors and tens of thousands of rows. Past that, or the moment the file becomes the system of record for money, compliance or personal data, move to something with permissions and an audit log.

Automation comes after the data model

AI is the current version of the buy-a-platform instinct, and the same sequencing applies. The technology is genuinely useful in operations work: classifying documents, extracting fields from PDFs, drafting responses, routing requests. It also amplifies whatever it is pointed at. Automate duplicate entry and you produce duplicates faster. Ask a model to interpret a column whose meaning nobody ever agreed and it will answer fluently from ambiguity.

The order that works: workflow first, data model second, permissions and auditability third, then automation and AI where they measurably cut cost or risk. By that point the automation is usually smaller than anyone expected, because most of the pain was never technical.

Good internal systems are rarely dramatic. They make the expensive work quieter, clearer and harder to mishandle. A spreadsheet with an owner and a defined job is often one of them.