Lead-time-aware top-ups, on autopilot.
Policy-driven replenishment that turns the plan into POs by supplier lead time — and only reorders what cover and open-to-buy allow.
Reorder the moment cover runs out
Dynamic safety stock, daily simulation — reorders fire before the shelf goes to zero.
Why replenishment is where availability is won.
Service level held by Tightly's dynamic safety stock (z = 1.65) — reorders fire before cover's gone, not after the stockout.
Source: Tightly · replenishment engine
Share of unplanned markdown that traces to upstream replenishment and buying decisions, not in-season demand.
Source: Coresight industry research
Full-price sell-through gap between retail leaders and the field — a large share driven by how reliably the shelf is in cover.
Source: Incisiv × WRC × Anaplan 2026
What breaks before replenishment runs to plan.
Three steps to a reorder that fires in time.
Daily demand per SKU × location
Tightly's forecast runs at SKU × location × day — the granularity replenishment needs. Variability is measured, not assumed.
Dynamic safety stock, projected inventory
Safety stock sizes with lead-time and demand variability (95% service level). Projected inventory is simulated forward day by day — the reorder trigger fires when projection dips below safety.
Sized, prioritised, capped by OTB
Order size = safety + future demand − projected. Priority is a margin-weighted composite score; orders group by supplier and stage to the ERP only after the OTB cap. Never auto-commits.
Replenishment that respects the plan.
Policy-driven replenishment that turns the plan into POs by supplier lead time — and only reorders what cover and open-to-buy allow.
What changes once the reorder fires before cover's gone.
Policies in plain English
Min/max, safety stock, lead times, supplier MOQs — set per SKU, channel and supplier, in language a buyer can change without filing a ticket.
OTB-aware reorders
Replenishment proposals never quietly exceed the open-to-buy. If the cover is needed but the OTB is tight, the system surfaces a decision, not an order.
Basket and supplier consolidation
Proposed reorders roll into baskets that hit MOQs and case-pack rules before they go out as POs — fewer small orders, better landed cost.
Talks to your ERP
Approved POs land in NetSuite, Dynamics, BigCommerce or your ERP of choice with the line, the cost and the reason code intact.
Meet your Supply agent
Simulates projected inventory per SKU × location, fires reorders the moment cover dips below dynamic safety stock, and stages the POs — sized, prioritised and OTB-gated — for your approval.
Meet the agents3 SKUs will breach safety stock inside their lead-time window. Want me to stage the reorders — sized to dynamic safety and inside OTB — for your review?
“The stockouts stopped being surprises. Reorders fire before cover's gone, sized to the day — and we're inside OTB every week without babysitting it.”
Service level held · in cover
The replenishment you run today, and the one Tightly delivers.
Replenishment is one part of the connected plan.
Allocation
Rebalance the network before raising a new PO — move stock first, order second.
Demand forecasting
Per-SKU × location × day demand feeds the safety-stock calc and the projection simulation.
Open-to-buy
The OTB cap the reorder engine respects — POs stage only within the envelope.
How does Tightly size safety stock?
Safety stock is calculated per SKU × location from lead time and demand variability, targeting a configurable service level (default z = 1.65 ≈ 95%). It moves with the data — when velocity or lead times change, safety moves.
How is the reorder decision made?
Projected inventory is simulated forward day by day. When projection dips below dynamic safety stock, a reorder fires. Order size = safety + future demand over the lead-time window − projected inventory. Nothing waits for a calendar.
How are priorities decided when many SKUs are due?
Every proposal gets a margin-weighted composite score — margin × velocity × stockout risk. Highest score reorders first. Orders group by supplier so one PO covers many SKUs where possible.
What if the total reorder would exceed OTB?
The OTB cap is a hard gate. Proposals stage in priority order until the cap; anything beyond it surfaces for buyer review. Nothing auto-commits.
How is the difference from allocation drawn?
Allocation distributes existing stock across doors and rebalances via transfers. Replenishment raises new POs when even rebalancing can't hold cover. Rebalance runs first — reorder is the last resort.
Reorder in time. Dynamic safety stock, simulated forward, gated by OTB.
There's nothing to rip out. Tightly runs on your existing ERP, EDI, e-commerce and POS. Give us 30 minutes and we'll show it on your own categories.