A consultation practice that runs on fixed slots has a scheduling problem and a queue problem, and they are not the same problem. Booking decides who has a slot; the queue decides what actually happens on the day, when people arrive early, late, together, or with family members who were not on the booking.
Build both halves against one record. A booking creates an appointment; the appointment carries visitor information, family members and its delivery mode; and on the day it moves through check-in, queue and completion. The visitor experience and the staff experience read the same object from opposite ends.
Detail
I'm not naming the practice, and I describe no visitor or household data beyond the shape of the fields the system holds.
The booking form is a weekend's work. Everything after it — holds, concurrency, rescheduling, arrivals that do not match bookings, and the queue that forms when a session overruns — is the actual product.
Stack
The decisions behind the build