Dispatch Recommendation Workflows: Choosing the Right Courier on TAT and Cost

Most brands dispatch on habit. One courier is "the reliable one", another is "the cheap one", and the routing rule was set months ago in a spreadsheet nobody has revisited since.

The problem is that neither delivery time nor cost is stable. Carrier performance varies by lane, by pincode, by season and by day of week. Rate cards change. A partner who moves Bengaluru to Hyderabad in 36 hours may take five days into Guwahati. Meanwhile the channel's promise date is not negotiable — a breach means penalties, cancellations and a ranking hit.

So teams make one of two expensive mistakes, repeatedly.

Over-serving. Air-shipping an order a surface partner would have delivered comfortably inside the SLA, paying a premium for time you did not need.

Under-serving. Routing to the cheapest partner on a lane where they habitually miss, then absorbing the penalty, the return, or the lost sale.

Both are invisible in aggregate. They show up as a slightly worse contribution margin and a slightly worse fill rate, quarter after quarter.

What the workflow evaluates

Rather than applying a fixed rule, the workflow scores each shipment when it is ready to dispatch. It needs four inputs:

1. Order context — destination pincode, channel, SKU, weight and dimensions, and the promised delivery date.
2. Serviceability — which partners actually service that pincode, and with what pickup cut-off.
3. Observed TAT — not the carrier's advertised transit time, but your own delivery performance on that specific lane over the last 30 to 90 days.
4. Landed cost — rate-card cost for the weight slab and zone, including fuel surcharge, COD fee and expected RTO cost.

Then one constraint: among partners who can meet the promise date with acceptable confidence, choose the lowest landed cost.

Confidence is the word doing the work. An average TAT of 48 hours means nothing if the 90th-percentile TAT on that lane is six days. Score on percentile reliability, not averages.

A worked example

A 2 kg order, Bengaluru warehouse to a Pune pincode, marketplace promise date four days out.

A "cheapest" rule picks C and breaches the SLA. A "safest" rule picks A and overpays by ₹75. The workflow picks B — cheapest option clearing the promise date with a day of buffer.

Seventy-five rupees is trivial. Seventy-five rupees across 40,000 shipments a quarter is not.

Where the data comes from

This only works if TAT and cost data are current, which is where most attempts stall. The workflow pulls from:

• Carriers — Delhivery, Blue Dart, DTDC, ClickPost and Aramex for manifests, lorry receipts, delivery scans and POD.
• Channel portals — the promise date and SLA on each order.
• ERP or OMS — SKU master, weight, dimensions and dispatch location stock.
• Rate cards — held as a reference table so finance can update slabs without touching the workflow.

Observed TAT is then computed from your own dispatch-to-POD timestamps, per lane, and refreshed continuously. The recommendation sharpens as history accumulates.

Start in recommend mode

Five steps to build it:

1. Trigger on ready-to-dispatch, or on a schedule for batch runs.
2. Enrich with destination, weight, channel SLA and promise date from the ERP or OMS.
3. Score eligible partners on observed P90 TAT against the promise date, and on landed cost.
4. Recommend — write the suggested partner back to the OMS, or hand the ops team a ranked suggestion with the reasoning attached.
5. Learn by logging actual dispatch-to-POD performance back into the TAT table.

Step four deserves emphasis. Most teams should run in recommend mode before auto-assign mode. Running the recommendation alongside the human decision for a few weeks builds trust in the scoring and, more usefully, exposes lanes where your rate card or serviceability data is stale — which is almost always the real problem underneath a bad dispatch decision.

What to expect

Dispatch selection belongs to the same family as every other repetitive, data-dependent decision in operations: high frequency, rules-based, and badly suited to human judgement at volume.

The brands that automate this category of work see it in time returned rather than in a single dramatic saving. Bikaji recovered 60+ hours a week across order operations; Opptra 100+ hours a month. Fastrack, moving exception handling from manual checking to automated monitoring, cut response time by 75% — which matters here because a delayed consignment noticed on day one is recoverable and the same consignment noticed on day four is a breached SLA.

The freight saving is real but modest per shipment. The compounding gain is that nobody is making forty routing decisions a day on instinct.

Questions we get asked