Custom timetabling software for education
The timetable is where the education programme meets reality: which group takes which subject, taught by which teacher, in which room, at which time. Four kinds of scarcity at once, with thousands of people planning their day around it and a deadline that doesn't move. Appfront builds custom timetabling software for secondary schools, vocational colleges, universities of applied sciences and universities: from prerequisites and clustering through to daily scheduling and publishing every change to everyone who needs to know.
What makes timetabling in education different
A calendar appointment reserves one thing. A timetable allocates four at once: a teacher can only be in one place, a group can only follow one lesson at a time, a room can only house one activity, and a lesson slot occurs only once a week. All four must be free at the same moment, or the lesson cannot exist. A timetable is therefore not a collection of loose appointments but one interconnected structure. Move a single lesson and the puzzle shifts in places you didn't anticipate: the follow-up lesson for the same group, the lab room that is now double-booked, the part-time teacher who doesn't work on Thursdays. That is why timetabling is rarely solved by working harder and usually requires a model.
Are you in the right place? This page deals solely with timetabling: scheduling teaching activities across teachers, groups, rooms and time. If your question concerns student administration, meaning enrolment, curriculum, results and graduation, you want a student information system for higher education. If you are looking at the broader operation, where timetable logistics is one part alongside staff, procurement and the data behind your funding, then education ERP is the wider entry point. There, the timetable is one module in a larger landscape; here, it is the subject itself. A simple rule of thumb helps with that distinction: if the question concerns the status of a person, such as an enrolment, a credit earned or a diploma, the answer belongs in administration. If it concerns who is in which room at what time, it is a timetabling question. The two systems exchange data, which is exactly why the boundary must be clear: enrolment is the source, the timetable is derived from it, and that direction should never be reversed.
Staff planning may also seem related, and the comparison holds up to a point: availability, qualifications and contract hours matter in both. Yet it is a different puzzle. In a business, you roster people against demand you forecast, and you can run a shift with one fewer person if needed. In education, the demand is fixed by the curriculum, and it is matched by a second party that cannot be duplicated: the group itself. A lesson without a class or without a room does not exist, and nobody judges a business roster by the gaps between customers' visits.
Four kinds of scarcity at once
Teacher, group, room and time slot must all be free. One occupied element and the lesson cannot go ahead.
One change affects hundreds of diaries
A lesson that moves changes the day of pupils, teachers, parents, reception and the screens in the hall.
Quality is a management decision
Fewer gaps for pupils often come at the expense of teacher preferences. The timetable makes that choice visible.
Hard and soft constraints
Everything in a timetable falls into two kinds of rule, and that distinction shapes what your software should look like. Hard constraints are the rules whose breach makes the timetable unworkable. A teacher cannot be in two places at once. A group cannot attend two lessons in the same period. A room cannot host two activities. No more pupils can sit in a room than there are seats. A teacher who does not work on Thursdays does not teach on Thursdays. A practical session takes place in a room with the right facilities, and a group does not walk across town to a building on the other side during the break between two lessons. If such a rule is broken, you do not have a mediocre timetable but one that falls apart on Monday.
Soft constraints are the preferences that determine whether the timetable is experienced as good. As few gaps as possible for pupils. A subject spread across the week rather than three hours in a row. No days that start at eight and finish only after the last period. Fixed rooms per department, so materials need not be carried to every lesson. Consecutive working days for part-time teachers. Practical subjects scheduled in the block where the related theory has already been covered. These preferences are not optional, as they shape how your organisation is judged, but they can be traded against one another: you can let a few drop and still end up with a working timetable.
In practice, the distinction means this: hard constraints determine whether a timetable exists at all, while soft constraints determine whether it is accepted. Both must be stated explicitly in the system. Where that doesn't happen, they migrate into the head of the timetabler, and that is precisely why schools grind to a halt as soon as that person leaves or falls ill. Equally important is honesty about which rule belongs in which category. Every wish entered as hard shrinks the solution space, and many timetables described as "impossible" are in fact over-specified: a preference that has been written down as a requirement. Conversely, a hard rule can sometimes be shifted after all by adjusting something on the other side, for instance by splitting a group or freeing up an additional room.
Weighing is an administrative choice, not a technical one
Once wishes contradict one another, and they always do, someone has to decide what carries more weight. Software cannot make that decision for you; it can, however, make the choice visible and repeatable. This is done by assigning each soft constraint a weight and summing those weights into a single score, so that two timetable variants can be compared with each other rather than judged on gut feeling. The value of this lies in the conversation it enables: if the board wants to know what it would cost to halve the number of free periods in the upper years, the answer should be expressed in the wishes that would have to be sacrificed to achieve it.
These same weights have a side effect that is often underestimated: they make the timetable explainable. A teacher whose wish has not been granted will accept that considerably more readily if the system shows which wishes were counted and how heavily. Without that justification, the discussion shifts to the person who made the timetable, and that is an unfair position to put them in.
What a solver does and does not do for you
Timetabling is known in computer science as a computationally hard problem: the number of possible combinations grows so rapidly that checking every variant is not a feasible route. Timetabling software therefore searches intelligently rather than exhaustively. It first places whatever is most constrained, then systematically swaps lessons around for as long as the score improves, and delivers a good solution without proving that no better one exists. That is not a shortcoming; it is the nature of the problem. It does, however, have consequences for what you should expect from your software.
The most important thing is that the timetabler remains in control. They must be able to lock parts of the timetable and have the rest recalculated without losing yesterday's manual work. They must be able to place variants side by side and revert to an earlier version. And if no solution is found, the message "no timetable found" is useless. What they need is a diagnosis: which lessons together require more practical room than is available on Tuesday afternoons, which teacher is needed in too many places at once, which cluster of elective subjects cannot be placed with this staffing. Only then does the conversation with the faculty become a conversation about a solvable problem. The final few percent will remain manual work, and that is perfectly fine; the goal is that those hours go to the exceptions rather than to filling in the obvious.
What timetabling software for education must be able to do
These elements are connected. Constraints without good source data produce a neatly calculated timetable that does not match your school, and a perfect timetable that does not reach the pupil in time is still a problem on Monday morning. The integration with administration belongs in from the start: enrolments, groups and appointments are kept elsewhere and should flow in here rather than being retyped.
Constraints with weights
Record rules as hard or soft, with a weight and a scope: institution-wide, per programme, per location or per teacher.
Clustering elective subjects
Derive from pupils' subject packages the groups and clusters, with a clash analysis before the choices become final.
Rooms by capacity and facilities
Allocation that considers seats, room type, facilities, accessibility and the distance between buildings.
Daily timetables with cover
Record absence, excursions and room unavailability, and make a choice for each lesson: cancel, merge, move or take over.
Publishing to every channel
A single change that goes live at the same time in the app, the portal, the in-building screens and the calendar subscription.
Versions, scenarios and traceability
Place variants side by side, revert to an earlier version and see for each change who changed what and when.
The sources that must be right before you can timetable
A timetable is a derived product. It only exists when four registers are in order: the people, the groups, the rooms and the course offering. Timetabling projects that struggle rarely get stuck on the algorithm, and almost always on these four. That is good news, because this part is not difficult, only unforgivable when it is skipped.
For people, it is about more than names. For each teacher, the subjects they are qualified to teach should be fixed, along with the size of their appointment expressed in teaching and workload hours, the days on which they are available, and the tasks outside lessons that take up just as much time: mentoring, coordination, supervising placements. If that last part is missing, someone may appear to have capacity they do not have. This register is also the least stable of the four, because appointments continue right up to the start of the year, and the timetable needs to be able to keep moving with them.
The course offering is the register that most often stays implicit. You need the subjects or units of study, the number of contact hours per week or per period, and the teaching formats they are delivered in. That last point matters more than it seems: a lecture, a seminar and a practical class for the same subject each have a different group size, a different room type and sometimes a different lecturer. Then there are the links you must not break, such as lessons that must be back to back, or a practical that may only fall after the theory block.
Groups form the third register and are the most confusing, because several kinds exist side by side. There is the home group or class to which a pupil is administratively attached, there are teaching groups that differ from it as soon as a subject is taught in smaller units, and there are groups that arise only from choices made. In higher education, the distinction between lecture groups and seminar groups is added to that. All these groups should be derivable from the enrolments in the administration, with an indication of which kind each one is. Where that does not happen and groups are maintained by hand, the timetable quietly drifts out of step with actual attendance.
Rooms are more than a number of seats
A room list that only holds a room number and a number of places forces the timetabler to fill in the rest from memory. You also need the type of room, the facilities present, accessibility and the position within the building. A practical room with extraction, a workshop with machinery, a computer room, a sports hall and a studio are not interchangeable square metres. Capacity, moreover, is not a single figure: a hall that holds forty students for a lecture accommodates considerably fewer people for an exam, and seating arrangements for exams are a problem in their own right, closely related to examination software. A room with a fixed layout also rules out some teaching formats. Distance matters too, since consecutive lessons in two buildings produce a timetable that is correct on paper but starts late in practice.
This list deserves a single owner and a simple change procedure, or it quietly goes out of date. Almost every institution has rooms that have been refurbished, let out or fitted out differently, and the timetabler knows this but the system does not. What helps is closing the feedback loop: whoever measures afterwards how full each room was will soon discover which rules in the list no longer hold.
Elective subjects and the group allocation that follows
As soon as pupils or students make their own choices, the trickiest part of the puzzle begins. In secondary education this means profiles and subject packages, in vocational education qualification units, and in higher education electives and minors. These choices sit in the administration and determine two things at once: how many groups are needed per subject, and which subjects may run at the same time on the timetable.
The number of groups follows from the number of enrolments and the maximum group size, and the remainder rarely divides neatly: 53 pupils with a maximum of 28 gives two uneven groups, and opting for three costs an additional teacher and an additional room. Next comes clustering. Subjects chosen by different pupils in the same year group are deliberately scheduled at the same time, so that everyone goes to their own elective during that period. Such a cluster only works if no pupil has two subjects from the same cluster in their package. One unfortunate combination, chosen by a handful of pupils, can make an entire cluster impossible.
That is why the clash analysis should take place before the choices are confirmed, not afterwards. Software that shows, from the provisional choices, which combinations make the timetable expensive gives the institution the chance to steer: open a second group, stop offering a combination, or offer a single pupil an alternative. If that only happens once all packages are fixed, the only remaining solution is the most costly one.
- Qualifications, appointment and teaching hours per teacher, up to date for each period
- Groups that follow from enrolments, not from a separate list
- Rooms with type, capacity and facilities, with a single owner
- Course offering with working methods and contact hours per period
- Subject packages with a clash analysis before choices are fixed
- One source per data item, with visible origin and date
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →The day itself: absence, room changes and publishing
The annual timetable is a snapshot that comes under pressure from the very first school day. A teacher reports sick at ten past seven. A room is closed after a leak. There is a field trip, a test week, an open day, a guest lecture that moves, a group that has to go to another room for a project. Each event calls for a decision per lesson, and those decisions are limited in number: cancel the lesson, merge the group with a parallel group, have a colleague take it over, have the pupils work independently under supervision, or move the lesson to another time. Which of those five is appropriate is partly policy and partly arithmetic. Policy, because many schools do not accept dropouts in the lower years but do in the upper years. Arithmetic, because the system must know who is free, qualified and present at that hour.
Timetabling for a single day is a different exercise from annual timetabling, and software that ignores that difference will not be used. With the annual timetable you look for the best possible solution and you have time to find it. With the daily timetable you look for the smallest possible disruption, and you have minutes. Recalculating everything is exactly the wrong answer: it moves lessons that nobody needed to move. What the person making the daily timetable needs is an overview of the consequences before they choose. Which groups end up without a lesson, which pupils gain a free period, which room becomes available, and which colleagues are free without making their own day unworkable. And once the choice has been made, it should be fixed who made it, because the daily timetable is where agreements about workload are tested in practice.
Publishing to everyone is the real work
The change itself takes a minute. Making sure everyone it concerns sees it in time is the actual work. A single shifted lesson should be known to the pupils, their parents in the case of structural changes, the teachers involved, the colleague covering, reception, the caretaker and the screens in the hall. As soon as each of those channels keeps its own copy of the timetable, the classic mistake arises: two versions of the truth. The app says room 2.14, the screen says 1.09, and the pupil who opened the portal before the change was published is somewhere else entirely. The only lasting solution is a single publication source from which all channels draw, with a version and a timestamp, so that it can be traced afterwards what went out, and when.
The moment of publication matters at least as much as the content. A change for the first lesson that appears at five past eight reaches no one in time; the same message helps if it goes out before people leave home. Equally decisive is targeting. Whoever sends everything to everyone teaches their users to ignore notifications, and then the pupil for whom the message was intended misses it too. Timetable changes should therefore go to those affected, with a brief reason attached, because "changed" raises questions that would otherwise end up with the administration. For the calendars of teachers and students, a calendar subscription is the most convenient form: the open standard for this is iCalendar, defined in RFC 5545. With one caveat, however: the moment of retrieval is determined by the calendar app, not by you. A subscription is excellent for next week's timetable and unsuitable as the only channel for a change made this morning.
The timetable as realised is your measurement
Whoever keeps only the planned timetable measures, after the fact, a school year that never took place. Only once absences, cover and room swaps are recorded does the realised timetable emerge, and that is the record you can steer by. The first question it answers concerns your building. Room occupancy is not a single figure but the product of two things: how often a room is in use within the hours the building is open, and how full it is at those times relative to its capacity. A lecture hall that is booked all week but half empty, and a practical room that is full two mornings and stands empty otherwise, can score the same on an average while calling for opposite measures.
That is why the breakdown matters more than the total: by building, by room type and by part of the day. Nearly every institution finds the same pattern, namely Tuesday and Thursday mornings full and Friday afternoons empty, and that distribution can be influenced with timetable rules before anything is built or rented. The second thing that underpins the realised timetable is teaching time. In secondary education, the Wet voortgezet onderwijs 2020 (Secondary Education Act 2020) sets out in Article 2.38 that the vwo stream comprises at least 5,700 clock hours, havo at schools offering havo at least 4,700, and mavo and vbo at least 3,700 each, with at least 1,425 clock hours in the first two years combined; Article 2.39 requires that teaching is provided on at least 189 days per school year. That same Article 2.38 obliges the competent authority to hold organised data on how those clock hours are filled and spread. A timetable that retains its realised form provides that evidence as a by-product, rather than as an annual search.
Bear in mind that timetable data is personal data: it shows where an individual teacher or pupil was at a given moment. For occupancy analyses you do not need that level of detail. Work with aggregated figures instead, and do not keep traceable data for longer than you use it for, in line with what the GDPR requires of you. This is not a brake on the analysis; mostly it saves debate about a dashboard that shows too much.
When an off-the-shelf package is the better choice
Timetabling is not a blank spot in the software market. There are mature timetabling packages that focus explicitly on Dutch education, with versions for secondary, vocational and higher education, and with integrations into the common pupil administration systems. For many of the institutions reading this page, such a package is the more sensible route, and we would rather say so now than halfway through a quote process.
If your teaching follows the familiar pattern of lesson hours, year groups, clusters and periods, you buy that ready-made, including maintenance and the adjustments that follow from changed regulations. Your effort shifts from building to configuring. Do not underestimate that second part: the quality of a timetable lies in its constraints and source data, and no package fills those in for you.
Custom software pays off in fewer situations than vendors suggest, but there are a few where it is clearly the better choice. The strongest is an educational model that does not fit the thinking behind off-the-shelf packages: learning routes that students compose themselves each period, timetables that run in day parts or blocks rather than lesson hours, work placements and internships where external parties help plan, or teaching that is structurally spread across varying locations. Trying to force such a model into a package form means losing precisely the part that sets it apart. The second situation lies on the outside: institutions that are satisfied with the timetabling core but get stuck on everything around it, that is, the app, the screens, communication with parents and the integrations. The third is the wish to combine timetable data with room management, lettings or facilities planning, so that the timetable is no longer only an education question.
Often the middle path is the best answer: a package as the timetabling core, custom software at the edges. Then there is one question you should ask early, namely whether that package makes its data available through a usable programming interface and whether you are allowed to write back to it. If that answer disappoints, the middle path is more expensive than it looks. The flip side of building yourself is also part of the picture: keeping up with changing rules and with your own educational model then rests with your organisation, and the academic year is unforgiving. The timetable has to be ready when the year starts, and that date does not move just because a system is not finished yet.
If you want to weigh this decision seriously, do not start with a package comparison but with your own rules. Put on paper which constraints are genuinely fixed for you and which are preferences, name who sets the weighting between them, and describe how a change today reaches a pupil. That document works in both directions: it is the basis for selecting a package and, at the same time, the functional design for custom work. It also exposes where the real pain lies, and in a surprising number of institutions it turns out not to be the timetabling itself but the data that precedes it or the communication that follows.
If you use Xedule and want the timetable in your own app or on screens, there is our page on a Xedule integration.
If you want to record lesson cancellations and cover straight away, so that the accounting of teaching time is correct, look at our app for teaching time and lesson cancellations.
For caretakers, teaching assistants, behaviour and attendance officers and invigilators, there is our software for rostering support staff.
- A package if your education follows the usual pattern of lesson periods and clusters
- A package if the source data first needs to be brought in order
- Custom development for an education model that packages do not support
- Custom development if publication and communication are the bottleneck
- The middle way: a package as the timetabling core, custom work at the edges
Frequently asked questions about timetabling software
Hard constraints are rules whose violation makes the timetable impossible to carry out: a teacher cannot be in two places at once, a group cannot follow two lessons in the same period, and no more pupils can be placed in a room than there are seats. Soft constraints are preferences that determine quality, such as as few gaps in the day as possible or a subject spread across the week. Hard rules determine whether a timetable exists at all, soft ones whether it is accepted. Be strict in this division, because every preference entered as a requirement shrinks the space of possible solutions unnecessarily.
Usually because the problem is over-specified: more hard requirements are entered than can all be true at once, often because preferences have been written down as requirements. Sometimes there is genuinely too little capacity, for example one practical room too few on Tuesday afternoon. In both cases the message 'no timetable found' does not help you further. What you need is a diagnosis that identifies which requirements contradict each other and which room or teacher is short, so that you can choose between dropping a requirement, splitting a group or adding capacity.
The choices pupils make determine two things: how many groups are needed per subject and which subjects can be scheduled at the same time. Subjects chosen by different pupils from the same year group are brought together in a cluster that runs at the same moment, so that everyone goes to their own subject during that period. This only works if no pupil takes two subjects from the same cluster. Good software therefore works with the provisional choices to calculate which combinations clash, so the school can adjust before the packages are final.
For each lesson, you have to choose: cancel it, merge it with a parallel group, have a colleague take it over, let students work independently under supervision, or move it to another time. The software should show who is free and qualified at that hour, which groups would otherwise be left without a lesson, and which room becomes free. More important still is what happens next: the change should reach the app, the portal, the screens in the building and the teachers concerned in a single action, with a timestamp, so that two versions of the truth don't emerge.
In workforce planning, you schedule people against a demand you forecast, and a shift can, if necessary, run with one person fewer. In education, the demand is fixed by the curriculum, and it is matched by a second scarce resource that you cannot duplicate: the group itself. On top of that come the room with the right facilities and the fixed lesson slot, so four elements have to be free at the same time. Availability, qualifications and contract hours play a role in both puzzles, but software that only looks at how people are deployed does not solve the educational problem.
Often, yes. Mature timetabling packages exist for the Dutch education sector, with integrations to the common student administration systems. If your education follows the pattern of lesson hours, year groups, clusters and periods, you can buy that off the shelf. Custom software becomes interesting with an educational model that packages do not account for, such as learning routes that students compose themselves or timetables in day parts, and for institutions that are satisfied with the timetabling core but get stuck on publishing to apps, screens and parents. The middle path, a package as the core with custom software at the edges, stands or falls with a usable programming interface.
Related services
Student information system
If your question concerns student administration itself, so enrolment, curriculum, study credits and certification, you need a student information system for higher education. That is where the enrolments come from on which this timetable is built.
Education ERP
If the question reaches beyond the timetable, to enrolment and placement, staff, procurement and the data behind your funding, then building education ERP software is the broader entry point.
Staff planning software
If it concerns shifts, rosters, leave and qualifications in a business environment rather than lessons and groups, then custom workforce planning software is a better fit for your question.
Taking a close look at your timetabling process
Tell us how your timetable is currently drawn up: which rules are truly hard for you, where the choices of pupils or students lock the puzzle in place, and what happens when a teacher calls in sick at ten past seven. Those three answers usually show whether a package, custom development or a combination fits best.