Timetabling software demos are misleading in a specific way. The sample school always has enough teachers, no part-time contracts, no shared campuses, and no subject that can only be taught by one person in one room. Every product looks excellent under those conditions, because under those conditions the problem is easy. Your school is not those conditions.
The questions worth asking are the ones that expose behaviour at the edges, where real timetables actually live.
Start with what happens when there is no solution. This is the single most revealing question you can ask, because sometimes your constraints genuinely cannot all be satisfied, and how a product handles that tells you how it was built. A weak product spins, times out, or produces a partial timetable with silent gaps you discover later. A good one tells you which constraint is the blocker — "Physics needs 24 periods a week but its teachers can only cover 20" — and what to change. Ask the vendor to show you a deliberately impossible setup during the demo. Their reaction to the request is informative on its own.
Then ask what counts as a constraint versus a preference. Every product will prevent a teacher being in two rooms at once. Fewer handle part-time contracts, protected non-contact time, teachers shared across campuses, subjects that must use a specific room, or the requirement that a class not have the same subject three times in one day. Write down your five most awkward scheduling rules before any demo and ask specifically about each. Vague answers about "flexibility" mean no.
Ask how changes are handled mid-year, because this is where the real cost lives. Building the timetable in July is a two-week job once. Reworking it when a teacher resigns in November, when a room is taken for building work, or when a new class is added in January is a job that recurs. If the answer involves rebuilding from scratch or manually dragging lessons, you have bought a document rather than a system. The right answer is that you update a constraint and regenerate, with the option to lock the parts that are working.
Ask what the timetable connects to. A timetable that lives in its own application is a timetable someone will re-key into the attendance register, the parent portal, the cover system, and the room booking sheet. Every one of those re-keyings is an opportunity for the versions to diverge, and they will. Ask whether the schedule feeds attendance directly, whether teachers and parents see it without a separate export, and what happens to all of those when a single lesson moves.
Ask who can operate it. Some timetabling tools are genuinely powerful and require a specialist who has been trained on them — which is fine until that person leaves. If only one member of staff can run the system, the timetable is a single point of failure with a notice period. Ask how long it takes a competent administrator to become independent, and be sceptical of any answer measured in weeks.
Ask about exports and printing, unglamorous as it sounds. Staff want their own timetable on a page. Heads of department want a subject view. The cover manager wants to see who is free in period four on Thursday. Reception wants a room view. If the product only produces one master grid, those views will be rebuilt by hand in a spreadsheet, which is where the divergence starts.
Two questions specific to international and multi-campus schools. Does it handle a Sunday-to-Thursday week as a first-class option rather than a workaround? And can it schedule across campuses while respecting travel time for shared teachers? A surprising number of products assume Monday-to-Friday and a single site, and the workarounds are painful.
Finally, ask what the tool does about workload fairness. A timetable can be perfectly valid and still be unfair — one teacher with five consecutive periods and another with a comfortable spread, or one member of staff carrying every early start. Valid is the floor, not the goal. Ask whether the software optimises for balance and gaps, or merely avoids clashes.
A practical suggestion for the evaluation itself: do not test with the sample data. Take one year group, with your actual teachers, your actual part-time contracts, and your actual room constraints, and ask each vendor to build it during the trial. A product that handles one real year group will probably handle the school. A product that only handles the demo school definitely will not.
Skoolia’s timetabling is built around these specifics: constraint-based generation, named reasons when something cannot be scheduled, regeneration around locked lessons, and a schedule that feeds attendance, cover and the parent portal without a re-export. If you want to test the constraint behaviour before talking to anyone, the free generator on this site will happily tell you why an impossible setup is impossible.