How to build a class-rotation schedule that doesn’t collide

Updated 2026-07-20 · scheduling · class rotation · capacity · waitlists

A rotation schedule collides when two things it shouldn’t allow both happen at once: a room booked past capacity, a kid signed into two classes at the same time, or a class quietly running with no teacher assigned. On a spreadsheet, every one of those is possible, because nothing stops you from typing a name into a full cell.

The fix isn’t a better spreadsheet — it’s treating capacity, time, and space as rules the schedule enforces, not details a human has to remember to check.

Why do spreadsheets break down here?

A spreadsheet is a grid of text. It doesn’t know that “Gym” holds 40 people, that a kid can’t be in two places at 10:30, or that “Advanced Knots” requires a rank a particular kid doesn’t have yet. Every one of those constraints lives only in the head of whoever built the sheet — which is fine until that person is out sick, or the sheet gets duplicated three times over email and two versions disagree. The moment a schedule has more than about twenty classes, or more than one person touching it, spreadsheet collisions aren’t a risk — they’re a certainty.

What are the actual building blocks of a rotation schedule?

Every rotation schedule, regardless of what you call the pieces, is built from the same four things:

• Rooms or stations — the physical (or virtual) spaces classes happen in, each with a maximum capacity.
• Timeslots — the repeating blocks of time classes are assigned to (e.g., four 90-minute blocks across a Saturday).
• Classes — what’s taught in a given room during a given timeslot, by a given teacher, to a given capacity.
• Registrants — the kids assigned into a class, up to that class’s capacity, with anyone beyond it going to a waitlist.

Get these four modeled correctly and “does this schedule collide” becomes a question the system can answer instantly, instead of a question a human has to re-derive by scanning rows.

How should capacity actually work?

Capacity needs to live at two levels, not one. A room has a hard ceiling (a gym holds 40 people no matter what’s happening in it), and a class has its own ceiling that can’t exceed the room’s (a 12-person craft class in a 40-person gym still tops out at 12). When a class fills, the next registrant shouldn’t be silently rejected or squeezed in anyway — they should land on a waitlist tied to that specific class, and when a spot opens (a withdrawal, a no-show marked ahead of time), the next person on that waitlist should move up automatically. Done right, an organizer glances at the board and sees exactly this at a glance: green means open, amber means full, red means waitlisted — no guessing, no phone calls to “check if there’s room.”

How do you handle classes that span more than one timeslot?

Some classes — a longer skill, a multi-part project, a hike — legitimately need two or three consecutive timeslots rather than one. The schedule needs to treat these as a single block that reserves the room and the kid’s calendar across all the sessions it spans, not as separate classes a kid has to separately register for and hope line up. If it doesn’t, you get the classic collision: a kid signed into “Part 2” of a multi-session class while also signed into something unrelated at the same hour, discovered only when both teachers ask where they are.

How do minimum-level or prerequisite rules fit in?

Many programs have classes that only certain kids should be able to take — a minimum age, a completed prerequisite class, a rank or level. The cleanest approach is to attach that rule to the class itself, so a kid who doesn’t qualify simply doesn’t see it as an option, rather than registering and getting turned away at the door. This one rule prevents a surprisingly large share of day-of friction, because it moves an awkward in-person conversation (“sorry, you’re not old enough for this one”) into an invisible, upfront filter.

A worked example

Picture three rooms — a gym (cap 40), a classroom (cap 20), and an outdoor field (cap 100) — running four timeslots on a Saturday. That’s up to twelve class slots. Layer in: one class in the gym that needs two consecutive timeslots (a longer project), one classroom class that requires a prior “beginner” class as a prerequisite, and 85 kids trying to register across three age levels. Manually, that’s dozens of small judgment calls happening simultaneously across however many volunteers are managing signups. On a proper schedule grid, it’s one board: each cell shows the class, teacher, and a live count (e.g., “Knot Tying — Kai S. — 6/6”), the multi-session class visibly blocks its second slot the moment it’s placed, the prerequisite class is invisible to kids who haven’t met it, and waitlists fill themselves in the order people asked. The organizer’s job shifts from arithmetic to actually running the event.

What should you check before you call a schedule “done”?

A quick pre-launch checklist: every room’s capacity is set correctly (not left at a default); every multi-session class actually reserves all of its timeslots; every level-restricted class has its rule attached, not just a note in the description; every teacher is assigned to exactly the classes they’re teaching, with no double-bookings; and the whole grid has been looked at by at least one other person besides whoever built it. That last step catches more real-world mistakes than anything else on this list.