TL;DR: three to five days, $1,500-2,500, $9-16/month to run. Worth it from roughly 20 orders a day. The whole difficulty is in four places: duplicate webhook delivery, partial fulfilment, failed payments, and returns. Everything else is wiring modules together.
Shopify gives you the store. It does not do the work behind it. Every order still needs someone to check stock, tell the warehouse, produce a packing slip, get a tracking number in, and tell the customer. At five orders a day you cope. At fifty you do not.
This is the deep version, covering order processing only. If you want the wider picture across orders, support and reordering, the full store guide covers that at a higher level and this goes underneath it.
The happy path, which is the easy 20%
Shopify fires a webhook on a new order. Your scenario catches it and runs: check stock, notify whoever packs with the order and instructions, generate the packing slip, create the shipment with the courier and pull the tracking number, send the customer a real tracking email. Order to warehouse notification in under two minutes.
Building that takes a day. Building the version that is still correct in month six takes the rest of the week, and the difference is entirely in the four problems below.
Problem 1: webhooks arrive more than once
This is the one that costs real money and almost nobody builds for it. Shopify guarantees at-least-once delivery, not exactly-once. If your endpoint is slow or returns an error after doing half the work, the same order is delivered again.
Without a guard, that is a second pick instruction to the warehouse, a second confirmation email to the customer, and sometimes a second shipping label you paid for. It does not look like a bug, it looks like a strange busy day.
The fix is small and must come first in the scenario: record the Shopify order ID before doing anything else, and on every delivery check whether that ID has already been handled. If it has, stop. This makes retries safe, which in turn makes it safe to retry deliberately when a downstream API is flaky.
Related and just as important: answer the webhook fast and do the work afterwards. A scenario that spends forty seconds calling a courier before responding will be re-delivered by Shopify while it is still working. Acknowledge, then process.
Problem 2: orders do not ship all at once
An order with three items where one is out of stock is not an edge case, it is Tuesday. If your automation treats an order as a single unit, it will either hold the whole thing until everything is available, or mark the order fulfilled when the first part ships.
Both are bad for different people. The first annoys a customer who would happily take two items now. The second tells them their order shipped when half of it did not, which produces a support ticket and a refund request.
Decide the policy explicitly before building: ship what is available and track the remainder as a separate fulfilment, or hold, with a rule for how long. Then build it. The default of not having a policy is what generates the tickets.
Problem 3: paid is not the same as captured
A webhook on order creation fires for orders whose payment later fails or is flagged for review. If your warehouse notification goes out on order creation, you will occasionally pick and ship goods for an order that never pays.
Trigger the fulfilment path on payment status rather than on order creation, and treat a pending or under-review payment as a hold rather than a go. The correct trigger is boring and it is the difference between a system you can leave alone and one somebody has to watch.
The same logic applies in reverse: a cancellation or refund after your scenario ran needs to reach the warehouse. If the only path is order creation, nobody downstream ever hears that an order was cancelled.
Problem 4: returns, where most automation stops
Returns are less predictable, so they get left manual entirely. That is an over-correction: roughly 70% of return requests follow a shape. The customer submits a request, the system checks that the order exists and is inside the window, approves, sends the label, updates the status.
The other 30% fall outside the rules and go to a person. Automating the 70% is a large saving and carries little risk, as long as the boundary is a rule and not the model's judgment. Anything touching a refund amount, a goodwill decision, or a customer who is already unhappy goes to a human by default.
The inventory loop, which is harder than orders
Order processing is a straight line. Inventory is a loop, and it is where most stores are still doing it by hand: checking stock and emailing suppliers when something looks low.
The automated version: a processed order decrements the SKU, and when a SKU crosses its reorder point a second flow drafts and sends the supplier order. We have run this for Simbago for over a year with no stockouts.
Two things make it work rather than misfire. Set the reorder point from sales velocity and supplier lead time rather than a flat number, because a SKU selling twenty a week needs a different trigger from one selling two. And for the first fortnight, send the draft to yourself rather than the supplier. An automation ordering the wrong quantity from a real supplier is an expensive way to discover your thresholds were guesses.
What you need
The stack is unremarkable and that is the point.
An automation platform: Make from $9/month covers most stores, n8n if you want self-hosting
A Shopify webhook on order events, configured in the admin under notifications - Shopify moves this occasionally, so search the admin rather than trusting a path from any article including this one
A channel the warehouse actually reads, which is usually not email
A sheet or database for inventory, if it is not already in Shopify
A courier API, if you want labels generated rather than typed
An email sending service for customer notifications
Cost, and when not to bother
Three to five days to build and test, $1,500-2,500 as a project, $9-16/month for the platform. It pays back within a month for a store doing 20+ orders a day.
Below about ten orders a day, do not. You will spend more on the build than the time is worth, and a person handling ten orders catches the odd ones automatically. Automate this when the volume has made that impossible, not in anticipation of volume you do not have yet.
Running a store and unsure which parts are worth automating first? The audit at 2pizza.team/audit takes two minutes, no call, and gives you an order of operations rather than a pitch.
Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.
Top comments (0)