Delivered orders only, timing is estimated (see note below table)
Loading…
Supplier Health
Click headers to sort
Loading…
Time to Fulfill
Ready to Ship → In Transit · tap a card for the weekly trend
Loading…
How this is computed: there's no dedicated per-package status-history table in the backend, so cycle time is package_order.createdAt (when assigned to the supplier) to package_order.modifiedAt (verified to match delivery time within ~1 second for the package that actually fulfilled the order). Reassignments between suppliers are sequential, not concurrent, so this is cleanly attributed per supplier. Time to Fulfill is package_order.createdAt to checkout_order.inTransitAt — a ship-vs-deliver split using inTransitAt was dropped once before after finding bulk-backfilled timestamps clustered across unrelated orders, but it's been re-verified on recent data (zero duplicate timestamps in the last 30 days, plausible per-supplier variance) and is safe to use for recent windows; re-check for clustering before trusting it on older/historical ranges. Cancel %, reassigned-away, and time-to-fulfill are based on orders assigned in the window (so a supplier that ships nothing still shows up, with its unshipped backlog and how long it's been waiting); cycle time is based on orders delivered in the window — different cohorts, so the counts won't match exactly. For FedEx-labelled shipments, inTransitAt is when the label/status was set, not when FedEx physically collected the package — the backend doesn't store a pickup timestamp (see the Not Yet Picked Up table on the main page for currently-stuck shipments).