One File, One Team: The Shared Spreadsheet Problems That Follow
If your team runs its contracts from one workbook on a shared drive, you know the file: something like Contracts_2026_v4.xlsx, with a link everyone on the team has. You correct the weekly hours on a few contracts and save. A colleague opened the same file earlier that morning, left it open through the invoice run, and saves after you. Your corrections are gone, and nobody notices until a client is billed at the old rate weeks later.
The usual response is a schedule for who edits on which day. It will not hold for long, because nothing went wrong with anybody's attention.
A shared spreadsheet fails in four predictable ways: concurrent edits overwrite one another; a save conflict leaves two files where there was one; no log records who changed a value; and access is all-or-nothing, so anyone who can read the sheet can also rewrite it. These are not user mistakes; they are the consequences of using a file as shared infrastructure, when a file has no concept of permissions, roles or history. The usual remedy is to keep the data and replace the file with an interface that enforces permissions and records every change.
The four failures a shared spreadsheet tends to produce
The first is the lost edit: work that was typed, saved, and is no longer there. The second is the fork: two files with almost identical names, both containing real work. The third is the unanswerable question — a rate is wrong, everyone is certain they did not touch it, and the file cannot say otherwise. The fourth is exposure: the subcontractor who needed three columns received the whole workbook, margins included.
Each has the same root. A spreadsheet is one object, opened whole, saved whole, and shared whole. Partial access, simultaneous work, and an audit trail all require it to be divisible, and it is not. That is why moving the contents of the workbook into an admin panel can address all four at once rather than one at a time.
Why simultaneous edits quietly overwrite each other
When two people open a file from a shared drive, each gets a copy in memory, and saving writes that entire copy back over whatever is on the drive. There is no comparison step, no merge, and no warning that the version being replaced is newer. The last save wins, and it wins completely.
Your whole version of the file is replaced, including the rows you corrected and every row you did not touch.
Cloud co-authoring narrows this and is worth turning on, but it does not close it. It reconciles cell-level edits well and handles structural changes badly: sorting a range or inserting rows can displace what a colleague is typing. Anyone working offline in a desktop client is back to whole-file replacement on reconnecting.
Why two people saving at once produces two files
The alternative to a silent overwrite is a conflicted copy, which most sync clients produce when they cannot reconcile two versions. You end up with Contracts_2026_v4.xlsx and Contracts_2026_v4 (conflicted copy 2026-03-16).xlsx in the same folder, both legitimate.
Both contain genuine edits and neither is a superset of the other, so resolving it means comparing four hundred rows cell by cell. In practice nobody does. Someone picks the later timestamp, renames it, and the other set of edits is discarded unread.
Once two files exist, the naming begins: _final, _v5, _USE THIS ONE. The question that follows is not rhetorical: Which version is current? A filename cannot answer it: whoever wrote _final did so in good faith that Tuesday, and someone else wrote _final_2 that Thursday.
Nothing records who changed the number, or when
A cell holds one value. It does not hold the previous value, the time it changed, or the person who changed it. When a rate is wrong, the spreadsheet offers no evidence, and the investigation becomes a conversation in which everyone is honestly uncertain.
File-level version history is a partial answer. It shows what the whole workbook looked like at points in time, so establishing who changed the rate on site 27 from $412 to $380 means opening a dozen versions and checking one cell in each. History is commonly capped at thirty days, which means an error found in a quarterly review is often older than the record of it.
Track Changes exists, but only in a legacy mode that disables tables and conditional formatting, which is why almost nobody leaves it on. The most important file in the business cannot answer the question most often asked of it.
Why a spreadsheet cannot show one person less than another
Sheet protection, hidden columns, and a workbook password look like permissions and are not. Hidden columns unhide with two clicks; sheet protection prevents accidental typing, not deliberate reading; a password holds only until the file has been opened once and saved elsewhere.
All three are properties of the file, and the file is already on the holder's laptop: the cost column, the margin column, the pay rates on the hidden tab, and the client list on the tab nobody remembers is there — permanently, including after they leave.
The workaround is to send a filtered copy, and the workaround creates the fork. The moment a supervisor receives an extract of their own sites, there are two versions of the truth and the second starts drifting that afternoon. This is where teams begin looking at purpose-built internal tools, because different people seeing different subsets of the same live data has no expression in a file.
What to give a person who only needs to read three columns
A subcontractor on a cleaning contract, for example, needs the site name, the day, and the hours for their own sites, kept current. Everything else in that workbook is either irrelevant to them or commercially sensitive.
What they should be given is a view, not a copy: a page filtered by who they are rather than by a filter someone remembered to apply. When the office changes the hours on a contract, the page shows the new hours next time it is opened. There is no file to be out of date, because there is no file.
A copy ages from the moment it is sent; a view is a window onto a record being maintained. The same row can show three columns to a subcontractor and every column to accounting.
What an admin panel gives you that a shared file cannot
An admin panel is a plain interface over the same data: a list of records, a form for editing one, and rules about who may do what. Turning an existing workbook into one starts from the structure that is already there.
Four things change. Edits apply to a single record rather than the whole file, so two people working at once affect two rows and neither overwrites the other. Fields carry rules — a date must be a date, a rate must be positive, a site must exist — so a malformed entry is refused at the point of typing. Every change can be logged with the value before, the value after, the timestamp, and the person, which turns the unanswerable question into a quick lookup. And roles can be enforced, so read-only means read-only rather than a request politely made by email. Define the rules, the log, and the roles when you build the panel, and test each one yourself before anyone relies on it.
Keeping the spreadsheet as the source and the panel as the interface
Replacing the file does not mean abandoning spreadsheets, and it should not. Finance teams model in Excel for good reasons — pivot tables, scenarios, formulas that would be tedious to reproduce elsewhere — and removing that capability trades one problem for another.
The arrangement that works splits the two jobs. Day-to-day updates, and access by anyone outside the core team, happen in the panel where the rules live. Analysis happens in a spreadsheet copied from it when needed, and everyone understands that copy to be a snapshot — quite different from a snapshot that has quietly served as the master copy for eight months.
The original workbook usually supplies the structure. Column headings become field names, the sheet becomes a table, and the validation someone set up years ago becomes an enforced rule. When you go through replacing a shared spreadsheet with an application, keep the sheet's column names in the panel, so it looks familiar to the people who used the file.
How to make the change without losing existing data
Tidy the workbook first: one header row, one row per record, no merged cells, no subtotal rows inside the data, no blank spacer rows, and no marginal notes. Any column holding two facts — Site / Manager — becomes two. Take the time to do it carefully, because it determines how clean everything downstream is.
Then take a dated copy of the file and put it somewhere nobody will edit it. That is the rollback, and it costs nothing.
Upload the tidied sheet and check that each column has been read as the right type; dates stored as text are the usual culprit. Set roles next, starting tight and widening where someone is blocked. Then run both in parallel for two weeks, with the panel authoritative and the old file left read-only for reassurance, and archive the file at the end of it. Our note on why internal tools do not need building from scratch covers the sequencing, and the mechanics of the upload are in the guide to publishing an application from an Excel file.
The change worth expecting is not speed. Entering a contract in a form takes about as long as typing it into a row. What changes is that the weeks-long gap between an error and its discovery can close, because a wrong rate can be traced through the change history. The people who shared the file stop coordinating around it and start working on their own records at the same time. And the question that used to open every Monday — Which version is current? — stops being asked, because it no longer has a plausible answer.
