Reducing frauds due to wrong RTOs on Meesho
As part of Meeshos’ internal business assessment it was flagged that reimbursements to suppliers on Meesho has been a major cause of concern and needed immediate action to make sure of transparency, accountability and avoid fraudulent behaviors on the platform. Hence this project was conceived and I worked as a solo designer on this project along with my project manager. This project is now live to sellers on Meesho.
Image - Photo from live use case scenario
Background
Currently, suppliers on Meesho have the discretion of carrying out the logistics of their orders in any packet that is the white/grey polythene they use to pack and ship orders. These packets are imitable and are easily available in the market and don’t have any verification or standardization on them. This leads to third party suppliers on-ground executives replacing the actual ordered items/polythene bags to commit theft/frauds. When these orders are put to RTO (returned to origin), suppliers raise the dispute that wrong item is received. We aim to reduce these operational frauds and thereby reduce reimbursements to zero on platform.
Problem Space
At Meesho it came to our notice that Item mismatch during RTOs has been a ongoing problem which needed an appropriate fix.
But what is Item Mismatch - it means that the Item A sent in forward leg ( orders shipped to customer ) by suppliers, but during return ( RTO ) to suppliers the delivery executive hands over Item Z.
This Item Mismatch fraud is not accountable on any person or organization , thereby causing increase in reimbursement requests and costs to Meesho.
How does frauds happen in RTOs ?
Suppliers unhappy with the current experience where they have to go through a rigorous process of raising claims with a high rejection ratio
Suppliers want to get their products back in same state as they had shipped out
Suppliers know delivery executives swap packets but cannot pinpoint the blame
Suppliers don’t want something that would be a roadblock to their current business process
What supplier have to say ?
Image - Supplier calling to understand issues with reimbursements
Image - Fraud Instance Representation
Understanding the problem at its core
To understand the core problem, we had a workshop along with project manager and trust and safety pod where we tried to determine the core reasons for reimbursements through quick iceberg analysis of data we had received over a period of two years
Image - Ice Berg Analysis
Insights to work upon
Enabling Sellers to check their packets during RTO
Ensuring accountability of the packet on individuals
Ensuring legitimacy of packets and reimbursements
So here are the design challenges
How might we enable sellers to check if the product and packet returned is the same as the one shipped ?
How might we ensure accountability of individuals during every part of the delivery process and Meesho knows about it ?
How might we ensure legitimacy of packets before processing for reimbursements?
Operations team considerations
Initial brainstorming ideas for creating the journey for the suppliers
Post brainstorming I took to the board to create and test my ideas with users and get feedback
Design considerations
Segregated flows for scanning packets during shipping and receiving products.
Scanning Decision at each point dependent on seller , thereby ensuring freedom of usage.
User shown collection of all data to close the feedback loop
What are Barcoded Packets
Operations teams on ground had successfully run an experiment of introducing specially made Barcoded Packets instead of easily avaialble white packets, with 50 sellers with high order count and found out
Suppliers were more acceptable of the barcoded packets
Suppliers believed there were less chances of fraud
Suppliers had more assurance on the Meesho system
Barcoded Packets are tamper proof plastic packaging ( in specific color and pattern ) provided by 3rd party sellers that have been contracted by Meesho, with specific QR codes that are mapped to Meesho supplier IDs who buy it.
Image - Meesho Barcoded Packets
Iterate fast , fail fast !
As part of secondary research I found out that both Amazon and Flipkart do not face much of an issue with the above problem space as they already have their own logistics company with branded packets. Having the insights and business initiatives of introducing Meesho barcoded packets as guardrails I started iterating fast and tested my ideas with sellers.
User Testing Outcome
Too many clicks and decision points for sellers
Too much data, sellers losing out on which data to focus
Difficult to comprehend error / false packets scenarios
Iteration 1
Design considerations
Creating success and error states more understandable
Making data and job to be done synchronous
Keeping decision points to three clicks
User Testing Outcome
Low emphasis on scan button on Homepage - thereby difficulty in comprehending its usability
User still has multiple decision making points creating friction in current on ground flows
User has better comprehension of success and error states
Sellers fail to comprehend usage of tab in forward and return leg.
Iteration 2
Design considerations
Creating minimal touch point to avoid friction
Reducing decision paralysis by automating scanning functions from backend depending on state of AWB Barcode scanned
Keeping only most relevant information - reducing data overload
User Testing Outcome
User find automated flows work better for bulk scan
Users want concurrency usage of the scanner which lead to development difficulties
A one stop documentation for all scanned packets - suppliers confused with date, time and person who scanned.
Iteration 3
Design Decisions
Lets start with the user flow
After a lot of going back and forth on the designs that would best suite the users I decided to breakup up the problem scenario into jobs to be done by the users and create flows for the same.
So, here are the Design Considerations
Suppliers want to buy Barcoded Packets
Buy Barcoded Packets - The most used/ viewed panel is Orders Panel, hence to have more traction on this new feature I decided to have the Buying Ingress point on orders panel
Connecting Buying packets to reducing RTOs - You tube video for educating suppliers about usage Barcoded Packets along with information of trusted vendors from whom to buy
Enable seller to find out wrong packet during RTO
Check Packet -Seller scans both Barcode and QR code , if it matches saved server data then legitimate packet conveyed, if its not a match - supplier suggested not to take back packets
Packet QR code may be damaged - As transition to supplier during RTO is 45 days or more , codes may be damaged hence provision for manual entry provided
Save Information about Packet & Product while being shipped to customer
How to save Information - Scanning AWB Barcode of product and connecting it to the QR code of the tamper proof packet while shipping the product.
How to easily scan - Conventional scanning devices have a lot of hardware constraints, hence it was decided to leverage the Meesho mobile app to scan the codes.
Scan without interruption - Suppliers ship more than 50 products a day, hence this process shouldn’t add more time to the already existing operational process
Help recover from error easily- As this will be a operational process and fast paced, suppliers would need a lot of glanceable information to understand the state of scanning and saving information
During shipping to customer
During returning to seller ( RTO )
Validation from suppliers
Post design modifications I reached out to the sellers in person and conducted usability tests to validate if the suppliers are able to use and detect wrong packets and are they able to recover from their errors easily.
Suppliers easily finds out wrong product
“Ye toh galat packet hein , dikh raha hein laal matlab galat"
Suppliers can now set people accountable
“Ab 3PL samjega jab fraud karega , nahi bhaag payega”
Suppliers don’t want extra time add ons
“Ye thora time lega kya ? Extra time lagega toh kaise hoga ? Ye mandatory hein kya "
Challenges faced
The major challenges that I faced as a designer on this project are
Understanding on ground operational issues. Business teams and suppliers had difficult in conveying what are the on-ground loopholes
Creating an operational system with stakeholders as suppliers and 3PLs created a lot of edge case scenarios
Issues with development as a lot of server end data cannot be collected on local devices of suppliers who use more than one device under one supplier ID.
Reducing feature use time for suppliers yet ensuring bulk scan with limited API call , major roadblock in the project
Needed to understand a lot of engineering heavy discussions to get the proper and impactful design walkthrough
Image - Retro sessions on what could have been done better