AI customer service for retail: start with verified order status

A carrier record says delivered at 16:40. The customer says the parcel never arrived. An assistant that replies “You received your order” has converted a system event into a fact it does not know.

A useful retail service assistant retrieves authorised records, states what those records show and follows a defined handoff when they conflict with the customer's report. Begin with read-only status and agent assistance. Refunds, address changes and replacement shipments need separate action controls and approval boundaries.

Establish access before retrieving the order

Customer authentication and order access are different checks. A signed-in customer must still be authorised for the specific order requested. The backend should enforce that relationship on every lookup; the language model should not decide access from a plausible name or order number.

OWASP's object-level authorisation guidance explains the risk of accepting object IDs without checking the caller's rights. An order number is a lookup key, not proof of ownership. Apply the retailer's approved customer-verification flow before exposing order, address or payment information.

Return only the fields needed for the service question. A shipment-status answer rarely needs a full billing address, complete payment details or unrelated order history. Restrict logs and review samples so the pilot does not create a second uncontrolled customer-data store.

Work the delivered-but-not-received case

Assume the verified customer is authorised for order O84. The service retrieves:

A grounded reply can say that the carrier currently records delivery at 16:40, acknowledge the customer's non-receipt report and offer the retailer's approved investigation process. It cannot claim proof of handover to this customer or a completed replacement.

If the system is authorised only to prepare a handoff, it should say an agent needs to open the investigation. If it has a separately approved case-creation action, it may say the case was opened only after a successful result supplies the case ID. A tool timeout is not a successful action.

The same distinction applies to refunds. A local approval is not provider processing, and provider processing may not independently prove customer credit. Link the reply to the relevant evidence and use the refund workflow to investigate unresolved money.

1. Verify accessBackend confirms the customer may access order O84.
2. Retrieve narrow recordsRead shipment, provider status, timestamps and approved service policy.
3. State the evidenceCarrier records delivered; customer reports non-receipt.
4. Use the approved handoffPass the conflict and source timestamps to a staffed queue.

Exception: Wrong-order access, stale evidence or an unconfirmed action stops a definitive answer; no invented delivery, refund or case completion.

Keep retrieved text outside the authority boundary

A delivery note, customer message or imported product description can contain misleading instructions. Treat those fields as data. They cannot authorise a refund, change access policy or override the assistant's tool permissions.

OWASP's prompt-injection guidance recommends limiting privileges, separating untrusted content and testing adversarial cases. Implement those controls in the application as well as in the prompt. A prompt saying “never reveal other orders” is not a substitute for a backend that refuses such a lookup.

Give the first pilot read-only tools scoped to the authenticated customer and approved policy records. An agent-assist mode can draft responses for a service representative, but the representative still needs visible source context and a clear way to reject a draft. Do not hide a conflict merely to produce a confident-sounding answer.

Evaluate decisions as well as wording

Create a test set covering normal status, missing tracking, stale updates, split shipments, conflicting delivery, uncertain refunds and invalid order access. Include malicious instructions inside retrieved notes and requests to act beyond the pilot's authority.

For an illustrative 100-case exercise, suppose 52 receive correct direct answers, 35 receive other acceptable decisions (18 staffed handoffs on conflicting states and 17 correct access or prompt-injection refusals) and 13 fail (3 direct-answer errors, 7 missed or premature conflict handoffs and 3 security exposures). That is 87 acceptable decisions out of 100 (87%), with 52% direct resolution, not 87% automation. The 13 failures remain failures even if their prose sounds helpful.

If three failures expose another customer's information, an overall 87% acceptable score cannot justify release. Define critical access and action boundaries as mandatory pass conditions. Review less severe errors by topic and source freshness rather than averaging them away. These counts illustrate evaluation reporting; they are not results from a deployed model.

Set the operating contract before launch

The service head owns response policy and handoff capacity; engineering owns authorisation, tool reliability and monitoring; process owners approve the meaning of order and payment states. Define what happens outside staffed hours. A promise of immediate investigation is misleading if no team can receive the queue.

Set source-specific freshness rules from the actual service contract and customer use case. Show the observation time where it affects interpretation. A carrier may not have a newer event even after a successful refresh; absence of change is not proof that the last physical event is complete.

Begin with a narrow traffic slice and review the first cases. Keep a disable path that returns customers to the existing service channel. Monitor wrong-order denials, unsupported assertions, failed handoffs and unresolved-action messages alongside response time and direct resolution.

Let evidence limit the answer

The assistant's useful boundary is the information it can access and substantiate. A clear uncertainty statement with an effective handoff serves the customer better than a definitive status that the records cannot prove.

1. Select one read-only order-status journey and its authorisation checks.
2. Define source timestamps, state meanings and staffed handoff rules.
3. Test conflicting evidence, wrong-order access and prompt injection.
4. Expand actions only after their separate approvals, retry behaviour and evidence are verified.