Your ERP Is Why Customers Get Refund Emails Instead of Running Shoes

Mo Afshar Headshot
image depicting a shoe behind bars, like the one involved in the ERP order management problem mentioned in the article

Peak season exposes a fundamental flaw in how most brands process orders. The fix isn’t faster hardware – it’s a different architecture.

A few months ago, a Pipe17 customer placed an order on On Running’s website. Two pairs of shoes: a Cloud X 4 in Glacier/Stone and a Cloudflow 4 in Black/White. Total: $220. Standard stuff. The kind of order that should take 30 seconds to process and three days to deliver.

Instead, it kicked off a two-week email odyssey that perfectly illustrates why peak season turns into a customer experience disaster for brands that still route orders through their ERP.

The Email Trail That Tells the Whole Story

Here’s what actually happened, email by email.

December 1: Order confirmed. Two pairs of shoes, order number ON875927XXXXXX. No estimated ship date. No delivery window. Just a confirmation that yes, On took the money.

December 2 – one day later: A shipping notification arrives, but only for the Cloud X 4. The Cloudflow 4? Listed as “Preparing Your Order.” One item ships. The other doesn’t. No explanation why.

December 4: The Cloud X 4 arrives. The Cloudflow 4 is still in limbo.

December 14 – nearly two weeks after the original order: On sends a 10% voucher with an apology for “any inconvenience with your recent order.” Translation: the Cloudflow 4 isn’t coming. The order can’t be honored. Here’s a coupon for your trouble.

That’s four emails over two weeks for what should have been a single shipment. The customer got half an order, a vague apology, and a voucher code. On got a frustrated buyer and a return-to-purchase cycle that now requires re-engagement marketing to complete.

This isn’t a one-off. It’s a pattern. And it gets dramatically worse during peak season.

What’s Behind Those Emails

On Running almost certainly runs SAP (or a comparable enterprise ERP) as its order management backbone. The Shopify storefront captures the order, passes it to the ERP, the ERP validates inventory, routes to fulfillment, and pushes shipment confirmations back to the customer.

In theory, this works fine. In practice, particularly during peak season when order volumes spike 5x to 10x, it falls apart in a very specific and predictable way.

ERPs were designed as systems of record. They’re built for financial accuracy, not for processing tens of thousands (or hundreds of thousands) of orders per day at the speed customers expect. When December hits and order volumes explode, the ERP becomes a bottleneck. Orders queue up waiting to be processed. The backlog grows. And two things happen simultaneously that create the exact scenario our On Running buyer experienced.

First, orders take days instead of hours to reach fulfillment. The ERP is grinding through its queue, and each order has to wait its turn. That Cloud X 4 made it through the queue and shipped on December 2. The Cloudflow 4 was still stuck in the ERP’s processing pipeline.

Second (and this is the really painful part) the ERP continues pushing stale inventory counts to the selling channels while it’s backlogged. The Shopify store is still showing items as available because the ERP hasn’t caught up to reality. It processed orders from six hours ago. The inventory it’s broadcasting to Shopify reflects a world where those orders haven’t happened yet. Shopify keeps selling. Customers keep buying. And the brand keeps overselling items that were actually gone hours, sometimes days, before.

That’s exactly how someone orders a Cloudflow 4 on December 1 and gets an apology email on December 14. The item was likely already sold out when the order was placed. The ERP just didn’t know it yet.

Peak Season Makes a Bad Architecture Worse

This isn’t an On Running problem. It’s an architecture problem that affects every brand running the standard Shopify-to-ERP-to-fulfillment pipeline. On just happens to be the example because someone was paying attention to the emails.

During peak season, order volumes can increase by an order of magnitude. The ERP that processes 5,000 orders a day in September is now staring at 50,000 a day in December. The math doesn’t work. ERPs scale vertically – throw more hardware at the problem – but the batch processing model has a ceiling. That ceiling shows up as a backlog. The backlog shows up as delayed shipments and overselling. The overselling shows up as refund emails and discount vouchers.

The cost isn’t just the lost sale. It’s the customer acquisition cost that went into getting that buyer to the checkout page in the first place. It’s the support tickets. It’s the NPS hit. It’s the lifetime value erosion when a customer decides that maybe Nike’s website actually ships what it sells.

The Fix: Stop Pumping Orders Into the ERP

The answer isn’t a faster ERP. It isn’t more middleware between Shopify and SAP. It’s recognizing that the ERP was never supposed to be in the order processing hot path in the first place.

Straight-through processing means orders flow directly from selling channels to fulfillment: no ERP in the middle. An order operations platform handles the routing, inventory allocation, and fulfillment logic in real time. The ERP still gets its data, but asynchronously, after the order has already been shipped. It records the transaction. It doesn’t gate the transaction.

This changes two things immediately. Orders reach fulfillment in minutes, not days. Customers get their shoes while they’re still excited about the purchase, not two weeks later with a consolation coupon. And inventory counts stay accurate because the order operations platform is processing orders as they arrive, not six hours behind reality.

The overselling problem goes away because the system that’s tracking available inventory is the same system that’s accepting orders. There’s no gap between “what the storefront thinks is available” and “what’s actually available.” The two numbers are the same number, updated in real time.

What This Looks Like in Practice

In the On Running scenario, here’s what should have happened. Customer places the order. The order operations platform checks real-time inventory across all fulfillment locations. Both items are available (or they’re not, and the storefront says so before checkout). The order routes directly to the warehouse. Both pairs ship together. One email: “Your order has shipped.” Done.

No split shipments. No two-week mystery about the second item. No apology voucher. Just shoes, delivered, on time.

That’s the difference between an ERP-gated architecture and straight-through processing. One creates a queue. The other creates a customer experience.

Preparing for Peak Season 2026

If this sounds familiar, if the On Running email trail looks a lot like your own customer support queue from last December, the time to fix the architecture is now. Not in October. Now. Peak season planning that starts in Q4 is peak season panic. The brands that come through the holidays with clean order operations and happy customers are the ones that decoupled their order processing from their ERP months before the first Black Friday email went out.

The ERP still matters. Financial reporting matters. Systems of record matter. What doesn’t work is putting a system designed for batch-mode financial processing in the critical path of real-time order fulfillment. Sell, ship, record – in that order. Not sell, wait for the ERP to catch up, maybe ship, probably apologize.

For a deeper dive into why ERP-centric order operations break down and what the alternative architecture looks like, read Pipe17’s paper: Beyond the Ledger: Modern ERP Order Operations.

Share this article:

Mo Afshar Headshot
Table of Contents

More Posts

Replace Legacy Complexity 
With Modern SIMPLICITY

See how enterprise brands cut costs, speed implementation, and eliminate developer dependency with Pipe17.