A manager can audit a seated party's cover count only if the reservation system records enough detail: the earlier value, the replacement value, who made the change, and when. Some systems may allow staff to correct a count without keeping that history visible. Ask to see the actual workflow and report before relying on either.
For restaurant reservation cover count changes, the buying decision has two parts. First, decide who should be allowed to edit a seated party. Then check whether a manager can reconstruct what was overwritten, including multiple corrections. A final number alone answers neither question.
Separate the count at each stage
A cover is one guest, not one physical table or one party. A party of five seated across two physical tables is still five covers. When checking a correction, keep the reservation or party identifier in view so a table move or split does not accidentally turn one party into two counted parties.
Three values matter for a seated reservation:
- Original booked covers: the party size recorded when the reservation was made.
- Initial seated covers: the count entered when staff marked the party as seated.
- Later corrected covers: any values entered after seating, ending with the final recorded count.
Those values can differ for ordinary reasons. A guest may arrive late, a child may have been omitted, or the host may correct a keying mistake. The original booking explains what was expected; the initial seated value and later edits explain what staff recorded during service.
This is narrower than comparing total booked covers with total seated covers. The question here is whether a manager can follow an individual seated party through a correction. If the system only shows the latest count, a manager may see the final number without knowing whether it changed once, changed twice, or was entered that way at seating.
Decide which moment your team treats as the initial seated count. If a host can change the party size immediately before marking a reservation seated, ask whether that change is recorded separately from a post-seating edit. Also ask whether reopening a closed reservation creates another edit or replaces the earlier record.
Set permissions around the actual shift
Start with the people who encounter a correction. A host may notice an extra guest at the door. A server may notice that a guest left before ordering. A manager may make a correction after closing. Map those situations to the permissions you want rather than assuming every product uses the same staff roles.
For each role offered by a vendor, ask whether the person can view the count, change it after seating, change it after the reservation is closed, or view the edit history. These can be separate permissions. A staff member who can fix an obvious mistake does not necessarily need permission to alter old records or remove an audit entry.
Use questions like these in a demonstration:
- Can the permission to edit a seated count be assigned separately from general reservation editing?
- Can permissions differ by location, shift, or individual account?
- Is a reason required, optional, or unavailable? Can a manager see it alongside the edit?
- Can an employee change another employee's entry, and does the history identify the person who actually made the change?
- Can anyone delete or alter the history, and how would a manager know?
- What happens when a correction is needed but the only authorized manager is away?
Individual logins matter to the answer. If several people use the same account, a record may identify that account without identifying the person who made the edit. Ask how the system handles shared devices and whether staff can switch users quickly enough for a busy host stand.
A reason field is useful only if staff can find it and managers can read it later. Agree on short, practical reasons such as “late arrival” or “entry error,” if the product supports them. Avoid putting unnecessary guest details in a free-text note. If a reason cannot be required, decide whether your operating procedure needs a separate correction note and who will check it.
There is a tradeoff. Restricting every correction to a manager may slow service; allowing everyone to edit closed records may make later review harder. A workable policy might let a host correct an active seated count while reserving closed-record changes for a manager. Treat that as a requirement to verify, not a setting to assume exists.
Trace what was overwritten
The following is a hypothetical practice record, not a claim about any product. The reservation was originally booked for four guests. At seating, the host recorded three. A server then corrected the seated count to four, and a manager later corrected it to five after confirming another guest had joined.
The table shows one initial entry and two later edits for the same party. Times are local to the restaurant. The names are example user accounts, not evidence that a particular system supplies these roles.
| Local time | Recorded by | Previous seated value | New seated value |
|---|---|---|---|
| 6:10 p.m. | Host account | Not yet seated | 3 |
| 6:24 p.m. | Server account | 3 | 4 |
| 6:41 p.m. | Manager account | 4 | 5 |
The final seated count is five. The overwritten values are three and four. The original booking of four is a separate value; it should not be mistaken for proof that the seated count was never changed. If the report displays only five, it may be adequate for a final-cover total but it fails the history check.
Ask the vendor to show the sequence on the reservation itself and, if available, in an export. A useful history links each change to the same party, shows the old and new values in order, and identifies the account and time. Confirm whether the display uses the restaurant's local time and how it handles a change near midnight.
Also ask how long history remains accessible and whether a manager can retrieve it without opening every reservation individually. A daily export may be useful for review, but a file containing only the final count is not an edit log. If an older value is absent, ask whether it can be recovered, who can retrieve it, and what that process costs. Do not treat a verbal assurance that changes are tracked as a substitute for seeing the fields.
If full history is unavailable, decide whether a separate correction register would be practical. It could capture the reservation identifier, old and new counts, editor, time, and reason. Assign someone to reconcile it with the reservation record. That adds work and depends on staff making the entry; it is not the same as an automatic audit trail.
Check the final report without duplicating covers
Run a controlled simulation before making a purchase decision. Use a vendor demonstration or a practice environment with a clearly labeled test reservation and staff test accounts. Do not use a real guest's details. Configure the exercise so it sends no guest message, takes no payment, and triggers no courier dispatch. Confirm those safeguards with the vendor before starting.
Enter the hypothetical sequence above, then inspect both the reservation history and the final service report. This is a simulation, not a live service pilot. If you later run a live pilot, use your normal authorized booking process and assign a manager to review real changes; do not assume the simulation proves every live workflow.
Use these pass or fail checks:
- History: Can the manager see three changed to four and four changed to five, with the responsible accounts and times? Showing only five fails this check.
- Final count: Does the reservation show five as its final seated count after both corrections?
- Report total: For this one test party, does the report contribute five covers rather than adding three, four, and five together? Those entries describe revisions, not three separate parties.
- Identity: Do the edits and the final count remain attached to the same reservation, even if its physical table assignment changes?
- Access: Can the intended manager find the history, and can a test account without edit permission be prevented from making the correction?
Record each result and the screen or export used to verify it. If a check fails, ask whether a configuration change, another report, or a supported export resolves it. Repeat the check after any change. If the vendor offers no way to see overwritten values, mark that requirement as unmet rather than assuming the final report contains a hidden history.
When comparing a direct restaurant reservation system with a discovery-led service, also ask whether booking-channel attribution stays attached to the reservation after a correction. OpenTable offers reservations, restaurant operations, and a diner discovery network. Fleksa offers direct restaurant reservations and availability-qualified Google reservation paths. Ask each vendor about edit permissions, exports, channel attribution, and relevant fees; neither booking model answers the audit question by itself.
Before deciding, consider how the result will reach the rest of your operation. Ask whether the final cover count and its history appear in the reports your managers use, including any connection to your restaurant management software. A final count may be enough for a service summary, while an investigation needs the individual changes. Those are different reporting requirements.
For the next step, take the five checks above to a Fleksa demonstration and compare the answers with your written requirements. Ask to see the relevant permissions, overwritten values, and final report in the reservation workflow before buying.
Related guide: Restaurant Reservation Form Fields: What to Ask Guests.
Frequently asked questions
Who should be allowed to change a seated cover count?
That depends on your shift procedure. Decide who needs to fix active reservations and who may change closed records, then ask whether the system can enforce those choices with individual accounts.
Is the final cover count enough for an audit?
No. It can show the current recorded total, but it does not establish what was overwritten, who made a correction, or when. Ask to see the individual edit history.
Should every correction add covers to the service report?
No. A correction replaces the previous recorded count for that party. Check that the final report counts the final value once while retaining the earlier values separately for review.
