Skip to main content

Uber: How you can fix the broken "surge pricing" model you've implemented.


It's pretty clear at this point that Uber's surge pricing model has been met with mixed reactions and in many cases outright derision by the customer base. The pricing model instituted in some large cities at the end of 2015 allows customers to pay more for the luxury of having an Uber driver arrive in a timely fashion when demand is high.

At first this sounds like a very  good idea, Uber simply keys up the price of the fair percentage doled out to the driver until drivers swarm an area where demand is high, this gets the drivers a larger payout per fair but also ensures that the customers in high demand areas also get picked up faster...so what's the problem?

The problem is that surge pricing can't be accurately given a price estimate like non surge pricing calculations are given and often people being picked up in high demand areas are simply focused on one factor, getting picked up ....often under inebriated circumstances, when they sober up after the revelry is done they then notice a larger than usual Uber transaction fee that pisses them off.

The way Uber can fix the problem is to simply allow customers to set a priority on which factor is more important to them and then have the driver selection algorithm use that customer cue to modulate the driver selection so that their desires are not exceeded in real time.

For example, Uber can have the app. specify User convenience metrics in the settings, a first one could be a maximum time to wait (mttw) in all situations...this would allow high demand area calculations to allow users who are willing to wait, to do so and be connected with a more distal car for a cheaper potential final fair cost rather than be connected to a proximal car that is participating in the surge pricing enabled in a given area but pay the unknown higher price.



Another metric that the User should be given control of is simply a maximum price (mp) setting....if the surge fairs exceed that price then the algorithm should bias for drivers outside of the surge area with the trade off of the longer wait time...specifying to the User that their settings are biasing the selection of more speedy options for less costly ones. When all cars exceed the Users set maximum price the app. would simply indicate that no such drivers exist and return to them the lowest fair (which likely is a very distal one and thus likely to take a longer time to arrive).

By engaging this limited form of social oversight as a tool to inform the users of the available landscape of drivers and prices in a seamless way Uber can mitigate against any surprise pricing while also improving the trip experience by allowing communication with the customer as the trip is being facilitated such that a demonstration of customer care (in allowing them to a degree to select for wait time over price) is first and foremost.

This would eliminate the surprise that people have voiced experiencing after getting dropped home by Uber drivers called in an area under surge pricing and then having their card charged an unknown surge price for the trip. I am actually a bit surprised that Uber didn't implement this type of feedback control for Users of the app. (in general) as if it were present it would have fixed the issues of "surge pricing" automatically...since Users would have been given these types of controls as a default aspect of the ride service.

That said, better late than never....it should relatively easy for their engineers to implement the modifications to the application and the driver selection algorithm to accommodate this User bound metric sub feature...mainly because it works as a filter against the Users set mttw and mp values primarily (only when driver count falls to low or zero numbers should the algorithm need to be recalculated to consider drivers outside of the surge area that under the current system are not engaged at all).

Comments

Popular posts from this blog

On the idea of "world wide mush" resulting from "open" development models

A recent article posted in the Wall Street Journal posits that the collectivization of various types of goods or services created by the internet is long term a damaging trend for human societies.

http://online.wsj.com/article/SB10001424052748703481004574646402192953052.html

I think that the author misses truths that have been in place that show that collectivization is not a process that started with the internet but has been with us since we started inventing things.

It seems that Mr. Lanier is not properly defining the contexts under which different problems can benefit or suffer from collectivization. He speaks in general terms of the loss of the potential for creators to extract profit from their work but misses that this is and was true of human civilization since we first picked up a rock to use as a crude hammer. New things make old things obsolete and people MUST adapt to what is displaced (be it a former human performance of that task or use of an older product) so as to main…

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

Waking Out: A proposal to emerging ethical super intelligence safely.

The zeitgeist of Science fiction is filled with stories that paint a dystopian tale of how human desires to build artificial intelligence can go wrong. From the programmed pathology of HAL in 2001 a space odyssey, to the immediately malevolent emergence of Skynet in The Terminator and later to the humans as energy stores for the advanced AI of the Matrix and today , to the rampage of "hosts" in the new HBO series Westworld.

These stories all have a common theme of probing what happens when our autonomous systems get a mind of their own to some degree and no longer obey their creators but how can we avoid these types of scenarios but still emerge generalized intelligence that will leverage their super intelligence with empathy and consideration the same that we expect from one another? This question is being answered in a way that is mostly hopeful that current methods used in machine learning and specifically deep learning will not emerge skynet or HAL.

I think this is the …