The specific pain: a bot that answers is not a bot that resolves
A macro can paste a tracking link. A help-centre article can explain the returns window. Neither one checks whether this customer's order is actually late, whether this specific item is inside the exclusion list, or whether the size the shopper is asking about is actually in stock right now. So the ticket "resolves" on the surface and reopens two days later as a second contact, a chargeback, or a one-star review that mentions how unhelpful support was.
The underlying problem is not tone or response time. It is that a keyword-matching bot has no access to the systems that hold the real answer. It is guessing politely. An agent built for this work is wired into the order management platform, the carrier feed, the policy rules, and the catalogue, so what it tells a customer is what is actually true — and when it cannot verify something, it says so and hands off rather than guessing with confidence.
What the agent does, day to day
Before any conversation happens, the agent has to know who it is talking to. Every inbound message — email, chat widget, marketplace message, a call routed through voice AI — gets matched to a real customer record using the order number, the email on the account, or the phone number on file. No match, no guessing: the agent asks for the one detail it needs rather than inventing an answer against the wrong order.
From there the daily work breaks into five recurring jobs:
- WISMO. Pull live tracking and fulfilment status, translate carrier jargon into a plain answer, and tell the customer where the package actually is.
- Returns and exchanges. Check the request against the written policy — window, condition, category exclusions — and move it forward without a person re-reading the policy document every time.
- Pre-purchase questions. Answer sizing, compatibility, and stock questions from the live catalogue, in the moment a shopper is deciding whether to buy.
- Escalation judgement. Recognise when a ticket is not really about one order — it is the fourth complaint this week about the same SKU — and route that pattern to a person instead of closing four tickets as four unrelated ones.
- Handoff. Anything genuinely ambiguous, anything a customer is upset about, and anything that touches money gets handed to a person with the order history and the agent's own reasoning already attached, so nobody starts the conversation from zero.
None of this replaces a support team. It removes the part of the job that is purely lookup-and-repeat, so the people on your team spend their day on the tickets that actually need a human's judgement.
Walkthrough: a package stuck in transit
A customer emails "where is my order, it's been six days." Here is what the agent actually does, step by step.
- It matches the email address to the order, and if more than one order exists on the account, it checks which one the message is about rather than assuming the most recent.
- It pulls the live fulfilment status from the order platform and cross-checks it against the carrier's own tracking feed — the two do not always agree, and the carrier feed is the one that is right.
- If the package is genuinely in transit and on schedule, it replies with the real delivery window and the tracking link, in plain language, and closes the ticket. No person touches this case.
- If the carrier feed shows the package has stalled, been marked delivered when the customer says it was not, or is running past its delivery estimate, the agent does not guess at a fix. It drafts a summary — order details, carrier status, how long it has been stalled — and routes it to a person, because the next step usually involves a replacement, a carrier claim, or a refund, and any of those touching money or a new shipment goes through the approval rule a human set, not a decision the agent makes alone.
The customer gets an answer either way, in minutes rather than whenever the queue gets to them. The exceptions land on a person's desk already investigated instead of already three days old.
Walkthrough: a return that should really be an exchange
A customer emails wanting to return a jacket because it runs small.
- The agent identifies the order and checks the return request against policy: is the item inside the return window, is the category eligible, is it in the condition the policy requires.
- Because the reason given is sizing, it checks live stock for the next size up before replying, and offers the exchange path alongside the return path — the option a customer actually wants is often not the one they typed first.
- If the customer takes the exchange, the agent generates the return label, reserves the replacement item so another sale cannot take it in the meantime, and sends confirmation with both the label and what happens next.
- It tracks the return shipment and updates the customer when the warehouse scans it in.
- Completing the exchange — releasing the new item — is a straightforward policy match and the agent finishes it. But if the customer instead wants a cash refund to the original payment method, that step stops for human approval before anything is issued, unless the business has explicitly set a threshold below which the agent may approve refunds on its own. That boundary is a policy your team sets, not a default we assume.
Walkthrough: a sizing question, and a pattern worth noticing
A shopper messages on Instagram DM asking whether a dress runs true to size and whether it is in stock in a size 10. The agent checks the live catalogue and inventory, answers directly — sizing notes plus current stock, not a generic "check our size chart" — and offers to send a discount code only if that is a rule the brand has actually configured, never invented on its own.
Separately, and this is the judgement call a keyword bot cannot make: the agent is also watching volume across tickets, not just handling them one at a time. When five customers in three days describe the same SKU's zipper failing, a script would log five independent returns. The agent recognises the shared pattern — same product, same defect, tight time window — and raises it as a single flag to whoever owns product quality, with the five tickets attached as evidence, instead of quietly processing five refunds and letting the underlying defect ship to the next hundred customers unnoticed.
Where it connects
The agent sits inside the tools you already run rather than replacing any of them. If your storefront is Shopify, order, customer, and inventory data comes from there directly. If you sell through Amazon or another marketplace, the agent works inside that platform's own messaging and policy rules rather than around them. If your support queue lives in Gorgias or Zendesk, tickets are handled inside that queue, not a second inbox your team has to also check. If lifecycle email runs through Klaviyo, order and return status can flow back so a win-back email is not sent to someone mid-dispute over a broken zipper. These are named as integration examples of systems we connect to — not as partnerships, and not as certifications we hold.
Where a platform has no clean API, there is usually still a route in: a scheduled export, a webhook, a database connection. Older order-management tools are common in ecommerce operations, not a blocker to building this.
Every action the agent takes is logged — what it decided, what it checked, why — so a return processed on a Tuesday can be explained on a Friday. That logging, combined with the approval rules, is what human-in-the-loop actually means in a support agent: not a person reviewing every message, but a person holding the decisions that carry real consequence. If you want the fuller picture of how an agent reasons through a task in general, the custom AI agents overview and the plain-language agent definition cover the mechanics without the ecommerce specifics this page adds. For the wider set of problems ecommerce teams bring us — catalogue data, inventory signals, supplier chasing — the ecommerce AI overview is the page one level up.