Somewhere in your business there is a spreadsheet that matters more than any system you actually pay for. It might be called Job Tracker FINAL v7, or Quotes Master 2026, or just Schedule. It was probably built in an afternoon, years ago, to solve a problem your software couldn't. And it worked — so well that the whole operation quietly grew around it.
Then the person who built it goes on leave. Or resigns. Or is simply at the dentist on the morning a formula breaks, a column gets sorted without its neighbours, or the file won't open at all. That's usually the day a business discovers how much it depends on one file and one brain.
This post is about finding that spreadsheet in your business, honestly assessing the risk it carries, making it safer this week, and deciding — calmly, not in a crisis — whether it should stay a spreadsheet at all.
First, a Defence of Spreadsheets
Let's be clear: spreadsheets are not the villain here. Excel is one of the most successful pieces of business software ever written, and for good reason. It's flexible, it's universally understood, it needs no procurement process, and the person closest to the problem can build exactly what they need in an hour. For analysis, modelling, one-off calculations and quick lists, a spreadsheet is often the right tool.
The problem isn't the spreadsheet. The problem is the job it's been given. In most growing businesses, the critical spreadsheet exists because two systems don't talk to each other — the CRM doesn't know what the job management tool knows, the accounting software doesn't know what the quoting tool knows — so someone built a bridge. We've written before about why businesses end up running on six systems that don't talk to each other, and the critical spreadsheet is almost always the symptom of that same disease.
A spreadsheet acting as a bridge between systems is doing the work of a database, a workflow engine and an integration layer — with none of the protections those things normally come with.
How to Find Your Critical Spreadsheet
You probably already know which file it is. If you're not sure, ask your team these questions:
- “If this file disappeared right now, what would stop?” Invoicing? Scheduling? Payroll prep? Quoting? If the answer is “most of our week”, you've found it.
- “Who understands how it works?” If the answer is one name — and everyone says the same name — that's a single point of failure wearing a lanyard.
- “Where does it live?” A desktop, a USB stick, a personal OneDrive, an email attachment that gets forwarded around? Each of those is worse than the last.
- “What feeds it, and what does it feed?” If data is manually copied into it from one system and manually copied out of it into another, it's not a spreadsheet anymore. It's middleware. Unmonitored, unversioned, hand-cranked middleware.
Most businesses with 5–50 staff have at least one file that ticks every box. Larger businesses often have several, one per department, each guarded by its own keeper.
What the Risk Actually Looks Like
“Spreadsheet risk” sounds abstract until you break it into the specific ways it goes wrong. Here's what each failure mode looks like in practice:
| Failure Mode | What Actually Happens | Warning Signs |
|---|---|---|
| Key-person dependency | The one person who understands the formulas is away, and nobody else can safely update the file. Work queues or gets done wrong. | Everyone names the same person when asked how it works |
| Silent corruption | A column is sorted without the rest of the sheet, a formula is overwritten with a typed value, a row is deleted. Nobody notices for weeks — then the numbers don't reconcile. | “That figure looks wrong” conversations; manual re-checking before anything important |
| No version history | The file lives on a desktop or shared drive with no history. When something breaks, there's no way to roll back to yesterday. | Filenames like v7_FINAL_USE_THIS_ONE |
| No access control | Everyone who can open the file can change — or export — everything in it, including client lists, pricing and margins. | The file is emailed around or sits in a folder everyone can edit |
| No backup | The only copy is on one machine. A failed drive, a ransomware incident or an accidental deletion takes the business process with it. | Nobody can say where a second copy lives |
| Scaling collapse | What worked at 200 rows grinds at 20,000. Two people can't edit at once. The “system” becomes the bottleneck for growth. | “Don't open the tracker, Sarah's in it” |
Notice that most of these aren't dramatic. Spreadsheet failures are rarely a single catastrophic event — they're a slow accumulation of small errors, re-checking, and dependence on one person's memory. The cost shows up as hours, not headlines, which is exactly why it goes unaddressed. It's the same dynamic we described in why you find out whether a job made money a month too late: the information exists, but the way it's held makes it slow, fragile and dependent on manual effort.
The spreadsheet isn't the single point of failure — the person is. A file can be backed up in minutes. The knowledge of why column M multiplies by 1.1 “except for the Henderson jobs”, which rows are safe to delete, and what the colour coding means lives in one head. Annual leave, resignation or a bad flu turns that head into an outage.
Assess the Real Risk: Three Questions
Not every important spreadsheet deserves a project. Score yours honestly against three questions:
1. What stops if it's unavailable for a week?
If the answer is “a report is late”, the risk is low. If the answer is “we can't schedule jobs, invoice clients or pay suppliers accurately”, you're running a business-critical system on a file format designed for personal productivity.
2. How quickly would an error be noticed?
A broken formula that produces an obviously wrong number is annoying. A broken formula that produces a plausible wrong number — a quote 8% under cost, a schedule missing one job — is far more expensive, because it survives long enough to reach a client or the ATO.
3. Could a second person run it tomorrow, cold?
Not “could they open it” — could they update it correctly, knowing which cells are inputs, which are calculated, and what the unwritten rules are? If no, every day of its owner's leave is a day of accumulated risk.
High marks on all three means this file deserves the same treatment you'd give a server: backup, access control, documentation and a succession plan.
Make It Safer This Week (Even If Nothing Else Changes)
You don't need a new system to remove most of the acute risk. These steps take a few hours in total and are worth doing even if the spreadsheet stays forever:
- Move it into SharePoint or a proper shared location. A file in SharePoint gets automatic version history — you can roll back to any previous version in two clicks — plus co-authoring, so two people editing no longer means two conflicting copies. Our guide to SharePoint vs OneDrive explains which is right for a shared business file (short answer: SharePoint, because it belongs to the business, not a person).
- Get it into your backup regime. Version history is not a backup — if the account is compromised or the file is deliberately deleted, history can go with it. Make sure the file's location is covered by a real, tested backup, the same way the rest of your managed IT environment should be.
- Restrict who can edit. Most people who use the spreadsheet only need to read it. Set edit rights for the two or three people who maintain it, read-only for everyone else. This single change prevents the majority of silent-corruption incidents.
- Protect the formula cells. Excel lets you lock calculated cells so only input cells can be changed. Twenty minutes of sheet protection stops the classic “typed a number over the formula” failure.
- Document it — one page is enough. What the file is for, what feeds it, what it feeds, which cells are inputs, what the colour coding means, and the unwritten exceptions. Store the page next to the file, not in the owner's head.
- Run a handover drill. Have a second person perform one full update cycle while the owner watches but doesn't touch the keyboard. You'll find the undocumented steps within ten minutes. Fix the documentation, then repeat quarterly.
Do these six things and the spreadsheet stops being an emergency waiting to happen. What remains is the slower, structural question.
Should It Still Be a Spreadsheet at All?
Once the acute risk is handled, assess whether the file is doing a job a spreadsheet should do. The honest options, in rough order of cost and disruption:
Option 1: Keep it, hardened. If the spreadsheet is genuinely a calculation or analysis tool — not a bridge between systems — then a well-protected, documented, backed-up spreadsheet with a trained second owner is a perfectly legitimate end state. Don't replace things that work.
Option 2: Integrate the systems it bridges. If the spreadsheet exists only to carry data from system A to system B, connecting those systems directly may eliminate it. This keeps your existing tools but adds integration cost and maintenance. We've covered the trade-offs in detail in should you integrate your business systems, or replace them?
Option 3: Adopt an off-the-shelf tool. If the spreadsheet is really a job book, a CRM or a scheduler in disguise, a purpose-built product may do the job with proper access control, history and multi-user editing built in. The trade-off: you adapt your process to the tool, and per-seat pricing adds up as you grow.
Option 4: Build a system around how you actually work. If the spreadsheet survived every off-the-shelf tool you've tried, that's usually because it encodes how your business genuinely operates — and generic software didn't. That's the case where a custom-built operations platform earns its keep.
iTec HQ is our answer to option four: an operations platform we build around how your business already works, replacing the spreadsheet glue between your CRM, job book and inbox with one system. You run only the modules you need, it isn't priced per seat, and most builds are live in two to four weeks.
See iTec HQ →Which option is right depends on how central the spreadsheet is, how fast you're growing, and how much of your process is genuinely unique. There's no universally correct answer — but there is a universally wrong one: doing nothing and hoping its owner never takes leave.
The Bottom Line
Every growing business accumulates a spreadsheet that quietly becomes infrastructure. That's not a failure — it's a sign that someone cared enough to solve a problem the software couldn't. The failure is leaving it in that state once the business depends on it.
This week: find the file, move it somewhere with version history, restrict editing, protect the formulas, write the one-page guide, and train a second person. This quarter: decide honestly whether it should stay a spreadsheet, become an integration, or grow into a proper system.
The best time to have that conversation is any day its owner is in the office — because the worst time is the day they aren't.