Skip to content

OTA Inquiry Availability Responder

Example prompt: "When a Booking.com, Airbnb, or Vrbo inquiry forwards into our property inbox, pull out the requested dates and party size, check our 'Bookings' Google Sheet for availability, and draft a reply — available, partial fit, full, or 'please clarify dates' — for the host to sign off and paste back into the OTA's UI."

The Problem

Booking.com, Airbnb, and Vrbo all measure response time and rank listings by it. The inquiry arrives at the property inbox at 9pm on a Saturday, the host is plating dinner, and by morning the guest has booked somewhere else and the ranking has slipped a notch. Even when the host gets to the message, the answer requires opening the bookings spreadsheet on a phone, working out whether the room they asked for is free, and writing a sensible reply that does not promise something the calendar cannot deliver. The reply often gets shorter than it should because the host is on the back foot.

How GloriaMundo Solves It

We treat the forwarded OTA notification as the trigger and do the parsing, the availability check, and the drafting before the host opens the inbox. An LLM step pulls the dates, the party size, and the guest's question out of the platform's email. A code step compares those dates against confirmed and pending rows in the bookings sheet and the room capacities. A conditional branches into four tiers — available match, partial availability, no availability, dates unclear — and a second LLM step writes the reply for that tier in our voice, with the right rate and deposit policy from the settings tab. The draft sits in Gmail for the host to read; the host pastes it into the OTA platform's own messaging UI because that is where the response-time clock is measured. Glass Box preview shows the parsed request, the availability table, and the draft before any of it goes near the platform.

Example Workflow Steps

  1. Trigger (event): A Gmail message from a known OTA sender (Booking.com, Airbnb, Vrbo) with an inquiry-style subject.
  2. Step 1 (llm): Extract requested dates, party size, room preference, guest first name, platform, and the free-text question.
  3. Step 2 (integration): Read the 'Bookings' tab and the 'Rooms' tab; find rooms with capacity ≥ party size and no overlapping confirmed or pending bookings.
  4. Step 3 (conditional + llm): Classify the outcome into available_match, partial_availability, no_availability, or dates_unclear; draft a reply in the tier's voice with the right rate and deposit policy.
  5. Step 4 (integration): Save the reply as a Gmail draft for the host to copy into the OTA platform's messaging UI.
  6. Step 5 (integration): Append a row to 'OTA Inquiries' with the platform, the dates, the tier, the rooms offered, and the draft link.
  7. Step 6 (integration): Post a one-line summary in #front-desk on Slack so the host can act inside the response-time window.

Integrations Used

  • Gmail — the inbox trigger on OTA notifications and the draft store for the host's reply
  • Google Sheets — the bookings sheet, the rooms sheet, the settings sheet, and the OTA inquiries log
  • Slack — the #front-desk one-liner so the host sees the inquiry without opening the inbox

Who This Is For

Owner-operators and small hotel reception teams listed on one or more OTAs where response time is part of the ranking algorithm. The workflow keeps the response-time stat green without forcing the host to drop what they are doing every time a notification lands.

Time & Cost Saved

A careful manual response is ten to fifteen minutes — open the inbox, read the message, check the calendar on a small screen, write the reply, paste it into the platform. Across a B&B with twenty inquiries a week, that is three to four hours. The workflow does not save the platform-side paste step (the host still needs to do that to keep the response-time stat where it belongs), but it removes the parsing, the calendar check, and the drafting from the host's plate, which is most of the cost. The bigger saving is the inquiries that currently get a too-brief reply because the host was in service — the draft is in our voice, with the right rate and deposit terms, and the host can read it once and send it rather than write it from scratch.