Availability Search Abandonment

Availability searches that end without a booking make this journey worth building when the funnel report shows them as a visible share of searches and some of the requested slots are still open hours later. Store each search with its requested time and make bookings land on the same user identity before launch. The live state of the slot and nearby alternatives must be queryable at send time, and push, email and SMS consent held separately. If people leave because the slots shown in results turn out to be taken, fix the availability data first; a reminder cannot reopen a full slot.

Incremental booking rate vs control

Value here means how many more confirmed bookings the messaged group produces than the control group; opening a message, viewing a slot or joining the waitlist is not a booking.

How it is counted: Among all searches assigned at entry to either group, the share that end in a completed booking within the same follow-up window; the difference between the two shares is what the journey added. Delivered, opened or clicked status leaves the denominator as it is.

Also track

• Slot view rateSearches where the user reopens the requested slot or an alternative after the message, as a share of all assigned searches; the intermediate step before booking, not an outcome.
• Waitlist joinsReport users who join the waitlist separately from confirmed bookings; never add the two into one recovery number.
• Result by branchRead the booking gap separately for the still-open, alternative and waitlist branches; each carries a different channel and a different offer.
• Opt-outs and complaintsCount push opt-outs, email unsubscribes and SMS complaints for each channel on its own; when they rise, check first whether a message went out for a slot that was already taken.

• Trigger and entryA search that ends without a booking opens the journey; the scope is that one search and its requested time. At entry, hold out a random share of eligible users as a control group that receives no message from this flow; the rest form the journey group.
• Who must not enterUsers who booked since the search do not enter, and one search never holds two flows. Someone waiting for a product to return to stock belongs to Back-in-Stock Alert, not here; that wait is on the item, this one on the time the person asked for.
• Timing and channelsOne to two hours after the search, the flow checks booking status and the requested slot. A still-open slot gets a push; a taken slot with a close alternative gets an email with two or three nearby times; no alternative but a joinable waitlist gets an SMS. Never present a taken slot as available.
• Exit and handoffThe journey ends once a booking is made, with no handoff. After the push it waits up to one day or until the slot is taken, after the email or SMS one day. No booking, alternative, joinable waitlist or SMS consent closes it at No further messages; joining the list ends at On the waitlist.
• Frequency and consentEach search gets a single message, push, email or SMS depending on the branch, never all three in a row. SMS goes only with consent and only for a waitlist that really works; push and email also need that channel's permission. Do not imply a guaranteed place in the waitlist message.

1. 1If the booking rate among messaged searches is no higher than in the control group, the push or email only reached people who were coming back anyway; opens, slot views or waitlist sign-ups do not close that gap. Keep or drop the journey on the difference in confirmed bookings.
2. 2This reading applies to the one-to-two-hour first wait, these three branches and the single message each branch sends. If the same user is also in Back-in-Stock Alert waiting for a product, a purchase from that alert belongs to that journey, not to this search; keep the two outcomes apart.
3. 3Small gaps call for the A/B test significance calculator: enter each group's searches and bookings, and if the p-value does not fall below the significance threshold, extend the follow-up and let more searches accumulate. Few searches reach the waitlist branch, so collect enough entries before reading that branch on its own.