Estimated Delivery Dates at Checkout: A Pincode-Level Guide

A shopper deciding whether to order a gift does not care that you "dispatch within 24 hours". They want to know if it reaches Indore by Saturday. An estimated delivery date (EDD) answers that directly — and it is one of the few checkout elements that helps both conversion and support load. The catch is that a wrong date is worse than no date.

What goes into a delivery date

An EDD is three things added together:

delivery date = order time
              + handling time (until the courier picks up)
              + transit time (the lane's SLA)
              adjusted for non-working days

Most bad estimates come from getting only the middle term right.

Transit time comes from the zone

Couriers do not promise city-to-city times; they promise by lane. Each origin–destination pincode pair resolves to a zone, and each zone has a typical surface transit range:

• Within city: 1–2 days
• Within state: 2–3 days
• Metro to metro: 2–4 days
• Rest of India: 3–6 days
• Special zones (North-East, J&K, islands): 5–9 days

So a parcel from Bengaluru (560001) to Mumbai (400001) is a metro lane at 2–4 days, while the same parcel to Srinagar (190001) is a special-zone lane at 5–9. One "3–5 days" banner cannot be right for both. The shipping zones guide explains how pincodes map to lanes.

Faster service levels shorten the range: air and express typically take about a day off, where the lane is long enough to benefit.

Handling time and the cut-off

Transit starts when the courier picks up, not when the customer pays. Two settings decide that:

• Dispatch cut-off. If pickup is at 4 pm and packing takes two hours, orders after 2 pm ship the next working day.
• Processing days. Made-to-order or personalised products need their own handling time per SKU.

Show the cut-off when it helps: "Order in the next 1 hr 20 min to get it by Wednesday" is honest urgency.

Working days

Many lanes do not deliver on Sundays or public holidays, and your warehouse may not dispatch on them either. Count transit in working days and skip the rest.

A worked example

Order placed Friday at 4:30 pm, warehouse in Delhi (110001), destination Bengaluru (560001), cut-off 2 pm, no Sunday movement.

1. Missed Friday's cut-off, so it ships Saturday
2. Lane: metro to metro, 2–4 working days
3. Sunday is skipped: day 1 is Monday, day 2 Tuesday, day 4 Thursday
4. Estimate: Tuesday to Thursday

A naive "Friday + 2 days" would have promised Sunday. That gap is exactly where "where is my order?" tickets come from.

The code

Keep the date logic on your server, in one place:

function addWorkingDays(start, days, holidays = []) {
  const d = new Date(start);
  let added = 0;
  while (added < days) {
    d.setDate(d.getDate() + 1);
    const isSunday = d.getDay() === 0;
    const isHoliday = holidays.includes(d.toISOString().slice(0, 10));
    if (!isSunday && !isHoliday) added++;
  }
  return d;
}

function estimate(orderTime, slaMin, slaMax, cutoffHour = 14) {
  const ship = new Date(orderTime);
  if (ship.getHours() >= cutoffHour) ship.setDate(ship.getDate() + 1);
  if (ship.getDay() === 0) ship.setDate(ship.getDate() + 1);
  return {
    earliest: addWorkingDays(ship, slaMin),
    latest: addWorkingDays(ship, slaMax),
  };
}

The SLA range should not be hard-coded per city. It comes back with every rate quote, alongside the zone, so price and promise are computed from the same lane:

POST /v1/rates/calculate
{
  "origin": "110001",
  "destination": "560001",
  "weight_grams": 800,
  "service": "surface"
}

If you only need the delivery window on a product page, a serviceability check on the destination pincode returns the SLA without a full quote. Field names for both are in the API docs.

How to present the date

• Show a range when the range is wide. "Tue 1 Sep – Thu 3 Sep" is honest for a 2–4 day lane. Collapse to a single "by" date only using the later end.
• Use dates, not day counts. "5–9 days" makes the customer do arithmetic and guess about Sundays.
• Show it early. Product page first, then cart, then checkout — the same date in all three.
• Repeat it after the order. Put the promised date in the confirmation message, then update it if tracking shows a delay.
• Pad in peak season. During sale and festive weeks, add a day or two to every lane rather than defend a normal-week promise.

Measure whether you keep the promise

Store the promised latest date on each order and compare it with the actual delivery date. Review the share delivered on or before the promise, by zone. If special-zone orders regularly land after the upper bound, widen that lane's range. A kept six-day promise builds more repeat business than a broken three-day one, and showing the date early also helps with cart abandonment.

Frequently asked questions

How is the estimated delivery date calculated?

Add handling time (based on your dispatch cut-off) to the lane's transit time, counting only working days. The transit range depends on the zone between the origin and destination pincodes, from 1–2 days within a city to 5–9 days for special zones.

Should I show a single delivery date or a range?

Show a range when the lane's SLA is wide, and a single "by" date only if you use the later end of the range. Customers forgive a parcel that arrives early. They remember one that arrives after the date you promised.

Why do delivery estimates differ so much between pincodes?

Because transit time is set by the courier lane, not by distance alone. A metro-to-metro parcel moves on a high-volume lane in 2–4 days, while a North-East or J&K pincode sits on a special-zone lane that typically takes 5–9 days.