# Reservation Payment Reminder Page: https://alidemirbas.com.tr/en/lab/journeys/reservation-payment-reminder Reservation created → payment pending → reminders → confirm or release ## Purpose Protect a reservation while payment is pending, with reminders tied to the actual hold and payment deadline. Goal: Scheduling & Commitment · Category: Conversion & Purchase ## Steps - **Trigger**: Reservation created; payment is still pending - **Action**: Collect the reservation number, product or service, date, amount, payment deadline and hold window - **Decision**: What is the reservation state? - Already paid: Reservation already paid - No longer valid: Reservation is no longer valid - Valid and unpaid: Email: Payment is waiting for your reservation - **Action**: Email: Payment is waiting for your reservation - **Wait**: Wait 12–24 hours - **Decision**: Payment completed? - Yes: Email: Payment received; reservation confirmed - No: Is push permitted and reachable? - **Decision**: Is push permitted and reachable? - Yes: Push: Pay to keep your reservation - No: SMS: Pay to keep your reservation - **Action**: Push: Pay to keep your reservation - **Action**: SMS: Pay to keep your reservation - **Wait**: Wait until shortly before the payment deadline - **Decision**: Payment completed? - Yes: Email: Payment received; reservation confirmed - No: Is WhatsApp permitted? - **Decision**: Is WhatsApp permitted? - Yes: WhatsApp: Your reservation is about to expire - No: Wait until the payment deadline - **Action**: WhatsApp: Your reservation is about to expire - **Wait**: Wait until the payment deadline - **Decision**: What is the reservation state at the deadline? - Paid: Email: Payment received; reservation confirmed - Expired or cancelled: Email: The reservation period has ended and the hold was released - Still held: Deadline extended; follow the updated terms - **Action**: Email: Payment received; reservation confirmed - **Action**: Email: The reservation period has ended and the hold was released - **Exit**: Reservation already paid - **Exit**: Reservation is no longer valid - **Exit**: Reservation confirmed - **Exit**: Hold released - **Exit**: Deadline extended; follow the updated terms ## Guardrails - Stop when payment is completed. - Release the reservation when the real payment window expires. ## Core rule Reservation payment reminders should count down to the real deadline, not manufacture urgency. ## When to set it up 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. ## How to set it up - **Trigger and entry**: A 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 enter**: Already 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 channels**: Valid 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 handoff**: Payment 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 consent**: At 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. ## How to measure success **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. 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 rate**: Count 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 touch**: Track 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 deadline**: Report 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-outs**: Watch SMS and WhatsApp complaints, push opt-outs and email unsubscribes per channel; if they climb, review the urgency wording and the number of touches. ## What to watch when reading the result - If 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. - This 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. - Before you judge a thin gap, run the current completion rate and the smallest difference worth acting on through the [sample size calculator](https://alidemirbas.com.tr/en/calculators/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. - When 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. ## Frequently Asked Questions ### Which deadline should a pending-reservation reminder use? Use the reservation system's actual payment deadline and hold period. Read the identifier, amount, date and status from the same record. Update pending messages if the deadline changes rather than inventing urgency. ### Should I wait 12–24 hours when the reservation expires sooner? No. The example delay cannot be used if it exceeds the real deadline. Check validity at every wait and send. Tie timing to the actual payment window and do not ask users to preserve an already expired reservation. ### Which states must be distinguished at the payment deadline? Separate paid, expired and genuinely extended reservations. Confirm only verified payments. Announce release only when the held place is actually released. Do not send an expiry notice based on an outdated deadline.