The short answer
- Spreadsheets fail at concurrency, history and scale, not at arithmetic
- The signal is two people needing the same file at once
- Move orders first, then customers, then pricing
- Clean the data before importing — a migration is the only good chance you get
- Keep spreadsheets for genuine modelling; retire them for shared records
More decorating shops run on spreadsheets than on any dedicated software, and that is not a failing. A spreadsheet is flexible, free, understood by everyone, and shaped exactly to how a particular shop works — which is more than most software manages.
They fail in specific ways rather than generally, and knowing which failure you have tells you what to replace and when.
Why they work so well
Because they impose nothing. A shop can model its own quirks — a customer with odd pricing, a job type nobody else runs, a rule that exists for historical reasons — without asking permission from a vendor.
They are also immediate. Adding a column takes seconds; requesting a field in a software product takes a support ticket and a release. For a small shop that responsiveness is genuinely valuable.
So the argument for leaving is never that spreadsheets are unprofessional. It is that specific things they cannot do have started to cost you.
When they stop working
| Failure | What it looks like |
|---|---|
| Concurrency | "Who has the file open?" — two people, one truth |
| History | A cell changed and nobody knows who or when |
| Scale | Slow, fragile, too many tabs to navigate |
| Access control | Anyone who can see it can change anything |
| Linking | Orders, customers and artwork in separate files |
| Automation | Nothing can send an email or update a status |
The first two are the ones that actually force a move. A single-user spreadsheet is fine indefinitely; the moment two people need it simultaneously, you are either taking turns or maintaining two versions that diverge.
The history failure is quieter and worse. When a price or a date changes and nobody can say who changed it, you have lost the ability to settle a question — which is exactly what you need when a customer disputes something.
A spreadsheet is a superb tool for one person and a poor one for three.
What to move first
Not everything. Move the thing where concurrency and history hurt most, which is almost always orders.
| Order | Move | Because |
|---|---|---|
| 1 | Orders and job status | Most people need it at once |
| 2 | Customers and artwork | Everything else links to them |
| 3 | Quoting and price list | Consistency between people |
| 4 | Purchasing | Depends on orders existing as data |
| 5 | Reporting | Falls out of the above |
Orders first is the same conclusion as what to automate first, and for the same reason: nothing downstream is possible while the order exists only as a row somebody typed.
Getting the data out
Spreadsheets export easily, which is their great advantage at this moment. The work is not extraction but cleaning, and a migration is the only realistic opportunity you will get.
Clean before importing
- Merge duplicate customers — far easier in a sheet than afterwards
- Standardise names, so "Eastside FC" and "eastside f.c." become one
- Drop customers with no order and no valid contact
- Fix dates into one consistent format
- Separate combined columns — one field per fact
- Remove products not sold in two years
Duplicates are the item that repays the effort most. A customer existing three times will accumulate three price levels and three histories, and reorders will start from whichever record the person happened to open.
The one-fact-per-field rule matters for anything you will later want to search or report on. A column holding "48 navy L/XL/2XL" is readable by a person and useless to a system; sizes as their own quantities are what make a reorder repeatable.
What to keep
Spreadsheets remain the right tool for some things, and moving those into software makes them worse.
Keep spreadsheets for
- Modelling — costing a machine, testing a price change
- One-off analysis nobody else needs
- Scratch work while you think
- Exports you are checking before acting
Retire spreadsheets for
- Anything two people need at once
- Anything you will need a history of
- Anything customers depend on being correct
- Anything that should trigger an action
The distinction is between thinking and recording. Spreadsheets are excellent for the first and progressively worse at the second as more people are involved.
The transition
Run both briefly, then stop — and be firm about the stopping, because a shop running two systems indefinitely has the costs of both.
A four-week move
- Week 1 — export, clean, and import; check a sample by hand
- Week 2 — new orders go into the system; the sheet is read-only
- Week 3 — finish open jobs from the sheet; nothing new added to it
- Week 4 — archive the sheet somewhere findable and stop opening it
Archive rather than delete. Keeping the old file read-only answers questions for months afterwards, and it costs nothing — but making it read-only matters, or somebody will keep it current out of habit and you will have a shadow record within a fortnight.
Watch for the reason people keep going back. If somebody returns to the sheet, the system is missing a view they need, and that is worth fixing rather than policing. The rest of the software archive assumes you left spreadsheets for the things they are bad at and kept them for the things they are good at.
What the spreadsheet was doing that you should preserve
Before retiring one, work out what it actually did well, because that is what people will miss and what will pull them back.
Usually it is a view rather than data — everything sorted the way one person thinks, on one screen, with the columns that matter to them. Software that scatters the same facts across five tabs is objectively better organised and subjectively worse to use.
Ask before you switch it off
- What do you look at first when you open it?
- What does it show that the new system does not?
- What do you do in it that would take longer elsewhere?
- What have you added to it that nobody asked for?
The last question finds the useful bits. Spreadsheets accumulate small conveniences — a colour rule flagging late jobs, a column totalling the week — and those are usually configurable in the new system if somebody knows to ask.
