To compare booked covers with actual seated guests, keep the original party size and record the number actually seated against the same reservation. Then check that the report shows both numbers, rather than treating a seated status as proof that every booked guest arrived.
That distinction matters when you use reservation reports to plan staffing, review a service, or understand how many guests a booking channel brought in. A host may correctly mark a party as seated while the report quietly counts all six people on the booking, even though only four sat down. The status can be right and the cover total wrong.
Before choosing a restaurant reservation system, decide whether your team can capture that difference during service and whether you can verify it afterward. The worksheet below gives you a practical way to ask.
Define the three counts before comparing reports
A booked cover is one guest expected on a reservation. The input is the party size on the booking. Agree on which version you want to report: the original request, the latest size before arrival, or both. A guest who changes a booking from six to five before service creates a different question from a party of six that arrives with only four.
An arrived guest is someone the host has observed arriving. Arrival may be recorded as a party status rather than a headcount, so ask whether the system actually stores a number of people. A party can arrive in stages, and marking the reservation as arrived does not necessarily mean everyone is present.
A seated cover is one guest who has been seated. The most useful input is a headcount entered or confirmed by the host when the party sits. If the report simply copies the booked size when a host changes the status to seated, it is reporting an assumption, not an observed count.
Also distinguish a physical table from a guest party. One party may occupy two tables, or a table may seat several parties over a service. Count people against reservations first; do not use the number of occupied tables as a substitute for covers.
For a meaningful comparison, define the service period, location, and included booking channels. Decide how you will treat walk-ins, canceled bookings, and parties still waiting at the end of the reporting period. If walk-ins are included in seated covers but not booked covers, label them separately rather than presenting the difference as reservation shrinkage.
Use a smaller party to compare two outcomes
The following example is hypothetical. Assume one restaurant, one dinner service, and one reservation. Six guests were booked and the booking was not changed before arrival. The host observes four guests arrive together and seats all four. No one else joins later. Costs and sales are outside this example; the decision is whether the report represents the headcount accurately.
Use the table as a decision worksheet. Both outcomes start with the same booking and observation. The difference is whether the report preserves the observed seated count or substitutes the booked count.
| Decision point | Outcome A: counts retained | Outcome B: booking copied |
|---|---|---|
| Original booked covers | 6 | 6 |
| Guests observed arriving and seated | 4 | 4 |
| Seated covers shown in report | 4 | 6 |
| Reported difference: booked minus seated | 2 | 0 |
| Buying decision | Suitable for this comparison if staff can make and audit the entry. | Not suitable without a reliable correction and reporting workflow. |
Outcome A gives the owner the comparison needed: two fewer guests were seated than originally booked. It does not explain why. The host might know that two guests canceled late, but that reason should not be guessed from the numbers alone.
Outcome B hides the difference. If an owner uses the reported six covers to plan a similar shift, the report overstates this party's observed attendance by two. Editing the booking down to four might make the seated total look right, but it can also erase the original comparison. Ask what remains visible after an edit and which value each report uses.
This is not the same question as a no-show rate. A no-show measure classifies missed parties according to the restaurant's rules; it does not necessarily reveal that a seated party was smaller than booked. Use the no-show cost guide for that separate decision.
Find the failure before the report closes
The host or floor manager is usually best placed to spot a headcount mismatch: they can see the party arrive and confirm how many people sit. Assign one of those roles to check the count when changing a reservation to seated. If the party joins in stages, agree when the count should be updated and who makes the update.
Ask a vendor to show the fields and actions, not just a dashboard total:
- Can staff see the original booked size, the latest booked size, and an actual seated count separately?
- Is arrival a party status, a headcount, or both? What happens when only some guests have arrived?
- Can an authorized host correct a seated count without changing the original booking? If not, what supported workflow preserves the comparison?
- Who can edit or override a count, and can a manager identify the change and the person who made it?
- Does the service report or export use the corrected count, and can the manager trace a total back to the reservation?
A sensible failure case is a host marking a party seated before checking its size. The host should compare the displayed count with the people at the table and correct it before the service report is finalized. If the host cannot make that correction, the shift manager needs a named route for recording the exception and adjusting the comparison. A note that never reaches the report is not enough on its own.
Some restaurants will accept a manual reconciliation if the volume is manageable. For example, a manager could maintain an authorized shift sheet with reservation identifiers and observed seated counts, then compare it with the booking report. That adds work and creates another place for errors, so include the review time and access controls in your decision. Do not assume that a report or export contains a field until you have seen it.
Booking channels matter too. Ask whether direct website bookings and other available channels are identified consistently, and whether the same correction process works for each. If you accept Google bookings, ask how those reservations appear where available. Channel attribution helps you interpret the figures; it should not change the definition of a seated guest.
Set a demonstration standard and an exception owner
Before the demonstration, give the vendor your definitions and the report you want to see. Ask for a simulated reservation in a demo or test environment with notifications, payments, and dispatch disabled. The exercise should not send a guest message, take a real card payment, or send a courier. A simulated check is not a live service pilot.
- Create the booking. Enter the hypothetical six-person reservation and show its local date, time, channel, and original party size.
- Simulate arrival and seating. Mark the party arrived and seated, with four people observed. Show whether the headcount is entered separately from the status.
- Correct an error. Deliberately enter the wrong seated count, then have an authorized role correct it. Show who can make the change and what the manager can review afterward.
- Run the service report. Filter to the relevant service and show six originally booked and four actually seated for the same reservation. Show how a manager can trace the totals to the underlying entry.
- Check the exception path. Explain what happens if the host forgets the count or lacks permission to correct it. Name the shift manager as the owner who resolves or records the exception before reporting.
Pass: The demonstrated workflow retains the original six, records and reports the corrected seated count of four, and lets the manager trace the result and review the correction. An exception can be assigned to the shift manager and resolved or clearly carried into the reconciliation. Fail: The workflow reports six as actual seated covers, loses the original six when correcting the count, or cannot produce a traceable comparison. A manual workaround can be evaluated separately, but it does not pass this system demonstration.
For your own services, have the shift manager audit status changes before reporting: check parties marked seated, investigate missing or unusual headcounts, and reconcile known corrections. Decide a cutoff for late updates and record unresolved exceptions alongside the report. This makes the report a managed operating record rather than an unexamined total.
If the simulated workflow meets your requirements, consider a separate, authorized live service pilot with normal guest and staff procedures. Assign a manager to compare observed counts with the report and collect exceptions; do not assume that a successful demo proves staff can sustain the process during a busy shift.
For your next step, compare this checklist with Fleksa's reservation system and confirm current support for the fields, permissions, and reporting workflow you need. The table reservations documentation can help you prepare questions about the booking workflow before that conversation.
Frequently asked questions
Are booked covers the same as seated covers?
No. Booked covers are expected guests on reservations; seated covers are guests who actually sit down. A useful comparison specifies which booking version is used and how the seated headcount is captured.
Can a seated status prove how many guests were seated?
Not by itself. A status may apply to the whole party while the displayed count still comes from the booking. Ask how staff enter or confirm the actual number and how corrections reach the report.
What if the reservation system cannot store actual seated covers?
Consider a separate, controlled shift reconciliation if the extra work is acceptable. Assign a manager to match observed counts to reservations and resolve exceptions. Treat the manual process as a workaround, not proof that the system provides the report.
