At a glance
Daily fulfillment rate over trailing 90 days, expressed as % of orders shipped within the merchant’s promised SLA. The trend chart for Fulfilment Rate. Captures multi-week patterns (3PL queue depth, holiday-season backlog, seasonal staffing changes) that point-in-time fulfillment metrics miss.
Calculation
Worked example
A nutritional supplements brand on Adobe Commerce 2.4.6, US ShipBob and UK Huboo 3PLs, B2B in-house fulfillment from HQ. SLA: 48h consumer, 72h B2B. 90-day window ending Monday 4 May 26. 90-day fulfillment overview:
Notable dips in the 90-day series:
What this is telling operations:
- 94.2% average is in the healthy range. Best-in-class is 96%+; below 90% sustained needs intervention.
- The 9 below-90% days cluster around 3 incidents, not random variance. Each had an identifiable operational cause.
- The 18-22 Apr UK staffing dip is the single largest issue; 5 days at 84% means roughly 16% of orders breached SLA across that week. Cross-check with Fulfilment Delay Alert firings for that period.
- The Mar 5-7 stock-recount disruption is a known operational cost; if recounts happen quarterly, the fulfillment dip is predictable. Communicate proactively to customers in advance to manage expectations.
- The 12 Feb single-day dip (73%) was a pure carrier issue (UPS pickup missed), self-resolved next day. Acceptable, no systemic action needed.
- The 7-day moving average shows a slight upward trend from 93.8% (12 weeks ago) to 94.6% (latest week). Operational-maturity gain, possibly from the merchant’s recent introduction of pre-pick batching at Huboo.
- Action: review UK warehouse staffing-flex policy (the Apr staffing dip would have been caught earlier if the planner had access to forecast volume); consider proactive customer-comms for known disruption days.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Adobe Commerce Admin:Reports > Sales > Shipping for shipment counts and aggregates. Adobe doesn’t natively compute on-time rates; manual computation requires per-order time-since-payment vs SLA.
Sales > Orders with state filter and date range; manual export and analysis for SLA breach detection.
Sales > Shipments lists every shipment created in the period.Why our number may legitimately differ from a manual Admin computation:
Cross-connector reconciliation (when these connectors are connected for this merchant):
Known limitations / merchant FAQs
Why does the chart use 48h consumer SLA, my promise is 24h? Configure the manifest to your actual SLA. The 48h default is industry-norm; merchants with same-day or 24h promises should configure tighter. Per-Store-View thresholds are also supported (B2B 72h, consumer 48h, premium 24h on the same merchant). Adobe Commerce vs Magento Open Source: difference? None at the calculation. Both editions have the shipment entity and state machine. My multi-store, can I overlay Store Views on the chart? Yes, configure per-Store-View series. Useful when each warehouse serves a specific Store View; per-warehouse trend shows operational health independently. A single bad day (carrier issue) tanks my 7-day moving average; how to filter? Use the per-cause analysis. The card surfaces the dips; the operational team annotates known causes. The Vortex IQ workspace allows incident annotations against the chart so the dip explanation is preserved. Why includepending_payment orders in the denominator?
They’re not in the denominator on this card. Only orders that have entered processing (paid) count toward the SLA-eligible denominator. pending_payment is excluded because SLA hasn’t started.
Why does the on-time rate sometimes spike to 99%+?
Quiet days (single-digit order count) can show 100% on a single shipment. The 7-day moving average smooths this; raw daily numbers can be volatile.
Partial shipments confuse the metric, how does the card handle them?
Default: any shipment for an order moves it to “fulfillment-started” and counts as on-time if within SLA. For stricter “all items shipped” measurement, configure the manifest. The default is operational-pragmatic; the strict view is service-promise-rigorous.
Why does my customer service team see different SLA breach numbers?
Customer service usually counts breaches as “customers contacted us about a delay”, which understates breach count (most customers don’t complain on day 3, only on day 5+). The card counts SLA breaches by definition (over the threshold), regardless of customer notification.