Scheduling Starts at Registration

‍The Problem: Isolating Registration and Scheduling

After working with over 50 private schools, I have realized there is a fundamental problem no one is talking about - course registration. 

Schools treat registration and scheduling as two separate processes. One happens between January and March, the other takes place in the summer. But registration is inseparable from scheduling, because some of the most important scheduling decisions are made the moment students fill out the registration form. Schools collect course demand without knowing what they can actually supply. 

Take two schools we worked with, one in New York and one near San Francisco. On paper, they had the same problem. In practice, they got very different results.

The New York school ran registration the way most schools do. Students picked their courses but with no rankings and few alternates. Mostly a list of what each student wanted. The school has around 800 students requesting 10 courses each, so about 8,000 requests to fulfill. They achieved 98% fulfillment, which sounds excellent until you look at the remaining 2%. That's 160 requests that couldn't be fulfilled! The school had to go back to students to figure out what else they might want and somehow make it work. Hours and hours of effort until they can find a workable solution.

The school in San Francisco took a different approach. Students receive 16 course placements every year, but they're asked to rank 24 options. By collecting fallback choices upfront, the school always knows where to turn when a student's first choice isn't available. Scheduling starts with flexibility already built in. Instead of spending time patching holes, the school can focus on improving outcomes. Their fulfillment rates consistently land in the high 99s: 99.5%, 99.8%, 99.9%. And all because they collected the right requests in the first place.

Why Does This Problem Persist?

Your SIS typically contains modules for both registration and scheduling. However, they don’t really work that well so most schools use external tools. Students submit requests through Google Forms (or paper forms!), schedulers work separately, and someone else exports, cleans, and imports the data. The registration side remains blind to what the scheduling side needs and often gives scheduling an impossible problem to solve.

Most registration forms ask students to pick the courses they want, as if no matter what they choose, they'll get precisely that (this rarely happens even with 99% fulfillment). Two problems with this:

First, eligibility and prerequisites aren't correctly enforced. Most registration runs on Google Forms or paper, and neither checks whether a student has actually cleared the prerequisites. Second, every student in a grade sees the same course catalog, when they should see a choice pool personalized to their own academic record.

And even if a magical form got both right, checking that a student is allowed to take a course is a completely different question from whether the courses they picked can actually be built into a schedule. Eligibility only looks at one student in isolation: has this student met the prerequisites, are they in the right grade, is this course open to them? It never tells you whether every other student’s choices can fit together into a workable schedule given the sections, rooms, and teachers the school has. A form can clear every student individually and still hand over a set of requests that cannot coexist. 
‍

‍Solution

‍So if picking isn't enough, what should a form actually do? Three things:‍

1. Choice architecture should be personalized for each student

‍Two students in the same grade can have very different course histories. One finished Algebra II last year, the other didn't. So what each student should even be allowed to request is different, despite the same grade level. This is what personalized choice pools do: instead of a static and identical pool for the whole grade, each student sees the set of courses they actually qualify for. 

A form that shows everyone the same list is collecting requests that might need cleaning up later. Either the placement gets rejected down the line, or a teacher catches it auditing rosters, or worse, the student finds out after the semester starts that they were placed in a class they were never eligible for. Personalized choice pools don't have this gap.

2. Ranking (not picking) is the way to capture requests

This is the change that does the most work. A single pick is a hard constraint. It tells the system what this student wants, full stop. The system either delivers it or it doesn't. If it can't, there's no instruction for what to do next, so a human has to step in and decide. Now stack thousands of those hard constraints on top of each other, every student demanding exact courses with no flexibility, and whoever is building the schedule runs into dead ends constantly. There's simply no room to move.

Some schools try to soften this with alternates: pick your course, then name a backup or two in case it doesn't work out. It helps a little, but not much. An alternate is just a second hard pick sitting behind the first. It tells you what a student wants if their top choice fails, but it says nothing about how they weigh everything else, and it usually applies to one course at a time rather than the whole load. You're still working with a short list of fixed demands, just slightly longer. The moment the backup is also full, you're back to a human guessing.

A ranked pool works differently. If a student ranks their electives in order, you know not just their top choice and one fallback, but their full order of preference, the second, the third, the fifth. No one has to drop them into something random and hope they don't mind. There's always a next-best the student actually chose.

Once preferences are ranked, you can treat top-choice fulfillment maximization as the goal and ask what it would take to achieve it. Maybe another section of a course gets more students their first pick. Maybe adding a block to a part-time teacher's schedule does it. You can weigh what each option costs against how many students it would actually help. The question shifts from how many students missed out to what it would take to give them the courses they wanted. That's something a school can plan around, instead of a pile of fixed demands that can only be met or missed.

3. Forms should prevent invalid submissions

Decide what counts as a complete registration before the student submits, not after the schedule has been built. For each set of choices, the form sets the rule: rank at least five electives, you'll be assigned one; rank at least eight humanities options, you'll be assigned three. The form won't let a student submit until they follow the instructions. So by the time a request reaches scheduling, it's guaranteed to be solvable.

Checking the validity of course requests late carries a huge cost. A school in Georgia ran fifteen schedules trying to get a decent fulfillment rate. It was good - 92% - but they wanted more. It was only much later that they found out a lot of the course requests were incorrect, and nobody had noticed for weeks. They were trying to solve an impossible puzzle. That's why it matters so much that registration refuses invalid requests at the door so that scheduling doesn't suffer later. 

Put these three together - personalized choice architecture, ranked choices, and validity checked at the form, and it stops being a wish list. It collects requests that are already eligible, flexible, and complete, which means scheduling doesn't begin with a mess to clean up. The work starts from requests that actually make sense.
‍

‍Big Picture Stuff

This isn't as simple as building a fancy Google form. The shift is to stop treating registration as a form at all.

A form collects answers once and you move on. What a school needs is a system of record for student choice. It should capture the shape of student demand - what students want and how much they want it. That record preserves year-on-year memory. When a student misses out on their first-choice course one year, the system knows. The next time demand exceeds capacity, priority can be given to students who were previously turned away. Fairness becomes part of the process rather than a manual problem someone has to solve each year.

And, for this to work, the registration and the scheduling have to be built as a unified system from the start.
‍

Conclusion

We treat scheduling conflicts as a failure to solve a hard problem. But most of them aren't created during scheduling at all. They're created months earlier, in how we collect course requests, and by the time they show up they just look like scheduling problems. Registration shouldn't feed scheduling whatever students wish for; it should be guardrailed by what the school can actually deliver. Get that right, and a lot of the conflict you spend every summer untangling by hand goes away.