Automating Teacher Cover: How a Substitution Engine Decides Who Covers a Lecture

Every school with a period-based timetable has the same morning. A teacher calls in sick and someone has to work out who covers each of their lectures. Done by hand, that means checking timetables for who is free, remembering who covered yesterday, and hoping nobody is booked twice. The same reliable people end up carrying the load, and nothing records why a decision was made.

We built Teachora to turn that morning into a workflow. This article explains the design, because the same shape works for any "who should take this shift" problem.

Start with hard rules, then rank

The mistake is to treat this as one question. It is two:

1. Who is allowed to cover this lecture? These are hard rules. If any one fails, the teacher is out.
2. Of those who are allowed, who should? This is a ranking.

For a lecture, the hard rules in Teachora are that the teacher is free that period, is on that campus, and is under their limits. Only teachers who pass all three are ranked.

// Illustrative only: the shape of the idea, not production code.
type Teacher = { id: string; campusId: string; freePeriods: Set<number>; coverCount: Counts };

function eligible(t: Teacher, lecture: Lecture, limits: Limits): boolean {
  return (
    t.campusId === lecture.campusId &&
    t.freePeriods.has(lecture.period) &&
    t.coverCount.today < limits.perDay &&
    t.coverCount.week < limits.perWeek &&
    t.coverCount.month < limits.perMonth
  );
}

function rank(candidates: Teacher[]): Teacher[] {
  // Fewest recent covers first: spreads the load.
  return [...candidates].sort((a, b) => a.coverCount.week - b.coverCount.week);
}

Workload caps are the fairness feature

Without limits, "fair" means whatever the algorithm happens to do. Teachora keeps the limits explicit: one extra lecture a day, plus weekly and monthly limits the school sets (two and eight by default). They are settings, not code, because every school has its own idea of fair.

Always allow a human to overrule it

An engine that cannot be overruled gets abandoned the first time it meets a real emergency. Teachora lets an admin assign cover by hand, and lets them override a limit in an emergency, but only with a reason, which is recorded. That keeps the flexibility while leaving a trail you can look at later.

Keep the numbers honest when things change

Plans change. If a leave is cancelled, or a substitution is cancelled, the workload it counted against a teacher has to be released and the cover board cleared. If you only add to counters and never take away, the caps slowly stop meaning anything.

Multi-campus schools

A school with a Main campus and a Junior campus must not mix the two. In Teachora each campus is isolated: its own timetable, staff and cover board, with one place to switch between them. If your schools share staff, decide early whether that is allowed, because it changes the "who is free" rule.

What surrounds the engine

The engine is only useful with the daily plumbing around it: a leaves list and a substitutions board, weekly timetables with conflict checks, roles for admins and teachers, and notifications. Teachora is an installable web app with web push, so a cover decision reaches a phone instead of waiting for someone to open a desktop. It is built on Next.js, PostgreSQL and Prisma, and the scheduling rules are covered by automated tests, which is where we would put the most effort in any version of this.

When to build this

If cover takes a person a meaningful part of every morning, or the same teachers always get the extra work, it is worth automating. If your timetable data is not accurate yet, fix that first: no engine can find a free teacher from a timetable that is wrong.

Want a scheduling or approval workflow built around how your organisation actually works? Talk to Paraline Tech. The full project is in the Teachora.ai case study.