Start With Timetabling. Grow Into the Platform When You’re Ready.

The most common reason a school does not fix its timetabling is not that it likes the two weeks in July. It is that every product offering to fix it also wants to become the system of record for students, attendance, grades, fees and parent communication — and that is a migration, a retraining programme, and a political argument the school does not have the appetite for this year.

So the spreadsheet survives another year. Not because it is good, but because the alternative was quoted as an institutional transformation when all anyone wanted was a working timetable.

That is the gap the AI Timetabling plan exists to fill. It does exactly one job — generate and manage your timetable — and it deliberately does not touch anything else. There is no student record to migrate, because the plan does not manage students at all. Your existing student information system stays exactly where it is, doing exactly what it does. You are buying a timetabling engine, not a platform.

Being concrete about the boundary, because vagueness here is how people get surprised: AI Timetabling is $49 a month, or $399 a year. It covers one school, up to 150 staff, up to 100 classes, and 10 active timetable projects. It includes a 14-day free trial with no card required. It does not include student management, the parent portal, the student portal, Najiba, WhatsApp messaging, payroll or advanced analytics. Those are not degraded in this plan — they are simply not in it.

That constraint is the point. A school with 150 teachers can run its entire timetable on this plan without ever creating a student record, which means the decision is genuinely reversible. If it does not work out you have lost a month’s subscription and nothing else — no migrated data stranded in a system you are leaving, no retrained staff to retrain again.

What tends to happen next is the part worth writing about.

A school that has been timetabling in Skoolia for a term has already done the hard part of adoption without noticing. The staff list is accurate, because an inaccurate one produces a broken timetable. Rooms and their capacities are recorded. The class structure is modelled. Somebody on the admin team has become comfortable in the interface. When the conversation turns to attendance or the parent portal, the migration everyone feared has already quietly happened for the half of the data that was hardest to get right.

At that point moving to a full platform is not a migration project. It is a plan change. The timetable you built does not get rebuilt — it is the same data, in the same system, now with students attached to the classes it already knows about.

The shape of that journey, using a composite example rather than a named customer: a bilingual school outside Lyon, roughly 40 staff and 500 students, running the French national programme alongside an English section. They find a free timetable generator while searching for something to replace a spreadsheet that broke when two teachers went part-time. They use it, see that constraint-based scheduling actually resolves the clash they were stuck on, and start a trial of the standalone plan. For a term, that is all they use Skoolia for — no students in the system, their existing tools untouched.

What moves them is not a sales conversation. It is that the timetable is now the only piece of school data that is reliably current, and everything else is still being reconciled by hand. Attendance is taken on paper against a printed grid that is already one version behind. Parents email the office to ask what their child has on Thursday. The school upgrades — not because the timetabling stopped being enough, but because the gap between the part that works and the parts that do not became the obvious thing to fix. The timetable is not rebuilt; the classes and staff already exist, and students are added to them.

I have deliberately not attached numbers to that scenario. Skoolia is young, the free generator only launched recently, and inventing a percentage would be worth less than the honest shape of the story. When a school agrees to be named and quoted, we will publish that instead.

The practical question is when to move, and there are three signals worth watching. The first is when you find yourself exporting the timetable to make something else work — into the attendance sheet, the cover rota, a parent letter. Every export is a copy that will diverge. The second is when staff or class counts approach the plan’s limits of 150 and 100, which is a signal about the size of your operation rather than about the software. The third is when the person maintaining the parallel spreadsheets starts describing that as their job.

And the honest counter-case: if your student information system works, your parents are happy, and your only pain is the timetable, then stay on the timetabling plan. Consolidation for its own sake is not a strategy. I would rather a school ran one part of its operation on Skoolia for three years than migrated everything in a rush and regretted it — the OneRoster integration exists precisely so schools can keep the SIS they have.

If you want to see the scheduling engine before talking to anyone, there is a free browser-based demo at aitimetablegenerator.com that runs the same constraint logic on a sample school with no signup. If you are ready to schedule your own, the AI timetable generator is what the standalone plan gives you, and the full platform is there when — and only when — the timetable stops being the biggest problem you have.