School timetabling

Preparing timetable data: teachers, subjects, rooms, and the cycle

The five data sets to gather and clean before generation, and the errors that come back dressed as solver failures.

Juho Isola, Smootables founder

Most generation failures are data failures wearing a solver's error message. A missing field, a duplicated teacher, a wrong room type: each blocks placement, and the solver can only report where it got stuck, not that the input was wrong.

The cost of hand-wrangled data is well documented. The classic sourced case is the teacher who discovers in September that the grid has them in two rooms at once, and part-time staff are the most common trigger.

This guide lists the five data sets to prepare and the cleaning pass that catches problems while they are still cheap. For migration-specific cleanup (imports, field mapping), see data cleanup.

Key takeaways

  • Five data sets: teachers, subject requirements, rooms and equipment, classes, and cycle structure.
  • Teacher data means qualifications, maximum weekly hours, part-time availability, and preferred free periods.
  • Wrong room types and duplicates block placement and surface as solver errors.
  • Part-time availability deserves the most care; it is the most common double-booking trigger.

The five data sets

Gather them as sets so each has an owner who can check it.

  • Teacher information: qualifications, maximum weekly hours, part-time availability, preferred free periods
  • Subject requirements: periods per week, double periods, special room needs, combinations
  • Resource audit: rooms, labs, shared equipment
  • Class information needed for placement
  • Structural parameters: periods per day, cycle length, breaks
  • A list of known issues: duplicates, missing fields, wrong room types

Teacher data carries the risk

Teacher records need more than names: qualifications decide who can take a lesson, maximum weekly hours cap the load, and part-time availability decides which slots exist at all. Preferred free periods matter too, because they become soft constraints later.

Part-time availability earns special care. It changes mid-year, it is often recorded outside the timetable data, and when it is wrong the resulting double-booking surfaces late and publicly.

The cleaning pass

Run it before the solver is asked to explain placement failures.

  1. Gather the five data sets and name an owner for each.
  2. Remove duplicates and fill missing required fields.
  3. Check every room type against the lessons that need it.
  4. Map part-time availability onto the actual teaching cycle.
  5. Run static validation: missing values, duplicates, unstaffed lessons.
  6. Only after it passes, treat remaining failures as placement problems.

How to do this in Smootables: resources that match this list

Eligibility, hour limits, and availability turn teacher data into constraints the solver can use.

The Resources area holds the same data sets this guide asks you to prepare, so gaps surface while you enter them rather than at generation.

  1. Fill the Resources tabs: Teachers, Rooms, Equipment, Student Groups, and Students.
  2. Set Weekly max hours and Yearly max hours on each teacher; workload warnings measure against these limits.
  3. Record which teachers can be selected automatically for each study unit under Teaching eligibility. It is optional and feeds the solver's automatic selection; manual assignment stays open.
  4. Enter unavailability under Availability: full-day date blocks plus repeating in-day rules, for teachers and rooms.
  5. Bulk-load with Import data from Excel or CSV: resources, teaching offering, or a full period plan, with column mapping and a preview.

Subjects and resources interact

Subject requirements create demand that the resource audit must cover. Double periods consume consecutive slots, special rooms narrow the options, and lesson combinations tie groups together. Each interaction shrinks the set of usable periods before the solver starts.

When a placement fails on rooms, the fix is usually cleaner resource data rather than a cleverer run: a room type corrected, a lab added to the audit, an equipment record completed.

Signs the data is not ready

Any of these sends the work back to preparation, whatever the calendar says.

  • The same teacher appears under two spellings or identifiers
  • Lessons are missing staff, subject, class, or room data
  • Room types do not match the lessons assigned to them
  • Part-time availability is unclear or not mapped to the cycle
  • Periods per day, cycle length, or breaks are still moving
  • Double-bookings get found by people instead of validation

Questions planners ask about data preparation

Why do data issues look like solver failures?

The solver hits the gap at placement time and reports a blocked lesson. The message describes the symptom; the cause is a record that was wrong before the run started.

Why are part-time contracts the usual trigger?

Part-time availability is the data most often tracked by hand and most often out of date. The sourced classic case, a teacher timetabled into two rooms at once and finding out in September, traces back to exactly this.

How clean is clean enough?

When static validation passes: no missing values, no duplicates, no unstaffed lessons, and room types that match the lessons needing them. That is the gate; polish beyond it can wait.

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.