Dark store dispatch operations: the mechanics behind sub-15-minute quick commerce

Dark store dispatch operations: the mechanics behind sub-15-minute quick commerce

A dark store is not a small warehouse. It is a time-compressed, high-turn dispatch node where pick, pack, and rider-handoff must complete in under six minutes for a 10-minute delivery SLA to be possible. The operators running quick commerce at scale have built this as a tightly choreographed sequence, not as a loose sum of independent processes.

One of Asia’s largest quick-commerce arms with 5M+ orders/month across 200+ dark stores runs this choreography on Shipsy — see a detailed case study. The mechanisms underneath apply to every serious quick-commerce operator, whether in MENA, LATAM, SEA, or Europe.

The six-minute store-side clock

When a customer taps “buy” in a quick-commerce app, the store-side clock starts. Every second allocated to a non-delivery activity — pick, pack, handoff — is a second stolen from the rider’s delivery window. Operators hitting a 10-minute end-to-end SLA typically budget as follows:

Five and a half minutes of store-side budget for a 10-minute promise. Any mechanism that eats into that budget — an out-of-stock, a pick path that zig-zags the store, a rider who has not yet arrived at handoff — directly threatens the SLA.

The four mechanisms that protect the six-minute clock

Mechanism one — pick-path optimization inside the store. Shipsy’s dark-store module assigns picks in an optimal sequence for the physical store layout, not in the order items were added to the cart. A customer who added milk, chocolate, bread, and milk alternative gets picked as a single path through the store’s physical layout — bread aisle first, dairy second, sweets third — not in cart order.

Mechanism two — predictive rider pre-positioning. Atlas, the Shipsy control tower, forecasts order arrival rates at each dark store in 5-minute windows using historical patterns, current app activity, and promo flags. Astra pre-positions riders at the store counter so they are physically present when the picker completes the pack. A rider who arrives two minutes after pack is a two-minute SLA loss.

Mechanism three — substitution and out-of-stock handling without pausing the clock. The single biggest clock-killer is an out-of-stock item that forces the customer to be called, a substitution to be approved, or the order to be split. Shipsy’s substitution logic auto-applies pre-approved substitution rules per customer, per SKU, within a price tolerance — the picker sees the substitute, not a blocking exception.

Mechanism four — micro-cluster batching across concurrent orders. At peak hours, a rider dispatches with 2-4 orders simultaneously from the same store. Astra’s micro-cluster routing batches orders whose destinations fall within a single geographic cluster, without extending any individual order’s SLA past the commit. The rider’s stem time is shared; the customer’s delivery time is not.

How the agents coordinate

Clara handles the customer experience layer. When an order is 90 seconds from SLA breach, Clara proactively notifies the customer of the revised ETA, handles any incoming query about delay autonomously, and captures substitution consent where needed — without the live agent layer being touched.

Astra handles the planning and orchestration layer. It builds the rider-pre-positioning plan, the pick sequence, and the batching logic. Astra’s planning horizon for a dark store is 15-30 minutes ahead — long enough to pre-position riders, short enough to respond to demand surges.

Atlas handles the control-tower layer. When a store’s pick time starts creeping above budget (a picker calls in sick, a promotional push creates a 3x surge), Atlas auto-triggers mitigation: pulls a floater picker from an adjacent store, throttles the order-acceptance rate at app level, and reallocates rider capacity across stores in the cluster.

This three-agent coordination is what makes the six-minute clock protectable at scale. A single store cannot do it; a network of 200+ stores coordinated by a single decisioning layer can.

What operators running the traditional model lose

Quick-commerce operators who run dark stores on a lightweight warehouse management stack plus a separate delivery app typically see three pathologies.

The first is SLA degradation at scale — the 10-minute promise that worked at 20 stores breaks at 200 stores because cross-store coordination (rider rebalancing, demand-surge throttling, substitution policy enforcement) is not automated.

The second is rider utilization collapse. Riders sit idle at soft stores while hot stores run out of capacity, because the allocation layer cannot rebalance in real time.

The third is CX cost explosion. Without Clara-class autonomous CX, every SLA breach generates an inbound query, which generates a live-agent touch, which generates an apology credit. Quick-commerce CX cost can reach 6-9% of order value at scale without AI-native handling — often the difference between a profitable and loss-making unit economic model.

For context on quick-commerce replenishment, see the DC-to-dark-store replenishment playbook. For vertical context, visit the quick-commerce industry page or explore Shipsy’s last-mile product.