Why franchise launch spreadsheets stop working past ten stores
Spreadsheets are excellent at tracking one store launch and structurally bad at tracking twenty. A look at the five specific failure modes, and what to do about each.
Nobody chooses a spreadsheet for franchise launch tracking after evaluating alternatives. It is where the first store was tracked, it worked, and it stayed. That history matters, because it means the spreadsheet is rarely questioned until something expensive has already gone wrong.
Spreadsheets are genuinely good at this job for a while. The break is not gradual — it is a set of specific structural failures that arrive at roughly the same point, somewhere between the eighth and fifteenth concurrent launch.
1. Write access and accuracy are the same setting
A spreadsheet gives you one lever: can this person edit the file or not. But the people who know whether a task is done are the people on site, and the people you can afford to trust with the master file are a much smaller group.
So you pick. Give everyone edit access and the file gets accurate for a while, then someone sorts a column without selecting the adjacent ones and quietly corrupts three months of data. Or restrict access, and the file is now updated by one coordinator relaying status from WhatsApp — which means it is always somewhere between a day and a week behind reality, and its accuracy depends entirely on one person's inbox.
2. There is no such thing as an approval
A spreadsheet can record that Legal approved something. It cannot require it. The difference is the entire point of an approval.
In practice this means a cell reading "Approved — Legal" was typed by whoever was updating the sheet, not by Legal. It might be true. It might be a coordinator's summary of a phone call. When a licence turns out not to have been granted and the store cannot open, the sheet offers no way to find out which. Real department approvals block the task from closing and record who signed off and when — that is a different data structure, not a stricter convention.
3. Nobody can see just their own work
A launch tracker with twenty stores and sixty rows each is twelve hundred rows. The contractor coordinator needs eleven of them. The Legal reviewer needs a different nine.
Filters exist, but they are a per-person discipline, not a property of the file, and they reset. The predictable result is that people stop opening the sheet and start asking someone. That question is the WhatsApp thread, and the WhatsApp thread is now the real system of record — an unsearchable one, with no structure and no history.
4. Dates are typed, not derived
In a spreadsheet, every date is a value someone entered. When an opening date moves by three weeks — which happens constantly — the forty downstream dates for that store do not move. Someone has to move them, by hand, without missing any.
They will miss some. The sheet then contains a mixture of dates that reflect the new plan and dates that reflect the old one, with nothing distinguishing them. Every date in the file is now suspect, and the practical response is to stop trusting dates at all and go back to asking people.
5. There is no history
A cell holds its current value. When a launch slips and someone asks what happened, the sheet can tell you the task is late. It cannot tell you when it was assigned, when it was first marked at risk, who changed the date, or how many times it moved.
Version history in the underlying file technically contains this, in the sense that a disk image technically contains a deleted photo. Nobody is reconstructing a timeline from revision diffs across twelve hundred rows.
This is why launch postmortems at spreadsheet-run companies tend to conclude that the delay was caused by whoever is least able to defend themselves in the meeting.
What actually fixes it
The fix is not a better spreadsheet, and it is usually not a general project management tool either — those solve the access and history problems but leave you building the franchise launch process yourself out of boards and automations.
What you need is narrower than a work platform and stricter than a document:
- A reusable master checklist, so the fiftieth launch starts from the same plan as the fifth
- Per-person and per-department views, so nobody has to filter twelve hundred rows to find their nine
- Approvals that block completion rather than describe it
- Dates derived from the opening date, so moving the launch moves the plan
- An append-only activity trail, so the postmortem is a query and not an argument
That list is a fair description of what FranchiseLaunch is. If you want the underlying checklist first, start with the full store launch checklist.
