Blinkit Seller Dashboard
DEVELOPING A NEW REVENUE STREAM
ABOUT THE COMPANY
Blinkit (formerly Grofers) is an Indian quick-commerce unicorn trusted by millions. The platform delivers 5000+ products in a blink and is India's biggest 10-minute delivery platform.
PROJECT OVERVIEW
Blinkit is a marketplace operating in a buy-sell model (Inventory based) with ~10 sellers and brands.
However, the existing ecosystem is a blocker for many brands as they want to operate in a direct seller model.
There's a need to introduce a direct seller model (marketplace model) to onboard more sellers and scale its business. This will reduce dependency on existing sellers and provide more options to customers.
MY ROLE
→ Working in a fast-paced environment, researching, designing, & delivering the V1 of the product within 2 weeks.
→ Comprehending legal requirements and business models.
→ Addressing technological limitations while aligning them with the business requirements of both brands and Blinkit.
→ Understanding the interdependencies within the system, designing to ensure a seamless process.
LEARNINGS
→ This project required an understanding of multiple aspects, including legal aspects, licensing, and addressing technological limitations while aligning them with business requirements.
→ Conveying ideas as a designer: As a designer, I effectively communicated my ideas by providing logical reasoning for each point, supported by research, competitor analysis, or use cases.
IMPACT
→ Developed a new revenue stream and growth tool for Blinkit.
→ Streamlined seller operations, leading to increased efficiency of sellers and saving their time in creating their online presence.
→ Improved efficiency of sellers in managing their operations, such as inventory management, sales and payouts.
TEAM
Solo Designer, 2 Product Managers, Members from the Senior Management, Team of Developers
TOOLS
Figma, Slack, Trello
RESEARCH - UNDERSTANDING THE BUSINESS MODEL
Conducted secondary research to have a broad understanding of the two business models to proceed with the research.
Buy-Sell Model (Inventory Model) - The inventory is owned by the platform, and consumers directly buy the products from the e-commerce platform. The platform sources the products directly from brands or sellers and then stocks them.
Direct Seller Model (Marketplace Model) - The inventory is owned by the seller or brand. Customers buy products from the seller or brand through a marketplace (e-commerce). E-commerce provides a platform for these sellers to establish their online presence. In a marketplace model, multiple sellers can offer multiple products.
COMPETITOR ANALYSIS
Conducted competitor analysis to understand the offerings of platforms like Amazon and Flipkart that are already operating the direct seller model.
Various aspects were analyzed, including shipping methods, inventory management, catalogue, onboarding process, documentation, product listing process, pricing control, sales and analytics. This analysis was required to ask the right questions to brands that were interviewed after this analysis.
Did an in-depth analysis of Amazon Seller Central. We had limited access to Flipkart Seller Hub due to strict documentation process.
Inventory screen of amazon seller central
INTERVIEW WITH D2C BRANDS
Competitor analysis helped us ask the right questions to brands. These interviews were conducted to understand the difference between the two models and the perspectives and experiences of D2C brands.
During the first phase of development, we decided to build the features for D2C brands as the primary user group. Interviews were carried out with prominent brands in the market to gain better insights.
Meeting with Toyshine
Taking notes
INTERVIEW INSIGHTS
These interviews revealed the differences between the two models, role of Blinkit as a platform and seller expectations:
We need a hybrid approach where brands like Einstein Box, Toyshine, and Shumee can operate in a direct seller model and brands like boAt, and Ambrane can continue to operate in a buy-sell model. However, many brands like Pilgrim prefer to operate in both models depending on their goal and product type.
boAt's preference for buy-sell model over direct seller model:
boAt prefers to operate in the current model (buy-sell / inventory model) due to less inventory risk. boAt already has a market presence so sellers or platforms like Blinkit takes a bet on their products and purchases them. Hence, boAt doesn't need to work on a flat commission model (marketplace)
Many such brands have their presence on platforms like Amazon, Flipkart, and Blinkit through sellers but they do not operate directly in a marketplace model. These brands have their sellers who operate in a buy-sell model.
Sellers purchase the products directly from the brands and then list those products in marketplaces like Amazon, Flipkart.
SELLER INTERACTIONS
A platform seller currently has the following interactions with multiple stakeholders:
SELLER STORIES
-
As a new seller on Blinkit, I want to easily list my products and manage my inventory, so that I can start selling my products quickly & efficiently.
-
As an experienced seller on Blinkit, I want to be able to track my sales, manage my orders, & communicate with my customers easily, so that I can provide excellent customer service and grow my business.
-
As a seller on Blinkit, I want to be able to access detailed reports and analytics on my sales and customer behavior, so that I can make data-driven decisions and improve my business performance.
SELLER PERSONAS
PROBLEM
The absence of a direct seller model restricts Blinkit from scaling effectively, resulting in heavy reliance on existing sellers.
Additionally, this becomes a significant obstacle for numerous brands, as the current system solely supports the buy-sell model.
BUY-SELL MODEL (INVENTORY MODEL)
The platform sources products from brands or sellers, stocking them without multiple sellers offering the same product. Here the consumers purchase products directly from the platform.
SOLUTION
To build a platform to carry out operations for the direct seller model.
This will enable small and large businesses to list, sell and manage their sales and inventory on Blinkit.
DIRECT SELLER MODEL (MARKETPLACE MODEL)
Sellers and brands own the inventory, and customers purchase products directly from them through e-commerce platforms. This model allows sellers and brands to establish their online presence. Here multiple products can have multiple sellers.
FEATURE LIST FOR V1
This feature list was finalised with the product manager and the senior management. This includes all the main features (details explained later.)
INFORMATION ARCHITECTURE
To ensure informed decision-making, I tried to learn the necessary legal requirements for onboarding sellers in a marketplace model before designing the screens.
DASHBOARD DESIGNS
The objective was to deliver an overview of the V1, these designs may lack some minor features, lack UI details, but they serve as the foundation for the next designer. Each design decision is made based on the interview insights and personas.
LOW-FIDELITY WIREFRAMES
I began with some low-fidelity wireframes. After discussing the entire flow with the product manager, I proceeded to work on the actual designs. Initially, the emphasis was more on establishing the user flow rather than refining the UI elements or adding details. To make the process quick, I used UI elements from the CMS dashboard (designed previously), which helped me show a more refined version of the designs to the senior team members and the upper management.
ONBOARDING - REGISTRATION
The entry point for this dashboard will be a web page that’ll include all the necessary information related to the dashboard, seller benefits, pricing, and commission structure. The first step is seller registration, which will include the contact details of the seller.
The seller/brand needs to add company details like GST, CIN number, and registered address. These details are required for verification and proving the authenticity of the seller/brand. Furthermore, it facilitates smooth business transactions and compliance with tax regulations. The seller/brand must indicate whether they intend to resell products or if they operate as a brand. Additionally, they are required to select the categories in which they want to sell. This is essential to identify the documents required for the seller/brand to do business with Blinkit.
ONBOARDING - DOCUMENTATION
Documentation for resellers: This screen is designed for resellers to upload the necessary documents during the onboarding process. Depending on the selected categories for selling, specific documents will be requested.
Documentation for brands: If the user is registering as brand then along with GST details, they will be required to provide a Trademark Certificate (as a proof of their registered brand), NIC Registration (National Industrial Classification), which establishes their official classification within the industry.
ONBOARDING - PPOB AND APOB
When the user selects a state to provide their GST number, all the dark stores located in that state will be displayed. The seller/brand is then required to enter their APOB number corresponding to the dark store.
To streamline this process, automation through tech integrations was proposed.
The system should support the identification of APOB and PPOB (Principal Place of Business) numbers by allowing the upload of GST certificates. A state GST certificate typically includes all the APOBs and PPOBs associated with that particular state. With over 400+ dark stores, if a brand/seller intends to sell their products in PAN India, they would need to obtain the APOB number for each of these dark stores. Automation will significantly simplify task.
Since there's a lack of tech integration, we decided to remove the step of providing APOB and PPOB details at the time of onboarding. A consultant or specialist will support these tasks on Blinkit's behalf.
ONBOARDING - BANK DETAILS
I learnt about the documentation details through brand meetings and discussions with the growth team at Blinkit, to understand the legal aspects involved in the onboarding process.
The seller will have the option to skip providing certain details. however, when they begin listing products, they will be prompted to complete the necessary information related to licensing and documentation without which they cannot start selling. These required details ensure compliance and facilitate the smooth process of listing products on the platform.
CATALOGUE - PRODUCTS
When initiating the product listing process, the user is presented with three options:
-
"Search in Blinkit Catalogue": This option is suitable for users who wish to sell products that are already available on Blinkit.
-
"Single Product Request": This option is for sellers/brands who want to onboard a single new product onto the platform. They can submit a request to add this specific product.
-
“Bulk Product Request": This option is ideal for sellers/brands looking to onboard multiple new products. Instead of creating single requests for each product, they can submit a bulk product request, simplifying the process and making it more efficient.
CATALOGUE - SEARCH IN BLINKIT CATALOGUE
Users can search and choose products from the existing catalogue of Blinkit. Once they add the selected product to their catalogue, they must provide relevant licenses and purchase orders (PO) specific to the selected product. The documentation requirements will vary based on their ownership type, whether the user is a seller or a brand. This process ensures that users provide the necessary legal and administrative information according to their selected product and business type.
CATALOGUE - ADD TO CATALOGUE
There are two levels of verifications if the user adds products that are already a part of the Blinkit catalogue. The user will be required to provide a proof of authenticity.
CATALOGUE - SINGLE PRODUCT REQUEST
A user can onboard a product by filling in the necessary information of a product and raising a request to onboard the product. This feature will be useful for brands that not have a presence on Blinkit. This flow is the same as the one provided on Blinkit's brand dashboard. The brand dashboard, also known as Brand Central, serves as a platform for brands to optimize the presentation of their products to Blinkit's audience. Here, brands can add, create, or remove products.
CATALOGUE - BULK PRODUCT REQUEST
This is ideal for sellers/brands looking to onboard multiple new products. Rather than creating single requests for each product, they can streamline the process and enhance efficiency by submitting a bulk product request. If they already have the information in CSV format, they can conveniently upload the file. Alternatively, they have the option to download a template for bulk product upload, which aligns with their preferences.
Users can decide to download either of these two templates to add product details:
General Template: This option allows the user to download a template without any pre-filled data. It serves as a blank template for the user to fill in the required information.
Template by Brand and Product Category: This option provides a template with certain pre-filled data specific to the selected brand and product category. This facilitates a quicker and more convenient process for users by already populating some relevant information.
Additionally, there is an option to upload a list of UPCs (Unique Product Codes). The system will use the UPC details to automatically fetch all the corresponding product details, eliminating the need for manual data entry.
CATALOGUE - PRODUCTS AND PRODUCT REQUESTS
After adding products to their catalogue and completing the verification process, the user will be able to view the products on this screen. The screen will also display all the approved product requests. It is important to note that the products in the catalogue may not necessarily be live or available on the app. This is based on inventory availability.
The product request tab will display all the new product requests created by the user.
INVENTORY - PRODUCTS
This screen is dedicated to displaying the seller's inventory, providing an overview of its health and offering options for restocking. When the inventory reaches a critical limit, restocking nudges will be triggered to prompt the seller to take action.
Available Inventory: This represents the inventory that is ready to be ordered and fulfills customer demands.
Non-sellable Inventory: This category includes inventory that is damaged, expired, or defective. It helps users identify issues related to customer damage, warehouse or dark store damage, or damage incurred by the seller.
In-Transit Inventory: This refers to inventory that has been shipped by the seller and is currently en route to the Blinkit warehouse. It becomes available after the GRN (Good Received Note) is generated upon unloading at warehouse.
INVENTORY - RESTOCK PRODUCTS
First mile integrations: This allows the seller to have visibility of the nearest warehouse of Blinkit, available drop-off slots and create pickups from their own warehouse to Blinkit’s warehouse.
GRN status: Real-time GRN status which shows exactly the number of goods received, count of damaged goods received etc. This information is available at a drop-off level.
Inventory visibility: The seller can view where the live inventory lies in a city. For phase-1 we can share the SKU<> city-level inventory details along with a split between the warehouse and Dark store.
The seller has the option to restock a single product or restock products in bulk. I couldn't define the flow for bulk product restocking within the time frame due to a lack of understanding about the inventory restocking flow. This would also require tech integrations to initiate bulk restocking.
In a single product restocking request, the seller is required to specify the number of units they want to send to the warehouse, provide an estimate of the number of boxes, indicate the drop-off date of the shipment, and select a time slot.
This will redirect to the “Shipment” screen where the user can see all the scheduled shipments.
INVENTORY - PRICING
Sellers will be able to set pricing and discounting rules for all of their SKUs at an SKU<>city level.
We’re not building this at a store level (dark store) in V1 as brands generally price their products either uniformly across cities or with minor differences in cities. (INTERVIEW INSIGHT)
SHIPMENTS
To send the inventory, the user needs to initiate the process through a third-party service. They must then book a shipment drop-off slot and provide the shipment ID in the dashboard to communicate the shipment timings and date. It is worth mentioning that this process is not ideal and can be quite cumbersome.
Ideally, Blinkit would have integrated specific shipment services like BlueDart or Delhivery, allowing sellers to schedule and send shipments directly through the dashboard. However, it is important to note that there are currently no tech integrations available for shipment services, which means the current approach involves using external services for sending inventory and subsequently booking slots based on the estimated time of arrival for the shipment.
In V1, there is no provision for the seller to schedule a pickup. Instead, the seller is required to send the inventory directly to a city warehouse.
SHIPMENT - OLD FLOW
This was the initial version of the design, built with limited knowledge about the shipment process. A meeting was organized with the responsible individuals to gain an understanding of the current shipment and inventory management flow. However, this meeting took place a day before the last day of my project at Blinkit.
During my final two days at the company, I focused on knowledge transfer, important handovers, and providing design feedback on the developed versions of my designs.
SHIPMENT - USE CASES
Despite the lack of necessary tech integrations, an approach was considered to manage multiple shipments, particularly for bulk shipments. This involved using an Excel sheet with pre-filled fields to streamline the process of scheduling bulk shipments. In the case of bulk shipments, there will be different drop-off locations and different timings for each warehouse.
The shipment scheduling flow will be similar to the restock popup on the inventory screen.
SHIPMENT - SCHEDULED SHIPMENTS
This section displays all the scheduled shipments. It includes various shipment states such as "scheduled," "confirmed," "reached," "cancelled," "dispatched," and "incomplete."
PAYOUTS - DISBURSEMENTS
This section displays all the scheduled shipments. It includes various shipment states such as "scheduled," "confirmed," "reached," "cancelled," "dispatched," and "incomplete."
PAYOUTS - TRANSACTIONS
In this section, the user can review all the product-based transactions, which include the total charges for a product, additional charges received by the seller (we took some time to define it), and the Blinkit fees associated with the transactions.
PAYOUTS - STATEMENTS
In this tab, the user can view all the account statements, which function similarly to a bank passbook. It provides a comprehensive overview of the financial transactions related to the user's account.
SALES & PERFORMANCE - OVERVIEW
Users can view their daily, weekly, monthly, and yearly total sales and units sold. Additionally, they will have access to sales rankings based on cities. This feature will assist users in making informed decisions regarding potential expansion into specific cities based on sales performance.
SALES & PERFORMANCE - PRODUCTS
In this tab, the users have the option to view total sales at the product level, track units sold, and monitor the total sales of products. Additionally, this information can also be viewed at the dark store level, providing users with insights into the sales performance and metrics at a broader level.
Successfully completed the V1 of the project within 12 days, including research, interviews, prioritization of feature set, ideation, wireframes, and V1 designs. Received positive feedback from the product manager and handed over all resources to the next designer.