Bookings, services, and encounters

New users of Light routinely ask the same question: what's the difference between a booking, a service, and an encounter? They sound similar. They show up in overlapping places. And the app reinforces the confusion by putting them on separate navigation items that cross-reference each other constantly.

Here's the model.

Three entities, three purposes

• Service offering — what your pharmacy delivers. A type of thing that can be booked: a flu vaccination, a health consultation, a MedsCheck. Configured in Settings›Services. A service offering is the abstract entity; it says "we can do this, and here's how".
• Booking — a reservation. A specific customer has reserved a specific service at a specific time. Created via the booking flow; visible on the Calendar and the Bookings list. The booking is the schedule entry.
• Customer service — a delivery. One specific instance of a service being delivered — usually linked to a booking, sometimes not. The customer service is where forms live, where claims are tied, and where the encounter happens. Visible at /services and on the customer profile.

And one related entity:

• Encounter — the act of recording. Not really an entity — it's a workflow. When you fill in the forms for a customer service (vaccination details, consent, adverse reactions), that's an encounter.

The chain

Most clinical work flows through these in order:

Offering configured → Booking made → Customer service exists → Encounter recorded

• The pharmacy configures a Flu vaccination offering once
• A customer books it, creating a booking
• The booking automatically creates a customer service
• At the appointment, staff run the encounter — filling forms, capturing vaccine details

Each step builds on the last.

Where the confusion comes from

The app uses "Service" in two places:

• Settings / Services — the configuration surface (offerings)
• /services — the list of customer services (deliveries)

Same word, different noun. Once you realise the settings area is about what you can do and the /services area is about what you have done, it clicks.

The distinction between booking and customer service can also look redundant — most of the time they're 1:1. But:

• A booking can have multiple services (a customer booked a flu vaccine and a MedsCheck in one appointment)
• A service can exist without a booking (for example, a walk-in vaccination)
• A booking can be deleted while its service records stay

Two entities, because sometimes the relationship isn't simple.

Where each lives in the UI

If you're lost between them, orient by the URL: /settings/services vs /services vs /bookings are your three main anchors.

Why it's worth understanding

This model shapes everything:

• Variants exist on offerings (configuration), not bookings
• Claims belong to customer services, not bookings
• AIR submissions come from encounters, not bookings
• Vouchers apply per service on a booking

Getting the relationship right once means the rest of the docs — and the rest of the app — makes sense the first time.

For deeper dives on each part of the model:

• Offerings, variants, and services — the offering side
• The booking lifecycle — the booking side
• Encounter forms and phases — the encounter side