Self-Service Onboarding
A more efficient onboarding process, reducing time to value along with sticking points
The old onboarding experience for Wayfair's supplier portal (Partner Home) was rife with sticking points and unclear dependencies that required admin intervention, leading to an average time to value of 60 days. This statistic, along with the number of support tickets that onboarding suppliers submitted on a monthly basis, underscored the need for a revamped experience free of these inefficiencies.
Defining the Overall Problem
Wayfair supplier onboarding, as it existed in its previous state, was a complicated process involving a number of different actions that needed completing:
-
Signing a supplier agreement
-
Understanding payment terms and choosing a payment method
-
Uploading a catalog of SKUs (products)
-
Informing Wayfair of warehouse locations
-
Setting up API integrations for inventory and other data management
-
Etc
The process of completing all of these steps required Wayfair admins to work with the onboarding suppliers at multiple steps in order to clarify requirments, give status updates, and problem solve for increasingly frustrated suppliers.
My design team, along with our crossfunctional counterparts, set out to create a self serve experience that would drastically reduce the admin touchpoints, provide constant visibility into status, and improve time to value.
Illustrating the Supplier Journey
As a design team, we faced the challenge of garnering support for moving beyond just addressing the obvious problems with the old onboarding flow, and winning time in the project plan to conduct user research for quick wins and opportunity areas.
Juxtaposing the shortcoming of the current experience with the user journey was one method we used to provoke thought in our cross-functional partners. The information that we presented on the user journey was accompanied by the images you see below, illustrated by me.
The overall presentation, and especially these illustrations, were praised for its digestible format.
While the impact of such design artifacts aren't measurable directly in revenue numbers, their impact on provoking thoughtful development processes, creating greater cross-functional support, and providing an org wide understanding of the users we are working with are far from trivial.
With greater confidence and support on our side, we set about our divergent design process.
Visibility for Dependencies
As a design team, our first questions around the onboarding task dependencies were centered upon how we could eliminate as many of them as possible. Through insightful conversations with our engineering partners, we learned that eliminating the dependencies completely would require a tech platform overhaul that would dramatically increase the scope and timeline of the project.
Our next questions were:
-
How many dependencies can we eliminate, currently?
-
Of those remaining, how best can we simplify them for the supplier?
While our engineers focused on answering the first question, my team and I began brainstorming ways to answer the second.
Designing the New Onboarding Hub
Although I was primarily tasked with working on the warehouse addition flow, I had a significant role in determining the overall onboarding flow as well. To give guidance to the user on what tasks needed to be completed, along with the dependencies between tasks, we brainstormed an "onboarding hub" space through multiple collaborative design working sessions.
Finding a Layout
Much conversation was had around the type of experience that onboarding should become. Should it be a step by step wizard that deals with dependencies through the order of the task? Should it be something more flexible that allows suppliers to work on multiple tasks at their own pace? Our design team, knowing the importance of this first step in the process, worked collectively on this task.
We looked to the user journey research (referenced above) that we had wisely invested time in. Our potential suppliers are busy people trying to expand the reach of their brands to consumers across the world. Depending on the size of the supplier, there may be one person who is responsible for completing Wayfair onboarding, or there may be a digital retail team assigned to do it. Given the volume of tasks, the limited time of their schedules, and the possibility of multiple people working on onboarding at once, we leaned into creating an Onboarding Task "Hub".
The goal with this hub was to prioritize parallel work across multiple onboarding tasks, giving the supplier the ability to work on another item if they are blocked in completing something.
Task Order
Before settling on the layout you see above, there were many questions about what default order the tasks should be presented in. Although the aim of the hub was to give onboarding supplier the flexibility to work on whatever they wanted in whatever (reasonable) order they wanted, we knew that the initial layout may highly influence their actions. As such, we held multiple conversations around the topic, producing artifacts such as the below.
Task Status
Providing suppliers with timely feedback was also a major part of this design. In the previous, heavily admin oriented, onboarding experience, suppliers did not have the clearest sense of when each step of the process would be completed. In this new onboarding hub, suppliers were given status updates for tasks that were pending completion after submission, along with "estimated time remaining" text.
Supplier Testing
Supplier testing sessions (some of which were moderated by me) indicated that we had found a good solution to the lack of feedback and inflexibility of the previous onboarding experience.
Warehouse Addition
While the Onboarding (or Service) Hub design was a combined effort of collaborative success. Each member of my design pod was also responsible for one or two task flows, as well.
Warehouse addition (or Order Fulfillment) was the flow that I requested to take on.
Warehouse addition in the previous onboarding experience required direct communication with Wayfair admins who collected information in order to set up shipping lanes between the supplier and the customer. This information, along with the accuracy of the information, was crucial for the actual fulfillment of a customer's order.
The wrong type of parcel carrier could be assigned to a supplier's warehouse if, for example, a supplier does not report that the product they are shipping is considered "large parcel" or "bladed". Certain shipping companies may not be able to service that warehouse, and an incorrect assignment would lead to both wasted money and wasted time.
Divergent Design
Example A
This exploration emphasizes the minimum actions needed to complete the Warehouse Addition flow: The addition of at least one warehouse for each region they intend to sell in. This exploration followed a thought among our design team that all flows should be geared towards only what actions are necessary to have suppliers in a position to make their first sales as soon as onboarding is completed.
Example B
This option took the above concept of capturing the minimum amount of info needed to get the supplier to value, to its extreme. Upon entering the warehouse task, the supplier would be greeting with a form page to fill out. This information would then be submitted, completing the warehouse step with just the addition (and allowal) of one warehouse.
Example C
In this example, I explored a more wizard-like flow that takes suppliers through addition process step by step. I was never particularly convinced of this approach, as it didn't feel as straightforward as the above concepts for adding one warehouse, and it also didn't feel great for adding multiple warehouses. I explored it as an option, however, in order to get my design peers' opinions on this method.
Example D
In this example, the supplier is given a "warehouse hub" of sorts. In it's empty state, there would be messaging to prompt the main CTA of adding a warehouse, which would then take the user to another screen to fill out the warehouse's info. Upon submittal, the warehouse would be represented as a card with the option to delete or edit. At that point, the warehouse task would be considered done, but the suppliers would still have the option to add additional warehouses.
Divergent Stakeholder Review
The stakeholder review that was held in order to discuss these options led to the following thoughts.:
-
While we do want onboarding tasks to be considered complete once the minimum needed information is captured, we probably shouldn't limit the suppliers' ability to add additional info.
-
The idea of having the task flow open into a information form was received positively, but there were concerns about how the supplier's submitted warehouse info could be represented in a way that the supplier could easily see.
-
The warehouse cards in Option 4 were also received well as a way for suppliers to easily go in and edit previously submitted info
Convergent Design
With the feedback from the divergent stakeholder review, I wanted to steer the design in a direction where the minimally required information (the first warehouse) was quickly captured, but also allowed suppliers to add additional warehouses thereafter. This design also needed to show the submitted information for ease of consumption and editing. After some iteration, I landed on the flow below.
Adding the First Warehouse
Immediately upon entering the warehouse addition task. The supplier is greeted by a form asking for the address information of a single warehouse. Depending on if the user if based in the EU, the form will also dynamically ask for information on whether the warehouse will ship large parcel and bladed items.
Warehouse Hub
After the supplier submits that warehouse, the info is represented in a card. The warehouse addition step is considered complete at this step, and the supplier is now within a warehouse "hub". From here they can add additional warehouses, make edits, or delete warehouses.
Adding Additional Warehouses
When the supplier adds an additional warehouse, the address form appears in a drawer. From there the supplier submits the info and returns to the hub.
After Submission
After the submission of additional warehouses, these warehouses are also reflected in the hub for visibility and editing
Outcome of The New Experience
The launch of the new onboarding experience, comprised of the onboarding hub along with various task flows for completing each onboarding item, is still gathering analytics to determine the depth of its affects. At a high level, though, I am aware of the following outcomes:
-
The overall turn around time for onboarding was reduced from 60 days to 15 days.
-
Supplier satisfaction scores with the onboarding experience have trended positively.
-
The average time of completion for the Warehouse Addition portion of onboarding is 3 minutes.
As more analytics become available to me, I will update this space.