When only part of a booked party arrives, ask the vendor one question first: Can your system apply our written deposit policy to the number of guests who actually attend? Then ask staff to walk through the exact credit, retention and refund steps before you buy.
A deposit collected for a whole party does not automatically tell you what happens when two people are missing. Your policy, the way staff record arrivals and the payment workflow all matter. A useful demonstration should show the booking, the attendance record and the final deposit treatment together.
Choose the deposit rule before comparing software
Start by deciding whether the deposit belongs to the party as a whole or is calculated per cover. A cover is one guest, not one physical table. Six covers might sit at one table or several; the deposit question concerns the people booked and the people who arrive.
With a per-party deposit, the guest pays one amount for the reservation. Ask what happens if the party arrives short: Is the entire deposit credited to the check, can a portion be retained, or must a manager decide manually? Also ask whether the answer changes if the party size is reduced before arrival.
With a per-cover deposit, the amount is calculated using the number of booked guests. That can make a partial-attendance rule easier to express, but it does not guarantee the software can divide the payment as you intend. Ask whether staff can record actual attendance, whether the deposit can be split between attending and absent guests, and how any remaining amount is treated.
Write down when a guest can change the party size without a different deposit treatment. For example, does a reduction made the day before count differently from two guests failing to arrive? Decide who can approve an exception and what explanation staff should record. Have a qualified local adviser review the terms where appropriate before you put them into use.
When comparing a restaurant reservation system, ask the vendor to distinguish an automatic rule from a manual workaround. A workable manual process may be acceptable for a small number of bookings, but it needs a named owner and a clear record.
Work through six booked guests and four arrivals
The following is a hypothetical example, not a description of any vendor's features. A restaurant chooses a $10 deposit per booked guest. Six guests book, so the deposit collected is $60. Four attend and two do not.
For this example, the restaurant's intended policy is to credit $10 for each attending guest to the dining check and retain $10 for each absent guest, subject to the restaurant's approved terms. The expected split is a $40 dining credit and $20 retained. The $60 was already collected; it is not an additional charge at arrival.
Use the worksheet below during a vendor demonstration. The result column describes the chosen policy, not what every system will do.
| Check | Example input | Expected result | Pass or fail |
|---|---|---|---|
| Deposit collected | 6 booked × $10 | $60 recorded against the booking | Pass if the booking and amount match |
| Attendance | 4 arrived; 2 absent | Both counts are visible or documented | Pass if staff can identify the final counts |
| Dining credit | 4 attending × $10 | $40 applied to the check | Pass if the credit is shown without collecting it again |
| Absent-guest amount | 2 absent × $10 | $20 retained under the example policy | Pass if its disposition is clear and reconciles with the deposit |
| Exception | Manager approves a $10 refund | $40 credit, $10 retained and $10 refunded | Pass if approval and revised split are traceable |
In the exception row, the $10 refund replaces part of the amount otherwise retained. The three dispositions still total $60. If the dining check before the deposit credit is $120, the $40 credit leaves $80 to collect on that check. The deposit itself is not a processing fee, and the $20 retained is not the same measure as dining sales. Ask your accountant how the amounts should be recorded for your operation.
This example covers only the deposit and check arithmetic. It excludes fixed software charges, variable payment-processing fees and exception-handling costs such as staff time. A quoted processing rate alone is not the all-in operating cost. For current Fleksa plan pricing, see Fleksa's plans, checked November 2026, and ask for a written quote covering the setup you need.
Test the staff workflow and exception record
Ask the vendor to demonstrate the scenario in a sandbox or other safe simulation. Confirm beforehand that the exercise cannot trigger a real card payment, guest message or courier dispatch. Use fictional guest details and a simulated payment record. A later live-service pilot, if you choose to run one, is a separate step with real operational consequences and should use your approved procedures.
Have the person who would normally host a shift follow the process while a manager watches for decisions that require approval. Start with the original six-person booking. Record four arrivals, then locate the original deposit and show how the $40 credit and $20 disposition are entered. If the workflow depends on the restaurant POS system, ask how the reservation and check are matched and what staff must enter in each place.
Look for observable outcomes, not just a button labeled “deposit.” Can staff see which booking the payment belongs to? Can they record an attendance change without overwriting the original party size? Does the check show the credit? Can a manager find the final disposition afterward? If a step is manual, ask who records it and where.
Next, simulate the $10 exception. Ask the manager to approve it, enter a reason and show how the refund status would be checked. Find out whether the vendor's workflow records who approved the exception and whether staff can distinguish an initiated refund from one completed by the payment provider. A screen that merely permits a note may not provide the approval trail your restaurant needs.
Repeat the walk-through with a guest who reduces the booking before the restaurant's stated deadline. Your expected result may be different from the four-arrival scenario. Ask whether the deposit changes automatically, whether staff must arrange a refund, and what happens if the change is made by phone rather than online. The restaurant management software you use should support a process your team can explain and reconcile, even if some steps remain manual.
Check guest disclosure, channels and the agreement
Show guests the deposit amount and the partial-attendance rule before they commit. The wording should explain what happens when the party shrinks, when changes must be made, how the deposit is applied to the check and how an approved refund is handled. Avoid a vague statement that deposits are “subject to policy” without making the policy easy to find.
Ask the vendor where that wording appears during booking and in the confirmation. Can staff find the terms that applied to a specific reservation if the wording later changes? If a guest books by phone, decide how your team will communicate the same terms and record that conversation. Your lawyer or another qualified local adviser can help assess the terms and current local requirements; software settings alone do not settle that question.
Also ask how the workflow handles each booking source you use, including your restaurant website, phone bookings and Google bookings where available. Can staff identify the source and find the same attendance and deposit information? Do not assume a rule configured for one source applies to another. Ask about permissions, exports, booking-channel attribution and any channel-specific fees in the written quote.
Before committing, compare the answers with the number of partial-attendance bookings your staff actually expect to handle. If exceptions are rare and a manager can document them reliably, a manual step may fit. If staff regularly need to split deposits across busy shifts, require the vendor to show a repeatable workflow that meets your criteria.
Next step: Take the worksheet and your draft policy to a vendor demonstration. Compare your requirements with Fleksa and confirm current availability before choosing a workflow.
Frequently asked questions
Should a deposit be charged per party or per guest?
Either can work. Choose the rule that matches your policy, then ask the vendor to show how it handles a smaller-than-booked arrival and any approved refund.
Can staff simply credit the whole deposit when some guests do not arrive?
That is one possible policy. Write it clearly, check it with a qualified local adviser where appropriate, and confirm that staff can apply and document the full credit.
What should a vendor demonstrate before we sign?
Ask for a safe simulation that shows the original booking, actual attendance, deposit credit, remaining amount and an approved exception. Confirm which steps are automatic and which staff must complete manually.
