Launching a Subscription model in Ride Sharing Apps

Motivation:

Every morning while I get ready for my office, I open Uber and Ola apps, type the destination as ‘Work’, painstakingly compare the prices of different modes of commute on these platforms, sometimes close both the apps and reopen them after a while in anticipation of price drop, memorize the most economical one, tap confirm and patiently wait while the drivers accept my request. On a not so lucky day, if the driver cancels the request, I would have to go through the whole thing again. The entire process eats up 10 minutes of my busy morning schedule.

Agreed, these platforms offer great convenience today especially when compared to pre-historic days when we did not have these services, but as a customer I have become greedier and demand even more convenience. I would not want to spend even a couple of minutes of my time doing this comparison every day.

Subscription model:

If I am offered a subscription service that I can renew every week/month, assuring me of a cab at a fixed time every morning, without having to book every day, such an option would give me far more convenience than what I enjoy today.

To start with, this subscription can be introduced for rides on shareable basis (POOL/Share). Knowing booking requests in advance helps algorithms match riders efficiently so as to reduce the total transit time in comparison to the current model where requests come in an ad hoc manner. Less transit times compared to current levels would in turn benefit the users.

Users: Office goers who use ride sharing apps on a daily basis to commute to and fro from work

Now let us explore this idea further to see if it makes business sense for these apps

Market size for this service:

How many would be willing to opt for such service?

If we assume total active riders in India to be ~12million (Uber has 5million active riders in India as of Aug 2017, so I have extrapolated), and for simplicity, say 10% come from Bengaluru, that would make it 1.2 million active riders. Of this 1.2 million, let us say, if 30% use these apps on a daily basis, that would be 3.6 lakh per day. Out of 3.6 lakh, if 50% of the users use these platforms to book rides to office, then we would have 1.8 lakh users. Out of this population, if 30% sign up for the service, it would be 54,000 customers, only in Bengaluru.

Let us say, out of these 54,000, if 50% of customers switch between two apps every day, by introducing the subscription service, these apps can lock-in more customers per day, in addition to giving revenue predictability.

How the model works:

Offer monthly commute packages from home to work (vice versa) at a fixed time.

Let us assume that it is a 10km commute to my office and in order to save up a few bucks I only use share/pool. Assuming Rs.100 for a normal ride, Rs.150 for a ride booked when surge price is on, and assuming 1/3rd of my bookings are based on surge price, I would be spending Rs.2250 for 20 days. Any offer below that price point would make a sweet deal for me. Pricing can be gotten right by taking distance, timing of commute, pick-up location, ease of access to public transport, cost of alternatives, purchasing power, previous ride prices etc., into consideration.

If more people subscribe to this service, more predictability in terms of pick-up and drop locations and people can be pooled in efficiently to minimize the total transit time.

App would send a notification with the driver details 15 minutes prior to the scheduled pick-up time.

In a weekly subscription, the user would be given 5 rides, rides that are not used would get lapsed. (or user can be given an option where certain number of rides can be carried forward if he informs at least a day prior to the scheduled time, time of pick-up cannot be changed. There should be a cap on the number of rides that can be carried forward)

UI Mock-up for subscription service
Example of a notification presented to the rider every day

Couple of problems I see that deter users from subscribing to the service –

Not having visibility into the schedule for a month long time. There are days users would not go to office, because they avail work from home option or go on leave, which usually would be not more than 5 days in a month. This can be overcome by introducing weekly/10-day plans.

Another issue would be the time users go to office might not be the same every day. If they have a personal vehicle, they would not be too bothered about going at the same time every day. This problem could be assessed in a greater detail by doing user surveys.

Benefits to the user: Economical rides with optimal transit times, saving them the effort of dealing with bookings and cancellations on a daily basis.

Benefits for the ride sharing apps: Steady flow of revenues, customer lock-in reducing the likelihood of switching to competitor apps

This feature can be scaled by partnering with employers, who can issue weekly/monthly ride passes to employees.

How do we measure success? Metrics that can be tracked for this feature would be –

· Number of riders presented with the feature

· Number of riders tapped on the feature

· Number of riders subscribed to the service

· Number of riders renewing the service


Launching a Subscription model in Ride Sharing Apps was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.