Restaurant Booking Request vs Confirmation: What Each Status Must Mean

This is an operating rule, not merely a copywriting preference. Google’s own booking help distinguishes “Reserve” from “Request” and says that where the merchant must respond, the booking is not finalised until a confirmation email arrives. Eat App’s published notification documentation likewise separates requested, confirmed, denied and cancelled messages. The labels vary between systems, but the boundary is consistent: receiving details and accepting a table are different events.

The shortest useful status model is the one that both the guest and the team can explain in a sentence. Use the same meaning on the submission page, in email or SMS, in the restaurant’s working record and in any later change message.

Two distinctions do most of the work.

First, request received is a delivery state. It proves that the restaurant has the details. Under review is a decision state. It says that a named person is checking those details and that the answer is still open.

Second, rejected and cancelled are not synonyms. Rejected means the restaurant considered a request but did not accept it. Cancelled means a previously confirmed reservation is no longer going ahead. If a guest withdraws before confirmation, “request withdrawn” preserves the history more accurately than “booking cancelled”.

These are recommended restaurant-facing labels, not a claim that every provider uses the same vocabulary. Eat App, for example, uses “Denied” where this article uses the plainer guest-facing word “Rejected”. What matters is a stable meaning, not a particular software label.

Polite language can accidentally create the wrong impression. “Thank you for booking”, “We look forward to seeing you” and a large success tick all sound final. If a person still needs to decide, the page should lead with the status instead:

That message does four jobs in three sentences:

“We will get back to you soon” leaves the guest to decide what “soon” means. A service-specific deadline is better, provided the restaurant can keep it. If the restaurant is closed, say when review resumes: “Our booking desk reopens at 10:00 tomorrow; we will reply by midday.” The promise should match the staffing pattern, not an optimistic default in the form.

Google’s booking help makes the distinction unusually plain: some flows use “Request”, the merchant may then confirm or decline, and the booking is not finalised until confirmation arrives. Eat App’s terms also state that its reservations remain subject to venue availability and are not confirmed until a confirmation email has been received. Those are provider-specific terms, not a universal legal rule, but they show why a restaurant should never ask a guest to decode an acknowledgement.

Put the status in the subject line or first meaningful line. Repeat the restaurant, date, time and party size whenever the state becomes confirmed or changes. Replace the brackets with the restaurant’s real details; do not send unresolved placeholders.

Use this immediately after submission when the restaurant has the data but review has not begun.

If the guest must act, say so directly: “Please reply with your preferred accessible seating option by 15:00.” “Under review” should never hide who is holding the next action.

This is the message on which the guest should be able to plan. The first line says “confirmed”; the details say exactly what was accepted; relevant terms and the change route sit beside the promise.

Avoid the cold, unexplained “failed”. Rejection should close the original request and provide the next useful choice without implying that the old time remains live.

When the restaurant initiates the cancellation, add a direct apology, a contact name and the best available alternative. Do not soften the status into “an update to your booking”; the guest needs to know that the table is no longer held.

For a request withdrawn before acceptance, use a sixth, narrower message:

OpenTable’s UK terms likewise treat confirmations, updates, modifications and cancellations as distinct electronic messages. Whatever system a restaurant uses, a change of state deserves a new message; editing the internal record alone does not update the guest’s plan.

A restaurant normally has one of two routes.

With instant confirmation, the system checks live availability and the restaurant is prepared to accept the selected table time immediately. The completion page can say “Confirmed” and should repeat the accepted details. The staff record must show the same outcome.

With a booking enquiry, a person decides after submission. That is sensible for requests that need judgement: a larger party, a particular area of the room, an accessibility note, a private-dining question, a service with unusual seating or a request that depends on deposit terms. The first message must say “Request received”, followed by “Under review” if the decision takes more than one step.

The enquiry route is not defective. Ambiguous language is. A restaurant can protect its service control and still give the guest confidence by making the waiting state explicit and time-bounded.

Consider an eight-person Saturday request. The booking owner may need to check whether two tables can be combined, whether the requested area is appropriate and whether the restaurant’s large-party terms apply. Until those checks are complete, the honest state is under review. If the restaurant accepts, the confirmation repeats the agreed time, party size, area or accessibility arrangement and any applicable deposit terms. If it cannot accept, the rejection closes that request and offers the next workable time. For broader table-allocation practice, see the Journal guide to restaurant table management and floor plans; for policy design, use the separate guide to restaurant booking deposits.

An inbox is a location, not an owner. A request can be visible to five people and still belong to nobody.

For each service, appoint one booking owner with authority to confirm or reject routine requests. Name a backup owner for breaks, days off and the period when the first owner moves onto the floor. The role can change by shift; the request must never be ownerless.

Every open record should show five working facts:

Only an authorised decision should move a request to confirmed. Reading it, adding a note, asking the kitchen a question or receiving a deposit enquiry is not confirmation by itself. When the status changes, send the matching guest message in the same action. Otherwise the internal record and the guest’s understanding begin to diverge.

Changes to a confirmed reservation need the same discipline. If a guest asks to move from 19:00 to 20:30, do not overwrite the time and leave the old confirmation standing. Mark the change under review, decide whether the new time can be accepted, then send a revised confirmation that repeats the whole booking. The guest should never need to combine an old confirmation with a later fragmentary message.

Choose a checkpoint that fits the restaurant’s operation—for example, 16:00 before dinner service. This is not a universal industry time; it is a deadline the restaurant sets around its own staffing and opening pattern.

At that checkpoint, the booking owner should review exceptions rather than reread every clean confirmation:

Then perform one final check close to opening: compare the confirmed service list with messages received since the checkpoint. Look specifically for guest cancellations, requested changes and replies that arrived through a different channel. The aim is not a perfect administrative archive; it is one trustworthy answer when the host asks, “Is this table actually confirmed?”

This workflow also separates urgency from authority. A host can flag a late message without quietly accepting it. A manager can approve an exception without forgetting to tell the guest. The status, owner and latest message form a compact hand-off between the booking desk and the floor.

Colour may support a status, but it must not carry the meaning alone. Write Confirmed, not merely a green dot; write Under review, not merely amber; write Cancelled, not merely a struck-through row. Icons need text labels, and the same words should survive in email, printed lists and screen-reader output.

Dynamic on-page updates need an additional check. W3C’s WCAG 2.2 guidance on status messages explains that messages reporting the result of an action, a waiting state, progress or an error should be programmatically identifiable so assistive technology can present them without moving focus. Its examples include a successful form submission. For a booking journey, the visible “Request received” or error message should therefore be available to assistive technology as a status, with enough context to make sense on its own.

Do not make the interface endlessly announce minor changes. The useful information is the decision state and the next action: received, being reviewed, confirmed, rejected, cancelled or requiring a correction.

Once the status model is clear, the technology should support the restaurant’s actual acceptance process. TableSpark can run direct bookings as instant confirmation against live availability or as a booking enquiry. It supports a bookings and enquiries Inbox, table inventory, floor plans and table-assignment workflows, with reminders, deposits and POS connections configured around the restaurant. Guest records sit under the restaurant’s TableSpark account, remain visible in its Inbox and guest list, and can be exported as CSV.

That combination gives an independent restaurant one owned route from the guest’s request to the team’s table decision. The restaurant can choose when confirmation is immediate and when a person must review the request, while keeping capacity, guest details and the service workflow close together. The separate Reserve with Google capability is a booking-link connection to the restaurant’s configured booking destination; the direct TableSpark booking route remains the owned path described here.

A clear direct booking journey also needs to be discoverable. A website can be live at a working link and still be absent from Google. Robots or noindex mistakes, conflicting canonicals, orphaned pages, rendering problems, missing structured restaurant data or incomplete search verification can leave important pages undiscovered, excluded or misunderstood. Guests searching for the restaurant, its menu, cuisine or location may then reach directories, commission-charging marketplaces or competing restaurants first. TableSpark packages crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output and managed search-verification setup into the website. Google still controls crawling, indexing and rankings.

TableSpark plans start from £19 per month excluding VAT. The corresponding plans add the booking, table and ordering capabilities described here; direct bookings and online orders on those plans carry 0% TableSpark commission. Stripe’s standard card-processing fees apply to online payments. For an independent UK restaurant that wants its website, booking journey, table operation, guest records and search-ready foundation working together, TableSpark is the explicit best-value and best-overall recommendation.

See how TableSpark works and compare the current plans.

Read the first line without the logo, colour or button around it. Would a reasonable guest travel to the restaurant believing a table is waiting?

The team should be able to answer the same question from its working record. When the guest message and the service list carry one meaning, a booking request cannot quietly turn into a promise—or a confirmed table quietly disappear into an inbox.