Every business has to deal with refund requests. As there is (at first sight) no business added value in processing these requests (to the contrary they only cost money), very few companies invest in a fluent and efficient process for dealing with them.
This in contrast to the standard check-out process, in which significant investments are done to make this process as efficient and frictionless as possible. PSPs like Stripe, Adyen, Mollie… have become multi-billion-dollar companies in optimizing those flows.
The so-called exception case of a "Refund Request" might however not be such an exception, especially in the online world, where supplies are not always guaranteed, shippings are not always that reliable and users have the right to return (in case the consumer is not satisfied of the product, has simply changed his mind or the product is broken within the period of guarantee). For example Zalando is known for its easy return policy and admits to a return percentage of 50%, meaning refunds are clearly not an exception case for them.
Ensuring that this process runs smoothly (fast, accurate and frictionless for both the merchant and the consumer) will not only save a lot of effort (and thus money), but can also give a high degree of trust to a consumer for initiating a purchase (having the confidence he will be quickly and correctly reimbursed in case of an issue). Especially in online businesses where consumer-reviews and word-of-mouth is crucial, a poorly treated refund request can have important negative repercussions on your business.
At the same time if a refund is a good experience, people will likely spend again the money on the same webshop and stay a loyal customer for the future. Therefore a fluent "Refund" process can be a business differentiator and can lead indirectly to more sales.
Making the "Refund" process smooth and fast, while at the same time avoiding fraud and other issues, is however not that straight forward. A "Refund" process consists typically of multiple steps:
Step 1: The customer initiates a refund request. The key here is to capture as much info as possible (e.g. important to identify why the customer needs a refund), in the least frictionless way. Pre-filling based on the user’s past shopping and refund journeys is essential here. The customer can have multiple reasons for asking a refund, like the goods are damaged, the delivery was delayed or erroneous (never received or stolen at delivery), the wrong product was delivered (i.e. error in order picking or shipping), the customer does not want the product anymore or is no longer interested (e.g. not happy of the quality of the product), the customer found a better deal, the customer ordered a duplicate/wrong item (e.g. wrong size)…
It is important to react in the right way to each reason, thus avoiding refunds as much as possible. E.g. for certain reasons (like "wrong product delivered") it might be interesting to propose a reshipment, while for other (like "found a better deal") the merchant can propose offering a gift voucher for the difference, if the user can provide proof of a cheaper price at another shop.Step 2: The business should assess (ideally in real-time) if the "Refund" request is valid (justified). This should be based on a (potentially AI-based) risk model (based on the customer profile and the refund request itself). Depending on certain thresholds, the system should either authorize or refuse the refund, either redirect to an exception flow, where someone will manually assess the request (and potentially contact the customer to verify certain elements)
Step 3: Depending on the type of refund request, the system should give instructions of how to send back the received goods. Obviously in this case, the system should explain that the refund will only be triggered once the returned goods are received. This should however not withhold the user of already completing step 4.
Step 4: Agree how the "Refund" should be made. This can be via the same payment method (e.g. credit card) used for buying the goods, but the customer should also be offered the option to request an immediate wire transfer (instant credit transfer). In this case the customer should be asked to provide necessary account details (e.g. IBAN and BIC), which should obviously be validated as much as possible. This validation can just be a syntax validation or a real validation of ownership using e.g. a PSD2 account verification journey. This validation of ownership reduces the risk of fraud (e.g. someone else initiating a refund on your behalf) and money laundering.
Step 5: Correctly process the returned goods (if applicable). The returned goods should be inspected (if all returned goods are present and have the expected quality) and reinventorized. Potentially certain cleaning and/or repairs might be required and depending on the quality they can be resold as new, resold at a discount, given to charity or destroyed.
Step 6: Execute the "Refund" operation (when all conditions are met)
Step 7: Inform the customer about the "Refund". Obviously this communication can be also an opportunity to propose (sell) something similar (for a similar amount) to the customer.
Note that new payment methods like BNPL can additionally increase the complexity of this process, as it’s typically the BNPL player that needs to execute the refund. This can be very confusing for the user, i.e. who should he contact for a refund, i.e. the merchant or the BNPL player?
The above process should also be very flexible, allowing to skip certain steps. In the above process, the refund is initiated by the customer, but it can also be initiated by the merchant, in which case the customer will be informed (via mail/SMS, indicating that order could not be fulfilled and with a link to the refund process) and immediately directed to step 4. This is typically the case when:
There was an issue with the payment system, e.g. when one transaction is paid with 2 different payment methods (e.g. a gift card and a credit card) and the first one is successful, but the 2nd payment method failed (e.g. due to a loss of internet connection, customer pressing the "Back" button or closing his browser, insufficient funds available…).
The seller does not have the product in stock anymore or there is a general takeback of a product, with a safety or health concern
As indicated above, refunds should be handled as efficient and secure as possible for multiple reasons:
Customer experience, i.e. the more fluent a refund process happens the happier the customer and the more likely he will return in the future. Additionally a slow refund process, might lead to additional customer communications / escalations, which require additional time of the Customer Care team to reply to
Avoid fraud cases, i.e. the refund process should identify as much as possible fraud cases (e.g. customers indicating they didn’t receive a package, while they actually did), as those obviously cost a lot of money
Avoid manual effort at merchant side, as this is time-intensive and costly. E.g. many merchants process refunds manually by entering them in the back-office of their PSP, but this can be quite cumbersome and is only part of the puzzle (i.e. accounting system also needs to be updated and the customer needs to be informed).
If a refund process does not run smoothly, customers might turn to chargebacks. A chargeback is similar to a refund (you could consider it as a forced refund), but instead of initiating it to the merchant, the customer makes the request to his card-issuing bank. As this process comes with additional costs (fines/penalties to the credit card companies) for the merchant and potentially additional monitoring by the payment scheme if the merchant faces a large number of chargebacks, merchants should avoid this as much as possible. Normally chargebacks should only be used in case of fraud, exceptional payment errors or in case of customer dissatisfaction (e.g. when a refund request is not working), but in reality this feature is abused by many customers, i.e. 86% of all chargebacks are "friendly fraud", i.e. consumers who purchase things with the goal of challenging the charges later.
Additionally when a customer initiates both a refund (to the merchant) and chargeback (to the card-issuing bank), there is a risk for double reimbursement, so additional measures to prevent this should be implemented.
But even more important than handling refunds as efficient as possible is of course avoiding refunds and chargebacks as much as possible. This can be achieved via:
Good quality products, i.e. high-quality products are less likely to be sent back
Clear product descriptions (good pictures, clear description of dimensions, material…), avoiding any misunderstanding by the customer
Tooling to support the customer in choosing the right product for his needs, e.g. wizards and questionnaires helping you to select the right product, tools to measure yourself, so that correct clothing size can be calculated (taking into account specific shapes of each clothing brand/model)
Specific measures to avoid abuse of refunding goods, e.g. adding a large "Do not remove this tag" label on clothing, which should still be present to allow a refund or ask customers to pay for certain returns, based on their customer profile (e.g. past shopping and return history)
Ensure good delivery service, so that ordered items reach the customer in good condition and on schedule. Additionally ask the delivery service for proof of delivery (e.g. signature of the customer or picture taken of the good when it’s delivered)
Turn off guest checkout, i.e. force users to register and authenticate
Only allow secure payment methods, i.e. payments requiring always a 2-factor authentication.
Fraud prevention detection mechanism, like user-behavior analysis, identifying the location of purchases from their IP address, IP address blacklisting…
A clear description of the merchant’s name appearing on every bank transaction, i.e. too often payments handled via PSPs result in very cryptic bank transaction descriptions, which result in customers not being able to match the payment with a purchase and thus launching a chargeback
…
Multiple Fintech companies are already focusing on making the refund process as smooth as possible, but given the increasing complexity (e.g. due to BNPL - see https://bankloch.blogspot.com/2021/07/buy-now-pay-later-credit-in-disguise.html - or SNBL - see https://bankloch.blogspot.com/2022/06/is-snbl-more-sustainable-than-bnpl.html-, vouchers, coupons, different payment methods, internationalization…) and the increasing usage of eCommerce, this will become even more a crucial process, making it a very interesting business segment to have on your watch list.
Comments
Post a Comment