The goal of a successful robotaxi fleet is to offer a service that works as a "car replacement." You need to get people to give up car ownership to attain the brass ring. If they still own a car, they are motivated to use the expensive vehicle they already paid for rather than use your service. Most commonly in the early years, this will mean convincing people to switch from 2 cars in a family to 1, and use the service for all times 2 or more people need to travel.

If you have a great robotaxi service, with low costs, short wait times, and a wide service area, it should be easy to win such customers. You may even win them with special subscription plans which mirror the cost patterns of car ownership, but at a lower cost and the pleasure of not having to drive.

One thing that might scare them away would be the service becoming unavailable. Once people decide to depend on a service to commute or do other vital trips, they won't tolerate it being down with any frequency.

In particular, I want to consider these problem areas:

1. The vehicles are not rated for certain weather conditions, like a certain amount of snow, and they all stop service when this happens
2. Some major fault in the fleet management system makes it impossible to summon cars. (Airlines have shut down fairly often due to this.)
3. A safety problem in the software is discovered that is so serious that the fleet manager decides to cease operations until it's fixed.

The other modes of transportation also fail. Personal cars break down and need to be in the shop. Taxi demand can spike. Uber and Lyft can have unaffordable "surge" prices. Transit operators go on strike (especially in Europe.) Transit lines shut down due to problems on the line. Highways get temporarily closed. And weather even gets so bad that most human drivers refuse to go out in it.

When this happens we have solutions. When the personal car fails, it's fairly easy as transit, Uber and other methods are still working. It's more challenging when a fleet or mode fails.

Snow

Most robocar developers today, in a "one problem at a time" approach, are putting minimal effort into snow driving. There's lots of places to get started without snow. Even so, there are some promising solutions in development to deal with the problem of not being able to see the road, including radar that reads the gravel underneath the pavement and 3-D and edge sensors that figure out where you are from the patterns of trees, poles and buildings.

Even so, humans are reckless in snow. We'll go out driving "because we have to" in snow we probably aren't safe to drive in. Commercial fleets will be forced to be more conservative on that account. So a day will come when your robotaxi service says, "We're not operating until the snow clears" but people are out driving regular cars. In this situation, transit, Uber/Lyft and carpooling may suffice depending on how bad the snow is. Beyond a certain limit, nobody will be angry at their robotaxi service.

Still, it is a different situation in towns with rare snow compared to towns that get dozens of snowfalls a year.

Software failures

Regardless of the weather, software is not perfect, so bugs may occur that shut down the fleet -- either directly, or because they compel the fleet operator to order the shutdown. Most frightening, perhaps, is the discovery of a safety flaw of serious proportions. Right now in the testing phase, it is quite common for the discovery of a problem, or worse an accident, to cause the grounding of the entire fleet until the problem is isolated. When Uber's vehicle killed Elaine Herzberg, their fleet was shut down for what is now 3/4 of a year. Once a fleet is widely deployed, accidents will happen, perhaps several times a day, and you can't shut down the fleet every time one happens. But some accidents will be serious enough, or signal some serious unknown problem, that the decision may be taken.

It's a tough call. When such an event happens, the vehicles haven't changed. They've been driving around for a long time, having an acceptable safety record, and the arrival of an incident doesn't change that. The problem is that from a legal standpoint, the problem is now something they know about. If a car causes a problem for an unexpected reason, that's one thing. If the car goes and does it again, after the operator knew the problem was there, that's another, at least in the legal system.

This challenge is worthy of another article, because after such incidents the team will need to find the problem, create a fix and deploy it. But a fix deployed in a rush can be a risk of its own. But not deploying the fix is a risk as well.

In the old world, when a safety flaw is found in a car, the maker issues a recall. They send letters to all car owners, warning them of the problem and telling them to come into the dealer for a fix. Once they are notified, if they keep driving the car without going for the fix, then the driver is assuming a lot of that risk. Not the case in a robocar. The order not to use the car can be instantaneous.

Unless they never find a problem so serious, or they never have a fleet management shutdown, it's going to happen.

Contingency plans

A smart robotaxi fleet operator will need contingency plans to maintain customer confidence in the event of shutdowns. These plans can involve

• Paying for human driven service (Uber/Lyft/Taxi) for customers -- if such services are still operating in the robotaxi world.
• A reciprocal agreement with competitors that they will handle the load in case of a software failure.
• Having a fleet of "standby drivers" ready to be become taxi drivers for a day. They may even drive the robotaxis themselves, through use of a plug in steering wheel and pedals.
• Recruiting, in advance, a large number of people willing to be carpool drivers during the outage, going only minimally out of their way.
• Free transit tickets for all stranded customers, and possibly even deploying fleets of contracted vans and buses
• In some cases, allowing customers with drivers licences and some practice to use plug-in controls to drive the vehicles themselves -- though this may not be a good idea in bad driving conditions.

As much as possible, the backup plan must deploy with few hiccups. If a service leaves customers in the lurch too often, stranded, they will possibly abandon the service.