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 which mistakes can be put right.
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. Also called, or served if they were served straight from the waitlist, when your team moves them back |
called | At the counter, being served. In the dashboard this is Start serving (Call, on the waitlist screen), and it sends nothing — the message that it is their turn comes from the Alert bell, sent while they are still waiting. Through the API, moving a visit to called sends that message. | waiting, or a walk-in added straight to Serving. Also served, when your team moves them back |
served | Dealt with. Out of the line. | waiting or called |
no_show | Called and never appeared. | waiting or called |
cancelled | Removed from the line — by the customer, by your team, or by clearing the waitlist. | waiting or called |
On the dashboard, the line can be walked backwards to correct a mistake: somebody served can be moved back to where they came from, and somebody in Serving back to waiting, where they keep the place they joined at. Moving somebody back sends them nothing. Cancelled and no-show are final.
The API is stricter. To an integration, served, cancelled and no-show are all terminal: a request to change a closed visit is refused rather than quietly reopening it.
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. Also completed, when your team moves it back |
confirmed | Somebody has confirmed it is going ahead. | booked. Also completed, when your team moves it back |
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.
A booking completed by mistake can be dragged back to Serving on the location overview, and returns to booked or confirmed — whichever it was. Cancelled and no-show bookings are final.
What each step sends
Moving a visit or booking is what triggers a message. There are 19 in total. The wording is fixed, but every one can be switched on or 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 completedSent when a waitlist visit is marked as completed
- Waitlist visit followed upSent five minutes after the visit, when a survey is on for this location
- Waitlist visit cancelledSent when a waitlist visit is cancelled
- Waitlist closedSent to everyone still waiting when the waitlist is cleared, by staff or at closing time
Bookings (10)
- 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 marked as arrived
- Booking running lateSent by an automation rule when the customer hasn’t arrived by their booking time
- 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 five minutes after the visit, when a survey is on for this location
- Booking cancelledSent when a booking is cancelled
Most fire from the action that caused them. A few are driven by the clock rather than a click: the two follow-ups (which invite the customer to your survey, and are sent only when one is on) and the booking reminder are sent by a scheduled job, Booking running late by an automation rule once a booking’s time has passed, and Waitlist closed when the waitlist is cleared at closing time (or by hand). See customer messages for how to choose which are sent and on which channels.
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.