A practical guide to order-status answers, return requests and human handoffs, with identity checks, permission boundaries and an honest support-cost example.
Auteur
Anichur Rahaman
Imagine a support lead opening 410 unread tickets after a long sale weekend. In a fictional sample of twenty, fourteen ask “Where is my order?”, three concern jacket sizing, two ask for a return and one reports a possible duplicate charge. This is a teaching scene, not a survey or a customer result.
The queue contains different needs, not just repeated sentences. A parcel question may involve the wrong account or a missed promise. The payment complaint may be two pending authorisations rather than two captured payments. Speed helps only when the answer is both permitted and supported by evidence.
A useful AI assistant retrieves verified facts, explains their limits and makes it easy to reach an accountable person. This guide shows how to design that service without treating a fluent answer, an automatic closure or a low-value refund as proof of safety. Reviewed on 4 November 2026.
Classify tasks by the data they expose, the action they trigger and the consequence of a mistake. Even a read-only lookup can disclose an address or another customer’s purchase. The following lanes are a starting design, not universal permission to automate.
| Lane | Examples | Boundary |
|---|---|---|
| Scoped factual reply | Published product facts, approved policies, the verified customer’s order status | Use current sources and minimal fields; never invent fit, eligibility or delivery guarantees. |
| Bounded workflow or draft | Return intake, address-change proposal, cancellation request | Validate identity, state and policy on the server. Obtain the approval required for the actual action. |
| Authorised human decision | Disputed charges, uncertain rights, damage claims, identity recovery or requested escalation | Route to someone with authority. AI may summarise permitted facts, not settle the dispute. |
A static FAQ can explain standard shipping terms; it cannot locate a particular parcel. Ground the reply in the relevant order and courier record. Keep “last scan”, “current verified state”, “carrier estimate” and “customer promise” distinct. A fresh event is evidence, not a delivery guarantee.
For example, if the last scan was 31 hours ago, say when and where that scan occurred if disclosure is permitted. Check your carrier-specific freshness rule and refresh if appropriate. Do not turn an old “in transit” event into “arriving tomorrow”, or assume a 24-hour threshold suits every route.
Keep request, authorisation, label, receipt, inspection and refund as separate states. The assistant can collect a reason and prepare a request without promising that the claim is accepted. Check ownership, quantities, existing requests, relevant delivery dates and the applicable policy version.
A store’s “30 days, unworn, original packaging” rule is an example of commercial policy, not a universal statement of customer rights. Category exclusions and damaged-item claims need the applicable legal and contractual rules. An uncertain or failed automated check should offer a review route, not a final refusal.
Issue a label only through an authorised workflow. Refund authority, payment state, amount, currency, duplicate protection and an audit record still matter; a value cap alone is insufficient. Do not claim every refund must wait for warehouse receipt. Timing depends on the applicable obligations and approved process. For an exchange, confirm stock and reserve it at the authorised stage.
The following numbers are invented assumptions in generic currency units, not vendor prices or industry benchmarks. Use one defined cohort of 6,000 unique support cases. An approved draft, return request or automatic closure is not counted as an independently resolved case.
| Intent | Cases | Assumed AI resolution | AI-resolved cases |
|---|---|---|---|
| Order-status enquiry | 2,100 | 70% | 1,470 |
| Return or exchange request | 900 | 0% | 0 |
| Product and size facts | 900 | 70% | 630 |
| Cancel or change address | 480 | 0% | 0 |
| Refund dispute or damage | 900 | 0% | 0 |
| Account, rights and other | 720 | 0% | 0 |
| Total | 6,000 | 35% | 2,100 |
| Cost line | Calculation | Units |
|---|---|---|
| Before: allocated human handling | 6,000 × 4 | 24,000 |
| After: intake and AI attempts on all cases | 6,000 × 0.10 | 600 |
| After: extra workflow cost for AI resolutions | 2,100 × 0.30 | 630 |
| After: remaining human work | 3,900 × 5 | 19,500 |
| After: quality review and operations | 1,000 | 1,000 |
| After: total | 600 + 630 + 19,500 + 1,000 | 21,730 |
Assume 70% resolution for order-status and product-fact cases only: 1,470 + 630 = 2,100, or 35% of the cohort. The other 3,900 remain human-handled, including cases with AI assistance. These rates must be measured, not borrowed as targets.
The baseline allocation is 4 units per case. Remaining human cases are assumed harder, at 5 units each. The 0.10 intake/AI-attempt allowance covers every case, including failed attempts and drafts; the extra 0.30 applies only to successful automated workflows. Avoid double counting actual supplier fees.
The example totals 21,730 versus 24,000: a reduction of 2,270 units, about 9.46%, with an average 3.62 units per case. That is an allocation comparison, not a promise of cash savings. Fixed salaries may stay unchanged; include your setup, integrations and ongoing governance when assessing the full investment.
A smaller queue does not prove a shorter wait. Arrival patterns, staffing, priority and the complexity of remaining work determine response times. Measure the human queue separately; do not infer that five hours becomes two.
Give each workflow only the records, fields and actions it needs. Treat chat text, attachments and retrieved notes as untrusted content, not instructions granting new permissions. Keep secrets and unrelated orders out of prompts. Log access and decisions without retaining unnecessary personal information; define retention and provider data-use settings.
OWASP’s Excessive Agency guidance recommends minimal permissions, user-scoped tools and approval for high-impact actions. Apply those controls outside the model.
After a write timeout, check the existing request reference before repeating it. Use duplicate protection for labels, cancellations and refunds. A polite retry must not create a second transaction. Make escalation reachable without requiring the customer to use a particular angry keyword.
Use a visible AI label and a plain first message: “I’m the store’s AI assistant. I can check permitted order information. Ask for a person at any time.” Show real staffed hours and a contact or ticket route; do not promise instant human availability when none exists.
EU Article 50(1) places direct-interaction disclosure duties on providers, subject to scope and exceptions. The Commission states transparency duties apply from 2 August 2026. See the Article 50 text and Commission guidance.
Assess the business’s provider/deployer role, territorial scope and other applicable duties for the actual service. A label does not replace privacy, security or consumer obligations. Do not assume that every overseas seller has identical duties, or that a disclosure alone makes the assistant compliant.
Back in the fictional Monday queue, a useful assistant has not magically erased half the tickets. It can show a permitted parcel fact, mark an uncertain estimate and route the possible duplicate charge for payment verification. The support lead sees what is known, what still needs a decision and who owns the next step. That clarity is the service improvement worth earning.
Anichur Rahaman is the creator of StoreConsole. This guide presents operational design choices; its story and financial model are illustrative.
À propos de l'auteur
Anichur Rahaman
Continuer la lecture
