Can a piece of code trust you?

We have subscribed to BB Daily’s milk service. On average, we get a damaged pack of milk once or twice a month. When that happens, my wife informs BB Daily about it on the app and that amount is refunded almost immediately in the wallet (if they cannot deliver another packet soon, which may cost them more than a packet of milk incidentally). No questions asked.

I like the convenience of it. And also the fact that the system trusts us to tell the truth. If my milk delivery service was the nearby grocery shop, I may need to call them up, get someone on the line, explain to them about the damaged pack, depend on that individual’s amount of trust at a stranger’s word and get the same refund… or see it being denied for some reason.

Uber does the same too, in terms of reversing the amount charged more than what should have been, for a trip, when you point it out in their app.

This codified ‘trust’, of the system designed to trust strangers who seek refunds or make claims, seems like a ‘cost of doing business’. It plans for such eventualities and designs them into the system, probably allocating a certain threshold/percentage of their business to this eventuality.

So, it’s not as if the vendor, or the app or the system trusting us in the literal sense of that word, but more like a simple flow chart added in the program to deal with this situation. My wife updates BB Daily via the app’s chat facility where a human, with a specific name is assigned to the conversation. The point is, they don’t know us (me or my wife) at all – we are just users. So they have no specific reason or context to ‘trust’ our word. They have been tasked with the approval to ‘trust’ users on face value, with conditions (how often is this being raised, frequency etc.)

We users may see it as the system ‘trusting’ us, but for the business, this is just a simple process with no sentiment or emotion attached.

I was discussing this recently with someone and they felt that only really well-funded companies can afford this cost-of-doing-business by coding ‘trust’ into the system. Even so, removing the funding aspect, it makes business sense to build this trust into the code because of the potential fall-out.

What may be the fall-out?

The need for customer care executives to deal with complaints from honest customers, discuss that with them and manually decide whether to trust them enough to refund the money.

That plays directly into the user experience. To call a human and explain that a pack of milk has been damaged is a waste of time and effort. No one’s going to become rich by collecting such refunds. It’s too small an amount to cheat a company.

In any case, if there was a way to find consistency in this behavior (say, a refund claim every week), then at least that could give rise to doubt. But once or twice a month seems like a normal occurrence given that we are dealing with plastic packets that move between a lot of hands.

So, it may be far less about the funding and more about the intent of how to make the user experience better.

Amazon’s no-questions-asked refund policy is a winner precisely because of this. Of course, it can be gamed and some people have spectacularly gamed it too. But those exceptions cannot be used to distrust all customers. The starting point is to trust all customers, by ensuring that there are thresholds to check patterns and discern misuse.

Cover pic from .

Comments

comments