OVERVIEW

This article covers the various use cases that can occur when merchants use Loop's Workflows feature, as well as some feature limitations to keep in mind.

Important: Due to the complexity of Workflows, Loop recommends publishing and immediately testing a few return scenarios to ensure the merchant's desired behaviors are met.

Product workflows allow merchants to do the following:

• Waive return handling fees if an item arrives damaged.

  • Condition: Return Reason

  • Action: Handling Fees

• Limit return outcomes for specific products. For example, the merchant could offer store credit or exchange as a return outcome.

  • Condition: Product Type or SKU

  • Action: Exclude Outcomes

• Route certain products directly to the merchant's chosen destination, rather than back to the default destination.

  • Condition: Product Type, Tag, SKU

  • Action: Return Outcomes > Select Return Destination

• Set manual processing events for items that need to be inspected before the merchant's team approves the return.

  • Condition: Any

  • Action: Return Outcomes > Manual Review

• Eliminate inline exchanges for single-variant SKUs.

  • Condition: SKU

  • Action: Return Outcomes > select Inline Exchanges

• Offer free return shipping when testing new product lines or categories.

  • Condition: Any

  • Action: Handling Fees > Waive All Fees

• Hide products from appearing on the order upon lookup. This workflow is commonly used for add-on line items such as shipping insurance or customization line items.

  • Condition: Product Type, Tag, SKU, ID

  • Action: Hide Products

Order workflows allow merchants to do the following:

• Control actions based on order discount.

  • Condition: Discount Code, Discount Total, or Discount %

  • Action: Exclude Outcomes

• Manage customers' outcomes based on the number of exchanges against a specific order.

  • Condition: Return Count

  • Action: Exclude Outcomes, Handling Fees, or other

• Extend the return window for holidays or peak gifting season.

  • Condition: Order Date or Order Tag

  • Action: Return Window

• Assess a handling fee based on a customer's shipping country.

  • Condition: Order Country

  • Action: Handling Fees

• Make flash sale items final sale.

  • Condition: Order Date

  • Action: Return Outcomes > Reject Items

• Order tags can be used to identify subscription orders and treat them differently.

  • Condition: Order Tag

  • Action: depends on intended behavior

• Configure a Shop Now Cart Discount (percentage-based) to match the original order's discount. This workflow is supported for Shop Now on both the In-App and On-Store experiences.
  For example: A customer purchases a $100 item at a 20% discount, resulting in a discount amount of $20. When exchanging the item through Shop Now, the 20% discount applied to their original purchase would be matched to the new cart value for items exchanged through Shop Now.

  • Condition: Order Discount Code

  • Outcome: Shop Now Discount %

  • Important:

    • This workflow is not the same as Pre-Discount Credit. Pre-Discount Credit offers the original value of discounted items to be used by way of Shop Now, whereas this workflow passes the original percentage discount to the Shop Now cart.

    • It is not recommended to use both the Pre-Discount Credit & the Shop Now Discount workflows at the same time. However, if the merchant wants to offer the Shop Now Discount for specific scenarios only, they may combine it with the "exclude pre-discount credit" action (under the "Exclude outcomes" action) to ensure customers are not offered double discounts through the Shop Now experience.
      

      

• Offer partial credit to a customer to forego the return of a damaged item.
  Note: To be used with the "Ask a question" Workflows template and the Keep Item action.
  

  

  • Condition: Product Return Reason (damaged reasons)

  • Ask a question: "Would you like to keep the item and receive X% of your purchase amount?" If yes > Action 1: Partial Return Credit (X%) and Action 2: Keep Item.

  • This workflow relies on the nature of the damage and the subjectivity of the customer. However, it eliminates returns for cases in which the damage is tolerable for the customer who has been given the option to take partial credit for the item.

  • Merchants can also control when partial return credits are offered to prevent fraudulent return behaviors:

    • Condition: Customer partial return credit count (less than X)

      

    • Note: If a customer accepts the partial return credit and then chooses an exchange item, Loop will charge the price difference between the partial credit item and the new item selected.

Customer workflows allow merchants to do the following:

• Offer first-time shoppers a tailored customer experience.

  • Condition: Number of Orders

  • Action: Handling Fees > Waive All Fees, Return Windows

• Waive fees or extend return windows for the merchant's most loyal customers or most important internal stakeholders.

  • Condition: Customer Tag

  • Action: Handling Fees > Waive All Fees or Return Windows

• Keep bad actors or serial returners from receiving Shop Now Bonus Credit.

  • Condition: Customer Tag

  • Action: Bonus Credit > $0

Return workflows allow merchants to do the following:

• Mitigate fraud by having the merchant's warehouse manually inspect high-value returns before the processing event occurs.

  • Condition: Return Value (for example: > $300)

  • Action: Return Outcomes > Manual Review

• Set handling fees based on the number of items in a return.

  • Condition: Item Count

  • Action: Handling Fees > Flat rate

• Set bonus credit to vary based on the value of returned merchandise (tier to mirror a percentage of return value).

  • Condition: Return Value

  • Action: Bonus Credit

"Ask a question" workflows allow merchants to do the following:

• Ask customers a Yes or No question to set an action.

  • Condition: Product type; Question: (for example: Have the tags been removed?); Return Outcome: Reject Item

  • Condition: Product type; Question: (for example: Has this item been washed or worn?); Return Outcome > Manual Review

    

• Use the "Ask a question" format to require a photo upload from the customer.

  • Condition: Return reason; Photo upload > Manual review

    

All customer-related "count" conditions (for instance, "Number of orders" or "Keep items count") are established before the customer initiates their return and therefore will not include the return actively being created.

For example:

• "Keep items count" will only include the number of times the customer has kept items before this return.

• "Number of orders" is completely disconnected from Loop because it analyzes the number of orders the customer has in Shopify. Therefore, this count is whatever that number is at the time the customer looks up their order in the returns portal.

• Order-related conditions (for example, "Order Return count") will be based on whatever is happening in that specific return.

Because the customer's order count is already established when the customer begins their return request, the "count" is more straightforward.

If the merchant wants to target a customer on their first order, the customer order count will be "1," meaning that the merchant must set the condition to "Customer - Number of orders" is less than "2". Less than "1" would indicate that the customer has never ordered before, and less than "0" is impossible in this case.

Things that happen during a return, such as Keep Item, will not be included.

If a merchant wants to offer Keep Item to a customer on their first return, the condition must be "Customer - Return count" is less than "1". At the time the customer is creating their first return, their return count is technically "0"; a "less than 2" condition would indicate that the customer will be able to keep their second return, as well.

Loop's Point of Sale (POS) workflow conditions help streamline merchants' in-store return processes. For returns initiated via the POS app, merchants can customize the return reasons, apply distinct return windows, and restrict return outcomes. Merchants can also add handling fees for online returns selected to be brought to the store.

• Condition = Return: "Return portal: Point of Sale"

  • This workflow applies to any returns started in-store via the POS app.

  • Available actions:

    • Exclude outcomes (limit returns to store credit only).

    • Return reason group (enable a POS-specific set of return reasons).

    • Return window (apply a different return window for in-store returns).

• Condition = Return: "Return method: Loop Point of Sale"

  • This workflow applies to any online return where 'Bring to our store' is selected as the return method.

  • Available action: Handling fees (set a fee for returns dropped off in-store). By default, this type of return has no fee associated.

The availability of an extensive list of Conditions and Actions in Loop's Workflows feature allows merchants to support a wide range of return rules and exceptions that fall outside of their typical return policy. Due to this extensive functionality of Workflows, a high level of complexity is introduced when certain Condition + Action combinations are used, or when multiple Workflows are enabled, and can result in conflicting outcomes that impact and potentially hinder or prevent the intended functionality.

The below list includes some of the most common attempted Condition + Action combinations that may not produce the desired outcome.

Important: This list is not comprehensive of all potential scenarios; Loop strongly recommends testing any workflows the merchant sets up as soon as they are published to ensure functionality.

• Making products final sale.

  • Don't: Action: Exclude Outcomes with ALL return outcomes selected.

    

  • Do: Action: Reject Item.

    

  • Why: If the Action is set to Exclude Outcomes with all return outcomes selected, the customer attempting the return request will be unable to proceed further in the returns process without any messaging as to why, creating a confusing customer experience. Instead, using Reject Item will alert the customer that their product is ineligible for return. The Exclude Outcomes Action is meant to exclude one or only a few of the return outcomes, not all.

• Extending the return window.

  • Don't: Pair the Return Window Action with any Conditions other than the Order Tag Condition.

    

  • Do: The best Condition to use to extend the return window is the Order Tag.

    

  • Why: Most of the Conditions available in the Workflows tool are pieces of data that surface after order lookup (for example: Product Tag, Product Return Reason, etc.). The Return Window in the merchant's Return Policy settings will be one of the very first rules that gets triggered upon order lookup, preventing the majority of Conditions from being eligible to trigger any Workflow Actions.

• Pausing the customer from receiving a return shipping label immediately, or not wanting the customer to ship back their parcel.

  • Don't: Action: Disable Label

    

  • Do: Action: Manual Review and/or Keep Item

    

    

  • Why: The Disable Label Action will prevent a label from generating for the customer, but instead Loop will display the merchant's Destination address and instructions for the customer to purchase their label and mail back their parcel. If this is not the desired outcome, then the Manual Review and Keep Item Actions will likely be the better option. The Manual Review Action will pause the return request and flag it for the merchant's review, which pauses the label generation. Once the merchant's team has reviewed and accepted the return request, the customer will then receive their label. The Keep Item Action will bypass label generation altogether and instruct the customer not not ship back their parcel.

Certain Workflow Actions may be affected by the Allowlist functionality. The below chart outlines which outcomes are impacted by an Allowlist:

Please contact support@loopreturns.com with any additional questions.