Retaining Order Automation

 

BACKGROUND

In 2019, Shopify introduced the Shopify Fulfillment Network (SFN) which was a fulfillment service that allowed merchants to store their inventory in a warehouse and fulfill orders. When a merchant would receive an order, SFN would pick and pack their products and ship them to their customer, with most shipments being delivered within a couple of days. Merchants were able to manage shipment tracking, customer data, and inventory levels in the SFN app on the Shopify platform, making it a more convenient and scalable solution for getting their products into customers hands.

 

ROLE | DURATION | TEAM

Sr. Product Designer @ Shopify

Jan 2022 - Mar 2022

My team was made up of a product manager and 5 software engineers.

THE CHALLENGE

In 2021, the Shopify Fulfillment Network team transferred the network to a different platform named the “fulfillment platform”. This was mainly a technical endeavor, but had a variety of cascading effects on the user experience for merchants and warehouse employees. One of the main effects that my team was tasked with was a regression in expected behavior. After the fulfillment platform would be adopted, the following would be true:

  • The only way a merchant could request fulfillment of an order would be to manually click the ‘request fulfillment’ button in Shopify Admin

  • Merchants would have to manually re-request fulfillment in the case of a rejection from the warehouse

These were large problems for merchants because by using SFN they expected to have orders automatically be fulfilled. If orders weren’t automatically fulfilled, there was little to no value of using SFN, therefore not meeting the functional requirements for a quality service.

Although merchants expected the majority of their orders to be automatically fulfilled, there were cases in which they needed to add a ‘order processing delay’ or place a hold on fulfilling orders. Some of the reasons they would set an 'order processing delay’ (period of time between when the fulfillment order was paid and when it started processing, which is set by the merchant) were the following:

  • During non-operating hours (holidays, weekends) to review orders when they are back to operating again

  • Allow for buyer’s remorse, because once an order is in progress they can’t cancel it

  • Risky orders (risk of fraud) are not automatically set aside, so merchants increase delay to be able to review each order in case of an issue

Reasons merchants would want an order automatically be placed on hold are the following:

  • Inventory is out of stock

  • An address is incorrect

  • High risk of fraud

  • Awaiting payment

The goals of our project were to:

  1. Provide automation for initial fulfillment requests to SFN

  2. In cases a fulfillment request could be retried, provide automation to re-request it

  3. Provide the ability to automatically hold fulfillment requests based on specific conditions set by the merchant

If we met our goals, the impact of the project should have had the following effects:

  • Merchants would be able to reduce their order processing delay to a value approaching zero and take advantage of fulfillment hold automation

  • Operations should reduce instances where orders are getting to warehouses and not able to fulfill them

  • Internal teams should expect to get less support interactions related to automatic holds and re-requests


THE APPROACH

Example of a Flow workflow

Our approach for automation was to utilize an existing 1st party Shopify app that allowed for custom workflows called Flow. We would use the Flow app API for the initial fulfillment request and re-requests, essentially making the automation invisible to the merchant and not requiring them to click ‘Request fulfillment’ upon each order they received. For a fulfillment hold, merchant’s needed to be able to set specific conditions in which to hold a fulfillment request. In order to do that we leverage the existing Flow app UI in the form of customized templates.

There were a few constraints in using this approach such as no ability to deep link to a specific Flow workflow and for holds, all fulfillments that existed on the order would be held because there was no control to choose the specific condition for the fulfillment order. Although not ideal, we didn’t think that these constraints were detrimental to the goals of the project.



EXISTING SHOPIFY FULFILLMENT APP SETTINGS PAGE

 

EXPLORATIONS FOR CONFIGURING FLOW TEMPLATE

Exploration 1: Configure certain holds in SFN + Flow app (Not preferred)

PROS & CONS OF EXPLORATION 1

  • ✅ Provide a method to enable most common holds without having to go to the Flow App

  • ❌ Building additional functionality into SFN may not align with long term vision

  • ❌ Extracting existing functionality in the Flow app and ingesting it into SFN to meet our needs

  • ❌ Merchants could have the combination of a visible and an invisible enabled workflow, introducing discordance in features abilities and high potential for confusion

 

Exploration 2: Configure all holds within the Flow app (Preferred option)

PROS & CONS OF EXPLORATION 2

  • ✅ Doesn’t bloat SFN settings

  • ✅ Keep consistency with keeping Flow workflows in the Flow app

  • ✅ We don’t run the risk of having a combination of visible and invisible Flow workflows for the merchant

  • ❌ Users have to be redirected to Flow to configure all automated holds and it can be confusing if they are not familiar

  • ❌ Users have to edit and enable templates for the more common hold reasons

CONCLUSION

After discussion with design and engineering leadership both within SFN and Flow, we decided to move forward with Exploration 2. After it’s release it was clear that merchants were able to set more custom workflows easily within Flow and depend on the invisible workflow of automated generic fulfillment for everything else.