Analyse Waitlist

In this article

Before you start

• Open the app with a valid organisation, location and service occurrence selected; for the GB demo use Harbor Demo Group, Harbor Soho and `BOOKING_WAITLIST_OCCURRENCE_ID`.
• The operator can load the occurrence detail with `reservation:view` or `reservation:manage` for the active location.
• The backend call has at least one of `reservation:view`, `reservation:manage` or `optimization:view`, plus access to automatic reservation use.
• The occurrence is a service occurrence for the active location and has `booking_mode` equal to `waiting_list`.
• The occurrence or its event has a layout and optimiser configuration so availability can be calculated.
• For the demo capture, use `OPTIMIZATION_WAITLIST_RESERVATION_LABEL` = Sara Molina.

Instructions

1. 1.

   Open the waitlist occurrence

   Open the reservation occurrence detail for Harbor Soho using `BOOKING_WAITLIST_OCCURRENCE_ID`. When the occurrence is in `waiting_list` mode, the primary action becomes `Lista de espera` instead of the new-reservation action.

2. 2.

   Open the analysis modal

   Select `Lista de espera`. The app clears any previous waitlist selection, opens the modal and loads calculated options unless it already has local analysis for the same occurrence.

3. 3.

   Review the waitlisted reservations

   Read the rows in the modal. Each row shows the customer, phone when available, party size and number of calculated slots. In the GB runtime, Sara Molina is the expected waitlisted reservation.

4. 4.

   Expand a reservation and compare slots

   Expand the reservation to inspect start times, tables and optimiser metrics for risk, saturation, table preference and score. Treat these values as decision support before any promotion is confirmed.

5. 5.

   Refresh only when current slots are needed

   Use Refresh when the operator needs a recalculation. The app calls the same endpoint with `force=true`, returning current analysis without persisting a new result on the occurrence.

6. 6.

   Stop before confirmation for this action

   Selecting a slot prepares the later promotion flow and can reveal `Confirmar`. This guide stops there; confirmation is a separate action that changes the reservation.

Validations and limits

• The occurrence must belong to the active `locationId`; otherwise the backend treats it as not found.
• The occurrence must be a service occurrence in `booking_mode` `waiting_list`; other booking modes are invalid for this action.
• A layout and `optimization_config_id` are required before the backend can calculate availability.
• The request is `GET /api/app/{orgId}/{locationId}/service-occurrences/{occurrenceId}/optimization/waitlist-analysis` and sends no request body.
• `force=true` is the only query value used to force recalculation; without it, cached or local analysis may be reused.
• Only reservations with `status` equal to `waitlist` are analysed, ordered by creation time and then by ID.
• If one waitlisted reservation has no viable slot, the modal keeps it visible with no slots instead of failing the whole analysis.
• If the response no longer reports `waiting_list` mode, the app clears the modal state and refreshes the occurrence context.
• The analysis endpoint does not update the occurrence, reservation status or table assignments.
• Displayed slots are advisory and may no longer be available when the separate promotion flow runs.

Expected result

The operator has a read-only view of calculated waitlist options for the service occurrence and can decide which slot to promote later, while the reservation remains waitlisted until the separate promotion action succeeds.