Setting a lead time for a supplier who is never on time

Use the worst realistic arrival you have actually seen from that supplier, not the lead time they quote. Pull the last ten deliveries of the SKU, count the real days from the moment you sent the purchase order to the moment the stock was sellable, sort those numbers low to high, and take the second-worst. That is the lead time you put into your reorder point. If the supplier says 21 days and your sorted list reads 19, 22, 23, 24, 24, 25, 26, 28, 31, 45, your lead time is 31. Not 21, because they have never once hit it. Not the 26 day average, because an average is a number you will be under half the time. Not 45, because that was the week the port backed up and you will be carrying that pad forever.

Then revise it after every delivery. Keep the list rolling: a new arrival goes on the end, the oldest comes off, and you re-read the second-worst. A supplier getting worse shows up in that number within two or three orders, which is long before it shows up as an empty shelf. That is the whole method. The rest of this is how to get the data, where to put the padding, and what it costs you.

Why the quoted lead time is the wrong input

The quote is the supplier's best case under their own control. It usually excludes the two days your PO sat in an inbox, the day the payment cleared, the three days the freight forwarder held the pallet for a full container, customs, and the half day your own warehouse took to count it in and push it live in Shopify. None of that is dishonesty on their part. It is just a different clock to the one your inventory runs on.

Your reorder point is a promise to yourself: when stock hits this number, there is still enough cover to survive until the replenishment lands. If the lead time you fed it is the supplier's clock rather than yours, the promise is broken before you make it. A reorder point built on an optimistic lead time does not fail loudly. It fails on the one order that runs long, on your best-selling variant, in the week you were running paid traffic to it.

Build the arrival log before you touch the formula

Shopify does not record when you placed a purchase order, so the data has to come from you. A spreadsheet with five columns is enough, and you only need it for the SKUs that matter.

• SKU and supplier. Group by supplier, because lateness is a habit of the supplier, not of the candle.
• PO sent date. The day you actually sent it, not the day you drafted it.
• Promised date. What they told you. You are not using this in the maths, but the gap between promised and actual is the fastest way to see who is drifting.
• Sellable date. The day the stock was counted in and available to sell. This is the date that matters. Stock sitting unreceived in your own stockroom is not stock.
• Quantity and anything odd. Short shipments, split deliveries, a batch that failed QC. You want to know later whether a long arrival was a one-off or the start of a trend.

If you have no history at all, start from the quote plus the slack you know your own process adds, order twice, and let the log correct you. Two real arrivals beat a year of guessing.

Pick the worst realistic arrival, not the worst ever

The reason to take the second-worst of ten rather than the maximum is that the maximum is usually an event, not a lead time. A strike, a factory fire, a shipping lane closing. You cannot hold permanent cover against those without tying up cash in stock that will mostly sit there. The second-worst of ten sits around the upper end of what this supplier normally does when things go against you, which is the thing you are actually trying to survive.

Some practical shapes this takes:

• Fewer than ten deliveries. With five or six, take the worst and then sanity check it. If the worst is wildly clear of the rest, step down one.
• A supplier with two modes. Air freight for top-ups, sea for bulk, with totally different clocks. Those are two lead times, not one noisy one. Record them separately and set the SKU to whichever route you would actually use for an emergency reorder.
• A long tail you keep seeing. If three of your last ten ran past 40 days, 45 is no longer an event. It is the supplier. Move the number up.

The same logic applies to how much warning you want on top, which is a separate decision from the lead time itself.

Where to put the padding

There are two honest places to absorb supplier variability. One is a separate safety stock figure. The other is to inflate the lead time itself, which is what the second-worst arrival method does.

Restoc takes the second route deliberately. The reorder point engine uses a sales velocity window you choose, 7, 14 or 30 days, and a lead time you enter per SKU, and it is implemented as one tested pure function so the same inputs always give the same number. There is no separate safety stock field. That means your lead time setting is the lever, and it has to carry both the travel time and the uncertainty. The field accepts a whole number of days between 1 and 365, validated on the server, so there is nothing stopping you entering 31 for a supplier who quotes 21.

The trade-off is real and worth saying out loud. Moving a lead time from 21 days to 31 raises the reorder point by ten days of sales, so you order earlier and hold more stock between orders. On a slow SKU that is a rounding error. On a hero SKU with high velocity it is a meaningful amount of working capital sitting in a box. The way to decide is to compare it against what a stockout on that specific SKU would cost you in lost margin and advertising you paid for twice, and then pad the ones where that comparison is lopsided. Not every SKU deserves the same caution.

How to revise the number after each delivery

Two rules keep this from becoming a monthly chore.

1. Every delivery, log the sellable date. Thirty seconds. If the new arrival is longer than your current lead time setting, raise the setting to the new arrival immediately. You just learned something and it cost you nothing to act on it.
2. Every quarter, re-read the list. Recompute the second-worst of the last ten. Lower the setting only if three consecutive arrivals came in comfortably under it. One good delivery is not a trend, and cutting the pad on one good delivery is how merchants get caught.

Seasonal suppliers deserve a third rule. If you buy from a factory that shuts for a national holiday, or a producer with a harvest window, raise the lead time six weeks before the closure and drop it after the first post-closure delivery lands. The arithmetic is not clever. It is just a calendar reminder you keep.

Doing this across hundreds of SKUs

A merchant with 50 SKUs can hold their suppliers in their head. A merchant with 900 cannot, and typing a lead time into 900 rows one at a time is not a plan.

The practical shortcut is to set lead time by supplier and only override the exceptions. Most of your catalogue comes from a handful of suppliers, and the SKUs inside one supplier usually arrive on the same truck. Pick the second-worst arrival for the supplier as a whole, apply it to everything from them, then hand-set the three or four items that come by a different route.

In Restoc today, lead time is entered per SKU on the reorder rules screen. We know that is tedious at scale, so two changes are approved and in build: syncing each SKU's Shopify vendor so you can see who supplies what on the dashboard and in the weekly report, and a vendor lead times screen that sets one number per vendor and fills in every SKU that does not have its own. We will say so here when it ships rather than before.

Once the number is in, the monitoring is the easy part. When it launches, Restoc watches stock levels against the reorder point and fires an email or Slack alert when a SKU crosses it, through a background job built to be idempotent so one crossing does not turn into five notifications. The dashboard shows current stock, days of inventory remaining and reorder status per SKU, and the weekly report lists everything below its reorder point with a suggested order quantity, viewable in the app or exported as CSV. A late supplier is survivable. A late supplier you did not see coming is the expensive version.