Complete guide
How to build a university timetable
The process, in the order it actually happens, with the parts that consume the most time flagged honestly. Written for registrars and timetabling officers rather than for computer scientists.
Before anything else: decide what one timetable means
The first decision is structural and almost everyone gets it wrong at least once. A single timetable should cover everything that shares resources. If two faculties draw on the same rooms, the same staff, or the same modules, they belong in one timetable even if they schedule independently in practice.
Splitting them produces two timetables that must be reconciled by hand every time either changes, which is exactly the work you are trying to eliminate. Split only where the boundary is real: no shared rooms, no shared staff, separate publication.
The six stages
Build the structure
Programmes, years, study areas, modules and the hierarchy connecting them. This is the skeleton everything else hangs from, and getting it wrong is expensive to correct later. Import it from your student information system if you can.
Load the resources
Rooms with real capacities and equipment, buildings with real travel times between them, lecturers with their departments and teaching loads. Estates and HR usually hold better data than the timetabling office does.
Collect availability
The stage that eats the calendar. Do not do it by email. Open a web booking system to your teaching staff and let them enter their own free hours, then chase non-responders with one automated reminder rather than a hundred phone calls.
Define constraints
Separate the rules that must never break from the preferences you would like satisfied. Treating every preference as absolute is the single most common reason a timetable turns out to be unsolvable.
Generate, then argue with it
Lock anything that genuinely cannot move, generate, and look at what came out. Produce two or three variants with different priorities and compare them on utilisation and workload figures rather than on impression.
Verify, then publish
Let lecturers check their own schedules before release — it is far cheaper to fix an objection now than in week one. Then publish to every channel at once from a single source.
Where the time actually goes
Not where most institutions expect.
Ask a timetabling office to estimate effort and they will usually describe generation and conflict resolution as the hard part. Measure it and the answer is almost always availability collection: two to three weeks of chasing, followed by manual data entry, followed by corrections arriving after the spreadsheet closed.
This is why self-service availability changes the arithmetic more than any algorithmic improvement can. If generation already takes under a minute, making it faster saves nothing. Removing a three-week collection phase saves three weeks.
The second largest consumer is integration with systems that were not designed to talk to each other. Budget for it explicitly, and find out early which of your systems have usable APIs.
Common mistakes
- Treating preferences as hard constraints. If everything is inviolable, nothing is solvable, and you will spend the next fortnight overriding your own rules.
- Collecting availability by email. It does not scale past about forty staff, and the data is stale before it is entered.
- Splitting one timetable into several. Any shared resource turns into a manual reconciliation you will do every week.
- Publishing before lecturers verify. Objections that arrive after publication cost far more than objections that arrive before it.
- Publishing a PDF. Students screenshot it in September and are still looking at it in March, three room changes later.
- Never measuring utilisation. You are scheduling your institution's two most expensive resources and producing no data about how well.
A realistic timeline
For a first implementation, cloud infrastructure can be running in a day and training takes three to five days. The full cycle — structure, resources, availability, constraints, generation, verification, publication — typically runs a few weeks, dominated by your data and your integrations rather than by the software.
In subsequent years it is dramatically shorter, because last year's structure carries forward and only the changes need attention.
Want to see this working?
Book a 45-minute online presentation and we will walk through it against your institution's own scheduling problem.