Every timetabling tool promises a schedule in minutes. Every school discovers the minutes come after the data, and the data is where the work actually is.
This article is what we would tell you in an onboarding call: exactly what a solver needs, the order that avoids rework, and the four mistakes that consume the most time.
The five things a generator actually needs
Less than most people expect. In dependency order:
| # | What | Why it must come first |
|---|---|---|
| 1 | The grid — days per week, periods per day, breaks | Everything else is placed inside it |
| 2 | Subjects — name, short code | Referenced by lessons and teachers |
| 3 | Teachers and classes | The two things lessons connect |
| 4 | Rooms — and room types where they matter | Only labs, gyms and specialist rooms need typing |
| 5 | Lesson cards — class + subject + teacher + weekly hours | The actual units being placed |
That is a working timetable. Availability, distribution rules and preferences make it a good timetable, but they are refinements — and adding them before you have run anything is the most common way to waste a week.
The order that avoids rework
Day one: get to a generated plan, however rough
Enter the grid, subjects, teachers, classes and lesson cards. Skip availability. Skip preferences. Skip room types except where a lesson genuinely cannot happen elsewhere. Then generate.
The result will not be usable. That is fine — that is not what it is for. What you get is proof that your data is coherent, and a baseline. Every problem visible at this stage is a data problem, not a scheduling problem, and data problems are much cheaper to fix now than after you have layered fifty preferences on top.
Day two: add the constraints that are facts
Teacher availability. Rooms that are genuinely unavailable at certain times. Fixed events — assembly, staff meeting. These are not preferences; they are true statements about the world, and the timetable is wrong without them.
Generate again. If it now fails, the cause is almost always one of the arithmetic conflicts described in our article on infeasibility — most often a teacher assigned more hours than they are available.
Day three: add preferences, one group at a time
Distribution rules, gap minimisation, day balancing. Add a group, generate, look at the result. This is slow-sounding and fast in practice, because when quality drops you know exactly which rule did it.
The alternative — configuring everything and generating once — produces a plan you cannot reason about. If it is bad, you have forty candidate causes.
The four expensive mistakes
1. Modelling the timetable you have instead of the school you run
The most costly one. Schools transcribe last year's plan — including the pins, the workarounds, and the group splits invented because the old generator could not express something.
Ask of each unusual structure: is this a fact about our school, or a scar from old software? Split classes that exist only because a previous tool could not handle a shared lesson are the classic case. Carrying scars forward means paying for them forever.
2. Over-specifying rooms
Assigning every lesson a specific room feels thorough. It removes an entire dimension the solver could have used to resolve conflicts. Specify a room only when the lesson genuinely requires it — labs, gym, computer room, music. Let everything else float; you will get a better plan, and rooms will still be assigned.
3. Making every preference strict
Understandable — everything on the list matters to someone. But strict means never violated, and forty strict rules is how you reach an infeasible model in which every rule is binding and none is obviously wrong. Strict for the three or four that are genuinely non-negotiable; weighted preferences for the rest.
4. Entering student course choices too early
For schools doing student-based scheduling: get the class-based part of the timetable working first. Individual choices multiply the constraints substantially, and debugging a data error is far harder when every one of six hundred students is a constraint. Establish that the foundation is sound, then add the choices.
If you are coming from other software
Import rather than retype. aSc XML, Untis interchange files and Excel all carry the five essentials, and the import brings your existing plan across as a starting scenario — which means you can compare like for like rather than judging a new tool against a memory.
Do check two things after any import: that weekly hours per class match your curriculum totals, and that room types mapped sensibly. Those are the two places where importers across the industry most often guess.
A realistic timeline
For a secondary school of moderate size, starting from a spreadsheet:
- Half a day — grid, subjects, teachers, classes, rooms. Faster with an import.
- Half a day — lesson cards. The bulk of the typing, and the part worth importing.
- An hour — availability and fixed events.
- An afternoon, spread over a week — preferences, calibration, comparing runs.
Two to three working days to a timetable you would publish, most of it data entry you would have done anyway. The generation itself is seconds; it is the only part that has genuinely got faster in thirty years, and it is the part everyone benchmarks.
A free Bildena workspace comes with a sample school already loaded, so you can run a generation and see the shape of the data before entering any of your own.