Calculate Internal Availability

In this article

Before you start

• The user is signed in to Harbor Demo Group and working in Harbor Soho.
• The service occurrence is automatic, open, not completed and not in the past.
• The occurrence or its service event has a floor plan and an optimisation configuration.
• The floor plan has tables and, where needed, table combinations configured.
• The optimisation service is configured and responding, unless the operator is intentionally testing the manual fallback path.

Instructions

1. 1.

   Open New Reservation

   Open the Reservations calendar or the service occurrence detail page, then choose New reservation for an automatic open service occurrence. This opens the optimisation modal used for internal availability.

2. 2.

   Select Date And Service

   Choose the booking date and service, such as Harbor Soho's lunch service. The modal loads optimisation services for that date and loads the floor plan when a layout is available.

3. 3.

   Enter Party Size

   Enter the number of guests. If a duration is supplied by the flow it can be included; otherwise the effective duration comes from the optimiser option or optimisation configuration.

4. 4.

   Choose Table Conditions

   Choose whether the booking can use any suitable table, should prefer selected tables, must use selected tables or should be fixed to assigned tables. The modal sends those choices as table, restricted-table or preferred-table conditions.

5. 5.

   Calculate Availability

   Move to the Time step. The app sends the availability request, and the backend validates the occurrence, permissions, floor plan, optimisation configuration, existing reservations and table assignments before asking the optimiser for slots.

6. 6.

   Review Time Slots

   Review each returned time window, table name, duration, score and operational metrics. If no slot matches the current conditions, the modal shows the empty state and offers Add to waiting list; if the optimiser is unavailable, the manual fallback can be shown when configured.

Validations and limits

• The normal UI entry point requires reservation:manage for the location.
• The calculation endpoint requires reservation-automatic:use plus one of optimization:view, reservation-availability:view or reservation:manage.
• Manual, waiting-list, completed or past occurrences cannot be used for this calculation.
• The calendar occurrence, calendar event and layout must belong to the route location.
• party_size must be greater than zero, and the frontend does not request availability without org, location, occurrence and party-size context.
• If the table mode is not indifferent, at least one effective table must be selected before the request is built; unknown table ids are discarded against the loaded floor plan.
• The availability routes accept only POST; invalid JSON returns 400 with payload invalido.
• The generic route requires occurrence_id; the occurrence-specific route uses the occurrenceId from the URL and replaces any occurrence id sent in the body.
• Cancelled and waiting-list reservations are not sent as occupying reservations to the optimiser.
• If a selected slot disappears after recalculation, the modal clears the selected slot and keeps the operator on the Time step.

Expected result

The operator knows which internal booking slots are viable, or why no automatic slot is available, without creating, updating or cancelling any reservation.