Restaurant Booking

Restaurant Booking

Get the right table and confirm what was actually booked.

Before booking

• Start on OpenTable unless the user names another provider, or their known preferred or signed-in provider offers this restaurant. If the first provider can't book it, try the remaining options in order: OpenTable, Resy, then another booking provider verified through the restaurant's official site. Use the restaurant's direct flow only if no aggregator can book. Provider accounts are more likely to have the user's booking details and payment method already on file.

• Check the venue and branch, local date and time range, party size, booking name, and seating or dietary needs. Look for an existing confirmation or later change before making a new reservation. Use $orbit:restaurant-recommendations if the restaurant still needs choosing.

• Check what the booking has to fit: a show, commute, meeting, celebration, or another person's stated constraint. Use relevant past feedback about indoor or outdoor seating, noise, or accessibility without assuming it applies to everyone. If a missing fact changes the booking, first check existing notes or likely sources; ask only for what you still cannot establish.

• If a booking provider such as Resy needs a number for texts, check relevant notes, past booking emails, or a profile before asking. Keep looking if the first source shows only part of the number; don't assume a work number is right for a personal booking. Finding a number does not authorize sharing it. Follow <confirmation_policy> for the specific number and provider before entering it. If it's likely to be the right one, ask, "Can I send your number ending in 0192 to hold the spot?" Ask for the full number only if you cannot find it.

• Check live availability with the booking provider. If a read-only reservation-search tool is actually available, it can help find times; it cannot authenticate, pay, or book. Complete the reservation in the browser at the provider's exact restaurant, date, time, and party-size checkout, not the restaurant homepage. An open restaurant is not the same as an available table.

• If the requested slot is full, check nearby times within the agreed range, the restaurant's published table-release time, and whether it offers a waitlist. Only join the waitlist when authorized. Say a monitor is set only after a supported tool confirms it.

• If no requested slot is available, say what you checked and offer a verified alternative. Offer to watch for cancellations; set up a monitor only if the user agrees or already asked you to keep checking. Set a cutoff for when the reservation would no longer be useful.

  • Ex: "There's nothing for two Saturday between 6 and 8. Want me to watch for cancellations? Rintaro has 6:30 Friday if you're flexible."
  • If the user already said, "Keep checking and let me know if a table opens," set up the monitor without asking again and confirm when it will stop.

• Read the terms for the specific table: deposits, prepaid menus, minimum spend, cancellation or no-show fees, and any time limit. Surface charges or restrictions the request doesn't cover before submitting.

Handle the reservation

• Follow <confirmation_policy> when booking, changing, or cancelling. Keep the venue and time within the user's permission. If emailing the restaurant is the next step, use $orbit:email for the first outbound email and follow <confirmation_policy> before sending; a request to book does not by itself authorize a fallback email. Join a waitlist only when authorized, and report it as a waitlist until a table is confirmed.
• Prefer an existing signed-in provider session and a card visibly saved there when the user's authorization covers its use. If sign-in is needed, request secure sign-in at the provider early, explain what the user needs to do, and resume promptly afterward. Don't send the user to the restaurant homepage or ask for fresh card details when the provider's saved card can complete the booking. Don't promise the session will stay signed in for future bookings.
• Carry approval through the same booking or renewed temporary hold when the terms haven't materially changed; don't ask again just because sign-in or an expired hold interrupted it. Surface a newly introduced or materially changed payment, deposit, no-show fee, or cancellation term and follow <confirmation_policy>. If anything blocks you, tell the user rather than silently stopping.
• For changes, check the replacement and the cancellation terms before giving up the original table. If submission gives an unclear result, check the reservation or confirmation before retrying.
• Share dietary or accessibility requirements accurately and only as authorized. An identifiable person's allergy or health information requires authorization for that specific information and destination under <confirmation_policy>; ask a general question without naming the person when that is enough. A booking note does not prove the kitchen can avoid cross-contact. If no usable provider-stored card is available, use the Wallet skill when supported and authorized; calendar changes and messages to companions follow <confirmation_policy> too.
• Return the restaurant and address, local time, party size, confirmation, and any fee, cancellation deadline, or request still unconfirmed.
• For an important meal, include arrival instructions or the deadline that would cost the user money, if relevant. If an authorized cancellation or change has a fee, verify the provider's actual outcome and expected refund instead of assuming it went through.