Core concepts
Waitlist and bookings
There are two ways a customer can arrive: join the waitlist now, or book a time later. They are separate flows with separate public pages, but they share a location, a customer record, a set of services and resources, and the whole messaging system.
How they differ
| Waitlist | Bookings | |
|---|---|---|
| The customer asks for | A place in line, now | A specific time, later |
| Public page | /q/your-branch | /book/your-branch |
| They are told | Their position and an estimated wait | A confirmed date and time |
| Ordered by | When they joined | The slot they hold |
| Staff screen | Waitlist | Appointments |
| Needs | A queue | Services with durations, and usually resources |
Running both at once
Most businesses that take bookings still get walk-ins, and the product assumes that rather than making you choose. A salon can hold a chair for a booked appointment at two o'clock and still let somebody join the waitlist at half past one.
What keeps the two from colliding is resources. A resource can only be in one place at once, so a booking that has claimed a stylist takes that stylist's availability out of the pool. Without resources configured, the two flows do not know about each other and it is up to your team to keep the balance.
Services can be limited to one flow
Each service says whether it is available for waitlist visits, bookings or both. A ten-minute prescription collection makes sense as a walk-in and not as an appointment; a forty-five minute treatment is the reverse. Set that on the service rather than switching a whole flow off.
Which to switch on
- Waitlist only— shops, pharmacies, restaurants, clinics running drop-in sessions, anywhere the answer to “when can you see me?” is “shortly”. This is the simplest setup: a queue and a QR code and you are running.
- Bookings only — where every visit is planned and an unannounced arrival is a problem. Needs services with realistic durations before it does anything useful.
- Both — salons, barbershops, garages, veterinary practices. The common case, and worth the extra setup of defining resources so the two do not double-book each other.
You are not committing to anything. Both flows are configured per location, under waitlist and booking rules, and a branch that only wants one can leave the other alone.