When a spreadsheet stops being enough

When a spreadsheet stops being enough

A spreadsheet is one of the most useful tools ever put in front of a business. It is quick, free-form, and it asks nothing of you before you start typing. Most companies keep their first list of customers, orders, or stock in one, and they are right to. The problem is never the spreadsheet itself. The problem is the day it quietly stops being a private tool for one person and becomes the shared system that several people depend on. That change happens without an announcement, and the failures that follow are specific enough to name.

If you can recognise the signs, you can decide to move before a mistake forces the decision for you. None of the failures below is a reason to feel foolish. Each one is simply a spreadsheet being asked to do a job it was never built for: to be the single, shared, trusted record for a team. Here are the signals that a shared system is overdue, and what each one is actually telling you.

Two people cannot safely edit it at once

The first sign is the file named budget_final_v3_FINAL.xlsx. It exists because two people opened the same file, both made changes, and only one set of changes survived. Someone then made a copy to be safe, and now there are two versions of the truth and no way to tell which is right.

Managing simultaneous changes is a genuinely hard problem, and it is the reason databases exist. The field that studies it, concurrency control, exists so that "concurrency control ensures that correct results for concurrent operations are generated, while getting those results as quickly as possible" [3]. A spreadsheet shared over email or a drive has almost none of this. When you find yourself coordinating who is "in the file" right now, or reconciling two copies by hand on a Friday afternoon, the tool has already been outgrown. A shared system lets several people work at the same time without overwriting each other, because that is the first thing it is built to do.

The same fact is stored in more than one place

Watch for a customer's phone number living in the orders sheet, the invoices sheet, and the mailing-list sheet. When it changes, you have to remember to change it in three places, and you will not. Soon the three copies disagree, and nobody can say which is current.

The principle a shared system is built around is that "every data element is mastered (or edited) in only one place" [1]. One record for each customer, edited once, referenced everywhere else. A spreadsheet has no way to enforce this — copying a value into a new column is the easiest thing in the world, and every copy is a future contradiction. We wrote about this more fully in what one customer record actually means. If your team spends time asking each other which number is right, the cost is already real; see also why your team asks the same question twice.

Nothing stops a wrong entry going in

A spreadsheet cell will accept anything. A date typed as text, a price with a stray letter in it, a status spelled three different ways, a blank where a value is required. The sheet does not object, because it has no concept of what belongs in that column. The error sits there quietly until a formula returns nonsense or a report is wrong in front of a customer.

This is the difference between holding data and protecting it. Data integrity is "the maintenance of, and the assurance of, data accuracy and consistency over its entire life-cycle" [4], and it is something a system does actively — checking each entry against rules for what that field is allowed to contain. A spreadsheet cannot do this in any serious way. When you notice that the accuracy of your numbers depends entirely on everyone being careful all the time, you have found a failure, because people are not careful all the time.

A reference points at something that no longer exists

Most real data is relational: an order belongs to a customer, an invoice belongs to an order, a task belongs to a project. In a spreadsheet these links are held together by a shared ID typed into two sheets, and nothing guarantees the link is sound. Delete a customer row and their orders are still there, now pointing at a customer who no longer exists. Renumber some rows and half the links quietly point at the wrong thing.

A real system enforces what is called referential integrity, which is "a property of data stating that all its references are valid" [2]. It will not let you delete a customer who still has orders, or attach an invoice to an order that is not there. A spreadsheet offers no such protection. If you have ever found orphaned rows — records attached to a parent that has vanished — you have seen exactly the failure this rule exists to prevent.

You cannot tell who changed what, or when

One morning a total is different from yesterday and nobody knows why. A discount was applied, a row was deleted, a figure was overwritten — and the spreadsheet keeps no honest history of any of it. You are left reconstructing events from memory and blame.

A shared system keeps a record of every change: who made it, what it was, and when. This is not bureaucracy; it is how a team resolves a disagreement with facts instead of recollection, and how you answer a customer who says a figure was different last week. We covered why this matters in the audit trail nobody thinks about. When you find yourself unable to answer "who changed this and when", the spreadsheet has stopped being trustworthy as a shared record.

Everyone can see and change everything

A spreadsheet is all-or-nothing. If someone can open it, they can see every salary, every margin, every customer, and they can edit any of it — including the cells they should never touch. As a team grows, this stops being acceptable long before anyone admits it. You start keeping a "real" version separate from the one you share, which puts you straight back into the problem of two versions of the truth.

A shared system lets you decide who can see what and who can change what, per person and per kind of data. That is not distrust; it is the ordinary structure of a business where not everyone does the same job. We looked at this in why permissions matter as a team grows.

The workarounds have become the work

The final sign is the most telling. Someone "owns" the master file. There is a ritual for merging everyone's copies. There is a colour code only two people understand. There is a weekly hour spent tidying up what the week broke. None of that is the business; all of it is scaffolding holding a spreadsheet in a role it cannot fill. When the effort of keeping the sheet usable rivals the work the sheet is supposed to support, the decision has already been made — you are just paying for it in time instead of tools.

What moving actually buys you

A shared system is not simply a bigger spreadsheet. It is a different kind of thing: one record for each fact, rules about what each field may hold, links that cannot dangle, a history of every change, and control over who can do what. Those five properties are precisely the five failures above, turned the right way up. This is the ground we covered from the other direction in the spreadsheet that outgrew itself.

When a business reaches this point, the honest move is not to buy the largest system available. It is to move the shared record — customers, deals, orders, conversations — into something built to be shared, and to keep the spreadsheet for what it is still excellent at: private, one-off analysis. 360REV is built around a single record for each customer that the whole team works from, with that history and those permissions included rather than bolted on. The test of any such system is simple: does it turn the five failures above into things you no longer have to think about.

You do not need to wait for a disaster to decide. The signs are specific, they arrive in roughly this order, and once you can name them you can act on the second or third rather than the fifth. A spreadsheet stopping being enough is not a failure of the spreadsheet. It is a sign the business grew.