News and Events » Publications » Trapeze In The News

STN Magazine Article

By: Dan Bower, Product Manager for Rideshare Software Applications
Trapeze Group, TDM Review Volume XII, Issue II, 2004 Reprinted with permission.

Organizations that provide rideshare services, like other businesses, recognize that use of the internet holds the promise of extending services around the clock, while decreasing the staff costs of providing them. Realization of this benefit hasn't been instantaneous, but it has been achieved at a number of sites. This article describes the evolution of online ridematching, the innovations that have solved select problems and yielded advantages, a look at the current state-of-the-art and a preview of Web services under development for the future.

The Dawn of Internet Applications

The earliest uses of the Internet were the creation of static informational Web sites. These typically provided the same information as printed brochures on services, incentives, etc. Available around the clock, these simple Web sites attracted attention and answered questions that would have otherwise been handled during business hours by rideshare service staff.

Provision of rideshare matching services via the Web started shortly thereafter. In the earliest cases, the commuter completed a simple form online. The form generated an email to the rideshare agency, and the data was hand-transferred from the email to rideshare database software. A matchlist was then run and delivered to the commuter. The turn around time was typically three days if mailed to the commuter and less than a business day if emailed.

This approach had some advantages, such as flexibility in choice and location of internet service provider. No broadband internet access was required at the rideshare organization. Ridematching was still available to those without internet access through previously provided paper surveys, telephone registration, etc. It was also secure, as no Internet access existed to the actual rideshare database.

In some areas, however, there was a long lag time until delivery of results, and many Web users expect instant results. Re-entry of data was often inefficient and sometimes error prone. Refinements to this approach included direct import of data from Web registration form to rideshare software, which improved turn around time, but not significantly.

The approach also did not deal well with a large influx of demand, such as during a transit strike. During the recent threat of a transit strike in New York City, CommuterLink (a Transportation Management Association in Queens) saw a 1650% increase in registrations. Due to budget constraints, they could not move beyond the approach described above. Although their Web registration system helped, they still had to augment staff and equipment (as well as work long hours) to handle the significant spike in demand.

The Shift to a Web-Based Interface

The next development in online ridematching was to create an entirely web-based interface to a matching database located at a service providing company. Here, all of the software and data are housed at a remote location, and all functions are dealt with strictly via the web. In most such implementations, the software is not purchased. Rather, the rideshare agency pays a monthly fee for the use of the software, supporting hardware and connectivity. The first such systems were initially active in 1998 and 1999.

In an approach such as this, so long as the software, hardware and connectivity are properly configured at the service provider, capacity concerns during emergen- cies are addressed. For rideshare agencies that do not have information technology staffs and/or web oriented hardware in place, this approach also saves the capital costs of hardware and the staff time to do backups and other system maintenance.

Early implementations did not permit direct access to the database for external communications and analyses. Spur of the moment reports, mail merges (or email merges), etc., on a real time basis were not possible. A refinement that partially addresses this issue is to download a copy of the database periodically, so that queries and reports could be run from the rideshare service's own computers. For small databases, the data transfer approach is reasonably successful. Also, it does not give the rideshare agency access to directly update the live data - to maintain security, such tasks are reserved for the staffs at the software providing company.

Adding Direct Database Access

The next major development was to add a suite of Internet functionality to a locally installed rideshare database system. Here, a registration and matching system on a web server accesses a database of commuters, worksites, etc. as does the remote installation described above. However, it is installed on hardware local to the rideshare agency, and rideshare staff utilize an interface from their desktop computer to gain direct access to the database. As the database is local and common to the Web and desktop interfaces, ad-hoc access to the data is possible. Capacity during emergencies is also addressed, with the same provisos of properly configured hardware, software and connectivity. Systems such as this started coming online in 2000 in cities such as Atlanta and Denver.

During normal operations, the impact of Web-based systems depends on factors such as the penetration of the Internet to the "rideshare likely" population, the marketing of rideshare incentives, cultural acceptance of ridesharing, etc. For example, the rideshare service for the South Florida region has had their Web interface active for about half a year, and are now receiving about 15% of registrations by the web. In Minneapolis/St. Paul, where Web registration and matching has been available for two years, 13 percent of the 33,000 record commuter database has registered via the Web site. In June 2004, approximately 50 percent of the match reports were run by the commuters themselves over the Web.

A much more impressive benefit of a Web interface for registration and matching is when the rideshare service is under the stress of a surge in demand, in situations such as a regional transit strike. Two recent examples include Minneapolis/St Paul (March 2004) and Los Angeles (October 2003). Typically, the peak demand for ridematching happens just before the transit strike begins. In Minnesota, new registrations by the Web peaked at nearly 500 per day just before the strike commenced and tapered off over the duration of the strike. Web matches from existing and new registrants peaked at nearly 1,400 per day. However, as the hardware, connectivity and software was configured to handle the demand, the crunch was handled without adding any temporary staff or hardware. Including the costs of training temporary personnel, the author's estimate of the savings of having the Web interface was $15,000 to 20,000.

In the Los Angeles region, four rideshare services share common database for ridesharing, and the Web interface (www.RideMatch.info) was launched in September 2003. When the Los Angeles County MTA driver's strike started in October, the system administrator there tracked Web usage by time of day. A telling detail is Rideshare Web Site Activity that of 46,000 Web site visits just before the strike, more than half were between 5:00 PM and 8:00 AM, when telephone staff was not available. Presumably, many of these people would not have tried the phone during work hours and would have been lost. 5,890 new permanent registrations were received and, as some requested match lists more than once, 6,679 matches were delivered. As was the case in St. Paul, no extra hardware or staff was required to handle the load.

Future Innovations

And what's coming next? One ongoing development is to integrate rideshare matching services with transit itinerary generating software, so that detailed transit solutions can be part of rideshare match lists. Another is the offering of expanded hosted solutions which enable regional integration of rideshare databases. An example being implemented presently is a single rideshare database for the state of North Carolina. Different interfaces (appropriate to the needs of each group) are being installed for large employers and TMAs, the general public, and the staffs at five rideshare services, all accessed via the Internet.