Your timetable was correct on Monday morning. By Wednesday four new students have started, two have moved up a level, one group has outgrown its room, and a Friday afternoon class has quietly dropped to three students. Language academy timetabling is not a puzzle you solve in August and live with until June — it is a process you run every week, for as long as the academy is open.
That is what most scheduling advice gets wrong. It treats the timetable as an optimisation problem with one correct answer, when in an academy running rolling intakes no answer survives next Monday's arrivals.
By the end you will know which constraints actually bind, how to build a timetable that absorbs change instead of breaking under it, what to do when a student changes level mid-course, and why software designed for school terms falls apart here.
A school builds a timetable once. An academy never finishes one.
In a secondary school, timetabling is an annual event. You know the cohort in June, you build the grid over the summer, and barring a resignation it holds until the following year — with room allocation, staff contracts and reporting all resting on that stability.
A language academy has none of it. Students enrol in any week of the year, for two weeks or for nine months. They start at a level set by a placement test, not by their date of birth, and they move up whenever they are ready, which is almost never a tidy date. Some are on a fixed programme; others renew month by month and decide in the last week whether they are staying.
So the Monday ritual is not "check the timetable". It is "rebuild the parts of it that moved over the weekend" — a Director of Studies with four spreadsheet tabs, one each for groups, teachers, rooms and the arrivals admissions confirmed on Friday, reconciling all four before the first class starts. That work does not scale with student numbers. It scales with the number of changes, and changes grow faster than enrolments do.
Why software built for semesters breaks here
Most timetabling tools were designed for institutions with terms. That one assumption produces three failures, and you will meet all of them.
It assumes a fixed start and a fixed end
Term-based systems model a course as a container: a start date, an end date, and a roster set at the beginning and closed. A student who joins in week six is an exception the system was never designed for, so you either backdate them and corrupt the attendance record, or leave them off the register and lose them.
The workaround academies land on is to create a new course every month. Now the same B1 group exists as eight separate objects, each holding a slice of the attendance history, and nobody can answer "how long has this student been at B1" without opening all eight.
It treats level as a year group
School systems assume a student's group follows from their age and changes once a year. In an academy, level follows from ability, it is reassessed continuously, and two students who arrived on the same day can be three levels apart. Anything that models the group as a fixed attribute of the student, rather than a membership with a start and an end date, will fight you every week.
It rebuilds instead of moving
The test to run on any system you are evaluating: ask how a student moves from one group to another mid-course. If the answer involves unenrolling them and creating a new enrolment, it does not fit your operation — you lose their record's continuity every time somebody progresses, which here is the desirable outcome, not an edge case.
School platforms and booking tools disappoint academies for opposite reasons: one assumes the timetable is stable, the other treats every class as an independent appointment with no concept of a level or a progression. Software for language academies has to hold both ideas at once — a stable weekly structure, with a student population moving through it.
The constraints that actually bind
Timetabling looks like it has hundreds of constraints; a handful decide almost everything.
Level and group composition. A group works only if the students in it are close enough in ability to be taught together, and that sets how many groups you run — and therefore how many rooms and teachers you need. Widening a level band to avoid opening a group is the quiet mistake of academy timetabling: it costs you later, in retention and complaints nobody traces back to the timetable.
Rooms and capacity. Capacity is not one number: a room seats more for a standard class than for one needing pair work or space to move, and two groups share it across a day only if their patterns line up exactly. Run out of rooms and you get no warning — you get a teacher standing in a corridor with eight students.
The pattern the student bought. Morning, afternoon and evening are not interchangeable. Someone on an intensive programme, someone who works and comes at 18:00, someone whose agent booked a specific pattern — none can be shuffled to balance your grid. Treat the pattern as fixed and the group as the variable.
Teacher availability. Availability windows, hour targets and cover for absences are a discipline of their own; for building the grid, take availability as a hard input.
Contact hours and accreditation. If your centre is accredited, or enrols students on a study visa, the timetable is also a compliance artefact: delivered hours and recorded attendance may have to satisfy rules set by your accrediting body or national authority. Get those rules from the body itself, not from what your software permits, and design the timetable so the evidence falls out of daily operations rather than being reconstructed before an inspection.
Build for change, not for optimality
Once you accept that the timetable will be edited every week, the goal changes. You are not looking for the best possible grid — you are looking for the one that is cheapest to change.
Timetable slots, not one-off classes. Define a recurring weekly structure — this level, this pattern, this room, this teacher — and let student memberships start and end inside it. A new student is added to a slot; a progressing student ends one membership and starts another. The structure survives and only the membership moves.
Give every level a predictable entry point. Rolling intakes feel chaotic mostly because entry is unconstrained. Decide, per level, when a new student can join a group, and publish it. The frequency matters less than the fact that admissions can promise a start date without phoning the Director of Studies first — no other change removes as much timetabling work.
Leave slack on purpose. A timetable with every room booked and every teacher at their maximum cannot absorb the next arrival, and the next arrival is coming. Agree in advance the minimum size at which a group is viable and the maximum at which it stops being teachable, then keep a margin below that ceiling. Unbooked room-hours are what let you say yes on a Friday without a rebuild.
Keep one source of truth. If the timetable lives in a spreadsheet, on a wall, in the teachers' WhatsApp group and in admissions' emails, you are maintaining four copies and they will disagree by Thursday. That is what academic management software is for: one structure of classes, levels, periods and calendars with teachers and rooms attached, so publishing follows from the change instead of being a second job.
What happens when a student changes level mid-course
A student finishes B1 on a Wednesday and is ready for B2. In a spreadsheet stack that single decision means removing them from the B1 sheet and adding them to B2, checking B2 has a seat and the room can take one more, telling both teachers, correcting the register so Thursday's attendance is taken in the right class, updating the student's own copy of their timetable, noting the change on their progress record so their certificate reflects the levels they completed, and telling the agent or the family. Each is a separate edit in a separate place, made by a different person, and any one can be missed. The failure mode is undramatic: a student sitting in the wrong classroom, an attendance report showing a gap that never happened, a certificate that undercounts what they did.
In a system designed for this, the level change is one action. The old membership ends on a date, the new one begins on the next, and everything else follows — registers, room counts, the student's timetable in the app, the history on their profile. Nothing is retyped, and the attendance record stays continuous across the move. That continuity is the point: that history is what an inspector, an agent or a student disputing a certificate will ask for.
What changes when you open a second site
A second location does not double the timetabling work; it changes its shape. What you need is one timetable with a location dimension, not two timetables that meet in a monthly report, and a level ladder standardised across sites so a student moving between campuses is a transfer rather than a fresh enrolment. NED College runs Dublin and Limerick with around 1,500 students; how multi-site academies approach this is covered in the KMPUS customer stories.
What this looks like with a system built for academies
Timetabling stops being a weekly reconstruction and becomes a set of small edits. Classes, levels, periods and academic calendars live in one place with teachers and classrooms assigned to them. Attendance is taken against the group the student is actually in today, and their full history — levels, results, evaluations, movements — stays on one profile however many groups they pass through. New students arrive already attached to a start date and a level, because online enrolment feeds the same system rather than an inbox, and everyone sees their current timetable in the mobile app, so a Wednesday change is visible on Wednesday.
None of that optimises the grid for you, and it should not. Whether to open a new B2 group or hold a student one more week is academic judgement and belongs to your Director of Studies. What software removes is the retyping that follows each of those decisions — which is most of the week's work.
Frequently asked questions
How often should a language academy rebuild its timetable?
Ideally never. A well-structured academy timetable is amended continuously — memberships start and end, groups open and close — while the weekly structure underneath is left alone for as long as it works. If you rebuild from scratch every month, that structure is fitted too tightly to last month's students.
Can timetabling software generate an academy timetable automatically?
Automatic generators solve the school problem: a known set of students, subjects and constraints, solved once. They can produce a starting grid, but in a rolling-intake academy it is stale within a week, and the decisions that matter most — whether a student is ready to move up, whether a group of five is worth running — are pedagogical and commercial, not mathematical. Automate the propagation of a change, not the decision to make it.
Is scheduling software enough, or do we need a full platform?
A booking tool is enough when classes are independent appointments, which is closer to how private tutors work. An academy with levels, progression and a fee attached to every enrolment needs the timetable connected to student records, attendance and billing — otherwise the retyping just moves to a different desk.
If your timetable is rebuilt every Monday in a spreadsheet, see what it looks like in a system designed for rolling intakes and constant level changes: start a free trial of KMPUS, no credit card required.
