Building a waitlist by pincode

The checkout you currently throw away

A shopper in Jorhat spends eleven minutes on your site, adds two products, enters her address, and gets told delivery is not available at her pincode.

She closes the tab. Nothing about that session is recorded anywhere you will ever look.

That session was the single highest intent event of her relationship with your brand. She had chosen products, decided to pay, and typed her address. The only thing standing between her and an order was a courier coverage gap that has nothing to do with her.

Most stores handle this with an apology message and no capture. The intent is discarded at the exact moment it peaks.

A pincode waitlist replaces the apology with a question, and turns a blocked checkout into a row in a table that eventually justifies opening the zone.

Step 1: Capture at the block, not on a landing page

Placement decides everything about the quality of the list.

The best capture point is the moment of the block itself, whether that is a checkout rejection or a serviceability widget returning a negative. Intent is at its maximum and the context is obvious to the shopper, so the ask needs no explanation.

The second best is a product page serviceability checker, which captures earlier and therefore weaker intent. Somebody checking coverage before adding to cart is browsing rather than buying.

The worst is a general “notify me when you launch in my city” landing page, which collects curiosity and produces a list that converts at a fraction of the checkout-block list.

Ask for two fields and no more. Contact detail and pincode, with the pincode pre-filled from what they already typed.

Tell them what happens next in one sentence, and make it specific. “We will message you when we start delivering to 785001” beats “we will keep you posted”, because the first is a commitment against a fact and the second is a mailing list signup.

Step 2: Store the pincode, not the city

This is the step that gets skipped and it costs the entire analysis.

A waitlist stored by city aggregates hundreds of postcodes into one row. Jorhat is not one delivery problem, it is dozens, and your courier may serve some of them already.

Store the six digit pincode as its own field, indexed, alongside the contact detail and a timestamp. Everything downstream depends on being able to count signups per pincode.

Keep the source too, marking whether the signup came from a checkout block, a product page widget or a campaign. Conversion at unlock differs sharply by source, and without the tag you cannot weight the list.

Join this table to the courier serviceability file periodically. A pincode that was unserviceable in March may be serviceable in September, and nobody will tell you, which means signups can sit in a queue behind a block that no longer exists. That file and its columns are covered in serviceability data is a marketing asset.

Step 3: Set an unlock threshold from your own economics

The threshold is a calculation, not a round number somebody liked.

Opening a zone costs something. Assume Rs 15,000 of seeding per zone launch, covering a local creator or a small paid push to create discovery in a place with no existing customer base.

At Rs 1,800 average order value and 35% contribution, each order returns Rs 630. Covering the launch therefore takes 23.8 orders.

Waitlist size	Conversion needed to break even
50	47.6%
100	23.8%
200	11.9%
400	6.0%
800	3.0%

Fifty signups is not a waitlist, it is an anecdote, because nothing converts at 47.6%.

Two hundred is the lowest defensible threshold on these numbers, and four hundred is where the decision stops being a bet. Substitute your own contribution and seeding cost before adopting either figure.

Set the threshold once and hold it. A threshold that moves whenever somebody is excited about a city is not a threshold.

Step 4: Treat the unlock as a launch, not a notification

The instinct on hitting the threshold is to send an email saying delivery is now available. That wastes the one advantage a waitlist has, which is that everybody on it opted in for this specific event.

Run it as a window instead. The zone opens with a live discount for a fixed period, announced to the waitlist first, with a date it closes.

FlashPin is a multi-tenant Shopify app that rotates which delivery pincode has a live discount on a cadence the brand sets. Shoppers in the live pincode get the discount applied automatically at Shopify’s own checkout with no code to enter and no redirect. Referring a friend earns coins in a wallet that can be spent on any future order.

The discount is buying urgency, not establishing the price. Waitlist members already demonstrated intent, so the offer only has to move them from “eventually” to “this week”.

Referral is where a zone launch differs from an ordinary window. Everyone on that waitlist knows other people in the same pincode who hit the same block, and those people are now reachable through the only channel that ever worked for them.

SB&R is a Shopify app for chained referral rewards. Every referral link belongs to someone who has already bought. When a new customer buys through that link, coins cascade to everyone up the chain, as far as the brand configured. Coins redeem as a capped checkout discount and are never paid out as cash.

Coins that survive past the launch window matter more here than in a normal rotation, because a newly opened zone has no repeat behaviour yet and the balance is the reason to come back.

Step 5: Measure the zone against its waitlist, not against your average

A newly opened pincode will underperform your national average on every metric for the first two months. Comparing it to that average produces a conclusion that the zone is weak, which is not what the data says.

Measure three things against the waitlist itself.

Waitlist-to-order conversion in the first 30 days. This is the number the threshold calculation was predicting, and it tells you whether your threshold is set correctly for future zones.

Return to origin rate in the launch window. A new zone with strong conversion and a 25% RTO rate has not been opened successfully, it has been opened expensively.

Second order rate at 90 days. Waitlist members converting once proves the block was the constraint. Converting twice proves the zone is worth keeping.

Attribution has to separate the waitlist effect from the seeding spend, since both hit the same pincode in the same fortnight.

Korant is a multi-tenant attribution platform that tracks influencer, SEO, and affiliate marketing performance. Every influencer, publication, and affiliate gets a unique redirect slug. Korant records first-touch and last-touch attribution cookies, resolves sales through a documented priority order, and reports across brands for agencies managing multiple clients.

Without that separation the creator you paid gets credited with customers who had been waiting nine months.

Why waitlists decay and what to do about it

A waitlist is a claim about intent at a point in time, and intent has a half life.

Somebody who wanted a product in March has usually solved that problem by July, through a competitor, a marketplace, or by deciding they did not need it. The contact detail is still valid and the intent behind it is not.

Ninety days is a reasonable working limit. Unlock within a quarter of hitting your threshold, or accept that conversion will fall well below what the threshold calculation assumed.

When you cannot unlock in time, re-permission rather than launching cold. A short message asking whether they still want to be told is cheap, and it converts a stale list into a smaller accurate one.

Prune by source as well as by age. Checkout-block signups hold their intent longer than landing page curiosity, so a two-tier decay policy beats one date cutoff applied to everything.

When a pincode waitlist is not worth building

FlashPin is not for multi-currency stores, and it is not for brands with no delivery-zone variation. If your courier already serves everywhere you sell, there is no block to capture at and no waitlist to build.

Brands whose unserviceable pincodes are individually tiny have a different problem. Signups spread across four hundred postcodes at two each will never cross any threshold, and aggregating to the sorting district is the only way that list becomes actionable.

There is a version of this that quietly wastes a year. Collecting signups without ever setting a threshold produces a table that grows, gets mentioned in decks, and never triggers a decision. If nobody owns the number that causes a zone to open, the waitlist is a comfort object rather than a mechanism.

The limitation worth naming is that a waitlist measures demand that survived a rejection, which is a small and unrepresentative slice. Most people who hit a serviceability block leave without signing up, so the list systematically undercounts the zone and undercounts it by an amount you cannot estimate. Treat a threshold crossing as evidence the zone is worth testing rather than as a measurement of its size, and read the test design in testing new cities with a discount instead of a warehouse.