Leaving spreadsheet scheduling
Most departments schedule in a spreadsheet, and the usual pitch against it is that it is primitive. It is not. It is a bad fit for four specific things, and genuinely excellent at everything else.
What a spreadsheet is good at
Showing everything at once. A grid of people against days is the right visualisation and every scheduling product is trying to reproduce it.
Unconstrained editing. Any cell, any value, immediately. No workflow, no validation, no permission.
Costing nothing and needing nobody. No procurement, no vendor, no login.
Being understood by everyone. There is no training.
Any replacement that is worse at the first and fourth will be abandoned.
The four things it cannot do
It cannot check itself. A spreadsheet does not know that moving that cell left somebody with eight hours between a night and a day shift. The rules exist only in the head of whoever is editing, and are applied as consistently as attention allows at 11pm.
It cannot distribute fairly over time. The tallies that make long-run fairness work need history, a per-person share and a window. People do build this in spreadsheets, and the result is a second sheet nobody else understands and nobody maintains after that person stops doing the job.
It cannot be the live version for twenty people. The moment it is distributed it is stale, and the real schedule becomes the spreadsheet plus an email thread. Nobody is sure which version they have.
It has no history. When somebody asks who moved that shift, there is no answer. The file has one state, the current one.
Note that all four are about scale over time rather than complexity. For one month, for one person, a spreadsheet is fine. The costs accrue.
What has to be ready
The rules, written down
This is the real work and it is not technical. Most departments have never written their rules down, because they have never had to — the rules live in the practice of whoever schedules.
Expect to discover that two senior people disagree about a rule both believed was settled. That discovery is valuable and is the main reason this step takes as long as it does.
Write them in two groups: things that must never happen, and things that should happen where possible. The distinction matters more than the wording.
Designing a fair call policy covers what a policy has to decide.
The staff categories
The list of categories the department actually uses, and who is in each. Not a standard taxonomy — the terms used locally, because those are the terms the eligibility rules will be written against.
The shift patterns
Each distinct shift as a template: name, start, end, and which categories may work it. Multi-day shifts as single spans rather than as runs of days.
A decision about opening balances
Whether past imbalance carries over, and if so from what record. Decide it explicitly and tell everyone, because the failure mode is half the department assuming their history came with them.
Equitable weekend and holiday rotation
What switching actually looks like
Build one period in parallel. Keep the spreadsheet as the live schedule, generate the same period against the configured rules, and compare.
The comparison is the useful part. Where they differ, either the rules are wrong or the spreadsheet contains a judgement nobody had articulated — and both findings improve the configuration. Switch over for the following period.
Do not migrate history. Seed the fairness balances from whatever record exists and start counting.
Common questions
What has to be ready before switching?
Four things: a written list of the rules the department actually works by, the staff categories it uses, the shift patterns it covers, and a decision about opening fairness balances. The rules are the hard part, because most departments have never written them down.
How long does it take?
The software side is short — there is nothing to install and configuration is a matter of hours. The work is writing down rules that currently live in one person's head, and that is as long as it takes to reach agreement on what they are.