Skip to content

Last-Minute Cancellation Rebooking Runner

Example prompt: "When I change a booking row in our Google Sheet from 'Confirmed' to 'Cancelled' and the arrival is within 7 days, pull the top three candidates from our waitlist and recent enquiries who'd fit the room and dates. Draft a personal Gmail to each with a staggered hold time (2 hours, 1 hour, 30 minutes) and post the ranking in #front-desk on Slack before any offer goes out."

The Problem

A cancellation that lands ten days out costs us a few hours of admin. A cancellation that lands two days out costs us the room. We have a waitlist and we have a stack of recent enquiries, but on a Friday evening when the cancellation email comes in, nobody is going to read through forty entries to find the family who wrote on Tuesday asking about the exact weekend that has just opened. So the room sits empty, and the guest who would have happily taken it never hears from us. The other risk is the opposite — sending the same offer to three people at once, or letting the second offer go out before the first one is properly closed, and finding ourselves overbooked by morning.

How GloriaMundo Solves It

We build a workflow that watches the bookings sheet for any row flipping to 'Cancelled' inside seven days of arrival. The waitlist and the recent enquiries are read in, ranked by date match, then party-size fit, then date of enquiry. An LLM step drafts a short, personal Gmail to the top three candidates with a candidate-specific hold-until ladder — two hours, one hour, thirty minutes — written into each draft. All three start as Gmail drafts; nothing is sent until the host has sense-checked the ranking in Slack and approved the first send. Once the host sends candidate #1, the workflow runs two distinct branches in parallel: a fully-automatic timer-expiry branch that, the moment a live row's hold expires, marks it 'Expired' and releases the next queued draft to send without waiting for any reply; and a passive late-reply branch that, if a reply ever arrives on a row already marked 'Expired', drafts a truthful response chosen from the current run state — room taken, offer pending, or room still open — without advancing the ladder or treating the reply as an acceptance. Every attempt is logged. Glass Box preview shows the host the ranking, the three drafts, and the hold ladder before any email goes out.

Example Workflow Steps

  1. Trigger (integration): A row in the 'Bookings' tab changes from 'Confirmed' to 'Cancelled' with arrival_date inside the next seven days.
  2. Step 1 (integration): Read the 'Waitlist' tab for guests on the list for any date that overlaps.
  3. Step 2 (integration): Read the 'Recent Enquiries' tab for anyone who wrote in the last fourteen days asking about overlapping dates.
  4. Step 3 (code): Rank candidates by closeness of date match, then by party-size fit for the room that has opened, then by date of enquiry, and take the top three.
  5. Step 4 (llm): Draft a short, personal Gmail for each candidate referencing what they originally asked about, with a fair price, a single confirm link, and a candidate-specific hold-until written into the body (two hours for #1, one hour for #2, thirty minutes for #3).
  6. Step 5 (integration): Save all three as Gmail drafts addressed to the candidate — nothing is sent at this point.
  7. Step 6 (integration): Append a row to a 'Rebooking Attempts' tab for every draft (cancelled booking, candidate, sequence number, date drafted, hold-until, status — 'Drafted' for all three at this stage).
  8. Step 7 (integration): Post the initial Slack message in #front-desk with the cancelled booking, the three candidates in order, the hold-until ladder, and links to all three drafts so the host can sense-check the ranking before any offer goes out. No timer runs and no inbox-watching happens until the next step.
  9. Step 8 (integration + conditional): When the host approves and the system actually sends candidate #1's email, mark its row 'Sent', start its two-hour hold timer, and begin watching the inbox for a confirming reply addressed to that candidate.
  10. Step 9 (conditional): If a candidate confirms within their live hold, mark their row 'Accepted', mark every other row in the run 'Cancelled', and post a follow-up Slack message in #front-desk naming the accepted candidate and confirming no further offers will be sent.
  11. Step 10 (conditional, on timer expiry — automatic): The moment the live row's hold timer expires without confirmation, mark that row 'Expired' and immediately release the next queued draft to send, mark its row 'Sent', and start its hold timer (one hour for #2, thirty minutes for #3). This branch runs on timer expiry alone — it does not wait for any reply. Repeat for #3 if #2's hold also expires. If all three holds expire, post a Slack message in #front-desk that the run has closed with no rebooking.
  12. Step 11 (conditional, on late reply — passive): If a reply ever arrives on a row already marked 'Expired', do not release, send, or accept anything. Check the run state in 'Rebooking Attempts' and draft the truthful Gmail for the host to send: 'sorry, the room has now been taken' if any row is 'Accepted'; 'your window has passed and we are considering another offer for those dates — we will let you know if it falls through' if a later row is currently 'Sent' with a live hold; 'your window has passed but the room is currently still open — let us know quickly if you would still like it' if all rows are 'Expired' or 'Cancelled' with no acceptance.

Integrations Used

  • Google Sheets — the bookings register, the waitlist, the recent enquiries, and the log of rebooking attempts (the run state in 'Rebooking Attempts' is also what the workflow consults when picking the truthful reply to a late response on an expired offer)
  • Gmail — drafts the personal rebooking offer to each candidate; later drafts the appropriate reply to any late response on an expired offer (room-taken, offer-pending, or room-still-open depending on the run state)
  • Slack — the #front-desk channel receives two messages: an initial pre-send ranking and hold-ladder message for the host to sense-check before any offer goes out, and a follow-up outcome message when the run closes (rebooked with the accepted candidate, or all offers expired)

Who This Is For

Small hotel, B&B, and short-let operators with a real waitlist or a steady trickle of enquiries, who know they lose revenue every time a cancellation lands on a Friday evening, and who would rather see three named candidates and three drafted emails than have to remember who wrote in last week.

Time & Cost Saved

A single late cancellation in the high season costs more than the platform does in a year. The workflow turns a Friday-evening scramble into a five-minute review of three drafts that are already in the right tone. Across a season, the saving is two ways at once — the room that gets rebooked instead of going empty, and the host who is not at the desk at seven on a Friday trying to remember who said they would take any weekend that came up.