Updated 01/23/07


Pilot Tests of Dynamic Ridesharing

Overview

Ride Now is a computer- and telephone-based system for “dynamic ridesharing,” which allows commuters to make one-time ride matches close to their departure time.  The Ride Now system is different than most in that it assigns people to car pools (that is, makes matches to form car pools), rather than having people choose their match partners (say, from a list).

I developed the Ride Now software systems, and I conducted or was closely involved in three pilot tests of the Ride Now system.

These pilot tests were not successful.  The requirements for success appear to include: (1) an institutional sponsor committed to the project; (2) sufficient incentives (for example, scarce parking spaces provided to project participants); and (3) sufficient marketing (including start-up incentives to create “critical mass”).  This world does not seem to offer a reasonable chance for these factors to coincide.

These pages are my attempt to document my experiences with this project.

Contents

Overview

Summary

I.  Introduction

A. Why think that dynamic ridesharing will work?

B. The Vision Thing

II.  Reverse Casual Car Pools

III.  Dynamic Ridesharing

IV.  System Design

A.   How the system works from a user’s perspective

B.   System design decisions

V.  FHWA Proposal

VI.  Interstate-80 Corridor

VII.  Dublin-Pleasanton BART

A.   First, let’s add some obstacles

B.   Marketing

C.   Initial operations

D.   Re-launch

VIII.  Marketing Efforts – Summer 2005

IX.  West Oakland BART

A.   Computer and phone system revisions

B.   Marketing efforts

Appendix A: Review of Previous Systems and Designs

A.   Sacramento

B.   Los Angeles

C.   Bellevue

D.   Seattle

E.   Sydney

Appendix B. Other Dynamic Ridesharing Systems [coming]

A. “TECAPSY,” - European Union

B. “M21” - Stuttgart, Germany

C. “Social Traffic” - Amsterdam, Netherlands

D. “NuRide”

Appendix C. Annotated Links

Summary

The body of this write-up doubtless contains more detail than any likely reader will find interesting or useful.  Here’s a summary.

Dynamic Ridesharing.  There are obviously plenty of empty seats going plenty of places.  Can’t modern communications exploit this opportunity?  “Casual car pools” – in which riders and drivers queue at established locations to take advantage of car pool lane timesavings – demonstrate that under suitable conditions people will participate in an analogous scheme.  I created web- and telephone-based systems that enable people to make “ride match requests” close in time to when they want to travel, finds the best matches between riders and drivers that meet certain criteria (such as no detour greater than 10 minutes), and provides automatic notification of the matches to riders and drivers.  I was successful in working with a transportation agency in the San Francisco Bay Area to get a Federal grant to conduct pilot tests of dynamic ridesharing.

Interstate-80 project.  There were many delays in implementing such a pilot test.  I decided to implement a project on my own in the Interstate-80 corridor where there was already significant casual car pool activity.  This was not successful.  It turned out to be very difficult to get to the necessary critical mass.  My primary market – existing casual car pool users – turned out to be fairly suspicious of a new, competitive, and potentially priced service.  Most likely, incentives to use the new service were not sufficient, and there was no way to build volume gradually to sufficient levels.  This is because there is no reward available to someone who tries the service and is not matched.  Only when there are sufficient numbers of users will there be enough matches so that the likelihood of reward – time savings in the car pool lane – will make it worth continuing to use the service.

BART Dublin-Pleasanton project.  The local transportation agency was in charge of the pilot test at this BART station.  A number of things did not go well.  The incentive for users to use dynamic ridesharing at the station – parking spaces reserved for users – was flawed from two directions: at first, parking spaces in the regular lot were not scarce; when parking there became scarce, then there were not enough parking spaces available for program users (only 10 spaces with – more critically – no enforcement, so the spaces were generally unavailable to legitimate users).  While supplementary incentives were available – in the form of BART tickets given to users – I did not feel these were effectively used.  Overcoming problems like this depends on the commitment and flexibility of an agency such as BART – such commitment and flexibility was definitely in short supply in this case.  The program never reached a point where participation was at a level to encourage further growth in participation.  The pilot test ended at the conclusion of its planned six-month duration.

Marketing efforts.  While awaiting the much-delayed implementation of the Dublin-Pleasanton pilot test, I attempted to seek other entities that could potentially be interested in trying a dynamic ridesharing program.  Prospects included universities, transit systems, and large employers.  My pitch was that we (an independent, non-profit corporation, which I hoped that prospects would not realize consisted so far of a single person) would operate the dynamic ridesharing system at their site for six months at no cost to the participating institution.  I eventually contacted and followed up with 34 different entities during a three-month period.  It was very difficult to translate initial interest into anything concrete.  “We don’t have parking spaces available.”  “We’ve got more than enough parking spaces.”  “Where is this working already?”  “We don’t have money to pay for it after six months.”  The closest I got was with a major Silicon Valley company, whose transportation manager said, “yes, let’s do it.”  It turned out that their security department did not want to monitor the car pool parking spaces; nor did they want someone else to do so, either.  The transportation manager tried to “escalate the issue,” but it ended there.

West Oakland BART project.  While the Dublin-Pleasanton pilot project was still in progress, I decided to try one more time at a location where I thought there would be a sufficient incentive.  At West Oakland , parking spaces in the station lot cost $5 per day.  Spaces in adjacent, privately-operated lots cost either $5 or $6 per day.  The natural outcome of a carpooling program would be parking for half price.  While this – $2.50 per day – is not a lot to work with, I thought that an initial incentive of free parking for one month – a $100 value – would certainly be enough to elicit interest.  I could then gauge whether and to what extent to modify that incentive.  My experience this time was that there didn’t appear to be any monetary incentive that could move people into the program. 

My minimum goal at West Oakland was to have 100 registered users before starting operations (out of 3000-plus people entering that station daily, the vast majority of them drivers).  I hired a student to assist.  We handed out approximately 700 flyers with an offer of a $10 BART ticket for registration on-line.  Two people signed up.  We increased the offer to $30 and handed out another 300 or so flyers.  Two more people registered.  I guessed that people just didn’t understand the program.  We then conducted a “survey,” which was really just an excuse to engage commuters, explain the program, and ask a key question: “what dollar amount per day would get you to participate in the start-up of this program?”  This showed that people indeed previously didn’t understand the program.  With the explanation, about half of those surveyed said they’d be willing to participate, and named a “price” most commonly around $5 per day (which is the incentive I had planned).  People received a $10 BART ticket if they took the survey and responded to a follow-up email that confirmed their email address.  Approximately 60 people did so who had also said they were willing to participate in the start-up of the program.  These people were offered a $20 BART ticket to take the next step: register on the web site.  Eight of them did so.  After a month of effort we had 12 registered users.  I gave up.

I believe a key missing ingredient in the West Oakland case was the imprimatur of an established organization.  “Who is Ride Now?” was a common question.  That the marketing effort was limited to one avenue – a couple of people handing out flyers – probably emphasized the less-than-solid appearance of the enterprise.  I realized within the first few days that the marketing effort was impossibly more difficult than I had anticipated.  I approached/begged BART to run messages promoting the dynamic ridesharing program on the train-announcement signs, as they had done at Dublin-Pleasanton, but they were unwilling.

Conclusion.  I still retain the hope that dynamic ridesharing will work, given the right combination of circumstances.  But I have very low expectation that the necessary ingredients can actually come together. 

I.  Introduction

I have two purposes here.  First, I’d like to dissuade would-be developers of dynamic ridesharing services – or at least make sure they are forewarned to the extent of my experience.  Second, I still harbor hope that someone will figure out how to make this work; perhaps my experience contains some useful lessons.

A. Why think that dynamic ridesharing will work?

Dynamic ridesharing is not a difficult concept to come up with.  Traditional carpooling has long been in decline (although some regions saw a small increase with recent increases in gas prices) – people have more varied schedules and more errands to run before and after work, making it difficult to keep to the regular schedule traditional carpooling requires.  On the other hand, new forms of communication – the Internet, cell phones, text messaging – have become ubiquitous, and so-called “social networking” – for example, myspace.com, meetup.com, and dating sites – is a growing trend.  So why not use these new tools to allow people to carpool “on the fly”?  The stream of empty seats going from place to place is obviously huge.  Surely it is possible to use new technologies to match these seats with people to fill them.  In addition, some form of authentication and reputation management – concepts already in widespread use in Internet commerce, such as on eBay – would allow people to securely accept rides from and give rides to people they have not previously met.

In addition, an existing phenomenon appears akin to dynamic ridesharing, and seems to provide an “existence proof” of the concept.  This phenomenon is called “casual carpooling” in the San Francisco Area, and “slugging” in the Washington, D.C. area, though the phenomenon is the same in both areas:  in various locations people and vehicles queue in order to form car pools that take advantage of high-occupancy vehicle lanes that offer significant time savings, and – in the San Francisco case – toll savings.1  In both cases the systems are completely informal; there is no central or government oversight.

The incentives – time and money savings – are a key feature of the casual carpooling phenomenon.  People do not get in cars with people they don’t know for nothing; they do it when time and money savings make it worthwhile.  This observation, coupled with further evidence from the varied success and failure of afternoon “reverse” casual car pools (see the next section), as well as the uniform failure of earlier pilot tests of dynamic ridesharing (see Appendix A), made it clear that adequate incentives were a necessary condition for a successful dynamic ridesharing program.

While casual carpooling is a successful phenomenon in certain locations, it does have a number of limitations.  First, it depends on transit, in two ways: (1) the existing morning casual car pool locations have grown from transit locations (at least in all the Bay Area cases with which I am familiar) – it starts when a driver offers a ride to a would-be transit passenger; with a good outcome both participants are inclined to repeat the experience, and the phenomenon grows; and (2) casual car pools also depend on transit as the “backup,” especially for a ride home in the afternoon.

A second limitation of casual carpooling results from this transit-dependence: its effects on traffic congestion are probably slightly negative.  Most car pool passengers would otherwise have taken transit; thus, their switch to casual carpooling is neutral with regard to the number of vehicles. Some car pool passengers would otherwise have driven their own vehicles; thus, their switch to casual carpooling reduces vehicles. But some drivers would otherwise have taken transit; thus, their switch to casual carpooling increases the number of vehicles.  In the Bay Area case, this increase seems to slightly outweigh the decrease caused by solo drivers who become casual car pool passengers.  (Casual carpooling may also be said to have a negative effect on transit, but so does our system of free roads in general.)2

A third limitation of casual carpooling is its need for the coincidence of several factors: a casual car pool location must be adjacent to transit; have available curb space (both space for picking up riders and additional space for vehicle queues); and have parking for riders nearby, or be located in a fairly dense residential area.  It appears to be impossible to establish a casual car pool location without meeting these requirements.

B. The Vision Thing

My interest in dynamic ridesharing is to a large extent a product of a utopian vision of its success (a characteristic I’m sure I share with many would-be entrepreneurs, although I consider myself a reluctant entrepreneur, given the lack of a business model for this enterprise).  My vision is that successful dynamic ridesharing can accomplish a number of good things:

Dynamic ridesharing can overcome the limitations of casual car pools.  It does not have to depend on transit; in fact it can be tailored not to take riders from transit.  This can be accomplished by providing users relatively little advance notice in the morning.  When a user who can otherwise drive is left unmatched on short notice, it is not a problem for them; they can just get in their car.  A transit user, however, likely needs more time to make their transit connection and arrive at work in timely fashion.  In this way, dynamic ridesharing works better for would-be drivers than for would-be transit users.  As a result, dynamic ridesharing will reduce traffic congestion.  Further, by having car pool partners meet in cyberspace rather than at physical locations, requirements for curb space, adjacent parking, and residential density are obviated.

Dynamic ridesharing can also serve as a new, more efficient way to serve the low-density residential development that is typical of modern suburbia.  Fixed-route buses run at low load factors in such settings, and as a result, often at infrequent intervals.  Larger numbers of smaller vehicles – personal autos – are better suited to low-density settings.  Such settings are typical of transit feeder service, which are intended to shuttle riders of longer-distance transit – such as suburb-to-city trains or buses – between their homes and transit stations.  Parking at such stations is often in short supply; dynamic ridesharing multiplies the utility of each parking space.

Parking itself is very expensive.  Land costs alone in suburban areas can easily exceed $5,000 per space.  The construction of multi-level parking structures generally exceeds $20,000 per space.  A simple per-year cost (that should roughly account for interest, taxes, depreciation, etc.) would divide that $25,000 total cost by ten: that’s $2,500 per year, or, over 250 work days per year, $10 per parking space per day.  In comparison, dynamic ridesharing should be able to save parking spaces at ongoing costs around $2 per day.  System operation costs are actually de minimus; less than $100/month for servers and telephone access.  The most significant ongoing cost is for tax rides home: I believe these are at worst about one taxi ride per day for each 30 users.  Let’s say a taxi fare averages $15.  If dynamic ridesharing produces an average occupancy of 1.5 people per vehicle (I think dynamic ridesharing will do better), then 30 users will require 20 parking spaces, saving 10 spaces compared to the case where all 30 users drive.  So the taxi ride comes to $1.50 per saved parking space.3 

Finally, part of my vision was that – should it prove successful – there was a sizable market for dynamic ridesharing systems.  Any freeway corridor with significant car pool lane time savings; any transit station short on parking; any large company concerned about providing parking; all of these would be candidates for dynamic ridesharing.4

II.  Reverse Casual Car Pools

My first involvement in transportation issues came via my then colleagues at Environmental Defense Fund, who were doing research and advocacy on “congestion pricing” (which has gained currency since its successful application in central London by mayor Ken Livingston beginning in 2003).  I was intrigued by the casual car pool phenomenon as an interesting and creative response to a particular set of circumstances and incentives.  At that time casual carpooling was a one-way, inbound only phenomenon.  It occurred to me that it shouldn’t be too difficult to create “reverse” casual car pools in the evening.

During an employee strike of the Bay Area Rapid Transit District (BART – the Bay Area’s subway/commuter railroad system) in 1998, the San Francisco Department of Parking and Traffic attempted to enable evening carpooling.  They posted a “car pools here” sign along a route to the Bay Bridge.  It didn’t catch on.

I thought a little more organization would enable success.  The Department of Parking and Traffic agreed to set aside more curb space in San Francisco, and post more signs, corresponding (roughly) to different destinations in the East Bay (which were locations of morning casual car pool sites).  Then one Monday morning I and about a half-dozen colleagues from Environmental Defense Fund each went to a different casual car pool site and handed out flyers.  The flyers said “meet this afternoon in San Francisco, and it will work!”  Together we handed out approximately 5000 flyers.  The BART strike was by then over, but people were interested, and indeed it did work; a bit chaotically at first, but people came the next day, and the next, and the evening casual car pools are now an established institution.

It is also an interesting lesson in incentives to observe that not all East Bay destinations have been successful for evening casual carpooling.  For example, while the north Berkeley site is very successful in the morning, there is no activity at all for this destination in the afternoon.  While quite a few north Berkeley-bound commuters showed up that first Monday afternoon, the incentives are not sufficient to keep people interested.  The north Berkeley site is relatively close to the Bay Bridge.  In the morning, drivers save 20 minutes or more when they bypass the toll plaza, but only a few minutes on the relatively short section of car pool lane between north Berkeley and the toll plaza.  In the afternoon, north Berkeley-bound drivers save only a few minutes using a car pool-only onramp, plus the few minutes due to the car pool lane (there is no toll collection or toll plaza delay in the afternoon commute direction); evidently these few minutes together are not enough to make it worth their while to pick up passengers.

In contrast, several East Bay destinations have wildly successful casual car pool activity in the afternoon.  The Vallejo location, for example, is distant – commuters will be in the car pool lane for more than 16 miles, bypassing one of the most congested commutes in the Bay Area.  They’ll also save time and money at the Carquinez Bridge toll plaza.  For passengers, there is no direct transit to Vallejo.  They must take BART and then transfer to a bus.  Casual car pool passengers regularly wait in line for 30 minutes to get a ride; nevertheless they will have a shorter total travel time than the transit alternative.

III.  Dynamic Ridesharing

Shortly after this I began to explore the potential for creating a web- and telephone-based dynamic ridesharing system.  I found that a handful of government-sponsored pilot tests of similar systems had been tried in the early 1990s (see Appendix A). None of these were successful, but then none of them seemed to have applied my conclusion from observing casual car pools that adequate incentives are a necessary condition for success.

A colleague at Environmental Defense Fund and I wrote a proposal to solicit funds from foundations (see Appendix C).  I started doing research on such systems.  I wrote a computer simulation model that created “commuters” making “ride-match requests,” randomly distributed by time and location, and calculated how many could be matched into car pools given various constraints (such as the maximum detour for a driver).  I wrote a paper summarizing the model and its results, which I submitted to the Transportation Research Board. 

Nothing came of these activities.  No foundations expressed interest.  The TRB rejected the paper as “not useful” (while accepting a paper I wrote on congestion pricing). 

Nevertheless, in the year 2000 I resolved to move forward to at least create an initial software and hardware system.  Despite my complete lack of experience in creating web pages – let alone telephone systems – I believed that this was within my capabilities, and by doing so I would overcome an initial cost hurdle to creating a dynamic ridesharing service.  These both turned out to be true (and may be the last time I made a correct positive prediction in this endeavor!).  I started work in earnest on the system – learning web programming as I went – in early 2001.

IV.  System Design

A.   How the system works from a user’s perspective

Before I discuss the decisions made in arriving at the dynamic ridesharing system I implemented, here is an overview of how the system (in its final incarnation for use at the West Oakland BART station) works for a user. 

  1. Registration (one-time setup).  On the registration web page the user provides their phone number and location (address or nearby intersection).  They also pick a "personal identification number" (PIN) that they use to log in to either the web page or the automated phone system.

  2. Mornings:

    1. Make a ride match request.  On the morning the user wants to leave, or up to a day before, the user makes a ride match request, either by logging onto the web site, or by using the automated phone system.  They indicate when they want to leave home, and whether they are offering a ride, need a ride, or can do either.

    2. Wait for notification of ride matches.  About 25 minutes before the user’s time to leave home, the computer system will notify the user of their ride match.  The system can give the user a phone call, send email, or send a cell-phone text message.  Alternatively, the user can check for ride matches either on the web site or by calling the automated phone system.

    3. Call the Ride Now telephone system to contact one’s match partner(s).  The telephone system will forward the user’s call.  The user should confirm their arrangements with their match partner(s).  (This call confirms the user’s eligiblity for parking or a guaranteed ride home.  By going through the telephone system all phone numbers are kept confidential.)

  3. Afternoons/evenings:

    1. Call the telephone system when one is approaching or at the station.  The user should make a cell phone call.  If they used the system in the morning it will know whether they are driving or need a ride.  Otherwise, they enter touchtones to indicate whether they are driving or not.

    2. Wait just a few minutes for matches. The system will check for other people arriving at the station at about the same time.  The system makes matches every five minutes; users don’t wait more than about 10 minutes to find out about their match.

    3. Find out about one’s match. The system will either send the user a text message or call them with an automated voice message telling them about their match.  Alternatively, they can call the system themselves to check.

    4. Contact one’s match partner(s) via the telephone system.  The telephone system will forward the user’s call so that the match partners can agree where to meet.

B.   System design decisions

I made two major decisions about the overall design of the dynamic ridesharing system early on, that I stuck with throughout the pilot tests.  Other aspects of the system, however, are “tunable parameters” that were changed to some extent during the course of the pilot tests.  The first major decision was to make an “assigned-match” system: the computer finds the “best” match partners for each request rather than allowing users to choose their match partners.  Second, as much as possible the system’s capabilities would be made available via telephone (through an “Interactive Voice Response” system – that is, “for a ride match, press 1,” etc.) as well as via web page interface.

The first major decision – to use an assigned-match system – was based on efficiency considerations.  I believed that in the long run people’s continued use of the system would depend on their own cost-benefit comparison of the system with alternatives.  From my observations of the casual car pool phenomenon I concluded that time, rather than dollar costs, is the most important factor.  An assigned-match system should (1) minimize the time spent finding a match partner; (2) create the most efficient matches – in terms of minimizing detours; and (3) produce the greatest number of matches (clearly it’s a cost when the user spends the time contacting the system and then does not get a ride match).  Finally, the assigned-match system is a fairly close analog to the casual car pool system: casual carpoolers normally accept the next person or vehicle in line.

It is unclear whether this was the right decision.  The downsides of this choice include the fact that it is unfamiliar to people; existing car pool systems – dynamic or not – are based on choosing a potential match partner from a list.  In addition, people may not like the “lack of control” inherent in this scheme.  The only successful dynamic ridesharing system uses the “choose your partner” method (see NuRide in Appendix B). 

The second major decision – to make the system telephone-accessible – meant significant additional work and is also the only real source of ongoing system operational costs (that is, things other than marketing or guaranteed rides home, for example).  The convenience provided by telephone access appears to be well worth it, however, and telephone access was well used during the only pilot test of significant duration, at BART Dublin-Pleasanton (although there were some complaints about the usability of the system – Interactive Voice Response system design is more difficult than web page design, I conclude).  In addition, advances in Internet-based telephony have alleviated the cost concern.  In fact, I completely rebuilt the telephone system before beginning the third pilot test (at West Oakland BART) in order to take advantage of so called “Voice Over IP” technology, add additional features, and (hopefully) improve usability.

A few other decisions became inherent features of the system design.  One was to make it a “one match per request” system (that is, each ride match request is a new transaction – there are no “standing requests”) and to limit the “maximum request lead time” – how far ahead one could make a match request – to one day (that is, if you wanted to get a ride on Wednesday morning, the earliest time you could make such a request was Tuesday morning – although weekend days are ignored in this calculation, so that requests for Monday could be made the previous Friday).  My thinking was that the worst thing a user could do is not show up for a match.  These features are intended to minimize the possibility that people would forget their commitment.

Other features were designed to be flexible; they could be changed by altering various system settings.  For example, the minimum request lead time (that is, the nearest time before a ride match that a user could still make a request) can be as short as zero (which is what is done in the afternoons at the transit station, as described in the “user’s perspective” in the previous subsection).  Another setting can be used to define a minimum “time window” required for ride match requests.  For example, in our pilot tests, users were required to provide at least a 10-minute time period when they would accept ride matches (for example, the user might indicate that they wanted to leave home between 7:30 and 7:40 AM.)  Another setting indicates whether or not parking is available for system users (which then invokes the “parking credits” calculations, described in the section on the Dublin-Pleasanton pilot project, below).

An important flexible setting is whether or not the destination is a transit station.  This invokes a completely different scheme for homebound ride matches.  (In fact, two different homebound match schemes were eventually implemented.  I’ll describe the first one – used at the BART Dublin-Pleasanton station here.  The second one, planned for the West Oakland BART station, was described in the preceding subsection.)  While it is possible that afternoon matches could be requested in a manner similar to morning matches – users could call ahead of time while they are at work, indicating what time they wanted to arrive at the destination station, and be notified of their prospective match.  A sufficient “time window” would then make it easier to form ride matches.  For example, if one user was willing to get a ride home between 6:00 and 6:30 PM and another between 6:30 and 7:00, then they could be matched at 6:30 PM.

I thought people would have difficulties with such a scheme: they would have to leave work at a fixed time and then get to their departure station at a time appropriate to catch a train that arrived at the Dublin-Pleasanton station at the appointed hour.  I tried to design a more reliable scheme: once people were on a BART train they would use their cell phone to call the computer telephone system.  They would use a touch tone to indicate where they were on the BART line leading to Dublin-Pleasanton (they would indicate which station they were either at or approaching).  This was feasible because there were many miles of above-ground track on that BART line.  Once a train exited the underground or transbay tube section of the line, they still had more than 30 minutes before they arrived at Dublin-Pleasanton.  The computer system would compare the user’s indicated position and the time of their call with the BART train schedule to estimate their arrival time at Dublin-Pleasanton.  They could then be matched with other users arriving at that time.  Finally, a computer monitor at the station would display match results.

Of course, sometimes trains are off-schedule.  This occasionally led to missed match partners, and led me to the scheme – call when you get there – described in the preceding subsection.

Finally, it may be useful to note that the dynamic ridesharing system used in all three pilot tests is a “many-to-one” system.  That is, in the morning there are many origin locations (different user’s homes), but a single destination (either downtown San Francisco or a train station).  A “many-to-many” system would be useful in a situation like the San Mateo-Hayward bridge, which crosses the southern San Francisco Bay, and has a car pool bypass at its toll plaza.  Work destinations on the west Bay (Peninsula) side – including many suburban-style office parks – are not centrally located.  Although I think I was pretty close to completing a “many-to-many” version of the dynamic ridesharing system, I never fully implemented it.

V.  FHWA Proposal

At about this time – I don’t remember now how or when – I made acquaintance with Allen Greenberg, then with the Environmental Protection Agency in Washington, DC.  He had written a paper (accepted for presentation at TRB) on the potential for dynamic ridesharing.  I had also started contacting various agencies and organizations to see if they could be interested in participating in a dynamic ridesharing project.  The one success I had was in getting the “station access” department at BART to show some interest.  They said they would write a letter indicating that they would be willing to participate in a project if money could be found (they were quite clear that they had no funds to contribute).  They identified the Dublin-Pleasanton station as the location for a project – while parking was very scarce there, a fairly large car pool parking lot was mostly unused.  A successful ridesharing program could fill those otherwise unused car pool spaces, and free up more spaces in the main lot.

In mid-2001 Allen contacted me, saying that he had moved to the Federal Highway Administration (FHWA).  He encouraged me to apply for a grant for a pilot test of dynamic ridesharing.  He also indicated that it was extremely difficult for FHWA to fund software development; thus a proviso of any proposal should be that the software was provided – at least for the purposes of the proposal – at no cost.  Such proposals would have to come from a government agency; at this point I approached a local transportation agency and they agreed to participate with BART in an application for funding.  I wrote the proposal; it was sent to FHWA in November 2001.  (This is actually an abbreviated version of the full story; I had earlier elicited some interest from a southern California transportation agency.  A partnership with the California Department of Transportation was agreed to.  I wrote the proposal.  At the last moment the southern California agency declined to participate.)

The FHWA requires a “local match” contribution of 20% of the total proposal.  The proposal for dynamic ridesharing pilot tests was written with a total request of nearly $500,000.  As things developed, the local agency was unwilling to commit more than $20,000.  FHWA allowed the total $500,000 request to remain, with the understanding (backed by a letter) that the local agency would provide the $20,000 local match for a $100,000 total “first phase,” and that the regional transportation agency would “consider” funding the remaining local match requirement in a “second phase” of the project.

In July 2002 FHWA announced its award of funding to our project.  There then followed a period in which bureaucratic funding intricacies contributed their delays, and then there was further delay while Bay Area transportation spending was held up (some irony here) by an environmental lawsuit.  Finally, although my (perhaps naive) expectation was that I would then be in charge of implementing the pilot test (I had set up “Ride Now, Inc.” as a California non-profit for several reasons, but with the indication that it would soon be receiving $100,000), the local agency informed me that a “competitive solicitation” for a project manager was required, and that I was not viewed competent to lead or administer such project. 

I contacted two organizations, informing them of the coming solicitation, and indicating my interest in being a subcontractor in a proposal.  They were interested, and decided to make a joint proposal.  Without my knowledge, they included me in their proposal at zero cost. 

The local agency rejected the single bid (for reasons that I won’t go into, but in retrospect had little merit).  The agency held a second solicitation.  Fearing that a single bid might again be rejected (it was the same two organizations again, merely reversing their lead and subcontractor roles), I put in my own bid (as well as agreeing to subcontract in the other bid).  The organizations’ bid was accepted this time (I could only speculate why).  A first meeting was held in June 2004.

VI.  Interstate-80 Corridor

Given the passing years and dimming prospects for the BART project (more on this, below), I had in the meantime continued searching for a location and partner for another pilot test of dynamic ridesharing.  I thought the incentive provided by the available funding would be useful.  More than a few hours were spent writing two additional proposals that in one case the would-be participating agency backed out of, and in the second case was submitted and then rejected by the funding agency (which said, in essence, “if you can prove this will work then we’ll support it”).

I decided that I had a good opportunity to implement a project on my own in the I-80 corridor, where casual carpooling is in some instances a victim of its own success.  For example, I had observed that at the Vallejo park-and-ride lot, casual car pool activity dropped off dramatically at about 7:00 AM.  Why?  Because that was when the parking lot filled.  A number of other locations along the I-80 freeway were also quite short on parking; in addition, there were often queues of either riders or drivers that required waits of 5 to 10 minutes.  Finally, as I mentioned earlier, for the ride home to Vallejo from San Francisco, riders endured a 30-minute wait.

Dynamic ridesharing offered an alternative to each of these shortcomings of existing casual carpooling.  Users could choose meeting locations where parking was available.  Scheduled meeting times would avoid waits for drivers or riders, which would be especially advantageous compared to the afternoon wait in San Francisco.

It occurred to me that I had a low-cost opportunity to gauge the attractiveness to users of dynamic ridesharing in this application: many of the likely users worked in downtown San Francisco; it would be relatively easy to get them to participate in a lunch-time focus group.  I borrowed a conference room and, with the promise of lunch and $25, recruited a dozen participants for each of two groups.  I hired a consultant with experience in corporate marketing to run the groups.

The participants had a very positive response to the proposed project.  Existing casual carpoolers were eager to get away from the uncertain and long wait times.  We also explored possible marketing approaches, and asked participants about needed lead times for matches in the morning and afternoon (that is, how much ahead of time before they were to meet their riders/drivers they wanted notification of their ride match).  We also asked their preference on whether users should be required to provide a credit card during registration (to provide some security/background about the people with which one would be riding) or whether this would be too much of a burden or inconvenience compared to the security value (people indicated that providing their credit card was not a problem).

(As it turned out, the information from the focus groups was nearly worthless.  Target users – existing casual carpoolers – were, as a group, far more cynical and skeptical than were the focus group participants.  I think that willingness to participate in a focus group is itself evidence of a less cynical attitude.)

I made several decisions in designing how the system would work in this case.  I limited users to 16 pre-set meeting locations, which I picked to correspond roughly to existing casual car pool locations (near the freeway), and to meet two additional criteria: (1) all-day parking was available; and (2) the locations were close to bus stops, so that people could take a bus back to their car in the afternoon if they couldn’t get a ride.  (I had always envisioned a guaranteed, free taxi ride home as a component of a dynamic ridesharing system that asked would-be morning drivers to leave their car behind.  In this case I deemed that impractically expensive: the most distant location I was serving – Vallejo – is nearly 30 miles from San Francisco.)  I also required users to provide a credit card during the registration process, consistent with the feedback provided by the focus groups.

I had two main approaches to marketing: (1) media, both conventional (newspaper) and new (email); (2) direct –  handing out flyers to existing casual car pool users.  I hoped that a three-week period would be sufficient to gather enough users.  (My computer simulations indicated that as few as 20 active users per day would be sufficient to get almost everyone matched into a car pool.  In retrospect, these simulations were based on at least one flawed assumption: that drivers would be willing to pick up and drop off passengers at intermediate stops along the way; that is, they would be willing to get off and back on the freeway.  With the start of service, drivers were quite clear that they were unwilling to do that.)  Of course, I did not know how many registered users would be active users at any given time; I don’t recall that I had any firm goal for number of registered users in mind.)

The flyers and web site included these incentives: $5.00 to drivers who offered rides home; $20.00 to anyone who made 5 ride match requests within the first week, and $5.00 to anyone who needed but did not get a ride home.

Around the beginning of July 2004, about two weeks before my planned launch date, I began handing out flyers at casual car pool sites along I-80 in the morning, and also handing out flyers at the afternoon casual car pool location in San Francisco.  Conditions were conducive to reaching people this way: they were either passengers waiting in line for a driver; or drivers waiting in their cars for passengers.  Thus they generally had time for a short pitch on what it was I was “selling.”  The response was positive to the extent that perhaps one out of ten people would say “that’s a good idea” (or even “that’s a great idea!”).  But there was also an undercurrent – people who thought that the dynamic ridesharing system would destroy the existing casual car pool system, and that my goal must be to at some point to charge them money for what currently they got for free (a reaction clearly missing from the focus groups!).

During this period I also approached the transportation reporters for several newspapers.  While I never elicited interest from the San Francisco Chronicle, the Contra Costa Times reporter found the project intriguing. He interviewed me at some length in person, and had a photographer take my picture one morning handing out flyers.  The article, with photograph and a prominent link to the Ride Now web site, ran on the front page of the West County Times, a local version of the paper with circulation primarily in cities along the I-80 corridor – in other words, it was ideal for my purposes.

There was no noticeable effect on web site visits.  In the next couple of days of handing out flyers there was maybe one in 25 people who said, “I saw you in the paper.”  Rather less useful than I anticipated!  Nevertheless, I believe it was very helpful to have copies of the newspaper article to hand out along with the flyers – it provides an independent corroboration of one’s “legitimacy.”

An additional, shorter article ran in a local paper, the Vallejo Times.  I also had a five-minute appearance on a local television station morning show.  Again, that was helpful only to the extent that perhaps one in 50 people mentioned seeing it.

Some registrations were being made on the web site.  At the suggestion of Paul Resnick (interested in “social computing,” he had come across the Ride Now site, and visited the San Francisco casual car pool location with me), I began to try to “register” people on paper, as I talked to them.  This was fairly effective, but also much more effort than I had anticipated.  Registrations became very much a one-person-at-a-time engagement.  Had I known that personal contact was going to be my primary marketing method, I would have hired someone to help with this.  As it was, in an additional week after my planned launch date I got to 45 registered users.

As users registered I followed up with a (U.S.) mail package that included a thank-you note and summary guides to using both the web site and the telephone system.  On the weekend before the Monday, July 26, 2004 launch date I sent email and left telephone messages urging people to make a ride match request for Monday morning.

Here are the results:

Table 1.  Results of the I-80 Ride Match Program


Requests

Matched

Drive alone

No ride

# car pools

Monday morning

19

12

1

6

5

Monday afternoon

14

8

0

6

3

Tuesday morning

6

3

0

3

1

Tuesday afternoon

7

5

0

2

1

Wednesday morning

6

2

0

4

1

Wednesday afternoon

7

4

0

3

1



On Monday morning, 19 of those 45 potential users  made a ride match request.  Twelve people were matched into five car pools.  Monday evening there were 14 requests, with eight people matched into three car pools.  This could be considered moderately successful, but the important indicator is user response: was their experience worth repeating?  The Tuesday and Wednesday results at best indicate there may have been a small core group of users willing to continue. Those usage levels did not produce results that could be used to attract new users.

I pulled the plug Wednesday evening.  Things were actually worse than the match statistics imply, because there were drivers who said, “no, I'm not going to drop somebody off part way home,” and riders who said, “no, I'm not going to drive to THAT meeting spot.”

I believe the principal reasons this project did not succeed are these: (1) an independent entity with an apparent profit motive was unable to gain the trust of potential users; (2) incentives to use the new service were not sufficient (especially for drivers in the afternoon – the existing system works fine for them); and (3) there was no available “path” for building volume to sufficient levels (that is, there was no reward available to someone who tried the service and was not matched – only when there is a sufficient volume of users would there be enough matches so that the likelihood of reward made it worth continuing to use the service).

VII.  Dublin-Pleasanton BART

A.   First, let’s add some obstacles

As I mentioned, by this time a consultant had been selected to run the dynamic ridesharing pilot test at the BART Dublin-Pleasanton station.  Several key events, however, occurred earlier.  When I first approached BART, the Dublin-Pleasanton station was an ideal location – car pool parking spaces were available, and parking was scarce.  (I believe I was told that the parking lot was full before 7:30 in the morning.)  I am certain that is not because people all want to go to work that early.  But for many people – for whom transit connections to the station are not convenient or who simply do not want to take transit – if they want to take BART to work at all, they have to get there in time to get a parking space.  Others who cannot do this – perhaps they have to drop off children in the morning – are pushed into other commute modes (primarily driving alone, no doubt).  For such people, car pool parking spaces available through dynamic ridesharing would be a powerful incentive to use dynamic ridesharing.

Thus, the program was designed to exploit this incentive: any user who made a ride match request (that is, offered to drive) in the morning would get a parking space, whether or not the system found them a match partner.  This provides a way to build participation: every time someone uses the system they get something they want (which, as I mentioned above, was a key factor lacking in the I-80 corridor project).  I created a system to exploit this incentive in the afternoon as well as in the morning.  In the afternoon, there is no natural incentive for a driver to offer rides home (they already got their parking space!).  What I created was a system to award “parking credits.”  Afternoon drivers automatically earned a “credit” every time they offered a ride home; they “used up” a credit every time they used a parking space in the morning.  They could use a parking space in the morning only if they had one or more “credits” in their “account.”  This would require drivers to offer rides home if they wanted to keep getting a parking space on subsequent days, while leaving them the flexibility to sometimes not offer a ride home, yet still be able to use a parking space the next day.  (A few additional details: new users’ “credit accounts” started with three credits, and credits were only needed when drivers didn’t have any riders.)  The entire scheme proved to be initially confusing both to users and to various advisers to the local agency.  One meeting with agency advisers began with “we don’t like this.”  An hour later the reaction was “that’s brilliant!”  Users wanted to know how they would “get their credits,” but once it was explained that their account was on the web site and that they could see how many credits they had at any time, people seemed to understand the scheme.

The first two key events that affected the Dublin-Pleasanton project were external factors that essentially erased the parking incentive: (1) the “dot-com” crash led to a decline in BART ridership; and (2) additional parking was added at the Dublin-Pleasanton station.  When I observed parking usage at the beginning of 2003 the lot still had available spaces at 9:00 AM.  When I again looked in early 2004 the distant spaces did not fill until 8:35 AM.

The third key event occurred during the long period of soliciting and re-soliciting bids, during which time I was excluded from participating in discussions with the local agency, since I was a potential bidder.  I was brightly informed at one point, however, that the agency had concluded negotiations with BART, and that BART had agreed to provide 10 parking spaces for the dynamic ridesharing program.  This was an obviously fatal misunderstanding of the requirements for the program – I knew that in order to have a reasonable number of matches that at least 30 ride match requests per morning would be needed; even at two per car this would be more than the 10 available spaces.  At lower participation levels it still could be problematic: with fewer requests there were likely to be fewer successful matches.  With 15 requests, at least 10 people would have to be matched into car pools if 10 spaces were to be sufficient (5 car pool vehicles and 5 drive-alone vehicles); with fewer matches one or more users would not be able to get a parking space.

Early on, of course, I realized that the key ingredient for success of dynamic ridesharing at the Dublin-Pleasanton station – the scarcity of parking spaces – had disappeared.  I told the local agency that the project would have to be moved to another BART station where parking was still scarce.  The agency’s reaction surprised me: “we told our Board that we were doing the project at Dublin-Pleasanton; we told FHWA that we were doing the project at Dublin-Pleasanton.” 

There followed a protracted period of pleading, begging, and whining on my part.  FHWA readily asserted that they didn’t care where the project was located; eventually the local agency’s Executive Director asserted that their Board likewise would not care about the project’s location.  Finally, the staff in charge at the agency agreed to talk to BART about moving the project to a different station.

I focused on the Rockridge station in Oakland, since I knew that parking there was very tight (my observation day showed the lot filling at 7:20 AM).  The primary difficulty was that only 16 spaces were allocated to car pool parking, and at least 10 of these were regularly used.  Eventually BART staff acknowledged the logic of my argument that the expansion of space allocated to car pool parking to accommodate dynamic ridesharing users would cause no harm to other station users: even drivers who did not get matched with riders would likely have parked in the regular lot; every car pool formed would likely free up one space in the regular lot.  The response, nevertheless, was “our Board wouldn’t understand.”  (The truth of the matter is they “just didn’t wanna” do the project at that station.  Likewise, the local agency staff rejected another station on the grounds that “too many out-of-county people use that station.”)

So the project would be at Dublin-Pleasanton.  The one bright side of the delays was that the economy was improving, and parking was getting scarcer there.  Of course, if dynamic ridesharing users were interested in getting a parking space, we would soon use up the 10 spaces BART had allocated to our program.  Eventually the seriousness of this problem became apparent both to agency staff and their consultant, and they set a meeting on this issue with BART staff.

I did not attend that meeting.  (My attendance at previous meetings seems to not to have helped; I thought I would try the opposite tack.)  For whatever reason, BART would not be moved on this.  Perhaps we could “buy” parking spaces – allowing dynamic ridesharing users to park in the “reserved” lot?  No, not that either.

Were there any alternatives?  Agency staff contacted nearby office parks about leasing spaces.  (Not much of solution in my mind – use our program so you can park even farther away.)  No spaces were proffered.  I suggested that at least those participants who had been matched into car pools could be directed to the regular car pool lot; that would at least save the 10 spaces for those drivers who did not get matched with riders.  BART’s rules precluded this: each car pool occupant must have their own car pool parking permit, which must be displayed on the dashboard of the car.  How would a dynamic ridesharing rider – who, at the end of the day, is likely to go home at a different time than their morning driver – get their car pool parking permit back?  Could BART’s rules be modified to accommodate dynamic ridesharing carpoolers?  I should have realized by then that such a question would not even be open to consideration.

BART did manage to add one insult to these injuries.  As I mentioned, the “parking credits” scheme would allow drivers – even those without a matching rider – to park in one of the 10 spaces in the morning as long as they had sufficient parking credits – that is, as long as they had been offering rides home in the afternoon as well.  This, of course, assumed some kind of enforcement mechanism – perhaps only sporadic – that would prevent those who were not eligible from parking there.  The computer system makes it fairly easy: it knows who has been matched with who; it knows how many “parking credits” each driver has; it knows the license plate number of each driver’s car.  As I volunteered, “each morning the computer can send an email with the license plate numbers of eligible vehicles, or it can send a fax, or a cell phone text message.  Just let me know which and where you want it to go.”  BART contacted their parking enforcement staff; the response came back: “we have no way to deal with that information.”  BART staff concluded: “you know, Dan, it’s just a pilot program, so there won’t be any enforcement.”

So the program would begin with a limit of 10 parking spaces as a major obstacle.  A few additional obstacles were also added.

A first additional obstacle concerned the free taxi ride home offer.  Every proposal for the project had included this feature: if a rider (who had left their car behind and taken a ride in the morning) was not matched with a driver in the afternoon, then they could take a taxi home and the project would pay for it.  Local agency staff thought this offer was “too generous.”  They insisted that the least the rider could do was wait for another train to arrive in case a suitable driver might arrive on the next train.  Trains arrive at Dublin-Pleasanton at 15-minute intervals – a considerable wait for someone who had otherwise expected to simply get in their car and drive home.  Nevertheless, I was required to make that modification to the software.

A second obstacle was added to the guaranteed ride home offer: the vouchers with which users would pay for their taxi ride were only valid for use with cabs from a single taxi company (out of the 18 that served the station).  Users would have to call the cab company and wait for it if one was not available at the station.  Couldn’t we just let people take whatever cab was at the front of the line, and reimburse them?  No, the local agency could not take the liability risk, according to their lawyer. (What liability risk?  Again, not even open to discussion.)

One more obstacle was added: even if one of that particular taxi company’s cabs was in the line, BART would not allow users to take that cab from the line. “That would look like line jumping.”  BART insisted that users could only meet their cabs off BART property.  (It gets sillier: a nearby dead-end street was identified as a place for riders to meet the cab they had called. The local agency decided they should ask the city of Dublin’s permission whether that would be all right.  The City said no, the street did not have a streetlight.  The project paid $5,000 to have a streetlight installed.  Add three months.)

I did add one more obstacle myself, in one of the few unilateral decisions I was able to make in this project.  (How?  I just did it, since this was a matter of software parameter settings, and I controlled those.  The project managers did not notice the settings until a very late date, at which point they went along with what I had done.)  I restricted morning ride match requests to the 7:00 AM to 8:00 AM period.  I was concerned by the limited number of parking spaces available for program users, and I wanted to maximize the incentive value of those parking spaces.  The 10 dedicated parking spaces would not be at all valuable when parking spaces were plentiful in the regular lot.  I also wanted to maximize the chances for ride matches by having people make requests as much at the same time as possible.  As it turned out, usage was so low initially that the lack of parking spaces was unlikely to have been an issue by itself.  There were a number of interested users with an earlier schedule, and the restricted time period simply excluded them from participation.

B.   Marketing

The agency’s consultant created a new front page for the web site.  I had anticipated that people would be able to view the web site demo, and proceed to register if they wished to.  Those in charge opted for a multi-step process: initially those who were interested would provide contact information.  Later they would be contacted and told to come to an “orientation session” at which time they would be requested to register.  (Why the orientation session?  BART was concerned to make it clear that this was “only a pilot project,” and that users should be aware that there were bound to be glitches – perhaps in the software, perhaps elsewhere.  In addition, they felt that people needed to be told how the system would work.)

BART did make one contribution that was extremely important: they agreed to provide up to $5000 of BART tickets as promotional incentives for the program.  (One reason this was so important was because the program managers were not otherwise willing to use any of the program budget for such incentives, or for augmenting the incentives provided by the BART tickets.)

The local agency and consultants designed a new logo for the project and its web site, and the new front page was put up in February 2005.  (The project managers also sought a different name than “Ride Now,” which I had trademarked.  An ongoing concern was not to advantage that private entity – non-profit status notwithstanding.  As it happened, they were unable to think of a better name.)  The web page included at the bottom the logos of the local agency and BART (which I now consider quite important to gaining the trust of potential users).  Perhaps most important, the web page indicated that people who “register and attend the orientation session will receive a $32 BART ticket.”

Two methods were used to publicize the program.  First, a small article ran in BART’s rider newsletter, which is available to every BART rider at every fare gate.  Second, the electronic announcement signs at the Dublin-Pleasanton station (which are used to indicate train arrivals, as well as providing various system information and public service announcements) periodically carried a message providing the Ride Now web site.  These messages were probably the most effective marketing method.

In addition, a computer monitor had been installed in the station to show ride match results to program participants when they got off their train in the afternoon.  During non-afternoon commute times it alternatively displayed two screens of information/advertising for the program.  The monitor was not in a prominent location, so this probably had little effect.  (That computer monitor’s installation was itself responsible for many months of delays.  Because it was within 30 feet of a BART train track – the fact that is was on an entirely different station level than the train platform apparently didn’t matter – BART’s requirements were that the computer be installed in its enclosure only by a UL-approved entity.  The location for the monitor had to be surveyed by a team of three BART employees, including a station custodial representative, etc., etc.)

A final marketing matter concerned the level and type of incentives that would be offered to encourage initial use of the system – only by having enough people making ride match requests at the same time can the system succeed.  I thought the offer of a $32 BART ticket just for registration was a good – perhaps too generous – first step; more important to my mind was encouraging people to actually use the system, rather than just register.

Thus I was disappointed by the project managers’ proposed incentive: a $20 BART ticket when people made three ride matches.  This incentive was entirely wrong in my view because it rewarded outcomes over which individual users had basically no control.  Whether or not people “made” a ride match was up to the system – it did the matching.  People made ride match requests, that is all.  Certainly, more requests should lead to more matches, but the connection is not direct.  After I made these arguments, the managers added a second incentive: users would also get a $20 BART ticket after they made 10 ride match requests.  These allocations of a limited amount of incentives did not make great sense to me.

C.   Initial operations

From a later perspective, it’s hard to get a sense of the lengths of time that passed.  Here’s a brief review:

Table 2.  Review of Dublin-Pleasanton Pilot Project Timeline

November 2001

Application to FHWA

July 2002

FHWA grant awarded

June 2004

First meeting of project “team”

February 2005

Web page up

April 2005

Station computer monitor installed

November 2005

Operations begin



Even after June 2004 it took approximately one and one-half years to get to the beginning of a six-month pilot project, with “team” meetings (and attendant hours billed) almost every month.

The project was finally ready to begin operations in November.  (The final obstacle had been installation of a streetlight in the adjacent city street where users getting a taxi ride home would have to meet their cab.)  Over nine months approximately 90 eligible participants indicated their interest in the program.  (The principal qualification was that participants reside in one of the four cities near the Dublin-Pleasanton station.)  I was unable to persuade the project managers that a project launch that encouraged all participants to begin making requests at the same time was important.  Instead, the system was put into operation on the day of the first orientation; the second orientation was held the next day.

The two orientation sessions were held in the afternoon at the station.  In order to have their $32 BART ticket mailed to them, participants were required to fill out a survey, and to complete their registration on-line.  Of the 90 eligible participants who had been notified of the orientations, 35 attended one of the sessions.  By the day after the second orientation 14 had registered.  There were no ride match requests made on the first day of operation (on which the first orientation was held).  The next day one user made a request in the morning and another in the afternoon.  (They didn’t get a ride match!)  Within a week 28 people registered.

Over the first month and one-half of operation, there were an average of about 2 ride match requests per day in the morning and another 2 in the afternoon; the greatest number was 5 requests during one commute period.  Obviously, with so few users, the odds are against two of them having similar locations and travel times.  The first ride match was made after about a week, but actually was a software error. 

New registrations came in slowly after the first week – the message board announcements continued, and there was even another orientation session (a single person showed up; after that attendance at such a session was no longer required).  After a month there were 34 registered users, and after two months, 40.

I had always assumed that most people would be willing to try the program because they really did want to get ride matches, and that people would be willing to make only about three ride match requests without positive results (namely, a match) before giving up.  For a number of people, this was clearly true, and the low number of requests on any given day seemed to insure a simple demise for the program: no requests. 

What was surprising to me, however, was the existence of a handful of people who were willing to try and try again, with very little reward.  (Certainly not the parking space; some of these people were only looking for a ride.)

After three weeks there were finally a couple of ride matches.  After two months there were a total of nine ride matches (although at least one of them did not result in a car pool, because a rider was instructed “to wait for the next train,” and did not).  These results were consistent with my expectations of utter failure based on the various obstacles placed on this pilot test.

D.   Re-launch

I urged the project managers to make a new start on the dynamic ridesharing service – while there were never more than five ride match requests during and one morning or afternoon period. in fact about 18 different users had made a ride match request at one time or another.  If even just those people could coordinate their efforts, the ride match success rate should be much greater.  I made these recommendations:

  1. Suspend the program.

  2. Announce/publicize a re-start date.

  3. Allow people to register on-line; give a $10 BART ticket to those who did; do not require attendance at an orientation session.

  4. Provide a $5 BART ticket for every ride match request made; keep doing so until the incentives budget was exhausted.

  5. Give some special rewards to encourage people to participate on the re-start date.

My hopes were raised when the project managers accepted all but the first of these recommendations.  My hopes were intact only until the first meeting to discuss these recommendations.  First, the project managers announced they had decided with BART that orientations were still necessary.  However, they continued to accept my recommendation that the incentive for registering be $10.  (This was the low point of my interactions with the project managers.  When I objected, “wait a second – we’ve already proven that people won’t come to an orientation for $32; why are they going to come for $10?” I was told to “stop being so argumentative.”)  In addition, they had decided that the $5 incentive per ride match request should be limited to five requests per person.  (The “stop being argumentative” remark made it impossible for me to raise further questions.  I later sent an email pointing out that even though we wanted people all to start making ride match requests on the re-start date, many people are slow to respond.  In fact, by the time some people started making ride match requests, some people would have already used up their five-request allocation of incentives.  Since there was no cost difference – we would keep providing the incentives, just to different people – why not do our best to retain our most likely prospects?  These points were not addressed on their merits.  Instead, the response was, “we already voted on that.”)

In addition, the time period for making morning ride match requests was extended from 7:00-8:00 AM to 7:00 to 9:00 AM, the requirement that riders wait for a potential driver on the next train was eliminated, and BART okayed putting flyers on all the cars parked in the station parking lot one day.  The project managers also organized several drawings in which one of the users making ride match requests on a given day would be chosen at random to win a $75 BART ticket.

The project managers also organized a “press event” on the re-start date, Wednesday March 29.5  A small article ran in a regional newspaper the following Monday.

Before the re-start, ride match requests had been running at between 3 and 5 per time period (morning and afternoon) each day.  Here are the results, beginning with the Monday before the Wednesday, March 29, 2006 re-start:

Table 3.  Dublin-Pleasanton Results - March 29, 2006 “Re-launch”

Morning


Afternoon


Requests

Matched

Unmatched

Car pools

Overall occu- pancy


Requests

Matched

Unmatched

Car pools

Overall occu- pancy


D

R

DR

Tot


drive alone

no ride avail.




D

R

Tot


drive alone

no ride avail.

taxi ride

# taxis



Mar 27

1

1

4

6

0

5

1

0

1.0


4

0

4

0

4

0

0

0

0

1.0

Mar 28

1

0

5

6

0

6

0

0

1.0


5

1

6

0

5

1

0

0

0

1.0

Mar 29

4

2

4

10

2

6

2

1

1.1


6

1

7

0

6

1

0

0

0

1.0

Mar 30

5

5

5

15

8

5

2

4

1.4


7

3

10

0

7

2

1

1

0

1.0

Mar 31

4

1

3

8

4

3

1

2

1.4


8

3

11

0

8

1

2

2

0

1.0

Apr 03

8

2

3

13

6

6

1

3

1.3


10

3

13

0

10

2

1

1

0

1.0

Apr 04

7

3

4

14

6

8

0

3

1.3


8

4

12

2

7

3

0

0

1

1.1

Apr 05

5

0

1

6

0

6

0

0

1.0


8

1

9

0

8

1

0

0

0

1.0

Apr 06

6

1

5

12

6

5

1

3

1.4


7

3

10

3

6

1

0

0

1

1.3

Apr 07

4

0

3

7

2

5

0

1

1.2


5

2

7

0

5

2

0

0

0

1.0

Apr 10

5

2

2

9

4

4

1

2

1.3


4

1

5

0

4

1

0

0

0

1.0

Apr 11

7

2

1

10

2

7

1

1

1.1


6

1

7

0

6

1

0

0

0

1.0

Apr 12

4

2

1

7

0

5

2

0

1.0


4

2

6

0

4

2

0

0

0

1.0

Apr 13

6

1

5

12

6

6

0

3

1.3


7

3

10

2

6

1

1

1

1

1.1

Apr 14

4

2

2

8

2

4

2

1

1.2


4

0

4

0

4

0

0

0

0

1.0

Apr 17

8

2

2

12

4

8

0

2

1.2


8

3

11

0

8

2

1

1

0

1.0

Apr 18

6

3

3

12

4

7

1

2

1.2


7

0

7

0

7

0

0

0

0

1.0

Apr 19

7

3

5

15

10

5

0

5

1.5


6

1

7

0

6

0

1

1

0

1.0

Apr 20

6

1

2

9

4

5

0

2

1.3


5

2

7

2

4

1

0

0

1

1.2

Apr 21

8

0

0

8

0

8

0

0

1.0


3

2

5

0

3

2

0

0

0

1.0

Apr 24

6

1

1

8

0

7

1

0

1.0


6

2

8

0

6

2

0

0

0

1.0

Apr 25

6

0

0

6

0

6

0

0

1.0


4

2

6

4

2

0

0

0

2

1.5

Apr 26

7

1

1

9

0

8

1

0

1.0


4

1

5

0

4

1

0

0

0

1.0

Apr 27

7

1

3

11

2

9

0

1

1.1


7

2

9

0

7

2

0

0

0

1.0

Apr 28

5

1

1

7

4

3

0

2

1.4


5

2

7

0

5

2

0

0

0

1.0

May 01

5

1

2

8

2

6

0

1

1.1


5

0

5

0

5

0

0

0

0

1.0

May 02

5

0

3

8

2

6

0

1

1.1


7

0

7

0

7

0

0

0

0

1.0

For each morning and afternoon match period this table shows the number of ride match requests made, broken down by those users indicating they wanted to drive, ride, or could either drive or ride (“DR”).  The number of users matched into car pools is shown, while unmatched users are broken down in the morning by those who drove to the station without a car pool partner, and users who wanted a ride but did not get one (“no ride avail.”).  In the afternoon the results include the number or riders who got a ride in the morning but did not get a ride home, and were thus eligible for a taxi ride home (“# taxis”).  Finally, the table shows the number of car pools and the overall average occupancy (number of people divided by number of vehicles).

The table shows that the re-start did increase usage from the previous three-to-five ride match requests per time period.  On the re-start date, March 29, there were 10 ride match requests during the morning period, and 15 the next morning.  Several times when there were 12 or more requests, half or more of those users were matched into car pools.  For example, on March 30, with 15 requests, 8 people were matched.  Similarly, on April 6 and April 13, each with 12 requests in the morning, 6 people were matched in each case. 

The ride match results in the afternoons were considerably worse.  Afternoon matching is a more difficult undertaking – people are less flexible in two ways: first, those with cars do not have an option to take a ride (as they do in the morning).  Second, people do not have the option of entering a “time window” over which they can accept a ride match (as they can in the morning).  Instead, they can only be matched with another user on the same train.

However, 15 ride match requests was the most that ever occurred in a single time period.  The usage never reached the 20-to-30 requests per time period that I thought were necessary for good ride match results – that is, where more than 95% of users requesting ride matches would be matched into car pools.  (This is especially true for the afternoon match periods, where the constraints described just above make sufficient volume critical for ride match success.)  These results were not adequate to cause participation to grow.  More detailed usage statistics made it pretty clear that while new participants did join the program over time, existing users stopped participating at an equivalent or greater rate. 

From emails received from project users, it became evident that the unavailability of parking spaces was a serious problem.  According to the statistics there should have been enough spaces.  There was no day on which more than 10 potential drivers requested ride matches, and usually some of those would be matched together, saving one vehicle per match.  Eventually one of the consultant staff did go to observe the parking lot one morning, and discovered that a number of people who had registered with the program were using the parking spaces without ever having made a ride match request.  Emails were sent to all registered users, indicating that they would be ticketed if they did not follow the rules.  No enforcement was ever available, however,  and the lack of parking spaces continued to be a problem.  (The seriousness of this problem should not be underestimated.  As one user related, after making a ride match request, she proceeded to the station.  All of the ten parking spaces were occupied, and the regular lots were full, too.  She drove back home and took the bus.  Such experiences are unlikely to generate repeat users.)

There were a number of missed ride matches.  In one case a driver declared that the passenger was too far out of their way (though well within the 10-minute-detour limit).  In more than one case it was unclear what happened, other than a failure of communication: “As a rider, I didn’t think it was my responsibility to call the driver.  I waited for 20 minutes and they didn’t show.”  In several cases in the afternoon, when BART trains were off-schedule, it was difficult for the system to determine which train users were actually on, and when they would arrive at the Dublin-Pleasanton station.  These were two useful observations from the pilot program, which led me to revise a few aspects of the system for my attempt to implement the dynamic ridesharing program on my own at the West Oakland BART station (see below).

The five-match-incentives per person limit also appeared to be a constraint on participation.  Perhaps – with continued incentives and more available parking spaces – the ride match success rate would have gotten to a level where people might have continued without the incentives.  This pilot program did not answer that question.

The pilot program ended on May 19, 2006, six months and a few days after it started.  The local agency staff had made it clear in February that they would have no further interest in the project.

The consultant wrote an evaluation report (see Appendix C).

VIII.  Marketing Efforts – Summer 2005

Marketing efforts.  While awaiting the much-delayed implementation of the Dublin-Pleasanton pilot test, during roughly the period of Summer 2005, I made a “marketing push” to find other entities – universities, transit systems, large employers – that could potentially be interested in trying a dynamic ridesharing program. 

The marketing pitch was that we (an independent, non-profit corporation, which I hoped that prospective customers would not realize consisted so far of a single person) would operate the dynamic ridesharing system at their site for six months at no cost to the participating institution.  I set a goal of making 100 contacts with likely prospects, with the expectation that my chances of success were perhaps one out of that 100.  I created a two-page, single-sheet “brochure” (see Appendix C.)

I have known all along that I am not a “people person,” let alone a marketing person, and I’m sure some of my prospects realized this all too soon (a bit more frustration/impatience in my tone than “have a great day!”).  I tried my best.

There were many who initially expressed interest, but (as I’m sure professional marketers know), it was very difficult to translate initial interest into anything concrete.

An important obstacle is that no one wants to be the first – at least not in the settings to which I was directing my marketing.  “Where else is this working?” is a typical, early question.  Those with a bit more knowledge could be an even more difficult sell.  As one transportation consultant to Silicon Valley companies emailed me:

In the past couple years, I've been contacted by several other people trying to offer a similar service as yours.  It's a good idea, but never seems to get past the pilot stage.  Not sure if they run out of money, time or interest or just get another job that diverts their efforts.  For that reason I won't ask any of my clients to participate in a ridematching pilot.  If a new ridematching system gets off the ground that offers significant advantages over 511.org [the Bay Area ridematching service] and other companies I know are happy with it, then I'll promote it to my companies.

Of course, given the outcome of my experiences here, that consultant was quite correct.

Then again, there seemed to be many who could reject dynamic ridesharing without getting even that far: “we don’t have parking spaces available,” and “we’ve got more than enough parking spaces” were both offered (separately) as reasons to decline interest.

Yet another reason to reject the offer of a free six-month pilot test was the issue of what would happen after six months.  Not being able to see a way to fund a successful program, they declined to start down that path.

The closest I got was with a major Silicon Valley company, whose transportation manager said, “yes, let’s do it.”  We considered several of their facilities, both in California and in another state.  We decided that their Silicon Valley headquarters offered the best opportunity, since parking was scarce there, and there were a number of car pool lanes along commute routes to the headquarters site.  I was surprised by the transportation manager’s resistance to a number of the features I considered part and parcel of the dynamic ridesharing system.  For example, the manager thought people should get a preferential parking space only when they provided someone a ride.  But over several telephone discussions I was able to persuade the manager that the parking space incentive was important, and that it was my (the system’s) job to match people into car pools.  The possibility of cheating was also a big issue – the manager thought that somehow people could avoid giving rides; again, I had to argue that the system either wouldn’t allow this, or that we would quickly find out (from the would-be rider!) whether people followed through.

So it was time to begin implementing the system.  Parking spaces would need to be made available to system users, and they would need to checked – at least occasionally – to make sure they were being used only be legitimate drivers (those who had made a ride match request that morning.)  Their Security Department was in charge of parking.  They did not want to monitor any parking spaces for this purpose.  OK, I said, we’ll have somebody check them.  No, said Security, they could not abide someone else coming on-site for that purpose.  The transportation manager agreed with me that this was neither fair nor helpful.  He tried to “escalate the issue” (in their parlance), but his boss said, “we need to be friends with Security.”  It ended there.  (This example provides evidence that government and public entities are not the only ones with bureaucratic constraints.)

By that time I had contacted and followed up with 34 different entities over a three month period.  While I still had eight “open cases” (they hadn’t said “no” yet), the odds were too long for me. 

IX.  West Oakland BART

As the Dublin-Pleasanton pilot ground its way to what I considered to be certain failure, I resolved to make one last attempt to implement a dynamic ridesharing program.  I considered a program near the Pleasant Hill BART station for the purpose of carpooling directly to San Francisco.  I was aware of a number of San Francisco-bound commuters in that area who were interested in casual carpooling, but no casual car pool location had ever gotten started in that area.  I thought a system that allowed people to meet at places of their choosing within a quarter-mile or so of the BART station would allow riders to find parking in the morning, and still be able to take BART back (and walk to their car) in the afternoon.  Thus, I wouldn’t provide any taxi rides.

I settled on a program at the West Oakland BART station for the purpose of getting to BART and avoiding parking fees.  BART had fairly recently begun charging $5 per day for spaces in the station lot, commensurate with spaces in adjacent, privately-operated lots that cost either $5 or $6 per day.  I thought this could provide a fairly strong incentive to use dynamic ridesharing, especially with an initial, promotional incentive of free-parking for a month (a $100 value, at least).  In addition, I thought marketing would be easier at West Oakland than at Pleasant Hill, since all prospective users came through the BART fare gates (in contrast to Pleasant Hill, where many prospective users currently drive to San Francisco, and are thus hard to reach in a targeted fashion).  Finally, dynamic ridesharing at West Oakland offered a clear environmental benefit in reducing driving and freeing up parking spaces while still putting people on transit.  A program at Pleasant Hill would doubtless take some people off transit.

A.   Computer and phone system revisions

The incentives for dynamic ridesharing to West Oakland BART are entirely monetary.  Since there are private lots that can freely adjust their fees, there is no shortage of parking spaces.  As I mentioned, as a promotional incentive we could offer people free parking.  In the long run, it was plausible that the dynamic ridesharing program could offer half-price parking – that is, assuming that both riders and drivers paid a share, and that average occupancy was two people per car (and ignoring other expenses such as taxi rides home and running the system!).  Obviously, half-price parking did not produce a sustainable business, but for demonstration purposes I thought it would be adequate (that is, I would lose money at a slow-enough rate that I could keep it going for six months or a year).

In order to accommodate a monetary-incentive system, I designed a “fee-rebate” structure for use of the dynamic ridesharing system, and designed an on-line “My account” page so that the system and users could keep track of their position.  I also re-implemented credit card process capabilities, both as a method of identifying legitimate users and to potentially charge people fees.

The fee-rebate structure to implement half-price parking worked like this: drivers would receive $1.25 for offering a ride in the morning, and another $1.25 for offering a ride home.  Assuming they pay $5.00 per day for parking, those “rebates” would cover half their parking fees.  To encourage would-be drivers to instead take a ride in the morning, the morning ride would be free.  If the dynamic ridesharing program provided a ride home, it would cost $2.50.  For those riders who took a ride in the morning, the dynamic ridesharing program would pay the cost of a taxi.  Thus, a rider’s costs per day would also be $2.50, compared to the $5.00 they would have spent on parking had they driven.

In order to offer free parking during a promotional period, an additional rebate of $2.50 per day would be given to each user.  This would give drivers a total rebate of $5.00, and for riders it would offset the ride-home fee.

I had planned to start the West Oakland BART dynamic ridesharing service in Spring 2006, but at about this time I noticed more of the results from the Dublin-Pleasanton pilot program where it appeared that riders and drivers were reluctant to make the “social contact” – the phone call – to confirm their arrangements.  (“I waited for 20 minutes and they never showed up.”)  With a suitable telephone system I thought I could encourage/force users to take that step.  I could have drivers and riders contact each other through the telephone “switchboard,” and make rebates contingent on that.  This would also solve another problem: people were reluctant to share their cell phone numbers.  Since all contacts would be made through a central number, users would not need to know each other’s cell phone numbers.

The telephone system I had been using was not well-suited to such a switchboard role.  The system used a dedicated computer with a “telephony board” that connected to four regular telephone lines.  The system was not very good at connecting inbound and outbound lines, and further, telephone lines (at about $20 month) were in fact my major operating expense, so the necessary doubling of the number of telephone lines needed was an onerous requirement.  A bit of research indicated that since the time I chose this original telephone system (in 2001), new, inexpensive technology – voice over internet protocol (VOIP) – had become widely available.  This required, however, a complete re-implementation of the phone system, which I did over the summer of 2006.  With the new system my services provider allows the equivalent of eight telephone lines – four incoming and four outgoing calls, simultaneously – for $11 per month.  The “switchboard”/IVR system is handled by the same server that hosts the web site; no specialized telephony hardware is needed.

B.   Marketing efforts

My principal marketing approach was to hand out flyers to passengers arriving at West Oakland BART in the morning and departing in the evening.  (The flyer can be seen here.)  Given my I-80 corridor experience, I knew this would involve some effort, so I hired a UC Berkeley student to help with this.

My minimum goal at West Oakland was to have 100 registered users before starting operations (out of 3000-plus people entering that station daily, the vast majority of them drivers).  We handed out approximately 700 flyers.  We also handed out a coupon that promised a $10 BART ticket when people  registered on-line.  Two people signed up.  I noticed that several people started registration, but balked when they got to the part of the form that required confirmation of a credit card.  I changed the web-site settings so that no credit card entry was necessary, and created a new coupon that offered a $30 BART ticket when people registered on-line.  We handed out another 300 or so flyers.  Two more people registered. 

My optimistic hopes that the offer of a month of free parking would gather users were in fact wildly optimistic.  I guessed that people didn’t understand the program; at any rate, I wanted to at least discover why people weren’t interested.  I designed a “survey,” which was really just an excuse to engage commuters.  The survey form, which we asked commuters to fill out (promising a $10 BART ticket as a reward if they did so), asked a few questions about whether they had driven or taken transit that morning, and what time they had arrived.  It then asked them to listen to our explanation of the dynamic ridesharing program, and then requested their response to a key question: “what dollar amount per day would get you to participate in the start-up of this program?” 

This showed that people indeed previously didn’t understand the program.  With the explanation, about half of those surveyed said they’d be willing to participate, and named a “price” most commonly around $5 per day (which is the incentive I had planned).  People received a $10 BART ticket if they took the survey and responded to a follow-up email that confirmed their email address.  Approximately 60 people did so who had also said they were willing to participate in the start-up of the program.  These people were offered a $20 BART ticket to take the next step: register on the web site.  Eight of them did so.  After a month of effort we had 12 registered users.  I gave up.

I believe a key missing ingredient in the West Oakland case was the imprimatur of an established organization.  “Who is Ride Now?” was a common question.  That the marketing effort was limited to one avenue – a couple of people handing out flyers – probably emphasized the less-than-solid appearance of the enterprise.  I realized within the first few days that the marketing effort was impossibly more difficult than I had anticipated.  I approached/begged BART to run messages promoting the dynamic ridesharing program on the train-announcement signs, as they had done at Dublin-Pleasanton, but they were unwilling.

Appendix A: Review of Previous Systems and Designs

[Adapted from “Proposal for a Bay Bridge Electronic Ride-match System,” January 1999, available in Appendix C.]

This appendix provides brief descriptions of previous efforts to facilitate real-time ride-matches. In summary, none of these efforts were at all successful, with a number of evaluations concluding that a real-time ride-match system cannot be successful due to a number of factors, including primarily the reluctance to share rides with strangers.  Of course, the existing casual car pool system in the Bay Bridge corridor belies this conclusion.

These previous efforts do point to the necessity for adequate incentives, and sufficient marketing to achieve adequate ride-match success rates.  Another lesson that might be drawn is that the particular technology implementation is not a factor in the success of these efforts.

A.   Sacramento

A real-time ride-match service was tested in Sacramento in 1995.6  Over the evaluation period only ten to 15 match requests were processed, and no ride matches were formed.7  The evaluation concludes that the system “Failed on two basic counts: in recruiting sufficient drivers to provide rides in this service, and in marketing the service to potential riders.” The driver pool – 360 drivers – was inadequate to generate matches.8

The service was not automated, but relied on a telephone-operator-based system.  There was only one HOV incentive available to Sacramento-area drivers, and surveys indicated that participants were largely unaware of or unconcerned with this incentive.9

Focus groups were conducted before and after implementation of the system. Security registered as very important concern.  “By far the most significant barrier to participation is the concern for physical safety.  Even if they are provided with what they believe is critical advance information, people are extremely hesitant both to get into a vehicle with a stranger and to allow that stranger to see where they live.”10

Project costs were reported to be: $806,000 (systems: $489,000; personnel, marketing, other: $317,000), plus $142,000 for evaluation11

B.   Los Angeles

The “Los Angeles Smart Traveler Field Operational Test” included an automated ride-matching service.12  This service was based on an Interactive Voice Response (IVR) system accessed via an 800 number.  Through pre-registration, users provided their trip origin, destination, and departure time.  Via telephone, users could enter changes in preferred travel times, receive a list of potential ride-matches, and record a message that would be automatically delivered to potential ride-match partners.

Thirty-four people per week, on average, used the system. Of those, most users were seeking regular rideshare partners, rather than a one-time match.13  Only 20% of requests for rides got a positive response.14  Surveys indicated that “most people are not inclined to give or take rides from people they don’t know.”  The evaluation concluded, “the market for one-time or occasional ridesharing is not sufficient to support a service like [this].”15  While over 50% of people seeking ride matches with the Los Angeles rideshare agency indicate they have variable work hours, the evaluation finds: “While this might suggest an opportunity to experiment with the ‘one day only’ service, it is more likely that the majority would chose to drive alone if they know in advance that their hours will differ from normal.”16

Costs were reported to be $145,000 for development and marketing, and $28,000 per year for operations.17

C.   Bellevue

The Bellevue Smart Traveler project, a 1995 effort of the Washington State Transportation Commission, set out to design and test a ride match system in the city of Bellevue, Washington.  The project used telephone and pager technologies to facilitate the formation of dynamic car pools, provide traffic information, and provide information on other transit options.

As an early “proof of concept,” the Bellevue project showed a large degree of acceptance for technological solutions to creating dynamic ride-matches, but according to the project report, did not “achieve the behavior changes that would make it a viable transportation alternative.”18  HOV lanes were not available in the Bellevue area during the test period.  At most, the program had 53 registered users, thus there were “insufficient rideshare choices.”

The project’s reliance on pagers as the technology of choice may have hampered its success.  The evaluation report suggests that an Internet based matching system would improve success rates by allowing participants to “more easily obtain and respond to rideshare information.”19

D.   Seattle

The “Seattle Smart Traveler” project was funded by the Federal Highway Administration to demonstrate dynamic rideshare matching.20  This test used the Internet as the exclusive interface for participants. Users entered information via the World Wide Web and received match information via e-mail.  The users then contacted one another via telephone.

The system was implemented in March 1996, serving University of Washington staff and students. Through November of that year there were approximately 200 active users, on average.  Approximately 100 ride match requests per month were processed by the system.  Of these requests, 39% resulted in successful matches.

The system operated in parallel to the traditional rideshare program in the area. The test found that there was very little overlap in populations of users.  The Internet matching system attracted a different population than the traditional ride-matching program.

The web interface used a hierarchical structure of drop down lists to determine the geo-coded location for the origin and destination of a request for a ride-match.  Several thousand city intersections and landmarks were hand-coded by students working on the project.

E.   Sydney

A real-time ride-matching service that uses telephone (Interactive Voice Response) as the primary interface was implemented in Sydney, Australia in November 1997.21  While market research indicated strong interest in the service – 18% of motorists expressed a willingness to join and 87% said the were prepared to pay the annual membership – and the launch of the service was accompanied by good publicity, results were disappointing.  Approximately 500 people were registered as users in 1998.22

The system was designed as follows: To join the system a prospective member fills out a membership form including a valid car driver’s license number along with relevant personal details (address and home, office and mobile telephone numbers, gender and date of birth).  Personal preferences are also checked on the membership application.  These preferences are for age group, smoking/non-smoking, male/female, and car radio music tastes.

To make a trip request the member dials the Easy Share computer, which has a menu driven voice-mail type front end. The member provides the origin and destination zip codes for the proposed trip, the time by month, day, hour and minute, and the desire to be driver or passenger or either.  When a match is found the member is given the other member’s name and phone numbers. They then contact that member to arrange a convenient pick-up point.

Zip codes were chosen as the prime location identity as they were publicly available and easily input by members into the IVR system.

The scheme has built-in security aspects including membership number and PIN.  Members are required to forward a signed form with identification before being allowed onto the system.



Appendix B. Other Dynamic Ridesharing Systems [coming]

A. “TECAPSY,” - European Union

B. “M21” - Stuttgart, Germany

C. “Social Traffic” - Amsterdam, Netherlands

D. “NuRide”

See www.nuride.com.

Appendix C. Annotated Links

Proposal for a Bay Bridge Electronic Ride-match System.  Environmental Defense Fund, January 1999.  This was my first attempt to garner interest in dynamic ridesharing.

Electronic “Instant” Ridematch and HOV Lane Time Savings: Simulation Modeling for the San Francisco Bay Bridge Corridor.  This is the paper I submitted to the Transportation Research Board in 2000.  As mentioned in the text, the paper was rejected as “not useful.”

FAIR Lanes and Dynamic Ridesharing.  This is the proposal that was submitted to the Federal Highway Administration in November 2001.  The proposal includes two parts, that were separately implemented: (1) a study of congestion pricing; (2) the dynamic ridesharing pilot project.

Ride Now brochure.  This is the single-page, double-sided brochure that I created for my efforts to market a trial of dynamic ridesharing to various companies and institutions.

RideNow Evaluation Report.  This is the final report on the BART Dublin-Pleasanton pilot test provided by the consultants to the local agency as part of the Federal Highway Administration-funded project.  (I do not know why it is marked “draft.”  As far as I know it is the final report, as available on the agency’s web site, here: www.accma.ca.gov/pages/HomeCongestionMgmt.aspx.)  I have not read this report, nor will I.  (I feel I owe at least this much to my physical and mental well-being.)

West Oakland BART flyer.  The is the flyer we handed to passengers at the West Oakland BART station.

Endnotes

1At least two explanations are commonly offered for the origin of the term “slugging:” (1) riders are “slugs” because they slow, lazy (while drivers are “body snatchers” since the riders might otherwise have used public transportation); (2) “slugs” are fake coins that could be used in transit fareboxes (likewise reflecting the riders’ defection from public transportation).

2This analysis does not suffice to answer the question whether or not casual carpooling is a good thing.  Clearly, there are benefits to casual car pool riders and drivers that would have to be weighed against the costs and benefits to others.

3This calculation only illustrative, of course.  Some users may not otherwise have driven.  Marketing costs, and initial and ongoing administrative costs are missing from this calculation.  But the vision is that dynamic ridesharing can be extremely cheap compared to shuttle buses or parking alternatives.

4But wait, there’s more! (I should have stopped here, but I’ll make the product of an active mind with plenty of time to think about things available to diligent footnote readers.)  By allowing more people more flexibility in taking advantage of car pool lanes, utilization of these lanes can be increased, and congestion reduced.  In fact, dynamic ridesharing offers an alternative to freeway expansion, that can be implemented in a fraction of the time and at almost no cost compared to new lane construction.  This results from the ability to use dynamic ridesharing to convert existing lanes into car pool lanes.  This is something that cannot ordinarily be accomplished, because of the immediate, negative effect on congestion.  The congestion effect can be avoided if solo drivers are allowed to use the car pool lane, provided that they make a ride match request.  (Since the dynamic ridesharing system can know the license plate numbers of users, there is an enforcement mechanism.)  There may be a need to ration use of the car pool lane if there are not enough matches, but this too could be accomplished.  These features allow the car pool lane to be fully utilized, yet maintain free-flowing speeds.  (Some will recognize this as a variant of a HOT – “high-occupancy toll” – lane, with a lottery instead of pricing.)  Finally – this was suggested to me by someone else – dynamic ridesharing could “reduce social alienation.”  I didn’t think of it that way, but I did think it would only be a matter of time before we could celebrate our first “car pool marriage.”  (If these thoughts are the 1% inspiration, then the 99% perspiration is large indeed.)

5Yes, the recommendation for a re-start was accepted in January.  The re-start occurred 2½ months later.

6Evaluation of the Sacramento-Area Real-time Rideshare Matching Field Operational Test: Final Report, Raghu R. Kowshik, Paul P. Jovanis, Ryuichi Kitamura, California PATH Report to Caltrans 96-C5, February 1996.

7Ibid., p. vii.

8Ibid., p. x.

9Fewer than half the participants were aware of the Highway 99 HOV lanes, and only about one-quarter of those considered the HOV lanes important in their decision to join the ride-match program. Ibid., p. 28.

10Ibid., Appendix G, “Real-time ridesharing focus groups,” Executive Summary.

11Ibid., Appendix E.

12Los Angeles Smart Traveler Field Operational Test Evaluation, Genevieve Giuliano, Randolph W. Hall, Jacqueline M. Golob, California PATH Research Report UCB-ITS-PRR-95-41, December 1995. The test also included travel information kiosks and software for PC-modem access to travel information.

13Ibid., p. 5.

14Ibid., p. 130.

15Ibid., p. 5.

16Ibid., p. 119.

17Ibid., p. 71.

18Bellevue Smart Traveler: Design, Demonstration, and Assessment, M. Haselkorn, et al., Washington State Transportation Center, August 1995, p. xvii.

19Ibid., p. xviii.

20Seattle Smart Traveler, D. J. Dailey, D. Loseff, D. Meyers, and M. P. Haselkorn, University of Washington, Transportation Research Board Annual Meeting, January 1997.

21Social Equity In Transport, Congestion Pricing And The Role Of Car Pooling, Ros S. Trayford and Charles A. Karl Jr., Easy Share Australia Pty Ltd, and James Y. K. Luk, Nanyang Technological University, Singapore, International Conference on Transportation, Singapore, 1998.

22Charles Karl, personal communication, October 1998.