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.
| What it counts | Per day: COUNT(orders shipped within SLA hours of payment) / COUNT(orders that should have shipped that day). SLA is configurable per merchant (default 48h consumer, 72h B2B). The chart is the percentage series; companion absolute count series available. |
| API field | state, created_at, updated_at from GET /rest/V1/orders; shipment existence via shipment index. |
| VAT / tax treatment | n/a, time-and-count metric. |
| Shipping inclusion | n/a. |
| Discounts | n/a. |
| Credit Memo refund treatment | An order shipped within SLA then later refunded still counts as “shipped on time”. |
state machine inclusion | processing and beyond count toward the denominator; orders with at least one shipment count toward the numerator. |
pending_payment quirk | Excluded; SLA clock only starts when payment captured. |
Multi-currency grand_total vs base_grand_total | n/a. |
Store View scope (store_id) | All Store Views; per-Store-View overlays useful when warehouses serve different regions independently. |
| Time window | 90D daily granularity. |
| Alert trigger | None by default; pair with Fulfilment Rate for alerts. |
| Roles | owner, operations |
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:| Metric | Value |
|---|---|
| Average daily on-time rate | 94.2% |
| Standard deviation | 3.4 pts |
| Lowest day on-time rate | 78% (single bad day, Friday 22 Apr) |
| Highest day on-time rate | 99% (typical Tuesday) |
| Days below 90% threshold | 9 of 90 |
| Period | Median rate | Cause |
|---|---|---|
| 18-22 Apr 26 (5 days) | 84% | UK warehouse staffing dip (packer absent) |
| 5-7 Mar 26 (3 days) | 82% | US warehouse stock-recount disruption |
| 12 Feb 26 (single day) | 73% | UPS pickup truck delay; backlog cleared next day |
- 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
| Card | Why pair it with Fulfilment Over Time |
|---|---|
| Fulfilment Rate | Single-period summary. |
| Fulfilment Delay Alert | Real-time alerting for breaches. |
| Unfulfilled Orders | Current-state pipeline. |
| Fulfillment Breakdown | Cross-state distribution. |
| Total Orders | The volume context (a 90% rate on a busy day is more material than on a quiet one). |
| Refund Rate | Lagging effect; sustained SLA breaches drive refunds. |
| Cancellation Rate | Lagging effect on customer-cancels. |
shopify.fulfillment_over_time | Cross-platform peer. |
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:
| Reason | Direction of divergence |
|---|---|
| SLA threshold. Card uses a configurable threshold (default 48h consumer, 72h B2B). Manual analysis using a different threshold gives different results. | Material if thresholds differ |
| Time-zone. Admin in Store View timezone; card UTC. Day-bucket assignment can shift by ±1. | Negligible at 90D |
pending_payment exclusion. SLA clock only starts at payment capture. Admin export may include pending-state in the count. | Card rate higher than naive admin computation |
| Partial shipments. Adobe allows partial shipments. Card treats any shipment as fulfillment-started. Stricter SLAs (all items shipped) yield lower rates. | Card rate higher than strict definition |
| Sync lag. Card uses OpenSearch sync; Admin live. | Negligible at 90D |
| Pair | Expected relationship | What divergence tells you |
|---|---|---|
| 3PL on-time-shipment reports | Should align within sync lag | Material divergence indicates either off-platform shipments or SLA-definition difference. |
| Carrier API tracking | First-scan timestamp ≈ Adobe shipment-create | Lag indicates carrier handover delay. |
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.