Operations
Detecting and resolving timetable clashes
Most institutions check for room double-bookings and stop there. The clashes that cause actual damage are the ones a room-level check cannot see.
Six kinds of clash, in rising order of embarrassment
- Room double-booking. Two sessions, one room. Everyone checks for this.
- Lecturer double-booking. One person, two rooms, same hour. Usually caught, occasionally not where a lecturer teaches across faculties.
- Group double-booking. One student cohort scheduled twice. Caught when groups are modelled properly, missed when they are not.
- Capacity violation. The group no longer fits the room. Frequently missed, because enrolment changes after the timetable is built.
- Travel impossibility. No overlap by any conventional definition, and still impossible — ten minutes between buildings twenty minutes apart.
- Individual student clash. No group collides, but the eleven students taking an unusual elective combination have two exams at once. Almost never caught before the day.
Why individual-level checking matters most for exams
In a teaching timetable you schedule groups, and group-level checking is usually adequate. In an examination timetable every student's combination of modules is potentially unique, so group-level checking is structurally incapable of finding the problem.
This is the single most common serious failure in academic scheduling, and it is discovered by a student sitting an exam rather than by an administrator running a report. Exam scheduling needs student-level clash detection across every module combination, not a group check. More on exam scheduling.
Test the swap before you make it
The everyday version of this problem is the exchange. You want to move two sessions past each other and cannot tell in advance whether it is possible, so you try it, discover a downstream clash, and unpick it.
A conflict control tool that evaluates a proposed swap and tells you immediately whether it is feasible — and if not, what blocks it — turns an afternoon of trial and error into a few seconds of checking. That is the single most-used feature in most timetabling offices after generation itself.
- Instant feasibility feedback on any proposed exchange
- The blocking constraint named, not just a refusal
- Automatic resolution offered where a clean solution exists
- Deliberate, recorded overrides where you decide the rule should bend
Exceptions, recorded rather than hidden
Sometimes breaking a rule is correct. A professor agrees to an extra hour; two groups genuinely can share this once. The important thing is that the exception is deliberate and recorded, so it does not quietly become the new normal and so the next person to look at the timetable knows it was a decision rather than an error.
Want to see this working?
Book a 45-minute online presentation and we will walk through it against your institution's own scheduling problem.