Almost every growing organisation we meet runs on spreadsheets somewhere. There is nothing wrong with that. A spreadsheet is the fastest way to model a process, capture a list or share a calculation. Problems start when the spreadsheet quietly becomes the operation — the single document that bookings, stock, jobs or staff depend on every day.
The transition is usually invisible. One sheet becomes three. A column becomes a tab. A tab becomes a copy emailed each morning. By the time anyone notices, the business is paying for the spreadsheet in small ways: duplicated entries, awkward handovers, version confusion and a quiet anxiety about what would happen if the file were lost.
Signs the operation has outgrown the sheet
- Two people regularly edit the same file and reconcile by hand.
- Decisions wait on someone exporting, filtering and emailing a snapshot.
- New starters are trained on the spreadsheet itself, not the process.
- There is a colour key, and the colour key has rules.
- Nobody is fully sure which version is current.
Any one of these is fine in isolation. Three or four together usually means the spreadsheet has become load-bearing — and load-bearing spreadsheets fail quietly, often at the worst time.
What to do before reaching for new software
The instinct is often to buy a platform. That is sometimes right, but it is rarely the first step. We usually recommend three things first.
- Write down what the spreadsheet is actually doing. Not what it stores — what it decides. The decisions are the real process.
- Separate reference data (relatively stable) from operational data (changes daily). They almost always belong in different places.
- Identify the single handoff that causes the most friction. That is usually the highest-value thing to redesign first.
When a bespoke system makes sense
Off-the-shelf software is the right answer for common, well-understood problems. A bespoke operational layer becomes worth considering when the way the business works is part of its competitive advantage — when shaping the system around the operation costs less, long-term, than reshaping the operation around the system.
Either way, the work begins with the same step: mapping the operation as it really runs today, not as anyone wishes it ran. Everything else follows from that.