Restock Dashboard: where signals become a proposed buying decision
The Restock Dashboard is not just a list of SKUs. It is the working decision table that combines demand, inventory, inbound stock, timing, and risk into a reorder recommendation.
Why this tile was built
Before this tile, restock work depends on manually combining Amazon inventory, warehouse inventory, recent sales, lead time, supplier constraints, and judgment. That is slow and creates risk. This tile exists to make the decision path visible so Franz can see how a final quantity is being formed.
Every important part inside the tile
SKU / ASIN / Product
Identity fields. These are not boring labels. They prove that all later numbers are attached to the correct product.
On hand
Units currently available in the relevant inventory lens. Franz must ask: is this Amazon sellable, warehouse stock, or combined planning stock?
Inbound
Units already on the way. Inbound reduces how much we need to buy, but only if timing is reliable and the inbound shipment is real/useful.
Reserved/problem inventory
Inventory that exists but may not cover demand. This prevents Franz from treating all stock as equally usable.
Daily velocity
The demand engine. It tells us how quickly stock is expected to disappear. Franz should check whether velocity is based on 7-day, 30-day, 60/90-day, or blended behavior.
Days of cover
The urgency translation. Inventory divided by velocity becomes time. This is why raw units alone are misleading.
Lead time
The delay before new stock can help. Supplier time, shipping, receiving, prep, and Amazon check-in can all matter.
Target cover
The cushion Brent/Fergus want. This protects against running too lean, especially when lead time or demand is unstable.
Suggested reorder
The math output. It is a recommendation, not a command. It must be rounded to case pack/MOQ and reviewed for exceptions.
Notes/flags
The judgment layer. Notes explain risk, uncertainty, supplier concerns, listing problems, or manual overrides.