Smootables
Book a demo

School timetabling

How school timetable generation works

What generation places, the order that keeps the grid solvable, and how manual, automatic, and mixed runs stay under planner control.

Juho Isola, Smootables founder

Timetable generation places agreed classes into periods. That is the whole job. It runs on the staffed, feasibility-checked structure that year planning produced; it does not invent the curriculum, and it cannot repair a weak plan.

Generation can be manual, automatic, or mixed. In all three, the solver's role is assistant: surface issues before changes are applied, while the planner decides what to lock, move, or rerun.

This guide covers what generation consumes, the order that keeps a grid solvable, and where planner judgment stays. The wider workflow around it is mapped in how to create a school timetable; the handoff that must precede it is covered in timetabling handoff.

Key takeaways

  • Generation consumes a staffed, feasibility-checked structure and turns it into placed lessons.
  • Most-constrained items go first: singletons, then core subjects, then electives.
  • Manual, automatic, and mixed scheduling are all legitimate; the choice is the planner's.
  • Solver feedback is reviewed before a change lands, never after.

What generation consumes

The inputs are the agreed classes, staff assignments, rooms, and constraints from planning. Generation places them; it does not question them. A structure that has not passed feasibility checks can fail placement for reasons no solver can repair, because the failure was designed in upstream.

That boundary is useful. When a run fails, the first question is which side of it the problem sits on: the data and structure, or the placement.

Run generation in constraint order

Place the hardest items while the grid still has room for them.

  1. Confirm the structure is staffed and feasibility-checked before anything is placed.
  2. Lock the fixed points the school has already committed to.
  3. Place singletons and other lessons with very few valid periods.
  4. Place core subjects that large numbers of students must attend.
  5. Place electives and options into the remaining space.
  6. Review solver feedback, then send unresolved conflicts to validation or conflict resolution rather than forcing the grid.

How to do this in Smootables: generate a timetable

Generation runs on the period plan, after validation and inside the scope you choose.

Generation in Smootables runs from the period plan and validates before it solves.

  1. On Planning, open the period and click Generate timetable (or Generate new timetable when one exists).
  2. Pick the scope in the Generation scope dialog: Changed groups only, or All student groups.
  3. The solver runs in two phases: hard constraints first to find a feasible grid, then soft preferences to improve it.
  4. Tune the soft side under Solver Settings: six weights from 0 to 200 (Student Gaps, Teacher Gaps, Student Daily Balance, Teacher Daily Balance, Subject Spread, Morning Preference). A weight of 0 disables a constraint, and only Morning Preference is enabled by default.
  5. Restrict a single placement with Schedule preferences: specific weekdays, morning or afternoon, or all lessons on the same day.

Manual, automatic, or mixed

Some schools place everything by hand, some generate everything, and many mix: the solver places lessons, the planner reviews exceptions and locks what must not move. All three are legitimate. The deciding question is where judgment adds value, and the answer differs by school.

What does not differ: feedback is reviewed before changes are applied. A solver that shows a clash before the move is an assistant. Applied silently, the same suggestion is a liability.

Some planners ask whether a general-purpose chatbot could do this instead of a solver. See can ChatGPT create a school timetable? for what the evidence shows.

Ready-to-generate checklist

A gap in this list is what later shows up wearing a solver error.

  • Staffed classes from the year-planning structure
  • Blocks, bands, sets, and option patterns checked where the school uses them
  • Fixed points identified and locked
  • Teacher availability and room requirements entered for validation
  • A deliberate choice of manual, automatic, or mixed scheduling
  • A review step between solver feedback and applied changes

After the run

A finished run is a draft, not a decision. Check the grid against the commitments that were locked, then work the leftovers: validation findings go back to data, stuck lessons go to conflict resolution.

For how the checks themselves split into static and dynamic stages, see constraint validation.

Questions planners ask about generation

Can generation fix an unfinished curriculum plan?

No. If staffing, blocks, or class structures are not feasible, the solver rediscovers that infeasibility as failed placements. Fix the structure in planning, where the fix is cheap.

What is a singleton and why does it go first?

A lesson with very few valid slots, often a single class with one qualified teacher. Easy lessons can fill almost any slot, so they can wait. Leave a singleton to the end and its few valid slots are already taken.

Does a failed run mean the data is wrong?

Often. Data gaps surface as placement failures, and the solver can only report where it got stuck. Run validation before blaming the constraints.

More guides on this topic

See how Smootables fits your school

Book a walkthrough and we will map Smootables to your planning, workload, and timetabling process.