A purchase order sits in a shared spreadsheet, waiting for the finance manager to change a cell from "Pending" to "Approved". The vendor calls twice. The site supervisor, who needs the material by Thursday, has no idea the request is stuck because someone was on leave and nobody reassigned the row. This is not a people problem. It is a software problem wearing a people costume.
Every operations team we speak with started with spreadsheets for good reason: they are flexible, familiar, and free. The trouble is not that spreadsheets are bad tools — they remain unmatched for analysis, modelling, and one-off reporting. The trouble is that they get pressed into service as the coordination layer for live, multi-person processes: approvals, purchase orders, site progress, collections follow-up, service tickets. That is a job spreadsheets were never designed to do, and the gap between what they can do and what the business needs from them is what we call operational software debt.
What operational debt looks like in practice
Technical debt in software engineering is a useful analogy. A team ships a shortcut to hit a deadline, intending to fix it later; the fix never comes; the shortcut becomes load-bearing. Operational debt follows the same pattern. A spreadsheet tracker gets built in an afternoon to solve an urgent problem — perhaps a backlog of unapproved expense claims. Six months later, that same spreadsheet has twelve tabs, three hidden columns nobody remembers the purpose of, and a macro that only one former employee understood.
The debt is invisible most of the time. It only becomes visible at the worst moment: during an audit, during a busy season, or when the one person who understood the workbook leaves. By then, the cost of the shortcut has compounded well beyond what fixing it early would have cost.
The five warning signs
- A process depends on one named individual remembering to check a tab or a WhatsApp thread.
- Status information exists in more than one place and the copies disagree.
- New joiners need a 45-minute walkthrough before they can safely touch the file.
- Approvals happen by comment, chat message, or verbal confirmation, then get transcribed later — or not at all.
- Nobody can say, right now, how many items are stuck and for how long, without opening the file and counting manually.
If two or more of these apply to a process in your business, you are not looking at a tooling preference — you are looking at a risk. This is the same conclusion we reach in [what an AI-native business system actually means](/insights/what-ai-native-business-system-means): the question is not whether a spreadsheet can technically hold the data, but whether it can hold the process without a person compensating for its gaps.
Why the failure is usually silent until it is not
Spreadsheets fail gracefully from a technical standpoint — they rarely crash — which is precisely what makes them dangerous operationally. A formula reference breaks quietly. A row gets sorted out of order and a status flag no longer lines up with the correct request. A file gets duplicated and edited in two places by two people who each believe they hold the master copy. None of these produce an error message. They produce a wrong number that someone eventually notices, usually downstream, usually too late to be a minor issue.
The pattern across functions
The same debt shows up with different costumes depending on the function. In procurement, it is the purchase order tracker that cannot tell you, at a glance, which vendor commitments are overdue — a gap addressed directly by [Procurement & vendor management](/solutions/procurement-vendor-management). In finance, it is the collections spreadsheet that shows an invoice as outstanding two weeks after it was paid, because nobody updated the row — the exact failure mode [Finance & collections intelligence](/solutions/finance-collections-intelligence) is built to remove. In service operations, it is the ticket log that cannot show a manager which customer has been waiting longest, a job better suited to [Service & support](/solutions/service-support).
What actually fixes it
The instinct is often to add more structure to the spreadsheet: better naming conventions, a shared style guide, a designated owner. These help marginally and buy a few more months. They do not address the underlying issue, which is that a spreadsheet has no concept of a workflow — no notion that a purchase order has a defined next step, a defined owner for that step, and a deadline that should trigger an escalation if missed. A grid of cells cannot enforce sequence, and it cannot notify anyone of anything without a human remembering to look at it.
Fixing this well does not mean ripping out every spreadsheet in the business overnight. It means identifying which processes are business-critical, time-sensitive, or multi-person, and moving those specifically into a system designed to carry the process rather than merely store it. Analytical spreadsheets — the ones used for modelling, one-off analysis, board packs — can stay exactly as they are. For a structured way to make that distinction, see [our approach to how we work](/how-we-work), which starts by mapping the real process before recommending anything.
Making the call
A practical way to test whether a spreadsheet has become operational debt is to ask what happens if it disappears tomorrow. If the answer is "we would rebuild it from memory and lose a week of context," the spreadsheet is not a convenience — it is unmanaged risk sitting in your critical path. The fix is not more discipline. It is giving the process a home that was built to run it.
The spreadsheet did not fail. It did exactly what a grid of cells does. The process failed by asking a grid of cells to be a system.