A useful restaurant blocked tables report should let you separate tables assigned to guest bookings from tables held back for operational reasons. It should also show what was available, what was out of service, and which capacity figure sits underneath any occupancy percentage.
Ask to see the report and its underlying records, not just the availability screen. A system can prevent guests from booking a table without giving a manager enough detail to explain why that table was unavailable. Use the checks below when comparing reservations software.
Classify physical tables for one service window
Start with a defined point in time or a clearly labeled service window. Count physical tables, not reservations or guest parties. One party may need two tables, and a table may serve more than one party during an evening.
The following worksheet is hypothetical. Assume a restaurant has 10 physical tables at 7 p.m. on Friday. Three guest parties have reservations: two parties have one table each, and the third party has two tables joined together. Every table has one primary status at that moment.
| Table IDs | Status | Count | Reason or assignment |
|---|---|---|---|
| 1–4 | Booked | 4 | Assigned to three guest parties |
| 5–6 | Blocked | 2 | Patio closed for this service |
| 7–9 | Available | 3 | Open for booking or seating |
| 10 | Out of service | 1 | Table damaged; awaiting repair |
The rows add up to 10 physical tables. Four are booked, but that does not mean four parties are booked. Two more are unavailable because of a service decision, and one is unavailable because it needs repair. The remaining three are available. If the report simply combines tables 1–6 and 10 as seven unavailable tables, it cannot answer the owner’s question on its own.
Agree on definitions before comparing products. For this worksheet, a block is a temporary operational hold, such as a closed patio or a staffing decision. Out of service identifies a physical table that cannot currently be used. Your restaurant may use different labels; what matters is whether the report preserves the distinction you need.
Ask how the system handles conflicts. If a booked table is later blocked, does the report show both records, flag a conflict, or silently assign one status? Also ask whether a booking without an assigned table appears separately. An unassigned party should not disappear from a service review merely because it is not yet tied to a physical table.
Compare occupancy denominators before trusting a percentage
Using the same 7 p.m. snapshot, four booked tables can produce different occupancy percentages depending on the denominator:
- All physical tables: 4 booked ÷ 10 total = 40%.
- Tables excluding the damaged table: 4 ÷ 9 = about 44.4%.
- Tables open for guest use: 4 ÷ 7 = about 57.1%; this excludes the two blocked patio tables and the damaged table.
Each figure answers a different question. The first shows booked use against the whole floor plan. The second removes the table awaiting repair. The third measures booked use against the tables the restaurant chose to make available for that moment. None is automatically the best measure for every decision.
A manager reviewing staffing may want the third figure alongside the patio block. An owner considering repair priorities may want the first or second figure as well. If the report only shows “57% occupied,” ask what it excludes. A percentage without a denominator can hide a closed section as easily as it can reveal demand.
Also ask what “occupied” means. A reservation assigned to a table is not necessarily a party currently seated there. A report may measure bookings, seated tables, or time in use. Those measures should not be treated as interchangeable.
For a whole service, check whether the report uses a snapshot, a count of table assignments, or table-time. Adding together snapshots can count the same table more than once. If the product offers a service-level percentage, request its calculation and confirm whether blocks are excluded for their full duration or only at selected times.
Check whether every block has a reason, duration and author
Use a vendor demonstration or a safe practice environment to recreate a small version of the worksheet. Set the scenario up as a simulation: it must not send a real guest message, take a card payment, or dispatch a courier. Do not use real guest details unless you have authorized access and a suitable method.
Ask the vendor to demonstrate these checks:
- Create an operational block for two tables with a clear reason, start time and end time. Confirm that the report identifies those tables as blocked rather than booked.
- Record a damaged table separately. Check whether a manager can tell it apart from the temporary patio closure in the report or export.
- Change the end time of the patio block. Check whether the current duration is visible and ask whether the earlier value is retained in a history.
- Have an appropriately permitted user make the change. Check whether the record identifies who created or changed the block, and when.
- Remove or shorten a block in the simulation. Check how the report represents the released time and whether any history remains available.
The decision boundary is straightforward: if a manager cannot identify the affected tables, reason, start and end times, and responsible user from a report or accessible history, the workflow does not fully meet this review requirement. A useful workaround may still exist, but price the staff time and risk of maintaining it separately.
Check permissions as well. Can a host make a short operational block? Can only a manager change a repair status or view the history? Ask who can edit, remove and export records, and whether permission changes affect the audit trail. Do not assume that a user name shown on the current record is a complete change history.
Once the simulated checks pass, consider a limited live-service pilot with a named manager and normal restaurant procedures. Review real blocks after service rather than creating unnecessary live holds. A pilot can show whether staff consistently use the agreed reasons; a simulation alone cannot establish that.
Set up a weekly manager review and export
Ask for a sample export before signing. A screen can be useful during service, while a weekly file lets a manager compare patterns across shifts. Check the file’s field names, time zone, date range and whether one row represents a table, a booking, a block or a change to a block.
For blocked-capacity review, request these fields where available:
- Physical table ID, service date, and block start and end in local time.
- Status and reason, with enough detail to separate an operational hold from a table awaiting repair.
- Creator and last editor, plus creation and change times, or a separate history linked to the record.
- Booking reference and party size where relevant, with a clear way to identify an unassigned booking or an assignment spanning multiple tables.
- Reported numerator and denominator, or the underlying records needed to calculate them.
Review the previous week by shift. Start with the longest or most repeated blocks, then ask whether each reason was still accurate and whether the end time matched the actual service decision. A recurring staffing block may prompt a scheduling discussion; a repeated repair status may prompt a maintenance decision. Neither should be counted as guest demand without further evidence.
Reconcile a sample shift back to the floor plan and reservation list. Check that physical table IDs are not duplicated and that joined tables are not mistaken for separate parties. If the export lacks change history, decide who will keep a separate log and how often they will check it. Include that recurring work in the operational comparison.
For a broader restaurant management review, keep blocked capacity separate from no-shows. A reserved table that goes unused because a guest did not arrive raises a different question from a table the restaurant chose not to sell. The guide to measuring reservation no-shows can help with that separate review.
To compare the workflow with Fleksa, bring the table statuses, required export fields and decision boundary to a conversation about its current product fit. Ask for a demonstration using your own reporting requirements before deciding.
Frequently asked questions
Is a blocked table the same as a booked table?
No. In this review, a booked table is assigned to a guest reservation; a blocked table is held back for an operational reason. Ask each vendor how its report labels both.
Should blocked tables be included in occupancy?
That depends on the question. Include them when comparing booked use with the entire physical floor plan; exclude them when measuring booked use against tables open for guests. Label the denominator either way.
What if the report cannot show who changed a block?
Ask whether a separate history or export provides that detail. If not, decide whether a manual log is practical and include its upkeep in your comparison.
