Strategy

The delivery promise your network can actually keep

Key takeaways
  • You have two maps. The promise map is what customers are told, by pincode, on the product page and in the campaign.
  • Compare the two errors properly, because they are not symmetric.
  • A single national claim is either priced at your worst lane, which wastes your best lanes, or it is not true.

Marketing writes the promise. Operations absorbs the miss. That gap is where a lot of Indian D2C margin goes, and almost nobody has an owner for it.

This is not about how a delivery date is calculated. That is a separate discipline with its own inputs. This is about whether the claim your brand makes in market is one the network you actually operate can honour, and what to do when it is not.

Your promise map and your node map are different documents

You have two maps. The promise map is what customers are told, by pincode, on the product page and in the campaign. The node map is what your network can do, by pincode, from wherever your stock physically sits today. Most brands have never put the two on the same screen.

Build the overlay at pincode cluster level. For each cluster, the date you display against what your lane data says you deliver at the high end of the distribution, not the average. Averages will lie to you here, because the customer experiences the tail.

Three states come out of it. Over promised, where you are booking a miss. Matched. And under promised, where you are quoting a longer date than you reliably deliver and losing conversion for nothing. Brands hunt hard for the first state and almost never look for the third, which is free money sitting in the model.

One nuance that multi node brands get wrong. A pincode is not served by your network. It is served by the node that holds that SKU today. Serviceability in a split network is a SKU level property, not a geography level one, and a promise engine that ignores where the unit sits will confidently quote a date your slowest node cannot meet.

The asymmetric cost of a date you miss

Compare the two errors properly, because they are not symmetric.

A missed date costs a support contact, sometimes a cancellation or a refund, a higher chance of return to origin especially on cash on delivery, a rating that stays on the listing long after the parcel is forgotten, and a measurable decay in the odds that the customer buys again. Most of that lands after you have already paid the acquisition cost. You pay twice.

A longer honest date costs a slice of conversion at checkout. That is bounded, it is measurable, and it is recoverable next month.

One error is bounded and testable. The other is unbounded and arrives late. That asymmetry, rather than any benchmark number, is the argument. The exact size of both varies by category, so run it on your own data. Gifting and occasion driven categories punish a miss hardest because the date is the product. Replenishment categories tolerate a longer honest date with very little conversion loss.

Test it rather than debating it. Move one region to a longer honest date for a defined period and read conversion, contact rate, cancellation and return to origin together. Reading conversion alone will always favour the aggressive promise, which is exactly how brands talk themselves into a claim they cannot keep.

Tier the promise by region, not one national claim

A single national claim is either priced at your worst lane, which wastes your best lanes, or it is not true. Neither is a good place to be.

Tier it instead. An express tier where a node is close and the lane is dense. A standard tier for served but not fast. An extended tier for genuinely long lanes. And named exceptions for hill states, islands and remote districts, handled openly rather than allowed to fail quietly and generate a support thread each time.

Show the tier at the point of decision. On the product page against the pincode, before the customer has invested effort, not at checkout after the address is typed. A modest promise disclosed early converts better than a bold promise corrected late, and late correction is where abandonment concentrates.

Treat the tiering as a commercial document. It should carry a sign off from whoever owns margin, not only from operations, because it prices a trade between conversion and cost to serve. Review it when the node map changes and again after every peak, since peak is when the tiers drift furthest from reality.

Let serviceability steer the marketing spend

This is the part almost nobody does. Budget gets allocated by channel and by blended acquisition cost, and geography arrives as an afterthought in a monthly deck. Meanwhile conversion, return to origin and repeat rate all vary by region for reasons that live entirely in the network.

Compute contribution by region after delivery cost and after failure cost, including returns, refunds and support. Regions where you are fast and dense will usually be cheaper to acquire in and cheaper to serve at the same time, and the compounding matters, because a good delivery experience feeds the reviews that lower acquisition cost later.

Then act on it. Weight spend toward regions where the promise is strong. Cap spend where it is weak, and treat that weakness as a network decision before it is a marketing decision. Spending harder into a region you serve badly buys you reviews you cannot take back and a cohort that does not return.

There is a deliberate exception. Sometimes you fund demand in a weak region precisely to build the signal that justifies a node there. Do that as a named test with a budget, a duration and a stated read out, not as the default setting. The distinction between a funded experiment and an unexamined habit is the whole point.

This is also how a node business case should be written. If the second node moves a region from extended to standard, the marketing plan for that region belongs inside the case, not in a footnote as a happy side effect. Fix the network, then open the tap. In that order.

Give the map an owner

One person owns the overlay. It gets reviewed monthly and after every peak. And one rule holds the whole thing together. No delivery claim goes into a campaign, a banner or a marketplace listing that the node map cannot support that month.

Align the promise with the network you have. Then go build the network that lets you make a better one.

The daily brief

Never miss a move

The moves that move money, every morning.

One email a day. No spam, ever.

FAQ

Quick answers.

The two errors are not symmetric. A missed date costs support contacts, cancellations, return to origin, a lasting rating and a decay in repeat purchase, and most of it lands after you have already paid to acquire the customer. A longer honest date costs a bounded slice of conversion that you can measure and recover. Test it by region and read conversion alongside contact rate and return to origin, never conversion alone.
A single national claim is either priced at your worst lane, which wastes your strongest ones, or it is not true. Tier instead: express where a node is close and the lane is dense, standard for served but not fast, extended for long lanes, and named exceptions for hill states, islands and remote districts. Show the tier on the product page against the pincode, not at checkout.
Conversion, return to origin and repeat rate all vary by region for reasons that sit in the network. Compute contribution by region after delivery and failure costs, then weight spend toward regions where the promise is strong and cap it where it is weak. Spending into a badly served region buys reviews you cannot take back. Fund a weak region only as a named test that is building the case for a node there.
Because a pincode is not served by your network in the abstract. It is served by the node that holds that particular SKU today. If the fast node is out of stock on an item, the order falls back to a slower origin and the promise moves with it. A promise engine that reads geography but ignores where the unit actually sits will quote dates your network cannot meet.

Related insights

India's Commerce Engine

Put it
to work.

hello@zane.marketing

Book a meeting