Regular customer

After an initial week of struggle and occasional no-show, we have comfortably settled down with Doodhwala for our daily milk supply. Given our Bengaluru-outskirts disadvantage, there are not too many options for daily delivery of milk, and finding a consistent and predictable source is helpful.

The way Doodhwala works, we need to fill money in its online wallet and place orders at least the previous day, by night. So we usually fill the wallet with Rs.500 and remember to place our order (since our daily need differs and is not necessarily always the same).

The earlier vendor was an offline enterprise, not an online startup. It was a grocery shop near home, and the system was similar – instead of an online wallet, we paid upfront to buy coupons. The requisite number of coupons were placed in a bag on our door so that the person delivering placed that many numbers of milk packs. A standard procedure that I’m sure you’d all be familiar with.

The interesting variation is when things go off the predictable rhythm. For instance, when we have exhausted the coupons and there’s a delay from the shop’s side to send us a fresh set of coupons (and collect that money). So how do we order milk on those days? We simply write down the number of packs we need on a piece of paper and leave it in the bag! And pay for those packs while buying the fresh set of coupons. As simple as that.

Of course, this is an outlier that doesn’t happen often, but it is one of the possible scenarios in the overall user experience. One that leads to no service being rendered for a day, if not planned for.

So, what’s this scenario’s equivalent in the Doodhwala model? Suppose we forget to top-up the wallet, despite a couple of system-triggered reminders that the next day the milk supply won’t happen if we don’t top-up the wallet by, say 9 pm. Assume that the wallet was not topped up by 9 pm, for whatever reason. What then? Just let the customer deal with the situation themselves as all options from your (the start-up’s) side have been tried? That’s one way to think, since your system has already sent the reminders multiple times. If the customer had still not topped up the wallet, one assumption you could make is that they want to end the relationship.

That seems like a reasonable assumption since wallet topping is an implicit, monetary sign of an ongoing relationship.

Say there is an outlier even here. The customer was simply not in a position to top up the wallet. Despite your automated reminders. And still wants milk the next day, so they top-up the wallet at 10 pm. And try placing an order for a certain number of milk packs the next day.

The system would obviously reject the next day’s order despite the topped up wallet. Because the system has been coded to understand that a minimum amount in the wallet should be available before a cut-off time on the previous day, to process the next day’s order. This is perfectly justifiable and is simply the way a process has been codified.

But I was wondering if there was a way a system could also think of the outlier like this, the way a neighborhood store handles it. In both cases, the deal involves credit – the store, as well as the startup, needs to trust the customer in question to offer milk on credit and collect that payment later (eventually).

The store owner has an advantage here. He is usually right next door/close enough and can offer the milk packets based on hand-written chits too and collect that money later in the day/next day. It’s a simple task for the store. He doesn’t need to worry about credit-worthiness of the customer and he doesn’t have any other details about the customer like PAN/Aadhaar etc. The only thing he knows for sure is that this is a regular customer with a one-off anomalous situation. That regular-customer tag should be enough for him to trust this customer and choose his next course of action to avoid service breakdown. And that act goes a long way in customers trusting this vendor, that things can be ‘managed’ no matter what.

Seen another way, this is the human touch, where variations from the norm (process) are managed with intuition and human ingenuity.

How can a codified process account for this particular anomaly, I wonder. Can Doodhwala look at the past orders (frequency of orders in the last 15-30 days, and/or value of orders, and/or frequency and timing of wallet top-ups for the past 5-10 occasions) and code a scenario for variations in the activity, like this one? If the system ‘understands’ that the customer has been consistent enough, that could be one signal for his/her creditworthiness, beyond visible, material signs like the bank balance. Bank balance is mere documentary evidence, but the recent track record is perhaps evidence of intent (of creditworthiness).

Just imagine the upside of thinking through such a scenario. You add the human element to your process – codified! The customer is delighted that you even thought-through a scenario like this, enough to plan it ahead and avoid service disruption even for a day. This is perhaps a word-of-mouth trigger, particularly if you plan the customer communication around it smartly. An in-app/text message the next morning, while the service remains unhindered, “We noticed that you topped-up the wallet beyond the cut-off time last night and we were unable to confirm today’s delivery. But, going by your track record, we thought we will do everything possible to not disrupt your delivery. Thank you for your trust in our services”.

Of course, the on-ground supply-chain mechanism needs to be tweaked to manage these variations, but that perhaps starts with a consideration towards such scenarios. The offline vendor doesn’t need to consider such scenarios at all since it’s a matter of face-to-face communication to solve such contingencies. For a start-up, these need to be thought-through from a process point of view so that the human element is baked into the product/service itself.

This thinking is easily applicable for many other situations too, and not just Doodhwala. For instance, your credit card. Imagine you paying your credit card bill on time for 22 months, every single month. The 16th month, due to some reason (despite the many, many reminders you may be bombarded with), you forgot and try paying it a day late. There’s obviously a price to pay for the delay.

But just imagine the equivalent of that credit card bill collector being a human being at your home (not the vile, violent money collectors we’re accustomed to hearing about). You would always try the, “Oh c’mon! Look at my track record. 15 months – no delay at all. Can’t you waive off the late fee this one time?”. Imagine if this was codified in your process. Check track record and set a criteria for it (say at least 18 months of on-time payment, and a certain threshold of amount spent/paid) – if those criteria are fulfilled, then you allow 3 late-fee waivers to the customer. And mention it to the customer and let that pleasant surprise be worded well, like how a considerate human would do – “We have checked your track record on card payment and it has been impressively on-time, so far. Since this is your first delay, we’re waiving off the late fee!”.

The same logic can be used for telecom services too. I have seen so many people using the, ‘Can’t they see I’m a regular customer for X years? How can they not account for that at all?’. This obviously stems from comparing the ‘system’ with human interaction in the same place.

Yes, you can make an argument about some people understanding this variation and gaming the system. But that is a concern in the offline system as well – people can say that they didn’t get the delivered number of milk packs and it’d end up in a you-say, he-say argument where nobody gains anything. For banks and telcos, waiving off fees like this would be a monetary loss, but ones like these that are carefully planned could give them a lot more returns in terms of customer loyalty, and make up for the monetary loss.



Article written by

Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'dsq_comments_template' not found or invalid function name in /home/itwofs/ on line 286

Please comment with your real name using good manners.

Leave a Reply