Reservation Payment Reminder

Reservations created with payment pending that then expire and release their held place in the reservation system are the signal for this journey, especially when they are a noticeable share of all pending reservations. Check first that the reservation number, amount, date, real payment deadline and hold window can be read at trigger time and that payment completion is written to the same reservation. Hold email, push, SMS and WhatsApp consent separately. If payments stay incomplete because attempts fail, the problem is in the payment step, not in the reminders; fix that first.

Incremental payment completion vs control

Reminders earn their place only if more reservations are paid before their deadline in the reminded group than in the control group; an opened or clicked message proves nothing by itself.

How it is counted: Among all valid reservations assigned at entry to either group, the share whose payment is verified by the payment deadline, which is the same follow-up window for both groups; read the journey's effect as the difference between the two groups. Delivery or click status does not change the denominator.

Also track

• Released hold rateCount how many reservations expire at the deadline and have their place released; this is the loss the journey is meant to reduce, so compare that share with the control group.
• Payment per touchTrack payments arriving after the email, after the push or SMS and after the WhatsApp message separately; if the last touch adds no payments, revisit the WhatsApp step.
• State mix at the deadlineReport paid, expired or cancelled, and still held as separate states; count an extended reservation neither as a payment nor as a loss.
• Complaints and opt-outsWatch SMS and WhatsApp complaints, push opt-outs and email unsubscribes per channel; if they climb, review the urgency wording and the number of touches.

• Trigger and entryA reservation created with payment still pending enters; the flow first reads the reservation number, product or service, date, amount, payment deadline and hold window from the record. Randomize valid, unpaid reservations at entry: a journey group that gets the reminders and a control group that gets none.
• Who must not enterAlready paid or no longer valid reservations leave at the first check; the scope is one reservation, and no second flow opens for it. A user whose payment attempt actually failed belongs to Payment Failure Recovery, not here.
• Timing and channelsValid unpaid reservations get an email at once; if payment is missing 12 to 24 hours later, a push goes where push is permitted and reachable, otherwise an SMS. Shortly before the deadline, still-unpaid users with WhatsApp consent get a WhatsApp message. Fit every wait inside the real deadline.
• Exit and handoffPayment completion stops the journey: queued reminders are cancelled and a confirmation email goes out. At the deadline, an expired or cancelled reservation is released and announced by email; a genuinely extended one closes without a message. There is no handoff; already-paid and invalid reservations end in their own exits.
• Frequency and consentAt most three reminders per reservation: the email, a push or SMS, and WhatsApp; the confirmation and release emails are one-time notices on top. SMS and WhatsApp are used only with that channel's consent. No message may use a deadline the system does not hold or manufacture urgency.

1. 1If completion in the journey group only matches the control group, the reminders merely brought forward payments that were coming anyway; a gap in opens or clicks does not compensate. Do not scale the journey while the released hold rate stays where it was.
2. 2This channel order, the 12 to 24 hour first wait and the deadline-bound second wait are what the result describes. A reservation whose payment attempt actually failed is credited to Payment Failure Recovery; never count one payment in both journeys. Appointment Reminder chases service prerequisites and solves a different problem; keep its report separate.
3. 3Before you judge a thin gap, run the current completion rate and the smallest difference worth acting on through the sample size calculator; it returns the reservations needed per arm, and dividing that by the reservations entering each arm per day tells you how many days to wait before deciding.
4. 4When the deadline is extended in the system, update the pending message to the new date and take that reservation out of the expired count; an expiry notice sent against an old deadline is both a false message and a wrong data point.