> ## 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. # Avg Order Fulfillment Time, Ecwid > Avg Order Fulfillment Time: average hours from order paid to order shipped or fulfilled. How to read it, why it matters, and how to act on it. **Card class:** [Non-Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > Average time from order paid to order shipped or fulfilled. ## At a glance > Average hours from the moment an order is marked `PAID` to the moment it moves to `SHIPPED` or `FULFILLED` over the rolling 30D window. For an Ecwid merchant this is the truest single read on operational health, it measures how long a paid customer waits before their order leaves the bench. Ecwid is an embedded-widget platform, so the merchant is usually the person packing the box; this card tells them whether the queue is keeping pace with sales. | | | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `AVG(fulfilled_at - paid_at)` in hours, across orders whose status reached `SHIPPED` or `FULFILLED` with `paid_at` inside the rolling 30D window. Orders never fulfilled in the window are excluded from the average (they live in the backlog cards instead). | | **API endpoint** | `GET /v3/{store-id}/orders` (paged, max 100 per call, OAuth2 with `read_orders` scope). The engine reads each order's `paymentStatus`, `fulfillmentStatus`, and status-change timestamps. Webhook updates fire on `order.updated` and `order.paid`. | | **Clock start** | `paid_at` (the order reaches `PAID`), not order-created. This is deliberate: an order sitting in `AWAITING_PAYMENT` is not yet the merchant's job to fulfil. | | **Clock stop** | The first transition to `SHIPPED` or `FULFILLED`, whichever Ecwid records first for the store's fulfilment model. | | **Weekends / holidays** | Counted as raw wall-clock hours. A small Ecwid store packing on weekdays will see weekend orders inflate the average; this is real customer-experienced wait, so the card does not strip it. | | **POS / in-person** | Ecwid POS (Lightspeed Retail / Ecwid Mobile) orders are usually fulfilled instantly, so they pull the average down. If a store mixes online and POS heavily, expect a lower blended number. | | **Digital products** | Auto-fulfilled at payment, so their fulfilment time is near zero. A store selling mostly downloads will show a very low average; this is correct. | | **Currency** | number (hours). Dimensionless duration, not a money value. | | **Time window** | `30D vsP` (rolling 30D vs prior 30D). | | **Alert trigger** | `>48h`. Average fulfilment exceeding two days signals the queue is falling behind customer expectation. | | **Sentiment** | `ecwid_avg_order_fulfillment_time`. Inverse: lower is better. | | **Roles** | owner, operations. | ## Calculation Calculated automatically from your Ecwid 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 small UK candle maker running an Ecwid widget on their Wix site, rolling 30D ending 27 Apr 26.** The maker pours, cures, and packs everything by hand from a home studio. They pack Tuesday and Friday evenings around a day job. Stripe is the primary payment method, and most orders ship via a tracked second-class courier. | Metric | This 30D | Prior 30D | Change | | -------------------------------------- | -------- | --------- | ------ | | Orders fulfilled | 92 | 71 | +29.6% | | Avg Order Fulfillment Time (this card) | 53.4h | 31.2h | +22.2h | | Pending orders at period end | 14 | 5 | +9 | | Orders shipped same day | 11 | 22 | -11 | ```text theme={null} Clock start: paid_at (order reaches PAID) Clock stop: first transition to SHIPPED / FULFILLED Average: AVG(fulfilled_at - paid_at) = 53.4h Alert floor: 48h -> breached ``` **What it means for this candle maker.** Fulfilment has slipped from a healthy 31 hours to 53 hours, above the 48h alert. The cause is visible in the adjacent numbers: orders fulfilled rose 30% but same-day shipments halved and the pending pile grew by nine. The maker is selling faster than they can pour. Because curing time is fixed (a candle needs to set before it can ship), volume growth without a second pour batch each week pushes the queue out. For an Ecwid hobby-to-small merchant this is the card that turns a vague "I feel behind" into a concrete number a partner or a part-time helper can act on. The fix is not a discount or an ad tweak, it is capacity: add a Sunday pour session, pre-cure a buffer of the top three scents, or temporarily mark slow-curing variants as made-to-order with a stated lead time so the expectation is set at checkout rather than broken after it. If the number had risen because of a single stuck order (one custom wedding-favour batch waiting on a supplier), the average would be skewed by an outlier rather than a systemic backlog. Always sanity-check the average against [Pending Orders](/nerve-centre/kpi-cards/ecwid/pending-orders) and [Order Processing Backlog](/nerve-centre/kpi-cards/ecwid/order-processing-backlog) before deciding whether the problem is one order or the whole queue. ## Sibling cards merchants should reference together | Card | Why it matters next to fulfilment time | What the combination tells you | | -------------------------------------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------ | | [Pending Orders](/nerve-centre/kpi-cards/ecwid/pending-orders) | The live queue. | Fulfilment time rising + pending rising = the backlog is real and growing, add capacity. | | [Order Processing Backlog](/nerve-centre/kpi-cards/ecwid/order-processing-backlog) | Aged-order signal. | Long average driven by a few aged orders points to stuck items, not whole-queue slowdown. | | [Awaiting Payment Orders](/nerve-centre/kpi-cards/ecwid/awaiting-payment-orders) | Pre-fulfilment stage. | Confirms whether the clock should even be running; awaiting-payment orders are not yet your job. | | [Total Orders](/nerve-centre/kpi-cards/ecwid/total-orders) | Volume context. | Volume up + fulfilment time up = capacity-bound; volume flat + time up = a process problem. | | [Cancellation Rate](/nerve-centre/kpi-cards/ecwid/cancellation-rate) | Downstream cost. | Slow fulfilment drives "where is my order" cancellations; watch both together. | | [Refund Rate](/nerve-centre/kpi-cards/ecwid/refund-rate) | Quality knock-on. | Rushed fulfilment to clear a backlog often raises packing errors and refunds. | | [Out-of-Stock Products](/nerve-centre/kpi-cards/ecwid/out-of-stock-products) | Hidden delay cause. | Orders waiting on a restock inflate fulfilment time without being a packing problem. | | [Avg Order Fulfillment Time (30D)](/nerve-centre/kpi-cards/ecwid/avg-order-fulfillment-time) | Trend anchor. | The same metric over the period frames whether today's reading is on-pattern. | ## Reconciling against Ecwid **Where to look in Ecwid's own dashboard:** > **Ecwid Control Panel (`my.ecwid.com`) -> My Sales -> Orders** > Filter to orders fulfilled in the window, then compare each order's "Paid" timestamp against its "Shipped" timestamp. Ecwid does not surface an average natively, so this is a manual spot-check rather than a single tile. For a quick gut-check, sort the order list by "Shipped" date and eyeball how far behind "Paid" date the recent shipments are running. **Why our number may differ:** | Reason | Direction | Why | | --------------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **No native average** | n/a | Ecwid shows per-order timestamps but no average tile; there is no single number to diff against, only a manual recompute. | | **Time zone** | Boundary days | Ecwid records timestamps in the store's configured time zone; we compute durations in UTC. Durations are time-zone invariant, but window membership at the edges can shift an order in or out. | | **Status model** | Either | Stores that use only `SHIPPED` and stores that use a custom fulfilment flow may stop the clock at slightly different events; we stop at the first `SHIPPED`/`FULFILLED` transition. | | **Excluded orders** | Ours often lower variance | Orders never fulfilled in the window are excluded from our average; a manual count that includes still-open orders as "very late" will read higher. | | **Sync lag** | Marginal | Webhook-driven; the most recent few minutes of status changes may not be in yet. | **Internal identity:** `ecwid_avg_order_fulfillment_time = AVG(fulfilled_at - paid_at)` in hours, over orders fulfilled within the 30D window. ## Known limitations / merchant FAQs **What counts as the start of the clock, order placed or order paid?** Order paid. An order sitting in `AWAITING_PAYMENT` is not yet something you can fulfil, so the clock starts when Ecwid marks the order `PAID`. If you want to watch the pre-payment stage, use [Awaiting Payment Orders](/nerve-centre/kpi-cards/ecwid/awaiting-payment-orders). **My average jumped but I do not feel behind. What happened?** Almost always one stuck order skewing the mean. A single custom or pre-order item waiting on a supplier can pull a small store's average up by many hours. Check whether the rise is broad (the whole queue is slow) or narrow (one or two aged orders) using the backlog card. **Do weekends count?** Yes, as raw wall-clock hours. If you pack only on weekdays, weekend orders genuinely wait longer and customers feel that wait, so we do not strip non-working days. If most of your sales land Friday night, expect the average to run higher than your "working hours" instinct. **Does Ecwid POS pull the number down?** Yes. In-person POS orders are usually fulfilled at the point of sale, so their fulfilment time is near zero and they drag the blended average lower. A store mixing heavy POS with online will read faster than an online-only store with the same packing speed. **What about digital products and downloads?** They auto-fulfil at payment, so their fulfilment time is effectively zero. A store selling mostly downloads will show a very low average, which is correct, the customer really did get their file instantly. **Why is the alert at 48 hours?** Two days is the common small-merchant expectation ceiling before "where is my order" emails start. It is a configurable default; a made-to-order maker with a stated lead time may set it higher, a same-day-dispatch store may set it lower. **My store sells made-to-order items with a 2-week lead time. This card looks awful. What do I do?** Either raise the alert threshold to match your stated lead time, or split made-to-order variants onto their own profile so the average reflects your in-stock shipping speed. The card measures wall-clock time honestly; it does not know your advertised lead time. **How fresh is this card?** Webhook-driven, typically within a few minutes of an order changing status. The 30D average recomputes on each dashboard render. **Why are orders I never shipped not in the average?** Because an unfulfilled order has no stop timestamp, so it has no duration to average. Those orders show up in the backlog and pending cards instead, which is where a growing pile of unshipped orders belongs. *** ### Tracked live in Vortex IQ Nerve Centre *Avg Order Fulfillment Time* is one of hundreds of KPI pulses Vortex IQ tracks across Ecwid 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.