Download to read offline
ONDC - Case Study - Anshul Karn.pptx assignment
- 1. ONDC - CaseStudy NETWORK OPERATIONS
- 2. Overview Operations • Order Cycle •Check Mechanisms • Cost Allocation • Operational Challenges • Payout Cycle Buyer App • Search • Catalog • Ad platform • KPI’s • Challenges Seller App • Functions and KPI • Onboarding • Catalog Creation • Merchant Helpdesk • Challenges Logistics & Customer Escalations • Functions and KPI
- 3. Order Cycle Exceptions OrderPlaced Order Picked In Transit Order Delivered Return Order Return Picked Delivered to seller Seller Buyer App Logistics Customer Customer Returns the Product after delivery *Seller can also provide Logistics *Seller/ customer can also provide Logistics Defective/ Damaged Partial Product Wrong Product
- 4. Safeguard and CheckMechanism Order Processed In transit Delivered Return Return in transit Return Delivered Insuranc e Provider Logistics Provider Seller Seller Customer Logistics CCTV Video *Serial Number CCTV Video X Ray Scan Shares Product Video and Image CCTV Video QC Check by Logistics before pickup CCTV Video X Ray Scan Proof of Delivery Signed by seller
- 5. Who bears thecost? Order Placed Order Picked In Transit Order Delivered Return Order Return Picked Delivered to seller Seller Buyer App Logistics Customer Customer Returns the Product after delivery *Seller can also provide Logistics *Seller/ customer can also provide Logistics Replacement can be delivered After return is picked from customer Customer Returns the Product after delivery
- 6. Return Reason Responsible Partner Product Cost SellerApp commission Buyer App commission Logistics Damaged Product Logistics Partial/ Full Yes Yes Yes Seller Yes Yes Yes Fraud customer (Seller bears cost) Yes Partial Product Delivery Logistics Partial Yes Yes Yes Seller Yes Yes Yes Fraud Customer ( Seller bears cost) Yes Wrong Product Delivered Seller Yes Yes Yes Logistics Full Yes Yes Yes Buyer App Yes( if damaged in transit) Yes Yes Defective/ Dead on arrival Seller Yes Yes Yes Customer cancels order Seller Yes Who bears the cost?
- 7. Operational Challenges Order PlacedOrder Picked In Transit Order delivered Returns the product Return picked Delivered to seller Seller Buyer App Customer Seller is the delivery partner *Seller/ customer can also provide return logistics Customer signs POD via app Or seller marks order delivered Through a messaging / missed call Based system If customer ships return: Seller to mark return Delivered, only then Refund to customer is processed
- 8. Seller Processes Order Order Delivered Return Period Payout Payout cycle Seller getspaid Timeline of Payout Logistics gets paid Seller App gets paid Buyer App gets paid Logistics gets paid for COD Order
- 9. Buyer App –Search and Discovery Sorting Search results • Price • GMV • Traffic/ Conversion • Units Sold • Product Rating • Sponsored Product Sorting of sellers on Product Page • Seller Rating • Recent Seller Operational Metrics • Delivery Timeline Is enough information being shared by the seller app to ensure sellers products have fair chance of discovery in search results? New Seller Old Seller Rating Reputation Reviews
- 10. Catalog Challenges Duplicate Products • Ensurecatalog of sellers include EAN/UPC numbers wherever possible • No new creation of product if EAN/UPC is in the database UI Problem • Multiple sellers have listed the same product but with different images/ product description fields • Which listing must be shown to the customer? Tax Rates • HSN codes need to be associated with every product to identify correct tax rate • Can be seller editable or picked directly from GS1 database Taxonomy • Buyer app is unaware of product category • Product categories must be defined and standardized Return Period • Sellers are being asked to share the return period of products • Are the buyer app systems equipped to deal with this data? • How will this effect seller payout?
- 11. Buyer App –Ad Platform Common Ad portal Manage Ads Payments Analytics Every ad portal has different properties, ways of bidding for keywords and settlement terms A common portal for the convenience of sellers where they can create ads, view analytics and manage payments Payments can be made in advance or on a billing cycle as the ad platform prefers Open access to ad properties which are at times managed manually, outside the scope of small sellers
- 12. Buyer App KPI Data on Impressions, Clicks for regular and sponsored results Number of catalogs rejected with reason Access to all ad properties Barred sellers who have crossed category linked operational SLA and their relisting criteria Are Payments being made to sellers on time? ONDC sellers to get access to promotion events and visibility of the products during sale events.
- 13. Buyer App Challenges ShortTerm • Working with new catalogs • Category identification of products from Gateway • Operational challenges in absence of established communication channels within network • Managing customers escalations from ONDC Network • Visibility of products from new sellers Long Term • Marketing costs to attract customers vs commissions charged • Retaining existing marketplace sellers to ONDC Network partners in case of low commissions • Pending cases with Network Partners ( ODR/ Court) • High Cost of integration and adaptation to guidelines and policies from the Network
- 14. Seller App –Functions and KPI Onboarding • Number of applicants • Applications in progress • Sellers onboarded • Sellers rejected with reason • Sellers with active inventory • Sellers with inactive inventory Catalog • Catalog requests received • Catalog requests processed • Products created count • Duplicates removed count • TAT for catalog processing Order Processing • QTY, GMV of orders • Seller order processing time • Seller cancellation rate • Seller return rate with reasons • Seller at fault for late pickup • Seller did not accept return from customer
- 15. Seller App -Onboarding Pre onboarding Info Category commission Logistic Charges Payment Gateway Charges Seller app charge Payment Timelines GST/ Multiple Registrations PAN Card Bank Details ( Cancelled Cheque) Warehouse Address (Multiple) Basic Criteria Must be visible on all seller apps and their communication channels
- 16. Seller app –Catalog Creation Existing Products • Pull data from known sources- Flipkart, Amazon • Sellers can share links of these products • Faster way to upload catalogs New Products • If EAN/UPC is not a match, create a new product • Identify minimum mandatory parameters for each category of products ERP Live Inventory Sync ONDC Network Buyer Apps A live inventory and price sync mechanism from an ERP system is critical for sellers and ONDC as a network to scale
- 17. Merchant Helpdesk Order related •Suspicious Buyer • Incomplete address • Order not picked • Tech Issue in processing Catalog related • Catalog not uploaded • Unable to edit catalog • Brand Approval Payment related • Incorrect Payment • Payment not received • TCS/ TDS related Returns related • Return not received • Damaged product received Seller Performance related • Request for removal of review • Relist after getting debarred Promotions related • Ad not visible • Unable to create ads Common Merchant Issues
- 18. Seller App -Challenges Short Term • Attracting new and first time sellers • Less number of orders initially • Operational challenges in absence of established communication channels within network • Educating New sellers as the platform evolves • Ensuring sellers and logistic partners are adhering to the timelines and Long Term • Are commissions enough to sustain the business • Retaining sellers who have faced operational difficulties • Pending cases with Network Partners ( ODR/ Court) • Will a fixed platform and logistic fee model work or should sellers be charged for every transaction
- 19. Network Intelligence ONDC Network Payment Gatewa y Seller App Buyer App Logistics Provider • Informationon fraud sellers and customers exists in silos • All network partners can share this information, this will help maintain a heathy network and keep costs in check in the long term
- 20. Logistics - KPI Order Processed Intransit Delivered Return Return in transit Return Delivered Order Processed In transit Delivered Return Return in transit Return Delivered Seller Customer Logistics Time Taken to deliver Order Time taken to deliver return order Time taken to pick the order Time taken to pick the order Time taken to pick return order Cost Based • Order Qty, Value damaged in transit • Insurance claims by sellers Coverage Based • List of pin codes ( Forward) • List of pin codes ( Reverse)
- 21. Customer Escalations Centralized Ticketing System Buyer App Seller App LogisticsSeller TSP’s Payment Gateway Customer • Number of tickets received • Number of tickets pending with respective Network Partner • Number of tickets solved within TAT • Number of tickets unsolved by Network Partner • Time of ticket spent in the owners bucket • Number of cases that moved to Level 1, 2,3 • Tracking of cases that went legal, were they solved • Number of tickets with ODR service provider and time taken to solve them. KPI
- 22. Role of ONDC Ensure that interests of all network participants is secured, keeping in mind the market forces and dynamics. Empowering and educating the smallest of the sellers to have a fair chance of inclusion in a highly tech oriented ecommerce domain. A small retailer having to compete against a 10 minute delivery system poses a huge threat to the retailers future, empowering them with competitive hyperlocal services will be key to the survival of such small entities. Learning from experiences of Network partners, playing the role of facilitator and mediator in situations of conflict, advice the network on good practices. Balance the supply created with inclusion of as many buyer apps as possible
Editor's Notes
- #3 Customer Returns the Product after delivery When customer returns the product, the reverse logistics partner would pick up the order, and deliver it back to the customer. Return can be due to the following reasons: Defective/ Damaged Product – seller or logistics can be at fault Partial Product Delivery – seller or logistics can be at fault Wrong Product Delivered – seller, logistics or even buyer app ( wrong catalog shown) can be at fault
- #4 It is advisable that insurance provider be allocated to handle the costs in case a product is damaged/ partially damaged during transit. This can be implemented in two ways: The logistics partner has a tie up with an insurance provider and extends this facility to the seller, the seller in such a case may be covered for insurance claims for transit damage as per the provisions made between logistics provider and the seller. Seller might be charged a fee for every order processed based on the product category they deal in and this will cover them for the transit damage. Check Mechanisms for a healthy network: Ask sellers to add Serial numbers (difficult to implement, limited use at scale) of products and videos (CCTV) proving either the packaging is intact or product with the serial number is visible. This data can be added to the shipping labels/manifests and invoices. Videos should be uploaded before processing the shipping label. Logistic service providers who have access to x ray scanning facility/ CCTV video can help check cases of fraud. Return QC Check: RTO’s that will be picked up need to be verified by the logistics provider Return to be acknowledged by seller ( signed proof of delivery document)
- #5 If the product is non returnable, but has visible signs of damage, defects- then order can be returned, seller will bear the cost for Return and replacement logistics ( if provided). When customer returns the product, the reverse logistics partner would pick up the order, and deliver it back to the customer. Return can be due to the following reasons: Damaged Product – seller or logistics can be at fault Basis the check mechanisms in place( Serial number/ video), we can identify if seller has shipped the right product, the product quality on the basis of video shared. So seller can be held accountable for the cost. In case seller themselves have shipped the product, the seller is at fault. If the seller is not at fault, it is likely the product was damaged in transit, or the customer is fraud ( has damaged the product, might have a history of similar cases). If the customer checks out, then ideally this cost should then be taken up by the logistics partner. Cost for logistics: Product cost( partial/ full) + Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) Cost for seller: Product Cost (as loss) + Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) Fraud customer case: Seller will bear the cost ( ideally, buyer app commission should not be taken in this case) 2. Partial Product Delivery – seller or logistics can be at fault Seller can be identified basis, the serial number, or video, if the product part was genuinely missing from the packaging, the seller may ship the rest of the item(s) to the customer through the network partners. If the video shows that the full product was shipped, in that case the logistics or customer is at fault, if the customer checks out, logistics partner needs to bear that cost Cost for logistics: Product cost( partial) + Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) Cost for seller: Product Cost (as loss) + Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) Fraud customer case: Seller will bear the cost( ideally, buyer app commission should not be taken in this case) 3. Wrong Product Delivered – seller, logistics or even buyer app ( wrong catalog shown) can be at fault Buyer app displays the wrong catalog, buyer app will bear the cost of: Logistics( forward + return) + commissions ( seller app) If catalog was provided by seller, in such case seller pays the cost. If logistics is at fault, the correct product must be identified and delivered, unless it is lost and in such a case logistics bears all the costs. Cost for logistics: Product cost( Full) + Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) 4. Defective/ Dead on arrival : Seller bears the cost : Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) 5. Customer Returns the Product or cancel order which is in transit If product has not been shipped : No cost for seller If product has been shipped: Cost for seller : Forward, Reverse Logistics ( can be deducted from refund given to customer if buyer app wishes so) * If customer provides reverse logistics, once the bill is shared, it has to be deducted from the payout of the responsible partner. ** All replacement logistic cost to be borne by the responsible partner. ***A seller who delivers the product on their own and has cash on delivery option enabled must ensure a COD balance account is maintained, in cases where customer has to be refunded for a COD order, then the refund can be paid via this COD account. One has to ensure that the value of orders does not exceed the COD balance of the seller.
- #6 When customer returns the product, the reverse logistics partner would pick up the order, and deliver it back to the customer. Return can be due to the following reasons: Damaged Product – seller or logistics can be at fault Basis the check mechanisms in place( Serial number/ video), we can identify if seller has shipped the right product, the product quality on the basis of video shared. So seller can be held accountable for the cost. In case seller themselves have shipped the product, the seller is at fault. If the seller is not at fault, it is likely the product was damaged in transit, or the customer is fraud ( has damaged the product, might have a history of similar cases). If the customer checks out, then ideally this cost should then be taken up by the logistics partner. Cost for logistics: Product cost( partial/ full) + Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) Cost for seller: Product Cost (as loss) + Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) Fraud customer case: Seller will bear the cost ( ideally, buyer app commission should not be taken in this case) 2. Partial Product Delivery – seller or logistics can be at fault Seller can be identified basis, the serial number, or video, if the product part was genuinely missing from the packaging, the seller may ship the rest of the item(s) to the customer through the network partners. If the video shows that the full product was shipped, in that case the logistics or customer is at fault, if the customer checks out, logistics partner needs to bear that cost Cost for logistics: Product cost( partial) + Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) Cost for seller: Product Cost (as loss) + Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) Fraud customer case: Seller will bear the cost( ideally, buyer app commission should not be taken in this case) 3. Wrong Product Delivered – seller, logistics or even buyer app ( wrong catalog shown) can be at fault Buyer app displays the wrong catalog, buyer app will bear the cost of: Logistics( forward + return) + commissions ( seller app) If catalog was provided by seller, in such case seller pays the cost. If logistics is at fault, the correct product must be identified and delivered, unless it is lost and in such a case logistics bears all the costs. Cost for logistics: Product cost( Full) + Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) 4. Defective/ Dead on arrival : Seller bears the cost : Commission (seller app) + commission( buyer app) + Logistics ( forward+ return) 5. Customer Returns the Product or cancel order which is in transit If product has not been shipped : No cost for seller If product has been shipped: Cost for seller : Forward, Reverse Logistics ( can be deducted from refund given to customer if buyer app wishes so) * If customer provides reverse logistics, once the bill is shared, it has to be deducted from the payout of the responsible partner. ** All replacement logistic cost to be borne by the responsible partner.
- #7 In case the seller delivers the product, order tracking might not be possible in such a case. One must ensure there is a mechanism to mark the orders delivered at the time of delivery. This can be an app based solution which collects the GPS coordinates, customer name and signature or in places where internet connectivity is an issue, a simple messaging or a missed call based system that then marks the order delivered in real time. The reason why we need this to be done in real time is that once the customer wants to return the product, they wont be able to make that choice in the buyer app as the order status will be still in transit. If the customer returns the product and ships it themselves and reverse logistics is not available from the network partner, in such cases tracking is not possible. In such cases, the seller will mark the order delivered once they receive the order. Refund to customer should only be given once seller has received the order
- #8 Seller: To be paid after order return window is closed Logistics Partner: To be paid after order return window is closed, unless it is a Cash on Delivery order in which case a logistics partner may want this to be paid in advance Seller App commission: To be paid after order return window is closed Buyer App commission: To be paid after order return window is closed Buyer App Ad: Prepaid or after ads are run as per their system ( monthly billing, or campaign wise settlement)
- #9 As a buyer platform, one would consider the following parameters in ranking/ sorting the search query results: 1. Sorting search results by: Price, GMV, Traffic, Conversion, Units, Product rating, sponsored product (backed by Ad) 2. Sorting sellers within product page by: seller rating, previous Operational SLA metrics, delivery timeline In such a case, is ONDC as a network capturing all the parameters required from the seller app and thus giving the best chance for a seller and their products to be discovered on any buyer app. Ideally, the sorting logic parameters must be shared from the seller platform to ensure sellers on ONDC network get a fair representation just like any other captive seller would get on the Buyer App. Understanding the perspective of the journey of a new seller vs an old one. How can a new sellers products be discoverable given they might not fare high in the buying logic adapted by a buyer app.
- #10 Reference for these suggestions are taken directly from the ONDC Catalog Template of Sellerapp: http://ec2-34-221-130-80.us-west-2.compute.amazonaws.com/x/d?c=27238015&l=b31e733f-548e-4107-a807-a5498ee7b7a4&r=012879f5-45da-4ff5-8340-d61e397bc30a As a buyer app, these are the challenges one might face from a catalog’s perspective: 1. From the search results shared by the gateway, identifying the parent SKU provided will be a challenge, one does not want duplicate results in search. 2. Considering product description fields shared by sellers might vary for the same product, which product description/ image/ video must a buyer app show to the customer? Consider a case where after going through the product features, a customer then chooses a seller, only to find that a different color product has been delivered, this becomes a challenge from a UI perspective as well. 3. Are Tags/ product name/ description enough to identify a products category and the HSN code( tax rate associated with it) Q. does gateway or seller app follow appropriate measures to avoid duplicate listings Q. Should taxonomy/ category tree be defined Q. EAN/UPC + HSN codes to be included in seller catalogs Q. Most efficient way to create catalogs for existing products on other portals Q. Do buyer apps consider the return period values shared by sellers, if so are their systems in place so that payment to seller is only released after return period
- #11 Current scenario: All ad platforms have their own properties, methods in which keywords, negative keywords, bidding is done. Not all ad platforms have the capability to offer in depth targeting, certain platforms don’t ask for keywords to be targeted, they have a list a premade group of keywords ( ad groups) that are defined by the products category For the convenience of a seller, can a NP provide a single platform to manage ads for all buyer apps, rather than the seller having to individually register on different platforms and collate data from there. The ad platforms are also different in the way they operate their settlements. One platform might allow the seller to run ads first and then pay for them from the earnings of their sale, others might want outstanding to be settled within a particular time frame, or a platform might want the seller to pay for the ads in advance. This situations creates the space for an ad platform aggregator which can be allowed to collect payments towards ads in advance. The platform must offer basic minimum services a merchant helpdesk, share gst invoices for the ad spend. Short term: Engage third party Digital marketing ad agencies, help sellers understand the ad space and let the service providers run ads on their behalf until an ad aggregator arrives. A common login can be shared with the sellers to login to the respective ad platforms Long term: Let ONDC monitor if guidelines for ads are being followed ( Media rating council’s standards on Viewable impressions or a new standard which can be set for India), for example: how would an impression be counted? Can ad platforms share their data on the bids vs the impressions given for the campaigns run so that a seller gets to know that they have paid a fair amount for the impressions/ clicks they get, current system is closed and not transparent. Certain ad properties are not accessible to ordinary sellers, in such cases can ONDC provide access to these ad properties to all sellers.
- #12 KPI Data of impressions, clicks, sellers who opted for ads – impressions and clicks Data of products not shown, rejected because the catalog did not qualify minimum parameters Are all ad properties accessible to ONDC sellers Sellers whose products are not shown because they have exceeded category wise returns Relisting criteria for sellers whose operational parameters can be improved Can ONDC sellers opt into promotion events Are sellers being paid on time
- #14 Onboarding: Number of applicants Number of applications in progress Number of sellers onboarded Number of sellers rejected with reasons Number of sellers with active inventory Number of sellers with inactive inventory Catalog: Number of catalog requests received Number of catalog requests processed Number of catalog request rejected with reason More information required from seller Number of products created Number of duplicate removed TAT for catalog processing Order Processing Cycle Number of orders/ items GMV of products Seller order processing time Seller cancellation rate Seller return rate- reasons for the return Seller at fault for late pickup Number of orders liquidated- seller did not accept the return
- #15 Sellers must be aware of the policies of the seller platform, basic information like commission on respective categories, costs that are to be borne by sellers( logistics, Payment Gateway) and payment timelines must be mentioned openly on seller apps Basic requirement to verify sellers: GST, PAN, Bank details (with cancelled cheque), warehouse address ( to be verified from GSTN) Seller app must be able to be configured in a scenario where seller has multiple warehouses, or seller has multiple GST registrations( working from different states) At all times, sellers status of GST number to be verified from GSTN, verify if returns are being filed regularly. We do not want to be giving orders to a seller whose GST number has been put on hold/cancelled or if a seller is operating from a different location not mentioned in additional place of business, or to a seller who is not filing returns to provide input credit to their customers.
- #16 Existing Products: Ideally, pull data from existing sources i.e Amazon, Flipkart, Brand websites etc. New Products: Taxonomy to be defined by ONDC Include EAN/UPC in catalog field to ensure duplicate listings are not created HSN code can be either asked from seller, or be pulled from GS1 database from the EAN number shared Ask seller about the processing time required to procure the product Seller must freely be able to make changes to the inventory or price of the product, given there are a minimum of 2 sale events in a month on any platform, it will be preferred that seller apps give this functionality of editing these values in real time to sellers. Eventually, seller app can also have provisions to connect with an ERP system( Tally, Zoho etc) to sync live inventory. Requirements from a seller dashboard perspective
- #19 To minimize the risk for all network partners, it is best that an intelligence network be created to ensure fraud sellers and fraud customers are kept out of the system. While this information may be available to individual network partners in their years of business, access to this information at a central level might be critical in curtailing costs and keeping the network healthy. Payment Gateway: Will have information on customers involved in financial frauds Buyer Apps: Will have information on customers that have been involved in fraud behavior, example- returning a different product and claiming refund Seller Apps: They will have information on sellers, example- a seller might be sending defective items to claim insurance Logistic Network: They will have addresses of places where potential fraud has happened, they might have very high return rates, in another use case, to identify addresses that are not traceable or do not exist.
- #20 Logistics Pick order from seller and deliver to customer Return orders to seller which are cancelled or returned by customer Collect cash for COD Orders Enabling COD functionality ( with a few logistic partners) involves sellers to place a deposit in a prepaid account so that logistic charges can be processed. In such cases, having one account from where any logistic partner can deduct this charge would be ideal. KPI Time based Time taken to pick order from seller Time taken to deliver order to customer Time taken for reverse pickup from customer Time taken to deliver reverse pickup to seller Cost Based: Number of orders damaged in transit, value of orders damaged in transit Damage cost covered by insurance for seller, claim amount received by seller Number of sellers who left due to logistic issues Coverage Based List of pin codes eligible for delivery ( forward) List of pin codes eligible for delivery(reverse)
- #21 A centralized ticketing system to handle customer escalations, that automates the first level of response and allocates the ticket to the appropriate owner. All responses have to be filed within a reasonable TAT defined by ONDC. Ideally, information that is awaited from seller, or any other network partner must be available to the respondent of the ticket at first glance so that minimum time is spent collecting the information to make an informed decision. Example: A cctv video footage/ x ray from a logistic partner, serial numbers from seller should already move and be readily available if the nature of the case requires this information. KPI: Number of tickets received Number of tickets pending with respective Network Partner Number of tickets solved within TAT Number of tickets unsolved by Network Partner Time of ticket spent in the owners bucket Number of cases that moved to Level 1, 2,3 Tracking of cases that went legal, were they solved Number of tickets with ODR service provider and time taken to solve them. Concern: In the existing system, the network partners get 7 days to respond within themselves which is a lot of time, the more the number of days we keep the customer waiting, the higher are the chances for them to move to consumer forum/ legal route. Disputes within Network Partners: While the ODR system will try to handle the cases, it must be in agreement between all network participants that this mechanism must be treated as the final authority on decision making. Even though ONDC wishes to play a role of facilitator and not regulator, an established line of communication with the affected network parties is critical for a smooth operating network. In case a network partner wishes to exist, adequate policies must be established to ensure all exist clause conditions are met and no other network partner is affected in their operations and settlements.