# Delivery Delay Management Page: https://alidemirbas.com.tr/en/lab/journeys/fulfillment-delay Delay detected โ†’ update ETA โ†’ monitor โ†’ recovery options or exit ## Purpose Tell the customer about a delivery delay before they have to discover it themselves, and escalate only if the revised date is missed too. Goal: Scheduling & Commitment ยท Category: Transactions, Delivery & Support ## Steps - **Trigger**: Delivery is expected to be late - **Decision**: Is a new estimated delivery date known? - Yes: Push: Delivery is delayed; share the new estimated date - No: Email: Delivery is delayed; say clearly that the new date is not known yet - **Action**: Push: Delivery is delayed; share the new estimated date - **Action**: Email: Delivery is delayed; say clearly that the new date is not known yet - **Wait**: Wait 1 day - **Decision**: Delivered? - Yes: Delivery completed - No: Was the revised delivery date also missed? - **Decision**: Was the revised delivery date also missed? - No: Push: Share the current delivery status - Yes: WhatsApp / Email: Apologize and offer a new date, delivery-point change or support - **Action**: Push: Share the current delivery status - **Action**: WhatsApp / Email: Apologize and offer a new date, delivery-point change or support - **Decision**: Did the customer choose an alternative? - Yes: Which alternative was chosen? - No: Continue delivery tracking - **Decision**: Which alternative was chosen? - New date: Move to delivery rescheduling - Delivery point: Move to address / delivery-point update - Support: Move to support - **Handoff**: Move to delivery rescheduling - **Handoff**: Move to address / delivery-point update - **Handoff**: Move to support - **Handoff**: Continue delivery tracking - **Exit**: Delivery completed ## Guardrails - Do not invent a new ETA when none is known. - Stop once the delivery is completed. ## Core rule A delay message should say what is known now and update when the estimate changes. ## When to set it up Carrier tracking that shows deliveries slipping past their promised date, while customers open support tickets asking where their order is before you have said a word, is the cue for this journey. Before launch, confirm that the delay signal is reliable, that each delivery carries a current estimated date and a delivered event, and that push permission, email subscription and WhatsApp consent are known separately. If deliveries run late because the promised date was never realistic, fix the date shown at checkout first; a notice cannot make a wrong promise right. ## How to set it up - **Trigger and entry**: Carrier or operations data predicting that a delivery will be late starts the journey. At entry, randomly split deliveries into the journey group and a control group that gets no messages from this flow; keep the control group small, since this is a service notice. - **Who must not enter**: A completed delivery does not enter; the delay is reported only while the delivery is still on its way, and orders without trackable status and estimated date stay out. The scope is one delivery: no second delay flow opens for it, and the open flow is updated when the estimate changes. - **Timing and channels**: With a new estimated date known, the first notice is a push with that date; without one, an email says plainly none is known yet and invents no date. A day later the delivery is checked: a push shares the status while the revised date holds; once missed, WhatsApp or email apologizes and offers options. - **Exit and handoff**: Delivery completion ends the journey, and any queued delay message is cancelled. A customer who picks a new date is handed to delivery rescheduling, a new delivery point to address / delivery-point update, and support to the support journey; with no choice, or while the revised date holds, delivery tracking continues. - **Frequency and consent**: At most two messages per delivery: the first notice and, one day later, either the status update or the apology. Push, email and WhatsApp are used only where that channel's consent exists, and the alternatives offered are only those you can really provide. ## How to measure success **Delayed delivery completion rate vs control**: The journey earns its place if informed deliveries get completed more often than the uninformed control group; a message reaching the customer is an information signal, not the outcome. Every delayed delivery assigned at entry to the journey group or the control group is the denominator; the numerator is those delivered within the same follow-up window from assignment, with rescheduled orders followed against their current date. Whether the notice was delivered or opened leaves the denominator unchanged. Also track: - **Delay-related support contacts**: Among assigned deliveries, the share whose customer contacts support about the delay; if the journey group sits below control, the notice saved the customer from having to ask. - **Alternative chosen**: After the apology message, count new date, delivery point and support choices separately; it shows which handoff route is carrying the load. - **Revised date missed**: Deliveries that have also missed the revised date at the one-day check, as a share of all entries; when it climbs, the problem is the estimate, not the notice. - **Opt-outs and complaints**: Count each channel's own reaction: push opt-outs, email unsubscribes and WhatsApp complaints. If the delay notice itself draws complaints, revisit its tone and channel. ## What to watch when reading the result - If informed deliveries are not completed more often than those in the control group, the message informed people without changing the outcome; then decide on the drop in support contacts. A delivered or opened message does not justify the journey on its own. - Read the gap as belonging to this channel order, the one-day wait and a first message that depends on whether the estimate is known. A delivery handed to rescheduling, delivery-point update or support is credited to that journey; never count one delivery in two flows. - Small gaps need a test before a decision: give the [A/B test significance calculator](https://alidemirbas.com.tr/en/calculators/ab-test) each group's delayed deliveries and completed deliveries, and if it reports no significant difference, let rescheduled orders reach their current dates and recalculate at the end of the follow-up window. - When the estimate changes, the message must change with it. Do not trust a gain from a variant that gives a date while none is known, or that presents a predicted risk as a confirmed delay; read it next to the rise in complaints. ## Frequently Asked Questions ### Should a delivery delay be communicated before a new date is known? A reliable signal of likely delay can justify early communication. If a revised date is unknown, say so. Label any estimate clearly and provide tracking or support. Do not present a predicted risk as an established delay or a guaranteed delivery date. ### What should happen if the revised delivery date is missed too? Reassess the current state and offer real options. This flow can route to rescheduling, delivery-location changes or support. Record the user's choice and hand over rather than repeating the old estimate. ### Which outcomes should delivery-delay management track? Track completed deliveries, selected alternatives and support needs separately. Follow rescheduled orders against their current dates. Treat message delivery as an information-reach signal. Cancel remaining delay messages once the order is delivered.