Multi-Channel Order Processing Automation for a Retail Brand

Client context

A consumer retail brand selling through Shopify, Amazon, and a wholesale channel, growing from 200 to 800+ orders a day. Three people spent their days re-keying orders into the ERP and pushing stock levels back to the channels from an Excel export. I owned the architecture, the build, and production support.

The problem

The brand had grown channel by channel, and the operations behind it hadn't. Orders were copied into the ERP by hand — SKU by SKU, address by address. Stock numbers on the channels lagged reality by hours, so the brand oversold regularly: around 40 oversold orders a month, each one a refund, an apology, and on Amazon, a hit to seller metrics they couldn't afford.

Tracking numbers were copied back to the channels in batches whenever someone found time, which meant late-shipment flags on orders that had actually gone out on schedule. Peak season made the math plain: hiring temps to re-type orders faster wasn't a plan.

The automation I built

The honest first decision was what not to use. I do a lot of RPA development, but classic screen automation earns its keep when systems lack interfaces — and here, every system involved had a workable API. So this became a set of small Python services rather than a bot clicking through web pages. Less dramatic to demo; far more durable in production.

Orders land in a single queue from Shopify webhooks and Amazon SP-API polling. Each is validated — address quirks, B2B pricing rules, gift options — then created in the ERP with an idempotency key, so a retry after a network hiccup can never produce a duplicate order. Inventory syncs to every channel on a 15-minute cycle, with per-channel safety buffers on fast-moving SKUs. When the warehouse ships, tracking numbers flow back to the source channel within minutes. Anything odd lands in a Slack channel with enough context for a human to act on it in seconds.

One holdout: a legacy courier used for oversized freight had no API at all, just a browser booking form. For that single step I built a small UiPath robot. It ran for about a year until the courier finally shipped an API, at which point it was retired without ceremony. Right tool per integration, even within one project.

• Order ingestion from Shopify webhooks and Amazon SP-API polling into a single queue
• Idempotent ERP order creation — retries can't create duplicates
• Validation rules for address quirks, gift orders, and B2B pricing before entry
• Inventory sync to all channels every 15 minutes, with per-channel safety buffers
• Automatic tracking-number write-back to each sales channel
• Hold rules that flag suspected fraud and unusual orders for human review
• Real-time Slack alerts plus a daily exception summary
• Nightly reconciliation comparing every channel's orders against the ERP

What made it hard

Amazon's SP-API throttling shaped more of the architecture than I'd like to admit. Rate limits vary by endpoint and burst behavior, so the poller had to budget requests, back off politely, and prioritize order retrieval over less urgent calls. Getting this wrong doesn't fail loudly — it just quietly delays orders, which is worse.

Partial failure was the other hard problem. The nasty case isn't a request that fails; it's a request that succeeds while its confirmation gets lost, leaving you unsure whether the order exists in the ERP. Idempotency keys make retries safe, and the nightly reconciliation job flags anything that drifted between the channels and the ERP. That job has caught issues the real-time monitoring missed — including one bug of mine.

International addresses provided a steady drip of edge cases: postcodes that don't fit the ERP's validation, apartment numbers in unexpected fields, customer names longer than a database column. Each earned a rule; the rules file is the sediment of six months of real orders.

Results

Order volume stopped being a staffing problem:

• About 95% of orders reach the ERP with no human involvement
• Oversells fell from roughly 40 a month to fewer than 3
• Tracking numbers reach the channel within minutes of shipping — the Amazon late-shipment rate returned to healthy territory
• The holiday peak, roughly triple normal volume, ran without temporary staff for the first time
• Wrong-SKU and mistyped-address errors in the ERP dropped to near zero

Business impact

The automation turned order volume from a staffing problem into a background process. The three people who spent their days re-keying orders now handle customer service and merchandising — work that actually needs judgment. Marketplace account health stabilized, which for an Amazon-dependent brand is existential rather than cosmetic. And because every order now carries clean, consistent data, the finance team's month-end channel reconciliation shrank from days to hours as a side effect.

Lessons learned

Pick the tool per integration surface, not per project. API-first automation and RPA screen automation solve the same business problem with very different maintenance bills, and this project needed 95% of one and 5% of the other. The deeper lesson was about failure design: in workflow automation that moves money and inventory, idempotency and reconciliation aren't nice-to-haves — they're the difference between a system the business trusts and one it babysits.

Stack