Claude for your online shop: Shopify and WooCommerce, run from your back office

This guide explains how to use Claude for your online shop: Shopify and WooCommerce stores alike. It focuses on the work that fills a small shop's inbox every day: order status questions, returns and product questions. The approach is to connect the shop's order data to a Zoho back office and let Claude work there. You do not add yet another chatbot plugin to the storefront.

Claude is an AI assistant. It reads text, reasons over it and writes answers. On its own it knows nothing about your orders. Once it can read your shop's data and your written rules, it can answer the question a customer actually asked. That might be "Where is my parcel?" or "Can I swap this for a larger size?"

The guide is written for owners and managers of shops that already trade. You have a storefront that works, a team that answers email, and some mix of helpdesk, stock and accounts tools behind it. You will get definitions first. Then comes what Shopify and WooCommerce offer according to the sources, one worked example, a table of who does what, the rules your shop must write down, and what this means for a UK business.

The aim is a decision you can make this month. The storefront stays as it is. Claude goes to work behind it.

Five terms come up throughout this guide. Each one is defined here in plain words so the rest reads easily.

• Connector. A ready-made link that lets Claude read data held in another system. According to a LinkedIn post on the launch, Shopify shipped a Claude connector that gives an AI agent direct access to a store's catalogue, orders, inventory, customers and analytics.
• MCP server. A small service that exposes a system's data and actions to Claude in a consistent way. Where no ready-made connector exists, an MCP server is how you build one. Our step-by-step guide to connecting Claude over MCP shows the setup in detail.
• Back office. The systems behind the shop window. These are your helpdesk, for example Zoho Desk, your stock system, for example Zoho Inventory, and your accounts, for example Zoho Books.
• Human in the loop. A person reviews what Claude has prepared before it reaches the customer or changes anything.
• Agentic commerce. Commerce in which AI assistants find products, compare prices and complete purchases for users, instead of users browsing websites.

Keep the difference between reading and acting in mind. Reading an order is low risk. Changing an address, issuing a refund or promising a discount is not. Most of the design decisions below come down to that distinction.

A chatbot plugin sits on the storefront. It sees what the storefront sees: product pages and perhaps the cart. It rarely sees the full picture a support answer needs. That picture includes the order history, earlier emails, the return already in progress and the credit note already raised. Those live in the back office.

Customer questions also do not arrive only through the website. They come by email, by reply to a shipping notice and through marketplaces. A plugin covers one of those doors. A back office connection covers every question that ends up as a ticket.

The builders' debate points the same way. On Reddit, one poster asked whether technically capable founders should skip Shopify and build their own store with Claude Code on top of Stripe. The same poster conceded it "may be too high risk for existing stores". The Claude Code Community in Australia says Claude Code works best as a development accelerator alongside a developer. It does not build a complete store on its own.

The lesson for a trading shop is simple. The storefront is where change is riskiest and least useful for support. Leave it alone. Put Claude behind it, where the order data, the tickets and your rules meet.

For Shopify shops, the connection is the easy part. The LinkedIn post cited above says the Claude connector is native, "not through a brittle Zapier flow". It covers catalogue, orders, inventory, customers and analytics. Those are the data an order support answer draws on.

Shopify has also moved on the buying side. Posts on the same LinkedIn page report that Agentic Storefronts went live in March. The feature lists a shop's products in ChatGPT, Microsoft Copilot, Google AI Mode and the Gemini app without a separate integration. It has its own admin page at admin.shopify.com/agentic. Another post describes Sidekick as "a conversational AI that lives in your admin dashboard". It can generate reports and carry out tasks.

Posts on the same page describe fast growth in orders from AI assistants, but they are individual views rather than Shopify's own figures, so we do not repeat them here.

Note what these features cover: finding products and running the admin. None of them answers the customer who emails three days after buying. That work still lands with your team. Order support is where a connection to your back office earns its keep.

WooCommerce shops start one step further back. The sources describe no native Claude connector for WooCommerce. The route is a small integration, built by a developer, that reads orders through the WooCommerce REST API. The REST API is the standard interface a WooCommerce store exposes to other software. The Claude Code Community page lists "REST API integrations" among the things Claude Code can generate for WooCommerce, alongside plugin code and checkout changes.

In practice you have two options:

• Sync WooCommerce orders into your back office, so Claude reads them from the helpdesk or stock system it already works in.
• Build an MCP server that lets Claude query WooCommerce directly for order status, lines and customer details.

Either way, decide the shape of the data before anyone writes code. In a Claude community discussion, one WooCommerce developer said he was still "on the fence" about moving his shop work to custom builds. A commenter's advice applies well beyond that choice: be strict about "writing the data model and checkout states before letting claude code". For order support, that means listing every order status you use and what each one means to a customer.

Two further cautions from the sources. Generated payment code should be reviewed by a security team before it goes live. Another commenter advised a decent errors and omissions insurance plan for anyone building their own system. Reading order data is far safer than touching payments, which is one more reason to start there.

Most shop inboxes split into three kinds of question. Each needs different data and carries a different level of risk.

Order questions

"Where is my order?" and "Has it shipped?" are the bulk of most inboxes. Claude needs to read the order, its status and the tracking reference. The answer is a reading task, so it is the best place to start. Requests to change a delivery address or cancel an order are different. They change something, so a person should approve them.

Returns and exchanges

Here Claude compares the order against your written returns policy. It checks the delivery date, the condition rules and whether the item is excluded. It can then tell the customer what applies and what to do next. The refund itself moves money. That step stays with a person, who raises it in your accounts system.

Product questions

Sizing, compatibility and availability questions draw on the catalogue and stock levels. For Shopify, the connector covers both catalogue and inventory. If your stock is held in a separate stock system, Claude should read it there. The back office figure is the one your warehouse works to.

Sort a month of your own tickets into these three groups before you build anything. The split tells you where most of the saving lies and which rules you must write first.

Take a Shopify shop selling clothing. It uses Zoho Desk for customer email, Zoho Inventory for stock and Zoho Books for accounts. The Shopify Claude connector is switched on with read access to orders, customers and inventory. Its returns rules sit in one written document that Claude can read.

1. The email arrives. A customer writes: "My order hasn't arrived and I think the medium will be too small. Can I swap it for a large?" The email becomes a ticket in Zoho Desk.
2. Claude reads the order. Using the connector, it finds the customer's order and its shipping status and tracking reference.
3. Claude checks stock. It looks up the large size in the same product and confirms whether it is available.
4. Claude reads the rules. It checks the returns document: is the order within the exchange window, and is this item eligible?
5. Claude drafts a reply in the ticket. The draft gives the delivery status, confirms the large is in stock and sets out the exchange steps exactly as your policy states them.
6. A person reviews and sends. The agent reads the draft, edits it if needed and sends it. If the exchange goes ahead, the agent creates it and any credit note in Zoho Books.

The customer gets a complete answer to both questions in one reply. The agent spends their time checking rather than looking things up across three screens.

For a WooCommerce shop the flow is identical. Only step two changes: Claude reads the order through the REST API integration or MCP server described earlier.

The rule of thumb: Claude may read and draft freely, but anything that changes an order, moves money or makes a promise needs a person. The table sets out a sensible starting position for each common task.

Start with every reply going out as a draft. After a few weeks you will know which question types Claude gets right consistently. Loosen control only on those, and only where the answer is a pure reading task such as order status.

Claude follows the rules it is given. If your returns policy lives in one senior agent's head, Claude cannot apply it and neither can a new starter. Before anything is connected, write down the following:

• Returns and exchanges: the window in days, the condition goods must be in, excluded items and who pays return postage.
• Refunds: which payment methods are refunded how, and who approves.
• Damaged or missing goods: what evidence you ask for and what you offer.
• Delivery promises: what you may say about dates, and what you must never promise.
• Identity checks: what a customer must confirm before Claude shows any order details in a reply.
• Escalation triggers: words and situations that send a ticket straight to a person, such as a chargeback or a legal threat.
• Tone: how you address customers and how you sign off.

At Svennis we ask clients to put these rules into one written document before we switch on any connector, because the gaps in a policy show up there rather than in a customer's inbox. That document then becomes the reference Claude reads on every ticket. Our guide to Claude Projects and Skills for a small team shows one way to store it so every user works from the same version.

For a UK business, the questions to settle before switching anything on concern customer data and accountability, not technology. Order records contain names, addresses and purchase histories. Connecting them to Claude means deciding where that data goes and who can see it. Check your position under the UK GDPR before you give a connector access to customer records, including where the data is processed and whether it leaves the UK. Our GDPR checklist is a useful starting point.

Your staff need rules too. An agent who pastes a customer's full order history into a personal chat tool creates the same risk as a badly configured connector. A short written company AI policy on what staff may put into Claude closes that gap.

Accountability does not move. A reply drafted by Claude and sent from your helpdesk is your shop's reply. The customer sees your name on it. This is the practical reason for the human-in-the-loop table above. It is also why the rules document matters more than the choice of tool.

Finally, budget for it properly. Seats, usage and the one-off cost of setting up a connection or MCP server all count. Our breakdown of what Claude costs a ten person company per year gives you the headings to fill in for your own team.

You can move from reading this guide to a working pilot in a few focused steps. Keep the storefront untouched throughout.

1. Sort last month's tickets. Group them into order, returns and product questions, and count each group. Start where the volume is highest and the risk is lowest, usually order status.
2. Write the rules document. Cover every point in the rules section above. Have the person who handles the hardest tickets check it.
3. Choose your connection. On Shopify, use the Claude connector with read access only. On WooCommerce, commission a REST API integration or an MCP server, and fix the list of order statuses first.
4. Run in draft mode. Every reply goes out only after a person approves it. Log the edits agents make.
5. Review weekly. Where drafts need no edits for several weeks, consider direct replies for that question type only. Where edits recur, fix the rules document rather than the prompt.
6. Add the next question type. Move to returns once order status runs cleanly, keeping refunds with a person.

To see the same pattern at work in a live service desk, read our post on Claude for business, from a Teams service desk to a helpdesk. The setting differs, but the approach is the same: Claude reads, drafts and routes, and people decide.