The Scheduler the System Forgot

Every university department has one: the person who builds the timetable. Sometimes it's the chair, sometimes an administrator or program coordinator, but whoever holds the job holds something else too: an accumulated, largely undocumented understanding of how their department actually runs. They know that two particular required courses can never overlap, that a certain instructor's lab needs the room with the fume hoods, that third-year students in one stream reliably take an elective from another. This local knowledge is the real engine of a workable schedule.

How do institutions use that information?

What the big systems do, and what they don't

Universities invest heavily in student information systems and centralized timetabling platforms, and those systems have a genuine role. Registration, records, room inventories, institution-wide optimization: this is work that belongs at the center, and the center needs serious software to do it.

But these platforms operate on a particular model. They collect constraints from departments, run an optimization, and deliver a timetable back. The model assumes that everything a department knows can be expressed as a constraint and entered into a form. In practice, much of what a scheduler knows resists that translation. And even where translation is possible, encoding hundreds of workflows, exceptions, and student-access considerations into a constraint interface is easily as much work as simply building the timetable. The department ends up doing the hard part anyway, only now in a format designed for a machine rather than for a human decision-maker.

But there's a deeper mismatch. Department timetables are rarely built from scratch. They evolve. When they're well-supported, schedulers work together year over year to assess what worked, repair what didn't, adjust to new enrollment patterns and program changes, and converge on arrangements that keep courses accessible to students. Like most products of patient trial and error, the result is more effective than the process suggests. A system that wants to regenerate the schedule from first principles discards that inheritance and asks the department to rebuild, in constraint form, knowledge that was already embodied in last year's grid.

And no timetable, however good, survives an academic year untouched. Instructors arrive and leave, sections are added or cancelled, enrollments shift. Each change lands on the scheduler's desk needing a quick, sound decision. What that moment demands is not another optimization run; it's the ability to see the situation clearly — what's affected, what conflicts, what's still open — so the person with the local knowledge can quickly act on it. The legacy systems aren't designed for that: they're designed to make the decisions, not support decision making.

The spreadsheet trap

Having spent generously on enterprise systems, institutions are understandably reluctant to fund additional software for departmental schedulers, with the licensing, IT deployment, and compliance overhead that usually entails. So schedulers reach for what they already have: spreadsheets.

Spreadsheets are wonderful, versatile tools, but they don't know what a section is. A colored block on the instructor sheet has no idea it conflicts with a colored block on the room sheet; catching that is the scheduler's job, every time, across every tab. Formulas and macros can paper over some of the gaps, but they're brittle, and when the person who wrote them moves on, the breakage is permanent. Many schedulers know the aftermath firsthand: the timetable goes to the registrar, the collisions surface, and an afternoon disappears into apologetic emails before registration opens.

And worse, spreadsheets are difficult to edit reliably. That provides an incentive for schedulers to just roll over last year's timetable: the antithesis of the evolutionary process discussed above, which responds to challenges and change instead of ignoring them.

The obvious rejoinder "surely there's better software for this" turns out to be less help than expected. There are hundreds of scheduling programs, but most are built for K-12 schools, whose scheduling problem is structurally different. Most of the rest require server databases, IT projects, and procurement approvals, which puts them right back behind the institutional wall the scheduler was trying to get around. And many are, in their own way, as complex as the enterprise systems they're meant to supplement. They're again focussed at the institutional level of generality, not on the department-level scheduler trying to get things done. And they're typically very expensive and require training to use. Our comparison page covers the landscape in more detail.

The department-level scheduler feels the pain daily but is locked in place by decisions made elsewhere: institutional commitments, procurement processes, IT policy. It's a gap in the market shaped exactly like one person's job.

What would actually help

Three things, none of them exotic. First, effective visual presentation: views of the schedule that surface issues instead of burying them, filtered to the instructor, room, program, or day in question, and kept in sync so that one change propagates everywhere. The scheduler makes the decisions; the software's job is to make the situation visible.

Second, conflict monitoring offered as a tool, not a rule. Instructor collisions, room collisions, and student-access collisions should be flagged the moment they arise. But defining what counts as a collision, particularly for student access, has to be nearly effortless. If it requires maintaining lists of formal constraints in an enterprise interface, we're back where we started.

Third, simplicity and focus on what the department-level scheduler needs. Drawing colored boxes on spreadsheets is simple, which is the attractive thing about that approach. But a better tool need not be more complex, it can just be better.

Filling the gap

TermPoint was built for exactly this gap. It's a desktop timetabling application for university and college departments: a focused visualization and record-keeping tool that installs like any ordinary program, runs locally, and requires no server, no database project, and no IT deployment. It replaces the parallel spreadsheets with synchronized views, surfaces conflicts as they happen, and leaves the decisions where they belong: with the person who knows the timetable best. And it's at an affordable price that doesn't require still more approvals.

Institutional systems will keep doing what they do well. TermPoint exists for the part they were never designed to do: supporting the scheduler.