Grab ride programming issue – a “nearer” driver

I have always been interested in the programming logic underlying Grab’s ride and delivery services but recently one new feature really bugs me.

If you are allocated a driver X minutes away, the algo starts to search for an another “nearer” driver. The motivation behind this is good, since it cuts waiting time, thus lowering risk of passenger cancellation and saves driver A’s petrol.

Presumably this feature comes in when:

(i) The initial waiting time X exceeds a certain threshold (probably obtained from their cancellation database)

(ii) Driver A is currently dropping off another passenger (not sure about this, but the presence of (ii) obviously adds to the waiting time).

On paper, this sounds good, but let me share with you a recent incident:

I was allocated a driver, 8 minutes away and current fetching a passenger to the condo beside my pickup point (a good thing of course since transition time will be minimal) and the search for nearer driver was triggered. I waited for 6 minutes and now driver A is already dropping off his current passenger when suddenly the algo allocates me another “nearer” driver B, 7 FULL MINUTES AWAY. Worse still, driver B is dropping off another passenger at a location where there’s higher transition cost to me. So in total I waited more than 10 minutes for a ride when it could have been less.

I don’t think Grab’s programmers are that dumb but this is a case of the product/service that feels great but has not been made with the end-user as the motivation point. Similar instances can be read here (Tampines red HDB) and here (bus-stop pillars block commuters). The creators have done what they feel is great but have not put themselves in the shoes of the actual users at all. I suppose in Grab’s case the primary motivation was to reduce passengers’ cancellation.

Maybe this feature works well most of the time, but oh well not the main point here. Grab can easily improve the situation by:

a) Allowing passengers to disable this search for a “nearer” driver feature.

b) Make the app disable the feature when driver A is less than Y minutes away.

c) Change the definition of “nearer”- driver B’s arrival time should be compared against driver

A’s dynamic arrival time, not the initial arrival time. Of course, I recognise there may be hardware issues around this, but separate problem.

I hope companies and staff can start producing and servicing with end-users in mind, it’s not always about KPIs, contract obligations and job descriptions only.