Facilitator availability: who can deliver, and who delivered
The platform models service delivery in layers: who can deliver a service at a site (with optional date bounds), what their weekly working hours are, which recurring sessions they are assigned to (including date-ranged cover), and who was actually attached to each occurrence, with a role. The plan and the delivery record are both data.
What does the capability do?
It answers the two staffing questions operators actually ask: who could deliver this session, and who delivered it?
- Service-and-site availability. Facilitator records declare that a person can deliver a given service at a given site, with optional from and to dates for seasonal availability or fixed-term contracts.
- Weekly working hours. Team members carry weekly patterns (day, start time, end time), so scheduling respects real working shapes rather than assuming everyone is always available.
- Session assignment with cover. Facilitators are assigned to recurring sessions per site, optionally date-bounded and marked with a cover level, so temporary cover is an explicit, dated arrangement rather than a diary note.
- Per-occurrence staffing. Every occurrence records its assigned team members and their roles through dedicated endpoints. The question “who delivered the Tuesday 4pm on the 12th?” has a stored answer, which matters for attendance registers, compliance queries, and payroll alike.
- Customer-facing profiles. Facilitators are queryable with their profiles for portal display, so “who is delivering this session?” is answerable to customers, not just staff.
Why the plan and the record are separate
Most scheduling tools store only the plan: this facilitator delivers this session. But the delivered reality diverges weekly (illness, cover, room swaps), and when the plan is the only record, the truth lives in text messages. Modelling occurrence-level assignment separately from session-level assignment keeps the plan tidy and the record honest, and it is what makes utilisation reporting and dispute resolution possible months later.
Why it matters
For service businesses, the people delivering the service are the product, whether that is a consultation, an appointment, a class, or a clinic. Knowing reliably who can deliver what, where, and when (and who actually did) underpins scheduling through terms and skip dates, cover management, customer trust, and staff pay. The Booking Engine treats that knowledge as structured data with an API, not tribal memory.
Frequently asked questions
How do facilitators declare availability?
How does cover work when the usual facilitator is away?
Is staffing tracked per occurrence or per recurring session?
More Booking Engine capabilities
Waitlists: positioned queues that never race
How the Booking Engine handles full sessions: atomic waitlist joins with explicit queue positions, configurable queue sizes, and live waiting counts.
Checkout reservations: hold a place while the customer pays
How the Booking Engine holds places during checkout: time-boxed reservations with configurable expiry, lazy release, and guarded atomic confirmation.
Capacity and overbooking: hard limits, deliberate exceptions
How the Booking Engine models capacity: per-occurrence limits, live booked and waiting counters, sub-capacities for trials and make-ups, and an explicit overbooking allowance.
See this working in a demo
Book a consultation and we will demonstrate this capability on the Booking Engine accelerator, against your own scenarios.
Book a demo