Guide
The pre-publish timetable checklist: what to check before staff see it.
Before staff see a new timetable, check every per-person promise (planning time to the minute, part-timer days, job-share handovers) and every structural one (rooms, meetings, duty coverage, bell times). Staff judge a timetable by the errors they find, not by the hundreds of sessions that were right. Run this checklist before publishing and the timetable stays out of the staffroom conversation.
Updated 20 August 20266 min read
Key takeaways
- Check the per-person promises first: planning time to the minute, part-timer days, job-share handovers. These are the errors staff find in the first hour.
- Check the structural errors second: room double-bookings, meeting clashes, duty gaps. Nobody finds these until they cause a problem.
- Publish from one place, with a view for each teacher, and keep versions so "current" is never in doubt.
- Keep the written record of the agreements and trade-offs behind the timetable, for the week-five question.
Why a checklist at all
A finished-looking timetable is a wall of small promises: this teacher is released here, this class is in the hall then, this meeting fits there. In a thirty-staff primary school the promises run into the hundreds, and looking at a full grid checks almost none of them. The grid looks equally convincing whether the promises hold or not.
The checklist below is in order of damage: the things staff will find within an hour of publication come first.
Per-person checks (staff find these in an hour)
Go teacher by teacher, not slot by slot. Each person will read exactly one row of your timetable, their own, with total attention.
- Planning time: every teacher receives their full entitlement (APT, RFF, NCT, DOTT or NIT) to the minute, pro-rata for part-timers, on days they actually work
- Part-timers: no sessions, duties or meetings on non-work days, and correct start and finish times on part days
- Job-shares: both partners' days correct, a clean handover, no session left without a teacher, and each partner's pro-rata release delivered on their own days
- Dual-role staff: classroom days and specialist days match the agreed pattern, and nobody is scheduled to release themselves
- Negotiated arrangements: every documented agreement (late starts, early finishes, no-Friday-duty deals) visibly honoured
- Meetings: every attendee of every meeting is actually free at that time, including part-timers and specialists
Structural checks (nobody finds these until they hurt)
These errors survive publication because no individual owns them. They show up as a corridor collision in week two.
- Rooms: no space double-booked. Halls, libraries, STEM rooms and shared spaces used by outside providers are the usual offenders
- Staff double-booking: nobody teaching, meeting or on duty in two places at once, including specialists counted in two roles
- Specialist rotations: every class receives its full program, and no class has been dropped from a rotation after a late edit
- Duty roster: every zone covered every break, and no duty assigned to someone who is teaching, in a meeting, or not at school that day
- Fixed events: assembly, chapel, sport and interschool commitments present and not overwritten by later edits
- Bell times: session boundaries match the bell schedule, including the early-finish day if you have one
The publish process itself
How you publish decides how errors get reported and fixed. Publish one version from one system, give each staff member a view of their own week, and say clearly where the current version lives. The fastest way to lose the term is three PDF versions in circulation, each partly right.
Keep versions deliberately. When a change lands after publishing (and it will), the old version should be visibly superseded, not competing. Archive a published snapshot as well: it is your fallback pack if systems are unreachable one morning, and your evidence when memories differ.
- One named source: staff know exactly where the current timetable lives
- A view for each teacher, so each person can check their own week in under a minute
- A feedback channel with an owner: errors reported once, to the right person, fixed at the source
- A printed or exported fallback pack: current timetable, duty roster and daily plan
- The decision record: agreements and trade-offs behind this version, written down
Automate what can be checked
Everything in the per-person and structural lists can be checked mechanically, which means every item is a job for software, not a Sunday afternoon. Bell Path runs these checks while you build and again as Final Check before publishing: planning-time delivery per teacher, availability and double-booking, room clashes, meeting conflicts, rotation completeness and duty coverage, with each problem named in plain language while it is still cheap to fix. Keep the human review for what software cannot judge: whether the trade-offs are the ones your school meant to make.
Common questions
- When should the timetable be published to staff?
- After the checks pass and leadership has walked through the per-teacher views, with enough lead time before term for staff to check their own week and report anything odd. Publishing a checked timetable a few days early beats publishing an unchecked one a fortnight early and spending the fortnight on corrections.
- Who should review the timetable before publication?
- Whoever built it should not be the only checker. A second leadership reviewer walking through the per-teacher views catches assumptions the builder cannot see. The specialists and part-timers with the most complex arrangements are worth a quiet confirmation of their own rows before publication.
- What if an error is found after publishing?
- Fix it at the source, republish as a new visibly current version, and tell the affected people directly. What damages trust is not the error (staff expect a few). It is finding that the fix lives in an email while the published timetable still shows the mistake.
In Bell Path
Dozens of these checks, automated
Bell Path's Final Check checks planning time, clashes, rooms, meetings and duty coverage before you publish, and explains every issue in plain language.
See how checking worksKeep reading
How to build a primary school timetable, step by step.
To build a primary school timetable, collect every staffing fact first, place planning time and specialist rotations before anything else, then check each teacher's week before staff see it. The order you make decisions in matters more than the tool you use. This guide walks through the order experienced timetablers follow, and the mistakes that cause a rebuild halfway through the term.
How to change a school timetable without rebuilding the whole week.
To change a school timetable mid-year without rebuilding it, keep the published week as your baseline, change the underlying staffing fact rather than the cells, compare how much the new version moves, and publish one clearly current version. A staffing change does not have to mean a fresh timetable and another round of disruption.
Planning time in Australian primary schools: APT, RFF, DOTT, NIT and NCT, explained.
Planning time is the weekly release from face-to-face teaching that every Australian primary teacher is entitled to. Victoria calls it APT, New South Wales RFF, Queensland NCT, Western Australia DOTT and South Australia NIT. The name changes, but the problem is the same everywhere: release time must be delivered to the minute, every week, and someone must teach the class while you do.
School timetable generator
Bell Path builds a primary school timetable from the details you give it: staff, classes, part-time days, planning time, meetings and rooms. It then checks the result and shows you what it could and could not fit.
Choosing school timetabling software
We built Bell Path, so this is not a neutral ranking. It is our honest guide to what matters when a primary school chooses timetabling software, what to ask each vendor, and where we fit.