AI Customer Service for Ecommerce: Orders, Returns, Tracking

AI Customer Service for Ecommerce: Orders, Returns, Tracking

AI customer service for ecommerce can answer on its own the questions that depend only on published rules, such as the return window, accepted payment methods and how to follow a delivery. Questions about a specific order, like status and tracking, work well when the AI queries your systems with narrow, read-only permissions. Exceptions, money and conflict with the customer should go to a person, with the context already summarized.

Key takeaways

• The useful split is not by topic. It is by how much order data and how much decision power each request requires.
• For policy questions (deadlines, shipping, payment), the AI answers from approved text without touching customer data.
• Tracking and order status require a system lookup and an identity check before any answer.
• Exchanges, returns and refunds have an automatable part (collecting details, opening the request) and a human part (exceptions, approval, amounts).
• A pilot with a single flow, a record of every decision and a well-defined handoff to a human reduces the risk of making mistakes at scale.

Why to sort requests by access level, not by topic

It is common to organize support by theme: delivery, returns, payment, product. To decide what the AI handles alone, that split helps very little, because inside every theme there are easy questions and dangerous ones. Knowing the cancellation window is one thing. Approving a return after the deadline is another, even though both are about returns.

A more useful split looks at three things. Does the AI need customer data to answer? Does the answer create an obligation for the store (money, shipping, cancellation)? Is there room for judgment, or is the rule objective? The combination of those answers defines the level of autonomy.

This follows a principle Anthropic describes in its guidance on building effective agents: start with the simplest flow that solves the problem, and add autonomy only when it is needed and when there is a way to verify the result. It is a useful reference for anyone who wants to understand the difference between defined workflows and agents with more freedom.

What the AI can resolve alone, without looking up the order

The first group is made of questions whose answer lives in the store's policy and does not change from customer to customer. The AI only needs a knowledge base of approved text that is current and has a named owner. Examples:

• Return and exchange deadlines and conditions, as set in the published policy.
• Accepted payment methods and how the store's installment plans work.
• How customers can track an order (where to find the code, which channel it arrives in).
• Product information already in the catalog: measurements, materials, compatibility.
• Business hours for human support and how to reach a person.

The risk here is not a data leak. It is an outdated answer. If the return policy changed and the knowledge base did not, the AI will confidently say something wrong. So the first job is to define who updates the base and when, and to make the AI cite the rule it used, which makes review easier.

If the question is not covered by the base, the correct behavior is to say it does not have the information and offer a handoff. Inventing a plausible answer is the most expensive mistake in this group.

What the AI resolves after checking the order: status and tracking

The second group is questions about a specific order. Here the AI stops being a question-and-answer assistant and starts using tools: a lookup in the store platform, the ERP or the carrier's system. Typical cases:

• Where is my order?
• Was my payment confirmed?
• What is the tracking code and the estimated delivery date?
• Has the invoice been issued?
• Can I change the address before shipping? (the lookup is automatic, the change depends on the order status and the store's rules)

For this group to work, three safeguards matter more than the model you choose.

First, the lookup tool should be narrow: find an order by number, return only the necessary fields and never allow listing other customers' orders. Anthropic publishes practical guidance on designing tools for agents, with a focus on clear names, lean responses and error messages that help the agent correct its path.

Second, the AI must report what the system shows without filling in gaps. If tracking has no recent update, the correct answer is to say so and explain what the store will do about it, not to promise delivery tomorrow.

Third, access should be read-only. Any action that changes the order belongs to a different level, discussed below.

Returns, exchanges and refunds: where the decision becomes human

Returns and exchanges mix mechanical steps with judgment steps, and it helps to separate them.

The part the AI usually handles well is intake: confirming the order, asking for the reason, requesting a photo when the policy requires it, checking whether the item is within the deadline and logging the request in the system. At this stage the AI builds the case and cuts down the back and forth.

The part that needs a human decision shows up when:

• The order is outside the deadline, but the customer claims a problem.
• The product arrived defective or damaged and the photos need to be assessed.
• The customer asks for a refund in a different form than the original payment.
• There is suspicion of fraud, misuse or a history of disputes.
• The customer has already shown irritation or threatens to contact a consumer protection agency.

The central point is that the AI can propose, but approval of a refund, cancellation or exception follows an explicit authority rule. A clear approval policy prevents the agent from making decisions nobody delegated. See the template in AI Agent Approval Policy, which lays out what an agent does alone, what it proposes and what requires authorization.

A conservative and common way to start: the AI opens the exchange request when it is within the deadline and the objective rules, and any refund, exception or defect case goes to the human queue with a ready-made summary.

Decision guide: who resolves each type of request

A practical way to apply all this is to classify each type of request into four levels. Each store should adjust the list to its own operation, but this structure works as a starting point.

• Level 1, direct answer: policy, product and general deadline questions. The AI answers from approved text and cites the rule. No access to customer data.
• Level 2, lookup with confirmed identity: status, tracking, invoice, delivery estimate. The AI reads the order in read-only mode after confirming who the customer is.
• Level 3, action within an objective rule: opening an exchange request within the deadline, resending a copy of a document, logging a complaint. The AI performs a reversible action and records everything.
• Level 4, human decision: refunds, deadline exceptions, defects, fraud, cancellation after shipping, a customer in conflict. The AI summarizes the case and hands it off.

A simple rule for classifying a new type of request: if it involves money, an exception or legal risk, it is level 4. If it requires customer data, it is at least level 2. If the answer exists in approved text, it is level 1.

The handoff to a person deserves its own design. WhatsApp AI Agent Human Handoff details what to send to the agent, when to trigger the handoff and how to keep the customer from repeating everything.

Illustrative scenario: a tracking conversation that changes level

Imagine a fictional cosmetics store that handles support on WhatsApp. A customer writes: my order has not arrived.

The AI asks for the order number and a second confirmation detail defined by the store. With identity confirmed, it checks the system, sees the status as in transit with the carrier's last update, and shares the recorded delivery estimate along with the tracking link. This is a level 2 case, resolved without a person.

In another conversation, the carrier's system shows the order as delivered, but the customer says nothing arrived. There is no objective rule the AI can apply: it could be a drop-off at the building desk, a wrong address or a real problem. The AI records the customer's account, attaches the tracking data and the delivery address, and hands off to an agent with a short summary: what the customer said, what the system shows and what is still to be checked. A person decides whether to open an investigation with the carrier or reship the product.

The same topic, tracking, landed on two different levels. That is why classifying by topic is not enough.

Identity, personal data and privacy law in order support

An ecommerce order contains a name, address, phone number and purchase history. Any AI flow that reads this data needs access rules before anyone thinks about answer quality.

Some control points that apply to most stores:

• Confirm identity before revealing any order data. An order number alone is usually not enough, because third parties may know it.
• Return to the conversation only what is necessary. To share tracking, there is no need to show a tax ID or the full address.
• Apply the principle of least privilege to the credential the AI uses. The OWASP Authorization Cheat Sheet is a concise reference on how to think about authorization and deny by default.
• Log every lookup and every action, so you can reconstruct what the AI saw and answered.
• Define the legal basis, the notice to the data subject and the retention of conversation history with legal support. The article LGPD Compliance for AI on WhatsApp covers legal basis, consent and records under Brazil's data protection law, and the national data protection authority (ANPD) publishes official guidance.

It is also worth remembering that customer messages are untrusted input. A customer can, on purpose or by accident, write something that tries to change the AI's behavior, such as asking it to ignore rules or show another order's data. The defense is not only in the prompt text but in permissions: if the tool cannot look up another customer or approve a refund, the malicious request has no way to work.

How to pilot without risking operations: map, limit, pilot, hand off

The method we apply in support projects follows four moves, adapted here to ecommerce.

• Map: collect the real requests from the past few months, group them by type and classify each group into the four levels. Also record current response time and volume to have a baseline.
• Limit: define which data the AI can read, which actions it can perform and which words or situations force a handoff. Start with read-only access.
• Pilot: choose one flow, for example status and tracking, and run it with a group of customers or during limited hours, with a record of every decision and a success metric agreed beforehand.
• Hand off: make sure the agent receives the case with a summary, and that the customer knows when and why they are talking to a person. After the pilot, decide whether to expand, adjust or stop.

Metrics and decision criteria are covered in How to Measure an AI Automation Pilot. In customer service, measure not only how many conversations the AI closed, but how many were resolved correctly, how many reopened and how many handoffs arrived with enough context.

If WhatsApp is your main channel, the choice between the official API and the app, the integration with the store system and the design of the messages also affect the result. The guide How to Integrate AI into Your Company's WhatsApp covers those implementation points.

Frequently asked questions

Can the AI answer tracking questions without accessing the store system? It can explain how tracking works and where the customer finds the code, but it cannot report the status of a specific order without querying the system. Answering without the lookup leads to invented or outdated information. If the integration does not exist yet, the better path is to guide the customer and hand off.

Can the AI approve exchanges and refunds on its own? In general, it should not at the start. It can collect the details, check the deadline and open the request within objective rules, but approval of amounts and exceptions works better with a person or with a written, tested authority rule. After a well-measured pilot, the store can decide to extend autonomy in low-risk cases.

Where should an ecommerce store start automating customer service? With the status and tracking flow, because it has high repeat volume, an objective answer and low risk when the AI only reads data. Before that, map the real requests, define the identity check and agree on the success metric. Only then move on to exchanges and other actions.

What should happen when the AI does not know the answer? The rule should be set from day one: admit it does not have the information, do not invent an answer, and hand off to a person with a summary of the conversation. These cases are also useful for improving the knowledge base, so review them regularly and decide whether they become a new approved answer or remain a human decision.

Sources

• Anthropic: Building effective agents
• Anthropic: Writing effective tools for agents
• OWASP: Authorization Cheat Sheet
• ANPD: Autoridade Nacional de Proteção de Dados