When your shoppers decide to return or exchange a product, it means that something went wrong with their purchase. Request Reasons are the answer to that question of what went wrong.
To see the details about the changes made to Request reasons in the last release, please read the following page:
Request Reasons changes in the last release
When your shoppers decide to return or exchange a product, it means that something went wrong with their purchase. Request Reasons are the answer to the question of what went wrong. We understand that for your brand, you would like to have reasons tailored to your brand voice and be as specific as they possibly can for you.
Return Reasons let you collect information on why your products are being returned. You no longer have to settle for standard reasons like Too big, too small, changed my mind, etc. You can add as many return reasons as you want, using your brand’s voice, to collect meaningful data on your returned items.
You can even have reasons specific to different products.
You can create as many reasons as you want, and you will have full control over what they say, and even drill down to find the specific answers you're looking for by setting up sub-reasons (in form of MCQs).
How to set up a request reason?
To set up a Return Reason, navigate to Configure > Return Management > Request Reasons
Click on Add Reason
This will lead you to a new page, where you will set up your reason.
Let's take a look at each of the settings that make up a request reason.
- Reason Identifier: Reason identifier is the name you give to your request reason. This will help you in identifying the request reason throughout the portal. If you make specific reasons for specific products, this will help you identify your reason. Your identifier must be unique.
- Reason Name: The name of the request reason. The text you put in here will be visible to your shoppers.
- Sub Reason: To further get a precise answer, we provide Sub-Reasons. These can be configured by clicking the (+) sign in the sub reasons section. Define the name of the sub-reason, i.e. the question your shoppers see, and add a list of possible answers to that question.
- Services: Next, you select what services are allowed for a return reason. You can set whether you will allow return for a specific reason or allow only exchange with the same variant for a product or allow exchange with the entire catalog.
- Other Requirements: You can also add constraints to a request reason. Here, you have two options:
- Media Upload: If you allow this, the shopper will have to add a picture of the product they are sending back. You can also make that optional.
- Qualification Approval: If you enable this, then this supersedes all the rules of automation, and will require a mandatory qualification approval by an admin user, even before a return label is issued to the shopper. See this for more details
- Application to specific products: You can also set your request reasons to apply to specific products or product type. You can set either of these. To set this, either select a product type, or select the specific products by clicking on select products and then selecting from among them.
Here's a video guide for adding a request reason:
Re-ordering your reasons:
You can also change the order in which your request reasons are shown to your shoppers. To do that, navigate to the request reasons table. In the title description, you will see "here". Clicking on that will take you to a new view where you can change the orders.
Keep in mind, however, that for a reason to appear to a shopper, it must be switched on in the table. You can change the order of reasons, but as long as it is turned off, it won't show up in the shopper portal.
Here's a video guide for the process:
Evaluating Service Reason Data
- You can generate a one-time report or schedule a recurring report from our Reporting Interface & you will get a detailed breakdown at item level containing service reasons and sub reasons.
When to use Qualification Approval
- We suggest merchants to use qualification approval in cases where you would like to review the shopper's request before allowing them to return.
- We've seen merchants usually do this for instances like 'Damaged Products' where they would review the images submitted by the shopper before they allow them to proceed with their request.