AI voice agents for retail: orders, deliveries and inquiries

Start with one frequent contact reason

A retail voice agent should separate general questions from individual purchase lookups. Store policy explains delivery, pickup and returns; the order system supplies individual status. Define the source for each question and the data authorizing lookup. A delivery-time policy does not establish where someone’s order is.

Attach current documents for opening hours, pickup and general guidance. Review store and regional rules so a generic answer does not hide an important exception.

Connect changing data

In Tigy, a configured tool can look up the store’s system when an integration is ready. Stock, timing and delivery status must come from current information. Agree with the integration team on what details the agent should request and which results it may communicate to the customer.

The integration must be configured; this scenario does not imply a ready-made connector for every commerce platform. Confirm the returned data before stating a deadline or availability.

Distinguish a request from a completed action

Recording an exchange request does not approve an exchange. Explain the completed step and who confirms what happens next. Preserve that distinction during integration failures.

If the caller changes an identifier or says the order belongs to someone else, follow the operation's confirmation process before a lookup or action.

Assess usefulness for customers and staff

Test nonexistent orders, slow lookups, pickup at another store and out-of-scope requests. Observe whether staff can continue without repeating the entire discovery process.

Track completed lookups, repeat contacts and staff effort needed to resolve exceptions. Use these together to decide whether to add more contact reasons to the pilot.

Distinguish policies, orders and deliveries

Policies define general conditions, order systems record transactions and logistics systems report delivery events. They update separately.

“Do you deliver Saturdays?” can use policy; “Will my order arrive this Saturday?” requires individual data and an available estimate. Dispatch status alone is not a guaranteed date.

Map questions to sources and authorized identifiers. General questions do not require full personal profiles. Collect information when it changes the next step.

Handle delayed delivery with verifiable information

For a fictional delayed order, confirm the reference and query the source. Present new estimates as estimates. Without one, explain status and follow the approved request process rather than invent reasons.

Mentioning another address does not authorize changing it. Confirm intent, check eligibility and wait for system acceptance. Dispatched orders may require a different process.

Test missing orders, two recent purchases, a corrected order number and a failed lookup. The store’s system must prevent access to another customer’s orders. Understanding speech correctly does not replace that protection.

Evaluate resolution and repeat contact

Track correct answers, routing, corrections and repeat contacts for the same order. Reading status may leave the original question unresolved; check the next step.

Separate promotions from normal periods because stock, logistics and staffing change. Otherwise logistical effects may be misattributed to the agent.

Start with lookups and guidance before write operations. Each new action needs its own authorization and confirmation tests.

Separate store policy from individual lookup

In retail, an order question often starts with general policy and ends with an individual situation. “Do you deliver to this neighborhood?” may be answered from approved information. “Will my order arrive today?” needs retrieval of the correct record and current status. The agent must distinguish these tasks before applying the same general policy to both.

Map frequent intentions with staff: timing, tracking, pickup, missing items, returns and address changes. Mark what requires documents, what needs retrieval and what requires human decisions. A pilot can begin with a few intentions if introductions clearly communicate scope. Advertising comprehensive service and refusing most requests creates poor expectations.

Use sources to explain processes and tools for individual data. Do not upload a spreadsheet containing every order into shared knowledge as a shortcut. Besides difficult maintenance, it lacks the authorization and freshness of retrieval from the responsible system. Documents hold policy; integration decides which records may be returned.

Consider a fictional store delivering to selected regions and offering pickup at two branches. Asking for a neighborhood helps explain coverage but does not confirm delivery for an existing purchase. Asking for a code may locate an order but does not independently authorize exposing all its data. Each task needs a defined contract, including what happens when callers lack identifiers.

Distinguish status from estimates too. “Being prepared” describes a state. “Expected tomorrow” describes an estimate. Explanation should preserve both without concluding that delivery is guaranteed. Test callers pressing for absolute confirmation, because conversational pressure can encourage promises unsupported by the system.

Confirm identifiers without turning calls into forms

Request only information the task needs and explain its purpose briefly. If a code enables lookup, say so. Avoid opening with full name, address, identity document and email when the operation does not use all those fields. Excessive collection increases effort and makes the real contact reason harder to identify.

Allow pauses and corrections in numeric sequences. Customers may read purchase messages while speaking. Before retrieval, confirm the relevant detail in a recognizable form. If a digit is corrected, the new value should replace the old one. Inspect the parameter sent to the tool rather than only the visible transcript.

Incomplete codes need a specific procedure. Do not guess missing digits or retrieve the “closest” record. The agent can request the rest or explain where to find the code when that guidance is approved. If continuation is impossible, offer the store's real alternative without inventing another search method.

If a lookup finds more than one result, agree on how to identify the right order without exposing other people’s information. The agent must not read out unrelated purchases to ask which one seems right. The store’s system needs to check access permission and return an explanation that protects customer information.

Test someone calling for another person, a shared number and incorrect identification. These situations exercise access policy. Conversation should collect the approved minimum, while integration blocks what policy disallows. Courteous speech and system control serve complementary purposes.

Treat modifications as separate capabilities

Retrieving an order does not give the agent permission to cancel it or change its address. Each write needs specific conditions. A store may allow modification before one stage and require staff afterward. The integrated system must enforce that rule alongside instructions. Status can change between retrieval and attempted modification.

Before writing, confirm details affecting the purchase and wait for agreement. Do not repeat an entire profile when only one field changed. Then use the operation result to explain the outcome. “Request received” does not mean “Address updated.” If modification needs review, conversation must retain that condition.

Plan for missing responses. An update may complete even when the agent receives no result. The system should allow investigation or recognition of repeated requests. Uncontrolled resubmission can create duplicate records or unnecessary messages. Explain absent confirmation and the approved alternative without claiming nothing happened unless verified.

Include changing decisions in tests. Someone requests cancellation, hears an alternative and decides to keep the order. The agent must follow the current decision. If an operation was already submitted, do not promise reversal without actual capability. Review action sequence rather than only the final sentence.

When a capability is outside the pilot, explain the limitation with an executable next step. Generic refusal leaves customers to discover the remainder themselves. Clear guidance to the approved department or channel improves continuity without implying the agent performed the change.

Test complaints and delivery discrepancies

System status may conflict with the customer's account. A record says delivered, but the caller says nothing arrived. The agent should explain the retrieved state without treating the report as false. The next action must follow approved investigation or human-service procedures. Do not conclude delivery was correct solely because a status exists.

Another situation concerns missing or incorrect items. General policy can explain how to request review without authorizing refund or replacement promises where decisions require investigation. Collect only information used by the process and confirm what was recorded. If a case is created, confirmation should depend on system results, including a reference where available.

During the pilot, compare completed lookups, recorded complaints and confirmed changes separately. Explaining status differs from resolving a discrepancy. This distinction supports deciding where automation is ready and where staff remain necessary.

Maintain examples for unavailable tracking services, old policies and customers correcting order details. Review them after integrations or retail procedures change. A working lookup should remain correct, while exceptions should still produce honest explanations and useful next steps. This keeps success tied to the actual shopping task rather than merely a completed call.

Give staff concrete pending information

When routing an exception, record what remains unresolved through the approved process. Did the customer check the code? Did retrieval return a conflicting status? Is modification still unconfirmed? These details help staff resume the task without interpreting a vague description as a final outcome.

If integration sends a summary, test association with the correct contact and delivery confirmation. Without that capability, do not claim staff received the history. The next step must reflect actual available service.

Use this information when reviewing repeat contacts too. A caller returning about the same unresolved issue may reveal a continuity failure even when each individual call sounded helpful. Compare the pending task with subsequent confirmed actions, rather than counting every repeated status explanation as a new resolution.