AI support works when it answers from live order and courier data and hands off with context. See which intents to automate, how a WISMO answer is built, a worked cost example, EU disclosure rules and a rollout plan.
Author
Anichur Rahaman
The support lead of a mid-sized online store opens twenty tickets at random from an inbox of 410 unread, at 7:50 on the Monday after a long weekend sale. Fourteen say some version of "where is my order?". Three ask whether a jacket runs small. Two want to return something. One is from a customer who has been charged twice and is not polite about it.
Fourteen of those twenty need a lookup, not a conversation. The one angry customer needs a person, quickly, and she is buried under the lookups.
This article is about drawing that line on purpose. AI customer service works in 2026 when it answers from live order and courier data, acts only inside written policy, and hands over to a human with the full story attached. It hurts when it improvises about money, rights or feelings. Below: which intents belong on which side, how a "where is my order" answer is built, a worked example with the arithmetic, the disclosure rules, and a rollout plan.
The useful split is not "simple versus complex". It is whether the answer already exists in your systems. "Where is my order?" (the support industry calls it WISMO) is answered by a row in your order table and a status from the courier. Nobody needs to decide anything. The machine only has to fetch, check and phrase.
Returns inside the policy window work the same way. The rule is written down (30 days, unworn, original packaging), the order date is in the database, and the outcome is a return authorisation and a label. Product questions are grounded in the catalogue: sizes, materials, stock by variant.
The damage happens at the other end. A refund outside policy is a decision about money. An angry customer needs acknowledgement before information. A question about consumer rights is a legal question. An account change, such as a new email or phone number, is an identity question. In each case a wrong answer is expensive and a fluent wrong answer is worse, because it sounds like a promise.
That last risk is not hypothetical. In Moffatt v. Air Canada (2024), a British Columbia tribunal held the airline responsible for wrong bereavement-fare advice from its website chatbot and ordered it to pay $812.02, rejecting the idea that the bot was a separate party. Whatever your assistant says in your name, you said.
Sort every intent your store receives into one of three lanes before you configure anything. The sorting is the real design work. Software settings follow from it.
| Lane | Typical intents | What the AI may do | Failure cost |
|---|---|---|---|
| Auto-answer | Order status, delivery estimate, return policy, product and size questions | Read data, reply, start an in-policy return | A wrong sentence, easy to correct |
| AI with approval | Exchanges, address change before dispatch, cancellation, goodwill vouchers | Prepare the action; a person approves it | A wrong parcel or a wrong credit |
| Human only | Refund outside policy, damaged or missing goods claims, angry or vulnerable customers, legal and account-identity questions | Summarise and route; never decide | Money, trust or a legal exposure |
The lanes map onto the same ladder used for back-office agents: reading is safe, drafting is reviewed, acting on money is gated. If you want the longer argument, AI agents in the ERP: what they can safely do walks through it.
Most disappointing support bots were built on a document: the FAQ, the shipping policy, a few past replies. A customer asking where parcel 10482 is gets a paragraph about delivery times. The bot cannot see parcel 10482, so it answers the question it can answer, not the one asked.
The fix is grounding on live data. The assistant is given two read-only tools, one that fetches an order by number plus a matching email or phone, and one that fetches the courier status for that order's parcel. It writes the reply only from what those tools return. If a tool returns nothing, it says so and hands off. It is never allowed to fill the gap from memory.
The second ingredient is freshness. A courier status is a fact with a timestamp. If the last scan is 31 hours old, "your parcel is on its way" is a guess. The flow below treats a stale status as a reason to check or escalate, not to reassure.
Every step in this flow is a question the code can answer without a language model. The model's job is the last mile: turning the verified facts into a plain, polite message in the customer's language.
The hand-off is where most of the customer experience is won. A person who opens a ticket and sees "Parcel 10482, promised 14 Aug, last scan 16 Aug in the sorting hub, customer asked twice, tone: frustrated" can write one useful reply. The same person facing a raw chat transcript starts from zero.
A return is a short state machine: requested, authorised, label issued, received, inspected, refunded or exchanged. The AI can safely own the first three steps when the policy is expressed as checks the system can run, not prose it must interpret.
If every check passes, the assistant creates the return request, issues the label and explains the next steps. If one fails, it does not argue. It explains the rule once, offers a human review, and routes the ticket with the failed check named. The refund itself stays behind approval or, at minimum, behind a value cap, and it fires only after the warehouse has marked the item received.
Exchanges sit one lane higher because they touch stock. The assistant can prepare the exchange (size M for size L, stock available at the shipping location), and a person confirms.
The numbers below are illustrative, built to show the arithmetic. Your mix will differ, so replace them with a month of your own tagged tickets.
| Intent | Tickets | AI resolves | Resolved by AI |
|---|---|---|---|
| Where is my order | 2,100 | 85% | 1,785 |
| Return or exchange start | 900 | 60% | 540 |
| Product and size questions | 900 | 70% | 630 |
| Cancel or change address | 480 | 25% | 120 |
| Refund disputes and damage claims | 900 | 0% | 0 |
| Account, legal and other | 720 | 0% | 0 |
| Total | 6,000 | 51% | 3,075 |
Now the cost. Assume a human-handled ticket costs $4.00 all in (about seven minutes of a loaded agent hour plus tooling) and an AI-resolved ticket costs $0.45 (model usage, order lookups, platform fee). Both figures are assumptions for the example.
First-response time shows the second effect. Assume the same team and a median first response of 5 hours before. The AI answers its 3,075 tickets in under a minute. The human queue shrinks from 6,000 to 2,925 tickets, so the median wait for those drops to roughly 2 hours. The saving matters less than the angry customer from the opening, who now reaches a person in the morning, not in the afternoon.
Permissions come first. Give the assistant read access to orders, parcels, the catalogue and the policy, and write access only to narrow actions: create a return request, add a note, route a ticket. Anything that moves money or edits a customer profile goes through an approval step with a log entry, as described in AI guardrails: approvals, audit trails and human in the loop.
Language is the quiet advantage. A store with customers who write in three languages usually staffs one. An assistant grounded on the same order data can answer in the customer's language, which is a real service improvement. Have a native speaker review a sample of replies each month; machine fluency hides small errors of politeness and register.
Tone rules should be short and testable: apologise once, state the fact, state the next step, give a date. Ban promises the system cannot keep ("it will arrive tomorrow") unless the date came from a tool. When the customer shows anger or uses words such as "lawyer", "chargeback" or "scam", the assistant stops and escalates. A bad day does not need a chatbot.
Tell customers when they are talking to a machine. It is good practice everywhere, and in the European Union it is law. Article 50 of the EU AI Act requires providers of AI systems that interact directly with people to design them so the person is informed it is an AI, unless that is obvious from the circumstances. The transparency obligations of Article 50 apply from 2 August 2026. The EU's digital omnibus delayed the high-risk system rules, but Article 50's disclosure duty was not moved; only a short grace period for machine-readable marking of generated content runs to 2 December 2026, and that part concerns synthetic media, not chat.
Practically: a visible label on the chat widget, a first message that says so, and a one-click path to a human. Keep the wording plain ("I'm an AI assistant for the store. I can check orders and start returns. Ask for a person any time."). If you sell into the EU from elsewhere, treat this as applying to you, and check your national rules with counsel. Details are in the AI Act text on EUR-Lex.
Start narrow and widen as the data says you can. A helpdesk that keeps tickets, order context and AI replies in one place makes this easier; StoreConsole's AI assistant is one example of an assistant that reads live store data. Whatever you use, the order is the same.
Deflection alone is a vanity number. A bot that makes customers give up also "deflects". Track these together:
Return to the 410 unread tickets. With the lanes in place, roughly half of them were answered before she opened her laptop: order status, size questions, in-policy returns. The remaining ones are sorted, and each arrives with its order, its courier trail and a one-line summary. The customer charged twice is at the top of her list, with the duplicate payment already highlighted.
She spends her morning on refunds, repairs and people. The assistant spent its on lookups. Neither is doing the other's job.
Anichur Rahaman is a software architect and the creator of StoreConsole. He designs commerce and ERP systems for growing businesses, with a focus on event-driven architecture, data integrity and self-hosted operations.
About the Author
Anichur Rahaman
Continue Reading
