Originally published as a Fonix.AI practical guide by AntEngage. This republication uses the same guide content.
An NDR event needs a current next step
NDR calling automation helps a fulfilment team respond to a non-delivery report: contact the customer, understand the obstacle and submit an eligible instruction to the courier. The useful result is a verified delivery action attached to the correct shipment. A customer saying “try tomorrow” is a preference until the carrier accepts the request.
This workflow starts after dispatch and a failed delivery event. It differs from COD confirmation, which concerns an order before dispatch, and cart recovery, which concerns an unfinished checkout.
Fonix.AI supports business voice conversations in Indian languages. Evaluate the call together with your order, shipment and courier systems. The event feed, address-change permissions and reattempt actions must be confirmed for the actual carrier integration.
Resolve the latest shipment event
Keep the shipment reference, order reference, courier, failure reason, event time and event identifier. A single order may contain several parcels, so an order number alone is not enough to choose the affected delivery.
Read the latest carrier state before calling. The parcel may already be delivered, out for another attempt, cancelled or returning to origin. A delayed or duplicated webhook should not reopen a closed recovery case.
Treat carrier reason codes as reports to clarify rather than unquestionable descriptions of the customer's behaviour. “Customer unavailable” could reflect an actual absence, a missed telephone call or an address-access problem. The conversation should preserve both the reported reason and the customer's explanation.
Choose the event or recovery-case reference used to prevent duplicate processing. Store its current owner and whether a courier action is already pending. Calling from two teams about the same parcel can result in conflicting instructions.
Figure 01. Resolve the authoritative shipment state using its own reference.
Match the obstacle to an allowed action
Ask what prevented delivery and determine whether the courier can accept a useful next instruction. Use the carrier's actual rules for timing, address changes and remaining attempts.
| Customer's response | Check | Record |
|---|---|---|
| I will be available tomorrow | Reattempt timing and carrier acceptance | Requested date and accepted result |
| The building entrance is elsewhere | Allowed delivery instruction field | Exact landmark or access correction |
| The address itself is wrong | Address-change permission and review process | Proposed change and reviewing owner |
| I received the parcel already | Latest delivered event or discrepancy process | Customer report and carrier evidence |
| I no longer want it | Cancellation/return policy for this shipment stage | Intent and actual system decision |
| I cannot discuss it now | Contact preference and remaining action window | One requested callback time |
Do not promise an exact delivery slot unless the carrier supplies and confirms it. “Tomorrow was requested” and “tomorrow was accepted by the courier” should be separate states in both the conversation and the record.
When a customer changes the destination, read back the requested information and use the authorised process. A conversational correction does not automatically make a new address valid for the shipment.
Verify the courier update before closing the case
A carrier action usually has at least three useful states: requested, accepted and completed. Preserve each rather than converting every successful API response into “delivery resolved”.
If the update times out, look up its result using the available action reference before retrying. The carrier may have accepted the instruction even though your application did not receive the response. Duplicate requests can overwrite an earlier instruction or reopen work.
When no automated action is available, assign the case to a fulfilment owner with the conversation context. Give the customer an accurate next step, such as “our delivery team will review the address correction”. Do not announce a reattempt booking that exists only as a staff task.
Reconcile the final carrier event later. Delivered, returning and unresolved are distinct end states. Keep the customer explanation so the team can find recurring problems with a postcode, delivery route or reason code.
Figure 02. Keep rejected or unknown courier updates visible with an owner.
A worked failed-delivery call
This fictional example assumes the carrier allows an additional attempt but does not provide a guaranteed time window.
Assistant: Hello, this is the automated delivery assistant for Birch Store. We received a failed-delivery report for your parcel. Is this a suitable time to clarify the delivery instruction?
Customer: I was there. Driver called the old number. Kal delivery chahiye, but after lunch.
Assistant: I have noted that you were available and that the contact number needs review. I can request another attempt; the courier has not guaranteed an afternoon slot. May our delivery team verify the number change?
The record preserves a disputed failure reason, a requested day, an unconfirmed time preference and an authorised review task for the number. It does not claim that an afternoon delivery is booked.
Suggested fields include shipment reference, latest carrier event, reported failure code, customer explanation, requested instruction, action reference, carrier acceptance, owner and final delivery state. These describe a workflow model rather than a published Fonix API.
Review the exceptions before scaling
| Situation | Required behaviour |
|---|---|
| Stale NDR arrives after delivery | Suppress the call and close the stale task |
| Order has multiple shipments | Identify the affected parcel explicitly |
| Courier rejects a reattempt | Preserve the rejection reason and assign review |
| Address correction crosses a service area | Use the carrier's approval path |
| Customer disputes the failure code | Store both accounts and investigate the operational issue |
| Update result is unknown | Reconcile before retrying or announcing success |
Test event duplication and event ordering. A delivery update followed by an older NDR should not move the parcel backwards. Where the carrier does not supply a reliable ordering field, define how your system establishes the current authoritative state.
Measure delivered shipments and preventable returns
Track eligible NDR cases, useful contacts, accepted courier actions, completed reattempts, delivered parcels and return-to-origin outcomes for the same shipment cohort. Separate unreachable customers from rejected carrier requests and incorrect addresses.
Measure time from the failure event to a useful instruction, then from carrier acceptance to delivery. Fast calls alone do not prove recovery. A comparison with similar usual-process shipments or a controlled pilot helps distinguish calling effects from changes in courier service.
Include additional fulfilment, reattempt and support costs. Review returns and cancellations alongside delivered orders so a workflow does not optimise for activity while increasing operational expense.
Bring a real carrier event to the demo
Bring an NDR payload with personal information removed, your accepted carrier actions, state-reconciliation rules and fulfilment ownership process. Ask to see a stale delivered shipment, a rejected instruction and an uncertain update result.
Request a failed-delivery workflow review to test the call and resulting carrier record. Use the calling-software guide for broader integration and retry evaluation.
Top comments (0)