End-to-end booking lifecycle

This is the chronological timeline of every guest-facing and internal event for a typical Direct booking made 30 days before arrival, with the guest opting in for both early check-in and late check-out add-ons.

Phase order

The workflow runs all phases sequentially. Each step.sleepUntil(t) waits until the target time before continuing. Workflows survive worker restarts and can sleep for days.

Order	Fires at	Phase	Action
1	Workflow spawn	cohost-notify	Email TP front desk on new TP booking
2	Workflow spawn	channel-specific-setup	Airbnb confirm + Booking.com PAID flag
3	Workflow spawn	cleaning-heads-up	Email/SMS cleaner
4	A −14d 15:00Z	pre-arrival-T14	Welcome email + 3 forms + yellow BA flag
5	A −3d 15:00Z	pre-arrival-T3	Pre-checkin reminder + pink “late” flag (if not done)
6	A −2d 15:00Z	early-checkin-availability	Bill capture/decline email
7	A −1d 06:00Z	arrival-flag	Set booking flag pink + statusCode 11
8	A −1d 15:00Z	pre-arrival-T1	Final pre-check-in reminder (if not done)
9	A +0 14:00Z	arrival-day-bill-email	Tell Bill who’s arriving today
10	A +0 14:00Z	pre-arrival-T0	Lock-box codes / arrival instructions
11	A +0 21:00Z	still-dirty-check	Alert Bill if cleaning not complete by 3pm
12	A +1d 15:00Z	arrival-plus-1-chase	Email guest if check-in form still unsubmitted
13	D −3d 15:00Z	late-checkout-availability	Time-picker link to guest
14	D −2d 16:00Z	cleaning-T2-reminder	Cleaner T-2 reminder
15	D −1d 14:00Z	checkout-eve	”Checkout tomorrow” message to guest
16	D −1d 16:00Z	cleaning-time-commit	Ask cleaner for time-commit
17	D +0 14:00Z	departure-day-bill-email	Tell Bill who’s checking out today
18	D +0 (eve)	departure-flag	Set booking flag cyan

Interleaving matters

The four pre-arrival phases (T-14 / T-3 / T-1 / T-0) used to be wrapped in ONE bundled call that ran through all of them with internal sleeps. That forced phases listed after the bundle (M4c at A-2, arrival-flag at A-1, M4d at D-3) to fall through immediately whenever their sleep target was already past — so they fired at the wrong time. The May 2026 refactor unbundled them and reordered the run() body strictly by fire-at time. See src/workflows/booking-flag.ts run() for the current layout.

A = arrival date, D = departure date. UTC times. 15:00Z = 9am MT, 14:00Z = 8am MT, 21:00Z = 3pm MT, 16:00Z = 10am MT.

What runs when

• Workflow spawn (immediate): cohost-notify, channel-specific setup, cleaning heads-up.
• Pre-arrival window: T-14 / T-3 / T-1 / T-0 messages staggered to match the guest’s planning window. (T-5 was retired May 2026; its visual-flag role folded into T-14 and T-3.)
• Arrival day: Bill morning email at 8am MT, lock-box codes go to guest at 8am MT, still-dirty alert at 3pm MT if cleaning incomplete.
• Stay window: T+1 check-in form chase, then quiet until departure-eve.
• Departure window: T-3 late-checkout picker (if opted in), T-2 cleaner reminder, T-1 checkout-eve message, T-1 cleaner time commit.
• Departure day: Bill morning email + departure flag set in evening.

Last-minute bookings

When a booking is created within 14 days of arrival, all pre-arrival phases whose fireAt is in the past would otherwise blast immediately. A 24-hour gate prevents that: any pre-arrival message phase reads pre_checkin_submissions.last_pre_arrival_msg_at; if it’s <24h old, the phase no-ops. The next phase still runs at its scheduled time.

Same-day booking gets exactly one welcome message; the T-3/T-1 reminders skip. T-0 morning-of-arrival still fires because it bypasses the gate (critical send).

Phase idempotency

Workflows can re-spawn (via ensureBookingFlagWorkflow) on every Beds24 modify webhook. Phases must therefore be idempotent:

• Per-recipient state in D1 (e.g., cleanings.heads_up_sent_at, pre_checkin_submissions.last_pre_arrival_msg_at)
• Beds24 infoItems (e.g., COHOST_NOTIFIED=Y, OTA_CONFIRMED=Y, CANCEL_CLEAN_SENT=Y)

See Booking-flag workflow for the implementation pattern.