WISMO AI Phone Calls: Order Lookup and Delivery Promises

On this page
If your team built a voice agent for an online store, WISMO AI phone calls will reach it sooner or later. They are also where an agent is most likely to say something confident and wrong.
This post covers the online-store version of WISMO automation. Order numbers, tracking numbers and emails. Split shipments, backorders and carrier status. Delivered-but-missing parcels, address changes and made-to-order lead times. If you run a delivery or driver line, our posts on missed delivery and return calls and last-mile driver support cover that side. For a restaurant's live order, see pizza where's-my-order calls. For a repair ticket, see phone repair status calls. Here the thing in transit is a retail parcel, and the caller wants a date.
What WISMO AI phone calls really ask
"Where is my order?" is rarely one question. The caller means one of four things. Each needs a different system.
1. Where is it now? A carrier scan question.
2. When will it arrive? A date question. This is the risky one.
3. Why is it late or missing? A cause question. The agent usually can't know.
4. Can I change it? An action question: address, items, cancel.
Your agent should classify the ask before it speaks. A caller who says "it says delivered" is not asking where the parcel is. They are asking you to take a side. A caller who asks "will it be here by Friday?" wants a promise you may not be able to make.
Treat each of these calls as a short workflow. Capture the key, look up the order, read the status, answer the ask, write the ticket. Every step can fail without any visible error, which is why the whole thing needs testing end to end rather than turn by turn.
A caution on numbers. Industry figures for what share of support contacts are WISMO circulate widely. Ship24 followed the citations and says it could not find a published study with a stated method. So this post uses no such figure. Count your own calls instead.
Order lookup by phone: which key did the caller read?
An order status voice agent meets callers who identify an order in at least five ways. Each has its own failure.
| Key the caller offers | Typical failure by voice | Safer handling |
|---|---|---|
| Order number | One digit swapped, or the "#" and store prefix dropped | Read back in groups, then match against open orders |
| Tracking number | 18 to 30 characters, letters and digits mixed | Prefer order number; use tracking only as a cross-check |
| Email address | Spelling, "dot" and "at", plus-addressing | Spell back; never accept a near match silently |
| Phone number | Caller phones from a number other than the one on the order | Treat as a hint, not proof |
| Name and ZIP | Common names, gift orders, shipping name differs from billing name | Use only to narrow, then confirm a detail |
Two traps matter most in retail.
Gift and household orders. The phone on the order is often the buyer's. The person calling may be the recipient. A shared household number can match five orders. If the agent picks the newest one, it answers a question nobody asked. List the open orders by item and ask which one.
Multiple orders per number. An agent that says "your order shipped yesterday" about the wrong order is worse than one that says "I can't find it." The wrong answer is plausible, so nobody catches it. Our post on tracking number capture in delivery exception calls covers the digit math. For retail the fix is the same: read the number back and confirm it against state, not just against what you heard.
The lookup is also where accent, speech pace and a noisy kitchen or car decide the outcome. A transcript can show "48213" while the audio said "48230". When Evalgent runs a WISMO suite, the caller profiles (accent, pace, interruption level, background noise) are applied to the same order-number script, and the verdict is judged from the audio, not only the transcript.
Three clocks that disagree
A parcel has at least three status sources. They do not move together.
- The order system. Paid, in process, partially fulfilled, on hold.
- The warehouse or fulfillment record. Which lines have left the building, and in how many shipments.
- The carrier. Scans, an estimated date, exceptions.
Shopify's Admin API shows how split the picture is. Its `Order` object carries a `displayFulfillmentStatus`, a list of `fulfillments` (shipments), and a list of `fulfillmentOrders` that group items fulfilled together. The display status enum alone has eleven values, including `PARTIALLY_FULFILLED`, `ON_HOLD`, `SCHEDULED` and `REQUEST_DECLINED` (as of November 2026, per Shopify's documentation). Other stores' systems differ in names but not in shape.
So an order can be "partially fulfilled" in your store, "in transit" for box one, "label created" for box two, and "exception" at the carrier for box one. One caller, one order number, three true statements.

The rule for the agent is simple. Speak per shipment, not per order. "Two of your three items shipped in one box and are in transit. The third has a label but no carrier scan yet." That is longer than "your order is on the way," and it is the one that stops the second call.
Backorders and "label created"
Two states cause most of the false reassurance.
- Label created. The carrier has a label, not the parcel. A UPS tracking-status page describes "Shipped/On the Way" as a shipment with a scheduled delivery date that may stay in that status until final delivery, which shows how little a status word can tell you. Do not tell a caller their parcel is "on its way" because a label exists.
- Backordered or on hold. No shipment, no carrier, so no carrier date. The honest sentence comes from your own inventory or promise date, if you have one.
Delivered but not received
"Delivered" is the status callers dispute most. UPS says "Delivered" means the shipment reached its final destination and a delivery time is recorded, and that without a signature requirement the driver may leave it in a safe spot such as a porch or garage. The scan says where the carrier believes it left the parcel. It does not say the caller has it.
The agent has a narrow job here.
1. Read the status and time as the carrier records them, with no embellishment.
2. Ask the caller to check the usual spots: neighbours, mailroom, side door.
3. Never say "it was delivered to you." Say "the carrier shows it as delivered at 2:14 pm."
4. Do not promise a refund or reship. Open a case and state the next step your policy sets.
5. Write the dispute to the ticket with the scan time, the address on the order and what the caller said.
Whether to reship, refund or file a carrier claim is a policy decision. The agent can route it. Keep that decision out of the model. Our missed delivery post goes deeper on claims, and the returns and exchanges post covers the refund side.
Address change requests after purchase
"Can you change the address?" is a request the agent can mishandle in two directions. It can agree when the parcel has already shipped, or refuse when the order is still unfulfilled and a change is easy.
The state decides the sentence.
| Order state | What the agent can do |
|---|---|
| Not yet fulfilled | Offer the change if your system supports it, and read the new address back |
| Label created, not scanned | Route to a human; the label may need to be voided |
| In transit | Do not promise a change; offer carrier redirect steps or a human |
| Delivered | Treat as a delivered-not-received case |
On any address change, spell the new address back, and get the apartment number and ZIP confirmed. A street name heard wrong is an order that now ships to a stranger. Never write the change from a single hearing.
Delivery promises in WISMO AI phone calls: the carrier estimate is the ceiling
The most expensive sentence on a WISMO call is the date. The rule we recommend: the agent may read the carrier's estimated delivery date, attribute it to the carrier, and say it can change. It may not compute, round or soften a date itself.
Why. Speed matters to buyers: Baymard's cart abandonment list shows 20% of abandoners who were not just browsing cited slow delivery. And the estimate moves. UPS describes an "Exception" as an unexpected error that may change the scheduled delivery date, and says the new date then appears in tracking. A date read at 9 am may be stale at 3 pm. Add the phrase "as of" when the status was last updated, and read it only if the timestamp is recent.
Made-to-order, pre-order and backorder lead times
For these, there is no carrier date at all. The only date is your own, and it is a business promise. The agent should read the date from a single field, label it as an estimate and never invent one from "typically ships in two weeks" text in the prompt. If the order is a pre-order, say so, and say whether the date can move.
Where the FTC rule fits
The FTC's Mail, Internet, or Telephone Order Merchandise Rule, 16 CFR Part 435, covers orders placed by mail, over the internet or by telephone, including automated phone systems (§ 435.1). In plain terms, as of November 2026:
- You need a reasonable basis to expect to ship what you sell.
- If you state a shipping time, you must ship within it. If you state none, the default is 30 days after you receive a properly completed order, or 50 days if the buyer applied for credit with the order (§ 435.2(a)(1)).
- If you cannot ship on time, you must offer the buyer a choice to consent to a delay or cancel for a refund, without waiting to be asked, and give a definite revised date where possible (§ 435.2(b)).
- Silence can count as consent for a delay of 30 days or less. It cannot for a longer one (§ 435.2(b)(1)(ii) and (iii)).
- "Shipment" means the goods are in the carrier's possession, not delivered (§ 435.1(e)).
For WISMO AI phone calls, the point is narrow. A sentence such as "it will ship Friday" is a shipping-time statement from your company, and the FTC's business guide says shipping details a representative gives on a call replace earlier advertised times. So the agent should state ship dates only from a verified system field, and a delay conversation should go to a human or a controlled flow. This is general information, not legal advice. Check your own order flows with counsel.

One worked example of a failed WISMO AI phone call
This is an illustrative example, not measured data. A caller phones from a shared household number. Three open orders match. The caller says "the blue jacket, 48213."
| Step | What the agent hears or does | Where it silently goes wrong |
|---|---|---|
| Capture | "48213" | Heard as 48230, a different open order |
| Match | Order 48230, a kettle | Number read back; caller says "yeah" to a long string |
| Status | Kettle delivered Monday | Agent says "your order was delivered" |
| Promise | "Anything else?" | Caller assumes the jacket is delivered too |
| Ticket | "Customer confirms receipt" | The CRM now records a receipt that never happened |
Every step looked fine in isolation. The transcript reads smoothly. The failure is a wrong key, a wrong match and a wrong record, and nobody is told until the jacket's customer calls a third time. That is why you test the identifier by item, not just by number.
What the ticket must carry
A where is my order voice agent ends each call with a write-back. It is the part of WISMO AI phone calls that teams leave untested. A useful WISMO ticket holds:
- The key the caller gave, and the key the agent matched. Both.
- Which shipment and which line items were discussed.
- The status and the carrier timestamp the agent read.
- The exact date sentence, if any, and its source field.
- The caller's ask (where, when, why, change) and the disposition.
- Any promise made and any handoff.
If the ticket says "status provided," you cannot audit anything later. If it stores the sentence and the source, you can.
How to test WISMO AI phone calls
Run this before any prompt, flow or tool change to your WISMO AI phone calls ships. Our prompt-change release guide covers the release gate, and the vendor evaluation post shows the same checks for a bought agent.
1. Seed a small order set. Include a single-item order, a split order, a backorder, a pre-order, a made-to-order item, a delivered order, an exception, a cancelled order and a gift order.
2. Seed identity traps. A shared phone number with several open orders, two orders with near-identical numbers, and an email that differs by one letter.
3. Script the four asks. Where, when, why and change. Include callers who change their mind mid-call and who read the key in chunks.
4. Vary the callers. Accent, speech pace, interruptions, response delay and background noise. Repeat the number with and without noise.
5. Check the lookup. Did the agent match the right order? Did it read back before it spoke?
6. Check the sentence. Compare each spoken status and date with the seeded source. Any date not from the carrier or promise field fails.
7. Check the write-back. Compare the ticket with the call. Wrong order, missing shipment or invented date is a fail.
8. Rerun after every change. Track wrong-match, wrong-date and bad-ticket rates per scenario.
For ecommerce voice agent order lookup, Evalgent generates test scenarios from the agent's prompt and flows, so branches like "split shipment" and "delivered but not received" become explicit cases rather than ones someone remembered. It then runs the simulator over phone, SIP or WebRTC and judges the audio, with evidence, plus custom metrics you define such as "date sentence cites carrier."

How many calls?
If you want to show a defect rate under 2 percent, with no failures observed, a rule of thumb is about 3 divided by the rate. That is roughly 150 clean calls per scenario family. This is a rough planning figure, not a guarantee. Rare, high-cost paths such as delivered-not-received deserve their own set.
What to monitor in WISMO AI phone calls in production
Tests cover what you thought of. Order tracking calls from real callers cover the rest. Push recordings from live calls into a monitor, and watch:
- Calls where the agent gave a date, and whether the date matched the carrier at that time.
- Tool-call failures at the lookup step, and calls that ended without a match.
- Repeat calls on the same order within 48 hours, a proxy for an answer that did not land. Our containment vs resolution post explains why this beats a raw containment number.
- Latency spikes at the lookup, where silence makes callers repeat the number.
- Tickets whose stored status differs from the sentence spoken.
Evalgent's production monitoring takes customer-pushed recordings, transcribes them, maps them to scenarios and judges them. It flags tool-call failures, latency spikes, policy failures and PII leakage, with fix recommendations. Use it to feed the failures back into the test set.
Frequently asked questions
What does WISMO mean for AI phone calls?
WISMO stands for "where is my order." On the phone, an AI agent identifies the caller's order, reads status from your order and carrier systems, and answers a where, when, why or change question. In WISMO AI phone calls, that is a lookup plus a spoken statement. Both can fail without any visible error.
How does an AI agent find an order by phone?
For order lookup by phone, it takes a key the caller reads, such as an order number, then matches it against open orders and reads it back. Phone number and name only narrow the list. When several orders match, the agent should list them by item and ask, rather than pick the newest.
Can an AI agent give a delivery date for an order?
Yes, but only a carrier's estimated date, attributed to the carrier and stamped with when it was last updated. The agent should not compute or round a date. For pre-orders and made-to-order items, read a single date field from your own system, and say it is an estimate.
What should the AI say when tracking shows delivered but the parcel is missing?
It should report what the carrier records, including the delivery time, and avoid saying the caller received it. It should suggest checking common spots, open a case with the scan details, and route the reship or refund decision to your policy or a human.
Can an AI agent change a shipping address after the order?
Only while the order is still unfulfilled and your system supports it. Once a label exists or the parcel is in transit, the agent should route to a person or share redirect steps. Always spell back the new address and confirm apartment and ZIP.
How do you handle split shipments on a WISMO call?
Speak per shipment, not per order. Name which items are in which box, give each box its own status, and say when one has a label but no carrier scan. A single "your order is on the way" misleads on at least one box.
Does the FTC shipping rule affect WISMO AI calls?
The FTC's order merchandise rule (16 CFR Part 435) covers orders placed by mail, internet or phone, and sets shipping-time and delay-notice duties. A ship date your agent states is a seller statement, so source it from a verified field. This is not legal advice; ask counsel.
How do you test a WISMO voice agent?
Seed orders covering split, backordered, delivered, exception and gift cases. Add identity traps such as shared phone numbers. Run varied callers over the phone, then check the match, the spoken status and date, and the ticket. Rerun after every prompt or flow change.
The bottom line
A voice agent for WISMO AI phone calls is only as good as the order it matched and the sentence it chose to say. Test both, from the audio, before every change reaches your customers.
Related Articles

How to automate voice agent testing: synthetic callers vs manual QA
Learn how ai test automation replaces manual QA for voice agents. Compare synthetic callers vs human testers, with a 5-step framework to scale without hiring.
Read more
AI Agent Testing vs Voice Agent Testing: What General Tools Miss for Voice
AI agent testing measures text outputs. Voice agent testing measures behaviour through an acoustic pipeline. Five failure categories general tools miss.
Read more