Why Your Business Can't Quit Spreadsheets - and What Finally Replaces Them

The spreadsheet you're afraid to touch

Every operations-heavy business has one.

It has a name like Master_Tracker_v7_FINAL_USE_THIS_ONE.xlsx. It was built years ago by someone who may or may not still work for you, and it has grown into forty-three tabs, colour-coding only two people can interpret, and a macro nobody dares to re-run after 5pm. The whole operation quietly routes through it - scheduling, compliance dates, margins, the real status of every job.

You've tried to kill it at least twice. There was the CRM rollout. There was the project management tool the consultant recommended. Both went live. Both are still running. And both are, right now, being reconciled against the spreadsheet - because when the numbers disagree, everyone trusts the spreadsheet.

Here is the uncomfortable claim this post will defend: your business can't quit spreadsheets because the spreadsheet is the only place your actual operating model has ever been written down. Once you see it that way, the path out looks completely different from "buy better software."

First, the damage report

Before defending the spreadsheet, let's be honest about the case against it - because it is brutal, and it is public.

JPMorgan, 2012. The bank's Value-at-Risk model for its Chief Investment Office ran on Excel spreadsheets, filled in manually, with figures copied and pasted from one workbook to another. The bank's own task force report found a formula error that divided by a sum instead of an average - understating volatility right as the "London Whale" trades went wrong. Total losses exceeded $6 billion.

TransAlta, 2003. The Canadian power generator lost $24 million on hedging contracts because of a cut-and-paste error in an Excel bid sheet. The CEO called it "literally a cut-and-paste error in an Excel spreadsheet."

Public Health England, 2020. Nearly 16,000 positive COVID-19 cases vanished from the national reporting system because case data was moved through an old Excel file format that silently ran out of rows.

Reinhart and Rogoff, 2013. One of the most-cited economics papers of the decade - used to justify austerity policy across multiple governments - turned out to contain an Excel range error that excluded five countries from a key average.

And underneath the famous cases sits the everyday reality: decades of research by Raymond Panko at the University of Hawaii found errors in roughly nine out of ten real-world spreadsheets audited. Not sloppy businesses. Ordinary ones. Spreadsheet error isn't an exception - it's the baseline.

So the prosecution rests. Spreadsheets are fragile, unauditable, and one mis-dragged formula away from a very bad quarter.

And yet yours is still open in a browser tab right now. Why?

Why the software you bought didn't kill the spreadsheet

We've now researched operations across ten industries - law, accounting, insurance broking, investment advisory, property, life insurance, data consultancies, venues, film production, retail supply. Different regulations, different vocabularies, different economics. One pattern held in every single one:

Somewhere in the business, the most critical operational system was a spreadsheet - usually sitting right next to expensive software that was supposed to replace it.

That is not because operators are stubborn. It's because of a structural difference between spreadsheets and almost every product they've been sold:

Off-the-shelf software makes your operation bend to the tool. A spreadsheet bends to your operation.

A generic CRM has an opinion about what a "deal" is. A project management tool has an opinion about what a "task" is. Those opinions were formed in an office far away from your industry, averaged across a million customers who are nothing like you. The moment your real process doesn't fit the tool's opinion - a compliance step the tool has no field for, a pricing rule it can't express, an exception it refuses to model - your team does the only rational thing. They open a spreadsheet, because a spreadsheet has no opinions. It will model anything.

That's why the rollout never sticks. The software captures the 80% of your operation that looks like everyone else's, and the spreadsheet quietly keeps the 20% that is actually you - the judgment calls, the exceptions, the rules of thumb, the "we always check this before that." The 20% that is, not coincidentally, where your margin and your risk both live.

The reframe: your spreadsheet is an operating manual in a language one person speaks

Look at the load-bearing spreadsheet in your business again - not as a file, but as a document. What is actually written in it?

The column order is a workflow. The colour-coding is a status model. The formulas are your pricing logic, your capacity rules, your compliance thresholds. The tab that says "DO NOT TOUCH" is a dependency diagram. Ten years of operational judgment, encoded cell by cell by the person who runs the process.

Your spreadsheet is your operating manual. It's the most honest documentation your business has ever produced - more honest than the process diagrams from the last consulting engagement, because people actually use it.

The problem is that it's written in a language only one or two people can read, in a medium that can't check itself, can't alert anyone, can't enforce anything, and - as JPMorgan can confirm - can't tell you when it's wrong.

So the fair question isn't "how do we get rid of the spreadsheet?" It's: what would we actually gain by replacing something that fits us this well? If the answer were just "nicer software," you'd be right to keep the spreadsheet. It isn't.

What Operational Encoding actually changes

Operational Encoding is the discipline of researching how an industry actually operates - its regulations, formulas, workflows and unwritten rules - and encoding that operating knowledge into purpose-built systems, before any software gets built. I coined the term - Schalk van der Merwe, at 4What Digital - and it's the discipline we work in: we encode industries before we build software.

Applied to the spreadsheet problem, the premise is simple: keep the spreadsheet's perfect fit to your operation - and add five things a spreadsheet is structurally incapable of.

1. Your rules start enforcing themselves. In a spreadsheet, your pricing floors, compliance thresholds and approval steps are descriptions. They only work when someone remembers to check them. Encoded, they become behaviour: the quote below margin gets blocked, the file approaching a regulatory threshold gets flagged, the deadline escalates while there's still time to act. The rule stops being advice and starts being infrastructure.

2. Key-person risk becomes a company asset. The judgment currently living in one operator's head - and their forty-three tabs - becomes explicit, documented and executable. "If our operations manager left tomorrow, how long would it take to rebuild what they know?" stops being the scariest question in the business. And the flip side is underrated: onboarding compresses, because reading the system is reading the operating manual.

3. Errors announce themselves. The JPMorgan failure wasn't really the broken formula - it was the silence. The error sat inside the model for months with nothing to catch it. An encoded system validates inputs, reconciles against source systems, and keeps an audit trail. Wrongness surfaces in hours, not at month-end, and not when a client points it out.

4. You see the operation while it's still happening. A spreadsheet shows you the past - whenever someone last updated it. An encoded system shows you capacity, margin and status live. That changes when you get to make decisions: mid-week, while a problem is cheap, instead of at the post-mortem, when it's expensive.

5. It compounds. This is the value most people miss. A spreadsheet is worth exactly the same on day 1,000 as on day one. An encoded system accumulates your operational data and starts surfacing what no spreadsheet ever will: which job types quietly erode margin, which clients go silent before they leave, where the team's hours actually go against what was quoted. The spreadsheet just gets heavier with age. The system gets smarter.

And the economics only work because of a structural pattern we keep seeing across those ten industries: operational architecture repeats. In our experience, somewhere between 65% and 80% of each platform we build turns out to be common machinery - that's our own estimate from our own builds, not an industry statistic - so you're not paying anyone to reinvent the generic bulk. You're paying to encode the part that is actually yours: your industry's rules, your formulas, your exceptions. Consulting-depth research at technology-team speed - weeks, not months, before anything gets built.

What replacing a spreadsheet actually requires

This also explains why the last rollout failed: nobody decoded the spreadsheet first. The team bought a tool and hoped the operating model would migrate itself. It never does. In practice, retiring a load-bearing spreadsheet takes three moves:

1. Decode. Treat the spreadsheet as source material, not clutter. Every formula, every colour rule, every "we always do it this way" gets researched and written down - alongside the industry's actual regulations, formulas, and workflows. Deep, practitioner-level research, not a requirements workshop.

2. Encode. Build the system around what you decoded - so it understands your compliance obligations natively, speaks your industry's language, and models the exceptions instead of refusing them. The operator should recognise their own week in the navigation. If they don't, you've built another tool they'll route around.

3. Retire. The spreadsheet doesn't get banned - it gets obsoleted. When the system holds the same knowledge plus the five upgrades above, the tab simply stops being opened. That's the only kill signal that matters.

Notice what's different from the standard playbook: the starting point isn't a feature list or a software demo. It's your existing operating knowledge, treated as the asset it is.

The five-question spreadsheet audit

You can run the first diagnostic yourself this week. For each spreadsheet your operation touches daily, ask:

1. If this file was deleted tonight, would revenue stop? If yes, it's load-bearing - it's not a spreadsheet, it's infrastructure wearing a costume.
2. How many people can explain every formula in it? If the answer is one, you have key-person risk with a filename.
3. Has it ever disagreed with your "real" software? And when it did - which one did you trust? Your answer tells you where your actual operating model lives.
4. Does it encode rules - pricing, compliance, thresholds - that exist nowhere else? That's unwritten IP. It should terrify you slightly that it lives in cell G14.
5. When it's wrong, how do you find out? If the answer is "a client tells us" or "at month-end," you're running blind between checkpoints.

Two or more uncomfortable answers on a single file means you've found the place where your business is most exposed - and, more usefully, the place where the highest-value system you could build is already specced. The spreadsheet did the requirements gathering for you. It's been doing it for years.

FAQ: getting your operations out of spreadsheets

What is Operational Encoding?

Operational Encoding is the practice of researching how an industry actually operates - its regulations, formulas, workflows and unwritten rules - and encoding that operating knowledge into purpose-built systems. The term was coined by Schalk van der Merwe at 4What Digital. The methodology runs in three moves: decode the existing operation, encode it into a system built for that industry, and let the platform learn from live operational data.

Why do businesses still run on spreadsheets after buying software?

Because off-the-shelf software makes the operation bend to the tool, while a spreadsheet bends to the operation. Generic systems capture the 80% of a business that looks like every other business; the critical 20% - pricing rules, compliance thresholds, exceptions - retreats into a spreadsheet. That's why the spreadsheet survives every rollout.

How do you replace a business-critical spreadsheet?

In three moves: decode it (treat every formula, colour rule and habit as source material, and research it properly), encode it (build a system that holds those rules natively and enforces them automatically), and retire it (the spreadsheet isn't banned - it's obsoleted, and the tab stops being opened).

When does a spreadsheet become a business risk?

When it's load-bearing: revenue would stop if the file were deleted, only one person can explain its formulas, it regularly disagrees with the "real" software and wins, or it encodes pricing and compliance rules that exist nowhere else. Two or more of those signals on a single file means your operating model itself lives in the spreadsheet.

Where this goes

We're publishing our thinking openly this year - the diagnosis, the methodology's shape, the patterns we keep finding across industries. (The formulas, data models, and research process stay behind the gate; that's the IP.) If you want the foundational piece on what Operational Encoding is and why we coined the term, start here.

And if you looked at question two above and thought of a specific file and a specific person - that's usually the conversation worth having.

Schalk van der Merwe is co-founder of 4What Digital, where he leads Operational Encoding for operations-heavy businesses. Reach him at schalk@4whatmarketing.com or visit 4whatdigital.com/operations.