Eliminating fake / jailbreak phones during exchange
- Year
- Role
At the customer's doorstep, during phone exchange and trade-in.
00Overview
Completely removing rooted and jailbroken phones from Amazon’s exchange, before they’re ever picked up.
The idea was to run backend checks and tell the delivery associate whether to pick up the old phone or reject it. The user here is the delivery associate, not a technical person, operating strictly on the instructions given to them.
01The customer problem
2.3%
of overall exchange orders during Diwali’18 were affected, enough to blunt the competitiveness of exchange on Amazon.
Trust is the thing customers exchange first.
Customers cannot exchange high-value devices such as OnePlus, iPhone and Samsung models on Amazon, either because they are unavailable for exchange, or because they carry low exchange quotes on A.in. The same models fetch higher quotes with IC and offline stores (Cashify and FK).
The primary reason for low exchange offers on high-value devices is the delivery associate’s inability to identify whether the phone is jailbroken or rooted at the moment it is collected from the customer. To work around it, such selection was removed from Amazon during regular days and made competitive by adding sweeteners on Offer days, causing burn.
To increase exchange competitiveness and give customers more selection, we had to identify fake and rooted phones at the time of exchange, and reject them at the doorstep.
02Coming up with solutions
Make or break for the exchange program.
We were confident in the problem and the need for the right solution. Coming up with one was the hardest part, it would make or break the exchange program at Amazon. So the exchange team sat down to find solutions that needed no, or minimal, customer intervention at the doorstep.
Concept workshop, voting on directions, and mapping what each meant for brands and for customers.
The voted concepts
01
To send an SMS to the customer's phone and navigate them to the browse page to show results.
02
Send an expert to verify the phone.
03
Send an SMS to the customer's phone to generate a QR code that the delivery associate can verify.
04
Bring the customer to the Amazon landing page and show results.
05
Bring the customer to the Amazon Your Orders page and the corresponding order page to generate results.
Behind the scenes
Verification runs on a third-party capability (Servify). The Servify SDK runs the tests that identify fake phones and stores the results, which are populated whenever they’re called for.
Most concepts weren’t technically achievable for the deadline, the upcoming Diwali, when the platform sees the most orders and the highest exchange adoption. The capability to detect fake phones still had to be built and shipped in time for it.
03The last option & validation
The only option we could ship, and where I pushed back.
The solution achievable for the Diwali launch demanded customer intervention at the doorstep. The customer had to be signed in to their Amazon app on the device being exchanged, so the DA could verify the exchange with the help of the Servify SDK, which runs checks on the phone in the backend and confirms whether the used phone is fit to be picked up.
We agreed on the problem and that it needed solving fast. But from a UX standpoint, I had real concerns about this solution.
Validation session, pressure-testing the doorstep flow against timelines, ownership and transparency.
Three ways it could quietly backfire
01
The customer's mental model when selling a phone is that they have to delete all the files from their device before it is passed on to the next person.
02
Relating to what customers have learned previously, a large portion of them would erase all content and sign out from their devices before the DA arrives for pick up, irrespective of any push notifications and SMS.
03
For customers ready to do a quick doorstep exchange, asking them to log in to their account and install the app would be frustrating. Customers are not aware of the phone-rooting issue before the DA arrives, so introducing new friction at the doorstep would result in the customer suspecting the DA's intention.
This might lead to more reject rates.
04Customer journeys
Two journeys, mapped end to end.
The front-end steps the customer and delivery associate move through, and the backend verification running quietly beneath them, current workflow against proposed.
Journey 1 · While purchasing the device, the moment exchange is applied, Servify is prompted to verify the phone and stores the result in the background.
Journey 2 · While exchanging the device, the proposed flow replaces manual IMEI and OTP checks with an in-app verification that runs for every exchange order.
Business impact
52%
Decrease in exchange rejects
46%
Reduction in fake-phone exchanges
29%
Higher conversion of devices with exchange
