Omnichannel Inventory Visibility Software: Why Does Your Site Oversell Stock You Are Also Hiding?

Why availability is the most expensive number in the business

A multi channel retailer runs a nightly extract from the merchandising system into the ecommerce platform. At 2am, on hand quantities land. By 10am the next morning those numbers are already fiction: stores have sold, the DC has shipped, three receipts have not been posted, and a cycle count adjusted 40 lines. The site shows 12 available on a jacket. There is one. It sells four times before the sourcing engine gives up and cancels three customers.

The reaction is always the same. Planners raise the safety buffer. Now every store holds back two units and the DC holds back fifty. Overselling drops, which is the metric being watched, and nobody measures the other side: several thousand units across the estate are sellable and are never offered, right through the weeks they were meant to sell at full price, until they are marked down in January. Both failures come from the same root cause, which is that availability is a stale snapshot being asked to behave like a live number.

Available to promise is not an inventory field. It is a calculation over on hand, in transit, reserved, damaged, held for collect orders, allocated to a promotion, and a policy about how much risk you will carry per node. The moment a retailer starts shipping from stores, that calculation has to run per node, per channel, several thousand times a second, and be right within seconds rather than within a day. That is a systems problem, and it is the reason this category exists.

Problem 1: a snapshot cannot represent a number that changes continuously

Batch extracts fail for a structural reason rather than a tuning reason. A snapshot says what was true at a moment. Inventory is a stream of events: sale, return, receipt, transfer out, transfer in, adjustment, reservation, reservation expiry, pick short. If you only carry the snapshot, you cannot answer when it changed or why, so every discrepancy investigation becomes a comparison of two end states with the middle missing.

Fluent Commerce is built around this idea and handles it well, which is why it appears on most shortlists. Manhattan Active Omni carries genuine depth and IBM Sterling Order Management has been running enterprise inventory for a very long time. The honest constraint with all three is not capability, it is fit and change velocity: you adopt their node model, their availability rules and their release cadence, and when your merchandising team wants a new rule for a category that behaves differently, the change is a configuration project rather than an afternoon. Kibo is a reasonable mid market answer with less depth at very high read volumes.

What a custom build does: hold an append only event ledger per SKU per node, with on hand derived from the events rather than stored as a mutable number. Every event carries a source, a timestamp and a correlation id. Availability becomes a projection over that ledger, recomputed on write and cached for reads. The immediate benefit is diagnostic: when a store swears it had three and the system said zero, you replay the ledger and get an answer in a minute. The larger benefit is that new rules become new projections, not migrations.

Problem 2: safety buffers are a tax nobody has ever measured

Ask five retailers how their buffers were set and you will get five versions of a meeting. A flat two units per store per SKU is the most common answer, and it is indefensible: two units of a fast selling core line is nothing, and two units of a slow moving size 4XL is the entire depth. Buffers exist to absorb inventory inaccuracy, and inaccuracy is not uniform. It varies by store, by category, by how theft prone the item is, and by how recently that location was counted.

What a custom build does: make the buffer a function rather than a constant. Inputs are the store's measured accuracy for that category, days since last count, recent short pick rate on that SKU, and the commercial cost of a cancellation versus a lost sale, which differs for a $30 tee and a $900 coat. A store with strong count discipline earns a smaller buffer and therefore sells more. That single mechanism creates a genuine incentive for store accuracy that no memo ever achieved, and in our delivery experience it is the change that surfaces the most sellable units in the first quarter after launch.

Problem 3: reservations, and the ninety seconds where two customers buy the same coat

Between add to basket and payment authorisation there is a window. In that window the unit is neither sold nor freely available, and how you treat it decides whether you oversell during a spike. Most stacks do nothing at all: the decrement happens at order creation, so two shoppers in checkout on the last unit both succeed.

What a custom build does: reservations as first class ledger events with a time to live, created at a defined point in the funnel and expired automatically. The policy is a commercial decision rather than a technical one, and it should differ by product: hold at basket for a limited launch product, hold at payment initiation for everything else, since holding too early on a general catalogue suppresses availability for browsers who never convert. Expiry has to be reliable at volume, because a leaked reservation is invisible stock loss that nobody will notice for weeks. Collect orders, subscription replenishment and pre orders all need their own reservation classes with different lifetimes.

Problem 4: read volume is the requirement everyone underestimates

Every product page, every listing page, every basket recalculation and every store locator asks the availability question. On a normal trading day that is a large multiple of your order volume, and during a drop or a peak weekend it is a very large multiple. The write side is comparatively tiny. Architectures that fail are the ones that compute availability on read, or that put the ecommerce platform in a synchronous call to a suite service across a region boundary.

What a custom build does: separate write from read explicitly. Events land on the ledger, projections precompute availability per node and per aggregate, and the read path serves from a cache designed for the traffic shape with a defined staleness budget. Say the staleness budget out loud and agree it commercially: two seconds on a product page is almost always acceptable, and demanding zero staleness at the edge costs a great deal of money to satisfy a requirement nobody actually has. Then make the aggregate view honest, because a shopper on a listing page cares whether the item is gettable, not which of the 300 nodes holds it.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape. A first release with the event ledger, per node availability calculation, configurable safety rules, reservations and a production grade read API runs $110,000 to $220,000 and ships in 14 to 20 weeks, typically running in parallel with the existing feed before anything is switched over. A full platform adding node capability scoring, backorder and pre order handling, in transit and future availability, and continuous reconciliation against the merchandising system runs $280,000 to $700,000 across 8 to 14 months.

What drives the number up: the number of source systems publishing events, since a merchandising system, a warehouse system, several POS (Point of Sale) versions and a returns platform all count separately and each has its own idea of what a transaction is. Store count, mainly through reconciliation volume. Multi region traffic, because read latency budgets across continents change the design. Whether your POS can publish sale events in near real time at all, which for older estates is the single biggest unknown and should be answered in week one. And peak profile: designing for a steady load is a different exercise from designing for a drop that multiplies traffic in ninety seconds.

What keeps it down: one channel first, an agreed staleness budget, and accepting store level availability at zone accuracy rather than perfect accuracy while you improve counting discipline in parallel.

Build versus buy, and when buying is the right call

Buy, and do not call us, if you are replacing your order management system anyway, run a compact node network, and your trading pattern has no violent peaks. Fluent Commerce in particular is a good answer at that shape and you will be live sooner than a build. Kibo is fine for mid market. There is no honour in building infrastructure whose rules you were never going to change.

Build when two or more of these are true. Your availability rules are genuinely commercial and change often, so a configuration ticket per change is a permanent tax on the merchandising team. You already run a distributed order management system you are keeping, and you only need the inventory layer, which suite vendors will not sell you cleanly. Your read volume or peak shape is severe enough that per call pricing on a hosted availability service becomes a serious line item. Your node network includes formats that vendor models handle awkwardly, such as concessions, franchise partners, third party logistics providers or vendor dropship stock. Or you have already tried raising buffers and know it costs more than it saves but cannot prove it, which is exactly what a ledger gives you.

How to choose a developer for inventory visibility work

Ask them to explain the difference between on hand, available to sell and available to promise, and to say where reservations sit. If those three collapse into one number in the conversation, they will collapse into one column in the database, and you will be back here in two years.

Ask what their staleness budget would be and how they would prove it in production. You want to hear measurement of end to end event lag as a monitored service level, not a claim of real time.

Ask what they have actually integrated. Publishing sale events out of an older POS estate is a hard, specific problem. Consuming receipts from a warehouse system is a different one. Ask for the named systems and the named event types rather than a general claim about integrations.

Ask who owns the code and the infrastructure accounts, and settle it before kickoff. Availability is the number your entire commercial operation depends on, and it should not live behind someone else's login. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk away from any developer who hedges on that point.