Keep a reservation request pending when a staff member must check something the booking rules cannot reliably settle: a private room, a seating arrangement, a service constraint, or a request that depends on another booking. Confirm it only after the reviewer can account for the physical space and the staff needed to serve the party.
A pending request is not a confirmed table. The guest should see that distinction before submitting it and know when to expect an answer. For ordinary requests that fit known capacity rules, requiring approval can add unnecessary delay. The goal is to reserve staff review for decisions that need judgment.
Separate a request from a confirmed booking
A party-size limit answers a narrow question: is this number of guests allowed to book online? An approval workflow answers a different one: can the restaurant meet this particular request at this time? A party can be within the online limit and still need review because it asks for a private room or a specific seating arrangement.
Use four distinct states when discussing the workflow with your team and software provider:
- Pending: The restaurant has received a request but has not promised the space.
- Accepted: Staff have approved the request, and the guest can treat the booking as confirmed.
- Declined: The restaurant cannot fulfill the request as submitted. An alternative time or arrangement is a separate offer, not an automatic confirmation.
- Expired: The response deadline passed without an acceptance. Agree in advance on what this means for the guest and the space; software may handle it differently.
Ask whether pending requests appear alongside confirmed bookings, whether they temporarily hold any capacity, and who can change their status. If a pending request does not hold space, staff need to recheck availability before accepting it. If it does hold space, find out when that hold is released so an unanswered request does not block a table indefinitely.
The guest-facing wording matters too. “Request received” should not look like “reservation confirmed.” Ask what appears on the booking page and in any message at each state. Check whether a request made through an available Google booking path follows the same approval rules as one made on your website.
Decide which requests need a person
Start with the exceptions your staff already discuss by phone. A private room may be unavailable because of an event, a staffing constraint, or a layout change that has not been reflected in the booking calendar. A guest might need step-free access, room for a stroller, or a seating arrangement that requires combining tables. The relevant question is whether the request can be fulfilled, not whether the guest falls into a category that deserves extra scrutiny.
Hypothetical example: A restaurant has one private room with three physical tables. Each table seats four guests, so the room's maximum is 12 guests. On a Friday evening, one confirmed party of four already occupies one table for the requested period. A new party of eight requests the room and asks to sit together.
The headcount fits the remaining capacity: two tables with four seats each. That does not settle the request. A staff member must check whether those two tables can be joined into one suitable arrangement, whether the existing party will still have adequate space, and whether the room can be served as requested. If those checks pass, the reviewer can accept. If the tables cannot be joined, the reviewer should decline the request as submitted or offer a different arrangement for the guest to consider.
The example uses three physical tables and two guest parties. The private room's 12-seat maximum is a physical constraint, not a promise that every combination of parties can be seated comfortably. The decision also depends on overlapping reservation times: a table that becomes free later may not be available for the full requested period.
Build a short review checklist for each exception. For a private room, include occupancy during the full time window, layout, and staff coverage. For a seating need, check the actual route and table placement with the person who knows the room. Record only the detail needed to handle the request, and ask the guest a follow-up question if the request is unclear rather than making assumptions.
A restaurant reservation system can help organize bookings, but ask the provider which request types can be routed for approval and which details the reviewer can see. Do not assume that an online party-size setting handles room layout or special arrangements.
Give pending requests an owner and a clear next action
A request can sit unanswered when everyone assumes someone else is watching it. Assign a primary reviewer for each service period and a backup for days off or busy shifts. Decide where the team will look for new requests and how often. A manager may own private-room decisions, while a host may be able to approve ordinary seating exceptions.
The table below is a working decision map. It describes a restaurant's intended process, not a promise that every system performs each action automatically. Use it to ask a provider which steps staff must perform themselves.
| State | Staff action | Guest expectation | Capacity to check |
|---|---|---|---|
| Pending | Assign a reviewer and check the request. | Request received; no table promised yet. | Determine whether space is held and recheck before approval. |
| Accepted | Record approval after checking space and service needs. | Booking is confirmed with the agreed details. | Count the confirmed booking against the relevant time and space. |
| Declined | Record the decision; offer an alternative if appropriate. | The original request is not booked. | Release any hold associated with the request. |
| Expired | Follow the agreed overdue procedure and check for unresolved requests. | The request is not confirmed; the next step should be clear. | Check whether any hold has ended before reallocating space. |
For the hypothetical private-room request, the reviewer would open the pending request, check the confirmed party and the table layout, then make a decision. If the arrangement works, the acceptance should identify the date, local time, party size, and room. If it does not, a decline should not suggest that the original arrangement is reserved. A proposed alternative needs the guest's agreement and a fresh capacity check.
Ask whether the system records who made a decision and when, whether staff can add an internal note, and whether another employee can see the current status before contacting the guest. Also ask whether acceptance, decline, and expiration generate messages automatically or require a manual action. If messages are automatic, review their wording and timing before relying on them.
For a broader look at settings and terminology, consult Fleksa's reservations FAQ. If you compare a booking tool with wider restaurant management software, include the handoff between the booking screen and the staff member responsible for the dining room.
Set a deadline and rehearse the exceptions
Choose a response deadline your team can actually meet. A request submitted before a busy dinner service may need a different response window from one submitted after closing. Tell guests the expected response time and what to do if they have not heard back. If the requested visit is sooner than your normal review window, decide whether to stop accepting that type of request online or direct the guest to contact the restaurant.
Ask the provider what happens when the deadline passes. Does the request change to expired automatically, remain pending for staff to resolve, or require another action? Is a capacity hold released? Is the guest notified, and can staff still accept the request afterward? If the system does not support your preferred behavior, write a manual procedure and assign someone to monitor overdue requests.
Rehearse the private-room scenario with fictitious details in a safe simulation or demonstration environment. Follow the request from pending to acceptance, then separately rehearse a decline and an overdue request. Check the status, the displayed capacity, and the message that would be sent at each step. The simulation must not create a real guest message, payment, or courier dispatch. Ask the provider how to prevent those actions before starting.
Then, if you choose to run a live service pilot, use your actual booking process with staff watching the review queue. Real guest communications may occur during that pilot, so make sure the team knows who sends them and how to correct a mistake. Review unanswered requests at the end of each shift. A pilot can reveal a slow handoff or confusing wording; it cannot guarantee that no request will be missed.
For your next step, take one request type that regularly needs judgment, write down its reviewer and deadline, and compare the relevant workflow and current availability with Fleksa. Ask to see how pending status, capacity holds, decisions, and guest notices would work for that request before you make a buying decision.
Frequently asked questions
Should every reservation require staff approval?
No. Approval is most useful when a request needs a capacity or service check that ordinary booking rules cannot settle. Routine bookings that fit known availability may be better confirmed without an extra handoff.
Does a pending request reserve a table?
Not necessarily. Ask whether the system holds capacity while a request is pending, how long the hold lasts, and whether it is released after a decline or expiration. Recheck availability before accepting if no hold exists.
What should happen if staff miss the response deadline?
Follow a documented overdue procedure: identify the request, check its current capacity hold, and give the guest a clear outcome. Ask whether expiration and notification are automatic or require staff action.
