The booking lifecycle

A booking is the central record linking a customer, a service, a time, and — for most services — a resource. Understanding its lifecycle helps you recognise where things can go wrong and why certain actions are only available at certain points.

The states that matter day-to-day

Staff work with four booking states:

• Booked — scheduled and reserved, not yet resolved
• Attended — the service was delivered
• Missed — the customer didn't show up
• Cancelled — the booking was deleted

The exact badges are catalogued in Booking statuses. This page is about why they exist.

A fifth Checked In state exists inside the booking data model and appears in the Bookings status filter, but Light doesn't expose an in-app action for it. Staff move bookings directly from Booked to Attended or Missed.

Why statuses matter

Several downstream features read the booking's status:

• Encounters and forms. Recording a vaccination or a service form against a booking doesn't move the status on its own — staff still mark the booking Attended from the Attendance action. Completing the encounter and marking attendance are two separate steps.
• Claims. PPA and integration claims evaluate attendance — a Missed booking isn't claimable; a Cancelled one releases any voucher that was applied.
• Reporting. No-show rates, utilisation, and revenue reports are all driven by the status field.
• Notifications. Confirmation, reminder, and cancellation messages are triggered by status transitions.

If a booking's status looks wrong, the downstream record is almost always wrong too. Fix the status first.

Nothing resolves itself

Light doesn't auto-transition a booking to Missed when its time passes. A past booking that's still Booked picks up a Past Due badge and sits in the Dashboard and Bookings list until staff resolve it. That's a deliberate choice — "Missed" should mean "we confirmed they didn't come", not "the system guessed".

Walk-ins still start at Booked

A walk-in bypasses the scheduling step — it's created at the current time rather than reserving a future slot — but it still starts with status Booked. Staff mark the booking Attended once the service is delivered, the same as any other booking.

Held bookings aren't yours yet

While a customer is mid-way through the public booking flow, Light creates a Held booking that reserves the slot for a short window. If the customer doesn't confirm in time, the hold expires and the slot reopens. You won't usually interact with held bookings — they self- resolve — but you might see them briefly in the list during busy periods.

Deletion is permanent but preserves records

Deleting a booking (status: Cancelled) releases the time slot and any vouchers, but it doesn't:

• Remove the customer's record
• Withdraw a submitted claim (do that from Claims)
• Erase a recorded vaccination from the customer's immunisation history — the encounter is preserved independently of the booking

This matters for compliance: an AIR submission tied to a deleted booking still stands.

Why there's no "Rescheduled" state

Rescheduling updates the booking's time, duration, or resource without changing its lifecycle state. The booking reference, customer, and service stay the same. If you see a booking rescheduled ten times, it's still the same booking — the activity log records each change.

If the service or customer needs to change, that's a different booking — delete the current one and create a new one.