# Failed Delivery Recovery Page: https://alidemirbas.com.tr/en/lab/journeys/delivery-attempt-failure Delivery failed → classify reason → reschedule or alternative → complete or escalate ## Purpose Recover a failed delivery differently depending on whether the issue is the address, customer availability, operations or an impossible delivery. Goal: Recovery & Retry · Category: Transactions, Delivery & Support ## Steps - **Trigger**: Delivery attempt failed - **Decision**: Why did delivery fail? - Wrong / missing address: Email: Update the delivery address - Customer unavailable: Push: Choose a new delivery time - Courier / operational issue: Email: Apology + new delivery date - Delivery not possible: Offer an alternative pickup point or refund - **Action**: Email: Update the delivery address - **Action**: Push: Choose a new delivery time - **Action**: Email: Apology + new delivery date - **Action**: Offer an alternative pickup point or refund - **Wait**: Wait 1 day - **Decision**: Was delivery rescheduled? - Yes: Wait for the next delivery attempt (usually 1–3 days) - No: SMS / WhatsApp: Final reminder to reschedule or choose an alternative - **Action**: SMS / WhatsApp: Final reminder to reschedule or choose an alternative - **Wait**: Wait for the next delivery attempt (usually 1–3 days) - **Decision**: Was delivery completed successfully? - Yes: Delivery completed - No: Move to refund / support / alternative-delivery resolution - **Handoff**: Move to refund / support / alternative-delivery resolution - **Exit**: Delivery completed ## Guardrails - Do not keep retrying when delivery is impossible. - Stop once delivery succeeds. ## Core rule The recovery path should match the actual failure reason. ## When to set it up Failed delivery attempts piling up in carrier reports, second attempts failing for the same reason and the same address-update message going to everyone regardless of cause: that is when this journey pays off. The carrier's failure reason has to be recorded for each attempt, rescheduling and delivered events tracked, and email, push, SMS and WhatsApp consent held separately before you launch. If most failures come from wrong or missing addresses, fix the address fields at checkout first; a recovery message cannot do what the address form failed to do. ## How to set it up - **Trigger and entry**: Entry happens when the carrier reports a failed delivery attempt; only attempts with a known failure reason enter. Split the entering attempts at random into a journey group that gets the messages and a control group that gets none of them. - **Who must not enter**: A delivery that is merely expected to be late belongs to Delivery Delay Management; a delivered but faulty order belongs to Post-Purchase Issue Resolution. One failed attempt is the scope, and no second flow opens for the same attempt. - **Timing and channels**: One first message per reason: an address-update email, a push for an absent customer to pick a new time, an apology email with a new date, or an alternative pickup point or refund when delivery is not possible. Without rescheduling after one day, a final SMS or WhatsApp reminder goes out before the next attempt. - **Exit and handoff**: Once the next attempt succeeds, the journey ends and queued reminders are cancelled. If that attempt fails too, the delivery moves to refund, support or alternative-delivery resolution; the same attempt is never queued again. - **Frequency and consent**: Two messages per attempt is the ceiling: the reason-specific first message and the final reminder, each channel used only with its own consent. When delivery is not possible, the same attempt is not repeated; an alternative point or a refund is offered instead. Never word an operational failure as the customer's fault. ## How to measure success **Incremental successful redelivery rate vs control**: Clicking the rescheduling link or choosing a date is an intermediate step; success is the messaged group completing more deliveries on the next attempt than the control group. Among all failed attempts assigned at entry to the journey group and the control group, the share delivered successfully within the same follow-up window from assignment; read the gap by failure reason. Delivery or click status of the message does not change the denominator. Also track: - **Rescheduling rate**: Attempts rescheduled at the one-day check, as a share of all entries; the intermediate step before delivery, and what decides how many people get the final reminder. - **Result by failure reason**: Read the completion gap separately for the address, customer absent, operational and delivery-not-possible branches; one branch's success does not mean the others were recovered. - **Handoff to resolution**: Share of attempts whose next attempt also fails and moves to refund, support or alternative delivery; a rise may mean impossible deliveries are not being separated early enough. - **SMS and WhatsApp complaints**: Watch complaints and blocks on the final reminder channel, push opt-outs and email unsubscribes; if the final reminder draws complaints, change its channel or wording. ## What to watch when reading the result - Equal delivery counts in the journey group and the control group mean the carrier was retrying anyway and the message only produced clicks. A rescheduling click or a chosen date is not a win; decide on the delivery gap. - This result holds for this reason split, the one-day check and the final reminder channel. An attempt handed to refund, support or alternative delivery is credited to that resolution; a problem reported after delivery belongs to Post-Purchase Issue Resolution, not to this one. - Each reason branch is a small group on its own. Work out how many attempts each branch needs with the [sample size calculator](https://alidemirbas.com.tr/en/calculators/sample-size-calculator): enter the current redelivery rate and the smallest gap you want to see, and withhold judgment on any branch that has not reached that count. - The delivery-not-possible branch will show a low completion rate; read acceptance of an alternative point or a refund as its outcome instead of mixing it with the others. Repeating the same attempt does not improve this branch. ## Frequently Asked Questions ### Should every failed delivery request an address update? First identify the actual carrier-reported reason. Address errors, absence and operational failures need different remedies. Offer a valid alternative or return route when delivery is impossible. Do not shift responsibility for an operational problem onto the customer. ### Does clicking a rescheduling link count as delivery recovery? No. A click or selected date is intermediate. Success requires actual delivery. This example waits for the next attempt after checking rescheduling and routes another failure to returns, support or an alternative solution. ### What belongs in the final failed-delivery reminder? Show the actual remaining action, valid delivery record and available remedy. This example checks after one day and uses a final eligible reminder if rescheduling is missing. Suppress outdated messages after delivery or a record change.