Accommodation Booking

---
name: accommodation-booking
description: >-
  When the user asks you to find, compare, book, or change a vacation rental,
  hotel room, or other place to stay for a trip, or asks what a listing costs
  for their dates, before you open Airbnb, Expedia, or any other lodging site.
---
# Accommodation booking

You find, compare, and book places to stay, then handle guest details and check-in information. Grok Bot has no listings index of its own. Every price, rating, and availability comes from a connector, a lodging site in your browser, or a web search, and you say which one you used.

## Entry points

- "Find us somewhere to stay in Lisbon the first week of June" gives a destination and rough dates; resolve the rest.
- "Two bedrooms in Joshua Tree, Friday to Sunday, under $400 a night" is a fixed search with a budget.
- "Is this place free the 12th to the 15th?" with a pasted listing link is an availability check that may become a booking. Open that exact URL.
- A forwarded confirmation email is a stay to look up, change, or get the check-in details for, not a new search.

## Before you start

- Pin down the destination or neighborhood, check-in and check-out dates, the guest count with children's ages, the budget as a total or per night, and every hard constraint (entire place or a room, pets, accessibility, parking, kitchen, cancellation flexibility). Infer harmless defaults such as two adults and say what you assumed. Ask only when the answer changes which listings qualify.
- Resolve relative dates against the time zone in your prompt's Time section. Say the weekday and the date together ("Friday, June 5 to Sunday, June 7") before you type a date into any site.
- Read the Memory section for the home city, the usual traveler count, loyalty programs, and past stays. Call RecallMemory for older trips or preferences that are not listed.
- Run SearchPlugins for a travel or lodging connector and for the site the user names. Use a connector when one is installed. Install a missing connector with InstallPlugin without asking; its connect card is the ask. Ask in one widget first only when the user named no service and several plugins fit (Gmail or Outlook, Google or Outlook Calendar), or the plugin has no connector. Say in the user's words why it helps, without saying plugin, MCP, or plugin id, and never paste a connect link. Do not assert that any lodging site has a connector before the search says so.

## Flow

1. If a lodging connector exists, search through it with the resolved destination, dates, guests, and price cap, and refine there. Skip to step 4.
2. Otherwise dispatch a `computerUse` subagent to Airbnb for rentals, Expedia for hotels, or the property's own site, with the tightest URL you can build (destination, check-in, check-out, guests, and the price cap in the query string). Tell it what to read back: listing title, neighborhood, entire place or room, beds and baths, rating and review count, the price for the stay and whether it includes fees, the cancellation policy, and the listing URL. The lookup is read-only.
3. Refine with the site's filters instead of asking the user again. "Closer to the beach", "needs a real kitchen", "free cancellation only", and "anything cheaper" are filter changes. Re-dispatch with the new URL or the filter to click.
4. Open the top candidates and read the total for the exact dates and guests, with cleaning and service fees and taxes, plus the cancellation policy, minimum stay, check-in window, and house rules. A search card shows a nightly or before-tax figure; the listing page shows the total.
5. Never report that nothing is available from one empty result. Widen the area or the dates by one step and say what you changed before you say so.
6. Present the options (see Presenting choices) and stop for an explicit pick.
7. Book on the site where you found the listing unless the user prefers another. If it hands payment to the property's own site, say so first, because that page is a new sign-in.
8. Enter guest details. Names, email, and phone come from memory when you have them. Anything else comes through `RequestUserForm` with fields targeted at the live page. A message to the host, an ID verification, or a selfie check is the user's; hand it over with `request_box_help` and one instruction.
9. When the site wants a sign-in, a one-time code, or a verify-you-are-human check, follow the Cursor-managed `sign-in` skill in its order, which ends with the Secure Form (`RequestUserForm`) and then handing over the screen with `request_box_help` and one instruction ("Sign in to your <service> account"). Never send a question widget before these; the tool is the ask. After a receipt or a hand-back, dispatch the subagent again; the session persists across turns. Travel insurance, damage protection, and paid extras are the user's choices; surface them, do not buy them.
10. Run the savings check (see Savings check). Then confirm the stay and the total with a question widget and pay (see Paying and confirming).
11. Report the confirmation code, the listing, the dates with their weekdays, the guests, the cancellation deadline, and the total from the confirmation page. Save a stated preference (a favorite neighborhood, a loyalty number) with `UpdateMemory` only when the user confirmed it.

## Presenting choices

- Show three to five options that differ on something the user cares about. For each: name or listing title, neighborhood, entire place or room, beds and baths, rating with review count, the total for the stay with cleaning and service fees included, and the cancellation policy.
- Take a Screenshot of the results or the map when location matters and attach the saved path. Name the tradeoff plainly ("$120 more for the whole stay to be walkable to the venue").
- When the user gave exact criteria and one listing clearly wins, you may pick it, but still show the listing, the terms, and the total and get a yes before booking.
- Use a question widget for the pick only when the shortlist is real and short. Otherwise send the summary and let the user reply.
- Show what you collected in the user's language, which is the language they write to you in unless they asked for another or the Memory section names one they prefer. When a page is in another language, translate the words you put in a card or a summary, such as titles, descriptions, specs and their labels, notes, review summaries, policies, delivery and status lines, and option names. Keep brand, store, seller, and venue names, model numbers, order numbers and other codes, prices with their currency, and links as the page shows them. Brief the browser subagent and type into the site in the site's own words, and match a choice the user makes in their language back to those words.

## Savings check

Run this once, on the final review page's total with shipping, tax, and fees, before you ask for the approval; a total from an earlier page can still be missing some of them. When the checkout takes codes only on an earlier page, gather them as Codes and offers below says before you leave that page and enter them there; the rest of the check still runs on the final page. It is one short pass, not a new search.

- Codes and offers. Apply the offers the checkout itself shows, such as a coupon to clip, an automatic cart promotion, or a member price for a membership in the Memory section. When an email connector is installed, search the user's mail for this store's promo codes, such as a welcome, newsletter, or loyalty offer, and keep only codes that have not expired. When the checkout has a promo code field and neither a tool result nor the mail gave a code, ask whether the user has one. Enter only a code the user, a tool result, or the user's mail gave, once each; never guess codes or take them from a list of codes on another site, since stores treat that as abuse. When the store rejects a code, or the total does not drop after it, carry on at the total the page shows with any code that did apply. Tell the user in one message every code you found, where each came from (the email's sender and subject, the tool result, or the user), and which one applied. Cash-back portals and rebate sites are not part of this check; leave them out.
- The merchant's own site. When you are buying through a marketplace seller, a travel site, or another reseller and the total is above 100 USD, or that amount converted to the checkout's currency at today's rate, or above an amount the user set for this check, read the same item, dates, and terms on the merchant's own site (the brand's store, the airline, the hotel). Tell the user both totals. When the merchant's is lower and the user wants it, start the purchase over on the merchant's site from the cart or booking step, so the cart summary, the review, and the approval all come from that site; never carry lines or a total from one site to the other. Keep the reseller when the user chose it for a reason, such as a perk or their account there. When `CheckSubscriptionUsage` reports that most of this cycle's included usage is used and does not say that on-demand usage is enabled, skip this part and say so in one line.
- The card. When you will pay with a card from the user's vault (see Paying and confirming), the user has not already chosen the card, as a message naming it by Vault id does, and `Vault` list shows more than one saved card, pick the one whose `When to use:` line fits this store or this kind of purchase, and give the reason in that line's words. Name only perks a `When to use:` line states, never a reward rate or protection you assume a card has. Without such a line, pick as you otherwise would and give no reason. When the user tells you a card's perk, such as extra points on groceries or a travel credit, offer to add it to that card's hint with `Vault`, and change the hint only when they say yes.
- Then say in one line what the check saved and how ("Saved $6.00 with CAMP6 from the store's welcome email", "Saved €297 by booking direct"), or that the codes you tried did not apply. Say nothing about savings when there was nothing to try.
- After the order is placed, record each saving, since the user paid the lower price: kind promo_code for a code or checkout offer, or direct_booking for buying on the merchant's own site instead of a reseller, with the reseller's total, including any code that applied there, less the merchant's total before any code you entered on the merchant's site, since that code is its own promo_code saving, dated the order date, with the order's https link as proof. Save one fact of type "journal" with UpdateMemory for each saving, in exactly this shape: `Saving YYYYMM: YYYY-MM-DD | kind | amount CURRENCY | store | proof link`. YYYYMM is the year and month of that date with no separator. amount CURRENCY is how much less the user paid, with its ISO 4217 code, such as 6.00 USD. Never start any other fact with Saving and a month. Save nothing when nothing was saved.

## Paying and confirming

- Before booking, send one question widget that restates the listing, the check-in and check-out dates with their weekdays, the guest count, the cancellation terms, and the total from the checkout page. A dismissed widget is a no.
- Never book, request to book, or pay without that yes. A request to book commits the user too; the host can accept it and charge the card.
- When the site wants payment, a deposit, or a card to hold the booking, work it in this order and stop at the first step that pays. First, a payment method already saved on the site's own account, not a card in the user's vault. Have the subagent select it, and when that account has several, ask which one in the confirmation widget. Next, when the account has none and the `purchases` skill lists a card saved in the user's vault, use that card as its Credit cards section says. When that skill has you send an `order` card, read every line, the total, and the ship-to address from the checkout's review page before you send it, and charge only after the user taps Pay. When neither has one and the site charges an exact total now (tax, fees, tip, and shipping included), Stripe Link is the preferred way to pay: with `RequestVirtualCard` among your tools this turn, raise a one-time card with the site as merchant and type it only into the merchant's checkout; a denial is final. Without that tool, offer Stripe Link once as the `purchases` skill says, when that skill is listed. A card kept on file for a hold or a no-show fee is not charged now, so it never gets a one-time card. Next, and right away whenever the user turns Link down, ignores the offer, or asks to use their own card, send the Secure Form (`RequestUserForm`, reason "checkout", the site's domain) for the card inputs the live checkout shows, such as card number, expiry, CVC, name, and billing ZIP; never tell them you can't take their card, and never predict that the form can't reach card inputs embedded from a payment provider. Last, when the host refuses the form or its receipt says a card field failed, or the user would rather type on the page, hand the box to the user with `request_box_help` and one instruction ("Add your card and confirm the payment on <service>"); the same handoff covers a CVC re-entry and any 2FA, 3DS, or bank prompt. The user finishes the payment inside that handoff, so when the box comes back, skip any later confirm or place-order click and read the confirmation page. When the user already typed their card into chat, use it as given for that checkout instead of sending the form. Card numbers, CVCs, and expiries stay in the merchant's checkout, never in chat or logs.
- Once the payment method is selected or entered, and unless the user already finished the payment in a handoff, the final click is yours. Give the subagent what the widget the user approved named (the itinerary or stay, the travelers, and the total), have it re-read the review or checkout page, and when nothing material changed, have it click the site's confirm, pay, book, or request-to-book control once and read the confirmation page. A material change is a total more than 1% or 5 units of its currency above the approved one, whichever is larger; a different currency; for a flight, different flights, dates, times, cabin or fare class, or passenger names or count; and for a stay, a different hotel or listing, room type, number of nights, or guest count. On a material change, click nothing: show the user what changed and send a fresh question widget, whose yes is the only one that books. Nothing else stops the click. A lower total, the same total with its fees and taxes labeled or split differently, a different layout, reworded or reordered fields, and banners all go ahead, and the subagent turns down seat, upgrade, insurance, and other offers the user did not choose, then continues. In the confirmation message, give the total the confirmation page says was charged, and say so when it differs from the approved one.

## Pitfalls

- The price on a search card is not the checkout total. Depending on the site and region it is nightly, leaves out taxes, or leaves out cleaning and service fees. The checkout page shows the number the card is charged.
- Instant Book confirms at once. Request to Book sends a request the host can decline or leave for a day. Say which one a listing uses, and never call a request a confirmation.
- Strict cancellation windows and non-refundable rates change the decision. Read the policy on the listing page and put the deadline in the widget and in the confirmation message.
- Minimum stays and blocked dates make a card look available and the checkout page fail. Read the total for the exact dates before you present it.
- Check-in windows, late-arrival fees, and self check-in codes that arrive on the day of the stay belong in the confirmation message. If the code has not arrived, say when the site says it will.
- A listing's map pin is approximate until the booking is confirmed. Do not promise a block or a street from the pin.
- Never invent availability, a rating, a total, or a confirmation code. If the page did not show it, say so.

## Site playbooks

Before you dispatch the browser subagent, Read the `site-playbooks-airbnb` or `site-playbooks-expedia` skill in this catalog, whichever names the site you are about to use, and paste the Dispatch snippet of the job that matches your step (a read-only lookup, or a cart and checkout) into the Task text. It carries the deep link or endpoint that lands on results instead of clicking through the home page, and the stop rules for that site.