On this page
When a delivery fails, the courier's status code rarely explains what actually happened. "Customer not available" might mean the customer was out, the courier never came, or the address was impossible to find. A short call can collect the real reason while it's still fresh, as long as the result reaches someone who can use it.
Call soon, and start with the facts
Trigger the call from your delivery exception event, within your calling hours. Pass in the AWB or order number, the item, the attempt count, the reason code and the next possible delivery date.
Open by saying who is calling and why. Then ask what happened, rather than reading the courier's reason as a fact. Customers are understandably annoyed when they're told they were unavailable when they were at home.
Collect what the next attempt needs
Keep to fields that will change the next attempt:
- Reason in the customer's words, plus a category for reporting
- Preferred day and time window
- Landmark or directions, which often matter more than a tidy address
- An alternate person who can receive the parcel, if the customer offers one
- Whether they still want the parcel
Read the important details back. Speech recognition can stumble on local place names and house numbers, so a person should be able to check the recording when something looks wrong.
Keep the risky changes away from the agent
A delivery call is an attractive target for fraud. Set hard limits in the prompt and in the tools themselves:
- Never ask for or read out an OTP. Fraudsters often use "delivery" as their pretext, so customers should hear that the agent won't ask for one.
- Don't change the address directly. Record the request as a note, and let your existing verification decide.
- Don't collect card or UPI details on this call.
- Don't promise a time unless your system has confirmed the slot. "I've passed on your preference" is honest. "It will arrive by 3pm" usually isn't.
Close the loop
The call has done nothing until the information reaches the courier or hub. Send the structured result by post-call webhook to the system that creates the next attempt, and have someone watch for requests that didn't arrive.
Live transfer to a person isn't available in zlicx yet. An upset customer should get a clear callback promise, handled as described in our handoff guide.
What to compare
Measure the outcome you care about: whether the second delivery attempt succeeded. Compare orders that got a call with similar orders that didn't, over the same period. Also track how many requests your team was able to act on. We haven't yet got customer results to publish for this flow, so treat a pilot as a real test.
The logistics page shows this workflow alongside others, pricing has the cost formula, and the delivery call test kit includes ready-made test cases. If you run a delivery operation, we'd like to hear how your exceptions work today.
Plan a delivery follow-up pilot.
Start with one hub or courier, and compare second-attempt results.

