AI systems built on your order and catalogue data

Start with the contact mix

List the request types the queue receives: order status and delivery, returns and exchanges, cancellations, address changes, refund status, sizing questions and serviceability for an address. Which of them carry the volume is read from your own ticket history rather than assumed, and the scope worth building is the part that is both high volume and answerable from a system of record.

The channel then decides what the agent may send. A delivery or refund update is business-initiated and needs an approved template within the messaging provider's session rules, while a return request arrives from the customer and opens a window for a free-form reply.

Order state is spread across several systems

A question about where an order is does not map to one query. Order records sit in the order management system, pick and pack state with the warehouse, movement events with the carrier and refund state with the payment gateway, and they disagree in normal operation: a carrier scan can arrive before the webhook that updates the order.

The agent names the system it read and when, follows an agreed precedence rather than the newest record, and reports a partially shipped order per line item. Before disclosure the request is bound to the order by a session token from a signed-in account or a one-time code sent to the contact already on the order, enforced in code. An order number plus an email address identifies a request; it does not authenticate it, and must not by itself unlock a delivery address.

Orders also arrive from more than one source, each with its own identifier format and return rules: marketplace orders, store purchases exchanged online, quick-commerce and cash-on-delivery. A marketplace often controls the refund and mediates buyer contact, so permitted actions are scoped per channel in the tool layer.

Retrieval over a catalogue that keeps changing

A product catalogue does not behave like a document corpus, because part of it is mutable state. Descriptions, materials and size charts are stable text worth indexing; price, inventory, promotions and delivery promise are not, because a copy inside an index goes stale the moment stock moves.

Stock is held at variant level while content usually lives at parent-product level, and the payable price is not a catalogue field at all, so a jacket question resolves to a size and colour before stock can be read or the pricing engine asked for a figure. Gaps in a supplier feed are where a model starts inferring, so the fields the agent may assert are listed explicitly.

Where price, stock and delivery dates come from

Three statements carry the bulk of the risk: price, stock position and delivery date. A wrong price has to be either honoured or retracted, and either way it is a complaint rather than a sale. A wrong in-stock position produces an order that cannot be fulfilled, which is a cancellation and a refund. A wrong delivery date produces a dispute, and where the customer has prepaid it can end in a chargeback for an item not received.

All three are function calls with a read timestamp rather than retrieved text. The payable amount comes from the pricing and promotion engine, which knows about coupon stacking, regional price lists and tax. Stock is read at answer time for the destination, dates come from the serviceability data the checkout uses, and when a service is unavailable the agent says it cannot confirm the figure.

Which returns policy applies to an order

Policy answers are version-sensitive in a way that most knowledge-base answers are not. The return window, who pays return shipping, whether an exchange replaces a refund and which refund method applies may all have changed since the order was placed, and the version in force on the order date normally governs the merchant terms. Policy documents therefore carry effective dates, and retrieval selects that version rather than the page published today.

Above those terms sit statutory consumer rights, which apply whichever policy version was published, so the eligibility check encodes both layers and no refusal comes from the merchant terms alone. Which statutory rights apply in your markets is a question for your own advisers rather than something we determine.

Eligibility is calculated against the order record rather than retrieved from a policy passage. Exclusions cover final-sale items, hygiene products, perishables, opened electronics and made-to-order goods, and over them sit facts only the order knows: days since delivery, whether the line has already been returned, and how it was paid for.

Write-actions that change an order

A return is raised per line item and per quantity rather than per order, so that granularity belongs in the tool contract, alongside reverse pickup, cancellation before dispatch, an address change and an invoice resend. Eligibility is re-checked server-side, and each action is confirmed before it runs, restating the items and the refund method. The idempotency key is supplied by the caller and scoped to a short dedupe window over the order, the lines and the quantities requested, so a redelivered webhook does not create a second return authorisation, while a genuine later return of the remaining quantity still goes through.

The failures that matter here are races with fulfilment. A cancellation requested after the shipment is manifested with the carrier is a refuse-delivery or return-to-origin path, and between pick and manifest it depends on what the fulfilment system permits, so the cut-off is read from that system rather than assumed. A rejected action is reported as rejected.

Some things stay out of scope. The agent does not read back payment instrument details, and it does not make discretionary decisions: a goodwill refund beyond policy, a price or discount concession, a fraud or blocklist call and a write-off all route to a person. The agent supplies the order context for that decision; it does not take it.

Sale events and the volume they bring

Retail contact volume follows the promotional calendar. A campaign send or a festive sale can compress a day of contacts into an hour, and returns arrive a return window behind the sale rather than with it, so the sale load and the returns load are two different peaks.

At peak the binding limit is as likely to be the rate limits of the order management, fulfilment and marketplace APIs as model throughput, so those limits are read before the architecture is fixed. That is also where caching would otherwise be introduced and where it is least safe, since price and stock move fastest during a sale. Catalogue text can be cached briefly, stock, price and order state not at all, and identical lookups are coalesced. Degraded behaviour is agreed in advance: answer from what is readable and say what could not be checked.

Evaluate against real order states

The evaluation set comes from historical tickets with their resolutions, weighted by the request mix those tickets show, plus fixtures for every order state the business can produce: placed, partially shipped, out for delivery, delivered, delivery failed, returned to origin, refund pending, refund credited. Answering a delivered order correctly demonstrates nothing about the failed-delivery case.

It also carries the cases specific to this domain: carrier events ahead of the order record, returns outside the window or on an excluded category, a request for an order the conversation cannot be bound to, and a dependency returning errors. Retrieval, generation and write-actions are scored separately, and the set is rerun on every prompt, model, policy and catalogue change.

What an ecommerce build costs

Every engagement starts with a fixed-price discovery sprint at USD 2,500 over two weeks, which produces the architecture, initial screen designs, acceptance criteria, a running-cost model and a fixed price for the build. The sprint fee is deducted from the build.

Running cost here is driven by tool calls as much as by tokens: an order-status answer that reads four systems costs more than a policy answer that reads one. Indexing recurs with catalogue churn, so the sprint models peak volume as well as median.

Part of the AI Feature Implementation Sprint → · Explore our work → · Discuss an AI project →