An AI voice agent for failed delivery rescheduling calls the recipient as soon as a delivery attempt fails, states the reason, confirms or corrects the address, offers real delivery windows, and writes the chosen slot back to the carrier system. Recovery rates are highest when that call happens within two hours.
Key Takeaways
- Recovery collapses on a clock. Two hours is the target, not same-day.
- A voice agent without live order data is a recorded message.
- Delivery calls carry recipient PII. Most platforms never say where it lives.
A failed delivery is a clock starting. Most operations answer it the next morning, and by then the parcel is already drifting toward return.
We build Dograh, an open-source voice agent platform, and delivery recovery is one of the workflows teams bring to us most often.
What the call actually has to do
The call that recovers a failed delivery is doing four jobs at once, and skipping any one of them turns it into a notification.
It has to state the failure reason in plain language, because "delivery unsuccessful" tells the recipient nothing they can act on. It has to confirm or correct the address on file, since a wrong flat number will fail again tomorrow exactly the way it failed today. It has to offer delivery windows that dispatch can actually honour. And it has to write the chosen window back into the carrier system while the recipient is still on the line.
That last job is where these calls quietly fail. A promise the agent makes and nobody records is worse than no call at all, because the recipient now expects a delivery that was never scheduled.
Gartner data cited in Locus research found that 96% of customers who go through a high-effort service experience become disloyal, against 9% after a low-effort one. A failed delivery is a high-effort moment by default, so the call either lowers that effort or confirms the customer's worst read of your operation. The opening seconds carry much of that weight, which is why how the first seconds of an outbound call decide the rest applies directly here.
The two-hour window is the whole game
Recovery falls off a cliff measured in hours rather than days.
Base.com's NDR recovery rates by response window, published in July 2026, puts numbers on it.
| Response window | How the recipient was reached | Failures recovered |
|---|---|---|
| Within 2 hours | Automated NDR workflow | 64% to 74% |
| Within 6 hours | Message plus phone call | 58% to 68% |
| Within 24 hours | Phone call | 42% to 52% |
| No proactive outreach | None | 28% to 36% |
Note what changes across those rows alongside the clock. The two-hour row is an automated workflow, while the six and twenty-four hour rows are people making calls. The distance between the top row and the bottom row is the whole case for automating this call.
Worth being straight about where this comes from. These are Base's own benchmark figures, published without an external citation behind them. Treat them as a directional signal rather than peer-reviewed research. The shape of the curve matches what anyone running a recovery desk already recognises.
The cost side is easier to pin down. Locus puts the direct cost of a failed first attempt at roughly $17, covering redelivery, wasted mileage and handling, attributing the figure to OrangeMantra.
Two hours is a dispatch constraint rather than a service aspiration. A human calling queue cannot hit it at volume, because failures arrive in a burst at the end of the delivery shift, which is exactly when the calling team is smallest.
Most delivery voice agents dial blind
These agents underperform for reasons that have little to do with how the voice sounds. A convincing voice reading stale data is still reading stale data.
If the agent opens the call working from a queue built at 6am, it does not know the attempt failed at 4pm, does not know the reason code, and cannot tell the recipient anything they did not already learn from the tracking page.
Pre-call fetch fixes that. It means the agent queries your own systems in the seconds before it speaks, keyed on the phone number in front of it. For this workflow, that means: order ID, failure reason code, address on file, and remaining capacity in the delivery window offered. An agent offering tomorrow morning without checking capacity is generating a second failure with a friendlier voice.
The write-back is the half that gets skipped. The agent needs a tool call that commits the chosen window to the carrier system during the conversation, then confirms it aloud from the system's response rather than from what it intended to do.
Lookups and writes both cost time, and time in a voice call is dead air. Anything past roughly 800ms end to end starts reading as a dropped connection to the person holding the phone, which is the same budget covered in our latency budget for natural conversation. The practical answer is fetching in parallel with the greeting rather than pausing after it, part of the broader mechanics covered in making AI outbound calls actually work.
Dograh handles the fetch step as a first-class part of the workflow, pulling fresh order or CRM data before the call connects, so the agent opens with the current state of the parcel instead of a snapshot from this morning.
Open Source Alternative to Vapi / Retell
Self-hosted voice agent platform — no per-minute fees
dograh-hq/dograh
Star on GitHub
Where the current delivery voice tools stop
The delivery voice category has the happy path well covered, call on failure, state the reason, offer a window, hand the exception to a human, and goes quiet where it matters for production. Operator guardrails around service areas, capacity, cutoff times and blackout dates are real and shipping today.
Evidence is where it thins out. Product pages and vendor documentation in this category carry almost no sourced numbers, and claims about handle time and deflection show up in comparison tables with nothing behind them. When a vendor tells you their agent resolves a call in under 60 seconds against 3 to 5 minutes for a human, ask where that came from before it enters your business case.
Integration specifics thin out the same way. Tools in this space will tell you that integration quality decides whether the deployment works, then decline to say what to integrate or how the write-back is committed. That is the hardest part of the build, described as a footnote. Where the call data physically lives gets the same treatment, which the section below covers on its own.
None of this sits on a cheap part of the business. Capgemini figures cited by Locus put last-mile at 41% to 53% of total logistics cost, so the gap sits on the most expensive stretch of the chain.
What NDR volume does to per-minute pricing
The pricing model that looks harmless in a pilot is the one that ends the rollout.
Per-minute pricing is normal in this category, and some vendors publish it openly at around Rs 5 per minute. Run that against real recovery volume rather than a pilot. Base.com's 2026 benchmarks put Indian RTO at 20% to 30% on prepaid orders and 30% to 40% on cash on delivery, climbing to 35% to 48% for fashion and footwear on COD. Recovery call volume scales with that rate, so the meter runs fastest exactly when the problem is worst.
The closed platform stack usually lands around 5 to 7 cents per minute for the platform layer alone, with speech recognition, the language model and speech synthesis billed on top, which in practice lands near 15 cents a minute all in. Self-hosting removes the platform fee entirely, and bringing your own keys or running open models pulls the AI usage down alongside it. On a workflow whose volume is defined by your own failure rate, that difference compounds in the wrong direction under a per-minute model. We worked through this arithmetic more generally in the real cost of automation versus traditional systems.
For scale, the last-mile delivery market grew from $184.2 billion in 2025 to $199.68 billion in 2026, an 8.4% compound annual growth rate. The recovery problem grows with it.
Join the Dograh Community
Dograh is an OSS alternative to Vapi. Join our Slack community for queries, releases, best practices & community interactions.
Where the customer data ends up
A delivery call is a personal data call, and the category is close to silent about it.
Consider what gets spoken aloud and recorded in ninety seconds. The recipient's full name. Their home address, often corrected mid-call, so both versions end up in the transcript. Their phone number. The order value, and sometimes whether payment is still outstanding. For cash on delivery that last detail tells anyone with access to the recording that there is cash at a named address at a known time.
Across the delivery voice tools currently on the market, hosting model, data residency and compliance posture went unmentioned in every one I reviewed for this piece.
If your recipients sit in a jurisdiction with data residency rules, or you ship cross-border, that silence becomes the whole procurement conversation. Self-hosting resolves it structurally, because call recordings and transcripts never leave infrastructure you control, and an open-source stack can be audited rather than taken on trust. That argument generalises well past logistics, which we made in full in why on-prem wins enterprise voice AI.
Rolling it out without breaking dispatch
Start narrower than feels worthwhile. One failure reason, in one city, on one shift.
"Recipient not available" is the right first choice, because the recovery path is simple and the write-back touches a single field. Address correction is the harder second phase, since it affects routing and can push a parcel to a different depot.
Set the guardrails before the first call goes out. Capacity limits per window, cutoff times, blackout dates and service area boundaries all belong to dispatch rather than to the agent, which should offer only what dispatch says is available. Decide the escalation rule early. Damaged goods, payment disputes and anything where the recipient sounds distressed should reach a person, because an agent improvising there creates a second and more expensive problem.
For measurement, recovery rate on calls placed inside two hours and first-attempt success on the rescheduled delivery are the obvious pair. Add write-back accuracy checked against the carrier system rather than against the transcript, which is the one that catches the failure mode where the call sounded perfect and nothing was committed.
You will see first-attempt failure rates of 8% to 20% quoted widely as a baseline. Locus, which publishes first-attempt delivery rate as a profitability metric, notes that these are vendor and aggregator estimates rather than researched benchmarks. Measure your own rate before and after, then use your number.
Glossary
- NDR (Non-Delivery Report)
- The record a carrier raises when a delivery attempt fails, carrying the reason code that determines whether the parcel can be recovered or heads back to origin.
- RTO (Return to Origin)
- A parcel sent back to the seller after failed attempts, absorbing forward shipping, reverse logistics and restocking with no revenue against it.
- Pre-call fetch
- Pulling live record state from your own systems in the moment before the agent speaks, so the call opens with current order data rather than whatever was true when the queue was built.
- First-attempt delivery rate
- The share of parcels delivered on the first try, the metric that moves last-mile cost more than route optimisation does.
Frequently Asked Questions
Failed deliveries are not going away, and the recovery window is not getting longer. Pick one failure reason, wire the agent to live order data, and measure whether the slot it promised actually landed in your system. That single check will tell you more than any vendor benchmark.
