On the legacy system of INTURN, whenever users uploaded a new file of inventory, the system would automatically create a new folder with those products in them. There were a few advantages to this process.
The problem with this setup, and the issue we set out to resolve, was around maintaining a single source of truth for inventory. We found that our users were using folders as a temporary parking lot for different inventory uploads, sometimes even maintaining different versions of the same upload file. This led to confusion when there were multiple users each uploading their own inventory files (for example, a men’s apparel user and a women’s apparel user) and each had to filter to the correct upload files before beginning their work. It also caused problems when a user uploaded a new inventory file with decremented inventory while offers were currently in negotiation, which led to usrs being unable to fulfill offers they had made.
We approached our research to better understand the problem space from three different sources. From our backlog of product feedback tickets, we were able to understand the issues that users had filed with our customer success team that spoke to their needs and the limitations of how they managed inventory on the platform. In addition, we spoke with our client operations team, who are deeply intimate with the inventory file uploads and implementation of each client’s configuration on our platform, to understand each existing client’s behavior and use cases. Finally, we spoke with clients to get more firsthand feedback about the existing function and their needs.
The following are samples of client feedback:
“It's important that I lock the offer, I won't unlock them, because I want to be able to ship if buyer counters” - apparel seller users
“I want to create offers only on the [unoffered units left]” - apparel seller user
“...Reduce oversell between outlet and external WHL/OP partners. Reduce headaches on order fulfillment team by centralizing stock on one platform. This is especially relevant for European clients and prospects and would be an extremely attractive value-add in sales-pitches.”
“...can’t focus on unoffered units when [2 users are] building an offer”
With our client operations team, I worked to audit and document every single client’s current behavior for uploading and updating inventory, their use case for folders, and what their needs were. I worked to understand the basics of their configurations, their go to market cycle (when they received new inventory files, and when/if they received updates) and their behavior for working the way they do. The entire process for auditing all of our clients took about a month.
From my research, the product manager and I came up with the following goals:
The concept of disposition channels is not a new one. Disposition channels are the different outlets a retailer has to sell their goods, whether through their own branded store, department stores, outlet, factory, or off price. With the future goal in mind of expanding INTURN’s scope to include not only off price inventory management but also any additional channels further up the chain (factory, outlet, etc), I worked with the architects to come up with our own version of internal channels which could meet our user’s needs as well as scale in the future.
The concept is elegant, with a few rules that helped keep inventory and negotiation numbers consistent
Users would upload their inventory into their own individual channels (A or B, each a different set of inventory). The data from those upload channels would funnel into an aggregate view called the inventory pool, which most users would not actually see, and was created for admin purposes. Users would then create their offers from these separate upload channels. The caveat here was that upload channels would be completely siloed, with no overlapping units, and offers could be created from a single channel only. For example, if Brand X was set up with 2 channels, one for women’s apparel (A) and one for women’s accessories (B), the user would NOT be able to create an offer with both apparel and accessories in it. The reasoning behind this decision was to simplify the reconciliation process when they updated their inventory.
In addition to the concept of channels, we also needed to layer on user permissions. Some users were considered Admins, and they had visibility into all channels. Other users would be managers, who had access only to a single channel. Admins could upload and update inventory as well as create offers from any channel. Managers could only manage their own channel, and would only be able to see or create offers from that channel.
While the concept of channels is relatively straightforward, the bigger design challenge was to guide the users through the process of confidently uploading, and more importantly, updating their inventory. In order to understand what was needed, I started by creating flow diagrams.
The diagrams made two things clear immediately. First, the process for updating inventory needed to branch in multiple directions in order to accommodate specific use cases. Did users want to update the quantities of their inventory, or just the attributes? The total units or only those that were remaining available to sell? Did the file they were using to update attributes also include quantity data that needed to be ignored? All of these use cases forced a new branch in the diagram.
Second, changing the upstream concept of how users uploaded and updated their inventory had downstream effects on how they accessed their inventory, created new offers, and viewed offers in their channel(s).
Once I fully understood the branching and implications of each decision, I started with wireframes to see how this would play out for the user. The UX here is straightforward, but the guiding copy is extremely important, with nuances that help the user make the right decisions.
At each step of the way, I met with our customer success team and client operations team to ensure the designs were clear and informative. If the UX for managing inventory was too complex for our users to follow, our CS team would inevitably be the ones to receive emails to help them with the process. Once we settled on the flow, I created the high fidelity mockups and finetuned the copy.
After this feature was launched, including all of the relevant updates for accessing and creating offers, we signed a new client who had a new use case. This was a great test to see if our inventory management process was flexible and scalable enough to handle new situations.
This new client had a unique use case. They had inventory for multiple warehouses that they uploaded into the same channel, because offers could have products from different warehouses in them. However, the inventory for warehouses could be updated at different times, and the user needed to be able to replace what was on INTURN with the information from this new file without completely overwriting the products in another warehouse.
I started by diagramming this use case to better understand what we were trying to accomplish.
What I learned was that the user needed a way to do a partial replace when a certain attribute value matched. The example above illustrates the requirement of replacing only the products that had the attribute “Warehouse 1”, and to not touch products from “Warehouse 2”. Our current options didn’t quite satisfy this use case because the replace function would erase the entire channel inventory and upload only what was in the file (therefore deleting products from Warehouse 2 that we still needed), or it would update existing products and add new ones (Product 1 and 4) but not remove Product 2. After diagramming the new use case, the product manager and I went back to our architecture team to discuss whether what we needed was possible. Because of the flexible way in which both the architecture and the design were created, they could easily be scaled to include this new option. It could be feature flagged to avoid an additional fork in the path for the users who would not need it, and provide a simple way for those who did to keep their inventory synced with their warehouse levels without having to start from scratch every time a single warehouse needed to be updated.
Inventory management issues reported to CS dropped by 47%, and the client operations team has not reported any gap functionality for managing inventory for any of the new clients we have onboarded since this feature was rolled out.
The new inventory management design gives our users a single source of truth for their inventory on our platform. They no longer park inventory and cause confusion about which products are available or have the most updated quantities, and no longer oversell their products and are unable to fulfill them, which led to issues with their buyer relationships.
The next level of this feature will be to build the ability to move products between channels. This will enable our current clients who wish to use INTURN to manage more than one disposition team on the platform (such as Factory as well as Liquidation) by allowing them to pass products from disposition channel to disposition channel throughout the lifecycle of the product. It could also create sales opportunities for prospective clients who are in need of disposition management that includes the off-price market.