Workflows: Common Workflow Templates
OVERVIEW
Merchants use Loop's Workflows feature to build rules on top of their general return policies. Workflows is a highly flexible tool, but it can be tough to know where to start. In this article, we'll highlight some of the most common workflows other merchants are building, and how you can put them together for your customers.
In this article:
Holiday Return Window
While this ask comes up most frequently around the holidays, when many merchants are extending their return windows so customers have plenty of time to return gifts, this template can be used to extend the return window for specific products or sets of customers as well.
Here's what that workflow looks like:
Template
This workflow will be built using the Conditional outcomes template.
This workflow is a simple condition and action workflow. It will not require any input from the customer during the returns flow, like answering a question or submitting a picture of their return.
Condition
The condition in this workflow is Order - Date.
The goal is for this workflow to only affect orders placed in our "holiday window". In most cases, merchants will use the Was placed between setting, allowing the workflow to work on all orders placed in a certain date range. For this example, the holiday window is November 24th through December 25th.
Tip: "Between" conditions are inclusive of their starting and ending values. In the example above, this means orders placed on November 24th and December 25th will also trigger the workflow. This is consistent across all "between" conditions in Workflows.
Tip: If you want to extend the return window for specific products, you'll use Product - Tag, Product - SKU, Product - ID, or Product - Type, depending on how you want to identify that set of products. You can extend the return window for a subset of customers using Customer - Tag, or even Customer - Number of orders if you want to specify frequent customers.
Action
The action for this workflow is Return window.
When an order is placed during the holiday return window specified above triggers this workflow, the end goal is to extend the return window for that order.
In the example above, the return window has been extended to 45 days using the Days since fulfilled setting.
Some merchants prefer to give a specific return date rather than an extended return window. For example, for "All returns placed during our holiday return window are returnable until January 15th", use the Returnable until setting instead, and set it to January 15th.
Final Sale
Nearly every merchant will want to mark a product final sale or make a product exchange only at some point. Workflows provides a flexible way to do so. With this workflow, we'll explore how to use tags applied in Shopify to initiate workflows in Loop.
Here's what that workflow can look like:
Template
This workflow will be built using the Conditional outcomes template.
Condition
The condition for this workflow is usually Product - Tag, which initiates this workflow based on a Shopify tag on a product.
The recommended setting for the Product - Tag condition is to trigger it based on the Tag at time of purchase. This ensures that even if a product is no longer final sale, those purchased while it was tagged final sale will still be treated as such.
Tag at time of return will only check to see if the tag is present when the return is initiated, regardless of how it was tagged when purchased.
Tip: Some other options for identifying products to mark final sale:
- Product - ID to identify specific products without using a tag
- Product - SKU to identify specific product SKUs without using a tag
- Product - Type to identify products by their product type in Shopify
- Product - Vendor to identify products by their vendor in Shopify, useful for merchants doing dropshipping
Action
The action for this workflow is Reject item. This action is under the Keep Item / Reject Item category.
When a tagged product triggers this workflow, Loop will mark it as final sale and make it not returnable.
If you would instead prefer to allow customers to return final sale or clearance products but limit their options, many merchants use Exclude refunds in the Exclude Outcomes category to allow customers to still exchange or get store credit, but block them from refunds. Those actions can be used to exclude whichever return outcomes you deem necessary.
Important: Checking every option in Exclude Outcomes will not work the same way as Reject Item. If you want to make something not returnable, full stop, you'll need to use the Reject Item action.
Waive Fees Based on Return Reason
In this example, we'll set up a workflow to waive return fees when the customer is initiating the return for a reason that is the merchant's fault. This is a great example of using return reasons to change the customer's return experience.
Here's what this workflow can look like:
Template
This workflow will be built using the Conditional outcomes template.
Condition
The condition for this particular workflow is usually Product - Return reason, then selecting which return reasons you'd like to waive fees for. Since return reasons are customizable by each merchant, this will depend on your configuration.
You can select parent return reasons, or go into specific child return reasons.
There are plenty of other possibilities with other return reason and action combinations, this is just one example.
Action
The action for this workflow is Waive all fees. This action is in the Handling fees category.
If you do not charge fees as part of your base return policy, but want to do so conditionally, you can do so by leveraging Workflows and this category of actions.
Tip: Waiving fees is just one example of how you can change the customer's return experience based on their return reason. Other possibilities include:
- Letting customers keep opened products to save label costs. This is common for cosmetics brands that can't restock opened products.
- Letting customers keep damaged products to save label costs.
- Switching returns for reasons that require inspection to manual review or manual processing.
Reject Worn Items
Many merchants don't allow returns on products that have been worn, or have had tags or hygiene liners removed. With this workflow, we'll explore the ability to ask the customer a question during the returns process, then adjust their return flow accordingly.
Here's what this workflow can look like:
Template
This workflow will be built using the Ask a question template. This template can alternatively be used to ask customers to send along a picture of their return.
Condition
For this particular workflow, we want to ask this question for all returns. The easiest way to set a condition that triggers for every single return is to use the Product - Return reason condition, then select every return reason. This means that when a customer selects their return reason, it will trigger this workflow.
If, for example, you wanted to omit return reasons that could be due to the merchant, such as wrong product or damaged product, you can do that here as well.
Question
This is where this template differs from the Conditional outcomes template.
You'll write up how you want to ask the customer your question, and can optionally provide a message for the customer if they answer Yes. This message is generally an explanation of your policy, and why Loop is taking this action.
important: Loop will only trigger the action when the question is answered with Yes. Write your question in such a way that an affirmative answer will trigger your action. If the customer answers No, no action will be taken and the customer will continue through the rest of the returns flow as normal. Loop is not able to trigger actions off of a No response at this time.
Below is an example for this kind of workflow:
This example includes an explanation of what's happening and why. This can mitigate customer confusion, but it is optional. Leave Response if "yes" unchecked if you don't want to provide a message.
Action
The action for this workflow is Reject item. This action is under the Keep Item / Reject Item category.
Similarly to the Final Sale workflow, you could use settings in the Exclude Outcomes category to still allow returns, but limit the customer's available return outcomes, e.g. no refunds.