In July we ran an experiment that started with a simple question and ended with a number I did not expect.
The question: when someone tells their AI assistant to find a nice place and book a table, can the assistant actually do it?
Not find the restaurant. Finding works. Ask any assistant for a quiet seafood place near the canals and you will get sensible answers. The interesting part is what happens after, at the moment the conversation has to turn into a reservation.
So we measured it. 200 Amsterdam restaurants, drawn at random with a fixed seed from 1,631 operational venues, so nothing was hand-picked. Every venue got the same checks, in the same conditions, on the same day. We walked the path a guest walks: find the place, understand what it offers, check whether it fits, find availability, book, get a confirmation. First the way a person does it, then the way an agent does. We never submitted a reservation. We stopped, on purpose, at the point where only the guest's own name and phone number remained.
What we found
Being online is not the same as being bookable. That is the whole study in one sentence. Here is how it breaks down.
163 of the 200 had a working website. Amsterdam does not have a web-presence problem. These are polished places with strong branding and deep review profiles.
41 percent showed a booking path a machine could see at all. The rest ran on contact forms, phone numbers, Instagram messages, or booking links buried where nothing could find them. For a person that is friction: you squint, you scroll, you try the other menu item, you find it. For an agent it simply ends the task.
The median score across the sample was 52 out of 100. The information usually existed. The structure did not. Hours in one place, a different set in another. The menu in a PDF from last spring. When the facts disagree, recommending a different restaurant is the safer answer, and assistants are built to prefer safe answers.
Many venues pay for a booking product, and it did not save them. The button is visible to a person, while the availability, the fields and the confirmation live inside an iframe or a script. Paying for booking software does not make a restaurant bookable by software.
16 of 200 could be taken to the final booking step by an agent driving a real browser. Eight percent.
And then the number that reframed the whole project for me. Across all 163 working sites, we checked whether any restaurant publishes a booking interface an assistant could call directly, without pretending to be a person with a mouse. Not one did. Nine sites served a machine-readable file, and all nine had been generated automatically by an SEO plugin. They described the restaurant. None of them contained a way to book it.
A booking button is not a booking interface
Most restaurant websites were built on a visual assumption. A person sees a button, recognises a calendar, understands the widget, knows what to do next. All of that understanding happens in the person, not on the page.
Software has none of it. An assistant needs the steps to exist as actual steps: check availability, choose a slot, pass the guest details, create the booking, get back a confirmation it can read. Where those steps exist, an agent books a table in seconds. Where they live inside a closed widget, the agent stalls, apologises, and recommends somewhere else.
One moment from building the test harness stayed with me. We watched ChatGPT read a page that describes a booking API in plain HTML. It understood the API. It listed the required fields. Then it reported, politely, that its web tool cannot issue a POST request. Assistants act through tools, not pages. Most of our dataset is that sentence, measured two hundred times.
The loss is invisible
Here is the uncomfortable part for the restaurants. You will never get a report about the booking you lost.
When an assistant fails to book, there is no error message for the business, no failed payment, no abandoned checkout. The assistant offers a different restaurant and the conversation moves on. From inside the business everything looks fine, because people can still click. A second channel is quietly being tested against you, and it does not file complaints.
Amsterdam is the warning, not the exception
This is one of the most digitally mature restaurant markets in Europe. Strong concepts, established booking platforms, deep review profiles. If the gap is structural here, it is structural everywhere.
And the direction of travel is not subtle. 45 percent of consumers used AI to find a local business this year, up from 6 percent a year earlier, according to BrightLocal's 2026 survey. Discovery has already moved. Action follows discovery. It always has.
What ready would look like
Four things, and none of them is a redesign. A clear public identity: one consistent set of name, hours, menu and policy, not four versions across four places. A website a machine can read, where the facts are stated rather than implied by a photograph of a chalkboard. A direct reservation path that does not live entirely inside a closed visual widget. And a confirmation that says plainly that the booking exists.
We published the method, the sample rules and the aggregate data, with no email wall. Any restaurant in the sample can request its own result, and we answer every request. Including the ones that tell us we got their row wrong. Especially those, because a study you cannot argue with is a study you should not trust.
Measuring the gap eventually forced us to build the missing piece ourselves. That is a story for another essay. This one is about the measurement, because the measurement is the part nobody had done.
The study: https://g-lab.studio/research/amsterdam-restaurants-2026
Top comments (0)