Class schedules
Making a class schedule is not a layout task. It is a constraint problem wearing a grid.
Most schedules get built the same way: block out a week in summer, print the class lists, and start filling a grid with the important subjects first. By day four it is eighty percent full and looking good. On day six it collapses, because the only Physics teacher is also the only person who can cover Year 11 Chemistry and both need period three on Tuesday.
That collapse is not bad luck. It is the predictable result of building in order of importance rather than in order of constraint.
Add up the weekly periods every class needs. If that exceeds the slots in your week, no schedule exists — you have asked for more teaching than the week contains, and no rearranging will fix it.
Then check each subject: periods needed times number of classes, against the total available time of the teachers qualified to teach it. If demand exceeds supply you need another teacher or fewer periods. Ten minutes of arithmetic here is worth four days of rearranging later.
A lesson that can only happen in the science lab, taught by the only qualified teacher, who is part-time and unavailable Fridays, has almost no valid slots. Place it while the grid is empty and it fits. Place it on day six and it does not.
Maths, teachable by any of four staff in any general classroom, has hundreds of valid slots and will fit around whatever is already there. Importance and difficulty are different axes, and only one of them should drive the order.
Giving your strongest teacher every top set loads them to capacity while a colleague sits idle — and makes the remaining placement problem much harder than it needed to be. Spread first, optimise for preference later if the constraints leave room.
Scanning a printed grid for double-bookings is precisely the task human attention is worst at. Check every teacher, every class and every room against every slot. One clash reaching publication costs more credibility with staff than a week of delay would have.
Only a very small one. The demo is capped at two classes, five subjects and three teachers, because it exists to show how the constraint engine works rather than to replace scheduling software. It will show you exactly what the process produces.
Building in order of perceived importance instead of order of constraint, and skipping the feasibility check. Together they account for most schedules that collapse partway through.
Keep the constraints, not just the grid. If the schedule exists only as a spreadsheet one person understands, every change is a fresh reconstruction because nothing records why a lesson sits where it does. If it exists as constraints plus a generated result, a change means updating a constraint and regenerating.
Start a 14-day free trial on Skoolia — no credit card, cancel anytime.
Start free trial14 days free · No card required · Clash-free timetables in minutes
