> ## 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. # Edit a reservation **Edit reservation** is one screen where you stage every change together: party size, date, time, and even which experience it is. You see the money consequence before you commit, and apply it all with one button. Edit reservation is available while a reservation is **Pending payment**, **Confirmed** or **Checked in**. That's deliberate. Changing a party size and a date are usually one decision. Splitting them means the first change is applied against availability that the second is about to move. ## Change a reservation 1. Open the reservation. 2. Press **Edit reservation**. 3. Stage your changes: party size, date, time or experience. 4. Read the **Summary** panel, including its line about the money. 5. Optionally, add a **Reason for edit**. 6. Press **Update reservation**. *** ## What you can change | Field | When | | - | - | | **Party size** | Always | | **Date** | While Pending payment or Confirmed | | **Time** | While Pending payment or Confirmed | | **Experience** | While Pending payment or Confirmed | Change the date, experience or party size and the **Time** list re-queries live availability. This reservation's own seats are excluded, so it isn't competing with itself. The times offered are for the party size you've staged. Shrinking a party opens up tighter slots, and the whole edit applies at that final size. A new date or experience needs a time chosen before the edit can apply. The field says **why**. A few examples: > Estate Tasting doesn't run on Fri, Aug 28, 2026 — its schedule has no times that day. > Estate Tasting takes parties of 2 to 8 — a party of 10 is outside that range. > Every time on Fri, Aug 28, 2026 is full for a party of 10 — try a smaller party or another date. > Closed on Dec 25, 2026 — Christmas Day. ## Overbooking on purpose When a change doesn't fit, Riserva says so in a warning and offers an override. That covers a full time, no table that seats the party, or a party outside the experience's size range. > **This change doesn't fit** > ☐ Overbook — apply this change anyway Tick the box and press **Update reservation** again. The change applies, and the time slot shows over capacity in Host and availability. The override is recorded on the reservation's timeline ("capacity overridden"), so it's always clear it was a decision, not an accident. Guests can never do this: it's a staff-only control. A date the experience doesn't run, or a closed day, can't be overridden. The override is for capacity, not for inventing times. *** ## The Summary panel The right-hand Summary panel lists exactly what will change: > Experience → Estate Tour > Date → Saturday, August 15, 2026 > Time → 2:00 PM · Barrel Room > Party size → 6 Then it gives **one line about the money**. That line is the whole point of the screen. The panel is built to say the same thing the system will actually do, so it can never promise a refund that doesn't arrive. *** ## What happens to the money, in plain words ### You add guests to a paid reservation Each added guest owes the experience's price. The payment badge turns to **Partially paid**: some money is in, more is owed. A line reads like "\$225 due for guests added after payment", and the timeline records it. Collect it with a payment link, on-site, or waive it. ### You remove guests from a paid reservation Removed guests first cancel out any **unbilled balance**. If three guests were added but never paid for and two then drop out, two of that balance simply disappears. Only after that do removed guests earn a **refund of what was actually paid**, worked out proportionally. **The refund follows your cancellation policy.** Removing seats is a partial cancellation, so the removed guests' share is priced by the same schedule a cancellation would use. A same-day shrink under a "no refund within 24 hours" policy refunds nothing. The withheld amount stays on the order, and the timeline and the Payment card both record it. When the policy withholds something, the panel offers the choice explicitly: * **Per the cancellation policy** — the default, with a sentence explaining exactly what's refundable and what stays. * **In full, overriding the policy** — refunds the whole share. The override is recorded on the timeline with who chose it. * **Don't refund** — shrinks the party and keeps the payment. The timeline records "Refund of \$75.00 skipped — payment kept on file". When the policy refunds everything anyway (plenty of notice), you just see the familiar checkbox, **Refund to the original payment**, ticked by default. The reservation page shows the party at its new size. The seats that remain show as **Paid**, and the badge does not change. A **Refunded** row shows what went back. When the party had paid through more than one order, each order is netted by the refund made on it. The guests added last are refunded first, from the order that paid for them. ### It's a whole-venue buyout Nothing happens. A buyout is one price for the room, so party size doesn't change what's owed. The panel says so before you commit: > A buyout is one price for the whole venue — changing the party size doesn't > change what's owed. ### You move the date or time (same experience) **No money changes.** But table assignments clear and any open payment link is voided. Whenever the date or the time changes, the panel says so before you commit: > Table assignments clear and any open payment link is voided. Any scheduled charge re-anchors to the new time. The guest gets the *Reservation rescheduled* email quoting both the old and the new slot. Moving a reservation flagged **Booked after its time** (paid after its visit had ended) clears the flag. ### You change the experience Riserva works out the difference between the new price for this party and everything already paid or owed. * **More expensive** → the difference is owed (the badge reads **Partially paid** when money was already collected). * **Cheaper** → any unbilled balance is cancelled first, then the remainder is refunded. * **Nothing paid yet** → it simply re-prices. * **Moving to a free experience** → everything paid comes back. Riserva flags add-ons for you to handle by hand: > Add-ons belong to the previous experience — review or refund them. *** ## Reason for edit **Reason for edit** is a short, staff-only note. It lands on the reservation's timeline as a comment under your name. > Only visible to staff — it lands on the reservation's timeline. Use it. Six weeks later, "moved at guest's request, wedding rescheduled" is the difference between a clean record and a mystery. A reason on its own, with no other change, is a valid edit. *** ## If the change doesn't fit Riserva re-checks every change against real availability at apply time. A change that doesn't fit gets the warning banner and override described in [Overbooking on purpose](#overbooking-on-purpose) above. Occasionally a move succeeds and the resize doesn't. Riserva tells you exactly that, rather than pretending the whole edit worked: > The date/experience change applied, but the party size didn't: … This is because of the order things happen in: **move first, then resize.** The move claims the new slot. The resize is then validated against capacity where the reservation now sits. That's the only order that gives a correct answer. *** ## Related **What things mean on this screen:** [What things mean: A reservation's page and Edit reservation](/reference/reservation-page) * [A reservation's page](/daily-operations/reservation-page) * [Cancellations and refunds](/daily-operations/cancellations-and-refunds) * [Payment policies and money states](/core-concepts/payment-policies) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.