How to build a high school master schedule

You need all four of these settled before placement starts. A missing one does not stop the software you use; it stops the schedule from meaning anything.

1. Verified course requests. Every student's requested courses for next year, after counseling review, with alternates recorded. Requests drive everything downstream, so an error rate you would tolerate nowhere else is intolerable here. 2. Staffing, in real allocations. Which teachers are available, for how many sections, with certifications and part-time constraints attached. A department's paper allocation and its actual availability are rarely the same document. 3. Room inventory. Ordinary classrooms plus every constrained space: labs, gyms, shops, the one room with the kiln. 4. The bell schedule. Periods per day, lunch structure, and any A/B or block rotation, decided before placement, because changing it afterwards restarts the build.

Pull the request totals per course and read them against last year. A course that doubled or halved is usually a data problem (a registration form defaulted, a counselor batch-entered) before it is a demand story. Chase the anomalies now. Correcting a hundred requests in March costs an afternoon; correcting them in August costs the schedule.

While you are in the data, record alternates. When a student's first choice cannot be scheduled, the alternate is what the loader falls back on, and a blank alternate becomes a counselor meeting in the first week of school.

Divide each course's request count by your target class size to get the number of sections. Round with judgment: 27 requests at a target of 25 is one generous section or two thin ones, and the answer depends on staffing, contract caps, and whether the course historically gains or loses students over the summer.

Then assign a teacher to every section before anything is placed. This is the step schools most often defer, and deferring it is how a grid that looked finished in May collapses in July when the actual availability of actual people meets it. Teacher workload has its own trade-offs; the teacher workload guide covers them.

A singleton is a course with exactly one section: AP French, orchestra, the third-year welding cohort. A doubleton has two. These terms matter because a student who requests two singletons placed in the same period can never take both, and no amount of later shuffling fixes it.

So before placing anything, build the conflict matrix: for every pair of singletons (then doubletons), count how many students requested both. The pairs with high counts must land in different periods. The pairs with zero can share one. Most scheduling software generates this matrix from the request file; in a spreadsheet it is a pivot over request pairs, tedious and entirely doable.

Place the hardest things first, while the grid is still empty enough to accept them:

1. Singletons, spread across periods according to the conflict matrix. 2. Sections tied to scarce resources: the single gym, the shared lab, the teacher who is in the building only in the mornings. 3. Doubletons, using the matrix the same way. 4. Multi-section courses last. A course with six sections can absorb almost any student's remaining free periods, which is exactly why it waits.

Keep lunch coverage and contractual planning periods visible as you go. A grid can be conflict-free for students and still be unstaffable because one department eats its entire lunch window.

Run the student loader. It will schedule some percentage of students cleanly and return a conflict list for the rest. Read that list as evidence about the grid: if the same course pair tops the conflict count, those sections are in the wrong periods relative to each other, and moving one section will clear dozens of student conflicts at once. Hand-fixing the dozens individually treats the symptom and leaves the cause on the grid for August.

There is no universal threshold for a good first load, and anyone quoting one is describing their own building. The honest reading is the trend: each structural fix should raise the clean percentage, and when further moves stop raising it, the remaining conflicts are genuinely individual and belong to counselors.

Before publishing, check section balance. The loader fills seats in the order it meets students, so without a pass over the numbers you can end up with one section of 31 and a sibling section of 19. Rebalance while schedules are still private; every swap after publication is a schedule change some student experiences.

Then stop. There is always one more improvement available, and chasing it past the point of structural fixes is how master schedules stay unpublished into August. Publish, hold a change window for genuine errors, and put everything else on the list for next year's build.

- Rolling last year's grid forward without re-checking it against this year's requests. Reusing the prior grid as a base is common practice; the mistake is skipping the re-tally of sections against current request counts, which leaves demand shifts to surface as conflicts in the student load. - Placing singletons late. By then the grid has hardened around them. - Treating the conflict report as a student problem. The first read of the report is always about section placement. - Skipping alternates at registration. The cost lands on counselors in week one. - Changing the bell schedule mid-build. Every placement decision made before the change was made against a grid that no longer exists.

The spreadsheet version of this process works, and small schools run it every year. What software changes is the cost of iteration: regenerating the conflict matrix after a request correction, re-running the student load after a section move, and validating the grid without reading it cell by cell. Smootables covers the structural side of the build, placing sections against teacher, room, and period constraints and surfacing clashes before changes are applied, so each pass through steps 4 and 5 takes minutes instead of an evening. If you are comparing dedicated tools, start with the current comparison of school timetable software.