> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Fulfilment Delay Alert, Adobe Commerce > Fulfilment Delay Alert for Adobe Commerce stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) ## At a glance > Real-time SLA tracker that measures hours elapsed between an Adobe Commerce order entering `state = processing` (paid) and the first shipment being created against it. Fires when more than 50 orders have been sitting unshipped for over 48 hours. Designed to catch warehouse-floor problems (a packer out sick), 3PL outages (the integrator's API queue is backed up), or carrier collection failures (the courier missed pickup) before customer complaints arrive. | | | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **What it counts** | For each open order: `now() - max(updated_at WHERE state transitioned to processing)`. The card excludes orders already shipped. The "first shipment" trigger uses Adobe Commerce's `shipment` entity (a separate document, created via `POST /rest/V1/order/{id}/ship`); the existence of any shipment for an order moves it from "open SLA clock" to "shipped, no longer counted". | | **API field** | `state`, `created_at`, `updated_at` from `GET /rest/V1/orders`; shipment existence via `GET /rest/V1/orders/{id}/shipments` or by querying the `shipment` index directly. | | **VAT / tax treatment** | n/a, this is a time-elapsed alert, not a value alert. | | **Shipping inclusion** | n/a for the alert. The companion roll-up (orders by SKU category) uses `shipping_amount` to estimate logistics cost at risk. | | **Discounts** | n/a. | | **Credit Memo refund treatment** | Refunds before shipment effectively cancel the SLA clock (refunded orders move to a different state), so they self-resolve. Credit Memos issued post-shipment do not affect this card. | | **`state` machine inclusion** | Numerator is orders in `state = processing` only. Excluded: `pending_payment` (not yet paid, no SLA owed), `holded` (deliberately frozen by ops), `complete` (already invoiced and typically shipped), `closed`, `canceled`. | | **`pending_payment` quirk** | Excluded by design. SLA only starts when the customer has paid. A flood of `pending_payment` orders does not count toward fulfillment delay; check [Order State Distribution](/nerve-centre/kpi-cards/adobe-commerce/order-state-breakdown) for that signature. | | **`holded` quirk** | Adobe Commerce uniquely supports a `holded` state where ops manually pauses an order (typical use: fraud review, B2B credit check, custom-make order awaiting design approval). Holded orders do not count, the SLA clock pauses while held and resumes on un-hold. This is correct: a 5-day fraud review should not flag fulfillment delay. | | **Multi-currency `grand_total` vs `base_grand_total`** | n/a for the alert (count-based). The companion "value at risk" estimate uses `base_grand_total` to roll up across currencies. | | **Store View scope (`store_id`)** | All Store Views by default. For multi-warehouse Adobe Commerce installations using MSI source-stocks, configure per-source variants if your warehouses operate independently. | | **Time window** | `RT` (real-time). | | **Alert trigger** | `>50 orders unshipped >48h`. The 48-hour window matches typical merchant promise; the 50-order threshold filters routine variance from genuine backlog. | | **Sentiment key** | `fulfillment_rate` | | **Roles** | owner, operations | ## Calculation Calculated automatically from your Adobe Commerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example A nutritional supplements brand on Adobe Commerce 2.4.6 with a US Store View, a UK Store View, and a B2B portal. Two 3PL warehouses (US: ShipBob Carlsbad, UK: Huboo Bristol). The merchant promises 24-hour dispatch on consumer orders and 72-hour dispatch on B2B orders. Snapshot taken Friday 22 Apr 26, 16:00 GMT. The alert just fired. **Open orders by warehouse and age:** | Warehouse | \<24h | 24-48h | >48h | Total open | | ------------------------------- | ----- | ------ | ------ | ---------- | | US (ShipBob Carlsbad) | 142 | 38 | 14 | 194 | | UK (Huboo Bristol) | 86 | 110 | **74** | 270 | | B2B (manual fulfilment from HQ) | 12 | 8 | 3 | 23 | | **Total** | 240 | 156 | **91** | **487** | **Alert trigger met:** 91 orders > 48h unshipped, well past the 50 threshold. **Drilldown:** | Warehouse | Median age of >48h cohort | 7-day baseline | Variance | | --------- | ------------------------- | -------------- | ------------------------- | | US | 53h | 47h | within range | | UK | **71h** | 38h | **+87%, anomalous** | | B2B | 60h | 60h | as expected (B2B 72h SLA) | What this is telling operations: 1. **The UK warehouse is the problem.** 74 of the 91 over-SLA orders are at Huboo Bristol. Median age in the over-SLA cohort is 71 hours, almost a full day past the SLA breach. 2. **The US warehouse is operating within normal variance.** 14 orders over 48h is light backlog, not a regression. 3. **The B2B portal at 60 hours is expected** because that 3-order cohort is in the merchant's promised 72h B2B SLA. They are not yet in breach. 4. **Investigation reveals**: Huboo Bristol's pick-pack staffing dropped Wednesday afternoon (a packer called in sick, the planner did not flex) and the backlog has compounded over Thursday and into Friday morning. Carrier pickup at 14:00 today only cleared the 24-hour-old cohort. 5. **Action**: weekend overtime for two pickers will clear the backlog by Sunday evening. Customer service should send proactive "shipping delayed by 1 to 2 days" emails to the 74 affected customers (Adobe Commerce admin > Sales > Orders > select with filter > Email Update). This converts a complaint into a positive (proactive comms is itself a retention signal). 6. **Revenue at risk**: 74 affected orders × \~$58 average UK consumer AOV = ~$4,290 of potential cancellations and refunds if the delay extends past 96 hours. Adobe Commerce will not auto-cancel, but customers do request refunds at the 4-day mark in measurable numbers. The point of this card: a Friday afternoon detection of a Wednesday-origin staffing issue is exactly the lag operations needs to absorb to get the weekend rescue in place. Without this card the merchant typically discovers the backlog from customer support tickets on Monday. ## Sibling cards merchants should reference together A fulfillment alert is most useful when triangulated against operational and customer-facing cards. | Card | Why pair it with Fulfilment Delay Alert | | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Unfulfilled Orders](/nerve-centre/kpi-cards/adobe-commerce/unfulfilled-orders) | The denominator and detail grid. The alert is a derivative of this card's open-order list filtered to >48h. | | [Fulfilment Rate](/nerve-centre/kpi-cards/adobe-commerce/fulfillment-rate) | The trailing percentage view. A 7-day fulfillment rate dropping from 96% to 88% confirms the backlog is sustained, not a single bad day. | | [Fulfilment Over Time](/nerve-centre/kpi-cards/adobe-commerce/fulfillment-rate-over-time) | The chart view. Look for the inflection point where backlog started accumulating. | | [Fulfilment Breakdown](/nerve-centre/kpi-cards/adobe-commerce/fulfillment-status) | Splits open orders by status/source/warehouse. Identifies which warehouse is the bottleneck. | | [Order State Distribution](/nerve-centre/kpi-cards/adobe-commerce/order-state-breakdown) | If `holded` orders are unusually high, ops has paused fulfillment deliberately (fraud review, credit-check queue) and the alert may be expected, not anomalous. | | [Cancellation Rate](/nerve-centre/kpi-cards/adobe-commerce/cancellation-rate) | The lagging consequence. Customers who wait past 96h cancel at a measurable rate; cancellation rate rising 2-4 days after a fulfillment alert is the cost. | | [Refund Rate](/nerve-centre/kpi-cards/adobe-commerce/refund-rate) | Same lagging effect. Some customers receive late, accept the delivery, and then refund anyway. | | [`shopify.shopify_alert_fulfilment_delay`](/nerve-centre/shopify/shopify_alert_fulfilment_delay) | Cross-platform peer for agency teams. | ## Reconciling against the vendor's own dashboard **Where to look in Adobe Commerce Admin:** Adobe Commerce ships with reasonable native fulfillment views: > **Sales > Orders** with the Status filter set to "Processing" gives the open-order list. Sort by Purchase Date ascending and the oldest unshipped orders rise to the top. Adobe does not natively compute "hours unshipped"; you have to mentally subtract the Purchase Date from now. For the shipment side: > **Sales > Shipments** lists every shipment created in the period. The lack of a shipment for a `processing` order is what this alert is detecting. For multi-source (MSI) merchants: > **Stores > Inventory > Sources** shows configured stock sources. Combined with **Sales > Orders > \[Order] > Source** assignment, you can identify which warehouse owns each unfulfilled order. Other Adobe Commerce Admin views that look relevant but are not: * **Reports > Sales > Shipping**: shipping cost aggregations, no per-order SLA detection. * **Reports > Sales > Invoiced**: invoiced amount, separate from shipment. * **Reports > Sales > Orders**: aggregated by date, no SLA dimension. * **Stores > Configuration > Sales > Shipping Methods**: configuration, not live state. **Why our number may legitimately differ from a manual Admin count:** | Reason | Direction of divergence | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | **Time-zone**. Adobe stores `created_at` and `updated_at` in server timezone (often UTC, but configurable). The card uses UTC. Hour-level boundaries can shift the >48h cohort by ±1. | ±1 order on the boundary | | **`holded` exclusion**. The card excludes orders in `holded` state. The Admin "Processing" filter does the same, but if you check the "All" status filter you'll see them. | Vortex IQ count lower than admin All-status count | | **Partial shipment**. Adobe allows partial shipments (some line items shipped, others not). The card treats any shipment as "fulfillment started"; an order with 1 of 5 items shipped no longer counts. The Admin order-status remains `processing` until all items ship. | Vortex IQ count lower for partial-ship operations | | **B2B 72h SLA**. The card's 48h threshold is consumer-oriented. B2B orders within 48-72h are not yet breached but appear in the >48h cohort. Configure per-Store-View thresholds. | Vortex IQ may flag B2B orders as breached when the merchant's own SLA allows them | | **Sync lag**. The card uses the most recent OpenSearch sync (5-15 min). Admin is live. | Vortex IQ slightly stale at the boundary | **Cross-connector reconciliation (when these connectors are connected for this merchant):** | Pair | Expected relationship | What divergence tells you | | ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 3PL connector (ShipBob, Huboo, ShipStation) order-queue depth | Should rise when this card is rising | If the 3PL queue is empty but Adobe shows backlog, the issue is the integration (orders not pushing to 3PL). If the 3PL queue is deep, it is genuine warehouse backlog. | | Carrier API tracking-event volume | Should drop when this card is rising | Carrier scan rate falling for outbound parcels confirms the warehouse is producing fewer ready parcels. | | [`stripe.stripe_chargebacks`](/nerve-centre/stripe/stripe_chargebacks) | Lagging effect, expect chargeback risk to rise 14-30 days after sustained fulfillment delays | Customers who never received goods file chargebacks when refund requests are denied. | ***
Same-metric documentation cross-reference (for agencies running multiple platforms) The same alert exists with platform-specific definitions on other commerce connectors. * [`shopify.shopify_alert_fulfilment_delay`](/nerve-centre/shopify/shopify_alert_fulfilment_delay) * [`bigcommerce.bc_alert_fulfilment_delay`](/nerve-centre/kpi-cards/bigcommerce/fulfilment-delay-alert)
## Known limitations / merchant FAQs **The alert fired but my warehouse says nothing's wrong, why?** Two common reasons. First, the issue may be in the integration layer rather than the warehouse itself: orders are sitting in Adobe Commerce in `processing` but never reaching the 3PL because the API push is failing silently. Check your integration logs (or the 3PL queue depth via the connector). Second, partial shipments: Adobe Commerce allows shipping some items but not others; an order with 1 of 5 SKUs shipped is removed from this card's count, but the warehouse view may show the remaining 4 items as outstanding work. **What's the difference between `state` and `status` and how does it affect this alert?** `state` is the system lifecycle (8 fixed values); `status` is configurable. This alert filters on `state = processing` because that's the universal "paid, not shipped" lifecycle position. Custom statuses you've layered on top (e.g. "Awaiting Pick", "Pick Complete", "Pack Complete") all sit within `state = processing` and are correctly counted by this alert. **Adobe Commerce vs Magento Open Source: any difference for this card?** The shipment entity exists in both editions and the `state` lifecycle is identical. Adobe Commerce edition adds the Order Management System (OMS) integration which can change where shipment-creation happens; if your installation uses OMS, ensure the OMS-to-Adobe webhook is firing or the card will undercount shipped orders. **Why does the card use 48 hours rather than my SLA of 24 hours?** The default threshold is consumer-norm. Configure your own threshold in the manifest if your promise is shorter (24h same-day) or longer (72h B2B). The 50-order count threshold is also tunable; very high-volume stores want it higher to filter routine variance. **My multi-warehouse Adobe Commerce, can I see per-warehouse alerts?** Yes, configure per-MSI-source variants. The default card aggregates; multi-warehouse merchants benefit greatly from per-source variants because the root cause is almost always at one specific warehouse, not the whole network. **The B2B portal has different SLAs, will the alert handle that?** Not by default. Set up a per-Store-View variant for the B2B Store View with a longer threshold (typical B2B SLA is 72 hours, sometimes 5 working days for custom-build B2B orders). Without the variant, the consumer-norm 48h threshold will spuriously flag B2B orders that are still within their own SLA. **Why doesn't `holded` count toward fulfillment delay?** Adobe Commerce's `holded` state is an explicit "operations has paused this order" signal. Common uses: fraud review, B2B credit-check queue, custom-make awaiting design approval. The SLA clock should pause while held; resuming when the order is un-held. Counting holded orders would conflate "warehouse is slow" with "ops deliberately froze it", masking the genuine problem signal. **`pending_payment` orders are sitting forever, why aren't they flagged?** This card excludes `pending_payment` because the merchant has no fulfillment obligation until the customer has paid. A flood of `pending_payment` is a different problem (gateway callback failure or net-30 PO routing issue); use [Order State Distribution](/nerve-centre/kpi-cards/adobe-commerce/order-state-breakdown) to monitor it. **My 3PL completes shipment but the Adobe order stays `processing`, why?** The 3PL needs to call back to Adobe (typically via webhook) to register the shipment. If the webhook is failing, the 3PL has shipped but Adobe doesn't know. The card will overcount unshipped orders in this scenario. Symptoms: a stable >48h cohort that doesn't grow but also doesn't drain. Check your 3PL integration's webhook status and replay any failed deliveries. *** ### Tracked live in Vortex IQ Nerve Centre *Fulfilment Delay Alert* is one of hundreds of KPI pulses Vortex IQ tracks across Adobe Commerce and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.