What this automation does
A customer asks for a return, and within minutes they either have a label in their inbox or a clear message that a person is reviewing it.
- Intake. Requests arrive through a return form on your site or as emails to support. The form collects order number, email, items and reason. For emails, a model extracts the same fields from free text.
- Match the order. The workflow looks up the order in Shopify or WooCommerce by order number and email, and pulls line items, fulfillment dates, discounts, payment methods and any existing returns.
- Check eligibility in code. Days since delivery against your window, final-sale or non-returnable tags, items already returned, order value thresholds, and open disputes or chargebacks.
- Score risk. Simple rules flag returns for review: high value, customers with many recent returns, mismatched shipping addresses, or a damage claim with no photo.
- Approve or route. Low-risk eligible returns get a return created in the store platform, a prepaid label from ShipStation, and a confirmation email. Everything else goes to a Slack review channel with the extracted details and the rule that flagged it.
- Refund on receipt. When the carrier scans the label or the warehouse marks the return received, the workflow issues the refund or store credit and closes the support ticket.
When it is worth building
The math is simple. If your team handles several hundred return requests a month and each one means opening the order, checking dates, creating a label and writing an email, that is many hours a week of copy-and-paste work that is easy to get wrong.
Start with an off-the-shelf returns app if you are on Shopify with standard rules. Build when returns arrive mostly by email, when you sell through several channels, when B2B customers have contract-specific return terms, or when returns must flow into a warehouse system the apps do not connect to. If you are also planning a customer support agent, this workflow becomes one of the tools it calls. If you are weighing an app against a custom build more generally, our custom vs off-the-shelf comparison covers the tradeoffs. Stores that already have an order exceptions workflow can reuse much of the same plumbing.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Intake | A return form on your site plus the support inbox (Gorgias, Zendesk or Gmail) | Structured requests from the form, AI extraction for the rest |
| Orchestration | n8n | Built-in Shopify, WooCommerce, Stripe and Slack nodes for orders, payments and messaging; Shopify returns and refunds (GraphQL Admin API), ShipStation and Gorgias through the HTTP Request node |
| Extraction | Claude Haiku 5.5 or a small OpenAI GPT model | Turns free-text and photo descriptions into line items and reason codes |
| Policy rules | Code step with your return policy as data | Windows, exclusions and thresholds must be exact and auditable |
| Returns and refunds | Shopify or WooCommerce APIs, Stripe for direct charges | Keeps inventory, accounting and order history correct in the system of record |
| Labels | ShipStation or your carrier account | Generates the return label and provides tracking events for the refund trigger |
| Review | Slack channel with approve and deny buttons | Reviewers act in one click, and the decision is logged |
How to build it
- Write your return policy as a table, not prose: window in days by product type, non-returnable tags, who pays shipping, refund versus store credit, and value thresholds for review. Gaps in the policy show up immediately.
- Map reason codes. Pick six to ten (wrong size, changed mind, damaged, defective, not as described, arrived late, missing item) and decide which ones need a photo.
- Build the order match with order number plus email, and handle customers who check out as guests with a different email than they write from.
- Build extraction for email requests, returning line item IDs, quantity and reason per item as JSON. Validate that every item ID exists on the order.
- Implement eligibility and risk rules in a code step with unit tests for edge cases, such as partial returns of discounted bundles.
- Create returns and labels for approved requests, and store the label tracking number against the return.
- Wire the refund trigger to carrier scan or warehouse receipt, and use the platform’s refund calculation so discounts, tax and shipping are allocated correctly.
- Run with every approval going to review for two weeks, then let low-risk returns auto-approve.
The downloadable starter template below covers form intake, Shopify order match, policy checks and Slack review.
What breaks in production
- Refunding twice. A customer opens a chargeback and also requests a return. Check for open disputes before refunding, and route disputed orders to a person.
- Discount allocation errors. Refunding one item from a “buy two, get 20% off” order at full price overpays the customer. Let the platform calculate the refund amount.
- Split fulfillments. One order shipped in three packages on different dates. The return window should run from the delivery date of the specific item, not the order date.
- Labels created and never used. Customers request a label and keep the item. Do not refund on label creation, and expire unused labels after your window.
- Serial returners. A few customers return far more often than everyone else. Flag customers above a return count or rate you choose and review them by hand.
- International returns. Customs paperwork and carrier rules differ. Keep international returns on manual review until you have a tested path.
Timeline and cost
A single Shopify or WooCommerce store with form and email intake typically takes two to four weeks. Lumeor builds returns and refund automation in the range of $5,000 to $12,000. The low end covers form intake, policy checks and labels for one store. The high end adds email extraction, exchanges, warehouse receipt events and multiple storefronts. Model costs are low because only email requests need extraction, and most of the logic is plain code.
How to measure success
- Time from request to label sent, median and slowest tenth
- Auto-approval rate, and the share of auto-approved returns later reversed or disputed
- Refund errors: over-refunds, double refunds and refunds on items never received, each counted
- Support tickets asking “where is my refund,” which should fall once refunds are tied to scans
- Return rate by SKU and reason code, now clean enough to share with merchandising