Operations Logistics

Late dispatch: fix these causes in order

Missing the dispatch deadline has six common causes and a correct order to fix them in. Routing before cut-offs, cut-offs before capacity, and the label and pickup chain last, because each step changes the load on the next one.

Key takeaways
  • The dispatch clock starts at order placement on the platform, not when the order appears in your own system, and it stops at carrier scan rather than at label print.
  • Fixing pick-pack capacity before fixing order routing buys throughput at a node that should never have received the order.
  • The binding cut-off is the last physical handover to the carrier, which is the timestamp most teams have never written down.
  • In a festive surge label generation and carrier pickup fail before picking does, so plan the carrier and label capacity first.

Late dispatch has more causes than any other operations failure and most teams attack them in the wrong order, which is why it comes back. The sequence below is deliberate: each step changes the volume the next step absorbs, so fixing capacity before fixing routing buys capacity in the wrong building.

Where the clock actually starts

Almost every team measures the dispatch clock from the moment an order appears in their own system. The platform does not. It starts counting at order placement or payment confirmation, and the gap between those two events is your polling interval plus any manual import step. On a twenty-four hour promise, a fifteen-minute poll costs you one percent of the clock. On a same-day promise with a twice-daily import, it costs you most of it.

The other end is measured wrong just as often. The clock does not stop when you print the label. On most platforms it stops at the carrier scan or the manifest handover, and the distance between packed and scanned is exactly where the breach lives. A team reporting a healthy packed-by-time and a bad dispatch SLA is measuring two different events and only one of them is the one being graded.

The fix order, and why the sequence matters

Routing first, then cut-offs, then pick-pack capacity, then the label, manifest and pickup chain. Route an order to a node that cannot ship it and every hour of capacity you add at that node is wasted. Extend a shift at a node whose last physical handover is already the binding constraint and you have built a bigger pile that misses the same van. Re-measure after each step, because each one shifts where the constraint sits.

Routing: the node that cannot ship it in time

In a multi-node setup the allocation engine usually optimises for distance to customer or for stock depth. Time to dispatch is rarely an input at all. A node two hundred kilometres closer with one carrier pickup at four in the afternoon will breach an SLA that a further node with an eight o’clock handover would have met comfortably.

Put a feasibility test ahead of the cost test. For every candidate node, answer one binary question first: can this node get this unit onto a vehicle before the deadline. Optimise cost only among the nodes that answer yes. The second routing failure is subtler. The node holds the stock on paper, but it sits in reserve rather than forward pick, so the order needs a replenishment move that will not happen until the next shift.

Cut-offs: your warehouse closes before the platform does

The floor closes at six. The last carrier pickup is at seven. The platform’s daily cut-off is at eleven at night. Every order placed in those five hours is born a day behind and no amount of picking speed recovers it.

The fix is not simply to stay open later. Write down three timestamps per node per carrier: last pick start, last manifest close, last physical handover. The handover is almost always the binding one, and it is the one nobody has written down. Then decide whether to move the shift or move the carrier, because buying a second later pickup from one carrier is usually cheaper than an extra hour of shift across the whole floor. The platform cut-off is also rarely a single time. It varies by fulfilment mode and sometimes by payment mode, so one number on a whiteboard is already wrong for half your orders.

Capacity against the arrival curve

Capacity is normally sized as daily volume divided by working hours. Orders do not arrive flat. On Indian marketplaces the curve carries a heavy evening block, a spike after any deal or price change goes live, and a second wave whenever the platform pushes a notification.

Take one full week of orders in thirty-minute buckets and overlay your measured pick rate on the same axis. What you are looking for is not average capacity. It is the deepest backlog point of the day and how long that backlog takes to drain, because the only question that matters is whether it clears before the handover. Fix the peak buckets specifically: pre-batch the predictable evening volume, hold a float of two pickers for the last two hours instead of spreading them evenly, and release picks against confirmed orders rather than waiting for a batch to fill.

Labels, manifests and the missed pickup

Label generation is the bottleneck nobody plans for. It depends on a carrier API, and at volume that API has rate limits and timeouts. One failed AWB stalls a batch, and the standard human response is to rerun the whole batch from the top. The symptom is a queue of orders sitting in label-pending for forty minutes at the busiest hour of the day. Generate labels asynchronously as orders confirm rather than in one pre-pickup batch, pre-fetch AWB blocks where the carrier permits it, and make failures individually retryable so one bad shipment does not hold ninety good ones.

The manifest is worse because it is a human action tied to one person’s login. If that person is on leave or on a call, the manifest does not close and the pickup is not legally a pickup. Give it two named owners and a fixed clock time rather than a when-we-are-done time. And when the driver arrives before you are ready, manifest what is ready and let the remainder ride the next slot. Holding a van for six more orders converts a partial dispatch into a missed pickup, and on most carrier contracts a missed pickup is scored against you and the next one is tomorrow.

What breaks first when volume triples

Picking is what everybody staffs for and it is not what fails first. In a festive surge the first thing to go is label generation, because the carrier API rate limit is shared across every seller hitting it in the same window. Second is the pickup itself, because carriers do not add vehicles as fast as you add orders and the van fills before your queue empties. Third is the pack bench, which almost always has fewer stations than the floor has pickers. Picking capacity typically breaks fourth.

So plan in that order. Confirm carrier vehicle capacity and slot times in writing before the event, agree a rate limit or a fallback label source, add pack stations before you add pickers, and if the arithmetic still does not close, extend the promise on the SKUs you know you cannot ship rather than letting the whole account breach.

The daily brief

Never miss a move

The moves that move money, every morning.

One email a day. No spam, ever.

FAQ

Quick answers.

Use the platform's, because that is the clock being graded. Keep your internal timestamps as diagnostics to show where inside your process the hours are being lost.
Usually none. Compare the cost of an extra hour across the whole floor against buying a second, later carrier pickup, which is generally the cheaper way to move the binding constraint.
Bucket a full week of orders into thirty-minute intervals, overlay your measured pick rate, and staff to clear the deepest backlog before the last handover rather than to the daily average.
Vehicle capacity and slot times in writing, an escalation contact at the local hub by name, and a fallback path for label generation if the primary carrier API throttles.

Related insights

From the wire

India's Commerce Engine

Put it
to work.

hello@zane.marketing

Book a meeting