Booking Flow Overview

​

Why This Matters

The booking flow is the primary revenue path for House of Legends. Every section is designed to reduce friction for individual guests while capturing the information the operations team needs to deliver a polished experience. The flow handles three distinct guest profiles: standard guests booking directly, guests celebrating special occasions who want add-ons and preference notes, and large groups who exceed self-service limits and require WhatsApp-assisted booking. Understanding the step progression helps operators diagnose where a guest encountered difficulty, why a particular reservation lacks certain fields, or how VIP bookings differ from standard paths.

​

How It Works

The booking flow is a conditional single-page experience embedded in the public website. Each confirmed decision reveals the next section in one continuous flow, so the guest can move through booking without a separate stepper control. State is held in a React context that persists across sections until the guest completes payment or abandons the session. Not every section appears for every guest. Add-ons only appear for the Tickets Only “No Extra Bundle” path when add-on offers exist. Large groups above the self-serve limit are redirected to WhatsApp for assisted booking and do not continue through the self-serve details, medical, payment, or confirmation sections. The backend owns all pricing and availability calculations. The frontend displays computed values and never recalculates totals independently.

​

Current Section Flow

Menu review is not a blocking step in the section order. When an event has an active menu PDF, the booking page shows it as contextual supporting content alongside the offer, add-on, or payment section.

​

1. Event Select

The guest lands on this section by clicking “Book Now” on any show page. They are presented with a calendar grouped by week, showing available dates and time slots for the selected show. Sold-out dates are marked and non-selectable. Once the guest picks a date and time, they proceed to Guest Count. This step pulls from the catalogShow.events data loaded at flow initialization. Availability is computed server-side and passed to the frontend. See also: Event concept — what a showEvent is and how it differs from a show template

​

2. Ticket Count

The guest specifies the total number of attending guests. If the show content is marked suitable for children, the UI shows a suitability notice only; the decision is entirely up to the guest and children use the same ticket price as adults. A summary panel shows the running total and the per-person price breakdown. The self-serve interface supports 1-6 guests when capacity allows. If the guest count exceeds the maximum self-serve threshold, currently 7 or more guests, the UI surfaces a WhatsApp link for assisted booking and the self-serve flow stops. The guest confirms the count before moving to Details.

​

3. Details

The guest enters their contact information: honorific, full name, email address, phone number, nationality, and an optional personal request. This information is stored against the reservation and used for confirmation emails and operational contact. Large-group inquiries skip the remaining self-service path. For all other guests, this section is required before proceeding.

​

4. Offers

The guest selects one of three experience tabs: Ticket Only, Dinner Show, or VIP. Each tab presents a different set of bundle options tailored to the selected show and event. Ticket Only displays admission plus fixed group bundle options, sometimes with a “5-Guest Upgrade” option for certain table configurations. The “No Extra Bundle” path is the only path that can reveal add-on offers later. Dinner Show presents fixed group dinner packs available for that show, with a “No Dinner Pack” option. VIP shows a single VIP bundle with its inclusions and any applicable availability notices. Below the bundle selector, an optional Special Occasion panel appears. If the guest selects an occasion type (Birthday, Date Night, Business, etc.), a free-text field becomes available for notes to the kitchen or host. This information surfaces in the operational dashboards for the relevant staff teams. When an active menu PDF exists for the selected booking path, the offer step also shows a menu link card so the guest can review the current menu before making extras and payment decisions. See also: Offer concept — how offers are structured and composed. Ticket Only Bundles and Dinner Show Packs for the full offer catalogue.

​

5. Add-ons

Add-ons are conditional. They appear only when the guest chooses Tickets Only and has no selected ticket-only bundle, meaning the guest chose the “No Extra Bundle” route and at least one add-on offer exists for the selected event. When visible, the guest sees available add-ons organized into collapsible accordion sections by category. Each add-on card shows the name, price, and a brief description. Add-on costs are included in the order summary shown in Payment. Dinner Show, VIP, Tickets Only bundles, and the 5-guest table-hold path skip this section. This section is gated behind the isAddonsSectionVisible flag, which is derived from the selected booking path, selected offer state, large-group state, and whether add-on offers exist. See also: Fulfillment concept — how add-ons map to fulfillments for kitchen and bar prep. Fulfillment Items — the full add-on catalogue.

​

6. Medical

Two free-text fields collect dietary restrictions and medical conditions. This data is visible to the kitchen and service teams through the Mission Control dashboard. The fields are optional and the guest can skip them. Large-group inquiries skip this section.

​

7. Requests

The guest can add optional seating, accessibility, celebration, or other preference notes that do not belong in the medical fields. These notes help staff prepare the event without blocking the booking when the guest has nothing to add. Large-group inquiries skip this section.

​

8. Payment

The guest reviews a full order summary including the event, experience bundle, add-ons, and any applied discounts. Two optional code-entry fields allow the guest to apply a promo code or referral code. A countdown timer displays how long the reservation is held before the session expires. The guest must explicitly approve the payment policy before the payment button becomes active. Approval is a checkbox-style toggle that confirms the guest has read and agrees to the terms of use and cancellation policy. Once the guest clicks Pay Now, they are redirected to the OnePay hosted checkout. After payment is processed, the guest returns to the confirmation route. See also: Payment concept — how the OnePay integration works and the payment lifecycle. Reservation concept — how the reservation is created at this section.

​

9. Confirmation

The guest sees a confirmation screen with their booking reference, a QR code containing the reservation identifier, and a summary of what they booked. A reservation confirmation email and payment receipt email are sent to the address provided in Guest Details. The booking reference follows the format RSV_YYMMDD_NNNN and is the primary identifier staff use to locate the reservation in the dashboard. See also: Reservation concept — the confirmed booking record. Event concept — the showEvent the guest booked.

​

Entry and Exit Points

Entry: A guest enters the booking flow by clicking “Book Now” on any public show page. The CTA passes the show slug to the booking SPA, which initializes the context with the catalog show data, available events, and applicable pricing. Exit — Success: The guest completes payment and lands on the Confirmation step with a booking reference. The session ends and the reservation is persisted in the database. Exit — Abandonment: If the guest closes the browser or navigates away before completing payment, the session state is lost. No reservation is created. A guest who returns to the show page starts a new booking flow from scratch. Exit — Large Group: When the guest count exceeds the self-serve maximum, currently 7 or more guests, the flow enters an inquiry state that displays a WhatsApp contact link. The guest is not creating a reservation through the self-service flow. Staff receive the inquiry through WhatsApp and handle it manually. Exit — Payment Expiry: If the payment countdown reaches zero before the guest completes payment, the hold on the reservation expires. The guest is given the option to start over, which resets the flow to Select Date. Exit — VIP Path: When a guest selects the VIP tab and confirms the VIP bundle, the flow proceeds through Medical, Requests, Payment, and Confirmation. VIP skips add-ons.

​

Conditional Step Summary