Driver Receivables: Part 2
source: getty images

Driver Receivables: Part 2

This is Part 2 of my article about solving the messy driver receivables problem at Ola.

Here’s the first part:?Solving messy problems: a case study

We talked about two of the four core questions in the first part.?

Now, to the third question – why were so many drivers getting offroaded daily??

The first thing we found is that our offroading logic was incorrect. We had this practice of taking a security deposit from drivers to cover for the credit we allowed. However, the offroading logic was completely ignoring this deposit! So we were collecting a deposit and ignoring its very existence!

(On a side note- we collected this deposit in small installments, to make it easy for the driver.? But the way we did it, it actually worsened the problem it was supposed to solve – we were trying to collect them by, yes, dumping the charge in the ledger, and therefore, creating a false increase in the credit balance! )

What’s more, the finance team was using the aggregate amounts when reporting to management. So, to calculate net receivables, they took the total gross receivables across all drivers, subtracted the total deposits we had, and thus reached the net receivables figure at a company level. That was clearly wrong – there were drivers who had security deposits with us, but didn’t owe us any money. Clearly, such deposits should not be subtracted from gross receivables, as that money couldn’t be adjusted against another driver’s receivable!

Anyway, this seemed like a trivial problem to solve- offroading logic should work on net receivables at each driver level, (gross receivables minus security deposit) rather than the gross receivables. Quite a few drivers would immediately stop getting offroaded! As they should, given that we had their receivables covered!

But this got us into a long discussion with the finance team. They wanted to talk about the total numbers at an overall level, and were unwilling to engage in any kind of ‘relaxation’ till we had collected security from all drivers. They were worried that the proposed change would increase the gross receivables number further. (It would, yes, but that didn’t matter - net risk to the company wouldn’t change.) But this argument didn’t fly, because someone’s target in the team was the gross receivables number. They were not willing to do anything that would increase that number, even if it was irrelevant!

Classic example of the company suffering because individual or team goals were getting prioritized over what was the right thing to do!.?

Luckily, we were able to build consensus and get the relevant team members to agree. It helped that the supply and revenue teams backed us on this. This was the first change that made a significant impact on the daily offroading numbers.?

But this wasn’t enough- there was more that needed to be uncovered.

The problem with free credit, and the fuzzy cloud of legacy decisions…?

Even driver segments that had no security deposit were getting offroaded very frequently.

We continued to dive into the data, and realized that lots of drivers were getting offroaded multiple times a week. These drivers were living on the edge of the credit limit. Every time they got offroaded, they paid just enough to come back within the limit. And so they kept getting offroaded almost daily.

We needed a solution that would get them further away from the edge. One solution we were able to think of was to create a separate ‘on-roading’ limit, which would be substantially lower than the ‘offroading limit’. This would mean that the driver would have to pay a higher amount to come back online. But once they did, they would likely stay online for a lot more days, as now there was some buffer that had been built.

This proposal received significant opposition from the supply team – they were always under a lot of pressure to improve supply on the platform, and were therefore wary about making any changes that could cause a risk to supply availability. They felt that drivers would not have the additional liquidity needed to make the higher payments, and therefore we would lose more supply hours. In the worst case, they reasoned, some drivers might just choose to switch to the competition.

There wasn’t much either side could do to convince the other – all the arguments were potentially valid, and there was no way to prove any of them using past data. We all finally agreed to roll this out as an experiment, picking certain cohorts of drivers across a few of the cities where supply was relatively less stressed.?

Once we did, the results were amazing! Drivers continued to come back online in the same time as earlier, and offroading frequency dramatically came down – the percentage of drivers getting offroaded daily went down by 40%!! And driver attrition in these cohorts saw no change at all. So basically, liquidity at these small numbers wasn’t really an issue – the drivers just needed a push to make those payments. (Earlier, there was no real reason for them to pay more than the minimum amount. They were simply making use of the free credit!)

Even with this data, the supply team wanted to move slowly – among other things, they were worried about possible driver unrest. But the direction was now clear, and everyone was aligned. We expanded the cohorts slowly over the next few months, ultimately covering the entire country.

Now to the last question- why was it taking drivers so much time to pay and come back?

One answer to this was relatively obvious – most of the driver pay-ins were done offline, through payment centers spread across the city. We did have online payment options, but the options were limited and the product experience was painful. Conversion rates on those funnels were horrible.?

Most of the steps to fix this were obvious, and while it took some effort, we got those moving:

  • Add more payment centers to make them more accessible - partner with additional providers if needed.
  • Get accurate geo-locations of these centers, and make it easier for drivers to search for and find the ones nearest to their current location, and nearest to their homes.
  • Focus on the online payment funnel, fixing issues and reducing friction. This was true for netbanking, but specially true for UPI.

We felt that the biggest needle mover for driver pay-ins would be paytm. Most drivers had paytm accounts, and the cash payments they took were often actually digital payments into their paytm wallets. So drivers would often have money in the paytm wallets; and they knew how to use paytm. Bank accounts were relatively iffy - they might not have money in their bank accounts, or they might not have set up netbanking/debit card payments.

However, there was a problem. Paytm was an absolute no-no.?

People felt there was no point even talking about it- in fact, they were afraid about even bringing it up. (Due to it being a competitive offering v/s OLA money.) Opposition at the very top of the org about paytm had always been extremely strong. The informal talk said there were other reasons for the opposition beyond just the strategic. So we were advised to not even think about bringing it up.?

Our team felt there was a nuanced view here – we had the opportunity to significantly improve driver pay-ins through paytm, while continuing to NOT use it for consumer payments. Driver pay-ins were of a much lower volume, and limited to a very small set of our users. The real strategic imperative was on the consumer side, which we were not going to touch. And for the other reasons that were mentioned – maybe they were right, but let’s just ask!

Tentatively, we brought this up, and received instant approval right from the top!

Lesson for us here-?

Never make assumptions. Keep challenging past decisions. Often, organisations develop these urban myths around how the founders/senior management will react.

(And lots of great options unfortunately get taken off the table!)

With all these improvements, online pay-ins went from ~30% of all payments to 85%, and was still rising when covid hit. We continued to make usability improvements, specially for UPI.

Reducing Net receivables per vehicle

Receivables from active vehicles were now stabilizing, compared to the earlier increasing trend. But that wasn’t enough – overall receivables were still growing, although at a much lower pace. We needed to reduce the net receivables per active vehicle to reduce the overall receivables growth. Ultimately, overall receivables would stop growing only when drivers leaving the platform left with zero credit, (in other words, net receivables per active vehicle got to zero).

By now, we had started thinking that perhaps we didn’t need to offer any ongoing credit limit to drivers at all! Any credit offered should be transient, and linked to the event causing the need for credit. So, for instance, if there were any cash outstation rides, give credit for a few days, till they were back in their home location. For most other cases, allow just a day of credit.?

But this idea was too radical, and contained too much risk. We anyway had to find a way to lower the receivables first. It felt safer to first lower the receivables progressively to a small number, and then think about getting rid of the credit limit completely.?

So we started a bunch of different experiments around lowering the credit balance. They essentially followed a two-prong strategy:?

  • Progressively reduce the credit balance of drivers, and?
  • Reduce the credit limit of drivers who were already at a lower credit balance (thus capping their potential credit balance, capping growth of receivables from ‘clean’ vehicles.)

We progressively started lowering credit limits for drivers, utilizing the new concept of the on-roading limit. Whenever a driver paid, say, 500 extra to get back online, we used that to reduce that driver’s offroading and onroading limits by, say, 250 rupees. Over a few iterations, they would come down to a much lower credit level. In addition, we picked cohorts of users where we reduced credit limits to the nearest 500 of their credit balance. As an example, for drivers who were at -600 balance, the new limit was -1000.

Again, there was opposition from supply, worrying that this would: increase offroading/drive attrition/cause driver unrest. But, by now, a lot of the other measures had shown strong improvements in supply metrics. We had built credibility, and trust. And it was relatively easier to convince folks to do staggered rollouts, keeping a watchful eye for the potential downsides.?

With all these test cohorts, net receivables came down sharply, AND? none of the supply metrics worsened. Over a period of time, the limits would keep going down. At a low enough limit, we could start talking about something that was unthinkable a few months ago – zero net receivables!? We could potentially move to a zero credit limit, creating a temporary credit limit in special situations, and enabling the drivers to cover for small daily fluctuations through a small security deposit.

The final outcome?

With all of the interventions, net receivables per active car went down 60% , and growth of AR went down 80%!?

Driver offroading went down 40%.?

The fraud and penalty system and policies got a major makeover, resulting in it actually controlling and reducing fraud (Worth an article by itself).

We had also made the overall system a lot simpler- in my view, simplicity is a goal by itself! A lot of time, people will justify complexity in solutions. I disagree.

The problem can be complex, but the best solutions are astonishingly simple!

At this stage, we still had a bunch of stuff WIP – solving for the outstation use case, making UPI payments seamless, increasing the share of digital payments by customers, progressively reducing credit limits, and experimenting with doing away with credit limits completely.

What had started as a problem that seemed to have a simple cause – low share of digital payments- actually turned out to have very different major causes! (And looked like all of them were of our own making!)

What had made this problem so particularly hard to solve?

I feel it was a combination of multiple factors: it had lots of? linkages within the system, there were lots of past decisions that no one understood the rationale for, there were so many agencies within the firm taking independent decision, each team had very aggressive targets to meet, and it was very difficult to get a holistic view of everything that was going on.

What allowed us to find our way through this maze was the focus on finding the right questions to ask.

If you liked this,

Some other articles that might interest you...

Fixing Cancellations in the Cab Market

On Product Management and Problem Solving

The Power Of Service Guarantees

Customer Experience: A few learnings

要查看或添加评论,请登录

Ankur Agrawal的更多文章

  • Core Tenet 2: Chase Perfection

    Core Tenet 2: Chase Perfection

    There are certain principles or ways of working that have served me rather well over the years. I’ve talked about some…

    3 条评论
  • Ola Guardian: A product innovation story

    Ola Guardian: A product innovation story

    This article talks about Ola Guardian – a product that was built to prevent high severity safety incidents in Ola cabs.…

    10 条评论
  • Measuring CS: Automation Layer

    Measuring CS: Automation Layer

    I’ve been talking about how to measure customer support. Have covered the two keys aspects earlier – effectiveness and…

    1 条评论
  • Measuring CS: Affordability

    Measuring CS: Affordability

    This is part 2 of my article on how to measure customer support. To recap, I had mentioned that there are two top level…

  • Measuring Customer Support

    Measuring Customer Support

    How should Customer Support be measured? Anywhere you look, there’s a whole list of acronyms and a long list of…

    3 条评论
  • LLMs in Customer Support: Part 2

    LLMs in Customer Support: Part 2

    This is part 2 of my article on using LLMs in customer support. Part 1 is here.

    3 条评论
  • LLMs and Generative AI in Customer Support

    LLMs and Generative AI in Customer Support

    Ever since GPT 3 burst onto the scene, there’s been a lot of hype around how Large Language Models (LLMs) it will take…

    15 条评论
  • Transforming Support: CSAT Story Part 2

    Transforming Support: CSAT Story Part 2

    Beyond freebird: Agent capability? This is part 2 of my article on how we transformed customer support at MMT and Ola…

  • Transforming Support: A CSAT Story Part 3

    Transforming Support: A CSAT Story Part 3

    This article concludes my 3-part story of CSAT Transformation. You can read Part 1 and Part 2 here.

    2 条评论
  • Transforming Customer Support: A CSAT story

    Transforming Customer Support: A CSAT story

    Both at MakeMyTrip and at Ola, we were able to achieve dramatic improvements in customer support, in just a few months…

    4 条评论

社区洞察

其他会员也浏览了