Cutting last-mile cost for a quick-commerce player

01 · Frame

Find the real question

Situation. Order volumes are growing across a dense urban footprint, with customers expecting short and dependable delivery windows.

Complication. Delivery cost varies widely by time and micro-market. Adding riders can protect speed during peaks but leaves capacity underused off-peak; changing store coverage can shift both travel time and picking load.

“Which operating changes lower cost per completed order while keeping the service promise intact?”

A good answer had to show:

~Separate picking, batching, dispatch and travel-time drivers.

~Compare store-level fixes with network and coverage changes.

~Measure cost and service together, segmented by zone and time of day.

02 · Structure

Locate the cost, then redesign the system

I decomposed cost per order into store work, rider time and network shape. That makes it possible to distinguish local process fixes from structural footprint changes.

How can the operator reduce delivery cost?

Where is cost created?Picking and handoff time
Rider idle and travel time
Failed or redelivered orders

Where does demand cluster?Orders by zone and hour
Basket and batch density
Distance to eligible customers

Which changes protect service?Shift and dispatch rules
Batching thresholds
Store coverage and capacity

Hypotheses I set out to test

H1A small set of low-density zones or dayparts drives a disproportionate share of delivery cost.

H2Better picking readiness and dispatch rules can improve rider utilisation without extending delivery time.

H3Coverage changes should be made only where demand can be served inside the stated promise.

03 · Analyse

Follow each order from shelf to doorstep

3.1

Build the cost-to-serve baseline

Decomposed cost per completed order into picking, rider labour, distance, incentives and failed deliveries by store, zone and daypart.

[Visual: cost per order waterfall by zone]

Insight: [Cost component] accounts for the largest addressable gap in [zone / daypart].

3.2

Find density and capacity gaps

Mapped order density, basket size, travel distance and store workload against rider schedules and promised service times.

[Visual: demand-density map with service radii]

Insight: [Cluster] combines enough order density with spare capacity to support a targeted pilot.

3.3

Simulate operating changes

Compared dispatch, batching, shift and coverage options on cost per order, delivery time and order completion under peak and off-peak demand.

[Visual: scenario frontier — cost vs on-time rate]

Insight: [Intervention] clears the service guardrail at [target cost]; [trade-off] remains the key watchout.

Score operating scenarios on cost and service

Compare interventions on the same volume and service assumptions. Use observed zone-level data to replace the placeholders and keep peak periods visible.

Operating measure	Current	Pilot case	Guardrail
Cost per completed order	[₹X]	[₹X]	[≤ ₹X]
Median delivery time	[X min]	[X min]	[≤ X min]
On-time completion	[X%]	[X%]	[≥ X%]
Rider utilisation	[X%]	[X%]	[≥ X%]
Failed / redelivered orders	[X%]	[X%]	[≤ X%]

05 · Looking back

What I would keep, and what I would change

What worked

[What made the diagnosis actionable, such as separating peak and off-peak economics.]

What I would do differently

[What operational data or frontline observation you would gather earlier.]

Sample case page: replace bracketed values with verified project details before publishing.