+972 52-548-6969
Who can give a refund?
Consider an eCommerce system where customers can buy stuff. Part of handling commerce is handling faults. Those range from “I bought the wrong thing” to “my kid just bought a Ferrari”. Any such system will need some mechanism to handle fixing those faults.
The simplest option we have is the notion of refunds. “You bought by mistake, we can undo that”.
In many systems, the question is then “how do we manage the process of refunds”? You can do something like this:
So a customer requests a refund, it is processed by the Help Desk and is sent for approval by Finance, who is then consulting Fraud and then get sign off by the vice –CFO.
There are about 12 refunds a quarter, however. Just the task of writing down the rules for processing refunds costs more than that.
Instead, a refund policy can state that anyone can request a refund within a certain time frame. At which point, the act of processing a refund becomes:
Is there a potential for abuse? Probably, but it is going to be caught naturally as we see the number of refunds spike over historical levels. We don’t need to do anything.
In fact, the whole idea relies on two important assumptions:
- There is a human in the loop
- They are qualified to make decisions and relied upon to try to do the right thing
Trying to create a process to handle this is a bad idea if the number of refunds is negligible. It costs too much, and making refunds easy is actually a goal (since that increases trust in the company as a whole).
Comments
https://docplayer.org/docs-images/95/123855730/images/38-3.jpg
Hegi,
The point wasn't to show an actual process, just to demonstrate the complexity
I like Oren but (IMHO) the quality of recent posts is pretty bad. My remarks: 1. First image is completely meaningless and confusing. Stating that it is there to 'just to demonstrate the complexity' is a weak argument.
2. '...writing down the rules for processing refunds costs more than that' -> I mean you just wrote most of it down, I've never heard an argument that writing down the details how the process works is more expensive then the benefits of the process.
3. The second image (just a box with text 'process') is also meaningless. I could write a box with 'application' inside
Honestly I would like Oren for an answer to a simple question: Is somebody else writing these blog posts (a student in your company) or are you messing with an AI generator (this particular posts seems to be the same quality as GPT-3 generated texts)?
Dalibor,
About "writing the rules" - stating them outright in a short paragraph or live discussion is simple.Sitting down and writing this down as an automated workflow process is far harder. Do we need approval for refunds? What if they are after a certain amount of time? What if they are bigger than a value?Who gets to approve such a refund? Is it the manager? Or the assigned contact for this person? Does it matter which contract we have with them? Etc... The second image is literally a button saying "Refund", as in, do the actual processing of the refund (send a command to the CC processor to refund it).The idea is that we don't codify the process. Instead, we assume that we are dealing with reasonable people who will be able to use their judgement.
I totally agree with this post. But the diagram and especially the Refund box confused me (didn't look like a button)
Maybe it's time to lower people's expectations lol.
I don't think this blog is to entertain or educate as much as to get stuff off Oren's chest. Same as RavenDB.
Sadly I have met way too many people who don't WANT "a human in the loop" or want to minimize that as much as possible...
@Wayne M: I met those people too. They have to learn it the hard way.
Comment preview