Student Scheduling and Tutor Matching Software

The scheduling process starts at enrolment, not at booking. When a student enrols, the system captures their subject requirements, the academic level they are working at for each subject, their goals for the tutoring engagement, and the days and times they are available. This structured intake creates the matching profile the scheduling system uses when assigning tutors -- rather than relying on the admin team to remember which student needs Year 11 chemistry versus Year 8 maths. Goal and level information is stored against the student record and is available to the matched tutor before the first session. When a student's requirements change -- a new subject added, a level adjustment after an assessment -- the enrolment record is updated and the matching logic reflects the change going forward.

The matching engine cross-references the student's subject and level requirements against each tutor's recorded subject expertise, qualification level, and teaching history. Tutors who are not qualified to teach a specific subject at the requested level are excluded from the match set before any availability check is run. From the qualified set, the engine filters to tutors who have available time slots that align with the student's availability. Results are ranked by match quality -- a tutor with documented experience teaching the specific subject at the specific level and a strong session completion record ranks above a tutor who is technically qualified but has taught the subject infrequently. The admin team confirms the match or selects from the ranked list; the system never auto-assigns without a confirmation step for new student-tutor pairs.

Once a student is matched to a tutor, the schedule generation step finds the best available recurring time slot that satisfies both parties' availability constraints and the centre's room or virtual session capacity. For centres with a high volume of student-tutor pairs, bulk schedule generation runs across the full roster and produces a conflict-free schedule for the enrolment period, surfacing only the cases where no valid slot exists and human intervention is required. One-off sessions are scheduled against the same availability model as recurring sessions -- the scheduling system sees all session types in a single view so conflicts across recurring and ad hoc bookings are caught together. Confirmation is sent to the student, tutor, and any parent contact recorded on the student's account, with session details and any preparation notes attached.

Conflict detection runs at the point of booking, not as a post-hoc check. When a session is being scheduled, the system checks the tutor's availability against all existing bookings -- in-person and online -- and blocks the slot if the tutor is already committed. Room conflicts are checked separately so a tutor available at the time isn't accidentally double-booked into a room that is already occupied. Online session conflicts check virtual link availability where the centre uses a shared conferencing resource. When a tutor's availability changes -- a blocked week, a changed recurring availability pattern -- all affected sessions are identified and surfaced to the admin team for rescheduling rather than silently left in a broken state. Conflict alerts are shown to the person making the booking change in real time, before the change is saved.

When a student or tutor needs to reschedule, the system presents available replacement slots based on current availability -- not a static list. The student or tutor selects from the presented options and the session is moved with confirmation sent to both parties. Cancellation rules are configurable per centre: a cancellation within 24 hours can trigger a late cancellation flag, a fee charge, or both, depending on the centre's policy. Late cancellation charges are created against the student's account automatically when the cancellation rule is triggered, without requiring admin action. Make-up session scheduling links the make-up to the original cancelled session so the record is complete. Tutor-initiated cancellations follow a separate workflow: the centre is notified, affected students are identified, and rescheduling options are presented for each affected student simultaneously.

When a student's preferred tutor has no available slots that match the student's availability, the system places the student on a waitlist for that tutor and subject combination rather than requiring the admin team to track pending demand in a separate spreadsheet. When a slot opens -- a cancellation, a tutor adding availability, or an existing student completing their programme -- the system identifies the first waitlisted student whose availability matches the opening and sends a notification with the slot details and a prompt to confirm. Waitlist position is recorded and visible to the admin team so they can see demand for specific tutors and subjects in aggregate. For centres with consistent demand exceeding tutor capacity for certain subjects, the waitlist data feeds the decision to recruit additional tutors for that subject rather than requiring the admin team to manually count pending enquiries.