It was a perfect evening in Denver, CO. My wife and I had just finished attending the soft opening of a new restaurant and decided to take the light rail home. It’s about a 30 minute walk from our stop to the house but fortunately several Car2Go vehicles were waiting at the station. With a full stomach and a long day behind us, a quick drive home seemed better than lugging ourselves and bags for that walk. I arrived at the station and immediately accessed a parked Car2Go vehicle using the convenient and speedy start rental feature on the phone app. I drove home, all green lights, and then slowed in front of my house to drop off my wife. I was mentally preparing for the next phase of my Car2Go experience: playing the let’s try and End The Trip game. I’ve played it many times. Sometimes you win and many times you lose. Tonight, I would lose.
The End The Trip Anti-Pattern: User Heal Thyself
As I parked the car in a spot that normally works for ending the trip, I listened to the inductive modulation pings and pops over the car speaker system. I’ve learned the tell tale patterns by now, and after several minutes of attempting a connection the modulation goes quiet with a resounding clamp. I know what will come next even though it takes another 30 seconds or so for the operating screen to display it: The connection attempt failed. Please drive to another location and try again.
Let’s stop and absorb that message. A Car2Go system component, the network, has failed. And now I am told that it is my responsibility as a customer and user to randomly drive around to resolve a Car2Go system failure mode. I would love to meet the designer or product manager that tested or approved this message and understand how they believe that this meets the standards of excellence for modern user experience.
No matter, the challenge has been issued. So let us descend through the madness of Dante’s Inferno. I accept the Car2Go challenge and begin the haphazard process by driving a few blocks down, stop, wait for the tortoise like on-board interface to end the trip and attempt to connect. I again hear the typical failing modulation pattern, but I am unable to interrupt that to re-start the car. So I wait some more. I then start the car and randomly try another spot a few blocks back. This process continues until the 5th attempt, at which point I am not just frustrated, I am upset. My wife is waiting inside our home wondering where the heck I am. We haven’t seen each other much this week, and I was looking forward to spending a little more time together before drifting off to sleep and another full day of activities that would keep us apart. Instead I have been conscripted by Car2Go to fix its network issue. All the while, the cold and blank stare of the on-board computer screen mocks me with it’s vague but commanding instruction.
After the 5th attempt I give up, park the car, and contact customer service. To add insult to injury I am of course placed on hold. By the time I reach a customer service representative it is clear that I am not happy. The customer service representative dutifully begins to explain the vagaries of wireless technology and cell towers. Oh the irony, as I stand by the failed vehicle listening to her on my cell phone that is quite successfully connecting to a wireless network. Of course, this is not the first time I have experienced this situation with Car2Go. The customer service call ends, credits are issued, apologies are provided, and I finally make it inside my house.
But, those gestures don’t absolve Car2Go. The failure to end the trip is akin to having a fantastic meal, and all of it is spoiled by the poor service experience of a server disappearing for an extended period right as you are ready to get the check. Or maybe a better example is waiting for a connecting flight while the status screen still shows an on-time arrival, even though it is a half hour late. And no one can tell you when it will arrive or provide a reason. The interminable wait persists as you are held hostage at the airport.
A Broken System Design
What is particularly frustrating is that I know the Car2Go platform could be designed to effectively eliminate the exasperating scenario I just described. When I look back at technology platforms I have worked on, they all provided a graceful degradation in the face of network availability issues. I have had the opportunity to work on distributed voice and data systems strung across the globe and space for mission critical Air Force and NASA applications, and I was an early employee and system designer for a commercial startup deploying a nation-wide wireless communications network and telematics platform for the trucking industry. All of those platforms assumed that the network would be constrained or ultimately fail and designed for that up front through redundancy and other mechanisms. And in no design meeting did we ever suggest: “If the network is not available, we should just tell the user to navigate around the failing location until the network becomes available again. Let them figure it out, that’s not our job to worry about. And if they complain let’s just remind them that networks fail and stuff happens. We simply can’t control that. It’s really out of our hands. I’m sure that pilot conducting maneuvers or truck driver trying to find a load to pick up for the return trip home will understand.”
But I don’t see the Car2Go issue as just a narrow network problem, I look at it more comprehensively through the lens of a distributed computing problem. Essentially each Car2Go vehicle is a distributed computing node performing a number of operations and interactions that ultimately are consolidated and managed from some centralized Car2Go framework. And when considering distributed computing problems, I think it can be helpful to reflect on the Fallacies of Distributed Computing. In particular, see Fallacy #1: The network is reliable.
Fallacy #1: The network is reliable
In my observations, the issues around that Fallacy are 1) the carrier and network choice of Car2Go seems to lack coverage where more conventional 3G networks deliver coverage; 2) the Car2Go network seems to suffer from congestion failures at peak windows of workday transitions and weekend evenings, further compounding issue 1; and 3) the Car2Go platform has made an explicit design choice that a vehicle must ultimately communicate, in a blocking fashion, with a remote back-end before completing the initiation or ending of a trip (and therefore falling prey to Fallacy #1 and issues 1 and 2).
I can imagine a number of design trade off discussions occurred at various phases of the growth of Car2Go. As a venture investor and advisor to early stage startups, I recognize that trade-offs have to be made because of limited resources. I suspect the desire to complete a trip in network coverage is driven by the need to ensure the maximum utilization of the vehicle fleet and to minimize the need to deploy field service personnel to find or move the vehicle in to coverage. If you park somewhere out of network coverage then how does another user discover the vehicle other than walking by it. I also suspect there was a design discussion that further rationalized the current behaviors with some logic that goes like this: By forcing the user to park in network coverage it will inherently monitor and enforce the map of network availability, relieving Car2Go from the effort.
But by making those decisions Car2Go has implicitly modified its contract with the User by adding an additional constraint. Not only does the User have to honor the geographic operating boundaries within a given city market, the User is now responsible, in effect, for honoring the resulting geographic boundaries of Car2Go’s network availability. I’m pretty sure if we overlaid BOTH of those as layers in a map, the actual usable locations within a city market would look quite different than what is presented by Car2Go’s current mapping view.
Let’s Fix It: Car2Go Map, meet RootMetrics
If you are going to make the user responsible for both parking in the approved geographical boundaries AND within your system’s network coverage, then you owe the user a map that reflects both. I would be willing to bet you are logging GPS coordinates, coverage and network metrics, at least at the critical trip initiation and completion stages. Car2Go probably has a more granular real-time view of network availability than its carrier provider does.
Why not warehouse this and create a network availability overlay with your current vehicle map, something akin to RootMetrics coverage maps. It doesn’t even have to be a real-time update, as the average availability is probably not going to change that frequently.
Let’s Fix It: a UI that helps the User
Let’s say that the GIS solution of exposing the actual network coverage maps is too hard. If you are going to make me play a game of find the in-coverage parking areas, at least give me a fighting chance. Remember the game Hot and Cold? How about providing a more detailed measured signal strength and network congestion indicator(not just a bar graph) through the on-board display. At least if I have to drive around, I will know if I am getting closer or will have a high probability of ending the trip. Am I getting warmer?
If it’s too difficult to deploy to the on-board platform, then relay it and provide it on my phone app. And if you take that step, how about a routing algorithm that takes me turn by turn to the closest areas of network availability based on the current system conditions.
Let’s Fix It: Wireless Diversity
As described earlier with my most recent End the Trip experience, I was on the phone with a customer service representative, next to the vehicle, in coverage. Admittedly, the signal strength for most carriers is low in that area, but it is not zero. I can sometimes get a 4G connection from the location and rarely do I observe drop outs. I can only assume Car2Go is on a different data tier with some other wireless band than conventional 3 or 4G variants. This is probably challenging to adjust with legacy on board systems and possibly long term carrier agreements.
But why not allow for incremental upgrades to more conventional coverage, or multi-band solutions that fall back to a different carrier network in the event a vehicle is out of coverage on the primary network. Even access to public WiFi might offer some helpful additions. And have all the antenna diversity opportunities been exhausted? Unlike a cell phone, a vehicle offers a larger footprint for higher gain antenna systems (although a vehicle environment can also present a number of challenges in closing a wireless link.)
Let’s Fix It: Store and Forward
Why not just store all of the information of a trip and allow it to be forwarded when the vehicle is next used and in coverage? This would allow a vehicle trip to end with out direct communication to the back end platform at that moment in time. The implication of this is that a new user would be able to locate the vehicle after the current trip, initiate a trip in a questionable network area, and also end the new trip in a working network area. I am going to suggest that by allowing a direct interaction, via the phone app, you could provide a mechanism to start a vehicle without a network connection. And secondly, statistically the vehicle would end up in coverage on a subsequent trip to allow forwarding any previous stored trips.
Let’s Fix It: Phone App Relay or Replacement
From my perspective, this seems to offer the most impact, but may also open a pandora’s box on security and design complexity. Basically, let my Car2Go phone app replace or relay the on-board vehicle computer actions though the phone carrier network or wifi. Essentially this is just continuing the extension of the existing app for starting rentals, to ending rentals. Once the trip is started you know the User identity, you know the vehicle ID, and you can even track location and driving activity all via a modern smartphone.
This would of course require some direct connection between the on board computer and the User phone which could come in the form of Bluetooth or WiFi. The on-board vehicle computer may be able to offer this today through an existing but dormant chipset or through a bolt on adapter. Once a User reached a destination, the vehicle can observe network availability and signal strength to either relay end of trip communication protocols through the primary Car2Go network or the User phone network. Car2Go would effectively get a nearly free upgrade to a robust multi-carrier backup network.
But if Car2Go isn’t ready to take that full leap, than at least allow a User to manually end the trip via the phone app or web. But wait, how would that work if there is no vehicle coverage? If the User is allowed to manually “tag” and relay the GPS location of the vehicle, the Car2Go platform can at least advertise the presence of the vehicle to other Users and service personnel. I am also presuming, based on previous interactions, that Car2Go is able to ping cars “in the blind” to reset and secure the vehicle. I assume Car2Go is taking advantage of the disproportional signal strength and processing gain from the outbound higher power transmissions of a cell tower. Or conversely, the on board computer can auto lock the car on some time out just like some passenger vehicles do.
The Future Is Here
I find myself using Car2Go less and less these days and not just because of the End the Trip issues. There is another car share service in Denver that offers significantly more vehicles in its fleet. A vehicle is rarely more than five minutes away compared to the often non-existent availability of Car2Go vehicles in my neighborhood or downtown during peak windows. And the availability zones are significantly larger, especially with the now reduced Car2Go boundaries for Denver. And the wonderful thing about this alternative service: the user experience has been flawless at the end of each trip. You simply get out of the vehicle and shut the door. Your trip is done and It Just Works(TM). No more rushing to your next meeting, hunting for the one last garage or on-street parking spot, only to receive the dreaded No Connection available message. What is this alternative service you ask? Car2Go meet Uber.
Uber isn’t perfect, but compared to my Car2Go experiences there are significantly less issues. I have never had to call Uber to remedy a bill or contact customer service to complete a trip. At the same time, Car2Go has many compelling qualities: When it is available there is generally no wait to access it; vehicles can be checked out over multiple hours or days; and sometimes you might just prefer to drive alone.
Ultimately the User doesn’t care about differences in network architectures and equipment choices. They just want to get from point A to Point B with the most pleasing and frictionless user experience. Car2Go, I know you can do better. It is surprising that you would allow the described issue to persist when it affects your core business offering and one of the most foundational and critical phases of the user experience.
I do not write this letter to mock Car2Go, but to offer a serious set of thoughts to solve a problem with its service. If Car2Go is going to make me responsible for its network availability issue during the use of its service, I am going to challenge Car2Go to provide a solution to address the underlying network problems, so that no one has to go through this again.