On this page
A cash-on-delivery order is a promise with no money behind it yet. A short confirmation call before dispatch is one of the simplest jobs for a phone agent: it has one question, a small set of answers, and a clear system to update.
Pass in what the agent needs
Use dynamic variables so the agent starts the call with the facts:
- Customer's first name
- Order number and short item description
- Order amount, to be paid on delivery
- Delivery city or PIN code
- Your brand name
The agent should never ask the customer to supply what you already know, and it shouldn't guess what you haven't told it.
Write the call in a few lines
A Hindi example, for your team to adapt and test:
"Namaste Priya ji, main ABC Store ki taraf se AI assistant bol rahi hoon. Aapke ₹1,299 ke cash on delivery order ke liye call kiya hai. Kya main is order ko confirm kar doon?"
This names the business, says it's an AI assistant, gives the reason for calling, and asks one question. The customer is fictional, and a real script should come from your own brand team. Keep to one language per agent; our language guide covers why.
Limit the outcomes
Allow only these results:
| Caller says | Agent does | Record |
|---|---|---|
| Yes | Calls the confirm tool, then thanks them | confirmed |
| No, cancel it | Calls the cancel tool after one check | cancelled |
| Change the address or item | Says your team will call back | needs_staff |
| Who is this? I didn't order | Doesn't press; flags for review | disputed |
| Call me later | Notes the time they asked for | callback |
| Voicemail or no clear answer | Ends politely | no_answer |
Anything that isn't on this list should end up as needs_staff. Don't have the agent negotiate, offer discounts, or discuss refunds unless you've built and tested those paths.
Connect it safely
Make "confirm" and "cancel" HTTP tools pointed at your order system. Two rules matter:
- The agent only says it's done after the tool succeeds. Put this in the prompt, and test it by making the tool fail on purpose.
- The endpoint should cope with repeats. If the same order is confirmed twice, it shouldn't create two shipments.
Keep the tool's API key in zlicx secrets, not in the prompt.
Record what you will measure
Add the outcome as a structured field in post-call analysis, then send it to your system by webhook. This lets you compare by outcome, by hour and by city without having to read transcripts.
Calling hours, do-not-call checks and consent records are covered in the guardrails article. You can estimate what each call costs with the pricing formula.
What to measure in your pilot
Before you start, write down today's rate of COD orders that are refused at the door. Then run a small batch and compare that rate between confirmed and unreached orders. We don't publish a typical improvement because we don't have customer results to support one. Your own numbers are the ones that count.
See the COD confirmation workflow, or ask us to go through your flow.
Plan your confirmation flow.
Bring your order system, your outcomes and your current refusal rate.