Order management system: what it records and what it misses

What an order management system is

An order management system (OMS) is the software that tracks an order from checkout through to delivery. It holds the record of what was bought, allocates stock against it, routes it to a fulfillment location, and updates its status as it moves. In a mid-market e-commerce stack it usually sits between the storefront and the warehouse, and often overlaps with an ERP.

The theory is that the OMS is the single source of truth for an order. In practice it is one system in a line of them: a storefront, a payment gateway, a warehouse system, the OMS, an inventory system, a carrier integration, the carriers themselves, returns and a helpdesk. Each one does a very specific job, and none of them was designed to detect when a customer does not get what they want on time.

Every order is a promise. Keeyu keeps it. The OMS records the promise. It does not usually notice when it breaks.

The gap between what the OMS says and what is actually happening

I once watched a customer service person at a retailer work with 65 browser tabs open. Storefronts, warehouses, carriers, ERP locations, all open at once so they could alt-tab between them to answer questions about orders. Every one of those systems was working correctly. The problem was that no one of them held the whole picture, and stitching them together was a human job done one order at a time.

The same gap shows up on smaller teams. At one brand, every time a customer asked where their order was, the team had to check 5 or 6 different systems: Shopify first, then the carrier portals, then the warehouse system, then the email threads to find what the warehouse had said three days earlier. The problems were not complicated. Finding the information was. The order existed in those systems the whole time, and nothing in them was designed to say this one has stopped moving.

The gap has a size: around eighty points of failure across the post-purchase journey, which is what we monitor and the number I gave on eCommerce Australia. An OMS records the state each system reports. The gap is everything happening between those reports, and it is where the orders actually go wrong.

Where orders actually break

The failures that generate support tickets are rarely failures of the OMS itself. They are failures in the seams between systems:

• Orders that never sync from the storefront to the warehouse and simply sit
• Stock that sells after it is gone because sync lagged during a volume spike
• Fulfillment holds that exist in the WMS but were never written back
• Shipments that stop moving at the carrier with no exception raised anywhere

Records drift from reality even inside a single system: a Management Science study by DeHoratius and Raman examined nearly 370,000 inventory records from 37 stores of one retailer and found 65% to be inaccurate.

The seams multiply with every system you add. As I said on The Quest for Success: "These systems are systems of record and there can be anywhere between 10 to 20 systems of record that manage an order. And they're good at performing a specific function, but when they fail, they fail silently."

At the start of COVID in 2020 our warehouse sale revenue went vertical and our Shopify store stopped syncing with the warehouse. It oversold. We ended up with a thousand orders for stock that did not exist. Every system involved was running normally. The break lived in the space between them.

Peak trade is where the seams show

During peak, retailers reliably overinvest in customer acquisition and underprepare fulfillment for the volume that acquisition creates. At P.E Nation and SurfStitch I made sure the warehouses had the staff to process what we were about to sell them, because the marketing spend was already committed and the orders were coming either way.

An OMS will happily accept ten times the normal order volume. It will not tell you that your 3PL cannot pick it, and it will not tell you which specific orders are now sitting still as a result.

The seam that shows first is the dispatch SLA. Under Black Friday volume an order that normally leaves the warehouse inside twenty-four hours can take seven days, or the stock is not where the system believed it was. When I was asked on Add To Cart how we catch that when the WMS does not, my answer was that we are an orchestration layer, not a point solution. We take the customer promise (order before 12, pay express, ship same day, get tomorrow) and check every order against where that promise says it should be right now. The OMS keeps recording the order correctly the whole time. What changed is the promise, and nothing in the stack is watching that.

What to add on top of the OMS

The missing layer is not another system of record. It is a system of action: something watching across the store, the warehouse and the carrier that knows what an order is supposed to be doing right now and notices when it stops.

That is proactive e-commerce operations. Detect the break, decide what should happen, act on it. Detect. Decide. Act.

A worked example: our out-of-stock workflow triggers when the warehouse types 'out of stock' into NetSuite, searches other stores for inventory, finds product alternatives, checks the ERP for next shipments, and if nothing can replace the item, cancels the order and processes the refund. For the stock side of this, we scored the oversell and backorder tools, Keeyu included, in our ranking of oversell and backorder management tools.

One brand had 70 orders captured on its US Shopify storefront that never synced to the warehouse, while the orders around them did. Those 70 had not shipped for 3 days. We detected it instantly. At EHP Labs an out-of-stock workflow that took the team 45 minutes now runs in five, and at one of our customers the CX function went from 18 people to 8.

The point is not that their OMS was bad. It is that no OMS is watching for the order that quietly stopped moving.

The watching layer reaches where helpdesk AI cannot: Return to Sender, Lost in Transit, awaiting collection, out-of-stock, handled end-to-end before the helpdesk ever sees them.

See how the workflows run or book a demo.

Add the layer with write access. A system of record processes the order, a system of notification reports on it, and a system of action can cancel, replace, reorder and reship inside the systems that own it, which is the distinction I drew on The Ecommerce Edge. Your OMS is the first kind by design, and nothing about buying a better one changes that.

Related reading

For the tickets this generates, read WISMO. For the operational layer overall, see post-purchase operations. For fulfillment specifically, read fulfillment.

• Order management systems: what a small team actually needs
• Order management in the supply chain: who owns which handoff
• Returns management, and the returns that were never really returns
• Delivery exception: what it means and how to act on it

• DeHoratius and Raman, Management Science, on inventory record inaccuracy: the research on inventory record inaccuracy.
• SCOR Digital Standard, RL.1.1 Perfect Order Fulfillment: perfect order fulfillment as the cross-system measure.
• Marketing for SMEs, Jevon Le Roux on the E-Commerce Mistake Costing Millions - the orchestration layer, and the 55% ticket cut at EHP Labs.
• Add To Cart #578, Stop Customer Problems Before They Start: Inside Keeyu's AI Ops - stuck returns, failed payments and orders caught mid-flight.
• The Breakout CEO #86, The Pivot This Founder Made After an Investor Called It Impossible - one in five US shoppers not getting orders on time, and the ticket ratios behind it.
• Founders in Motion, The Hidden Flaw In Every Fashion Brand (He Built the Fix) - the COVID warehouse sale and the thousand customers who paid for stock that had sold out.
• Keeyu, Clutch: Keeping Fashion Emergencies Stress-Free - the Clutch Glue case study: too many logins and windows, and delays spotted only after a customer complained.