A spreadsheet is a good tool for a 40-piece install, and pretending otherwise is how software vendors lose credibility with people who actually run projects.
The interesting question is not whether spreadsheets work. It is which specific properties stop holding as a project grows, and how to notice you have crossed that line before the install window rather than during it.
Six properties, in roughly the order they fail.
1. Concurrency during a container unload
A container unload is the one moment where several people need to write to the same record at the same time. A receiver at the door, a second person counting, a supervisor logging damage.
A shared spreadsheet handles this badly in a particular way: it does not error. The last save wins, quietly, and the count somebody entered twenty minutes ago is gone with no indication that it ever existed.
The failure is silent, which is why it is usually discovered at the end of the project during reconciliation rather than on the day. By then the container is unloaded, the people who were there have moved on, and the only recovery is a physical recount.
What replaces it is not "a database" in the abstract. It is that each transaction — this line, this quantity, this operator, this timestamp — is recorded separately, so two people counting at once produce two records rather than one overwrite.
2. Location that stays true after something moves
Every project spreadsheet has a location column. It is accurate the day it is filled in and decays from there, because the spreadsheet has no connection to the physical move.
Someone relocates a pallet to make room for an inbound container. The spreadsheet does not know. Three weeks later a picker goes to the recorded location, finds nothing, and either searches or reports it missing.
The property that matters is that the move updates the record — the location is a consequence of the transaction rather than a field somebody remembers to edit. That is also why "we'll just be disciplined about updating it" does not survive a busy week: it relies on the least reliable step being done under the most pressure.
3. Photographs attached to the piece they document
Damage photographs are taken on a phone. On a spreadsheet-run project they then live in a camera roll, a group chat, or a shared drive folder named by date.
Six weeks later, when a vendor disputes a claim, someone has to find the photo of that specific credenza. If the photo is not attached to a record that identifies the piece, the receipt, the timestamp and the operator, then in practice it is not evidence — it is a picture of a damaged credenza that could have been taken anywhere.
This is the property with the clearest financial consequence. The cost of the failure is not administrative; it is the recovery you do not get from the carrier or the vendor.
4. Stopping a damaged piece from shipping
This is the one that spreadsheets genuinely cannot do, at any level of discipline.
A highlighted row is a message to a human who might read it. It does not stop a picker from picking, and on the day a project is loading three trucks the picker is not reading the damage tab.
Preventing the ship requires enforcement in the path of the transaction: a location status that refuses the move, a held quantity that removes it from availability, a task that blocks rather than completing. Those are system properties, not process properties, and they are the reason a hold in a WMS and a hold in a spreadsheet are not the same word.
5. Chain of custody
"Who did what, and when" is answerable on a spreadsheet only by version history, and only in a weak form: it tells you which account changed a cell, not which operator physically counted the pallet.
On a small job this rarely matters. On a large one it matters twice — once when reconciling a variance, and once when a client asks a pointed question about how a damaged piece reached their site.
An operator identity and a system timestamp on the transaction is not bureaucracy. It is the difference between a project where variances get explained and one where they get absorbed.
6. Ownership of the next step
Spreadsheets imply ownership with a name in a column. They cannot express state.
There is no difference, in a cell, between "assigned and in progress", "assigned and blocked because the piece is damaged", and "assigned to somebody who left". All three look the same.
Assigned tasks with a status — including a blocked status with a reason — turn that into visible work. The blocked state is the valuable one: it is what lets an operator stop and escalate rather than improvising a number to close the row.
Signals you have crossed the line
Rather than a SKU threshold, watch for these. Two or more, consistently, and the spreadsheet has stopped being the cheap option:
- Somebody's full-time job is now maintaining the tracker rather than running the warehouse.
- You reconcile a physical count against the sheet more than once per project.
- A client asks a status question and the honest answer requires walking the floor.
- Damage photographs have to be hunted for across more than one system.
- Room or floor allocations are re-derived because the original tagging was not trusted.
- The install schedule slipped and updating the sheet took more than an hour.
- A damaged piece has shipped to a site at least once.
That last one is worth weighting heavily. It is the only item on the list that a client sees.
What good looks like on the other side
Moving off a spreadsheet is not about replacing the sheet with a fancier sheet. It is about acquiring the properties above:
- Transactions recorded separately, so concurrent work does not overwrite itself
- Location as a consequence of the move rather than a remembered edit
- Evidence attached to the piece, the receipt and the operator
- Holds the system enforces rather than flags
- Operator identity and timestamps on every action
- Work as assigned tasks with a real blocked state
- Destination, room, floor, kit and sequence on the line itself
- A read-only client view that removes the weekly export entirely
If you are weighing the move, the spreadsheets to WMS guide covers the transition mechanics, and the FF&E and project logistics page shows how these properties are modelled for project work specifically.