Order promises and returns
AI Solutions for E-commerce
Build an e-commerce exception workflow that reconciles order, payment, delivery and return states before a customer receives an answer or refund.
The difficult e-commerce question is rarely “Where is my order?” It is whether the answer remains true when an order has two parcels, one failed delivery, a changed address and a pending refund. An AI solution for a Saudi online retailer should preserve that transaction history while helping the operations team resolve the next exception.
Start with post-purchase operations: an assistant that assembles evidence, proposes the next step and prepares an accurate Arabic or English response. The AI solutions service can be scoped around the store's order platform, payment provider and carriers. The project must confirm the actual interfaces and permissions; a conversational demo does not establish that those connections exist.
Compare post-purchase service with catalogue and fulfilment work
Post-purchase exceptions are one starting point. A retailer with relatively smooth returns but inconsistent product information may obtain more value from catalogue evidence preparation. That workflow converts approved supplier material into structured attributes, flags conflicts and prepares Arabic and English descriptions for review. The unit of acceptance is a correct product variant, with source-supported dimensions, compatibility and conditions.
Catalogue work must distinguish an attribute from a marketing inference. A supplier describing a material as water-resistant does not establish every possible use or a stronger performance claim. Missing dimensions should remain missing until verified. Track publication errors, duplicate variants, customer clarification and returns attributable to incorrect information. More descriptions published is a throughput measure, not proof of better conversion.
A second alternative is fulfilment exception preparation. The assistant can identify orders waiting on stock allocation, address clarification, packing evidence or a carrier handover. It should assign the specific issue to the warehouse or customer team and preserve the order's promised service. It cannot resolve a physical stock discrepancy by repeatedly changing the allocation in software.
For this alternative, evaluate the time from an exception appearing to a verified action, missed cut-offs, rework and incorrectly released orders. An address suggestion should be confirmed through the approved process rather than replacing the customer's destination automatically. A carrier label is evidence of a created shipment record, not proof that the parcel was physically handed over.
Choose between these projects by examining the cause of repeat contacts. If customers ask about delivery because the order never reaches a reliable dispatch state, a more capable chatbot will still lack an answer. If returns arise from inaccurate sizing or product attributes, improving the catalogue may remove more work than accelerating the return response. The scope should identify that causal hypothesis and the evidence that could disprove it.
Expansion across channels needs a transaction reconciliation rule. A marketplace, owned website and support channel may describe the same order differently and hold different permissions. Confirm which system owns the promise and which party can approve a change. Test a cancelled item already packed and a refund already requested elsewhere before allowing an assistant to act across several channels.
Represent the order as several related states
Order acceptance, stock allocation, payment capture, warehouse dispatch, carrier delivery and refund settlement are separate events. “Cancelled” in the storefront may not mean a captured payment has been returned. “Delivered” may describe one parcel rather than the entire order. Keep item quantities and parcel identity, not only a single order-level label.
The minimum record includes the customer-authorised contact, order and item identifiers, original promise, current allocation, payment events, carrier evidence, return eligibility rules and previous communications. Record the event time and the time the store learned about it. Late carrier updates must not overwrite a newer confirmed event simply because they arrived last.
Data extraction is useful for documents and carrier notes; customer service owns conversation resolution. The e-commerce layer reconciles those components against the actual order. Where the sources disagree, the assistant should explain the uncertainty to staff rather than invent a coherent story.
A decision table for post-purchase exceptions
| Observed case | Check before action | Permitted next step |
|---|---|---|
| No dispatch evidence | Warehouse release, allocation and promised date | Ask fulfilment owner for a confirmed plan |
| Partial delivery | Items and parcels covered by each delivery event | Explain remaining items; investigate missing parcel |
| Return request | Applicable policy, item state and evidence supplied | Prepare reviewed eligibility and collection request |
| Refund shown as pending | Authorisation, processor receipt and settlement state | Confirm status without claiming funds have arrived |
| Conflicting recipient evidence | Identity, authorised delivery and carrier record | Escalate for investigation; preserve the dispute |
Policy retrieval must use the version applicable to the transaction and the relevant product exception. The Ministry of Commerce's published e-commerce evaluation criteria include visibility of return, refund, delivery and complaint policies. A buyer should have qualified staff confirm the current legal and contractual rules before converting them into operating decisions.
Worked example: one return, three distinct totals
Illustrative example: an order contains three items priced at SAR 120, SAR 80 and SAR 50, plus SAR 20 delivery. The customer paid SAR 270 before any further adjustments. The SAR 80 item is returned. That item value is known; the refundable delivery amount is a separate policy question, and tax treatment must follow the store's approved accounting rules.
If the authorised refund is SAR 80 and the processor reports SAR 80 submitted, the system must still distinguish submission from settlement. If two channels request the same refund, the order and return reference should prevent a second payment. A helpful response says what was authorised, when it was submitted and what remains unconfirmed. It does not invent a bank arrival date.
In a trial of 200 exception cases, suppose 120 proposed responses require no material correction, 50 need correction and 30 need investigation before a response can be drafted. The immediately acceptable draft rate is 60%, not 85% obtained by excluding investigations. Report both overall coverage and quality within each case type.
Protect the customer promise during automation
An estimated delivery date should come from an approved promise service or a clearly labelled estimate with supporting evidence. A language model should not create certainty because the customer asks repeatedly. Address changes, replacement shipments and refunds need explicit authority because they change the transaction, not merely its description.
Email triage can consolidate cases from multiple inboxes, while fraud detection covers investigative signals. A fraud score is not a reason to accuse a customer or deny a legitimate return automatically. Keep disputed facts reviewable and preserve a route for the customer to correct information.
Test mixed Arabic and English product names, multiple partial refunds, cash-on-delivery exceptions, duplicate webhooks, cancellations during picking and carrier outages. Mask payment and identity data that the task does not need. Do not place sensitive documents in customer-facing messages merely because retrieval found them.
Define authority across the storefront and marketplace
A retailer selling through its own site and a marketplace may receive the same customer request through different channels. Identify the seller, payment recipient, fulfilment party and party authorised to issue the remedy for that transaction. The assistant should not copy a refund action from the direct store into a marketplace case merely because the product code matches.
Test a customer who opens a return in the marketplace and then contacts the retailer by email. Both messages should refer to the same underlying case where the permitted integration supports that association. Preserve the external reference and check current status before creating another remedy. If the marketplace does not expose a required state, tell the operator which confirmation is missing. A commercially useful design can coordinate the follow-up even when it cannot execute the whole process.
Measure resolution across the entire return loop
Track time to an accurate next step, repeated contacts, unresolved case age, incorrect promises, duplicate actions and staff correction time. For returns, follow the physical receipt and the authorised financial event separately. A closed support ticket can coexist with a missing parcel or an unsettled refund; it is not sufficient evidence of completion.
Compare the pilot with cases of similar complexity and sales periods. Marketing campaigns can change order mix and service demand. Finance operations explains reconciliation of transaction exceptions, which becomes relevant when store and payment records disagree. Do not treat all faster drafting as cash savings if the team remains occupied with the same investigations.
The delivery scope should include a state dictionary, policy ownership, approved actions, duplicate prevention, case history, bilingual test set and a recovery procedure for uncertain writes. Trusted Data's Saudi retail guide offers related commercial context across online and store operations.
Review an order-and-return exception workflow with masked order histories, one policy version and examples where the storefront, carrier and payment provider show different states.
FAQ
Your questions, answered.
Can AI authorise every return that matches the written policy?
Begin with prepared decisions for review. Eligibility can depend on product condition, transaction terms and exceptions that are absent from the message. Any later automated approval needs a bounded policy, verified evidence, financial limits, duplicate prevention and an accessible escalation route.
How should split shipments appear in a customer response?
State which items and parcels are confirmed delivered, which remain in transit and what evidence is missing. Avoid copying one parcel’s status onto the whole order. If the estimated arrival differs by parcel, preserve those separate estimates and their uncertainty.
Can the assistant promise a refund arrival date?
Only use a confirmed commitment from the authorised payment process. A submitted refund is not settled funds. The assistant can explain the recorded submission date and next follow-up, but should not invent a bank processing deadline or mark the case complete prematurely.
What makes Arabic order support harder than translating a reply?
Product variants, dialect descriptions, order numbers and customer intent must map to the correct transaction. A polite translation can still promise the wrong size, amount or delivery. Evaluate complete Arabic conversations against the underlying order and policy evidence.
Should the tool send every suspected fraudulent return to rejection?
No. Separate investigative signals from a coverage or return decision. Review evidence, preserve the customer’s explanation and avoid accusatory language. A false positive can create financial and service harm, so evaluate legitimate cases delayed as well as confirmed abuse detected.
What is a suitable first integration boundary?
Read order and shipment states, prepare an exception record and draft the response inside a reviewed queue. Add transaction-changing actions only after identity, approvals, duplicate handling and recovery have been demonstrated. Scope one return or delivery exception before connecting every customer channel.