Owner stays blocked from an email, and the cleaning cancelled five minutes later

A Gmail trigger polls every five minutes. An OpenAI chat model at temperature zero, in JSON mode, turns each email into an action (new, edit, cancel or notification) plus the listing, owner, dates, whether a post-stay clean is wanted and any notes. The prompt is defensive: anything without the intake fields, or carrying the footer of a notification, is classed as a notification; it must never default to new; two dates side by side mean old then new; and an unchanged date is copied into both.

The system's own confirmations arrive in the same mailbox, so two layers stop it acting on them: a subject filter that drops confirmation, reminder and cancellation wording, and the parser's notification class. Without both, a confirmation could be read as a new request.

There is no local ledger. For a new block the scenario reads the listing's calendar for the days strictly between check-in and check-out (so back-to-back stays are allowed) and creates the owner stay only if no day is unavailable. An edit looks up the reservation on the old dates; a cancel looks up the dates. A conflict goes to Slack, to the owner and to the admin team.

A small scheduled scenario requests an access token with the client-credentials grant every thirty days and overwrites a single record in a Make data store. The owner-block scenario reads that record on each run and passes the token on to the cleaning scenario, so nothing authenticates per run and parent and child always use the same token.

The property-management system creates the cleaning task asynchronously, so the cancel-cleaning scenario waits five minutes before it looks, and tries up to three times at five-minute intervals. It is called fire-and-forget, so a slow or failed attempt never delays the owner's confirmation.

Nearly every module has an error handler that writes a row to an error log (message, listing, owner, dates and execution id), posts a Slack alert and rolls back. Slack-only steps are set to ignore failures, so a failed notification does not stop the work.