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).

the attributes of web 3.0...

As the US economy continues to suffer the doldrums of stagnant investment in many industries, belt tightening budgets in many of the largest cities and continuous rounds of lay offs at some of the oldest of corporations, it is little comfort to those suffering through economic problems that what is happening now, has happened before. True, the severity of the downturn might have been different but the common factors of people and businesses being forced to do more with less is the theme of the times. Like environmental shocks to an ecosystem, stresses to the economic system lead to people hunkering down to last the storm, but it is instructive to realize that during the storm, all that idle time in the shelter affords people the ability to solve previous or existing problems. Likewise, economic downturns enable enterprising individuals and corporations the ability to make bold decisions with regard to marketing , sales or product focus that can lead to incredible gains as the economic

How many cofactors for inducing expression of every cell type?

Another revolution in iPSC technology announced: "Also known as iPS cells, these cells can become virtually any cell type in the human body -- just like embryonic stem cells. Then last year, Gladstone Senior Investigator Sheng Ding, PhD, announced that he had used a combination of small molecules and genetic factors to transform skin cells directly into neural stem cells. Today, Dr. Huang takes a new tack by using one genetic factor -- Sox2 -- to directly reprogram one cell type into another without reverting to the pluripotent state." -- So the method invented by Yamanaka is now refined to rely only 1 cofactor and b) directly generate the target cell type from the source cell type (skin to neuron) without the stem like intermediate stage. It also mentions that oncogenic triggering was eliminated in their testing. Now comparative methods can be used to discover other types...the question is..is Sox2 critical for all types? It may be that skin to neuron relies on Sox2

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform cert

sent2null space

Search This Blog