For the TNCs--companies like Uber and Lyft--a prominent issue is “surge pricing.” When demand for rides exceeds the supply of drivers, the companies raise prices in that area, sometimes a lot. That reduces demand, but also sends an alert out to drivers near that area, telling them to head on over, or to get in the car and start working. For drivers, this can be a key part of their income, since ordinary non-surge revenue isn’t too exciting. Riders mostly hate it, though a few understand it means you an always get a ride if you are willing to pay, since the alternative is seeing “no cars available.” The unpredictability is not somebody anybody likes. If you’re about to do your normal $40 commute and it tells you the price has surged to $120, you may not have much choice.

The situation changes a lot with robotaxis. Robotaxis are always “on duty” unless down for charging or service. There is no such thing as “incentivizing” a robot. The fleet management system works hard to try to position robotaxis near where demand will come. Most peaks in demand are predictable, and robots don’t mind being sent to wait far from “home.” They don’t mind anything, only the fleet manager’s spreadsheet minds things that cost the fleet money. But you can’t just solve the search by recruiting more cars to join the pool … or can you?

Waymo has done some surge pricing. This raised ire, because it wasn’t to pay drivers more to get them on duty. It appears like simple greed by the company, to raise prices and charge what the market will bear. Free market economists have the reverse view, and say that charging what the market will bear is the system working well. When there’s more demand than supply, somebody is going to be unhappy, and there’s no answer that satisfies all.

Today’s robotaxi companies set prices to limit demand because their fleets are small. If they had lower prices, demand would be so high that they would often have no cars available, or would have to offer unacceptably long wait times for a ride. Short, reliable wait times are the hallmark of a good service. You don’t need a huge fleet, you just need a fleet size that matches your customer base size. Lyft has a much smaller fleet than Uber but offers similar wait times.

Normal ride-hail demand sees its daily peaks in the morning and evening rush hours, with a modest reduction mid-day. It gets very low in the middle of the night, to 5% of the weekly peak. The high peak is actually Friday and Saturday evenings due to socialization and drinking, Sunday’s peak less less than half.

One simple answer is to provision your fleet large enough to handle the peak. Yes, that’s a lot o cars, but it’s a lot fewer cars that was needed to serve the same people when everybody just had their own car. It’s not nearly as expensive as it seems.

The magic secret is that taxis wear out strictly by the mile. They do 60,000 to 100,000 miles/year of service, and are worn out in 5 years. It’s possible that electric robotaxis can last much longer, maybe even a million miles, particularly if you design for easy replacement of upholstery and other things that wear out. But they still will mostly wear out by the mile. Private cars wear out in a deliberately set balance of time and miles, lasting 200,000 miles and 19 years, on average.

If you double your fleet size, you just double the life in years of each vehicle. You make the same number of vehicles so your capital costs only increase modestly. Your added cost is the interest on the capital, and an increased need for spaces for vehicles to wait, because they are now spending twice the amount of time waiting. These are costs, but they come with a big upside: shorter wait times. Wait time is one of the biggest competitive factors in a ride service. With double the density of cars, you will provide a much higher level of service and win loyal customers.

The extra parking space is not as expensive as you think, either. Robotaxis can park “valet” style, taking 1/3rd the space regular cars did. Plus, because they are on the road longer and serve multiple people, they need less parking. They also are happy to take parking a slightly outside of the expensive, dense areas, while humans need to park right where they are going. Parking for robotaxis will be cheap. The extra downtime also gives you more time to charge the cars, and that means cheaper slow charging instead of expensive fast charging.

As such, it may make sense to just have a large fleet, ready to handle all your customers on that Friday and Saturday evening. However, it’s also possible to be a bit smaller than that and use these additional techniques

Human driven TNCs dont’ go away. A robotaxi company can decide to provision a bit low, then pay companies like Uber, or their own contractors, to just drive the peaks. When you run out of robots, summon those. It will cost more, of course, particularly if there is a general surge. The robotaxi company can decide to just eat that cost and continue to offer predictable rates by subsidizing this with revenues from other times. Or it can pass the surge on to customers as Uber does today. (You would limit this flat rate to loyal customers, otherwise everybody would switch to you during a surge.)

Earlier, I examined the economics of Tesla selling Cybercabs to private individuals who then hire them back out to Tesla’ robotaxi network. It’s not a very workable idea, but this is one exception – hiring the cars out only during peaks. If Tesla is able to make a working robotaxi (as yet unproven) people might do this. They won’t make a ton of money but will make something. They will know when the peaks are coming, and rush out to clean and organize their car if needed, then send it out. There might even be a bid/ask network where people state what price they want for the use of their car. The lowest bidders in the right locations would win. If the ask prices are cheaper than just having a bigger fleet, this could be a win-win. The problem is, this is not enough for a car intended to be a full time hire-out car, and many people want their car during peaks--that’s why they are peaks.

Once again, the extra cost could be passed on to riders, or subsidized.

One new approach is to support ride-pooling during surges. In the past, ride-pool services like UberPool didn’t do very well. They offered only a modest discount and came with significant delays and detours. Covid killed them. But demand peaks are actually the easiest time to find riders with paths in common for pooling. And with self-driving vehicles you have the ability to offer “low delay, no detour” pooling by having instant no-wait transfers. Riders are sent solo in a 1-2 person robotaxi to the point where they meet another car, such as a larger robotaxi or van, and then dispersed when their routes diverge. Each passenger takes the optimal route they would have taken in a private car, but the core of the ride is shared. It’s a smaller version of the “Vansit” shared self-driving transit concept.

Such pooling is easiest during peaks and naturally increases the capacity of the system, almost without limit, particularly if you have vans and buses for the common arteries. It’s almost transit, but without most of the transit downsides that led the rider to want a ride-hail.

The no-detour, minimal-delay function solves many, but not all of the problems of past UberPool. But then, the proposition was “Willing to accept long delays and give up privacy to save 25%?” and people didn’t take it. During a surge, if the choice is “You can pay a 200% surge fee, wait 30 minutes for a car, or pool” a lot of people would choose to pool.

This same approach applies to localized surges, such as everybody leaving a stadium or office building at the same time. The riders can get the same offer, “Pool part-way, or wait or pay” and many would pick pooling part-way. The part-way pool is slightly different. Since everybody is starting from (or going to) the same point, the pool vehicle picks up a full load at the event, but all passengers are going the same rough direction. It drives a few miles (on the route all of them would have taken in a personal vehicle) to a lot or curb where several personal vehicles are waiting with their names on them. They transfer in 20 seconds and are in a personal vehicle non-stop to their destination. Tesla is readying for this with their “robovan” which could pick up 20 people at a stadium, and take them out to 15 waiting private Cybercabs, if they get these vehicles ready for actual unsupervised self driving.

This is a nice confluence of problems and solutions When demand is high, you need more seats, and you want to use less road capacity. When demand is high, there are more people who can pool with no detour, and more people willing to do it.

The real answer will be a combination. Fleets will be provisioned to handle some volume o traffic a bit below the peak. At the peak (and at super-peaks) they will call in all the help they can get, pre-arranged for just this time. They’ll slowly increase the price and wait time incentives to pool until they become very strong. This can handle even the super-peaks, like major events and even many disasters. In the latter case you start bringing in the transit buses and school buses (with human drivers) but use the robocars to funnel people to them from wherever they are. You also take advantage of the fact that in an evacuation, robocars can make the return trip empty, to get more people, if needed.