Teacher scheduling, coverage, and workload management
The operations side of managing teachers — scheduling, coverage, and duty assignment — built on one shared engine.
Every school has the same daily puzzle: who is teaching which period, who steps in when someone calls out, and whether the coverage burden falls fairly across the staff. Today that puzzle is usually solved with a phone tree, a paper duty roster, and a sub-coordinator whose job is an undocumented art form. This platform brings teacher scheduling, substitute and coverage assignment, and workload and duty tracking onto one canonical slot engine — the same engine that already runs eight K-12 booking surfaces — so an administrator can see who is where, who covers the gap, and who has which duty, in one place. Here is exactly what is built and what is still coming.
The scheduling engine, coverage-equity computation, and staff roster are built. The dedicated substitute-fill UI and leave surfacing in the staff command center are in progress. We say so rather than presenting early work as finished.
What this is — and what it is not
Teacher Management is the operations side of the teacher record: scheduling, coverage, substitutes, and workload and duty assignment. It answers the question an administrator faces at 7:30 a.m. when a teacher calls out: who covers third period, does that person already have a duty this week, and how do we log the leave?
It does not answer whether a teacher is certified, how many PD hours they have logged, or when their next evaluation is due. Those questions belong to educator.management — the staff and professional development side, which just shipped its own HR and evaluation engine. The two surfaces share one staff roster and one slot engine underneath; they do not overlap in what they surface.
It also does not cover teacher development, mentorship, or onboarding pathways — that is teacher.farm. And it does not touch payroll; payroll processing is deliberately out of scope for this platform and is named as such, not hidden.
What is built
The modules below are code that exists and runs. Ones marked “in progress” are being built on top of foundations that are already shipped.
The scheduling core — eight K-12 surfaces, one engine
The schedule.software scheduling core is a single canonical slot, booking, and availability primitive that all eight K-12 booking surfaces are built on: period scheduling, picture-day slots, room and facility booking, senior portrait sessions, conference appointments, and the rest. Staff scheduling and coverage assignment are the same primitive applied to the teacher roster — a period slot with an assigned teacher, an availability window, and a conflict gate. The engine is built. The staff-scheduling surface that exposes it to an administrator is the layer being built on top. Shipped
The staff roster with roles and per-school memberships
The official staff list for a school — with roles (administrator, adviser, staffer), hire dates, departments, positions, and per-school assignments. An administrator can bind a new staffer, re-grade a role, and withdraw a departing employee; the change reflects everywhere the record is read. Scheduling, coverage, and duty assignment all bind to this roster. A staff member's assignments, their availability, and their duty record are all scoped to the school tenants their roster entry covers. Shipped
Coverage-equity computation
When a period goes uncovered, the system can compute coverage-load distribution across the staff: how many coverage assignments each eligible teacher has taken in the current period, their current duty count, and their scheduled load. The equity computation surfaces who has the lowest coverage burden among eligible staff so the administrator can make an informed assignment rather than defaulting to the same three people every time. The computation is built. Shipped
The staff cockpit workload snapshot
The whole-program staff cockpit gives an adviser or administrator a per-staffer accountability picture: how many assignments are open, how many are overdue, and how recently the staffer has been active. Applied to teacher workload, this is the starting view of who is carrying what: an administrator can read the load distribution across the department before making a new assignment or coverage request. The cockpit is built. Shipped
Leave balances and leave requests
Leave balances (accrued and used days, not money) and leave requests (dates, leave type, days requested, and approval status) are modeled in the HR persistence layer. The routes to record a balance and log a request are built. When a teacher submits a leave request, the system has the data to flag the affected periods as needing coverage. The persistence model is built; the surface that exposes leave balance and request history in the staff command center is in progress. Shipped — staff command center surface in progress
Substitute and coverage assignment
When a teacher is out, the system has the open slot (from the scheduling engine), the leave record, and the roster of available staff with their current load. Substitute or in-house coverage assignment is the act of filling that slot from those inputs. The slot engine and the leave model are built; the dedicated substitute-fill workflow — the surface where a coordinator sees the open period, the eligible staff, their load, and makes the assignment — is actively being built on top of these foundations. In progress
How the pieces fit together
The teacher management layer is not a separate application sitting alongside the school's other systems. It is a set of surfaces on top of the same shared data model that drives the rest of the platform. The staff roster, the slot engine, and the leave model are the same rows that back the publication workflow, the picture-day booking, the senior portrait session, and the HR evaluation cycle. An administrator does not maintain a separate scheduling system; they work inside the same record that the rest of the platform already reads from.
When a teacher is added to the roster, they are immediately eligible for scheduling, coverage assignment, and duty tracking. When they request leave, the leave record ties directly to the slot model so the system knows which periods are uncovered. When a coverage assignment is made, the equity computation records it so the next assignment can be distributed fairly. The data flows from one place to the next without a manual re-entry step.
The scheduling core — the one canonical slot, booking, and availability primitive — is what makes this possible. The same engine that books a senior portrait session knows how to express a teacher's period assignment, a room's availability window, and a substitute's open slot. Building eight different booking surfaces on one engine is the work that has already been done at schedule.software; teacher scheduling and coverage assignment are surfaces that reuse it, not a new engine that has to be written from scratch.
The coverage-equity computation sits on top of the scheduling and roster layer. It does not introduce any new data model; it reads the existing assignment records and computes the distribution. An administrator who wants to know who should cover third period today gets an answer drawn from real assignment history, not a guess or a manually maintained spreadsheet.
What is in progress and what is planned
These are not presented as available today. They are named so a school considering this platform can see the honest build trajectory.
The substitute-fill workflow surface
The dedicated surface where a coordinator sees an uncovered period, the eligible staff with their current coverage load, and makes the assignment — logging the coverage, updating the equity record, and sending the notification — is the primary in-progress work. The slot engine, the roster, the leave model, and the equity computation are all built; this surface is the interface that brings them together for the coordinator making the 7:30 a.m. call. In progress
Leave surfacing in the staff command center
The leave balance and leave request data model is built and the persistence routes exist. The surface that lets a teacher see their own leave balance, submit a request, and let an administrator review and approve it — inside the staff command center rather than through a separate HR form — is the next step in the leave module build-out. In progress
Duty-roster assignment and tracking
Duty assignments — hall duty, lunch supervision, morning arrival, afternoon dismissal — follow the same equity model as coverage: each duty type is a slot, each assignment records who took it and when, and the distribution is computed from the record. The data model is the same slot-and-assignment primitive that the scheduling core provides. The dedicated duty-roster surface that exposes this to an administrator is planned. Planned
Scheduling conflict detection across the staff roster
When an administrator schedules a teacher for a period, the system should check for conflicts against that teacher’s existing period assignments, leave record, and duty assignments in the same time window. Conflict detection across the full staff roster — the surface that flags a double-booking before it is saved — is a planned layer on top of the built slot engine. Planned
Automated coverage notification
When a coverage assignment is made, the substitute or covering teacher should receive a notification with the period, the room, and the relevant information. The notification model is part of the platform’s communication layer; the specific coverage-assignment trigger that generates and routes it is a planned connection between the substitute-fill surface and the notification layer. No communications provider is connected today; the architecture has the seam. Planned
Payroll
Payroll processing — computing stipend pay for extra duty, disbursing funds for substitute days — is deliberately outside the scope of this platform. The system records the assignment and the leave event; the actual payroll computation belongs to a dedicated payroll provider. This is a boundary held on purpose, not a gap to close. Not in scope
Who uses each part
The scheduling surface, the coverage-fill workflow, the duty roster, and the leave approval flow are administrator tools. A building principal or assistant principal is the primary actor: they own the period schedule, they fill coverage gaps, and they approve leave. The coverage-equity computation exists to help that administrator distribute the burden fairly rather than defaulting to the same available teachers every time.
A department head or scheduling coordinator has a narrower read on the same surfaces: the period assignments within their department, the coverage load for their staff, and the open slots in their area. The role model enforces what they can assign versus what they can only read; an adviser cannot re-assign a period for a teacher outside their department.
A teacher interacts with the leave and duty-acknowledgment surfaces: they can see their own leave balance, submit a leave request, and acknowledge a duty assignment. They cannot read a colleague’s leave balance or coverage history. Their own workload picture — their period schedule, their current duty assignments, and their coverage count for the period — is visible to them in the staff command center.
Studio and photography representative sessions are hard-denied access to all of these surfaces. A rep session never sees a teacher’s period schedule, their leave record, or their coverage history. The staff record is HR-gated at the session layer; the teacher management surfaces are invisible to the studio side of the platform regardless of what the request carries.
Student data does not touch any part of this layer. Teacher scheduling and coverage are staff-operational data, not education records. The privacy wall that restricts a student record to one school tenant does not apply here because there is no student data involved; the teacher management record carries staff operational facts, held under the same tenant isolation as the rest of the platform.
Frequently asked questions
Is this separate from the HR and evaluation side of the platform?
Yes, deliberately. The certifications, PD hours, classroom observations, and evaluation cycle live in educator.management, which just shipped as its own surface. Teacher Management is the operations side — scheduling, coverage, substitutes, duty — not the credential and development side. The two share one staff roster and one scheduling engine underneath; they do not duplicate each other's function.
Does the scheduling engine handle period schedules specifically?
The schedule.software core is a canonical slot, booking, and availability primitive that already runs eight K-12 booking surfaces. A period assignment is a slot with a teacher, a room, a time window, and a school-term scope. The engine handles this the same way it handles a picture-day appointment or a senior portrait session: one primitive, different surface metadata. The period-scheduling surface that an administrator actually uses to build and edit the master schedule is the layer currently being built on top of the engine.
How does the coverage-equity computation work?
The computation reads the assignment records for a given period — typically the current term or the current month — and computes the coverage count per eligible staff member. An administrator who asks “who should cover third period today” gets a ranked or filtered view of eligible staff ordered by coverage load, with their current duty count alongside it. It is a deterministic computation from real assignment history, not a recommendation drawn from a model.
What is the honest status of substitute assignment today?
The slot engine (which expresses the open period) and the leave model (which records why the period is open) are built and shipped. The dedicated substitute-fill surface — where a coordinator sees the open period, the eligible staff, their loads, and makes the assignment — is actively being built on those foundations. We describe the substitute-fill UI as In progress, not as available, because the coordinator-facing surface is not complete yet.
Does this handle payroll for substitute or extra-duty pay?
No. Payroll processing is deliberately outside the scope of this platform. The system records the assignment and the leave event — the facts a payroll computation would read from. Actual payroll processing belongs to a dedicated payroll provider. This is a boundary held on purpose and named plainly on this page.
Does this track whether a teacher is certified to cover a specific subject?
Certification tracking, endorsements, and credential files belong to educator.management, not this surface. Coverage-equity assignment can be filtered by role (a certified sub versus an in-house coverage assignment versus a paraprofessional), because that is an operational distinction in the roster record. But the credential verification step — is this person certified in mathematics, is their license current — is an educator.management function that pre-exists the coverage assignment, not one this surface computes.
Related tools and surfaces
Educator Management
The staff and professional development side — certifications, license tracking, PD hours, classroom observations, and evaluation cycles. This is where the credential and development record lives.
Schedule Software
The scheduling core this platform runs on — one canonical slot, booking, and availability engine across all eight K-12 booking surfaces. Teacher scheduling is one of those surfaces.
Teacher Farm
Teacher development, mentorship, and onboarding — the growth side of the teacher record. Not operations; not scheduling.
Student Records
The official student record the whole platform reads from: roster, guardians, terms, and the single-school privacy wall. Separate from the staff record; the two never mix.
The Full Platform
The platform overview: yearbook, picture day, student records, family communication, and school management in one place.
What is built and what is honest-off
The schedule.software scheduling core, the staff roster with roles and per-school memberships, the coverage-equity computation, and the staff cockpit workload snapshot are built and shipped. The leave balance and leave request data model and persistence routes are built; the staff command center surface that exposes them is in progress. The substitute-fill workflow surface — the coordinator interface that ties the open slot, the leave record, and the eligible-staff equity view together — is in progress. The duty-roster assignment surface, scheduling conflict detection across the full roster, and automated coverage notification are planned. Payroll processing is not in scope by design. We name these plainly rather than hiding them.
This page does not claim certifications, PD tracking, classroom observations, or evaluation cycles. Those belong to educator.management. This page does not claim teacher development or mentorship pathways. Those belong to teacher.farm. The distinction is held in the product, not just in the copy.