Skip to main content
Card class: HeroCategory: Marketplace
Orders downloaded from /download/orders that haven’t been dispatched yet.

At a glance

Live count of Alibris orders downloaded from /download/orders that haven’t yet been dispatched (no confirm-shipment event recorded). The workload view: how many books are queued for picking, packing, and shipping right now. Alerts when the count exceeds 2x the 30-day average, signalling either a volume spike or a fulfilment-team capacity problem.
What it countsCOUNT(orders WHERE status='CONFIRMED' AND dispatch_confirmed_at IS NULL AND status NOT IN ('CANCELLED', 'REFUNDED')). Includes orders within their dispatch_due_by budget (typical state) and orders past their deadline (which also appear on Late Order Processing Queue).
API endpoint + reportComputed locally from the Alibris Inbound Orders feed. Recomputes every 4 hours; updates in real time as confirm-shipment events land.
SeverityP2 baseline, P1 above 2x avg. Normal operating queue is healthy; a 2x spike means workload exceeds team capacity.
Why it differs from Late Order Processing QueuePending Dispatch shows ALL undispatched orders (most still within their budget). Late Order Processing Queue shows ONLY orders past their deadline. The two together: this is the workload view; Late Order is the alert view.
Fees / commissionNot applicable directly. Indirect: undispatched orders represent gross-of-commission revenue not yet earned.
Refunds / cancellationsCancelled and refunded orders excluded. Cancellation moves the order to Cancellation Rate.
CurrencyNot applicable.
Healthy rangesA bookseller doing 22 orders/day with 2-business-day handling typically carries 35 to 55 orders pending at any time (roughly 2.5x daily volume). Above 110 (2x average) is the trigger.
Common causes of spikes(1) Volume surge (back-to-school, holiday, promotion), ~30%. (2) Staff absence / illness, ~28%. (3) Confirm-shipment cron broken, dispatched-but-not-confirmed orders inflate the count, ~22%. (4) Inventory mismatch caused order-acceptance backlog, ~12%. (5) Other, ~8%.
Multi-marketplace overlapPer-marketplace queue. The same fulfilment team handles all marketplaces; spikes here often correlate with AbeBooks Pending Dispatch.
Time windowRT (live count, refreshed every 4 hours).
Alert trigger>2x 30D avg, the threshold where capacity is exceeded.
Rolesowner, operations.

Calculation

Calculated automatically from your Alibris 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 US bookseller, 22 orders/day average on Alibris, 2-business-day handling. Snapshot 01 May 26 09:00 UTC.
BucketOrdersNotes
Within 0 to 50% of dispatch budget28Healthy, just-arrived orders
Within 50 to 75% of dispatch budget22On-track, workload normal
Within 75 to 100% of dispatch budget38At-risk, prioritise today
Past dispatch_due_by8Already late (also on Late Order Processing Queue)
Total Pending Dispatch (this card)96(30D avg = 48; ratio 2.0x)
The card reads 96; alert is firing (threshold >2x 30D avg = 96). Six things to notice that are specific to Alibris and the book trade:
  1. The 38 at-risk orders are the urgent action set. Each one is within 6 to 12 hours of becoming an SLA breach. Triage today’s work to clear this bucket first; the on-track and just-arrived buckets can wait until tomorrow.
  2. The 8 already-late orders are the highest-cost work. Each one is dragging Dispatch SLA Compliance. Expedite-ship them with courier upgrade today; the SLA hit per order outweighs the courier cost.
  3. The 2.0x ratio is right at the alert threshold. Investigate cause: was Friday a volume-spike day with 35+ new orders? Did a staff member call in sick on Monday? The 30-day average represents normal workload; sustained 2x means underlying capacity issue.
  4. Confirm-shipment cron is the most under-suspected cause of inflated counts. If the cron fails or runs too infrequently, dispatched orders linger in the “pending” bucket for 6 to 24h longer than reality. Check Last Successful Upload for the outbound-confirm side.
  5. Cross-marketplace correlation matters. The same bookseller’s AbeBooks Pending Dispatch on the same date shows 78 (2.0x avg). Co-spiking on both AbeBooks and Alibris confirms a fulfilment-team capacity issue, not a marketplace-specific problem.
  6. Library Services orders extend the window. Alibris Library Services (institutional buyers) often have longer-than-standard dispatch windows (3 to 5 business days). Listings tagged buyer_type=INSTITUTION fall into the longer bucket; their presence inflates the count without inflating risk. Filter to non-institutional for a sharper view.

Sibling cards merchants should reference together

Pending Dispatch is the workload view. Pair with these:
CardWhy pair it with Pending Dispatch
Late Order Processing QueueThe breach view. Pending Dispatch + Late together: workload AND breach.
Dispatch SLA ComplianceThe aggregate metric. A spike here precedes SLA decline by 24 to 72h.
Avg Time to Process (hrs)Distribution view of fulfilment latency.
Inbound Orders File LagIf feed is slow, your dispatch budget is already eroded when orders appear.
Last Successful UploadConfirm-shipment failures inflate this card; check both.
Cancellation RateCompanion budget. Cancellations clear orders from this queue but cost on the cancellation metric.
AbeBooks Pending DispatchSibling marketplace; co-spike confirms capacity issue.

Reconciling against the vendor’s own dashboard

Where to look in the Alibris seller dashboard:
  1. Sellers → Manage Orders → filter by Pending. Per-order detail with dispatch_due_by deadline.
  2. Sellers → Performance Dashboard. The aggregate fulfilment view.
Why our number may legitimately differ from Alibris’s UI:
ReasonDirectionWhy
Refresh cadenceOurs updates every 4hAlibris UI is real-time; this card recomputes on the inbound feed cadence.
Time zoneBoundary effectsAlibris uses US Pacific Time on .com; the connector uses UTC.
Outbound-confirm latencyOurs can show pending even when Alibris shows shippedConfirm-shipment events delayed by cron schedule inflate this count.
Institutional handling windowDifferent bucketingLibrary Services orders have longer dispatch windows; not all UIs surface this clearly.
Cross-connector reconciliation:
CardExpected relationshipWhat causes legitimate divergence
abebooks.ab_pending_dispatchCo-correlated when fulfilment team is shared.Marketplace-specific dispatch windows differ slightly.
amazon.amzn_pending_ordersDifferent tracking, similar concept.Amazon’s clock starts at payment, Alibris at confirmation.

Known limitations / merchant FAQs

The card just hit 96, double the average. What do I do today? Three actions: (1) Drain the at-risk bucket (orders within 75 to 100% of dispatch budget) first. (2) Verify confirm-shipment cron is running; if dispatched-but-unconfirmed orders are inflating the count, that’s a feed issue not a workload issue. (3) If genuine workload spike, add capacity (overtime, extend handling time temporarily, or pause new listings until queue drains). Why does this card differ from Alibris’s pending-orders count? Alibris UI is real-time; this card refreshes every 4h. Confirm-shipment latency (your cron schedule) can show “pending” here for up to 4 hours after Alibris UI shows shipped. Run cron every 15 minutes to minimise. ISBN match quality, can it cause inflation here? Indirectly. Books that staff can’t find on the shelf (because the inventory ISBN doesn’t match the physical book) sit in the pending queue longer while staff search or escalate. Better intake-ISBN-capture reduces this latency. Multi-marketplace, should I drain Alibris first or AbeBooks first when both queues spike? Drain by financial impact: rare-book orders first regardless of marketplace, then by hours-to-deadline ascending across both. Don’t bias by marketplace; bias by per-order penalty. Library Services / institutional buyers, do they need different treatment? Yes. Their longer dispatch windows mean less urgency, but their high AOV and feedback weight mean higher per-order reputational stakes. Treat institutional orders as P2-but-handle-carefully; they don’t drag your average dispatch but they DO drive the high-value cohort. Listing-quality / Buy Box impact, when does the queue spike hurt my ranking? When pending dispatch correlates with rising late-dispatch ratio. The queue itself isn’t visible to Alibris’s ranking system; the SLA breach downstream is. Watch Dispatch SLA Compliance as the actual ranking input. Inventory-sync lag, can it inflate this card? Yes. Stockout orders (book sold elsewhere first) sit in the pending queue until the seller cancels them. Real-time inventory sync prevents the order from being accepted in the first place. Rare books vs commodity, queue treatment difference? Rare books require longer pick-and-pack time (find in rare-book room, condition-check, careful packaging). Most booksellers run a single 2-day handling time which is tight on rare. Setting handling_time=3 on rare-tagged listings absorbs 90% of the rare-book queue pressure. Why doesn’t Alibris show me this view? Alibris’s pending-orders page exists but lacks the 30-day-baseline comparison. The “2x average” alert is a Vortex IQ-derived threshold; Alibris’s own UI shows count without trend context. When does the alert auto-clear? When the count drops below 2x 30D average. The 30D average updates daily, so the alert may persist through a sustained higher-volume period until the average rises to match.

Tracked live in Vortex IQ Nerve Centre

Pending Dispatch is one of hundreds of KPI pulses Vortex IQ tracks across Alibris 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.