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 fulfilment 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, for most brands I have worked with, it is one of several systems that each hold a partial and slightly different version of that truth.

Every order is a promise. Keeyu keeps the promise. 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.

I have been on the receiving end of it too. It once took a retailer two and a half weeks to locate an order of mine. Not to deliver it, to locate it. The order existed in their system the whole time. Nothing in that system was designed to raise its hand and say this one has been sitting still for eleven days.

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
• Fulfilment holds that exist in the WMS but were never written back
• Shipments that stop moving at the carrier with no exception raised anywhere

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 fulfilment 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.

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.

At Clutch Glue, 70 Shopify orders in the US did not sync to the warehouse and went three days without shipping. We detected it in real time. At EHP Labs an out-of-stock workflow that took the team 45 minutes now runs in five, and their 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.

See how the workflows run or book a demo.

Related reading

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