Two inboxes, two jobs: a failed-payment alert and a branded owner email

The failed-payment alert extracts the platform, guest and property from the platform's fixed subject template with a single regular expression, and ignores thread replies with a filter on two modules so a conversation under the alert cannot raise a second one. The Slack message then carries what the guest-support team needs: who, where, which platform, when it was detected, and a checklist (contact the guest, give a 24-hour deadline, check the card or bank flags, retry).

Rather than a database, the thread itself records the outcome: staff reply RESOLVED, ESCALATE or PENDING. The source email is then labelled processed, which is also the scenario's memory of what it has already handled.

The owner-email scenario polls every fifteen minutes and excludes anything already labelled sent or skipped, so labels are its only state: no data store, and a notice that matches no property is labelled skipped and drops out of the queue instead of being retried forever.

The notice's HTML is parsed for the property, service date and service type, and the property is found in Airtable by street number and street name, tolerant of unit text. The owners linked to it are fetched, their first names are built into a greeting, and the regional support alias is copied in. The vendor's timestamp is parsed in the vendor's time zone and the owner's copy rendered in the owners' time zone, both set explicitly, so the date on the email is the date of the visit.

Every photo URL in the notice is extracted with a global regular expression, downloaded, and aggregated into both attachments and inline images in a table-based HTML layout, so the owner sees the photos whether or not their mail client loads remote images.