One platform. Every kind of scheduling. On a calendar substrate we own.

The same canonical slot/booking/availability primitive — the thing that tracks open slots, enforces capacity, prevents double-booking, and manages booking state — is composed into every booking surface: parent-teacher conferences, admissions tours, picture-day sitting appointments, and the facilities booking calendar all share it. It is not the same code copy-pasted eight times; it is one primitive composed into eight contexts through a single interface. The benefit is that a correctness guarantee earned in one context — the partial-unique index that prevents double-booking, the transactional capacity count — is the same guarantee that holds in every context that composes the same engine. A school can enable one surface or all of them.

No. The no-double-booking guarantee is a partial-unique index at the database: a UNIQUE constraint on (event_id, student_id) WHERE status <> ‘cancelled’. A second live booking for the same student at the same event triggers a unique violation at the database; the engine catches it and returns a clean 409 with reason ‘already_booked’. This holds even under concurrent inserts from two different request threads, because the constraint is at the database, not in application-level conditional logic that a race condition could bypass. Two families racing the last appointment both get a clean, retryable conflict — never an over-book, never a 500.

The family wall means a guardian can only book for their own claimed child. The student ID is resolved from a hash-verified claim established during the family onboarding flow — it does not come from the request body, where a guardian could supply any student ID. Cross-family and cross-school access both return a uniform 404: the response is identical whether the booking does not exist or belongs to another family, so the surface is never an oracle for roster enumeration. There is no open sign-up sheet to browse.

The subscribable .ics feed delivers calendar events with opaque labels. The SUMMARY field is a non-PII label; the ORGANIZER field is an opaque internal handle — not a teacher’s name, not a student’s name, not a real email address. This design means a guardian who subscribes to their conference calendar cannot inadvertently expose a roster of teacher or student names in their calendar app. Staff see all events in the feed; a guardian’s feed contains only their own bookings.

When a roster is fetched for a scheduled section, every identity field routes through a consent resolution chokepoint. A student whose consent record is suppressed, lapsed, or marked do_not_publish has their name masked and their grade nulled in the roster view. The row is still counted for capacity and reporting; only the identifying fields are stripped. This masking is enforced at the route layer, not left to a UI filter that a client request could bypass.

No. The advisory master schedule proposes a conflict-minimized timetable and explains what it could not place. The proposal comes back as a review item; the engine never commits it without a human-ratified commit step. That commit step re-runs the conflict classifier (period clash, full seat, duplicate) before placing anyone. The engine never enrolls students on its own. Prerequisite or grade-eligibility gating is not wired and is not claimed on this site.

No — both are honest-off. Reminders are consent-gated and queued: the engine checks whether the family has opted in to the relevant notification channel; if the opt-in is absent, the reminder is suppressed. Nothing is sent through this surface regardless of opt-in status today. Any booking fee is a computed line — the engine calculates the fee and records it as a reserved line in the ledger, but the charged amount is always zero and no money movement occurs through this surface. There is no live checkout here.

Yes. Scheduling is modular: each surface is gated behind its own module flag or owner-context discriminator. A school can enable the conference booking surface without enabling the master schedule, the volunteer scheduling surface, or the facilities booking surface. A studio can use only the photo-crew dispatch and picture-day family booking surfaces. Any org running an owned instance configures only the surfaces relevant to its context. Take one surface or all of them.

A picture-day appointment moves through six states: booked (reserved, slot counted), cancelled (slot freed, no longer counted against the partial-unique invariant), checked_in (student arrived on picture day), captured (photo taken), retake_needed (flagged for a second session), no_show (slot window passed without check-in). These states feed the day-of dashboard so the admin sees which students are outstanding and can trigger post-session workflows (retake scheduling, no-show notification).

The self-healing reschedule engine proposes a ranked list of minimal-cascade changes when a disruption occurs. The reasons it models are: weather, school closure, lockdown, sick crew, and school request. For each reason, the engine computes the smallest set of job-day moves that resolve the conflict and ranks them by impact. A human ratifies or adjusts the proposal; the engine commits only after confirmation. Route optimization for the working-day dispatch runs the heuristic greedy default; an external optimal-solver seam is available but is not claimed as live.

All eight K-12 booking and scheduling surfaces are built and the core engines are production-ready. In a conversation we walk through the current state honestly: the picture-day booking surface with live capacity chips and the family wall; the conference booking flow with the .ics feed; the advisory master schedule proposal and what-if surface; the facilities booking calendar; the photo-crew dispatch board and self-healing reschedule. Reminders and fees are honest-off — the infrastructure is there, not live. There is no pricing commitment and no signup. If it looks right for your school, studio, or organisation, we discuss what access looks like.

The professional platform extends the same scheduling engine outward to five segments: personal appointment links, business-services booking, resource and room management, field-service dispatch with route optimization, and workforce shift scheduling. The core engines — dispatch, routing, multi-resource constraint gate, self-heal, eligibility gate — are built and tested in production on the K-12 operation. The standalone product surface (public booking pages, general self-serve onboarding, two-way calendar sync, the CalDAV server) is in active development. Pricing is the plan; we are accepting early access registrations before the public launch. We do not claim these surfaces are live today.

The Personal free tier is the wedge: unlimited event types (the appointment-link tools restrict you to one on their free tier), a custom domain not paywalled to enterprise, and the same availability engine underneath that knows rooms, crews, and shifts. It is planned as an honest on-ramp — not a crippled trial — so a freelancer or solo professional gets a real tool, and growing into teams, rooms, or dispatch is a single plan change, not a platform migration. The free tier is part of the planned launch; it is not live today.

Two things no field-service incumbent combines. First, a consumer booking page that feeds dispatch: a customer picks a time window and a technician is dispatched with an optimized route from that one booking event. Every existing field-service platform is operator-side only; none ship a consumer-facing booking page. Second, the hard-constraint eligibility gate at assignment time: credential expiry, territory match, kit/vehicle exclusivity, capacity, and blackout windows are all enforced before a write lands, and the same gate re-runs on an open-shift claim to ensure the single winner is truly eligible. Neither of these is a feature tacked on; they are the architecture the K-12 dispatch engine was built around and runs in production today.

No, not for the domain. A custom domain is on every plan, the free one included — most scheduling tools charge for that and reserve full white-label for an enterprise contract. Removing our branding and applying your logo and colors is one paid tier up (Pro), not a sales call. Notification emails carry your display name and reply-to; the legal and consent footer stays ours by design. Pricing is the plan; there is no live checkout on this page.