When a guest changes a reservation, the deposit does not necessarily change with it. Depending on the restaurantās policy and the vendorās workflow, the original payment might carry over, part of it might be refunded, or an additional amount might be due. A cancellation can have a different outcome again.
Before choosing a restaurant reservation system, ask the vendor to show what happens to an existing deposit after each change. The key is to follow two records: the booking, which describes the visit, and the payment, which describes the money already collected and any later adjustment.
Start with the booking and the payment
A changed party size is not proof of a refund. A new date is not proof that the payment moved to the new booking. Staff need to see both the current reservation details and the depositās status before telling a guest what will happen.
For a demonstration, give the vendor a starting record and identify where each input comes from:
- Booking details: the original date, local time, party size, booking status, and reservation identifier, taken from the reservation record.
- Payment details: the amount collected, payment status, and transaction reference, taken from the payment record or processor view.
- Change request: the new date or party size, and who requested it, taken from the simulated guest request.
- Policy: the amount required for each date and the rules for changes and cancellations, supplied by the restaurant for the exercise.
Record what the demonstration actually shows separately from what you assumed. For example, seeing a three-person reservation is an observed booking detail. Assuming the guest has received a refund because the party got smaller is not a payment result.
Also ask whether the original reservation identifier remains in place after a date change. If the workflow creates a different reservation, have the vendor show how staff can connect it to the original payment without counting the deposit twice. Either approach needs a clear trail that a host can follow during service.
Compare outcomes before setting your rule
The following example is hypothetical. Assume a guest originally booked for four people and paid a $60 deposit, calculated at $15 per person. The guest then requests a date where the restaurantās stated deposit is $10 per person and reduces the party to three. Assume the restaurant permits the change and that the new date has room. The new required deposit is therefore $30.
All amounts below are deposit amounts, not sales. The comparison excludes payment-processing fees, fixed software charges, and exception costs such as staff time. It does not assume that a vendor offers either workflow.
Two possible policies give the restaurant different work to do:
- Refund the difference: Keep $30 against the changed booking and refund $30. The net deposit held is $30.
- Carry the full deposit forward: Keep the full $60 against the changed booking, if the restaurantās communicated policy permits it. The amount held is $30 above the new requirement; staff must know how that excess will be treated.
Those are not interchangeable guest experiences. If your policy calls for the difference to be returned, a workflow that only carries the full payment forward needs a reliable refund step. If you intend to retain the full deposit, ask how the guest and staff will see the excess and what happens to it later. Do not describe it as a refund or a sale while it remains a deposit.
Now consider cancellation as a separate decision. Using the same original $60 payment, a full refund leaves $0 held; retaining the full deposit leaves $60 held. The result depends on the restaurantās communicated policy and the facts of the cancellation. Ask the vendor to show the status and approval path for each outcome rather than assuming that canceling the reservation automatically settles the payment.
If a change increases the required deposit instead, ask how the additional amount is calculated, approved, and recorded. A label such as ābalance dueā should not be mistaken for money already collected. For help thinking about the broader cost of empty seats, see the guide to reservation no-show costs.
Use a decision worksheet in the demonstration
Use this worksheet with the same hypothetical $60 starting deposit. The expected outcomes are choices for the exercise, not claims about a product. The final column gives the result that would make each demonstration pass.
| Change | Assumed rule | Expected deposit result | Pass condition |
|---|---|---|---|
| Date and party change to three | New requirement is $30; refund the difference | $30 refunded; $30 held | Changed booking and payment adjustment are linked and visible |
| Same date and party change | Carry the full original deposit | $60 held; $30 above requirement | Staff can see the excess and its stated treatment |
| Cancellation | Full refund approved | $60 refunded; $0 held | Cancellation and completed refund have distinct, visible statuses |
| Cancellation | Full deposit retained | $0 refunded; $60 held | Staff can identify the retained amount and applicable decision |
The first two rows use the same booking change but different policies. Run them separately from the same starting state; do not apply both to one payment. The cancellation rows are also alternative scenarios. This makes it easier to see whether the vendor supports your preferred outcome directly or whether staff must complete and reconcile a separate step.
A pass means the presenter can show the expected result and the connection between reservation and payment. A fail means the amount is wrong, the status is ambiguous, the link cannot be established, or the required step has no accountable owner. If your policy requires a partial refund and the demonstration cannot show it, treat that as a failed requirement until the vendor demonstrates an acceptable supported process.
Test the failure case and assign an owner
Ask the vendor to simulate a refund that has been requested but not completed. The reservation may already show the smaller party, while the payment still shows the original $60. A host checking the booking could otherwise tell the guest that $30 has been returned when it has only been requested.
In this exercise, make the shift manager the exception owner. The host detects the mismatch before confirming the outcome to the guest and sends it to the manager. The manager checks the payment status, follows the restaurantās approval process, and records the resolution. Until completion is visible, staff should describe the refund as pending rather than completed.
Ask the vendor to show who can approve a refund, who can request or approve an additional deposit, and where those actions appear. Can a host see enough information to answer a guest without receiving broader payment permissions? Can a manager find unresolved changes at the end of a shift? If a manual processor step is needed, who performs it and who checks that the reservation record reflects the result?
Run practice scenarios in a safe simulation or test environment. Do not use a real card payment, send a guest message, or dispatch a courier as part of the practice. A live service pilot is a separate decision: agree on its scope, staff responsibilities, guest communications, and approved payment procedures before using it with real reservations.
Set acceptance criteria and compare the quote
Bring your own policies and have the same staff roles that will use the workflow watch the demonstration. The Fleksa table reservations documentation is a useful starting point for reviewing the reservation workflow; confirm deposit-change requirements directly with the vendor.
- Change the booking. Show the original and updated date, time, party size, and reservation status. Pass if staff can identify the current visit and trace it to the original booking.
- Trace the payment. Show the original deposit and the resulting held, refunded, pending, or additional amount. Pass if the displayed amounts match the chosen policy and are not counted twice.
- Exercise an exception. Simulate the pending refund. Pass if the host can identify the unresolved state and the shift manager has a clear action to resolve it.
- Check the handoff. Show where an incoming manager finds the decision and remaining work. Pass if that manager can distinguish a completed adjustment from one awaiting action.
Also ask about the booking channels you use, including Google bookings where available. Can staff trace the channel, reservation, and payment through a change? What permissions and exports are available for reconciliation? If a step takes place outside the reservation tool, include that work in your comparison rather than treating the workflow as automatic.
Compare written quotes for the software and any required payment services. Separate quoted processing fees from the broader operating cost, including fixed charges, variable charges, and the staff work involved in exceptions. Review Fleksaās plans for current pricing; pricing details were checked in November 2026. Ask each vendor what is included in its quote and what may cost extra.
Next step: Compare your reservation requirements with Fleksaās restaurant management software, and ask for a demonstration of your preferred deposit-change workflow before choosing it.
Frequently asked questions
Does a smaller party automatically receive a partial refund?
Not necessarily. The result depends on the restaurantās policy and the workflow used to adjust the payment. Check both the changed reservation and the payment status before confirming a refund.
Should a deposit move when a guest changes dates?
Decide whether your policy carries it forward, recalculates it, or requires another adjustment. Ask the vendor to show how the new booking is connected to the original payment and how any difference is handled.
Who should resolve an incomplete refund?
Assign a named role, such as the shift manager, to check the payment status and follow the restaurantās approval process. The host who spots the issue should escalate it rather than describe a pending refund as completed.
