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.

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.

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.

Mornings:

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.

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.

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

Afternoons/evenings:

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.

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.

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.

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:

Suspend the
program.

Announce/publicize
a re-start date.

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

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

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.

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

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.

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

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.

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.