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.

Metrics type: Supporting Metrics • Category: Ecommerce Platform

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

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 and 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	The live queue.	Fulfilment time rising + pending rising = the backlog is real and growing, add capacity.
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	Pre-fulfilment stage.	Confirms whether the clock should even be running; awaiting-payment orders are not yet your job.
Total Orders	Volume context.	Volume up + fulfilment time up = capacity-bound; volume flat + time up = a process problem.
Cancellation Rate	Downstream cost.	Slow fulfilment drives “where is my order” cancellations; watch both together.
Refund Rate	Quality knock-on.	Rushed fulfilment to clear a backlog often raises packing errors and refunds.
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)	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.

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 or book a demo to see this metric running on your own data.