Vendor reliability and the math of reorder

Memory averages weight recent events too heavily. The vendor that missed last Friday's delivery feels worse than the one who's been steady for 8 months but missed twice in March. The data says the opposite: 2 misses in 12 months is a 16% miss rate; 1 miss in the past week from an otherwise-steady vendor is statistical noise.

Each signal answers a different operational question. A vendor that's strong on one and weak on another is a different problem than a vendor that's weak on all three.

A vendor with 95% fill rate but 60% on-time delivery isn't unreliable — they're slow. You can plan around slow if the lead-time stddev is low. A vendor with 70% fill rate is something else: they're committing to volume they can't deliver, and that's a different conversation.

Classic reorder formula: reorder point = (avg daily demand × lead time) + safety stock. The safety stock multiplier is where vendor reliability shows up. The shorthand we run:

• Reliable vendor (fill rate ≥ 92%, lead-time stddev ≤ 1d): safety stock = avg daily demand × 3 days
• Mid-tier vendor (fill rate 80-91%, OR lead-time stddev 2-4d): safety stock = avg daily demand × 7 days
• Unreliable vendor (fill rate < 80%, OR lead-time stddev > 4d): safety stock = avg daily demand × 14 days, AND consider dual-sourcing
• New vendor (< 5 deliveries): safety stock = avg daily demand × 10 days until you have data

Once you have the rolling 90-day signals, vendor decisions become legible. Three actions, with the data threshold for each:

1. 1**Drop** — fill rate < 70% sustained over 90 days, OR on-time rate < 50%, OR repeated delivery-quality complaints. The conversation: 'Your data on us shows X. We can't run that risk; we're going to source elsewhere starting [date].' Documented, polite, final.
2. 2**Promote** — fill rate ≥ 95%, on-time ≥ 90%, lead-time stddev ≤ 1 day. The conversation: 'Your data shows you're our most reliable vendor in [category]. We want to consolidate volume to you. What does that unlock on price?' This is where reliability data earns its margin.
3. 3**Negotiate** — mid-tier vendor where the math says they're worth fixing. The conversation isn't a threat; it's data: 'Your fill rate this quarter was 82%, down from 91% Q4. Walk me through what changed and what your plan is.' Half the time the answer is solvable; the other half you have data to drop them.

Cannabis vendor reliability data has structural quirks that don't appear in other retail. Worth understanding so the math doesn't lie to you.

• **Lab-test failures** look like fill-rate gaps but aren't a vendor reliability issue per se. A producer whose lot fails QA isn't 'unreliable' — they're being correctly blocked. Track these separately so the metric isn't poisoned. WAC 314-55-079 5% lab-test passthrough applies but the underlying reliability question is different.
• **Brand aliases** — the same vendor might appear under multiple SKU prefixes ('NWCS' / 'Northwest Cannabis Solutions' / 'Northwest Cannabis'). If your data isn't deduped on aliases, every vendor's metrics look worse than they are. Bake the alias map into the vendor table; refresh quarterly.
• **Allocation cycles** — recreational producers cycle through allocation periods where the same brand can be 'in stock' or 'allocated' depending on the month. A vendor's fill-rate dropping during an allocation period isn't reliability failure, it's a market dynamic. Tag the period in the metric so you don't drop a vendor for surviving the same allocation everyone else is.
• **Same-LLC purchasing** — multi-location operators under one LLC may consolidate POs to a vendor. If you split the vendor's reliability metric across locations naively, you double-count the same delivery. Aggregate at the parent_llc level.

The data is automatable. The vendor relationship is not. Some explicit lines:

• Don't auto-place POs based purely on the threshold. The system suggests; the operator confirms. Most stockouts caused by 'auto-PO went out wrong' are bigger than the stockouts the system was trying to prevent.
• Don't auto-drop vendors below a threshold. Surface the candidates; the buyer makes the call after talking to the vendor.
• Don't auto-tag a delivery as 'late.' Systems-of-record promises and reality can disagree by a day for legitimate reasons (delivery driver took a different route, paperwork mismatch). Late-tagging needs a 24-hour grace before it lands in the metric.
• Don't share reliability data across operators (per CannAgent's tier-separation framework). Vendor data is the operator's data; cross-retailer aggregation is a different product that requires WSLCB express permission per the vendor-intelligence risk memo.