AI Agents for Ecommerce: Build an Order-Support Workflow

An AI agent that answers catalog questions and then guesses at shipping dates is not doing the job. A useful order-support agent reads the actual order: it finds the right record, checks whether a change is allowed, performs the change when it is, confirms the result, and hands off to a person when it cannot complete the task.

This guide walks a store operator through building that workflow, using Shopify as the worked example because that is where most documented native integrations live. The principles apply to any store that exposes order data through an API.

TL;DR: Start the agent with catalog and policy answers that need no customer data, then add order lookup with identity verification. Before enabling any order change, define the eligibility rules, the exact action the agent may take, and how the result is confirmed. Test with wrong, missing, and mismatched order IDs. Keep refunds and address changes with a person until you have verified the agent can complete them end to end. If an action is not confirmed by the order system, the agent must say so and escalate.

What an order-support agent must do

A customer asking "Where is order 18442?" cannot be answered from the help center. The agent has to call the order system, match the order to a customer, and read the current fulfillment state. If it cannot do that, it should say it cannot access the order and hand the thread to a person. A confident guess about a carrier is the failure that erodes trust fastest.

There is a meaningful difference between explaining a policy and executing a change:

• Informational answer: "What is your return window?" can be answered from a policy source.
• Operational request: "Cancel my order" requires permission, a valid order state, and a confirmed result from the order system.

Knowledge answers come from your trained sources. Order-specific answers and actions come from an authenticated connection to your store or fulfillment system.

Phase 1: Start with catalog and policy answers

The first deployment should cover questions that need no customer data:

• Product specifications, sizing, materials, and availability
• Shipping policy, return policy, and store hours
• Pre-purchase questions like "does this come in blue?"

These are safe to automate first; the risk is a wrong answer, not an unintended order change. A website chatbot that never sees Shopify is still useful for fabric, fit, and hours. Price it separately and do not let it promise a delivery date. The moment a customer asks about a specific order, the agent must call the order system or hand off.

Phase 2: Connect the order system

For order status and order changes, the agent needs access to live order data. Two approaches exist, and they are not interchangeable.

Native store integration. Several platforms ship prebuilt integrations. Chatbase's Hobby plan includes Shopify integration on its documented plan grid, though refunds and order edits depend on the plan and available actions. YourGPT documents a Shopify integration with built-in shopping actions: catalog search, product cards, product details, add-to-cart, and view-cart. These run only when the widget is deployed on a Shopify store with Agent Mode enabled. Order-status and returns capabilities appear on YourGPT's public homepage; that is a documented claim, not a setup guarantee. Verify behavior in your own store before relying on it.

Custom API work. If your platform lacks a native integration, you build a function or API call that defines the endpoint, parameters, and error handling. You gain full control, but you own authentication, logging, and failure recovery.

Either way, the connection must be authenticated and scoped. The agent should only read or change records belonging to the customer in the conversation. This is the core of order-support safety.

Setting up a Shopify connection

For a Shopify store, the current setup path is:

1. Create a custom app in the Shopify Dev Dashboard or with the Shopify CLI. Since January 1, 2026, new custom apps cannot be created in the Shopify admin; legacy admin-created token instructions are outdated for a new setup.
2. Configure Admin API scopes to the minimum needed for the actions you enable. Read-only order lookup needs fewer scopes than order editing.
3. Install the app on your store and obtain the access token. Store it securely server-side; it grants access to store administration.
4. Connect that token in your AI platform's integration settings.

Grant only what the workflow requires. A status-only agent should not have scopes that allow order edits. If you later add changes, grant the additional scope at that point. For customer-specific order data, prefer an authenticated customer session using an API that authenticates the buyer on their own behalf, such as Shopify's Customer Account API, rather than relying on a merchant-level token to identify the person in chat.

Phase 3: The order-status workflow

Build and test this loop first.

Step 1: Collect identity

Ask for the order number and the email or phone used at checkout. A typed email or order number is a lookup key, not proof of identity. The agent should match the order to an authenticated customer session or a server-validated identity flow, then authorize access to that specific order. Do not collect passwords, admin tokens, or one-time codes in chat; a secure login or verification screen should handle them. A guest lookup can send a secure link to the stored contact address without exposing records in chat.

Step 2: Look up the order

Call the order API. If the lookup fails, do not improvise. Say the order could not be found and ask the customer to check the number or confirm the email.

Step 3: Match the order to the customer

If the order belongs to a different account or email, that is a failed verification. Do not reveal another customer's order; state that access cannot be confirmed and escalate if the customer insists.

Step 4: Read and explain status

Pull fulfillment status, tracking events, and carrier information. Explain in plain language. If there is no tracking yet, say the order is still being prepared; do not extrapolate a delivery date from policy text.

Step 5: Confirm the answer

End with a confirmation prompt. Billing models define resolution differently: Gorgias counts an interaction as automated when the customer needs no human involvement within 72 hours; Intercom's Fin counts an explicit confirmation, a completed procedure, or a silent follow-up as an outcome. Check your vendor's definition when measuring resolution costs.

Worked example: "Where is my order?"

Customer: "Where is order 18442?"

Agent: "I can help with that. Could you confirm the email address used on the order?"

Customer: "jordan@example.com."

The customer completes an authenticated sign-in through a secure verification screen. The agent calls the order API with the customer's session, finds order 18442, and confirms it belongs to this account. It reads the fulfillment state and replies:

"Order 18442 is in transit. The last carrier scan was yesterday at 4:12 p.m. at the regional hub. The tracking number is 9410 1234 5678 9012 3456 78. Would you like the tracking link?"

That is a complete, verifiable answer. The agent did not guess, and it did not reveal another customer's data.

Failure condition: wrong order number

Customer: "Where is order 99999?"

Agent: "I can't find order 99999. Could you check the number on your confirmation email, or confirm the email on the order?"

The customer insists the number is right. The agent retries once, then hands off: "I'm connecting you with a person who can look into this." That handoff is the correct behavior. Do not let the agent invent a status for a number it cannot find.

Phase 4: Eligibility checks before any change

Before the agent changes an order, it must evaluate whether the change is permitted. Define rules explicitly per action:

• Cancellation: Is the order in a cancellable state? Many stores only allow cancellation before fulfillment begins.
• Return initiation: Is the item within the return window and in a returnable condition? Is a return label available?
• Address change: Has the order shipped? Carrier rerouting rules vary by service, destination, and dispatch state; check the specific carrier policy rather than assuming one rule.

Eligibility is separate from policy knowledge. A policy page may say "returns accepted within 30 days"; the agent must still check the order date and item state. Encode the checks as platform rules, for example: if fulfillment_status does not equal "unfulfilled", deny cancellation and explain why. In a visual workflow builder, put the same check at the top of the change flow.

Phase 5: Permitted changes and result confirmation

When a change is allowed, the agent performs the action through the order system, then confirms the result before telling the customer it happened. A confirmation is not the agent's own statement; it is the response from the system that performed the change. An API 200 or 202 response is not automatically a completed business action: read the operation state or the authoritative record, because asynchronous jobs can be pending or failed. On a timeout, inspect before retrying, and use idempotency or duplicate prevention so a retry does not create two changes. If the API returns success and the order record reflects the change, the agent can say the change was made. If the API returns an error or the record does not show the change, the agent must not claim success. It should explain the failure and either retry safely or escalate.

This distinction matters for reporting. A conversation that ends with the agent saying "I've cancelled that order" is not a resolution if the cancellation API failed. The action must succeed and be confirmed.

A minimal hypothetical API example

If you wire an order-cancel function yourself, here is a provider-neutral design you can adapt. This is pseudocode for a hypothetical application API, not a documented Shopify endpoint:

Endpoint: PUT /orders/{id}/cancel

Payload: { "reason": "customer_request" }

Responses:

• 200 with a confirmed order state: cancellation confirmed. Tell the customer the order is cancelled.
• 202 with a pending job: say the request is processing, then re-check the order record before confirming completion.
• 409: order not cancellable. Explain the order state and route to a human if the customer wants an exception.
• 401/403: permission or token problem. Attempt no further changes; escalate.
• 5xx: server error. Say the system is unavailable and offer to retry or hand off.

Map each response to an agent message in your platform and log every attempt. Never treat a timeout as success.

Worked example: an address-change exception

Customer: "I need to change the shipping address on order 18442. I'm moving."

The customer signs in securely, and the agent looks up the order and checks fulfillment state. The order has already shipped; the carrier cannot reroute. The agent replies:

"Order 18442 was shipped on March 2 and is already with the carrier, so I can't change the delivery address. What I can do is share the carrier's contact details so you can request a reroute or hold for pickup. Would that help?"

The agent does not attempt the change because it is not eligible. It has explained why and offered the next legal step. If the customer wants a replacement or refund, the agent sends that to a human.

Now consider the opposite case: the order is still unfulfilled, and the store allows address edits before fulfillment. The agent updates the shipping address through the order API, confirms the API response and the updated order record, and then tells the customer the new address is saved. If the API returns a validation error, the agent says the change could not be saved and provides the specific error.

What to keep with a human

For a first deployment, keep refunds, replacements, and address changes with a person. Refunds involve payment states, authorization, and confirmation of funds received; Shopify keeps order status and payment status separate, so a cancelled order can still have refund work remaining. Address changes interact with carrier rules that vary by destination, service, and dispatch state. Discretionary credits and policy overrides require judgment an agent should not invent.

Expand authority one action at a time after verifying each action in your own store. A successful product lookup does not prove refunds are ready to run without review.

Native store features versus custom API work

Be precise about what a platform can do out of the box. Native catalog actions such as product search, product cards, and add-to-cart are documented and generally safe to deploy with the correct configuration. Native order status depends on the platform's integration depth, so verify that the agent actually queries live order data rather than answering from training text. Order-changing actions such as cancellation, returns, and address edits are the highest-risk tier; some platforms document them, some require custom API functions, and some do not support them on a given plan.

Check the platform's current documentation for the specific action, then test it in your store. Do not assume a feature exists because a vendor mentions order support on its homepage. Setup and permission verification are part of the deployment.

Testing and rollout checklist

Run these cases before widening scope:

1. Correct order, correct authenticated customer (happy path)
2. Wrong order number: agent must not invent a status
3. Missing order number: agent must request it
4. Order belongs to a different account: agent must not reveal the order
5. Order in a non-cancellable state: agent must decline and explain
6. API returns an error on a change: agent must not claim success
7. API returns a timeout: agent must inspect the order state before retrying
8. Customer asks for a refund: agent must hand off, not improvise

Read every transcript where the order ID was wrong, missing, or mismatched. That case set is your test. If the agent fails any of them, fix the workflow before you widen scope.

Gorgias's demo video is useful for seeing the interface and the conversation shape. Use it to understand the screen, then run the bad IDs yourself. A vendor demo is not a substitute for your own failure testing.

Billing and cost expectations

Cost models vary by platform, and the units are not interchangeable across vendors.

Gorgias uses a ticket-plus-outcome model: a fee for each billable helpdesk ticket, plus an outcome-based automation fee when AI Agent resolves a ticket without handing over to a human. The pricing page says AI Agent is on every plan, you pay when it resolves a conversation, and helpdesk scales from 50 to 5,000 tickets monthly without per-agent pricing. Billing docs define an automated interaction as one where the customer needs no human involvement within 72 hours. The exact figures for your store require a quote or plan selection; published per-interaction rates vary by tier and plan type, and older blog rates may not match current contracts.

Other platforms use different units. YourGPT uses AI credits consumed by model and workload; Chatbase uses message credits; Tidio bills human conversations and Lyro conversations separately; Freshdesk includes the first 500 Freddy sessions on Growth, Pro, and Enterprise plans then charges $49 per additional 100. Do not compare a resolution from one vendor with a message credit from another. Decide which outcome you are paying for, then check that vendor's billing definition.

For tool selection and a full comparison, see the ecommerce AI support hub, which covers the platform shortlist, plan structures, and decision criteria in depth. The AI customer service software for ecommerce article is the broader directory. If your team already lives in Zendesk, Intercom, or Freshdesk, compare those seats in the help desk comparison before opening a second inbox.

Conclusion

The central design decision for an ecommerce AI agent is not which model to choose; it is what the agent is allowed to do with order data. Catalog answers can go live quickly. Order lookup is safe once identity verification is correct. Order changes hold the real risk and value, and each deserves its own eligibility rule, test, and confirmation path.

Build in this order: answer, look up, verify, check eligibility, act, confirm. When you cannot complete a step, hand off. That sequence keeps the agent useful without letting it fabricate outcomes and gives your team a clear, auditable boundary.

FAQ

What is a good first workflow to automate for ecommerce support? Order status and shipping policy are practical starting points. They require live order data but carry lower risk than refunds or address changes. Test the lookup with wrong, missing, and mismatched order IDs before going live.

Can an AI agent cancel or refund orders? Yes, if the platform supports the action and you enable it with proper permissions, eligibility rules, and confirmation checks. A cancellation or refund is only complete when the order system confirms it succeeded. Most stores should start with human handling for refunds and expand after verifying the agent in their own store.

How does an agent verify it is talking to the right customer? A typed email or order number is a lookup key, not proof of identity. The agent should rely on an authenticated customer session or a server-validated login flow, then authorize access to the specific order. If the order belongs to a different account, the agent must not reveal order details and should escalate if the customer persists.

What should the agent do when an order lookup fails? It should say it could not find the order, ask the customer to verify the number or email, and retry once. If the lookup still fails, it hands off to a person. It must never invent a status for an order it cannot find.

Why keep address changes with a human? Because carrier rerouting rules vary by service, destination, and dispatch state. An address change on a shipped order usually cannot be completed by the store at all. Until you have verified that your platform and store can perform this action reliably, a human is the safer owner.

Do I need custom API development for order support? Not always. Several platforms ship native Shopify integrations with documented order and catalog actions. Custom API work is needed when the specific action you want is not available natively or when you need full control over authentication and error handling. The body of this guide covers both paths and how to test them.