twimco.Let’s talk ↗︎
Menu
Field notes / Operations

Available online does not mean pickable at this DC

The site said in stock. The DC that owns the order has zero on the pick face. Somewhere between network inventory and local pickable stock, your promise got ahead of the aisle.

Editorial engraving of a bright warehouse mezzanine where an inventory lead compares a tablet badge to an empty aisle while a picker gestures toward a fuller aisle beyond.

Treat "available" as pickable at the fulfillment node that will actually ship the order, not as a sum across the network. Walk one SKU from website badge to ATP rule to reservation to pick ticket. If any step uses a different definition of available, fix the definition before peak, or you will invent backorders and apology emails on items that existed somewhere else.

Start at the badge the customer saw

This is a walk-through of one failure that shows up every peak season. Names and systems are composite; the shape is not.

A customer buys a blue jacket at 8:14 p.m. The product page said In stock. Checkout promised departure tomorrow. At 6:02 a.m. the pick wave at DC East prints the line. The pick face is empty. DC West has fourteen. The order is already assigned to East because yesterday's routing rule preferred East for that ZIP.

Support will call this an inventory glitch. It is usually a definition glitch: three systems used the word available to mean three different things. The customer did nothing wrong. Your stack accepted a promise that only a different building could keep.

The walk-through below is what to do on a quiet Tuesday with one SKU and two buildings, before November turns every exception into a pile.

How the work moves

Walk one SKU from badge to pick

  1. Website badge

    What "in stock" is allowed to mean.

  2. ATP

    What quantity was reserved, against which nodes.

  3. Routing

    Which DC received the order.

  4. Pick ticket

    Whether that DC can walk to a unit.

  5. Customer promise

    What must change if pick fails.

Illustrative walk-through; not a client WMS screenshot or measured fill rate.

Step 1 — What the site means by available

Open the product page rules, not the marketing copy. Does "in stock" mean any node in the network has a unit, the customer's preferred node has a unit, or a unit can arrive from a supplier before the promise date?

Network availability is useful for planning and for showing that you sell the item at all. It is a poor promise for a next-day ship badge. If the badge can light up on West's stock while East will receive the order, you have already written today's ticket.

Write the rule in one sentence a new merchandiser would understand. If you cannot, the website is improvising. Then check mobile and marketplace feeds. Marketplaces often get a different availability feed than your site. If those feeds still speak "network," you will oversell on the channel that hurts most when it fails.

Also check preorder and backorder badges. Teams sometimes reuse the green In stock styling for "we can get it," which teaches customers the wrong lesson about pickable stock. Different promise, different color, different copy.

Network stock is a planning number. Pickable stock is a promise.

Step 2 — What ATP reserved

Available-to-promise should reserve against the stock the fulfilling node can pick, after holds, damage, quality lock and work-in-progress. In too many stacks, ATP still subtracts from a pooled number while routing later picks a building.

Walk one SKU. Note the on-hand at each DC, the soft holds, the safety stock and the quantity ATP returned when you placed the test order. Then note which DC the order landed on. If ATP succeeded on pooled stock and routing ignored that pool, the math was theater.

Ask one more question: when ATP soft-reserves a unit, does that reservation live on a node or on a pool? Node reservations that routing can still override are how you get two orders believing they own the same East unit while West sits full.

Related reading: inventory truth drift is about disagreeing counts; this walk-through is about agreeing on the wrong count for the building that must pick. Both problems can be true on the same Monday.

Decision guide

Network available vs pickable here

ConsiderationNetwork "available"Pickable at fulfilling DC
QuestionDoes any node have a unit?Can this building pick a unit today?
Good forAssortment and planning views.Ship badges and order acceptance.
Fails whenRouting ignores where the units sit.Safety stock and holds are hidden from ATP.
Customer seesIn stock, then silence.A slower promise or a true next-day ship.
Decision framework; illustrative, not client data.

Step 3 — What the pick ticket believes

The pick ticket is the last honest system. It asks: is there a unit here, in a bin I can walk to, for this order? If the answer is no, every upstream "available" was a rumor.

Watch what happens next in your warehouse software. Does it auto-reassign to West? Create a backorder? Split the shipment? Email the customer? Or sit in exception until a lead notices at noon?

Each of those is a product decision. Peak is a bad time to discover which one you accidentally chose. Auto-reassign sounds kind until West is already at capacity and the carrier cutoff for the customer's ZIP from West is earlier than East's. Split ship sounds kind until the second carton misses its own cutoff. Sitting in exception sounds safe until the customer has already bought a replacement elsewhere.

Stand at the exception board for an hour. Count how many lines are "available somewhere else." That count is the size of the definition problem, not the size of the labor problem.

Step 4 — Close the loop on the promise

If East cannot pick, the customer promise has to move with the inventory, not with optimism. Either route to a node that can pick before you accept the order, or show a slower promise when only a distant node has stock, or offer split ship only when every package clears its own cutoff.

Before the second warehouse opened, someone should have decided which orders it gets; that planning note still applies when the second warehouse already exists and the first one still steals orders it cannot fill. See before the second warehouse opens.

Tell support what they are allowed to say when pick fails. "It's in stock in our network" is not comfort. "We are moving this to the building that has it; here is the new departure date" is an operating sentence.

If you sell on marketplaces that impose their own late-shipment penalties, this definition work is not optional polish. A badge that lies in your favor still shows up as your defect rate on their scorecard.

One more habit helps: publish an internal glossary with three terms only—network on-hand, ATP, pickable. Make every dashboard column use one of those three words. The day someone adds a fourth synonym is the day the badge lies again. Safety stock is not decoration; if pickable ignores it while ATP pretends it is sellable, you have rebuilt the bug in vocabulary.

When you open a third node next year, rerun this walk-through on day one. New buildings inherit old definitions unless someone forces the badge, the reservation and the pick ticket to introduce themselves again.

Network stock is a planning number. Pickable stock is a promise.

Put this into practice

Tomorrow morning, pick five bestsellers. For each, compare: website badge, ATP result for a ZIP served by your busiest DC, on-hand and pickable at that DC, and the DC your test order would assign. Write down every mismatch. Those five rows are the backlog.

Then change one rule before you buy another dashboard: the ship promise may only use pickable stock at the node that will fulfill. Everything else can stay a planning view with a different name.

We build fulfillment operations systems where storefront, ATP and the bench share one meaning of available. If your badge and your pick face disagree, talk to us.

Related work: Spin:Market.

twimco.

We build alongside the people doing the work.
Bring us the problem you’re thinking about.

Related work

Spin:Market ↗︎