Amazon Seller Flex
fulfill directly from a seller’s warehouse.
Fulfillment by Amazon (FBA)
With Fulfillment by Amazon (FBA), you store your products in Amazon’s fulfillment centers, and we pick, pack, ship, and provide customer service for these products. FBA can help you scale your business and reach more customers.
Our goal is for Amazon.in to have the largest selection of any marketplace in India. We also want a large part of this selection to be part of FBA so that we can provide this selection with a Fast Track promise and ensure great delivery experience synonymous with FBA.
Seller problems
As part of out routine seller visits, product/design team came back with the below seller problems
Sellers don’t commit their entire selection they commit only 10–15% to FBA as they have to split inventory and send it to Amazon’s FC. This inventory is not available to them in case they have immediate demand from some other channel.
FCs getting filled and reduction in space available for getting incremental selection. Any inventory that does not sell in FBA will accrue storage fee and incremental removal cost to get it back. Hence the selection committed is only which sellers are very confident of selling quickly.
Experience hypothesis
To solve these challenges we proposed a new channel called ‘Seller-Flex’ which allows us to fulfill directly from a seller’s warehouse.
The way it works is that the seller will have a dedicated space allocated for Amazon inside their warehouse. The Amazon area is staffed by a very lean team of one Amazon employee to train associates and oversee operations for first month.
- The site uses the Flex Warehouse Management System (WMS). All customer orders drop into this WMS and the seller team picks and packs them.
- Stowing, picking and packing will be managed by Seller employees.
- Analogous to FCs there are designated pickups scheduled by Amazon transportation which then take these packed items out for delivery.
- Since the Flex area is within a seller’s premises the inventory is always ‘at hand’ for the seller.
- Because there is no storage or removal cost accrued by Amazon, we intend to waive these fees off. We believe this would encourage the flex sellers to commit substantially more selection.
A quick design sprint
Getting the team together to conduct a design sprint was challenging due to time constraint and the deadline. but i performed the below activities to make sure the design thinking was accepted by the team.
1. Understand
At the outset of the project we didn’t have a clear mission or specific goals for the experience. Without pre-existing insights, I partnered with our product team to explore how sellers were performing their current tasks.
We shadowed 8 sellers at their own setup, learning how they perform their day to day tasks. Our goals were to understand the motivations and blockers sellers faced and the workarounds they employed.
2. User identification
Seller: Experienced in selling online with an organized team structure.
Account Managers: Works on multiple e-commerce platforms and are responsible for daily activities online
Associate: Juggling with multiple responsibilities, needs guidance on most activities.
3. Storyboarding
Storyboards helped us identify key moments in the experience of a seller going through order processing and inventory management.
It also established a shared vision with stakeholders and revealed issues and key modules early in the product development process.
Identifying user motivators and blockers
Convenience. Managing online is a smart way to do things It saves time, money and effort.
Self image. No one should appear outdated !
Dependency. It’s unfair to burden my boss with online transaction.
Making wrong Decision. I feel confused with so many options, I don’t know which one to pick.
Lack of Control. I get irritated and feel helpless when I make a mistake and I can’t rectify it.
Time and Effort. There are a lot of forms to fill and documents to be produced! It’s way too complicated.
Design guidelines
The user is in control. Give the user the control they deserve; guide them through the product while leaving the decision making up to them.
Simplicity. The system should be intuitive and easy to use, with one main action per atomic UI view. That said, it should provide all the necessary tools for the user to successfully complete their tasks.
Transparency. Inbound to packing to delivering, the user has full transparency of the product.
Trust. Although the user should remain in control, we should provide sensible defaults, anticipate their needs and provide a consistent experience.
Feedback. The system should provide meaningful feedback to the user; help them recover from mistakes as well as understand the options available to them.
Conceptual design
I collaborated with product team and development team to white board possible design solutions based on the storyboard and user needs we already knew.
For each feature phase, I went through cycles of requirements, consensus, approvals, detailed specs and handoffs. My process involved sketching and white‐boarding concepts and flows with my PM partner and then translating these directly into hi‐fidelity design comps. Since I was working with many existing design patterns, it was relatively easy to move straight into hi‐fidelity designs.
Structuring information
I validated our existing WMS application and re structured the information based on the core problems we were solving.
Navigations were based on the user journey and helped to convert users mental model to interactions. Page templates, components, interactions and mobile responsiveness were considered while structuring the information.
Detailed design
My next step involved slicing the comps and piecing them together with InVision into a prototype. In the early stages I focussed only on representing the highest risk areas of the design. Later phases allowed me to focus on micro‐interactions.
Prototyping was the most effective way to gain meaningful feedback from the team, consensus from stakeholders and approval from senior leadership. I was able to easily distribute these as videos and recycle them for Usability Testing.
High fidelity screens established a realistic experience to encourage useful stakeholder feedback, and also we used the same for user testing.
I had to consider and consult development team on current UI platform and limitations.
Testing our assumptions
Once the team had a prototype ready for use, we knew we needed to put it in the hands of our customers. 2 months before launch we doubled‐down on validating our wildest convictions.
Top learnings from our visits
Pick list customization: Auto generation of pick list was appreciated by sellers, however 4/7 sellers wanted flexibility to generate their own pick list manually.
Sellers planned the assignment of associates based on number of orders for a given day/s and availability of resources.
Pick list customization was a top need by our sellers, and we revisited our design to cater to their specific needs without compromising on the other users.
Learnings from our initial launch
Since launch 80K + units have been shipped out by sellers using SF 2.0 with Late ship rate (LSR) of .03% (vs target of .05%). Sellers have witnessed an increase in order processing efficiency by 25–30%.
“Outbound processing is very easy to use. Anyone in the warehouse can use this software to process orders” Vansh, LagOm Retail
“yes we can see drastic change in usability of seller flex portal. speed of shipment packing is almost double, less paper waste, less confusion. Pick task, Pack and Ship tab give clear picture of all orders status, need one more tab for Order Alert which may be not shipped due to any reason, so shipment ship on time and give customer best shopping experience” — Seller — perfect blue
Experience in Action
My learnings
One of Amazon’s leadership principles is having a bias‐for‐action. Amazonians are proud to insist that product decisions are reversible and spending time doing is better than over analysing.
Throughout this project, I observed how bias‐for‐action mutated into a bias‐for‐delivery. Our team disproportionately focused on measuring outputs, rather than learning and measuring outcomes. This inevitably led to a lot of waste, short‐sightedness and distraction for the team.
We let the question “how quickly can we build it?” define the it, more than we let our customers define it. We let the phrase “let’s just get something out there” define quality, more than we let our customer define quality.
If we had asked “are we building the right thing?” as much as we asked “are we going to meet our date?“, we would have launched a more reliable, intuitive and polished product, sooner.
Viability should have been defined by our customers way before the technology and date already did.
