Core concepts
The visit lifecycle
Every waitlist visit and every booking moves through a small, fixed set of states. Knowing them explains what your team can do at any moment, what the customer is being told, and why a closed visit cannot be reopened.
Waitlist visit states
| State | What it means | Reached from |
|---|---|---|
waiting | In line. The state a visit starts in. | Joining, or a member of staff adding a walk-in |
called | Their turn. This is the state that sends the message everybody actually cares about. | waiting |
served | Being dealt with, or finished. Out of the line. | waiting or called |
no_show | Called and never appeared. | waiting or called |
cancelled | Removed from the line — by the customer or by your team. | waiting or called |
The last three are terminal. A visit that is served, cancelled or marked a no-show is closed and does not go back into the line — including through the API, which refuses the change rather than quietly reopening it. If somebody was closed by mistake, add them again.
Things that are true about a visit, rather than states
Three more facts are recorded without replacing the state, because somebody can be all of these and still be waiting:
- Arrived — they are physically here. Useful where people join before setting off.
- Confirmed — they have acknowledged they are still coming.
- Delayed — they have told you they are running late.
Which of these your customers can set themselves is configured under waitlist rules.
Booking states
| State | What it means | Reached from |
|---|---|---|
booked | A slot is held. The state every new booking starts in. | The booking page, or a member of staff |
confirmed | Somebody has confirmed it is going ahead. | booked |
completed | The appointment happened and is finished. | booked or confirmed |
no_show | The time passed and nobody came. | booked or confirmed |
cancelled | Called off, by either side. The slot is freed. | booked or confirmed |
As with visits, bookings also record whether the customer has arrived and when they started being served, without those replacing the state.
What each step sends
Moving a visit or booking is what triggers a message. There are 18 in total — every one can be reworded or switched off per location and per channel, so this is the list of moments the product will speak on your behalf if you let it.
Waitlist (9)
- Waitlist visit createdSent when a visit is added to the waitlist
- Waitlist visit changedSent when a waitlist visit is changed
- Waitlist visit next in lineSent when a waitlist visit is next in line
- Waitlist visit alertedSent when the operator notifies a waitlist visitor that it is their turn
- Waitlist visit no-showedSent when a waitlist visit is marked as a no-show
- Waitlist visit servedSent when a waitlist visit starts being served
- Waitlist visit completedSent when a waitlist visit is marked as completed
- Waitlist visit followed upSent at least five minutes after visit completion
- Waitlist visit cancelledSent when a waitlist visit is cancelled
Bookings (9)
- Booking createdSent when a booking is created
- Booking changedSent when the booking time, duration, party size, service or resource changes
- Booking remindedSent ahead of time to remind the customer about the booking
- Booking alertedSent when a booking is alerted
- Booking no-showedSent when a booking is marked as a no-show
- Booking servedSent when a booking starts being served
- Booking completedSent when a booking is completed
- Booking followed upSent at least five minutes after visit completion
- Booking cancelledSent when a booking is cancelled
Most fire from the action that caused them. Three are driven by the clock rather than a click — the two follow-ups and the booking reminder — and are sent by a scheduled job. See customer messages for how to edit them.
A failed message never fails the visit
Sending happens after the action has already succeeded. If a provider is down, the customer still has their place in line and your team still sees the change — the failure is recorded in the message log instead of surfacing as an error.
Who can move a visit
- Your team, from the waitlist or appointments screen. This is the normal path.
- The customer, from their status page — cancelling, and confirming or reporting a delay where you have allowed it.
- An automation rule, after a condition has held for long enough — see automation.
- Your own systems, through the API. A visit moved this way sends exactly the same messages.