For a e-commerce product, our fulfilment turnaround was too slow for our users. I identified the issues of duplicated input and misaligned output on our fulfilment system, which contributed to the inefficient fulfilment process. Upon revamping the workflow on order management processes and API integration with our warehouse partner, we achieved the following results:

42→14 steps from creating products to inbound

3 days→1 day per order handling time

Products can be added or updated individually. There‘s a bulk upload template, which can be filled with multiple products info. By uploading the template to our fulfilment system, those products would be added or updated. However, due to redundant fields on the bulk upload template, the ops team opted for individual upload over bulk upload. When they absolutely have to upload with bulk template, they built their own separate converting spreadsheet.

Problem space

What does it mean by redundant fields? As our fulfilment system utilised Sailor, an open-sourced order fulfilment system, there were defaults that aren’t applicable to the current business. The ops team had no idea on how these inputs would impact the system, nor the tech team attempted to hide the unused fields. The below is the original workflow:

‍

There are 3 main issues:

1. Unused fields: fields like shipping weights, available date, product type are not used but still required to be filled in in order to successfully upload. So the ops team had to spend at least 30% more time filling up fake data into these fields before uploading.
2. Hard-to-find slugs: product categories, suppliers, product type require users to fill in with system-generated slugs. However, slugs are not available on display in the system. We had to export the slugs, and view them on the exported spreadsheet. Therefore, the ops team is actually keeping their own spreadsheet of slugs so that they don’t have to check every time before uploading. Yet when the slugs are edited, ops often forgot to update their slug spreadsheet, causing tagging errors.
3. Expanding price tier rates on individual product level:

• At least 5 price tiers have been created. Each tier has a different discount rate in percentage. Social sellers who orders more receive a deeper discount, while smaller sellers get less discount. However, when adding products with the bulk upload template, discount rates have to be expanded into actual numbers for each and every individual products.
• What’s worse is along with price, quantities and tier names are clustered in their own columns. Each values are only separated with semicolons. For example, given there are 5 tiers, user has to first input 5 tier names, separated with semicolons, in sequence in the first column, then the 5 prices in the same sequence to match with the tiers in the previous column. Imagine repeating these steps 6 times for every single product. When a new price tier is added, the workload is doubled. It’s impossible to double check for errors.

As the result, the ops team came up with a few temporary solutions below:

• Copy and paste the same values every time before uploading, yet it’s easy to miss some of them, which leads to unsuccessful upload.
• Create their own converting spreadsheet before duplicating the converted values onto the upload template.
• Curate a spreadsheet for storing slugs
• Avoid using the mass upload template at all, upload one by one instead.

Solution space

The strategy is to first remove unused fields that doesn’t fit the business now. Then, to minimise errors, defaults and drop-downs are added to the template:

A purchase order is meant for ordering stocks from suppliers, so that we can sell them to other social sellers. The original PO system was designed for event-based purpose for a single supplier. All orders within the event timespan will be included in a single PO automatically, so the PO could be directly sent to the event supplier. Until the previous PO has been fulfilled, new POs can’t be generated. In addition, we didn’t have to keep stock as suppliers deliver the stocks to us before each event. So inventory wasn’t factored into consideration. As the business model changed, it no longer fits our need.

Problem space

Since we work with multiple suppliers now, whenever we generate a new PO, all orders with multiple suppliers between the previous PO and now would be added to the new PO. Multiple suppliers’ POs would be clustered into one file. The workflow looks like below:

Hence, the team faced the following issues:

• The generated POs includes orders from multiple suppliers. Beside the first sheet with all products ordered, a sub-PO in a separate sheet would be created for each supplier. Yet their MOQ requirements are different for every supplier. So for any suppliers sub-PO that doesn’t meet the MOQ requirement, the procurement team had to store the list elsewhere, and combine with any future POs when the MOQ is met. As a result, products often get ordered multiple times, or overseen because the PO management process is manual, and stored out of system.
• Multiple suppliers mean multiple POs. After the first generated PO, the team cannot generate any new POs. So the ops team had to fake “fulfil” the PO on the system, and keep track of the PO status on a separate spreadsheet to make sure it’s actually fulfilled when the stocks arrive. It takes extra attention to keep track of which ones are actually fulfilled and which aren’t. It’s prone to error.
• Since we now keep stocks, yet stock count at warehouse wasn’t synced with our database, the team had to checks on the warehouse system, and deduct the number of stocks from the PO manually, so that we don’t overstock. Unfortunately, such manual procedures have created multiple incidents of over-ordering and under0ordering.
• The PO format is misaligned that on a single PO, every supplier has their own page. So when the procurement team needed to send out the PO to each supplier, the team had to manually split the POs one by one for each supplier.

Solution space

The PO page is revamped into 2 pages: Create PO page and the Overview page. At the create PO page, a list of orders will be available for the procurement team to pick and generate new POs. The generated POs can be viewed at the Overview page, along with the order numbers that the PO was created for.

With the current workflow, the team don’t have to manage orders and maintain POs on any spreadsheets. Pick orders to generate POs for, download and send over the PO document directly to suppliers are the only remaining steps. All of these is visible on our fulfilment system, leaving way less room for error and faster turnaround.