AI Voice Agents for Delivery Coordination: Confirm Before Dispatch

AI voice agents for delivery coordination place an outbound call after an order is routed and before the van leaves. The agent verifies the customer, confirms the delivery window from live slots, checks the address, captures access details, and writes the confirmed slot back to the transportation management system. The call needs consent captured at order.

Key Takeaways

• Call only when the delivery needs an answer. A plain confirmation is a text.
• Verify the customer before the agent reads any address or window.
• The TMS stays the system of record. The call writes the slot back.

This post is part of our guide to AI voice agents for logistics and delivery. The guide covers this call in its section on customer calls before the delivery, where the agent reads the order from the TMS, confirms the window and access details, and writes the slot back. Here is the full flow. In Dograh, an open-source, self-hostable voice agent platform, the call is a short flow that reads the order from your TMS and writes the confirmed slot back by webhook.

Why a call before dispatch pays for itself

Most failed first attempts trace back to something the customer could have told you before the van left. A 2025 survey of 8,000 consumers in Europe and North America by Descartes and SAPIO Research found that 66% had a delivery problem in the first three months of the year. Among shoppers under 35, the figure was 79%.

The causes are mundane. One carrier-data vendor, Parcel Perform, measured first-attempt delivery success in Germany falling from 92.79% in the first quarter of 2024 to 80.42% in the first quarter of 2025. Its stated reasons were missed delivery windows, incorrect addresses and a lack of flexible delivery options. Parcel Perform does not publish the parcel count or definition behind that figure, so treat it as one vendor's view of its own data. The direction still matters.

A pre-dispatch confirmation call attacks all three causes in one go. It asks the customer to pick a window they can keep and reads the address back, so a wrong flat number is caught at the depot rather than at the door. It also captures the access details a driver cannot guess. A failed first attempt costs a second trip and a second call. The call before dispatch costs one minute.

Which deliveries get a call, and which get a text

A call is for a delivery that needs a decision. A confirmation that needs nothing goes as a text. Routine messages such as "your order ships tomorrow" belong on SMS or WhatsApp, sent by your order system rather than by a call.

The call earns its place when the customer has to answer something. The transportation management system (TMS) flags an address it cannot match. The item is large, needs a signature, or has to go up three floors. The window is a four-hour block and the customer works. The building has a gate, a concierge or a dog. The order is cash on delivery and the money must be ready. In each of those cases a text leaves the question open, and an open question becomes a failed attempt.

Delays after dispatch are a different call with a different legal footing. Our post on AI voice agents for delivery delay and exception alerts covers that case, including what shoppers say proactive updates do for their patience.

Open Source Alternative to Vapi / Retell

Self-hosted voice agent platform — no per-minute fees

dograh-hq/dograh

Star on GitHub

The call itself: greet, verify, then read the window

The agent must know who is on the line before it says anything about the order. The number it dialled finds the record. It does not prove the person who picked up is the customer. Phones are shared, and numbers are typed wrongly at checkout.

So the flow runs greet, verify, disclose. The greeting names your company and says this is an automated assistant calling about a delivery. The verification asks for something the customer knows and a stranger does not, such as the last four digits of the order number or the delivery postcode. Only then does the agent read the window and the address.

Dograh runs this flow as a visual workflow: a Start Call step with a fixed greeting, a verification step, then the delivery steps. In the delivery steps the agent offers the window from live slot data, reads the address and asks for corrections, then asks for access details: gate code, buzzer name, floor, where to leave the parcel if nobody answers. It reads everything back once. Each answer is saved as an extracted variable, recorded as the customer stated it, with the transcript and recording as the exact record.

Some calls go beyond the script. The customer wants a different address outside the delivery zone, or wants to complain about the last order. Before handing those to a person, the agent writes what it has gathered to the TMS or the customer relationship management (CRM) system through an HTTP API tool, so the person sees the notes on screen rather than asking the customer to repeat them. Transfer Call then connects the customer to a person. It works on Twilio only, with an optional spoken introduction that both sides hear.

Where the order comes from and where the slot goes back

The TMS starts the call, feeds it and receives the result, so the voice agent never becomes a second copy of the truth. The sequence is short.

When the TMS routes an order for tomorrow, it fires an event. That event hits Dograh's API Trigger with the order details in the initial context: customer name, order number, planned window, address on file. The agent starts the call already knowing why it is calling. Our tutorial on API Triggers: Start a Voice Agent Call From Any System shows the request.

During the call, an HTTP API tool reads live slot availability from the TMS or routing system, so the agent only offers windows the depot can actually serve. While that lookup runs, the tool's Messages setting plays a short line so the customer hears something rather than silence.

After the call, a webhook carries the confirmed slot and the access details back to the TMS. That slot write-back is what makes the call worth placing: the dispatcher sees the confirmed window on the route, the driver sees the gate code on the stop. The pattern is the same one we describe in our post on webhook-driven voice agents.

Where this data lives is a choice you make once. Addresses, gate codes and phone numbers are personal data about where people sleep. Self-hosted Dograh with self-hosted open-weight speech and language models keeps the call audio and the transcripts on your own servers. With hosted models, the audio reaches the model provider, even when the keys are yours.

Consent before the first ring

An outbound call with an AI voice to a mobile number generally needs the customer's prior express consent, captured at order or sign-up, and our post on US consent rules for logistics and delivery calls sets out the rules state by state. US law carves out a narrow exemption in 47 CFR 64.1200 for a package delivery company's one-shot delivery notices, but a two-way coordination call that asks questions and can run past a minute generally sits outside it. Consent at checkout is the safer basis for a shipper or a retailer.

The practical consequence is that the consent check belongs in the trigger logic. The TMS should only fire the event for customers whose consent flag is set, so the API Trigger never starts a call that should not be placed. Keep the consent record next to the order. The statute text and the exemption's conditions are in the FAQ below, and this is general information rather than legal advice, so confirm your own position with counsel.

When nobody answers, and what to measure

Most pre-dispatch calls reach a person. The rest need a plan. If the call goes to voicemail, the agent leaves no order details, and the TMS sends a text with a link to pick a window. How many times to retry, and how far apart, is a business decision you set in the trigger logic. The agent only has to record every attempt so nobody is called twice in an hour.

Two comparisons tell you whether the call is working: first-attempt delivery success for orders that got a call against those that did not, and the share of calls where the address changed, which is the failed attempt you avoided. The share of calls transferred to a person then tells you where the script needs another step.

When the first attempt fails anyway, the next call is a different one. Our post on AI Voice Agent for Failed Delivery Rescheduling: The 2-Hour Rule covers the call after the missed attempt and why its timing matters.

Start with the deliveries that fail most often on your own routes, usually large items and addresses the TMS flags. Confirm those by phone for a month, measure first-attempt success against the rest, and widen the rule from there.