Explore

Multi POB

Context -

We are in the discussion to onboard V-mart & Pantaloons which operates through the Omni-Channel Model where in stores act as fulfilment centres. Onboarding and scaling these omni channel brands will enable us to -

Onboard perceptions drivers National Brands for Fashion which is OC backwards & searched on the platform

Omni-channel fashion brands packs selection of 50K PIDs with them which will contribute to ~18% of current Mall selection in fashion portfolios

Expected NMV run rate by onboarding these omni channel brands stands at ~45 Cr

Objective -

Enable onboarding of national / D2C omni channel brands by building support for multiple fulfilment centres for a given seller. The requirement is an acute enabler to onboard omni channel brands on Meesho.

Omni channel fulfilment journey -

One seller account is mapped to multiple fulfilment centres / places of business

Listings happens through the primary account and is then replicated across all FCs

Inventory management happens per FC

Order allotment happens to the store / FC nearest to the user, or next nearest in case of SKU OOS

Returns and exchanges happens via the FC addressing first mile

GSTINs are mapped basis FC’s state and the net GSTIN / tax and invoice details are aggregated across all FC’s to the parent seller portal for easy reconciliation

Every store will have different PIDs and Inventory basis regional demand

Multi item order where 2 items are present in 2 different stores. Price will not be an issue here but fulfilment might need it to happen as 2 separate orders

Parent - Child mapping of SIDs for reconciliation & data aggregation

Outside IN (WIP) -

Myntra / Flipkart and Amazon support these through in-house build

Nykaa partners with Browntape to build order hopping logic

Solution identification -

Seller - FC mappings -

Approach 1 - Maintaining FCs through child seller accounts and then aggregating order / payment details in the parent seller account

Pros - Primary backend changes in terms of collating payout / invoicing and order details from multiple accounts

Cons - Requires manual overhead to list across multiple accounts with separate web pages as well as manage seller operations

Approach 2 - Creating a FC filter in parent seller portal to manage inventory / orders and payouts at FC as well as overall level within the same panel

Pros - Easy brand experience with aggregated details as default and ability to filter for FC level performance across seller panel flows

Cons - Higher engineering effort with considerable design and front end changes

Order allocation / Hopping -

Approach 1 - Performed by Meesho

Would need user’s address details to dynamically allocate pickup basis distance and availability. One node between OMS & fulfilment and multi node between Meesho & OMS. Used by FK and Myntra

Pros - This model is clean & Scalable in terms of Reconciliation, pickups, taxation & fulfilment

Cons - Considerable tech effort

Approach 2 - Managed by OMS

Marketplace sends the order to OMS & then OMS decides on sub-order allocations (diff items within the order if any), pickups & fulfilment. Single node b/w Meesho & OMS. Nykaa uses this model.

Pros - Lower in-house tech effort

Cons - GST / Invoice and payment calibration / reconciliation workflows remain manually managed by brand leading to increased manual ops effort. Needs alignment to onboard all omni channel brands on the partnering OMS

Other open queries -

Does order growth levers like price reco / ads get managed per store or common across seller? TBC with brands

How does PLP / PDP serviceability and promised order dispatch work in these cases?

How does zonal pricing work in such cases? What price do we show on such PLPs?

Tech solutioning -
`Multi POB - Tech solutioning`⁠
⁠

Want to print your doc?
This is not the way.

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.