Parent-teacher conferences.

The parent-teacher conference is a small, high-stakes surface. A family gives up an evening; a teacher has thirty of those conversations back to back; a five-minute overrun cascades into a forty-minute wait by the end of the corridor. The old fix was a paper sign-up sheet on the classroom door — first come, first served, illegible by 6pm.

YESS replaces the sheet with a booking diary. The teacher decides when they are available and how many families each window holds; the parent picks a time from their phone; the platform enforces the capacity, sends the reminders, and tells each side when the other cancels. This chapter is deliberately scoped: it documents the booking spine that is live today, and names — plainly — the confirm / complete / no-show lifecycle and the post-meeting outcomes that are still to come.

A diary the teacher owns, a slot the parent claims, a reminder nobody has to send by hand.

Follow one Form-4 report-card night end to end and the rest of the book is detail.

Monday, 10:00. Mrs Tanoh, the Form-4 maths teacher, opens /dashboard/conferences. She clicks New slot and creates six windows on Saturday: 09:00 to 12:00, each twenty minutes long, one family per window, in person, in Room 14. She repeats for the afternoon. The slots appear under her Open slots tab; the Bookings tab is empty for now.

Monday, 20:15. Mr Mensah, a Form-4 parent, opens /portal/conferences. He sees Mrs Tanoh's open windows — only the ones that still have room. He taps the 09:20 slot, types a short agenda ("I'd like to talk about the mock-exam result and homework routine"), and confirms. The booking is his; the slot's remaining capacity drops by one. If another parent had been tapping the same window a second later, the platform would have handed them the next free slot instead.

Monday, 20:15 + 1s. Mrs Tanoh's phone shows a New conference booking notification. Her Bookings tab now carries Mr Mensah's reservation with his agenda attached, so she walks into Saturday already knowing what he wants to discuss.

Friday, 09:20 (24 hours before). A reminder lands with both of them — parent and teacher — through their preferred notification channels. Saturday, 08:20 (one hour before), a second reminder fires. Neither Mrs Tanoh nor Mr Mensah had to set an alarm.

Everything starts with a slot. A slot is a bookable window the teacher owns: a date and time, a duration, a capacity, a mode, and (for in-person meetings) a location. Slots live in the conference_slots table and are created from the New slot dialog at /dashboard/conferences.

The dashboard has two tabs. Open slots lists the teacher's own upcoming windows; Bookings lists the reservations parents have made against them, with a count badge. The Bookings tab is a read-only review surface: it shows the scheduled time, duration, mode, the parent's agenda, and a status badge, so the teacher can prepare for each conversation.

A parent opens /portal/conferences and sees the school's open slots — filtered so only windows that still have room appear. Tapping one opens a booking dialog with an optional agenda box; confirming reserves the slot. The reservation is written to the parent_teacher_conferences table with status = booked, the scheduled time and duration copied from the slot, and the parent's agenda attached.

Why the last slot never double-books

Booking does not write the row directly. It calls a database function, book_conference_slot, which runs inside a single transaction and locks the slot row before counting its reservations. That row lock is what makes the last slot safe: when two parents tap the same 09:20 window in the same instant, the function serialises them — the first claims the slot, and the second is rejected because the capacity is now full. The same function also refuses to book a slot that is inactive or in the past, and stops a parent from booking the same slot twice.

Cancelling

Each of the parent's own bookings carries a cancel control (until it is already cancelled or completed). Cancelling sets the booking's status = cancelled and records an optional reason. The other side is told automatically — see the next chapter.

A conference is only useful if both people remember it. YESS drives three automatic touchpoints, all through the notifications fabric, so each recipient gets them on whichever channels they prefer.

The reminder job (enqueue_conference_reminders) only touches future, non-cancelled bookings, and writes one notification to the teacher and one to the parent for each. Which channels actually fire — in-app, push, WhatsApp, SMS, email — is decided per recipient by their notification preferences, exactly as every other signal in the platform is routed.

Each booking a parent makes has its own detail page at /portal/conferences/[id]. It gathers what the family needs before they walk in, across three tabs.

• Overview. The agenda the parent wrote, the mode of the meeting, and — if the booking was cancelled — the reason.
• Counterparty. Who the meeting is with. Today this shows a placeholder reference to the teacher; the full teacher profile card links in with the staff-profile work in a later release.
• History. A simple timeline — booked, scheduled, and the current status — so the family can see where the reservation stands.

The same booking flow runs on the mobile app, where a parent can browse open slots and reserve one from their phone. The teacher's diary is web-only.

Conference booking is deliberately documented as a focused, working spine. Several natural next steps are scaffolded in the schema but not yet wired to a screen. They appear here so you can plan around them and are not surprised by their absence.

Conferences are one chapter of the wider communication cluster — they lean on the same notification fabric, the same portals, and the same calendar the rest of the school reads from.