TECHNICAL ARTICLE

How to Structure Services, Staff, Availability, and Appointments in a Booking App

A reliable scheduling model separates what can be booked, who can deliver it, when capacity exists, and the reservation that consumes that capacity.

Model bookable offerings

A service record describes what a customer can request: duration, active state, and business-specific constraints. Keep catalog information separate from the actual appointment so a later price or description change does not silently rewrite historical records.

If a service can be performed by only some staff, use an explicit relationship between services and staff rather than duplicating one service record for every employee.

Model capacity and availability

Availability is derived from schedules and exceptions: working hours, staff time off, breaks, resource limits, existing appointments, and buffers. Preserve the rule inputs so a displayed slot can be explained and recalculated.

For multi-staff or multi-room businesses, define which resource the booking consumes. A person and room may both need to be free; counting only staff availability can create a collision.

Represent appointments as reservations

An appointment should reference the selected service, customer, assigned staff/resource, start and end instants, and a lifecycle status. Snapshot important details when needed so later catalog edits do not distort the historical booking.

Cancellation and rescheduling should be explicit state transitions. Decide when an old slot is released and when the new slot is reserved; treat the change as an atomic operation where possible.

Enforce conflict rules consistently

The same availability rules should power the calendar preview and the final write. The final reservation must revalidate current capacity and prevent overlapping conflicts under concurrent requests. A front-end check is useful for feedback but cannot guarantee exclusivity.

The correct database constraint depends on the domain: fixed slots can use a simple uniqueness rule; variable intervals may require overlap-aware exclusion or a serialized reservation transaction. Choose based on the actual scheduling model.

Keep business time explicit

Store appointment instants consistently and store the business time-zone identifier used for opening-hour rules. Convert for display at the edge, and test daylight-saving transitions and appointments made by customers in other time zones.

BDS includes services, staff, availability, appointments, and calendar functionality in its appointment-booking source package. Its public product page and documentation are the source of truth for its concrete schema and supported workflow.