Smootables
Book a demo

School timetabling

How to create a school timetable

End-to-end process from feasibility-checked handoff through data prep, generation, validation, conflict resolution, and publication, with Smootables workflow steps.

Juho Isola, Smootables founder

Creating a school timetable is placement work: you take a staffed, feasibility-checked curriculum structure and put agreed classes into periods without clashes. It is not the same as building the curriculum from scratch.

This guide maps the full process from handoff through publication. Each step includes a How to do this in Smootables section with verified product workflow. For deeper steps, follow the linked guides in each section.

These guides cover planner process and decisions, not a Smootables product comparison. To evaluate capabilities, see automatic school timetabling software.

The steps below are numbered 1 to 7. Use the contents list to jump to each stage.

Key takeaways

  • Start only after year planning passes feasibility routines (block build, combing chart, clash table), not when the plan is merely typed in.
  • Clean teacher, room, class, and subject data before generation; dirty data often surfaces as solver failures that are really data gaps.
  • Place the most-constrained lessons first (singletons, fixed points, specialist rooms), then core subjects, then electives.
  • Validate in two stages (static data checks, then dynamic constraint checks), resolve kickouts with ordered swap tactics, and review before you publish.

Who is this guide for?

This guide suits timetable coordinators and planners who need an end-to-end map of the creation cycle. It assumes your school already has a curriculum structure from academic year planning and you are ready to place lessons into a grid.

It is less useful if you are still designing option blocks, contact ratios, or staffing models. Work through course catalog planning and resource and staff modeling first.

Contents

Before you build: confirm handoff readiness

The timetable handoff from year planning should be provably feasible, not just complete on paper. Verified routines include block build (no internal teacher or room double-booking within a block), combing chart (blocks fit together without double-booking a teacher), and clash table or conflict matrix (compatibility between blocks in different year groups).

Generation runs on this staffed structure. It places agreed classes into periods. It does not invent the curriculum or repair an unstaffable option pattern. See timetabling handoff for the full checklist.

How to do this in Smootables: confirm the handoff

Review workload warnings on Planning before you run Generate timetable.

On Planning, select your campus and open the target period. Confirm study units are placed in that period (the Planning tab shows "No placements for this period" until they exist). Review the timeline and teacher workload panels for warnings such as missing teachers, teachers over limit, or placements marked to be decided later before you generate.

Smootables generates from the period plan, not from an empty grid. If the structure still looks unstaffable, fix placements and group assignments on the Planning view first.

Step 1: Prepare and clean your timetable data

Duplicates, missing fields, and wrong room types are common causes of late clashes. A sourced example: when data is wrangled by hand, a teacher can discover in September that they are timetabled in two rooms at once, with part-time staff the most frequent cause. Work through data preparation before you open the scheduling grid.

  • Teachers: qualifications, maximum weekly hours, part-time availability, preferred free periods
  • Subjects: periods per week, double-period needs, special room requirements, subject combinations
  • Resources: rooms, labs, shared equipment, and room types
  • Classes: student groups, bands, sets, and option-block membership
  • Structure: periods per day, cycle length, breaks, and term dates

How to do this in Smootables: prepare data

Complete core resources before you import or open the period plan.

Clean data here prevents pre-generation validation errors such as missing teachers, missing rooms, or teachers over their weekly maximum.

  1. Open Resources and complete Teachers, Rooms, Equipment, Student Groups, and Students. Set weekly and yearly hour limits on teachers where your school tracks them.
  2. On Curriculum, confirm study units exist for the campus.
  3. Use Resources → Teaching eligibility to record which teachers can teach which subjects.
  4. For part-time or blocked time, open Resources → Availability. Add full-day date blocks or repeating in-day time rules for teachers and rooms.
  5. To bulk-load data, go to Import and upload Excel or CSV (resources, teaching offering, or full period plans). Map columns, preview, resolve ambiguous matches, then run the import.

Step 2: Define the day and week structure

Lock the structural parameters that every lesson will share: teaching periods per day and their times, operating days and cycle length, breaks and lunch, and named week types if your school alternates theory and practical blocks.

The period count feeds curriculum demand and staff capacity. A wrong cycle length or an unmodelled exam week makes the curriculum audit and staff loading chart disagree before scheduling begins.

How to do this in Smootables: school day profiles

Lesson times and holidays come from school day profiles attached to each period.
  1. Go to Settings → Academic Years, select the campus, and open the year you are building.
  2. Create or edit school day profiles for that year: active weekdays, lesson durations, breaks, and lunch waves.
  3. Add periods to the year with start and end dates. Assign a school day profile to each period.
  4. Choose recurring (same pattern every week) or custom weeks (each week can differ).
  5. Add holidays and blocked weeks on the year detail page so generation respects non-teaching days.

Step 3: Set constraints and fixed points

Separate fixed points the planner locks, hard constraints that must not break, and soft preferences the planner may relax if the grid is tight. Critical validation issues must be fixed before optimisation runs. Passing validation makes a feasible timetable likely, but never certain. See constraint validation.

How to do this in Smootables: constraints and preferences

School-wide soft preferences live in Settings; per-placement rules are edited on Planning.

School-wide soft preferences: open Settings → Timetabling (Solver Settings) and adjust the six weighted preferences (0 to 200 each): Student Gaps, Teacher Gaps, Student Daily Balance, Teacher Daily Balance, Subject Spread, and Morning Preference.

Per-placement rules: on Planning, open a placement and use Schedule preferences to restrict weekdays and time of day. Set Allowed rooms to Any room, specific rooms, or the study unit default.

Hard availability: teacher and room unavailability rules live under Resources → Availability.

Fixed points after a timetable exists: on Timetables, pin lessons you want the solver to keep fixed during regeneration.

Step 4: Choose manual, automatic, or mixed generation

Generation can be manual, automatic, or mixed. In every mode, the planner stays in control. See how timetable generation works and planner control during generation.

  • Singletons and other lessons with very few possible periods
  • Core subjects many students must attend
  • Electives and option lessons after tight commitments are placed
  • Lessons with specialist rooms, shared equipment, or limited staff availability
  • Lower-risk lessons that can move more easily near the end

How to do this in Smootables: generate and edit

Generation runs only after pre-generation validation passes.

Workplace-learning and remote-teaching placements follow different resource rules (no school teacher or room required where configured).

  1. On Planning, select the period you want to generate the timetable for.
  2. Fix validation errors before Generate timetable becomes available.
  3. Click Generate timetable. Smootables runs pre-generation validation, then the solver (hard constraints first, soft preferences in a second phase).
  4. Open the finished grid on Timetables. Drag lessons, swap two lessons, split an occurrence, or edit resources. Pin critical placements, then regenerate.
  5. When the period plan changed since the last solve, use plan-drift to regenerate for changed student groups only.

Step 5: Run validation before and after placement

Static analysis finds data problems that block creation: missing values, duplicates, unstaffed lessons. Dynamic analysis combines data and constraints to find problems static checks cannot see.

Treat a clean validation run as readiness to start placement, not as proof the finished timetable is conflict-free.

How to do this in Smootables: validation and infeasibility

Smootables checks the period plan before it spends time on a full generate run.

Before generation, the Planning Timetable tab runs the same checks as the validate API. Errors appear in the validation sidebar with links to the affected placement, teacher, or room.

After generation fails, read the infeasibility report with typed conflict causes and suggested actions.

After manual edits, moving a lesson on Timetables opens a Conflicts detected dialog if a teacher, room, or group would overlap. Hover a slot and open Slot insight (Free resources) to see which teachers, rooms, and equipment are free.

Step 6: Resolve kickouts and clashes

A kickout is a lesson that fits in no period because its staff and/or students are not all free. The core tactic is FIT (musical-chairs): an interchange of activities to make room for the stuck lesson. Part-time teachers are often the biggest single cause of clashes. See conflict resolution.

How to do this in Smootables: waiting area and manual fixes

Use the waiting area and Slot insight when automatic placement leaves lessons unplaced.
  1. If generation is infeasible but partial placement is offered, choose Place what you can and move the rest to the waiting area.
  2. On Timetables, drag a stuck lesson to a new slot, swap it with another lesson, or use Move to waiting area.
  3. Use Slot insight on candidate slots to see free teachers and rooms before committing a move.
  4. Pin lessons once they are agreed so regeneration does not move them.
  5. Check Resources → Availability when clashes involve part-time staff.
  6. Use Undo and Redo, or open timetable version history to compare branches and restore an earlier generation.

Step 7: Review with departments and publish

Walk department heads through the placements that affect their staff and rooms. Check part-time and job-share patterns against contracted hours. Confirm specialist rooms are used for the right subject types. Record which version is approved and who signed off.

Publication is distributing the approved grid to teachers, students, and admin systems. Keep one authoritative version.

How to do this in Smootables: export and share

Export shares the approved grid; Smootables stays the authoritative version.

Smootables today shares timetables through export and in-app views rather than a separate parent or student portal.

  1. On Timetables, filter by teacher, room, student group, or individual student to walk through each department view.
  2. Compare teacher grids against Resources hour limits and the workload panels you reviewed on Planning.
  3. When the grid is approved, use Export on the timetable toolbar. Choose CSV, Excel, or PDF.
  4. Keep the live timetable in Smootables as the authoritative version. Regenerating creates a new branch; restore an earlier branch from version history instead of maintaining a parallel spreadsheet.
  5. The per-branch audit trail records moves, pins, swaps, waiting-area changes, and restorations.

Common mistakes when creating a school timetable

  • Starting before feasibility proof: typing classes into a tool without block build, combing chart, or clash table checks
  • Treating solver errors as tool bugs when missing availability, duplicate rows, or wrong room types are the real cause
  • Scheduling electives before singletons while tight lessons still need grid space
  • Skipping validation: static and dynamic checks catch different problem classes
  • Under-modelling part-time staff availability windows
  • Publishing before department review forces expensive rework

What this guide does not cover

This guide answers one question: what is the end-to-end process to create a school timetable from a feasibility-checked plan? It does not compare vendors, rank tools, or explain how to design option blocks from scratch.

For year-planning decisions, see academic year planning guides. For software evaluation, see automatic school timetabling software, school year planning software, and best school timetable software (2026). For constraint-specific Smootables workflows, see docs recipes.

Questions planners ask

Can I create a timetable from a spreadsheet list of classes?

You can hold data in a spreadsheet, but creation still needs a staffed structure, validated constraints, and a placement method. Spreadsheet grids lack audit trails and make late double-bookings more likely. In Smootables, use Import to load a period plan or teaching offering, then validate and generate from Planning.

How long should timetable creation take?

There is no universal timeline. Schools with a feasibility-proven plan and clean data typically spend less time on rework than schools that start placement before handoff checks pass. Once the period plan is ready, automatic timetable optimization usually finishes in 10–30 seconds.

Should I generate the full timetable automatically?

Not always. Many schools use mixed scheduling: the solver places bulk lessons, and the planner locks fixed points, reviews feedback, and resolves exceptions manually.

What if generation finishes but teachers still clash?

Run conflict resolution on kickouts rather than accepting a grid with hidden double-bookings. Pin staffing or swap adjacent lessons to free a period. Part-time availability is the first place to look when clashes survive a clean validation run.

When is the timetable ready to publish?

When feasibility routines passed at handoff, validation issues are cleared or explicitly accepted, kickouts are resolved, and department review is complete.

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.