Somewhere in most operations there is a spreadsheet that is not really a spreadsheet. It is the dispatch board, or the job tracker, or the inventory sheet, and six people have it open right now. Someone who understood the work built it, and nothing else in the building responds to a change this fast. This page is about that specific artifact (the shared, multi-user, operational sheet), not the analysis file on one person's laptop. Those are fine. This one is load-bearing, and it fails differently.
The sheet won for a real reason
Adding a column to a spreadsheet takes fifteen seconds and no approval. Adding a field to a purchased platform takes a support ticket, a consultant, a sandbox, a release window, and often a licensing conversation. When the work changes on a Tuesday (a new customer type, a new compliance flag, a subcontractor who needs tracking differently), the spreadsheet absorbs the change on Tuesday and the system absorbs it in the spring.
That is not a failure of discipline. It is an accurate read of the available tradeoffs by people close enough to the work to know what waiting costs. Any conversation about replacing the sheet that starts from the premise that the sheet was a mistake will produce something less adaptable than what it replaced.
- The structure matches how the work is actually described, not how a vendor modeled the industry.
- Everyone can see the whole picture at once, which is exactly what a dispatch or status board needs to do.
- Exceptions get handled in a note field instead of blocking the process.
- It cost nothing to build and nothing to change.
How it fails once several people depend on it
Spreadsheet failures at scale are not crashes. They are quiet, plausible-looking wrong answers. Every one of these leaves a file that still opens fine.
Edit conflicts and lost updates
Two people update the same job status within the same minute. One update survives. In a desktop file the loser gets a conflict copy nobody opens; in a cloud sheet the last write simply wins, with no notification. Nothing is flagged, because from the tool's point of view nothing went wrong. A human typed a value and it was saved.
A sort applied to one column
Someone selects a single column, sorts it, and every row is now scrambled against every other row. Job numbers no longer match the addresses beside them. If the sheet is large and the mismatch is not obvious, this can survive a week, and by then the correct pairings are only recoverable from version history, if it goes back far enough.
Filters that change what other people see
In a shared file, a plain filter is global. One person narrows the view to today's work and everyone else's screen changes underneath them. Rows do not disappear from the data, but they disappear from attention, and work nobody can see is work nobody does. Filter views help, but the default action is still the destructive one.
Formulas replaced by pasted values
Someone copies a block of cells from an email or another tab and pastes it over a calculated column. The formula is gone. The numbers still look reasonable because they were correct when they were pasted, and they stay frozen while everything feeding them keeps moving. This is the most common cause of a report that was right last month and is subtly wrong now.
Duplicate tabs as informal backups
Because people know the sheet is fragile, they protect themselves. A tab named with last Thursday's date appears, then a copy in someone's own drive, then a version emailed to a manager. Each copy is a reasonable act of self-defense and each one is a fork. Within months, which numbers are current has a different answer depending on who you ask.
Permissions that are all or nothing
Access to a spreadsheet is access to the file. There is no supported way to let a subcontractor see the three rows that belong to them, or to let a warehouse temp update quantities without also seeing margins and pay rates. The workarounds (a separate export, a linked copy, a manually maintained extract) all mean someone is doing data entry twice. This is usually the constraint that forces the decision, because it does not degrade gradually. It is either possible or it is not.
Failure map
Most of these have a cheap mitigation worth doing regardless of what you eventually build. The last column is what actually removes the failure mode.
| Failure | What causes it | Interim fix | Real fix |
|---|---|---|---|
| Lost update | Two people edit the same row within the same save window; last write wins silently. | One owner per tab, and a status column that records who changed it and when. | Row-level records with per-field edit history and a conflict warning at write time. |
| Scrambled rows | A sort applied to a selected column instead of the full range. | Convert the range to a proper table object and protect the header row. | Sorting becomes a view setting, not a mutation of the stored data. |
| Hidden work | A global filter narrows the view for every user at once. | Train the team to use personal filter views; lock the plain filter where possible. | Per-user views and saved queries that cannot affect anyone else's screen. |
| Frozen numbers | A paste overwrites a calculated column with static values. | Protect formula columns and move calculations to a separate reporting tab. | Calculated fields live in the application layer and are not editable by users. |
| Competing copies | People duplicate tabs and files because they do not trust the shared version. | One canonical file, a dated archive folder, and a rule that copies are read-only. | A single stored record with real backups, so private copies stop being rational. |
| Over-broad access | Sharing is file-level, so partial visibility is impossible. | A separate export or linked view for outside parties, refreshed on a schedule. | Row-level permissions tied to the user's role, relationship, or assignment. |
What buys time, cheaply
A shared sheet under strain is rarely an emergency, and treating it as one leads to a rushed replacement that fits worse than the spreadsheet did. Two or three days of structural work usually holds it together for another year, which is enough time to make a good decision instead of a fast one.
- 1
Split entry from reporting. Data goes in one tab with one row per thing and no merged cells; every chart, pivot, and summary reads from it and nothing writes back.
- 2
Protect the columns nobody should type into (formulas, IDs, timestamps) and leave the rest open. Restricting everything just moves the work into private copies.
- 3
Replace direct editing with a form for the highest-volume entry path. Field updates and intake are usually the two that matter, and a form removes most structural damage in one step.
- 4
Give every tab a named owner, written at the top of the tab. Shared ownership of a shared sheet is how it drifts.
- 5
Turn on version history and confirm how far back it actually goes, then set a dated archive copy on a schedule so a bad week is recoverable.
- 6
Write down the rules that currently live in people's heads: what makes a job urgent, when a row can be deleted, what the blank status means. That document is the first real specification for whatever comes next.
None of this is wasted if you later replace the sheet. The tab owners become the people you interview, the form fields become the intake screen, and the written rules become requirements you did not have to rediscover.
When the interim fixes stop working
Row count is a bad signal. The useful signals are about trust, and about who is allowed to touch the file.
- People maintain private copies because they no longer believe the shared version is current.
- Someone spends a recognizable part of each week reconciling the sheet against another system.
- A person outside the company needs to see part of the data and there is no safe way to show it.
- The last three incidents were caused by the sheet, and each was found by a customer rather than by the team.
- One person is the only one who understands the formulas, and the operation pauses when they are out.
- New hires are trained on the workarounds before they are trained on the work.
Two or three of these together mean the interim fixes have already been spent. The replacement does not have to be large. The first version usually needs to cover one workflow, keep the same vocabulary, and be visibly faster than the sheet at the thing people do most. Everything else stays in the spreadsheet while that runs in production.
A trades services business moved job management, dispatch, and mobile field updates onto a flexible bridge stack in six weeks, then used that period to validate workflows and clean legacy data with real users before the permanent platform was designed.
The history in the sheet is the valuable part
The columns describe how the work is supposed to run. The rows describe how it actually ran. Those are different documents, and the second is harder to obtain and easier to throw away. A year of real jobs shows which statuses are used and which were abandoned, how often a job is rescheduled before it completes, which fields are always blank, and what people write in the notes column when the structured fields cannot hold what happened.
That notes column is the most useful thing in the file. Every recurring pattern in it is a requirement the spreadsheet could not express. Read it before designing anything.
Expect the data to be messy, and expect that to be informative rather than embarrassing. Dates stored as text, three spellings of the same customer, and a status only one person uses are all evidence of where the structure did not fit. Fix what blocks the migration, record the rest, and resist making the history look tidier than the operation actually was.
Common questions
- How many users can a shared spreadsheet realistically support?
- There is no fixed number, because the strain comes from concurrent editing rather than headcount. A sheet twenty people read and two people update is stable indefinitely; a sheet five people update simultaneously during a dispatch window will produce lost updates within weeks. Count simultaneous editors during your busiest hour, not names on the share list.
- Will moving to Google Sheets or Excel online fix the conflicts?
- It fixes the worst version: the conflict copy and the file locked by someone who went to lunch. It does not fix silent lost updates, destructive sorts, overwritten formulas, or file-level permissions. Cloud spreadsheets are a genuine improvement and they buy time, but they address collaboration mechanics rather than data integrity.
- Is a database the right next step, or should we buy a platform?
- It depends on whether your process is ordinary or distinctive. If the workflow in the sheet closely matches what an established product does, buy it and adapt. If the sheet exists precisely because no product handled the way you actually work, a purpose-built system will fit better and cost less to operate than a platform you have to fight. The written rules from your tabs are what make that call answerable.
- How do we let a contractor see only their own rows?
- Not within the spreadsheet itself. The usual workarounds are a filtered export, a linked copy, or a separate sheet maintained by hand, and each one means the same data is being entered or refreshed twice. Row-level access tied to who someone is and what they are assigned to requires a real data layer, which is why partial visibility is so often the requirement that ends the spreadsheet.
- Can we keep the spreadsheet after building something else?
- Keep it for analysis and ad hoc questions, which is what spreadsheets are excellent at. Do not keep it as a second place where operational data is entered or edited. If the new system is slow enough to change that people go back to the sheet for daily work, the problem is the new system's release cadence, not user resistance.
- What should we do first if we are not ready to replace it yet?
- Split entry from reporting, protect the formula columns, and give every tab a named owner. Those three take a couple of days and remove most of the destructive failure modes. Then start writing down the rules people apply by hand, because that document is both an operating manual today and the specification later.