> ## Documentation Index > Fetch the complete documentation index at: https://docs.riservahq.com/llms.txt > Use this file to discover all available pages before exploring further. # What guests see, end to end Guests find an experience on your store, pick a time, add details, check out as normal and get a confirmation email. This page walks through each screen as it works today. Use it to write website copy, train phone staff, or check a guest's complaint against what really happens. ## The guest journey at a glance | Step | Where | What the guest does | | - | - | - | | 1. Start | A product page, or your Experiences list page | Presses **Check availability** or a card's **Book** | | 2. Date and time | The booking window | Picks a party size, a day and a time, then **Continue** | | 3. Details | The booking window | Adds add-ons, answers your questions, then **Reserve** | | 4. Checkout | Your cart and your Shopify checkout | Checks out like any order | | 5. Confirmation | Email | Gets **Reservation confirmed** with a calendar file | | 6. Before the visit | Email and your storefront | Gets a reminder, and can cancel or move | *** ## 1. Where guests start Guests start in one of two places: * A **product page** with the *Experience booking* block. They see your button, whose default label is "Check availability". * A page with the **Experiences list** block, usually your property page. It shows a search rail over a grid of photo cards, one per bookable experience. Booking from a card opens the same booking window as the product page. It opens already on the right experience and date. ### How the Experiences list search works * The search rail has a date, a time and a number of guests. * Cards appear in the order you set with **Reorder** on the Experiences page. Until you reorder, they are alphabetical. * The search starts on **today** by default, so guests land on live availability instead of an empty rail. The block's **Preselected date** setting chooses Today, Tomorrow or No date. * The date opens a calendar right in the page. Picking a day searches at once. * The time filter (Morning / Afternoon / Evening, tick any mix) narrows the shown times without another search. The grid of cards changes with the search: * Without a date, the grid shows every experience with the hint "Pick a date to see each experience's open times". * With a date, each card carries one line summing up that day: "3 times · 11:00 AM – 3:00 PM" (or "1 time · 2:00 PM"). Experiences with nothing open drop out. * Guests pick the exact time in the booking window. * A search with no matches says so, and invites a different date or party size. ### What an experience card shows Each card on the Experiences list shows, from top to bottom: * **The photo.** An experience without one gets a quiet initial-letter placeholder. Add photos: they carry the card. * **The name.** * **The guest sentence.** This is your settings in one line, such as "Prepaid reservation for parties of 2 to 4 · 60 min". "Prepaid" appears only when you charge at booking. * **A two-line description.** * **The price and a Book button.** The price reads "\$85 per guest", "\$1,500 for the venue" for a whole-venue buyout, or "Free". The same guest sentence appears in your admin's Experiences list. What you see there is exactly what guests are promised. ### Set up the Experiences list block Set these in the theme editor. By default, everything matches your theme's buttons automatically. * **Cards**: Grid, or a List of rows. * **Show descriptions**. * **Book button**: opens the booking window, or goes to the experience's product page. * **Accent color**. * **Corners**: governs buttons and input fields together. * **Calendar days**. * **Top/Bottom spacing**: sliders for the breathing room around the block. * **Preselected date**: Today, Tomorrow or No date (see above). **Show only some experiences.** Under **Which experiences**, **Only this location** and **Only experiences tagged** narrow one block to one location or one tag. Set tags on each experience's **Organization** card. Use this for a page per property, or a "Family visits" page. When nothing matches, the block reads "No experiences match this block's location or tag settings yet." **Change the members' join button for one block.** Under **Members-only experiences**, **Join link for this list** and **Join button label** override the store-wide join button in the booking window for this block. The *Experience booking* block on a product page has the same two settings. For advanced tweaks, the block has a **Custom CSS** box. It is applied inside the widget after Riserva's own styles. Riserva treats the widget's class names as a stable surface, so your customizations hold across updates. In the rare case a release has to change one, we'll announce it ahead of time. ### How members-only experiences look to guests A members-only experience carries a "Members only" chip on its photo. Everyone sees that card the same way: full colour, with its price and **Book** button. * A non-member gets no times on a date search. The card stays listed when a time of day is chosen. * When a non-member presses **Book** (on the card or on the experience's product page), the booking window opens on a "Reserved for members" notice. * A recognised member sees the normal calendar. * You can also set an experience not to show to non-members at all. - The notice shows a lock, your message from Settings → Memberships, your join button and **Sign in**. - Whichever you chose to lead is the big button. The other is a quiet link under it. - Without a join link, the notice offers **Sign in** only. - A signed-in guest who isn't a recognised member is told their account doesn't have member access. They get no **Sign in**. *** ## 2. Step one in the booking window: pick a date and time Pressing the button opens the booking window. It is a panel over the page; on a phone, it fills the screen. * **Guests**: a stepper that starts at 2, limited to the party range you set on the experience. * **Calendar**: one month at a time, with arrows. Only days with something open are clickable; everything else is greyed out. Beneath it: "Shaded dates are open for booking." Once a date is chosen, the times appear: * **Times**: after a date is chosen, the day's open times appear as full-width rows showing the whole window, such as "4:30 PM – 6:00 PM". They follow your store's 12-hour or 24-hour preference. * **Venues**: when two or more venues run the experience that day, the times are grouped under venue names. Guests then know which room they're choosing. * **Scarcity**: a time row shows "3 left" only when four or fewer places remain. Times that are full simply aren't listed. * **Footer**: keeps the choice visible ("6:00 PM · party of 4"). Its **Continue** button stays disabled until a time is picked. > **Good to know** > Times are shown in the venue's local time, and the booking window does > **not** print a timezone line. If you sell to guests in another timezone, > say so in your experience description. ### Today's waitlist when today is full (optional) Guests can join today's waitlist online when today has no open times. Turn it on in **Settings → Reservations → Let guests join today's waitlist online**. The setting is off by default, and with it off nothing changes. * A guest who selects **today** and finds no open times sees "Join the waitlist" beneath the no-times message. * They leave a name and email. The party lands on the same waitlist your host stand and POS already use. * When you tap **Notify**, they get the *table ready* email. See [Host view](/daily-operations/host-view) for working the list. * The offer only appears for today. The waitlist is a right-now list, not a future-date request book. * It never appears on a day you've closed with a blackout period. * Joining twice with the same email doesn't create duplicates. *** ## 3. Step two in the booking window: details Step two collects add-ons, your questions and special requests. Its footer shows the running total next to the **Reserve** button. The total is price × party (or the flat price for a buyout), plus add-ons, or "Free". ### Add-ons in the booking window If the experience has add-ons, they appear under **Add to your visit** as tappable cards. Each has an **Add** button that fills in when chosen. * Add-ons priced per party or per guest toggle with a tap anywhere on the card. * Add-ons priced "each" get a quantity stepper, up to the maximum you set. * A per-guest add-on automatically bills one per guest. * If you gave the add-on a description, it shows under the price in two lines. **More** reads the rest, and **Less** folds it back. * Give the add-on's Shopify product a photo and the card shows it as a thumbnail. It updates within moments of the photo changing. **Photos.** You can also add the photo from Riserva. The add-on window has a **Photo** section: drop an image there when you create or edit the add-on. The cheese board sells better when guests can see it. Upload the photo at any size. The card shows a small copy that Shopify's image service resizes for it. A full-resolution product photo never slows the booking window down. **Products.** The **Add add-on** button asks which kind of product to use: * A product Riserva creates for the add-on. It is kept *Unlisted*: purchasable with the reservation, but hidden from your store's search and collections. * A product you already sell. Choosing one opens Shopify's product picker first, and the add-on takes the product's name and price from there. Either way, the add-on and its product stay in step from then on. Change the price or photo on the product, and the add-on follows. Edit the add-on's name, description or price in Riserva, and the product updates. Riserva only ever writes the fields you actually edited, so the rest of a shared product is never touched. **Variants.** If the product comes in several variants, pick just the ones you want to offer in the picker. Guests get one card with a dropdown of only those variants, each at the variant's own price. Adding one variant and switching the dropdown lets them add another. Everything they've added stays visible on the card. ### When add-ons are charged Add-ons follow the experience's payment timing. * On an experience that charges at booking, add-ons are paid at checkout with everything else. * On one that saves the card and charges later ("Before the visit", "At check-in" or "At the visit"), add-ons are charged on the **same date as the reservation**. That means one checkout and one charge. * To make that true, Riserva puts every add-on product on the experience's pay-later option. This includes a product you already sell. * The amount the fine print quotes is the whole deferred total, add-ons included. It matches what the card is eventually charged. See [Payment policies](/core-concepts/payment-policies). On a "Before the visit" experience, a guest booking *inside* your charge window pays at checkout instead. No card is saved, because there is nothing meaningful to wait for. The fine print tells the guest so: *"Your visit is less than 24 hours away, so your card is charged today at checkout."* If you'd rather everything went through the same collection, set **Advanced → Bookings made inside the window** to *Charge on the usual schedule* in the Pricing card. See [Payment policies](/core-concepts/payment-policies). This means Riserva couldn't add the add-on's product to the experience's pay-later option. The add-on's card in the editor says **Charged at checkout — retry**. Its three-dot menu offers **Charge this with the reservation**. Until you retry, that one line really is charged at checkout. The widget tells the guest so. Nothing is hidden; it's just a mixed checkout. See [Payment policies](/core-concepts/payment-policies). ### Your questions, special requests and the privacy line **Your questions.** Any intake questions you've set for the experience appear here, in the order you arranged them. Required ones are marked with an asterisk, and the guest can't continue until they're answered. See [Intake questions](/guest-experience/intake-questions). **Special requests.** A free-text box under a "Special requests" label, with "Allergies, celebrations, accessibility needs…" as the example inside it. It is capped at 500 characters, with a live counter. **Privacy line.** Fine print under the requests box tells the guest that contact details shared at checkout are used only to manage their reservation. It links to Riserva's privacy policy. The same line appears on the waitlist form, which collects a name and email directly. *** ## 4. Checkout Pressing **Reserve** does three things: 1. Riserva **holds the time** for 12 minutes, so the guest isn't racing someone else while they pay. 2. Riserva adds the reservation to the cart as a line item. The experience, location, date, time and party size (and any special requests) are attached. Each add-on gets a separate line. 3. The guest is taken to **the cart page**, where they check out as normal. Checkout is your normal checkout, because reservations are ordinary Shopify products. Guests use your payment providers, your discount codes and your order confirmation. Riserva marks reservation products as services, so Shopify does not ask a guest for a shipping address or shipping rates. > **Good to know** > The countdown on the hold isn't shown to the guest, so nobody is put under > visible time pressure. The hold lapses and the time goes back on the calendar. The guest's checkout carries on, and the reservation is still created when they pay. If someone else took that time in the meantime, the reservation arrives badged **Overbooked** for you to sort out. It's never dropped. ### One billed-later reservation per checkout A cart can hold only one reservation that's billed later. A saved card belongs to the whole Shopify order, and the later charge takes the order's whole balance. Two billed-later reservations checked out together would be charged together, on the first one's date. The booking window stops that before it happens. If the cart already holds a billed-later reservation and the guest reserves another, nothing is added. The window explains why and offers two buttons: * **Finish checkout** goes straight to checkout for the reservation already in the cart. * **Remove it and continue** takes that reservation and its add-ons out of the cart, frees its time, and adds the new one. Reservations paid at checkout share a cart freely, and so do bottles. That includes a charge-later experience booked inside its charge window. *"You have a reservation waiting in your cart that's billed later (Sat, Aug 15, 2 guests). Finish that checkout first, or remove it, then book this one."* The two buttons under it are **Finish checkout** and **Remove it and continue**. A cart can still get through with two of them: a theme with its own add-to-cart button, two tabs, or a restored cart. Every reservation is still created. * Each reservation's page says *"Shares its saved card with RES-… — the two are charged together"*. * The card is charged once, when the first of them comes due, for all of them. The others are marked paid by that same charge. * Cancel one before then and the order stays open for the others. Its share of the later charge is recorded on its timeline as money to refund. The booking window returns the guest to step one with a fresh calendar and one of these messages: * "Sorry, that time was just taken — here's what's still open." * "That time can no longer be booked online. Please pick a later time or contact us." This means they hit the booking cutoff. * "That party size can't be booked online for this time. Try a different party size or contact us." A guest who presses **Reserve** more than 20 times within 10 minutes is asked to wait. The same applies to someone on the same connection. The message is *"That's a lot of reservations in a short time — give it a few minutes and try again."* It clears by itself. ### A reservation left in the cart too long Riserva keeps old or altered reservation lines from being paid by mistake. It does this in the booking window and with its checkout rule. The checkout rule switches itself on once you approve Riserva's permission. Settings › Checkout › Checkout rules lists it as "Check reservations at checkout"; leave it active. Shopify keeps a cart for days. A guest may come back to any page with your booking window while their cart still holds a reservation whose time has already passed. Riserva removes it, with its add-ons, and shows a short note at the bottom of the page: *"Your reservation for \ had already passed, so we removed it from your cart."* If the guest goes straight to checkout instead, Shopify's checkout stops them with Riserva's checkout rule: *"Your reservation for \ has passed — remove it from your cart to continue."* The checkout rule looks at the visit's DATE, so a visit earlier today is not stopped there. If one of those is paid after the visit has ended, the reservation is still created. It is marked **Booked after its time**, and no confirmation is sent to the guest. Payment links for a balance after a visit are never stopped. A reservation's quantity is set by its party. It is the number of guests for a per-guest price, or 1 for a whole-venue price or free entry. * If a guest changes it in the cart, the booking window puts it back and says *"Quantity is set by the reservation (4 guests). Change the party size by booking again."* * If they go straight to checkout instead, the same checkout rule stops them with *"This reservation is for 4 guests — set its quantity back to 4, or book again for a different party."* * An order that still gets through is created. Its timeline says *"Payment mismatch — checked out with a quantity of 1 for a party of 4 (should be 4\)"*. ## 5. Confirmation When the order is placed, Riserva creates the reservation. If the guest gave an email at checkout, Riserva sends the **Reservation confirmed** email. * It has the date, time, party size, confirmation code and location. * It has an **add-to-calendar attachment** (`reservation.ics`). If the reservation is later moved, the reschedule email carries an updated file. That file replaces the calendar event rather than duplicating it. * It has a **Cancellation policy** line generated from your policy settings. It is the same sentence the Policies page previews, so the guest's email and your rules can never drift apart. The reservation appears in **Reservations** in your admin, usually within seconds of the order. On a charge-later experience (the card is saved and charged later), allow about a minute. Shopify takes that long to confirm those orders before telling Riserva. ### The confirmation code The confirmation code is what the guest types to manage their own reservation if they don't use the email's link. It looks like `RES-7K4M`. The prefix is yours to brand. **Settings → Reservation IDs** lets you change `RES` to anything short (`VIP-7K4M`, `NAPA-7K4M`). The change applies to new reservations only; codes guests already hold never change. *** ## 6. Before the visit * A **pre-visit reminder** goes out in the 24 hours before the slot. * The **Manage your reservation** link in their emails opens their reservation on your storefront. There they can cancel or move it within the limits your policy sets. See [Guests managing their own reservations](/guest-experience/guest-self-serve). *** ## What guests can't do These are honest limits, so you don't promise them: * **No future-date waitlist.** The storefront waitlist (if you've turned it on) covers **today only**. A guest can't ask to be notified about a full day next month. Full future days simply show nothing open. * **No account area.** A guest opens one reservation at a time, from the link in their email or with their code and email. There is no list of past visits for them. * **No deposits.** Depending on the experience's payment policy, a guest pays in full at checkout, or saves a card that's charged the full amount later, or doesn't pay online at all. * **No timezone label** on times, as noted in step one. *** **What things mean on this screen:** [What things mean: What your guests see](/reference/guest-surfaces) ## Related * [Add the booking widget to your theme](/getting-started/add-the-booking-widget) * [Intake questions](/guest-experience/intake-questions) * [Customer emails](/guest-experience/customer-emails) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.