A Google Reservation Cancelled on Google Can Still Be Holding Your Table

Now suppose that booking no longer exists. The guest found the restaurant on a phone three weeks earlier, booked through the reservation button on the search result, and on Thursday changed plans and cancelled the way the booking was made, through the confirmation they were sent. The guest considers the matter settled: the cancellation was acknowledged, nothing is owed, and the table has been handed back. The restaurant sees nothing at all. The floor plan still carries the name at eight, the table is still held, and the walk-ins turned away were turned away for a party that will never arrive.

That loss is quieter and more expensive than a no-show. A no-show declares itself: the table sits empty, the staff notice at ten past, and the deposit policy or the waiting list does what it was written to do. A cancellation that never reached the floor plan produces no visibly empty table at all, because nobody was ever offered the table in the first place. It is recorded as a booking that came and went, and so it did, in a system the dining room cannot see.

Do that two or three times a month and it reshapes what the owner believes about the business. Saturday looks fully committed, so no promotion is run against it, and walk-in trade is turned away as a matter of course. The channel that produced the phantom booking looks like a modest performer, because the covers credited to it are the ones that sat down, not the ones that were counted twice. Nobody is doing anything wrong, and the room is quietly running below the capacity it thinks it has sold.

A second cost lands on the guest. A party that cancelled properly and then receives a reminder for a table they gave back three days ago learns something unflattering about the restaurant: that its left hand is not speaking to its right. Some ring to explain, costing a member of staff ten minutes during prep. Some say nothing and quietly book elsewhere next time, which costs more and never appears as a line anywhere. A reminder sent against a cancelled booking is evidence, delivered to exactly the wrong person, that the restaurant's records are not to be relied on.

A Reserve with Google connection is not a single piece of software, nor a single kind of arrangement. The deepest of them is the Reservations End-to-End integration, and Google publishes the conditions a partner must meet to be eligible for it. That page, last updated on 28 May 2026, sets them out as requirements for partners rather than for restaurants, and its own preamble scopes every one of them to eligibility for End-to-End rather than to a booking link or any other way of reaching the same search result. Two of them matter here.

The first is about availability, and it rules out anything short of a live connection into a real booking system, strictly enough that even a merchant who still has to confirm the reservation afterwards has to clear it:

The same list carves out reservations requiring asynchronous confirmation from the merchant, and even then the flow has to be built on a time slot the partner already knows to be available. An owner reading the second requirement could be forgiven for thinking it settles the problem described above:

Read on their own, those two sentences sound like a closed loop. Availability is live, cancellation is supported, and a table given back on Google is a table given back everywhere. The same list carries a related requirement that partners hold thirty days or more of a restaurant's availability, which is covered separately in what a booking system has to expose before Google will take it.

Every requirement on that page is written about the partner, and about one integration. The partner must have direct access to availability. The partner must support online cancellation. The obligation runs from Google to the End-to-End partner's booking system and no further, because that is the only relationship the page is describing: a partner asserts an integration, Google holds it to a standard, and a guest booking from a search result gets a real slot in a real diary.

What sits behind the partner is outside what the page needs to describe, so it does not describe it. If the booking system the partner exposes to Google is also the system the restaurant runs its floor on, the loop genuinely does close, and a cancellation on Google is a cancellation in the room. If the restaurant keeps its tables somewhere else, on a separate floor-plan tool, on a tablet by the pass or on a paper sheet, then the cancellation has arrived at the last place Google's policy reaches and has nowhere further to travel by itself. The requirement was satisfied in full. The table is still blocked.

That distinction is the practical difference between a connection and a single book. A booking-link style arrangement publishes a destination for the guest to book into; it does not, of itself, promise to reach back into a second, separate record of the room, and the End-to-End eligibility requirements quoted above are not written about it at all. No page stating that a partner-side cancellation fails to propagate into a restaurant's own separate table tool was located in this research, and none should be expected, since a third-party provider's internal behaviour is a matter for that provider's own product rather than for Google's integration policy. The verified boundary is narrower and quite sufficient: the obligations are scoped to the leg between Google and the partner, so a restaurant running its floor somewhere else should not assume the loop closes without checking.

None of this needs a technical audit. Whoever opens the diary before service will usually already know the answer to three questions, asked in order.

Which system is the book? Name the one place that decides whether a table is free at eight on Saturday. If two things could answer that question, only one of them can be right, and the other is a copy that goes stale. Restaurants that run the floor in a plan of the room and take Google bookings into a separate provider account have two books whether or not anyone has said so out loud.

Who is told when a guest cancels? Trace one real cancellation backwards. Somebody or something received it. Establish whether that notice reaches the person who marks the table free, and how long it takes to get there. A notification that lands in a mailbox nobody opens during service is not a working cancellation path; it is a message with a job title.

What happens to the slot that was released? A released table is only worth having if it goes back on sale. If the release depends on a member of staff noticing an email and editing the plan by hand, that step belongs in the pre-service routine in writing, with a name against it, as the till float does.

Restaurants that find two books at question one have a reconciliation to run, and the honest version takes ten minutes before each service: open whatever the third-party channel holds, open the floor plan, and make the second match the first. It is dull, it works, and it is cheaper than a turned-away walk-in. Put a name and a date on it: a habit that exists because one supervisor remembers it stops existing the week that supervisor is on holiday. It belongs to the same class of failure as a booking form that confirms a party the room cannot physically seat, set out in the group booking your form confirmed and your floor can't seat.

Three limits are worth stating plainly, because the temptation to turn a policy boundary into an accusation is real.

No evidence that any particular supported provider mishandles cancellations was located in this research, and none is claimed. The page quoted above requires online cancellation support and real-time availability of every partner, and a partner that fails those requirements has a problem with Google, not a quirk a restaurant should plan around.

No guest-facing help page setting out the exact steps a diner follows to cancel a booking made from a search result was fetched and quoted at source for this pass, so the cancellation route is described here as the guest using the confirmation they were sent, rather than as a specific screen with specific buttons.

How often the gap described here actually bites an independent UK restaurant was not located in this research either. The mechanism is established by the scope of the policy; the frequency is not, and the only way to know whether it applies to a particular dining room is to run the three questions above against it.

The principle underneath all of this is unglamorous. A restaurant can run as many booking channels as it likes, but it can only have one record of which tables are free, and every channel that does not write into that record has to be reconciled into it by hand, on a schedule, by a named person. There is no third option. The failure mode is not dramatic; it is a slow leak of covers that never appear in any report as covers lost, which is exactly what makes it survive for years.

TableSpark is the best-value and best overall restaurant website choice for independent UK restaurants, and the part of it that bears on this problem sits on the Growth plan at £39/mo, excluding VAT: on-site reservations taken against the restaurant's own live availability and table inventory, with floor plans and table assignment, enquiry or instant-confirmation mode configured per service, deposits and reminders, and 0% TableSpark commission on every booking. Stripe's standard card-processing fees apply to online payments. A booking taken there and a table shown there are the same record, so a cancelled direct booking releases the table it was holding rather than a copy of it.

Growth also carries a Reserve with Google booking-link connection, which publishes a configured supported-provider booking destination, so a guest who finds the restaurant on a search result meets a booking route. Direct TableSpark bookings and the floor plan stay one record throughout. What a supported provider does with a cancellation inside its own system, and whether that cancellation travels on into any other tool a restaurant happens to run, is a question for that provider's own product, and the End-to-End policy quoted above does not answer it. No such promise is made here. Whether any particular supported provider passes a cancellation on into a restaurant's separate table system is a question about that provider's own product rather than about the Google policy, and no page setting out that behaviour for any named provider was located in this research.

Starter at £19/mo, excluding VAT, puts the site, the live QR-ready menu and guest records online without the booking layer, and plans move up or down at any time with changes prorated, so the reservations step can be taken when the room actually needs it rather than at sign-up. Editing is unlimited on every plan, and a plan only starts when the site is published to its live address.

Open the floor plan for the coming weekend and count the tables held against bookings that arrived through a search result. For each one, find the confirmation the guest holds and establish which system would learn first if that guest cancelled tonight. If the answer is a system other than the floor plan, the reconciliation step is not optional and it should be written into the pre-service routine this week rather than remembered in a quiet moment.

Then look at the channel itself with the same scepticism. A third-party booking route that cannot tell the room when a table has been released is usually a route that reports very little back about anything else it is doing, a pattern set out in the Google booking link that never tells you if it worked. The two symptoms share one cause, and it belongs to the shape of the arrangement rather than to any provider: a channel that is not the restaurant's own book is one the room can publish into without reading back out of it.

None of this is a promise about how a restaurant appears in search results, and none of it is offered as one. What it settles is smaller and entirely inside the building: when a guest gives a table back, the room finds out in time to sell it again.