e-Transit: Electronic Business Strategies for Public Transportation, Volume 4: Advanced Features of Transit Websites (2003)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

2-1 2. Executive Summary In 2001, the Transit Cooperative Research Program (TCRP) of the Transportation Research Board initiated Project J-09, a multi-task study of the potential for electronic business activities in the transit industry. Called “eTransit: Electronic Business Strategies for Public Transportation,” its seven Task Orders address a range of subjects from application service providers to Web-based training. The results of the project team’s research are organized into the following sections of this report: • Section 1: Preface – How to Use this Electronic Document; • Section 2: Executive Summary; • Section 3, Research Opportunity and Objectives; • Section 4, Methodology and Results; • Section 5, Case Studies of Itinerary Planning Systems; • Section 6, Real-Time Information, E-Mail Notification Systems, and Customer Relationship Management (CRM); • Section 7, Technology Considerations; • Section 8, Cross-Cutting Issues; and • Section 9, Notable Project Innovations and Opportunities for Further Research. Section 1: Preface --How to Use this Electronic Document This section of the report explains that the TCRP eTransit project was structured so that Task Orders would produce eDocuments for rapid distribution via the Internet. This eDocument is designed to provide live links to Web pages, on-line documents, and e-mail messaging. Section 2: Executive Summary Section 3: Research Opportunity and Objectives The third section of the report provides an overview of the research opportunity. It also describes how the Work Plan was modified to focus on advanced features of transit Web sites, in recognition of earlier Web site evaluations, both transit and non-transit, that have already provided basic analyses about design, content, and site navigation. TRB’s overall objective with this Task Order, which focused on using the Internet to provide customer information, and the other eTransit Task Orders is described below. “The declining costs of communications, data storage, and data retrieval are accelerating the opportunities spawned by the Internet and other information and communications technologies. Choosing and sequencing investments in technologies, processes, and people to reduce costs and increase productivity present challenges to the transit manager, who must weigh the costs, benefits, and risks of changing the ways services are delivered. TCRP's eTransit research program will identify, develop, and promote research to maximize the benefits of e-commerce and other new technology applications for public transportation and

2-2 mobility management (and) to provide flexible, ongoing, quick-response research designed to bring electronic business strategies to public transportation and mobility management.” Section 4: Methodology and Application The transit Web site research methodology was developed to identify and report on the potential of using Internet resources in the transit industry to provide customer information on the Web. The resulting research findings are intended to assist the transit industry and its constituent agencies in making decisions about how to take advantage of its Web investments, improve customer information, and ultimately enhance overall customer service. The project’s focus has been to create an initial knowledge base for transit agencies that are planning on enhancing their Web sites, with special attention to best practices and lessons learned. The telephone surveys of selected transit agencies were initially designed to simply summarize the use of advanced Web site features and to provide the data needed for both the cross-cutting discussion of issues and best practices in Section 8 and the discussion of notable project innovations and next steps in Section 9. However, the project team obtained a great deal of agency-specific information that it felt would be useful to the readers. As a result, the agency summaries were expanded into case studies so that the reader would have access to more detailed information. Two primary objectives of gathering this information are worth highlighting. First, the project team focused on obtaining information from transit staff with policy-level and/or day-to-day responsibility for an agency’s Internet customer information strategy and deployment. Second, the project team sought to obtain information about a diverse set of Web sites – representing a range of agency types – large and small, urban and rural, single mode and multi-modal – and involving both complex and simple approaches to advanced Web site feature development. Specifically, the task order involved the following steps: • Review prior institutional efforts and perform a highly targeted information search; • Select transit agencies whose advanced Web site features were worth investigating; • Develop a telephone survey for transit agency representatives; • Conduct detailed telephone surveys with transit agency representatives; and • Synthesize telephone survey information with previous research phases of the project. Section 5: Case Studies of Itinerary Planning Systems Eight case studies were developed from detailed Web site reviews and extensive telephone interviews with transit agencies that have automated itinerary planning systems (AIP) on their Web sites. AIP systems were the most common advanced Web site feature identified by the project team. The interview targets were selected from a pool of approximately 20 known AIP sites in the United States at the time of the research, and provide a wide variety of experiences with and approaches to providing an AIP service to customers.

2-3 Included in this Section are case studies of AIP services offered on the Web sites of: • The San Francisco Bay Area Metropolitan Transportation Commission (MTC); • Ventura County Transportation Commission (VCTC); • Washington Area Metropolitan Transit Authority (WMATA); • San Diego Metropolitan Transit System (SDMTS); • Twin Cities Metro Transit; • Southeastern Pennsylvania Public Transportation Authority (SEPTA); • Anchorage Public Transportation (APT); and • Greater Manchester Public Transport Executive, United Kingdom (GMPTE). Although at first glance many of the AIP systems look that same, several key differences are highlighted in Section 5, including: whether all customer input is on a single page or not; design of user interface for inputting origins and destinations; the type, detail, and number of itineraries provided; and whether the output page provides tools that allow customers to easily modify their trip preferences. Section 6: Real-Time Information and E-Mail Notification Real-time transit service information is becoming available to transit agencies around the world. One of the primary uses is to provide customer information, often via Web sites. Early transit vehicle location systems, such as those implemented in Kansas City, Missouri, Seattle, Washington, and London, England, used milepost-based infrastructure. These systems are now being supplemented and/or replaced by systems utilizing Global Positioning Systems (GPS). One advantage of GPS-based vehicle tracking is that position data is typically more accurate and more reliably converted into useful customer information. Section 6 also discusses Customer Relationship Management (CRM) systems in transit, including the use of e-mail notifications. The concept of CRM is well established in the commercial, eCommerce marketplace. These systems provide a wide variety of information about a customer’s product needs, prior and planned purchases or activities, and the potential for purchasing additional products. The CRM concept is that, by better understanding customers and addressing their needs, an organization can eventually increase sales to those customers and thus increase profits. CRM has burgeoned in popularity as the Web has grown more important in the general economy. The challenge in adapting CRM to transit, however, is to utilize this profile information at the individual customer level. At its most basic level of CRM, a transit agency could allow users to customize their view of the agency’s Web site, which would provide easier and personalized access to a customer’s preferred features. A transit CRM system might also provide alert messages about transit status, traffic incidents, or promotional programs that might affect a transit customer, such as known sources of delays and alternative routes, fare pass or other programs that might save them money, etc. Several case studies in Section 6 focus on using real-time vehicle location data to provide customer information services on transit Web sites. One case study explores NextBus, Inc., a leading private sector initiative that provides real-time transit customer

2-4 information. Other agencies already have or are considering, in some cases very cautiously, adding real-time information and/or customer notification systems and possibly CRM features to their Web sites. Several agencies are listed below as examples: • MTC – real-time information integrated into its IP system, notification; • VCTC – real-time information and notification; and • WMATA – real-time information and notification. The case studies presented in Section 6, along with the primary focus of each, are listed below: • The Washington State Ferry System (WSF, real-time information and e-mail notification); • Cape Cod Regional Transit Authority (CCRTA, real-time information); • The Virginia Railway Express (VRE, real-time information and e-mail notification); • Tri-County Commuter Rail Authority, Florida (Tri-Rail, real-time information); • King County Transit, Seattle (KC Metro, real-time information and e-mail notification); • NextBus Information Systems, Inc. (NextBus, real-time information); • New Jersey Transit Corporation (NJT, CRM and e-mail notification); and • Utah Transit Authority (UTA, CRM and e-mail notification). The case studies are organized to examine the following: • System Design and Functionality • Project Objectives • Implementation Issues • Outcomes/Benefits, and • Planned Improvements. Section 7: Transit Web Site Technology Considerations The research shows that most of the analysis provided in our interviews on transit Web sites focused on the functions rather than the technology. This was especially true for the three advanced Web features, which became the focus of the research. Typically, individuals responding to the telephone surveys were in positions of policy oversight, and did not actually run the hardware and software systems involved. Therefore, Section 7 addresses general concepts and concerns related to the following technology and application issues: • Application Design, Development, and Performance Issues; • Functionality; • Privacy Concerns; • Security Concerns;

2-5 • Application Deployment; and • Customer Relationship Management Functionality can greatly affect both an application’s usefulness and how much bandwidth it requires. Consequently, it is important to consider design features both in terms of what they offer the customer and what they take away, in the form of delays. In this context, three of the major considerations for transit Web site applications include Mapping, Data Push Versus Pull, and Use of Real-Time Data. These issues are summarized below. Mapping Integrating maps into a transit Web site has both advantages and disadvantages, and was a frequent topic of discussion during the telephone interviews. In an AIP application, the map might be used to display a proposed trip or walking directions from a customer’s last transit stop to the final destination. Maps can be very helpful to the transit customer; they provide an overview of the itinerary and indicate where transfer points are located, the proximity to landmarks, etc. A map displayed on a transit customer’s Web browser can also be used as an input mechanism, similar in function to text fields for addresses, intersections, or landmarks found on AIP Web pages. Constructing the map is typically time and labor consuming. It requires the initial creation of an accurate map for the service area and then timely attention to adding new streets, subdivisions, landmarks, routes, etc. Depending upon the quality of the existing data and the frequency of changes to the local geography, this can be a significant labor burden. A second consideration when incorporating a map is the simple fact that maps require much more bandwidth than text. As a consequence, Web pages containing maps may download more slowly to the customer than those that avoid maps, especially for customers with dial-up Internet connections. Data Push versus Pull Data is said to be “pulled” when the user must request a new Web page or refresh an existing one in order to see new information. Thus if the Web site user does not make such a request, the displayed data will be static and may be out of date. This would be the case, for instance, on a real-time transit information site where the map display of vehicle locations did not update itself automatically. Until the user requested refreshed data, the old data would continue to display. In contrast, a system that automatically updated its display (either on a regular schedule or when an event occurred) is an example of data that is “pushed”; the application continuously or periodically sends new data to the client. This is the case with a real-time, Web-based transit information service, such as KC Metro’s BusView, which automatically updates the information display at frequent intervals. Use of Real-Time Data Transit schedule information can be categorized as either “planned” or “actual.” Planned (i.e., static) schedules are those published in public timetables and usually posted on a transit agency’s Web site. These are the typical basis for itinerary planning systems. Actual schedules reflect the status of current operations, such as those displayed on

2-6 monitors in transportation terminals or used as the basis for personalized e-mail services. Airport arrival and departure monitors are one example. Actual schedule data is essentially real-time in nature. Real-time data reporting relies on a data collection and processing infrastructure, such as Automatic Vehicle Location (AVL) systems, which can track vehicles and compare their actual and planned locations at selected points in time. Such information is the basis for computer-aided dispatch (CAD) systems used in the transit industry, real-time notification systems, and transit terminal displays. Real-time transit information is also becoming more prevalent on the Web. However, its integration into AIP systems has yet to be implemented. Section 8: Cross-Cutting Issues of Advanced Transit Web Site Features Sections 5 and 6 of this report present case studies of the agencies the project team selected to study advanced Web site customer information features. Those advanced functions include automated itinerary planners, real-time information display, and electronic notification systems. Customer relationship management was also discussed. Section 8 summarizes the cross-cutting issues based on similarities, differences, and trends discovered during the project telephone interviews. The telephone interview outlines were structured to obtain information on the key issues of Section 8, which include: • Agency Web Project Objectives; • Future Promise; • Value Creation; and • Implementation Issues and Best Practices. Agency objectives for the web projects Impact on Call Centers. Most of the transit agencies interviewed stated that creating Web-based AIP, RTD, and EMN systems was at least partly motivated by a desire to lower the workload on call center agents or prevent the need to increase staff. All of the agencies reporting this objective stated that it had most likely been achieved. In some cases, the benefits had been quantified but in most, factors such as steadily increasing ridership make quantification impossible. Impacts ranged from fewer calls to shorter customer waiting queues to fewer lost calls to changes in the nature of calls received. Improving Customer Service. Another common theme expressed was that Web-based customer information projects are just one part of an agency’s overall customer information and customer satisfaction strategy. In particular, several agencies reported that their advanced Web site features were helping to minimize the uncertainty of using transit, suggesting a positive impact on ridership. Other agencies simply said that the new services were very well received by their customers. Enhancing Information Access. Most agencies highlighted the value of making transit information available to customers 24 hours per day, seven days per week, especially since telephone agents cannot be available at all time of the day without significant budget increases. Similarly, many transit agencies expressed the importance of providing

2-7 “instant” information access supported by the Internet, which minimizes any delay associated with contacting a transit agency’s call center. Where agency representatives alluded to the digital divide, a potential access issue, they typically provided statistics showing that a high percentage of their customers have Internet access. Ensuring Consistent Customer Information. Several agencies, especially those with AIP systems, noted that call center agents employ considerable subjectivity when providing itinerary information. With the implementation of an AIP system, either at the call center or on the Web, transit agencies expect that trip itineraries will be calculated with more consistency. The project team believes this objective is especially important in large, multi-modal regions, where there are multiple itinerary options for the same trip and it would be difficult for call agents to retain or quickly access the breadth of schedule information required for complex trip itineraries. Future promise Multiple Customer Markets. Most agencies indicated that their Web-based information services were designed to serve different market segments, including regular commuters, less experienced transit customers, tourists, and potential new customers. Indeed, agencies with more than one advanced feature often reported that one Web-based service was more useful to certain market segments while another was used by other customers. For example, commuters who typically follow the same itinerary may not require AIP assistance as much as they need real-time information or electronic notifications. Impact on Call Centers. As discussed above, the impact on call centers was a primary objective for the transit agencies involved in this study. The project team believes that additional promise will be realized by those agencies that develop ways to accurately measure the impacts of advanced Web site features, much as Washington State Ferries does. WSF’s measurements compare trends in call center demand to use of the agency’s Web site. Other transit agencies that have the resources could likely benefit from similar evaluation. Value Creation Intrinsic Value: More than half of the agencies surveyed by the project team indicated that their advanced Web site tools had intrinsic value, in addition to fulfilling the objectives of implementation. A frequently mentioned benefit was that these services are effective marketing tools. Other agencies said that providing these features improved an agency’s public image by showing its customers and the community that it was adopting the latest technologies to improve customer service, similar to those used in the private sector. Finally, many agencies reported that the advanced Web site features used by other departments were valuable additions to the agency. Question about Quantifying Value: The telephone surveys did not reveal a consistent method for quantifying the “value” created by real-time information programs. However, existing literature on the subject establishes that waiting times are “perceived” to be shorter when the uncertainty of arrival times is eliminated, even in the case of learning of a delayed bus. An equally important observation is that some agencies that offer a single advanced Web site service expressed doubt that adding another feature would be valuable and/or feasible.

2-8 Saving Training Resources: An interesting observation was made in Philadelphia, where the managers have insisted that the user interface of the system used by the telephone operators be as simple and user-friendly as possible. Before the implementation of the new IP system, operators were trained for several weeks, and only became proficient after a period of months or even years, because much of the itinerary planning still involved paper timetables. Now, after a simple training program, the telephone operators become proficient in using the system within several days. Using Tracking Information: The case study on UTA showed how one agency is actively using tracking information to enhance its service planning functions. Several survey respondents stated that the data is biased by the characteristics of Internet users. However, proponents of using tracking information, especially from AIP systems, noted that service planners typically gain input from a wide variety of non-random sources (such as site-specific public meetings, customer complaints, etc.). These proponents pointed out that information collected from typical, non-random service planning sources is no different than what might be collected from an advanced Web site feature. Perhaps the middle ground of using both sources would enrich the knowledge base from which transit service changes are made. CRM Potential: Even though it may be too early to evaluate the impact of the new transit CRM programs, the initial result reported by agencies appears promising. Moreover, many of the agencies included in this research already have components of CRM with their subscription features for notification systems or customized real-time information. Implementation Issues Most of the implementation issues that emerged from the project team’s research proved themselves controversial topics, eliciting strong perspectives from the transit agency participants. Section 8 discusses the following implementation issues: • Itinerary planning data input • Origin and destination input and error handling • Maps and mapping • Specificity of trip itineraries • Quality control • Role and use of real-time information on transit agency web sites • Predicting arrival times, and • Tracking usage and performance. Select issues are summarized below: Origin and Destination Input and Error Handling. The wide variation of AIP systems studied during this research showed two major problems in their landmark functions. First, the project team found a wide range in the sensitivity of AIP systems to accurately recognize landmarks, even major landmarks that are widely recognized (e.g., the White House, the Empire State Building). In one case, a landmark was chosen from the system’s own map, put in as the origin, and still not recognized. Many specific examples

2-9 could be given to illustrate this point. Fortunately, a theme expressed during many of the project telephone interviews was the recognition that landmark lookup components of AIP systems needed improvement. The other shortcoming was how well transit agencies’ Web-based AIP programs catch errors in a way that allowed customers to easily fix the mistake. Often, the error messages are difficult to interpret. However, some agencies do an excellent job of handling input problems. Maps and Mapping. There is no area with wider variation in management philosophy than the role of maps and mapping in the AIP process. At one end of the spectrum, both San Francisco MTC, and the GMPTE are moving directly to the use of GIS-based mapping for the core activities of the itinerary planning process, including the data input of trip origins and destinations via a map interface, rather than by typed or pulled down text. Similar intentions were expressed as potential system improvements by ART, UTA, and other transit properties. At the other end of the spectrum, staff at WMATA believe that maps could cause delay in the responsiveness of the system, a detriment since customers have not asked for this feature. Section 9: Notable Project Innovations and Opportunities for Further Research Section 9 summarizes what has been learned about best practices in the American experience, compares that with recent international experience, and summarizes the implications of these observations for further research in the area of advanced Web-based features in the transit industry. Notable Innovations from the J-09 Survey The J-09 survey has revealed a broad range of innovative initiatives undertaken by the American transit industry. While it is not possible to rank the importance of given features for the needs of the local community, it is possible to make some overall observations about exceptional contributions made by the American transit industry over the past six years. This section presents a number of illustrative examples of innovative solutions from the sample of projects included in the J-09 interview process. Best Practices from an international perspective The state of the art in American passenger information systems, as revealed through the J-09 survey, is briefly compared with developing patterns in the European experience, in order to better understand the need for “Further Research” in the American experience. Major new directions in passenger trip planning systems in European experience include: targeting information to specialized audiences, integration of metropolitan and long distance systems, and advances in graphics and data entry. Recommendations for further research The brief review of best case practice in the sample of American transit Web sites, augmented by the examples of new practices in Europe, leads to a recommendation for further research in eight specific areas, as follows: • Updating key developments with additional case studies; • Improving the data entry/error trapping process; • Expanding the geographic coverage of information services;

2-10 • Expanding the intermodal content of information services; • Creating information for targeted market segments; • Applying passenger information data to improve services; • Monitoring development of Customer Relationship Management; and • Coordinating with on-going studies of real time passenger information.