Building a School Timetable, Start to Finish

What it actually takes to build a school timetable with a constraint solver, from the first teacher you type in to the schedules taped up outside the staff room.

Most writing about timetabling software stays up in the clouds: constraint solvers, complex algorithms, optimization. Fine, as far as it goes. But if you're the one who has to hand in a finished master schedule before September, none of that tells you what the job is actually like on a Tuesday afternoon. What do you type in first? In what order? And when the computer's first attempt at a schedule isn't quite right, what do you actually do about it?

So here's the walkthrough nobody writes: start to finish, using Arignote Timetable as the example, though the shape of the process holds for pretty much any solver-based scheduling tool.

Everything later depends on getting this part right, so it's worth slowing down here. You're building a digital model of your school out of four pieces.

Teachers. Names, subjects, and their availability and wishes. Availability is the hard stuff: a part-timer who legally cannot work Fridays, say. Wishes are softer: a preference for morning classes, or a hope to avoid five straight hours of teaching. Get these in now, and the system respects them on every draft that follows, not just the first one.

Rooms. Not just a list of numbers. You define categories and capacities: which rooms are science labs, which have a projector, which can actually fit thirty kids without someone sitting on the floor. Classify them properly and the software assigns them on its own, instead of you cross-referencing a spreadsheet every time a class needs a lab.

Classes and courses. The curriculum itself: how many hours of Math or English each class group needs, and who's teaching it. Starting from nothing, Arignote ships with course structures already set up for several national school systems, which saves a fair amount of work. Coming from FET, gpUntis, aSc TimeTables, Penalara GHC, Additio, or PlanIt, you can just import what you already have and skip the setup step entirely.

The shape of the week. Days, period times, lunch breaks, the whole framework. Exam weeks or half-day summer schedules that don't look like the rest of the year? Build separate time grids for them and switch between them, rather than bending one rigid layout to fit everything.

One thing veteran schedulers will tell you: don't clean up the model to make it simpler. Put the awkward stuff in exactly as it is. The gym teacher who splits time with another school. The art room that's locked every Tuesday afternoon. The double period that can't straddle lunch. Anything you leave out here becomes a fix you're making by hand later, on every single draft.

Before you generate anything, tell the system about the classes that won't sit in one tidy hour-long slot.

Multi-period blocks come first: labs, doubles, split sessions. Define these as one unit and the solver keeps them together in consecutive slots instead of scattering them across the week. Synchronized classes are next, the option blocks where three subjects run at once so students can pick between them. Mark them as synchronized and it becomes a hard rule; the solver simply won't put one of those teachers somewhere else. And staff meetings need a place in the grid too, with the right room and the right people, checked for conflicts the same as any class. Leave meetings out and you'll find out why that was a mistake around the second week of term.

With the model finished, generating a timetable is almost a non-event. You click solve, and the engine works through a search space most people would never guess the size of, looking for a layout where every hard rule holds (nobody double-booked, every availability respected) while fitting in as many of the soft wishes as it can.

A few minutes pass. You have a complete, conflict-free schedule.

Worth sitting with that for a second: this is a first draft, and it cost you almost nothing. Building a schedule this far by hand used to eat a chunk of your summer. Here it took minutes.

This is where your own judgment comes back into the picture. You're not checking the draft as a math problem anymore, you're reading it as a week someone actually has to live through. Pick a teacher and follow their day. Look at how a student group's schedule flows. Check whether the science labs are sitting empty half the time.

Want to change something? Drag the lesson to a new slot. Conflict detection tells you instantly whether that spot is free or what it breaks if it isn't, which is a different world from spreadsheet timetabling, where one manual edit can quietly wreck five other classrooms and nobody notices until October.

Like a change you made by hand? Pin it, and the solver builds everything else around that decision on the next run. Don't like the draft at all? Adjust a rule and run it again. Testing five different versions in one afternoon stops being unreasonable, especially with unlimited undo and autosave sitting underneath everything you do.

Once the timetable actually looks right, sharing it takes almost no effort. PDFs for the official record, the noticeboard, and staff copies. HTML for posting straight to the school website. Excel workbooks with a separate sheet per teacher and per class, plus poster-style layouts built to print and tape to a classroom door.

What used to be an afternoon of copy-pasting into templates becomes a button.

Sometime around October, something breaks the plan. A teacher goes on leave. A room floods, or a new one opens up. It always happens.

This is the second payoff of building it this way. Instead of patching a hand-built grid and hoping nothing else quietly broke, you update the model, re-solve or edit directly with conflict checking still running, and export again. The timetable stops being a document you finished once and starts being something you can actually keep using.