Getting off the spreadsheet

Small agencies schedule in spreadsheets for a rational reason: commercial scheduling packages tend to carry annual minimums tied to fleet size, which prices out anyone running fewer than about ten vehicles. Given that choice, a spreadsheet is not a failure of professionalism. It is the correct decision under the constraints.

But spreadsheets have specific, predictable failure modes, and it is worth naming them precisely rather than gesturing at modernisation.

What actually goes wrong

There is no single copy

The moment a schedule is emailed, it forks. The dispatcher's copy has today's substitutions. The manager's copy has next quarter's plan. The printed one at the counter has neither. Nobody is wrong; there is simply no answer to the question 'what is the schedule'.

Changes leave no trace

When a trip time moves, the old value is gone. Six months later, when a rider complains or a funder asks, there is no way to reconstruct what was published in March or who changed it.

The schedule does not know about the equipment

A spreadsheet will happily assign a run to a vehicle that is out of service for an inspection, because the maintenance calendar is a different file, probably kept by a different person, possibly on paper.

It all lives in one person's head

This is the serious one. The spreadsheet is legible only to the person who built it. The formulas encode assumptions nobody wrote down. When that person retires — and in this sector they are often close to retiring — the agency loses not a file but an institution.

The knowledge is not missing. It is just held by one person, and it was never anybody's job to write it down.

What to look for instead

The trap is to jump from a spreadsheet to a system built for a full-time professional scheduler at a large agency. Those systems assume daily use. Your staff will touch scheduling a few times a year, at a service change, under time pressure, having forgotten everything since last time. That is a completely different design problem.

• Guided flows over blank canvases. If the software cannot walk somebody through a service change without a manual, it will not get used.
• A visible diff before anything publishes. Show me exactly what changes, in words, before I commit.
• Conflict detection in plain English. 'Vehicle 4 is booked for inspection that morning', not error code 4021.
• A practice mode. Somebody doing this twice a year needs a place to be wrong without consequences.
• An export you can walk away with. If you cannot get your schedule out, you do not own it.

Moving without a procurement

You do not have to migrate everything at once, and you should not. A sequence that works:

1. Pick one line — ideally the one that changes most often, because that is where the pain is.
2. Rebuild only that line in the new system while the spreadsheet stays authoritative.
3. Run both for one service change. Compare the outputs. Find out what the spreadsheet knew that you forgot to describe.
4. Switch that line over, and only then start the next.
5. Keep the spreadsheet, read-only, for a year. It costs nothing and it will settle arguments.

If a vendor tells you the migration has to be all-at-once, that is a statement about their software, not about your agency.