How it works

How AI assistants choose a restaurant — and what that asks of yours.

People increasingly hand the finding, comparing and booking to an assistant. That changes what a restaurant needs to be: not louder, but confirmable.

How AI assistants choose

Six steps between “dinner for two near Allston” and a booked table. Restaurants fall out at four of them.

This is what an assistant actually does when someone hands it a dinner plan. We watched it happen.

  1. 01

    Intent

    “Friday 7:30, two people, one vegetarian, under $100, we’d like to book.”

    No drop here
  2. 02

    Discovery

    Searches the web, maps and directories for candidates near the address.

    Where restaurants get dropped

    No website on your Google listing? You’re found through third-party pages that may be years out of date.

  3. 03

    Reading

    Opens each site or listing and pulls out hours, menu, prices, and how to book.

    Where restaurants get dropped

    Menu as a photo. Hours in an image. Prices missing. There is nothing to read.

  4. 04

    Constraints

    Checks every fact against the request: time, budget, diet.

    Where restaurants get dropped

    “Vegetarian?” Dish names don’t answer that. “Under $100?” No prices. You get marked “cannot confirm”.

  5. 05

    Availability

    Looks for a way to check the table: a booking link, a stated policy, or a phone number.

    Where restaurants get dropped

    No booking link, no policy. The assistant cannot finish, so it recommends the place that let it.

  6. 06

    Action

    Books, or hands the person a summary and the phone number to call.

    No drop here
  7. Observed in September 2026 by giving a real agent a real dinner task in Allston. It could not finish for any of the three candidates it found — not because they were bad restaurants, but because nothing confirmed price, dietary suitability or a way to book.

Assistants go where the data already is

When we gave a real agent a dinner task, it did not look for anything exotic. It searched the web, opened restaurant websites and directories, and used Google Maps to check hours, addresses and booking links. If your Google listing has no website, it learns about you from whoever wrote about you last.

No special file makes assistants find you. Being present in the sources they already use — your Google Business Profile, a working website, the booking platforms you actually use — is the whole of “discoverability”.

Restaurants are dropped for missing facts, not missing style

Once an assistant has candidates, it checks each fact against the request: time, budget, diet, party size, whether it can book. Every gap becomes a “cannot confirm”. In our test, all three candidates fell at this step. None was a bad restaurant. None had confirmed prices, dietary facts or a stated way to book.

This is the step we build for. Not to be ranked higher, but to not be dropped.

Listed is not confirmed

Hours on Google, a directory and an ordering page can all be different, and an assistant has no way to know which is right. A restaurant that states its own facts, with a date, resolves the tie. We keep “what listings say” and “what the restaurant confirmed” as separate fields, and we never quietly promote one to the other.

One record, four outputs

We maintain a single record of your facts. From it we generate the homepage people read, a facts page with sources and dates, a JSON data file with the same content, and a plain-text version. Change one field and all four change. Assistants can re-check the data file cheaply using standard web version tags, and we tested that they do.

Action is the last mile

Reading is not booking. We link to whatever you already use — phone, Toast, OpenTable, Resy — and state your policy in words. As booking and payment protocols for assistants mature, a maintained record is what they will connect to. We will add integrations when they are real, and say so when they are not.

Check my listing — free