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.

8-1 8. Cross-Cutting Issues of Advanced Transit Web Site Features Sections 5 and 6 of this report presented case studies of the agencies the project team selected to study advanced Web site customer information features. Those advanced functions included automated itinerary planners, real-time information display, and electronic notification systems. Customer relationship management was also discussed. This section summarizes the cross-cutting issues based on similarities, differences, and trends discovered during the project telephone interviews. The findings presented in this section are an amalgam of: • A targeted literature and on-line information search; • Detailed on-line reviews of transit agency advanced Web site features; and • Detailed telephone interviews with representatives of 16 transit agencies that the project team’s on-line Web site reviews indicated would be good participants. The telephone interview outlines were structured to obtain information on the key cross- cutting topics of the overall J-09 research. The cross-cutting topics, which form the core of Section 8, include: • Agency Web Project Objectives; • Future Promise; • Value Creation; and • Implementation Issues and Best Practices. Although applications/technology was originally one of the cross-cutting issues, the technological aspects are too complex a topic to describe in this context. Therefore, it was discussed separately in Section 7 because the technology information the project team obtained during the telephone interviews was primarily generic or unspecific. 8.1 Project Objectives The project team originally expected to identify formal strategic commitments that agencies had set to guide development of their Web-based customer information projects. However, very few of the interview respondents chose to describe their agency’s objectives in this manner. Instead, questions concerning project objectives were generally answered with simple descriptions of why the Web service was desired and/or why it was implemented. The case studies demonstrated that little variation existed in the vision of the transit managers. Nevertheless, a number of general objectives did emerge upon synthesizing the research results. 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 others factors such as steadily increasing ridership make

8-2 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 times of the day without significant budget increases. Similarly, many transit agencies expressed the importance of providing “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.69 Ensuring Consistent Customer Information Several agencies, especially those with AIP systems, noted that call center agents employ considerable subjectivity when providing itinerary information.70 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. 8.2 Future Promise One specific area of promise, which was expressed indirectly during the project telephone surveys, is maximizing investment in existing technologies. In many cases, transit agencies have built their advanced Web functions on top of other systems at relatively little additional cost. Washington State Ferries created Vessel Watch from its existing fleet management system. Similarly, Tri-Rail developed its real-time train location application from an existing train location tracking system. Another common approach involved agencies with AIP systems. Often, these systems had already been developed for call center agents, and were subsequently adapted for use on an agency's Web site, so that customers could build their own trip itineraries. In one 69 For a brief definition of digital divide and links to studies on the subject, visit the Whatis.com Web site at http://whatis.techtarget.com/definition/0,,sid9_gci214062,00.html. 70 This, of course, is not necessarily a bad thing, since experienced call center agents may be able to provide itineraries that cannot be duplicated with AIP logic.

8-3 case, the Web version of a transit agency AIP turned out to be superior to the customer agents’ networked version, and is thus sometimes used in lieu of the original desktop application. WMATA is taking this concept a step further by adapting its itinerary planning system to an Interactive Voice Response (IVR) telephone information service which is intended to enable customers to obtain automated itineraries if they do not have Internet access available. Transit agencies should be encouraged to look at existing systems, such as sources of real-time information, and determine if Web-based advanced customer information services can be developed using previous investments as the basis. 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. On the other hand, less experienced transit customers have a greater need for trip planning assistance. Indeed, several agencies indicated that having Web sites and advanced Web site features was the best way for new customers to learn about transit services in that area. This finding may indicate that AIP systems should be designed for customers unfamiliar with a geographic area and its transit network. One implication of this approach is that the method of entering origins and destinations is critical. More particularly, landmark identification should be clearly specified, as was described in the SEPTA case study in Section 5. (Landmark issues are discussed further below.) Other agencies noted that providing maps for origin-destination input and itinerary output is also very important if the resources are available. The project team suggests, however, that in the larger metropolitan areas characterized by multi-modal, multi-agency services, even regular transit customers could use features that in other transit systems would be designed for other market segments. Impact on Call Centers As discussed above, 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. Several of our survey participants noticed a difference in the content of the phone calls received. In cases where new strategies, such as automated voice recognition, have been implemented, the calls still going to the live operators tended to be more complicated than before. Simple calls asking “What is my bus schedule this month?” decreased, while those needing human interaction became a greater proportion of total inquiries.

8-4 Using Data from Advanced Web Site Features for Service Planning Several agencies contacted for this study use or are considering using data collected from advanced Web site features for service planning purposes. The best example discovered during the project research was UTA. As discussed in Section 6.8, the agency uses information it gathers from both its CRM information system and its AIP system. Even without connecting certain data sets to personal information, UTA can evaluate groups of common origins and destinations, as well as which routes the AIP included in its itineraries. This information can help service planning determine whether the routes are efficient and where changes might be beneficial. UTA is also able to do cross-sectional studies and learn how people are using transfers in order to develop more efficient services. The other CRM site, created by NJT, does not utilize the My Transit data for service and other management planning, butthe telephone interview suggested that the agency might eventually consider doing some demographic analysis with this information. It is also possible that NJT could use this information for some forms of service planning, although this use has not yet been identified. CRM Transit agencies expressed widely mixed perspectives regarding customer relationship management. Even agencies that have notification programs, which inherently involve elements of CRM customer databases (because they entail subscribing, providing personal information, and selecting notification preferences), do not see it having great potential value71. In some cases, agencies believe that their existing services render CRM unnecessary. In other cases, the project team found agencies believed that implementing CRM would be extremely costly, a position that appears unfounded based on the costs reported by transit agencies that had already developed CRM Web sites. Concerns about the costs for CRM may also be influenced by the high cost of complex enterprise CRM software used by traditional private business. (See the discussion of CRM in Section 7.6.) Nevertheless, as discussed in Section 6, NJT and UTA have excellent CRM sites that provide benefits to the agencies as well as their customers. Similar CRM projects are under consideration at MTC and KC Metro. 8.3 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. 71 The nature of KC Metro's MyBus feature involves CRM-like customization, although customer preferences are not recorded on the agency's system.

8-5 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. Existing literature on the subject is highly influenced by early results from London’s Countdown project, which provides real-time bus arrival predictions to individual bus stops throughout the city. That literature establishes quite clearly 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. These general observations have been reinforced among North American transit agencies. Equally important, some agencies that offer a single advanced Web site service expressed doubt that adding another feature would be valuable and/or feasible. In the San Francisco Bay area, MTC feels that trying to integrate 25 transportation providers to provide real- time information is a much lower priority than improving its AIP capability. 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. The Regional Transportation Authority, which serves the metropolitan Chicago area, has reported similar savings in customer agent training, although that agency was not part of this study. 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. Several agencies have measured the value added by advanced Web site features. As discussed in Section 6, NJT experienced a reduction of lost calls to its call center from an average of 7-12% of all calls to approximately 2%, as a result of implementing its advanced Web site features,. In San Diego, call center telephone inquiries reportedly fell between 15-18%. WMATA reported that its AIP system, RideGuide, has helped keep call center staffing levels constant even as total system ridership has grown considerably. Moreover, WMATA, which used to record approximately 15% lost calls, now believes the agency loses no calls. The reader should keep in mind that, consistent with all such observations, the extent to which decreases in call volume are attributable to advanced Web site features has not been confirmed.

8-6 CRM Potential Salt Lake City reported that over 5,000 customers registered for UTA My Way just after it was introduced in 2001, with that number rising to 9,000 during in the first two months of 2002. NJT’s My Transit CRM program registered over 8,000 customers in its first half year of operation. UTA is sure enough of its CRM feature that it is planning to improve the service by enabling customers using the Web site to communicate directly with the call center for help. 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. 8.4 Implementation Issues and Best Practices Most of the implementation issues that emerged from the project team’s research proved to be weighty topics, eliciting strong perspective from the transit agency participants. The implementation issues discussed in this section are as follows: • 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; • Predicting Arrival Times; and • Tracking Usage and Performance. Itinerary Planning Data Input According to the project telephone interviews, most transit agencies have been directly involved with designing the entire itinerary data entry process and customer interface. Many agencies reported using some form of market research and/or direct feedback from customers in this effort. The majority of agencies not only used a Web site development firm during the process, but also stated that more work needed to be done to improve the this part of their AIP systems. The project team observed significant variation among agencies during its on-line Web site reviews. Many of these data entry approaches can be viewed in the Figures in Section 5. WMATA and KC Metro use only one input format; the AIP system differentiates between an address, an intersection, and a landmark. Twin Cities Metro provides three radio buttons in the origin and destination sections of the input form that, when selected, change the text input fields (as shown in Figure 5.25). GMPTE’s system tells the customer that there is a word-search function and encourages the customer to submit a word to start the search process. SEPTA's AIP system does not inform the customer that true addresses are not recognized, but includes an error tapping routine that makes this characteristic clear. The UTA system immediately shows the customer that

8-7 several categories of landmark identification are ready to be accessed in a convenient drop-down format. Origin and Destination Input and Error Handling When an AIP system allows a customer to use landmarks as the origin or destination of an itinerary, several problems can arise. The wide variation of AIP systems studied during this research showed two major problems in the landmark functions of these programs. First, the project team found a wide range in the sensitivity of AIP systems to accurately recognize landmarks, even major landmarks that are generally known (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 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. Such fixes could include having reasonably anticipated alternate listings of individual landmarks linked in a database so variations could be found. For example, an AIP could “ask” a customer who had put in “Empire State” or “Empire Building” as a destination if he/she meant “The Empire State Building”. One feature found in several AIP systems was grouping similar landmark types. As shown in Figure 5.7, the Ventura County Transportation Commission allows its customers to choose from three different landmark categories: Ventura County locations, Southland locations, and transit nodes. Other AIP programs take this a step further. One new AIP system recently designed for the Pioneer Valley Transit Authority (PVTA, Springfield, MA), which was not included in any of the case studies, has separated landmarks into 12 categories and shows a listing of the landmarks in a category once the user has selected a category. This approach is shown in Figure 8.1. Often, the logic used for origin and destination lookup, whether by address or landmark, was not clear to the project team. This may suggest that the typical transit agency customer would have difficulty figuring out what he/she had done wrong. The second landmark function shortcoming was how well transit agencies’ Web-based AIP programs catch errors in a way that allows customers to easily fix the mistake. Often, the error messages are difficult to interpret. However, some agencies do an excellent job handling input problems. As shown in Figure 5.19, the San Diego Metropolitan Transit System can even help customers if an origin or destination address is not clear. 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 data input of trip origins and destinations via a map interface rather than typed or pulled down text. Similar intentions were expressed as potential system improvements by APT, UTA, and other transit properties.

8-8 Figure 8.1: PVTA Landmark Look-up Interface 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 feature73. The SCAG TranStar AIP system, used by several of the transit agencies included in this study, offers a middle ground on the mapping issue. TranStar’s itinerary output offers schematic “stick maps,” which provide transit customers with basic geographic orientation, but do not consume enough bandwidth to slow transmission to customers. In a creative compromise, the current MTC TakeTransit system starts with a text-based itinerary, and only provides maps if a customer requests this information at either the origin or destination end of the trip. Then, the customer is offered both the TranStar stick map, which is specific to the his/her itinerary, as well as the transit route map, which is static and not interactive. 73 See the discussion of mapping in Section 7.2 for more information.

8-9 In the early development of the telephone survey outline, the project team was aware that it would find opposing positions on employing maps to allow origin and destination input for AIP systems. Although none of the systems included in this study use maps as a customer interface, there is certainly a great deal of both positive and negative interest in the topic. Specificity of Trip Itineraries In the case of AIP systems, respondents generally noted the importance of providing door-to-door trip itineraries for their customers. APT, SEPTA, and GMPTE, which have point-to-point rather than address-to-address origin-destination definitions (i.e., transit node or intersection-based itineraries, but not actual address-defined origins and destinations), expressed a desire or a plan for upgrading their systems to handle the more specific itineraries that other agencies provide. Quality Control Many of the survey respondents noted that their telephone operators used some modified form of the automated trip planner in their work, and that they were the first line of defense to discover errors in the itinerary generation process. Other agencies maintain a service contract with their vendor, and automatically send a screen-save copy of outputs that look suspicious. The project team believes that MTC’s solution of requiring MOUs from participating agencies, discussed in Section 5.1, could be an excellent foundation for quality control, at least for multi-agency Web features. Role and Use of Real-Time Information Early in the telephone survey, all respondents were encouraged to discuss the role of real- time information in Web site development. This was a weighty issue among those respondents whose agencies have the ability to collect such information. Some telephone interviews indicated that providing real-time information to customers via the Web is basic and essential. Others believed that the issue served to divert attention and resources from more important and more easily accomplishable strategies. Predicting Arrival Times Most of the agencies surveyed for real-time information applications do not predict arrival time. They believe that the real-time data and/or the prediction algorithms are not accurate enough to calculate reliable predictions. Similarly, several agencies that collect real-time vehicle location information have decided not to develop Web-based real-time information services. They feel that the real-time information should primarily be used to keep buses and trains on schedule, rather than for customer information purposes. This may particularly be the case for Web-based real-time information, since a late vehicle could make up delay, which would throw off predicted times and possibly cause customers to miss their buses. The notable exceptions are KC Metro and NextBus. The BusView and MyBus features developed by the University of Washington for KC Metro include arrival predictions. NextBus also predicts arrival times, both for its Web service and for its wayside real-time arrival signs. Since it is a necessity for the next bus arrival signs, NextBus might just as well use the same information on its Web page.

8-10 Even among transit systems that provide predicted arrival times, there exists a general consensus that more work is needed on the prediction algorithms. These organizations recognize the trade-off between providing conservative assumptions to incorporate the possibility that a delayed vehicle will make up schedule time and the need to give waiting passengers accurate arrival times. Tracking Usage and Performance Measuring the impact on call centers is closely related to tracking Web site usage. The project team found that, in general, transit agencies with newer advanced Web site features track their use by customers. However, as these programs mature, it appears that measurement declines in part because the transit agencies no longer need to justify the value of these tools. The project team wonders whether the benefits of tracking usage really do decline over time, since it appears that these statistics could be used to improve and optimize functionality and ease-of-use. Thus, transit agencies would be well served by designing their advanced Web-based customer information features to encompass tracking functionality. By maintaining tracking systems, agencies could analyze their output so that performance could be measured throughout the life of the Web site.