Every order management system now claims the same three things: intelligent order routing, real-time inventory, and store fulfillment. On a feature list they read identically, so the list does little to help you tell the vendors apart.
What decides whether routing actually works is not on that list. It is the data the routing engine reads. Without RFID, the average retail store's inventory runs only about 65% accurate (Auburn University RFID Lab and GS1 US). A routing engine scoring stores on numbers that are wrong one time in three will send an order, with full confidence, to a store that cannot fill it. No scoring model fixes a count that was never right.
That is usually why routing keeps picking stores that cancel. The cause is rarely the algorithm. It is the inventory the algorithm trusts, and the routing rules nobody can change quickly enough. Both are things you can check before you buy.
Routing fails on the data and the rules, not the algorithm
Routing quality has two ceilings, and neither is the algorithm. The first is the accuracy of the store inventory the engine reads. The second is who can change a routing rule, and how fast.
Start with the data. A routing engine picks a fulfillment location by scoring stores on distance, cost, and available stock. When the stock number is wrong, the score is wrong, and the engine routes with full confidence to a store that cannot fill the order. The store cancels or short-ships, the order bounces to a second location, and delivery slips by days. The shopper who was promised two-day delivery now waits a week, and the brand absorbs a second shipping label it never planned for.
The cost of that bad input is not small. Global retailers lost an estimated $1.73 trillion to inventory distortion, stockouts and overstocks combined, in a single year (IHL Group, 2024). Much of that traces back to records that do not match what is on the shelf, and a routing decision inherits every one of those errors.
Now consider the rules. Most routing engines ship with logic that made sense the day it was configured. Then peak arrives, a storm closes a region, or a promotion drains one store's stock in an afternoon, and the rules need to change. If changing a rule means filing an engineering ticket and waiting for a release, the routing is effectively frozen during the moments it matters most. The team that owns the outcome, the ops team measured on cancellation and delivery speed, cannot touch the system that produces it.
Named plainly, this is a data-quality problem and a rule-ownership problem, not an algorithm problem. A buyer who evaluates only the scoring model is grading the part of the system least likely to fail. The two parts most likely to fail go untested until they are live.
Evaluations grade the algorithm and skip what fails
Most evaluations spend their time on the scoring engine, because that is what the pitch is built around: an order arrives, nearby stores are scored on distance and cost, the best one lights up. It looks decisive, so it gets graded as decisive. It is also the part least likely to fail.
The two parts that do fail rarely get tested. First, how accurate is the store inventory the engine reads, and what keeps it accurate over time. Second, can a business user change a routing rule without a developer and see the effect before it goes live. Neither shows up on a feature list, because both live in daily operations.
The result is familiar to anyone who has run store fulfillment. Confident routing on bad data sends orders to stores that reject them, work piles up while the dashboard still shows green, and associates stop trusting the queue and cherry-pick what they can fill. The routing logic quietly stops describing what happens in the stores. Most teams file this under store execution; much of it was decided earlier, by an evaluation that tested the algorithm and skipped the data and the rules.
Five questions that show how routing will actually behave
Two things decide whether routing works, and a feature list shows neither. Put these five questions to any vendor and listen for specifics; the one that has actually solved this will name the mechanics. Here is how HotWax Commerce answers, as a reference for what a real answer sounds like.
1. What number does routing read, and how deep is it? Most vendors say "real-time inventory" and move on. Ask what the engine actually scores. HotWax routes on Online ATP, the sellable count left after it subtracts each store's safety stock (the buffer kept for walk-in shoppers), the company threshold, and the units already earmarked for orders sitting in the brokering queue. That last part decides more than it looks. Two stores can both show the item in stock, but a store with three units and a safety-stock floor of two has nothing truly available, while a store with eight does. Score on raw quantity on hand and the engine treats those stores as equal, then ships to the one that cannot fill the order. Online ATP lets it compare real depth instead of shelf counts, and store-native cycle counting keeps that depth honest between counts.
2. Who changes a routing rule, and how fast? If the vendor configures it for you, every peak, storm, or promotion turns into a support ticket and a wait. In the HotWax Order Routing App an ops user builds the logic directly: sequential rule-sets, order batches so same-day runs before standard, a pick sequence, Facility Groups and a proximity radius, a brokering safety-stock floor per store, and a max order limit so no single store gets buried. It is configuration, not code, so the team judged on cancellations and delivery speed can change the rules the same afternoon the picture changes.
3. Can routing chase a business goal, not just the nearest store? Distance and cost are table stakes; the real advantage is routing that moves the inventory you actually want moved. Ask whether an ops user can rank eligible stores by something other than proximity. HotWax can rank by weeks of supply so online demand clears your slowest-moving stock first, protect your best-selling doors so ecommerce orders do not drain the stock those stores need for walk-in customers, push clearance out through outlet locations, and prioritize stores holding broken sizes or single pairs to clean up the assortment. Distance becomes the tie-breaker once the objective is met, not the objective itself. An engine that can only find the closest store with stock cannot do any of this.
4. Can you try a rule before real orders hit it? This is the question buyers forget, and the one that prevents the most damage. Without it, every rule change is a live experiment on real customers. HotWax includes order routing simulation: point a proposed rule set at real orders and see exactly how it would allocate, which stores would get which orders, before it touches live traffic.
5. What happens when a store cannot fill it, and does a split cost you money? Every network has rejections and awkward carts, and the happy-path demo skips both. Two mechanics matter. First, an order no store can fill under one rule-set should fall through to the next, or to a defined action like a tag, a queue, or an auto-cancel date, rather than fail silently, which is how HotWax's sequential rule-sets behave. Second, a split should protect margin: HotWax splits only when both the shipped portion and the leftover portion clear a shipment-value threshold, so a low-value add-on like laces never goes out as its own package, while a real two-item order still splits for speed. A store that has hit its max order limit drops out until it recovers.
None of these five questions is about the algorithm, and that is the point. Routing quality is set by what surrounds the engine: the number it trusts, who owns the rules, what those rules are allowed to optimize for, whether you can test a change before customers feel it, and how it behaves when a store says no. Grade a vendor on those, and a polished demo stops deciding the purchase.
Key takeaways
- Routing rarely fails because of the algorithm. It fails on the number the engine reads and the rules nobody can change fast enough.
- On raw quantity on hand, two stores look identical; on Online ATP, after safety stock, threshold, and the brokering queue, only one can truly ship. Routing needs the sellable number, not the shelf count.
- The real gain is routing to a business goal, not the nearest store: clear slow movers by weeks of supply, protect your best doors, push clearance to outlets, and clean up broken sizes.
- If changing a routing rule needs a developer ticket, your routing is frozen through every peak, storm, and promotion, exactly when it should move.
- Test a rule against real orders before it goes live. Without simulation, every change is an experiment on real customers.
- Judge the exceptions: a rejected order should reroute on its own, and a shipment should split only when it protects margin. That is where routing quietly wins or loses.
What to make a vendor show you
Put these five questions to any OMS vendor and make them show, not tell: Online ATP on a real product, a routing rule changed live in the Order Routing App, and a simulation against real orders before go-live. For a Shopify order management stack, that is how to choose an OMS your team can run, not just watch.
Contact HotWax Commerce team to learn more about intelligent routing.
