The NDR management overview explains why failed attempts need a dedicated queue. This playbook starts one step later: a courier has reported a failed delivery, and someone must decide what to do before the next cutoff. The useful unit of work is a single parcel, with an owner, a deadline and proof that the courier accepted the next instruction.
At receipt: create one case and find the real deadline
Record the tracking ID, order ID, courier, attempt number, scan timestamp, raw reason code and delivery address. Keep the raw courier event even after mapping it to your own reason categories. Duplicate webhooks and late scans happen; they should update the same case, not create two customer messages.
The first timer is not an assumed 48 hours. Ask the carrier or account team for the actual re-attempt and RTO cutoffs for that service, location and attempt number. The “first 48 hours” is a working horizon for this review, not a universal courier promise. A second failed attempt may leave far less time.
If the tracking ID is missing, the order has already entered return processing, or the carrier gives conflicting statuses, send the case to a person. Do not tell a customer a re-attempt is possible until the carrier confirms that it is.
First hour: classify the failure before messaging
Different failure reasons need different requests. “Customer unavailable” calls for a reachable time and a checked phone number. “Address incomplete” needs a corrected landmark or pin, subject to the carrier’s address-change rules. “Customer refused” needs a careful human review of the reason; a generic re-attempt nudge can make a genuine cancellation worse. “Payment not ready” needs COD amount and payment options confirmed from the order, not guessed from the scan.
Treat reason codes as leads, not facts. A courier can select “customer unavailable” when the rider could not locate the building. Compare the scan with earlier attempts, the customer’s messages and any rider notes. When the account disagrees with the scan, attach both to the human handoff.
For each case, write the next action and latest safe action time. An owner should be able to answer: what is blocking delivery, who can fix it, and how will we know the fix reached the courier?
Before the cutoff: get a usable customer answer
Choose the contact channel based on consent, reachability and the time left. WhatsApp can suit a time-sensitive reply if the customer has opted in and the business has an approved template where required. A call may be better for a complex address or repeated failure. Email can preserve the record, but its response time must be measured before relying on it for an imminent cutoff.
Ask one action-sized question. For an unavailable customer: “The courier could not deliver order 123 today. Can you receive it tomorrow between the carrier’s available slots, or should we call you?” For an address issue, show the current address and ask only for the missing detail. Do not claim a slot is booked merely because the customer tapped one.
Set a reply deadline earlier than the carrier cutoff. If there is no reply, follow the brand’s consent and contact policy for a second channel, then route high-value or repeated-attempt cases to a named person. Log attempts so the customer does not receive contradictory nudges from support and logistics.
After the reply: close the loop with the carrier
A customer reply is an input, not a recovery. Validate the new phone, address or time against what the carrier accepts. Submit the instruction through the carrier API or operations portal, retain its acknowledgement and check the shipment’s next status. If the carrier rejects an address change or cannot offer the requested day, tell the customer and offer an available path. The case stays open until a re-attempt is confirmed or a human records why it cannot be arranged.
At the next scan, reconcile the result: delivered, another failed attempt, or RTO initiated. A second failure creates a new decision with less time and more context; it should not restart the same template sequence. Cases with repeated attempts, disputed scans or a customer complaint should move to the exception queue.
The case ledger and the daily scorecard
Keep one row per parcel with event time, reason, contact attempts, customer reply, carrier instruction, carrier acknowledgement, owner, cutoff and final outcome. That ledger lets the team find cases waiting on the customer, cases waiting on the carrier and cases whose clock has already expired.
Review four measures by courier and reason: time from failed scan to first action; share contacted before cutoff; share with a carrier-acknowledged re-attempt; and delivered share after NDR. Count RTO separately, because a sent message and even an accepted re-attempt do not guarantee delivery. Compare against a pre-change baseline and watch complaints or unwanted-message reports alongside recovery.
The practical target is simple: every recoverable failure gets the right question before its real cutoff, and every answer becomes a confirmed carrier instruction or a human-owned exception. The broader NDR article covers why the queue matters; this ledger is how to work it tomorrow morning.