Key takeaways
- Excel cannot represent a double-booking, so clashes surface through complaints rather than checks.
- Version drift starts as soon as departments keep their own copies of timetable data.
- Without an audit trail, nobody can prove which file is current or who changed what.
- A short risk review of your own files gives you evidence before you propose any change.
The clash Excel cannot see
A timetable clash is a rule violation: one teacher, two places, the same time. A spreadsheet stores the two entries as unrelated cells. No rule connects them, so no warning fires when the second entry is typed.
That is why clashes in Excel are found by people. A teacher spots the double-booking in week one, or a room fills twice after publication. Manual cross-checking can catch some of this earlier, but it is slow, and it has to be repeated after every edit.
Version drift: which file is the timetable?
The second pattern needs no bad intent. A department head saves a local copy to try some changes. An assistant keeps last term's file open for reference. Soon the same teacher's hours differ between files, and nobody can prove which version is the timetable.
Version drift matters most at decision points: publication, staffing reviews, and any dispute about what was agreed. If two files disagree, someone has to reconstruct the history by hand.
No audit trail means no answers
A spreadsheet gives planners no audit trail for timetabling decisions: no record of who changed the data, when it changed, or which version to trust. When the timetable is challenged, the planning team cannot trace the decision.
The three patterns compound each other. Drifting versions with no audit trail and no clash detection mean errors enter silently, spread between copies, and surface late.
Six signs your files are at risk
You do not need a failure to justify the review. Any one of these signals is enough to run it.
- More than one spreadsheet is treated as current
- Departments keep their own copies of timetable data
- Teacher and room clashes are found by manual checking
- Double-bookings have surfaced after publication
- People disagree about which file is authoritative
- Week-one conflicts have forced rework in a past cycle
Run the risk review
Keep it factual. The output is a map of where clash and version risk enters your process.
- List every spreadsheet used for timetable planning and who updates it.
- Mark the places where the same teacher, room, or class data lives in two files.
- Collect recent examples of clashes found late, with dates.
- Note which file wins when copies disagree, and who decides.
- Write down where manual clash-checking happens and how long it takes.
- Decide which of these risks must be fixed before the next planning cycle.
How to do this in Smootables: version history and the audit trail
Versions and changes
Edit Log
- Maths 1 moved from Mon 08:30 to Tue 10:15
- Workshop safety pinned
- Health: teacher changed from A. Chen to M. Patel
Smootables keeps the timetable in one place and records what happens to it. The Versions and changes panel lists saved timetable versions on branches, and any earlier version can be brought back with Restore this version. The current timetable is saved to the active branch first, so a restore never destroys work.
Next to it, the Edit Log tab records each change: a lesson moved from one slot to another, a swap, a pin, a teacher change, a move to the waiting area. When someone asks why their Tuesday changed, the answer is in the log instead of in someone's memory.
What to fix before you change tools
Reduce the number of live copies first, then make clash evidence visible. If manual checking is the only clash detection you have, record who does it and when, so the risk is at least owned.
The review's evidence feeds directly into data cleanup if you migrate. If you stay manual for another cycle, conflict resolution and manual timetabling alternatives are the better next reads.
Questions planners ask about Excel timetable problems
We have timetabled in Excel for years without a disaster. Are these risks overstated?
One documented case: a school of about 2,000 students spent three weeks per term timetabling in Excel and still hit week-one conflicts that forced a partial rebuild. Careful manual work reduces the risk. It does not remove it.
Does a single shared master file solve version drift?
It reduces the number of copies, and it changes nothing about the other two patterns. The file still cannot detect a clash, and it still has no record of who changed what.
What evidence should we collect before proposing a change?
Conflicting copies of the same data, double-bookings found after publication, and disputes about which file is authoritative. Concrete examples from your own school carry more weight than any general argument.