Attendance registers: marks that mean something

What does the capability do?

It closes the loop between what was booked and what actually happened, without a parallel system to reconcile.

• One record, whole journey. The member’s relationship to a session occurrence is a single record whose status runs from reserved and confirmed through checked-in, completed, no-show, or cancelled. Attendance is a stage of the booking, not a separate ledger.
• A register API. Registers are read by occurrence or by member, and marks are written through dedicated attendance endpoints. Present, absent, late, and excused resolve onto the underlying statuses (checked-in and completed read as present, no-show as absent, cancelled as excused), and every write is audited.
• Live occurrence counts. Each occurrence maintains an attended count beside its booked and waiting counts, the same live-counter design used for capacity.
• Insight built in. The insights layer computes per-student attendance counts, consecutive-absence streaks since the last attended session, and last-attended dates, covered by SQL integration tests.

Why streaks are the number that pays

A single absence is noise; a streak is a signal. For term-based programmes, three consecutive missed sessions is the most reliable early warning of a non-renewal, and it is invisible in a paper register or a per-session view. Computing streaks in the platform turns the register from a compliance record into a retention tool: staff see who is drifting while a phone call can still change the outcome.

Why it matters

Registers carry real weight in this sector: safeguarding expectations, parent communication, funding evidence, and renewal forecasting all lean on them. A register that is the booking record (marked through one API, audited, counted live, and analysed for streaks) is trustworthy by construction. It also feeds the operational picture the rest of the Booking Engine presents, from waitlist demand to per-occurrence staffing with facilitator assignment.