Google's End-to-End Booking Button Won't Take a System That Can't See a Month Ahead

Owners who notice the gap almost always reach for the wrong explanation. They hunt for a setting inside the business profile, or conclude the restaurant is too small, too new, or in the wrong town. The real reason sits further upstream, written into a document a restaurant owner has no obvious reason to open. Google does not award the booking button to a restaurant directly; it awards it through the booking system standing behind the restaurant, and that system has to clear a published, numeric bar before any of the restaurants sitting on it can carry a button at all. A diary on the pass clears none of it, and neither does a voicemail box, an email enquiry form, or a booking widget that only ever opens a fortnight of dates. The room can be full every Saturday and the website can be immaculate, and the button will still not be there.

The cost of not knowing this is quiet, and it recurs every service. The restaurant keeps paying for the demand, in food, in staff, in years of word of mouth that put the name in somebody's head, then hands the last three seconds of the journey to a phone call that may not be answered. A guest looking at two restaurants on a Friday afternoon, one with a button and one without, is not weighing the cooking at that moment; they are weighing effort. Worse, the owner spends money in the wrong place while it happens, redesigning pages or buying visibility, when what is blocking the button is a property of the booking machinery and cannot be fixed anywhere else.

The relevant document is Google's Reservations End-to-End integration policies page, part of the Actions Center developer documentation, last updated on 28 May 2026 according to its own footer. It is addressed to partners, the booking platforms that connect restaurants into the programme, and it opens by saying plainly that these are eligibility criteria to read before an integration begins, and that clearing them still guarantees nothing.

Two items on the General Platform Requirements list decide almost every restaurant case. The first is about speed:

The second is about depth:

The page's own auto-generated summary compresses the whole thing into a single sentence, worth reading because it is the shortest honest statement of what a restaurant needs behind it:

Those three are what the page's own summary pulls to the front. The General Platform Requirements list runs longer, covering online cancellation, booking authorisation and automatic real-time confirmation among other items, and every item on it is written as a must.

People often misread the real-time requirement as a service-level promise: answer the phone quickly, reply to enquiries the same day. It is nothing of the sort. It is a technical latency figure. Google asks a system what tables are free, and the system has under a second to answer. No human process can sit inside that window, so the availability has to exist as live data in a system that can be queried, not as a state of knowledge held by whoever is on the floor.

There is a second reason the latency line matters more than it looks. That single line rules out a whole category of booking arrangements that feel perfectly modern from the inside. A paper diary is out, obviously. So is a spreadsheet that a manager updates between services, because nothing external can read it. So is an enquiry form that emails the restaurant and waits for a reply, because the availability at the moment of asking is unknown until somebody looks. The policy does make room for confirmation by the restaurant after the fact, and it is specific about the condition: the reservation flow must still be based on an available time slot, and the partner must still hold real-time availability even though the merchant confirms afterwards.

A system that can answer in under a second holds a single authoritative version of the book, because anything else would have to reconcile two versions before replying. That is the same property that decides whether a table held for a walk-in is visible to the website, and whether two guests can be given the same 8pm table by two different routes. The policy asks for it to protect the guest at the end of the button, but a restaurant gets the benefit of it in the dining room whether or not the button ever appears.

For an owner, the practical test is blunt: if a person has to look at something before the answer to "is 7.30 on Thursday free for four" is known, the system is not real-time in the sense this policy means, however fast that person is.

The inventory requirement is the one that catches restaurants who already run an online booking page and assume they are fine. Thirty days or more of availability is not a total; it is a depth. On any given day, a guest, and Google, has to be able to see roughly a month forward.

Booking tools that open a short window are common, and there are sensible-sounding operational reasons for them. A restaurant that changes its menu monthly, or that does not want to be committed to Christmas in October, sets the calendar to open two or three weeks ahead and closes the rest. That setting is invisible on the restaurant's own website, where the guest simply sees the dates that are open and picks one. Measured against this policy, a three-week calendar is exactly the partial inventory the page says may leave a merchant ineligible, and the page is equally clear that clearing the bar guarantees nothing.

The depth requirement also quietly settles a question owners argue about internally: how far ahead to take bookings for large parties, private hire and holidays. A calendar closed at three weeks is a decision about workload, a legitimate one, but not a free one. It removes the restaurant from a route that only exists for systems showing a month. An owner who wants both usually needs the depth to be real and the control to sit elsewhere, in service rules, minimum party sizes, deposits, or an enquiry workflow above a certain number of covers, rather than in a calendar that simply stops.

"Comprehensive" carries its own weight in the same clause. The wording is that merchants with partial or distressed inventory may not be eligible; a system exposing only its quiet Tuesdays, or only the tables nobody else wanted, is not describing the restaurant. The requirement is the real book, at the real depth, answered live.

The last thing the page does with its requirements is attach consequences to them, and the phrasing is worth quoting because it changes what kind of thing eligibility is:

That is written at three levels: the whole integration, an individual merchant, or particular services. A restaurant whose availability thins out, a calendar left closed after a refurbishment, a system that stops answering, a book kept only a fortnight deep through a quiet January, is a merchant-level risk on a platform that is otherwise in good standing. The button appearing once is not a permanent state of affairs; it is the current reading of a live condition.

Most published guidance about getting a booking button onto a Google profile is about the connection: which link goes where, which account owns it, which provider is selected. All of that is real work and it matters, but it is also the second job. The eligibility question, does the system behind this restaurant hold live availability, a month deep, for the real book, is settled before any of it, and no amount of careful setup substitutes for it.

The distinction has practical consequences downstream, too. How a booking link was added determines what a restaurant can later learn about it, which is the subject of the Google booking link that never reports back. And the same shape of question, is the system behind the profile registered for the feature at all, governs whether a guest who finds the restaurant full can join a waitlist from the profile rather than simply leaving.

The principle underneath all three requirements is the same, and it is worth stating independently of any product, because it is the thing an owner is really choosing between. Either the restaurant's true capacity, its tables, its covers, its service times, a month forward, exists as live data the restaurant controls, or it exists as knowledge in a person's head and marks in a book. Only the first can be asked a question by anything other than a human being. Every downstream capability, from a booking button on a search result to a reminder the night before, is a consequence of that one decision, which is why it is worth making deliberately rather than inheriting it from whatever the restaurant happened to start with.

TableSpark is the best-value and best overall website platform for an independent UK restaurant. The Growth plan, at £39 a month excluding VAT, carries the machinery this policy is asking about: live availability and table inventory described on the pricing page as "real tables, real capacity", floor plans and table assignment, deposits and reminders, and on-site reservations at 0% TableSpark commission, with Stripe's standard card-processing fees applying to online payments. Growth also includes a Reserve with Google booking-link connection, which publishes the restaurant's configured supported-provider booking destination. Whether a given booking system has been admitted to Google's Reservations End-to-End programme is Google's decision, recorded on Google's own partner surfaces, and no such promise is made here.

What an owner can act on today is narrower and more useful than a certification question. Open the booking calendar on the restaurant's own site and try to book a table five weeks out. If the dates are not there, the depth requirement is unmet regardless of anything else. Then ask whether the availability shown to a guest is generated from the actual table inventory or from a fixed number of slots per sitting typed in once and rarely revisited, because comprehensive inventory means the real book, and a slot count that no longer matches the floor is exactly the partial inventory the policy warns about.

The policy page quoted here is Google's own and was read in full, but it is addressed to booking platforms rather than to restaurants, and it is the only source behind the numeric requirements in this article. Whether the sub-one-second measurement is taken against a partner's live booking-server response specifically, or against some cached or batched availability lookup, is stated once on that page and was not cross-checked against the separate technical reference pages for those methods; that distinction was not located in this research.

Nor was any measured figure found for how many UK restaurants currently sit below the thirty-day line, or a current directory of which booking systems have already qualified. Those were not fetched in this research and no number should be inferred from the absence. The eligibility mechanics themselves, quoted above, are the verified part.

One more boundary is worth drawing clearly. The requirements on this page govern the Reservations End-to-End integration, the in-line booking button, and not every way a restaurant can appear bookable on Google. A restaurant below the bar is not thereby invisible; it is outside one specific route, which is precisely the route that converts at the moment of intent.

That is the decision this policy actually puts to an independent restaurant: not whether to apply for something, but whether the system holding Thursday's tables can answer for them.