Building a Repeatable Onboarding Process for Every New Marketplace

Here is a pattern we see in almost every growing brand. The first marketplace launch is a heroic effort. A founder, a few operators, late nights, a shared spreadsheet that nobody else understands, and a finish line that arrives by sheer willpower. It works. The brand goes live. Everyone exhales. Then three months later they open a second platform, and somehow it takes just as long as the first. Same scramble, same gaps, same surprises. The heroism did not compound into anything. It evaporated.

That is the real cost of treating every launch as bespoke. Not the late nights, but the fact that none of the learning gets captured. Each new marketplace starts from zero because the knowledge lived in people’s heads and a few unlabelled tabs, not in a process. The brands that scale across platforms quickly are not smarter or better resourced. They simply refused to launch the same thing twice from scratch. They built an onboarding playbook, and then they ran it.

Why bespoke launches quietly cost you weeks

A bespoke launch feels efficient in the moment because you are moving fast and solving live problems. The hidden tax shows up later. When the process lives only in someone’s memory, every step is rediscovered rather than recalled. You re-learn that the GST name has to match the bank account. You re-learn which image spec gets a listing suppressed. You re-learn the order in which inventory, pricing, and listings have to be ready. None of this is new knowledge. You already paid for it once. A bespoke launch makes you pay for it again.

The second tax is dependency. If only one person knows how a launch runs, that person becomes a bottleneck for every future platform. They cannot delegate, because the process is not written down to delegate. The brand’s ability to expand is capped by one human’s calendar. A playbook breaks that ceiling. It turns launch capability from a person into an asset the whole team can use.

A launch you cannot hand to someone else is not a process. It is a hostage situation, and the founder is the hostage.

What an onboarding playbook actually is

An onboarding playbook is not a vague document of best intentions. It is a sequenced, owned, repeatable set of steps that takes a brand from “we want to be on this platform” to “we are live and operating cleanly.” Every step has an owner, a definition of done, and a place in the order. The point is that anyone competent can pick it up and run it without reinventing the route.

The strongest playbooks separate the parts that never change from the parts that do. Roughly eighty percent of a launch is identical across platforms. Compliance, brand protection, catalogue preparation, operational readiness. That is your stable core, and it should be written once and reused every time. The remaining twenty percent is platform-specific, and that is where you slot in the quirks of each marketplace. Get this split right and most of your next launch is already done before you start.

The stable core: the compliance, brand, catalogue, and operations work that is true on every marketplace, captured as a master checklist you close line by line. Our brand launch readiness checklist for Indian marketplaces is the backbone of this layer.
The platform module: a short, per-marketplace addendum that captures only what is different. Onboarding flow, category approval quirks, documentation demands, image rules, and the live fee schedule for that platform.
The owner map: who is responsible for each block, so nothing falls between people during the rush.
The gate: the explicit rule that you do not go live until every line is closed, on the core and the module both.

Build the playbook in layers, in the right order

Sequence is where most launches go wrong, so the playbook should encode it. The layers have different lead times, and the ones with the longest lead times have to start first even though they feel the least urgent.

Compliance and operations go first

Compliance gates everything. GST, GTINs, category licences, KYC. These have long lead times and no shortcuts, so they are the first thing the playbook triggers, regardless of how excited everyone is to start designing the storefront. Right alongside it sits the unglamorous operational machinery, the inventory and pricing and support readiness that keeps you alive after day one. We treat this as its own discipline, which is why the operations setup checklist before you list a single SKU exists as a standalone module. In a repeatable process, operations is not an afterthought you bolt on. It is a layer you start early and close deliberately.

Catalogue and brand come next

Once compliance is moving, the playbook turns to the catalogue. Imagery to spec, titles and bullets built against real competitors, variations and size data complete. This is the layer founders enjoy, which is exactly why a documented process matters here. Left unstructured, teams over-invest in the fun parts and under-invest in the boring ones. The playbook forces balance by making every input a named line with a definition of done, not a vibe of “looks good enough.”

Decide which marketplace runs the playbook first

A playbook tells you how to launch. It does not tell you where to launch first, and the two questions are different. Running your repeatable process on the wrong platform is a fast way to do excellent work that does not move the business. Sequence the marketplaces by where your customers actually are and where your margins survive, then point the playbook at that list in order. We work through that decision in the marketplace prioritization framework for resource-strapped brands, because for most Indian brands the constraint is not capability, it is bandwidth. The playbook makes each launch cheaper. Prioritisation makes sure you spend that cheaper launch on the platform that pays.

Treat the playbook as a living asset, not a frozen document

The first version of your playbook will be wrong in small ways. That is fine. What separates a real process from a dead document is the debrief. After every launch, you sit down and ask three questions. What surprised us. What took longer than the playbook said. What did we discover that should be written down so we never discover it again. Then you update the document. A playbook that is not edited after each launch is decaying, not maturing.

This is especially true on Amazon, where the early weeks set patterns that are expensive to undo later. The brands that compound across launches feed every hard lesson back into the core. Our first 90 days playbook for Amazon India is exactly this kind of captured learning, the operational discipline of the launch weeks written down so the next brand does not pay for it again. That is the whole idea. Pay for a lesson once, then bank it.

Run a structured debrief within a week of every launch, while the friction is still fresh.
Promote any platform-specific surprise into the right module so the next launch on that platform inherits it.
Promote anything that was true across two or more platforms into the stable core.
Version the document so the team always knows it is reading the current process, not last year’s.

What changed recently, and why your playbook has to absorb it

The fastest-moving part of any onboarding module right now is quick commerce, and the rules are being rewritten faster than most brands can update a checklist. The clearest example is the take rate. In March, Blinkit moved from a flat category commission to a variable model tied to selling price, with rates climbing from roughly two percent on items under five hundred rupees to about eighteen percent above twelve hundred, as Inc42 reported. Zepto and Blinkit both moved to lift per-order economics in the same window, per Business Standard. The lesson for a playbook is blunt. The commission line in your platform module is not a constant you write once. It is a live number that has to be re-checked before every launch, because a margin model built on last quarter’s take rate can be wrong by ten points.

The second shift is what it costs just to be visible. Reporting by Storyboard18 describes Blinkit asking for a listing fee of around twenty-five thousand rupees per SKU per state, credited to an ad wallet that expires, with minimum monthly marketing spend often in the two to three lakh range, while Instamart and Zepto bundle listing and ad commitments into quarterly figures running into several lakh. Whatever the exact number when you read this, the structural point holds. On quick commerce, getting listed and getting seen are now two separate invoices, and a playbook that only plans the listing step has under-budgeted the launch.

The third shift is where the doors are. Flipkart Minutes has been adding dark stores at pace, crossing eight hundred and targeting around twelve hundred across roughly two hundred and fifty cities, according to Inc42. More surface area means more onboarding queues, more category-manager gatekeeping, and another platform module to keep current. None of this changes the shape of a good playbook. It changes what goes inside the modules, and how often you have to refresh them. The brands that stay ahead treat the fee schedule and platform map as a living input, not a footnote.

The payoff is speed that compounds

The point of all this is brutally practical. Your first launch on a new platform should take a known, shrinking amount of time, and your tenth should be close to routine. When the process is documented, a new operator can run a launch in a fraction of the time it took the founder to figure it out the first time. The brand stops paying the bespoke tax. Expansion becomes a decision about priorities and bandwidth, not about whether anyone has the energy to do it all again from scratch.

This is how we run Brand Launch on Marketplaces. We do not treat your launch as a one-off project that ends when you go live. We treat it as a repeatable system, with the readiness core, the operational layer, and the per-platform modules captured so that every subsequent launch is faster than the last. We pair it with Catalog and Listing Optimization so the catalogue layer is genuinely ready rather than nominally complete, and with Marketplace Account Management so the operational lines stay closed long after launch day.

So before your next marketplace, ask the honest question. If you launched on a new platform tomorrow, could you hand the process to someone else and trust it to run. If the answer is no, you do not have a process yet. You have a memory, and memories do not scale. Write the playbook. Then the second launch, and every one after it, gets faster.

Inventory Forecasting for Quick Commerce Dark Stores

A brand will show us a beautiful quick commerce forecast. One number per SKU, citywide, sometimes nationwide, accurate to within a few percent at the aggregate. And then half the dark stores in that same city are stocked out by 9pm while the other half are sitting on dead inventory the platform is about to charge them to hold. The forecast was not wrong. It was just answering a question nobody on a ten-minute delivery promise actually asks.

Quick commerce does not fulfil from a warehouse. It fulfils from a dark store that serves a two-to-three kilometre radius, and demand inside that radius has almost nothing to do with the national average. The forecasting model that works for Amazon, where stock pools centrally and any unit can serve any customer, breaks the moment your inventory is scattered across hundreds of tiny independent nodes that cannot share stock with each other. And there are a lot more of those nodes now. India crossed roughly 6,000 operational dark stores entering 2026, and the leading platforms are still building, so the grid you have to forecast against is denser and finer-grained every quarter.

Why the aggregate forecast lies to you

The core problem is pooling. On a marketplace, a thousand units in one warehouse can absorb demand from anywhere in the country, so the variance you forecast against is smoothed across the whole map. In quick commerce there is no pool. Each dark store holds its own stock, sells only to its own radius, and cannot lend a unit to the store three kilometres away that just sold out. You are not forecasting one demand curve. You are forecasting hundreds of them, each small, each noisy, each local.

And local demand is genuinely different store to store. A dark store in a young-professional pocket of Bengaluru sells protein bars, cold brew, and condoms at volumes a store in a family neighbourhood across the same city will never touch. Demand is shaped by who lives in the radius, what the nearest competing stores carry, the weather that afternoon, and whether there is a cricket match on. Aggregate it all together and the signal that should drive each store’s order is averaged into mush.

You are not forecasting a product. You are forecasting a product in a postcode, and the postcode matters more than the product.

This is the same trap that ruins assortment decisions, which is why we treat what each dark store carries as a per-store exercise rather than a catalogue you push everywhere. The forecast and the assortment are the same decision viewed from two angles. Once you accept that the right range differs by store, you have already accepted that the right quantity does too.

Fill rate is the number that actually pays you

Marketplace operators obsess over availability. Quick commerce operators should obsess over fill rate, and the distinction is not pedantic. Fill rate is the share of demand inside a given store’s radius that you could actually serve from that store’s shelf at the moment the order came in. It is a local number by definition. A national availability figure of 95 percent can hide a dozen dark stores running at 60 percent fill on your hero SKU, and those are precisely the stores quietly bleeding you.

The bleed is worse than the lost sale. When your product is out of stock in a dark store, the platform’s app does not show an empty shelf. It shows your competitor, or it drops your item from the listings that radius sees entirely. A few days dark in one store and you lose placement in that store’s slate, which means you lose it even after you restock. Stockouts in quick commerce are hyperlocal ranking events, and the damage compounds exactly the way it does on marketplaces. We have made the broader case that the real cost of a stockout is the ranking you cannot see on the invoice, and on a per-store grid that cost simply multiplies by the number of stores you let go dark.

How to forecast when every store is its own market

You cannot run a clean statistical model on a SKU that sells four units a day in one store. The numbers are too small. So the practical approach is to stop pretending each store is a standalone forecasting problem and start clustering stores that behave alike.

Cluster stores by demand pattern, not geography. Two stores in different cities can sell the same mix because the same kind of people live in their radius. Group stores by what actually sells, then forecast the cluster and apply it down to the store. This borrows signal across thin data without flattening real local difference.
Anchor to local history, adjust for local events. Last month in this store is a far better base than this month nationally. Layer on what is specific to that radius: a festival, a heatwave, a nearby office reopening, a competitor store going live next door.
Forecast at the SKU-store-day grain for hero items, coarser for the long tail. You do not need daily store-level precision on the slow movers. Spend the modelling effort on the handful of SKUs per store that drive fill rate and revenue.
Treat new stores as cluster members from day one. A store with no history is not a blank slate. It is most like the existing stores serving similar radii, so seed its forecast from its cluster and correct as real data arrives.

The point of all of this is not statistical elegance. It is to get the order quantity for each store close enough that fill rate holds without burying that store in stock it cannot move before it expires or racks up holding fees. The tighter your replenishment cycle, the more forgiving the forecast can be, which is why forecasting and replenishment cadence have to be designed together rather than handed off between teams.

Spiky demand, multiplied by hundreds of stores

Quick commerce inherits all the spike problems of Indian marketplaces and then makes them local. A platform sale, a long weekend, a sudden downpour that pushes everyone to order in rather than step out. The spike is real, but it does not land evenly. It hits the stores serving the right radius and barely touches the others.

The discipline of separating steady-state baseline from event-driven demand, which we laid out for forecasting marketplace demand when it is spiky, carries straight over. What changes is that you now run that separation per cluster, because a Friday-night spike in alcohol-adjacent snacking shows up in one set of stores and a Sunday grocery top-up spike shows up in another. One national event forecast smears these into a single bump that is wrong everywhere it lands.

The mix is also shifting under you. Non-grocery categories like electronics, beauty, and small appliances have been growing faster than food on the major platforms, which means the spiky, considered-purchase demand patterns you used to ignore now sit inside your hero set in more stores than before. A cluster that was once pure grocery may now need a different forecast shape entirely.

Sequence stores so forecasting is even possible

None of this works if you are trying to forecast a thousand dark stores you launched all at once with no history and no operational depth in any of them. Forecasting quality is downstream of how deliberately you expanded. Brands that go deep in a few high-density cities before they go wide build the per-store history and the cluster patterns that make hyperlocal forecasting tractable. Brands that sprint across the map forecast everything badly at once.

This is why we are unromantic about which cities to launch quick commerce in first. Concentration is not just a marketing or unit-economics call. It is what gives your forecasting model enough local signal to keep fill rates high instead of guessing blind across a footprint too thin to learn from.

What changed recently

The biggest shift for brands is that the platform increasingly owns the forecast. Blinkit moved to an inventory-led, first-party model from September 2025, buying stock from brands, holding it under its own GSTIN, and selling as the legal seller. By the third quarter of FY26 it reported that roughly 90 percent of net order value came from its own inventory, a transition Blinkit itself framed as a route to better availability and fill rates, per Medianama. When the platform owns replenishment, your forecast does not stop mattering. It becomes the input you use to push allocation, argue stock cover, and contest the platform’s own demand planning store by store rather than accepting a citywide number.

The grid you forecast against is also getting bigger and faster. Blinkit has said it is targeting 3,000 dark stores by March 2027 while staying profitable, as reported by Business Standard, and Flipkart Minutes is moving to double its network toward roughly 1,500 stores by the end of 2026, leaning hard into tier-2 and tier-3 towns. More stores in newer, less-understood radii means more nodes with thin history, which is exactly where cluster-seeding earns its keep. Storyboard18 reports non-grocery categories growing well faster than food across the major platforms, which is the assortment-mix change feeding straight back into how your forecast clusters need to be drawn.

Make the dark store the unit of planning

The brands that win quick commerce stop thinking in national SKUs and start thinking in store-SKUs. Every forecast, every order, every fill-rate target is set at the store level and rolled up only for reporting, never for deciding. They cluster stores so thin data becomes usable, they protect fill rate on the items that matter per radius, and they accept that a perfect national number is worthless if it leaves individual stores dark. In an inventory-led world where the platform is doing its own forecasting, the brand with the sharper per-store view is the one that wins the allocation argument.

This is the operational core of what our Operations & Logistics Management team builds for quick commerce brands, working alongside Marketplace Performance and Data & Analytics because the per-store demand signal and the platform fill-rate penalties are two halves of the same problem. Forecast the postcode, not the country. Hold fill rate store by store. The aggregate will take care of itself once the stores do.