Tag Customers who reach a certain threshold of returned/refunded orders
complete
Steve Honey
Something I've seen talked about in a few store owner groups is the ability to flag/take action on "repeat offenders" who place and then refund/return a lot of orders (particuarly fashion/apparel stores suffer from this).
Broad idea would be:
Subscribed to refunds/create and a bulk run manual trigger option for historical back fill.
Task would maintain a "refunds count" metafield on the customer record (options for namespace/key).
Option for "threshold" number of orders when a customer should be flagged.
Option for customer tag to add when threshold reached (tag then allows segment to be created in admin and further actions to be triggered on that tag being added).
Matt Sodomsky
marked this post as
complete
https://tasks.mechanic.dev/tag-customers-who-reach-a-certain-threshold-of-refunded-orders
Matt Sodomsky
Brad (Tekhaus)
Steve Honey I have a few questions/notes on this that hopefully you'll have valuable input on.
Since one can open/close a return without initiating a refund, and vice-versa, a refund can be made that isn't linked to a refund, I'm wondering what makes the most sense for determining what specifically should count towards the threshold. Throw in the various return statuses available and it gets a bit more fragmented (e.g. if a customer initiates a return, but doesn't follow through, does that count?).
I presume that many merchants handle returns outside of Shopify and just refund when they receive the items, since there wasn't much capability in this area until recently.
I'm ruminating on which webhooks to respond to - https://shopify.dev/docs/apps/fulfillment/returns-apps#webhooks - or perhaps none at all and there is instead a daily task run that looks back at orders updated in the previous day.
Does it make sense to include a max lookback period, say 1 year, or configurable at least? I am thinking of shops with 100Ks of historical orders.
Also, customer segments can use >= on integer metafields, so I'm curious if the customer tagging might be redundant here.
Thoughts on all of the above?
Steve Honey
Brad (Tekhaus): Yep, I hear you on 'native' returns, I had looked at the available webhook topics and considered making the task configurable for looking at refund and/or return topics but it did seem difficult to pick one returns topic suitable for this use case. My other thought was these returns topics will generally be fired by a returns apps, quite a few of which have their own functionality around this. So I landed on it's probably better to have the scope here just focused on refund activity, it'd cover the use case for a large proportion of potential users + if you have a returns app you can probably leverage the in app functionality for this kind of thing.
In terms of lookback hadn't considered huge stores, perhaps a more efficient way to run things would be to do a look up covering all time on the specific customer when the task runs on refunds/create and set the count field based on that rather than incrementing? That way first time a repeat offender enters the flow you get their historical activity? Alternatively a one year look back would likely suffice - though could still be a monster run on big stores.
The other thought around tagging was that it's surfaced a little more clearly to customer service users if the metafield defintion isn't pinned, and there's still a bunch of third party use cases (email platforms etc.) where a tag is more readily accessible than a metafield. Certainly could make the tagging piece optional, IE only added if a tag is specified in the option.
Brad (Tekhaus)
Steve Honey: Thank you for the feedback, especially the clarity on returns. I agree that focusing on refunds seems to be the way to go.
I think I'll make the look back duration configurable, and optional.
And yep, on each refund webhook, it will query all of the customer's orders (or within the look back period if one is set).
Brad (Tekhaus)
Steve Honey This task has landed. In the end, I decided to forego the look back.
Also, I was able to limit the bulk op query to customers who have placed an order and only retrieve the refunded or partially refunded orders.
That should allow high volume shops to complete an initial manual run for historical tagging.
Matt Sodomsky
Brad H (Tekhaus) - any concerns about the feasibility/complexity of implementation of this task?
Brad (Tekhaus)
Matt Sodomsky: Sounds like a great task idea, I'll look into it.
Matt Sodomsky
Brad (Tekhaus): Awesome :) Let me us know what you find out :)