> ## 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. # A reservation's page A reservation's page holds everything about one reservation. Open any reservation to see who's coming, what they're coming to, what they've paid, where they'll sit, and every single thing that has ever happened to it. The page is titled with the confirmation code. ## The header The header shows the reservation's status and holds its actions. **Status badges** sit beside the title. The status badge has a small progress circle: * Empty before arrival. * Full once the party is here. * Half while only part of the party is here. A checked-in party with guests missing reads **Partial check-in** in yellow. **Overbooked** shows where it applies. A red **Booked after its time** shows when the guest paid after the visit had already ended. The **Member** badge isn't in the header; it sits beside the guest's name on the Guest card. **Arrow buttons** in the header step through the reservations from **the list you were just looking at**. Open the third row of *Needs attention*, and the arrows take you to the second and fourth. They honor the tab, filters, search and sort you had set, exactly like stepping through orders in Shopify. The back arrow returns you to that same filtered list. ### Header buttons by status The header keeps two buttons and a menu, the same shape as a Shopify order page: * The natural next step is the main button. * **Edit reservation** sits beside it while the reservation is Pending payment, Confirmed or Checked in. * Everything else is under **More actions**. The buttons change with the status: | Status | Main button | Under More actions | | - | - | - | | Pending payment | **Confirm** | Check in, Send reminder email, Mark no-show, Cancel reservation | | Confirmed | **Check in** (asks first when the party is well ahead of their time — see the Host view article) | Seat, Send reminder email, Mark no-show, Cancel reservation | | Checked in | **Seat** | Complete, Undo check-in, Edit guests here, Cancel reservation | | Seated | **Complete** | Unseat, Edit guests here | | Completed | — | Edit guests here | | No-show | **Undo no-show** | — | | Cancelled | — | — | **Send reminder email** appears only for an upcoming reservation with an email address. Inside the **More actions** menu, the order runs from likely to rare: 1. The second step (Seat beside Check in, Complete beside Seat). 2. The one-step-back actions. 3. **Edit guests here**. 4. The reminder email. 5. Last, the red destructive actions. The red actions are never next to the button you press fifty times a day. **Undo check-in** and **Unseat** walk a party one step back after a tap made by mistake. They stay in the **More actions** menu, never the main button. * **Undo check-in** puts a checked-in party back to Confirmed, or Pending payment if that is what it was checked in from. It clears the check-in time. * **Unseat** puts a seated party back to checked in. * A seated party goes back one step at a time. The timeline records each step back with your name. Riserva refuses to undo a check-in that already charged the guest's saved card, or that marked the reservation's order fulfilled. The banner says why. Edit or cancel the reservation instead. **Undo no-show** is the step back for a no-show called too soon. The no-show may have come from a host, or from your automatic no-show setting (Settings → Reservations → No-shows). **Undo no-show** is the main button on a reservation whose badge is **No-show**, because it is the only thing left to do there. It appears nowhere else. After you press it: * The reservation goes back to Confirmed, or Pending payment if that is what it was marked from. * Its no-show time is cleared, and **Check in** works again. * The timeline reads "No-show undone — the party is back among those arriving", with your name. Nothing refuses **Undo no-show**: no money moves on a no-show. Sometimes an order for a reservation arrives after its visit is over. Usually it's an old cart that was paid days later. Riserva still creates the reservation, because the money is never dropped. But Riserva: * Sends the guest no confirmation. * Never marks the reservation a no-show by itself. * Lists it under **Needs attention**. The page shows a banner with **Move to a new date** (opens Edit reservation) and **Cancel and refund**. Moving the reservation clears the flag. ## The reservation card The reservation card has no heading: the experience name *is* the heading. The experience's photo, the venue and the location sit beneath it, and then: * **When**: the full date and time, with the timezone. * **Party size**. * **Add-ons** the guest bought, with what they paid. * A **Subtotal** under the add-ons. The experience's own price sits at the right of its heading row. The add-on prices line up beneath it, so the card reads as one itemized list that adds up to the subtotal. A free reservation shows no prices at all. The reservation card also carries: * **Intake answers**: your questions and the guest's answers. * **Special requests**: what the guest typed. * **Staff notes**: notes Riserva records, such as a cancellation note. While only part of a checked-in party is here, a grey strip along the bottom of the reservation card says so. It reads "2 of 4 guests here", with **Edit** to change the count. After the visit it reads "2 of 4 arrived". A whole party shows no strip. The strip is a count beside the reservation. It doesn't change the party size or the money. **More actions → Edit guests here** sets the count at any time after check-in. ## The Payment card The badge on the right of the Payment card is the payment state: **Paid**, **Payment due**, **Not required**, and so on. Below the badge: * The **payment policy** in words, prefixed `Policy:`. The policy is *when* money is due for this experience, not whether it's been paid. The badge above is the state. * The money, itemized: **Experience**, **Add-ons**, **Order total**, and any **fee credit toward the bill**. With no add-ons it's a single **Paid** line. * Any **balance from guests added after payment**. * The **Shopify order** (or orders) that took the money, each linking straight into Shopify admin. More on payment states in [Payment policies and money states](/core-concepts/payment-policies). The Payment card lists **Shopify orders**, one row per order that holds this reservation's money: * The checkout order. * An **Additional** payment-link order, when the party grew. * A **Register** sale. Each row is netted by the refunds made on that order. **Total paid** shows beneath when there is more than one order. The amount on an order row includes the add-ons bought on that order, so before any refund it matches the order's total in Shopify. A **Refunded** row appears whenever money went back. It's one row with the total, whether the refund came from a cancellation, a party that shrank, or a refund made in Shopify. * The badge becomes **Refunded** (everything came back) or **Partially refunded**. * A party that shrank keeps its **Paid** badge, because the seats that remain are paid for. * On a cancelled reservation, a **Kept on cancellation** row shows what the policy or an override kept. The lines above the Refunded row keep their original prices, so **Order total** always matches the Shopify order. The arithmetic reads top to bottom: what was paid, what went back, what stands. Only an add-on refunded by name in Shopify is struck through. **Paid on-site** and **Waived** rows appear when staff resolved a balance that way. Neither is part of the order total. Paid on-site was collected outside Shopify, and Waived was never collected at all. So the order total keeps matching Shopify. ### Charge-later reservations For a **charge-later** reservation, the Payment card has one line saying exactly what happens next. For example: * *Charges \$120.00 from Sun, Sep 20, 2026, 2:00 PM · collected within the hour · Visa •••• 4242 (exp 04/28)* * *Charges \$120.00 when you check the party in · Visa •••• 4242* The guest's card is saved with Shopify. Riserva collects the balance from that moment on. Collection runs hourly, so the charge lands in the hour that follows, not on the minute. That's why the line says *from* and *within the hour*. Once that moment has passed, the line reads *Charges \$120.00 at the next collection run — queued*. It's the same promise stated honestly, rather than a time in the past. If the card details haven't come back from Shopify yet, the line reads *saved card* until they do. Opening the reservation is usually what fetches them. On a charge-later reservation, **before** the money lands, the itemized figures are what *will* be charged: * The subtotal reads **Due later**, or **Due now** once the collection moment has passed. * The breakdown rows read **Experience (due)** and **Add-ons (due)**. They switch to what was actually collected the moment the charge settles. A vaulted order really does collect \$0.00 at checkout, so showing zeros here would tell you the reservation was free. A charge that Shopify has accepted but not finished shows the badge **Charging** and the line *Charging… confirming with Shopify*. That is not a payment yet. Shopify usually confirms it within seconds. The page keeps checking on its own while the badge says Charging. It turns into **Paid** or **Charge failed** without a refresh. Don't collect again while it says Charging. ### Charge a saved card now While a reservation reads **Charge scheduled** or **Card on file**, the charge-later sentence sits in a blue banner with a *Charge now* button. Press *Charge now* to collect the balance today instead of waiting for the scheduled moment. Use it for a party that arrived a day early, a guest who asked to settle up, or a month-end you want closed. * *Charge now* checks the order's balance first. If the money already landed, it simply marks the reservation paid and charges nothing. * The timeline records who pressed it. * Checking a party in does the same thing on its own. Check-in is the latest a saved card is ever charged, whatever the experience's policy. * For an experience charged *at the visit*, the banner also has a **Waive fee** button. It forgives the fee, so the card is never charged. ### Recover a failed charge **Charge failed** is a **Payment due** state, not a dead end. The Payment card shows a *Payment due* callout headed by the reason Shopify gave. Examples are *"The card was declined"*, *"No saved card on this order"* and *"Shopify never confirmed this charge"*. Below it is every way of recovering the money: * **Retry charge** tries the saved card again. * **Create payment link**, **Mark paid on-site** and **Waive payment** are the same three options as in **Collect money** below. * **Tap to pay at the register**: the reservation's page on the POS Reservations tile offers **Add to cart — collect \$X**. Ringing that sale settles the reservation here automatically. **Retry charge** checks the order's balance first. If the money already arrived (a register sale, or a payment someone took in Shopify), it simply marks the reservation paid and charges nothing. The toast tells you which happened. ### Collect money When a reservation shows **Payment due**, three buttons appear on the Payment card: * **Create payment link** mints a Shopify invoice. Then **Copy payment link**, **Open**, or **Email invoice** to the guest. * **Mark paid on-site**: they paid at the counter. * **Waive payment**: comped or forgiven. Waiving always forgives the **whole** outstanding balance. The payment link's own status is shown too: *Link sent, not paid yet*, *Invoice sent*, or *Paid — order syncing*. The reservation's payment badge can still read *Awaiting payment* at the same time. That badge describes the reservation's money, not the link. Sometimes a register sale is linked but hasn't finished paying: a split tender left incomplete, or a "pay later" order. Then the three collect buttons don't appear. The Payment card explains that the order owns the payment. Collect it at the register or from the order's page in Shopify. The payment attaches here on its own. Don't cancel that order unless you mean to cancel the reservation. The two are tied. If the reservation was booked without guest details, paying the payment link fills in the missing name, email and phone from that order. So does a POS sale with a customer attached. The timeline notes what was added. Details staff entered are never overwritten. If a guest has paid an invoice but the order hasn't caught up, the Payment card offers **Sync order now** to pull it in directly. Riserva also tries this by itself whenever you load the page. So the button is a manual retry rather than a normal step. ## The Guest card The Guest card shows the guest's name, email and phone. **View customer profile** links into Shopify admin when the reservation is tied to a customer record. ### The Member badge and what it means When the guest is a club member, you'll see a **Member** badge beside their name. ## Table assignment The Table assignment card is separate from the **Seat** action, and the distinction matters: * **Seat** (header button) = the party has sat down. It's a lifecycle step. * **Table assignment** (this card) = *which* table they're at. The Table assignment card only appears when the reservation's venue has tables. Tables are a capacity choice, not a requirement. A tasting bar with no tables configured books, seats and completes reservations without ever seeing this card. ### Assign a table 1. Press the offered tightest fit, such as **Assign Table 6**, or **Assign Table 5 + Table 6** for a party that spans a combinable pair. 2. Or press **Choose table** to pick from the full list. In the full list, each table shows the party sizes it seats. If the table is taken in that window, it shows which reservation has it: "Taken — RES-7K4M at 5:30 PM". The tightest fit is marked **Best fit**. Pick an occupied table and Riserva warns you, then changes the button to **Assign anyway**. Double-booking is allowed, because sometimes it's the right call. But it never happens by accident. ### Suggested tables on a floor-map venue On a floor-map venue, the reservation already has a table when it is made. The table has a **Suggested** badge: Riserva chose it and may still move it. * Press **Keep** to make the table yours. * Press **Lock** to stop anyone changing it. A locked table shows a **Locked** badge and an **Unlock** button. * Press **Change** to pick another. * An assigned table also offers **Clear assignment**. That table is pencilled in for another party. Choosing it is allowed, and that party is given another table straight away. When Riserva has not suggested a table itself, **Best fit** is never a shared table (a bar or communal table). Choose one of those yourself when that is where the party should sit. Where tables are suggested automatically, a shared table can be the suggestion when it has the seats. ## Details The Details card holds the small print: * **Channel**: Online, Phone, Walk-in, POS. * **Capacity strategy**. * **Entry**: entry fee vs free to book. * When the reservation was **booked**. * The **cancellation policy** that governs it. The cancellation policy is the experience's custom rules if it has them, otherwise your shop policy. It's stated as one sentence, so you never have to reconstruct it from Settings. ## The timeline The timeline shows everything that has ever happened to this reservation. It's grouped by day, newest first, in plain sentences with the name of whoever did it: > Reservation created for a party of 4 > Guest checked in > Assigned to Table 6 > Payment attached — \$300.00 > 3 guests added — \$225.00 payment due > Changed to Barrel Tasting → Estate Tour on Sat, Aug 15, 2:00 PM > Reservation confirmed email sent to [guest@example.com](mailto:guest@example.com) Guest actions, staff actions, Shopify events and system sweeps all land on the timeline. It's the answer to "who changed this and when". ### Add a staff comment The box at the top of the timeline posts a comment. * You can attach up to five images per comment. They're stored in your Shopify Files. * You can edit a comment afterwards; it gets an "(edited)" marker. * You can delete a comment. Comments are the **only** thing on the timeline that can be changed. Everything else is a permanent record. The caption says it plainly: **Only you and other staff can see comments.** Guests never see them. ## Send a reminder by hand Riserva sends one reminder email automatically in the 24 hours before the visit. For an upcoming reservation with an email address, the page's actions also offer **Send reminder email**. It's useful for a guest who booked weeks out or sounded unsure on the phone. * The manual reminder counts as the reminder; the automatic one won't send a second. * It lands on the timeline with your name. * If reminders are switched off in Settings → Emails, the page says so instead of pretending it sent. ## What you can't change here **Guest name, email and phone are fixed once the reservation exists.** There is no way to attach or swap the customer record afterwards. Those are set when the reservation is created. Everything else (experience, date, time, party size) is changed from **Edit reservation**. ## Related **What things mean on this screen:** [What things mean: A reservation's page and Edit reservation](/reference/reservation-page) * [Edit a reservation](/daily-operations/edit-a-reservation) * [Cancellations and refunds](/daily-operations/cancellations-and-refunds) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.