Why Schools Still Build Timetables by Hand (and Why It's Costing Them Weeks)

Every summer, in thousands of schools, someone closes their office door with a spreadsheet, a stack of teacher requests, and a growing sense of dread. It doesn't have to be this way.

Ask any deputy head or academic coordinator what the worst part of their year is, and you'll hear the same answer surprisingly often: the timetable.

Not teaching. Not inspections. Not even budget season. The timetable.

It usually happens in the quietest weeks of the year — late June, July, August — when the building is empty and the pressure is invisible to everyone except the person doing it. One person (occasionally two) sits down with the master list of teachers, subjects, rooms, and class groups, and starts placing lessons into a grid. By hand. Cell by cell.

And then, three days in, they discover that the physics teacher who also teaches maths can't be in two places on Tuesday morning, and half the grid unravels.

Here's what people outside the process rarely appreciate: building a school timetable is not an administration task. It's a combinatorial optimization problem, and a brutal one.

A medium-sized secondary school might have:

• 40–60 teachers, each with their own subjects, contracts, and part-time patterns
• 20–30 class groups, each needing a full week of lessons
• Dozens of rooms — some generic, some specialized (labs, gyms, music rooms)
• Hundreds of individual lessons that all have to land somewhere

Every lesson you place constrains every lesson you haven't placed yet. Put Ms. García's biology double period on Monday at 9, and you've just removed options for her chemistry group, for Lab 2, and for every class that shares students with that biology group.

The number of possible timetables for even a modest school exceeds the number of atoms in the observable universe. Humans solve it anyway — through experience, intuition, and heroic amounts of erasing. But "solving it" by hand typically means:

• Two to six weeks of one senior person's time
• A result that's feasible, not good — it works, but nobody dares touch it
• A single point of failure: if that person leaves, the institutional knowledge leaves with them

The worst part of a hand-built timetable isn't the weeks it takes to build. It's what happens afterwards.

A new teacher arrives in October. A room floods. The government changes the required hours for a subject. In a hand-built timetable, every change is terrifying, because the person who built it knows — better than anyone — how fragile it is. So schools live with bad compromises for a whole year rather than risk pulling the thread.

That rigidity has a real cost: teachers stuck with schedules that ignore their stated preferences, students with dead gaps in their day, specialized rooms sitting empty while classes squeeze into the wrong spaces.

Automated timetabling isn't new — but for a long time it was the preserve of expensive, complicated desktop software that looked like it was designed in 1998 (because it was). The current generation of tools works differently, and the shift is worth understanding.

The core idea: you describe the problem; the solver does the placing.

You tell the software what's true about your school — who teaches what, which rooms exist, what each group needs, who's part-time on Thursdays, which teacher prefers mornings. Then a constraint solver searches that astronomically large space of possible timetables and returns one with zero conflicts: no teacher in two places, no double-booked room, no group with overlapping lessons.

With Arignote Timetable, that generation step takes minutes, not weeks. And because generating is cheap, the whole relationship with the timetable changes:

• Iteration becomes possible. Don't like the first result? Adjust a constraint and regenerate. You can explore five variants in an afternoon — something that would take a manual planner most of a term.
• Changes stop being scary. New teacher in October? Update the data, re-solve, review the diff. The timetable becomes a living document instead of a fragile monument.
• Preferences become data, not politics. When "Mr. Blanco prefers no first-period classes" is a recorded constraint rather than a hallway negotiation, the process gets fairer and more transparent — and the software respects it every single time it solves.

Every school believes its constraints are uniquely impossible. Split-site campuses. Teachers shared between two schools. Option blocks where four subjects run simultaneously across three groups. Double periods that must not straddle lunch.

This is exactly the territory where hand-building breaks down and constraint solvers shine — a solver doesn't get tired on constraint #200. Good timetabling software handles these as first-class concepts: multi-session lectures placed as one unit, synchronized lessons across groups, per-teacher availability windows, even staff meetings scheduled inside the same conflict-checked grid.

If a tool can't express one of your real constraints, that's a reason to pick a different tool — not to go back to the spreadsheet.

Let's be honest about what automation does and doesn't do.

It doesn't remove the human from the process. Someone still has to know the school, encode its reality accurately, and judge whether a generated timetable feels right — software can verify there are no conflicts; only a person can verify that the timetable is humane.

What it removes is the mechanical labour: the weeks of manual placement, the cascading rework after every discovered clash, the fear of touching a finished grid. The person who used to spend their summer with a spreadsheet gets that time back for the parts of the job that actually need their judgment.

For most schools, that's the difference between a timetable that merely exists and one that's actually good.