An order confirmation call can stop a bad shipment before it becomes a return, a support case, or a failed cash-on-delivery collection. It can also create new risk if the call exposes customer data or lets a language model change an order without controls. The useful design is a narrow workflow: call selected orders, capture an explicit decision, commit it through a policy-controlled API, and route every uncertain case to a person.
What an order confirmation call should do
An order confirmation call is a phone conversation after an order is created and before fulfillment. It confirms buyer intent and resolves delivery-critical details such as quantity, delivery window, or an incomplete address. It does not replace the written receipt, prove that payment settled, or guarantee delivery.
The call should have a defined operational purpose. Common triggers include cash-on-delivery orders, an address validation failure, an unusual quantity, an urgent or perishable shipment, or a fraud-review rule that requires customer contact. Calling every customer adds cost and interruption without necessarily changing an outcome.
Choose the lightest channel that can resolve the issue:
| Channel | Best fit | Main limit |
|---|---|---|
| Email or SMS | Receipt, order summary, tracking, and a self-service change link | Easy to miss when fulfillment is time-sensitive |
| Keypad IVR or OTP | A binary confirmation or proof that the buyer controls a phone number | Cannot handle questions or nuanced corrections well |
| Voice AI | Multi-turn confirmation, clarification, constrained corrections, and human handoff | Requires integration, testing, policy controls, and exception handling |
| Human agent | High-value, disputed, sensitive, or policy-heavy orders | Higher handling cost and limited capacity |
At Dasha, we provide a managed voice AI backend for teams that need the third option. Dasha can place outbound calls, conduct the conversation, invoke your business tools, and return call results. Your order system remains the source of truth.
A production order confirmation workflow
The safe boundary is simple: the voice agent can gather intent, while deterministic services decide whether a record may change. A prompt is never the authorization layer for shipment, cancellation, refund, discount, or payment.
1. Select orders with an explicit policy
An order event reaches a policy service first. The service checks the order state, payment method, fulfillment deadline, customer communication preference, calling window, suppression list, risk signal, and whether a call has already been scheduled. It returns call_approved or a reason to skip.
This gate prevents duplicate calls and keeps ineligible customers out of a campaign. It also makes the trigger auditable. The model does not decide whom to call.
2. Create a minimum-data call job
Pass an opaque order_id, policy version, locale, and correlation ID to the call job. Avoid putting a full address, payment data, or other unnecessary personal information in call metadata. The voice agent retrieves current, approved details from a read-only order tool after the call connects.
Record the order version used to start the conversation. That version lets the backend reject a stale write if a customer or employee changes the order during the call.
3. Schedule the outbound call
Dasha's REST API can schedule individual or bulk outbound calls with priority and custom data. A linked phone number and SIP credentials provide the telephony route and caller ID. Use the customer's local time zone, a bounded call deadline, and a capped retry policy.
additionalData should carry correlation values such as order_id, policy_version, and attempt_number. It should not become a second customer database.
4. Identify the business and capture a decision
The agent identifies the merchant, says it is an automated assistant, explains the purpose, and gives the customer a safe way to disengage. It verifies the right person without reading sensitive details aloud, then presents only the facts needed for the decision.
The terminal outcomes should be constrained values such as:
- confirmed
- correction_requested
- cancellation_requested
- human_requested
- wrong_person
- unreachable
- disputed
- system_error
A completed call with no valid decision stays pending. Silence, a hang-up, or a positive-sounding sentence is not confirmation.
5. Commit through a policy-controlled tool
After an explicit read-back, the agent calls a narrow tool such as commit_order_decision. Its JSON Schema should allow only known actions and required identifiers. The backend then authenticates the request, loads the current order, compares versions, enforces allowed state transitions, and writes once using an idempotency key.
For example, a fulfillment-ready order may allow pending_confirmation to become confirmed. An already shipped order must reject cancellation. An address change may create correction_pending_review instead of updating the shipping record immediately.
6. Close the loop outside the call
Send a written confirmation of what happened. A completed or failed-call webhook should update the campaign record, create any human task, and attach the call ID to the order timeline. Fulfillment consumes the committed order state, never a transcript summary.
A script that customers can trust
People receive scam calls that imitate merchants. The opening should reduce uncertainty without proving identity by revealing the customer's address, items, or payment details. It should also state what the agent will never request.
A practical opening sounds like this:
Hello, this is Ava, an automated assistant calling for Northstar Shop about order ending 4821. I will not ask for your password, login code, or full card number. Is now a good time to confirm the order?
Then verify with a fact the customer supplies rather than one the agent reads aloud:
For privacy, please tell me the delivery ZIP or postal code.
After a match, summarize only the decision-critical details:
Thank you. This order has two items, a total of $84, and delivery to Austin. Would you like to confirm it as placed, correct something, cancel it, or speak with support?
Before any write, use an explicit read-back:
I heard that you want to cancel order ending 4821. Should I submit that cancellation now?
If the backend accepts the action, state the resulting status and send the receipt. If it rejects the action, do not improvise a promise. Explain that no change was made and create the approved support path.
If you received an unexpected confirmation call
The call may be legitimate, especially after a cash-on-delivery order, but caller ID alone is not proof. Do not share a password, login OTP, or full card number. If you do not recognize the order or the caller asks for a secret, end the call and contact the merchant through the number in its app, website, or original receipt. A trustworthy workflow gives customers that option without penalizing the order.
How Dasha fits into the integration
Dasha is the conversational runtime and operating layer. It is not a prebuilt Shopify order-verification plug-in, an order management system, or a fraud engine. A technical team connects it to the systems that already own those functions.
| System | Role in the workflow | Recommended boundary |
|---|---|---|
| Commerce platform or OMS | Emits the order event and stores order state | Sends an opaque order reference to the orchestrator |
| Policy service | Decides eligibility and allowed actions | Owns calling rules, consent status, state transitions, and limits |
| Dasha | Runs the outbound conversation | Collects intent and invokes narrowly scoped tools |
| Telephony provider | Supplies the number and SIP route | Own numbers, reputation, routing, and geographic coverage |
| Order API | Reads current details and commits approved decisions | Authenticate, authorize, validate, version, and deduplicate every request |
| CRM or ticketing | Receives transfers and exceptions | Create a task with the order ID, call ID, reason, and urgency |
| Messaging service | Sends the receipt or fallback link | Keep written communications in the existing customer channel |
| Warehouse and delivery systems | Fulfill the committed state and report final outcomes | Do not dispatch based on conversation text alone |
Dasha tools call external HTTPS endpoints using JSON Schema arguments. Event webhooks report call start, completion, failure, and transfer decisions. Completed calls can be inspected through transcripts, audio when recording is enabled, model interactions, tool executions, and a timeline. This gives engineering and operations teams one trace to debug while business authorization stays in their own backend.
For a first build, two business tools are enough:
- get_order_for_confirmation(order_id) returns a redacted, current view plus order_version and allowed actions.
- commit_order_decision(order_id, order_version, action, idempotency_key, fields) returns the authoritative new state or a structured rejection.
Use a third tool, create_support_case, only when the exception queue cannot be created from the completion webhook.
Exception handling is part of the product
Most operational damage occurs outside the ideal conversation. Define each exception before launch.
| Exception | Agent behavior | System behavior |
|---|---|---|
| No answer, busy, or voicemail | Leave a minimal message with no order details, if policy allows | Record the attempt, apply the retry cap, then use the approved written fallback |
| Wrong person | Apologize and disclose nothing else | Suppress more calls until the contact record is reviewed |
| Customer disputes placing the order | Do not seek payment or persuade | Hold fulfillment and open a fraud or support case |
| Address or item correction | Capture the requested change and read it back | Validate inventory, price, delivery eligibility, and approval rules before committing |
| Order changed during the call | Say the order needs review | Reject the stale version and route to a fresh lookup or a person |
| Tool timeout or ambiguous response | State that no change was completed | Keep the order pending and reconcile by correlation ID |
| Duplicate tool call or webhook | Do not announce a second change | Return the first result for the same idempotency key |
| Customer asks to pay | Move to the approved payment channel | Keep card data out of the model, transcript, recording, and tool payload |
| Customer asks for a person | Stop the automated flow | Transfer or create a priority callback with context |
Fallback results are useful for read-only tools. They are unsafe for a write tool if the fallback could sound like success. A failed mutation must return a clear failure state.
Test the complete deployed path
Prompt review alone cannot establish that an order flow is safe. Test the conversation, telephony, tools, webhooks, and final system state together. Dasha supports browser chat, browser voice, and real-phone tests, followed by completed-call inspection.
Build a regression set from real order states and expected results:
- clean confirmation produces one allowed write and one receipt;
- cancellation requires explicit final confirmation and stops fulfillment only when policy allows;
- correction changes only approved fields and preserves totals or delivery promises until recalculated;
- wrong-person and voicemail paths reveal no order details;
- a stale order_version produces no write;
- repeated tool calls and webhook deliveries produce no duplicate mutation;
- a timeout, 500 response, or malformed result leaves the order pending;
- background noise, interruption, silence, and self-correction do not create a false confirmation;
- a human request reaches the queue with the correct context;
- an unexpected request for payment, a refund, or an unrelated action is declined or handed off.
Release gates should include zero unauthorized or duplicate state changes, zero disclosure of prohibited secrets, complete trace correlation, and successful exception routing. Review all failures and a random sample of successful calls after launch. Add every reproduced production defect to the regression set. Our voice agent testing guide goes deeper on scenario design and failure injection.
Measure outcomes after the call
A confirmation rate measures what callers said. It does not show whether the program improved delivery or unit economics. Join call data to fulfillment and payment outcomes by order ID.
| Metric | Definition | What it reveals |
|---|---|---|
| Contact rate | Right-party connections divided by eligible orders attempted | Reachability, timing, and number reputation |
| Valid decision rate | Accepted confirm, cancel, or correction outcomes divided by right-party connections | Conversation usefulness |
| Decision accuracy | Audited correct dispositions divided by audited calls | Mishearing and interpretation risk |
| Unauthorized mutation rate | Disallowed or unconfirmed writes divided by write attempts | Safety of the authorization boundary |
| Duplicate mutation rate | Repeated business changes divided by write attempts | Idempotency failures |
| Delivery success | Delivered and, for COD, paid orders divided by dispatched orders | Downstream operational outcome |
| Prevented fulfillment cost | Stopped invalid orders multiplied by avoidable handling and shipping cost | Gross loss avoided |
| Cost per valid decision | All program costs divided by valid decisions | Efficiency of the channel |
| Complaint, opt-out, and transfer rates | Each event divided by connected calls | Customer friction and scope mismatch |
Use a comparable holdout cohort that follows the previous confirmation process. Compare final delivery, return-to-origin, payment collection, support contacts, and contribution margin. Otherwise, riskier orders selected for calls can make the called cohort look worse even when the workflow helps.
Model the business case with your own costs:
Net benefit = avoided failed-fulfillment cost + contribution recovered from corrected orders - call, platform, integration, review, and support costs
Keep avoided cost separate from recovered revenue. A cancelled bad order can save shipping expense without creating a sale. A corrected order can preserve contribution only if it is later delivered and paid.
Compliance and trust boundaries
Compliance rules depend on where the merchant and customer are located, the number called, the technology used, the call purpose, and the consent record. Turn those rules into executable policy fields rather than prose in the prompt.
For U.S. calls, the FCC has confirmed that AI-generated voices fall within the Telephone Consumer Protection Act's restrictions on artificial or prerecorded voice calls. The detailed requirements for consent, identification, calling behavior, and opt-out mechanisms sit in 47 CFR 64.1200. Store the consent basis and policy version used for every scheduled call.
Keep the confirmation flow transactional. The FTC treats updates about a prior sale, including order status and delivery information, as purely informational under its Telemarketing Sales Rule. Adding a product offer, upgrade, warranty, or other sales component can turn a mixed prerecorded message into telemarketing with different requirements. The FTC's compliance guidance explains that distinction. Do not insert an upsell into the confirmation script by default.
The production policy should also cover:
- suppression and opt-out handling across systems;
- permitted local calling windows, retry caps, and frequency limits;
- merchant identity, automation disclosure, callback route, and caller ID;
- recording notice, consent, access, and retention by jurisdiction;
- minimum personal data in prompts, metadata, transcripts, and logs;
- encryption in transit, secret rotation, role-based access, and audit events;
- a secure payment boundary aligned with PCI DSS;
- language and accessibility needs, plus an immediate human option;
- deletion and correction workflows for customer data.
Where voice AI does and does not fit
Voice AI fits when a material number of orders need a time-bound decision and the likely conversations are narrow enough to constrain. It is especially useful when customers often need to explain a correction rather than press a key.
It is a poor fit when email or SMS already resolves the issue, order volume cannot justify integration and review, or most calls require negotiation and discretionary judgment. High-risk cancellations, refunds, disputed identity, regulated goods, and payment collection should stay behind stronger authentication and human or deterministic controls.
Dasha handles the real-time conversation, call execution, tools, testing, and traces. It cannot make stale order data accurate, guarantee that a customer answers, prevent carrier spam labeling, or turn an unconstrained prompt into a safe transaction. The merchant still owns telephony setup, business APIs, compliance policy, release acceptance, and the human recovery queue.
Start with one narrow flow: read the current order, capture an explicit confirm or request for help, and keep all changes in human review. Once the traces and downstream metrics show that the boundary works, add idempotent cancellation or correction actions. To build that pilot on a managed production runtime, start with Dasha.