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.

5-1 5. 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 were selected to provide a wide variety of experiences with and approaches to providing an AIP service to customers. 19 In addition, one site was chosen in the United Kingdom. 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 Transportation Authority (SEPTA); • Anchorage Public Transportation (APT); and • Greater Manchester Public Transport Executive, United Kingdom (GMPTE). These agencies were selected using the criteria discussed in Section 4. Although at first glance many of these systems are quite similar, several key differences will be highlighted in the remainder of this section, including: • Whether all customer input is on a single page; • Design of the user interface for inputting origins and destinations; • Type, detail, and number of itineraries provided; and • Whether the output page provides tools that allow customers to easily modify their trip preferences. Each of the AIP case studies is presented using the organization described in Section 4.6 above. Note that from this point forward, automated itinerary planner and trip planner will be used interchangeably to reflect how individual agencies describe their systems. 5.1 Metropolitan Transportation Commission The Metropolitan Transportation Commission (MTC) plans transportation programs for the San Francisco Bay Area.20 MTC is both a regional transportation planning agency and the metropolitan planning organization (MPO) that addresses development of public 19 Number of itinerary planning sites adapted from the Volpe Center's Transitweb, which can be found at http://transitweb.volpe.dot.gov/Search_Features.asp. 20 Visit the MTC home page at http://www.mtc.ca.gov/ and the TravInfo home page at http://www.travinfo.org/.

5-2 transit, highway, airport, seaport, railroad, bicycle, and pedestrian services. The telephone interview was conducted primarily to obtain information about MTC’s Web- based TakeTransit itinerary planner. As part of its overall commitment to multi-modal traveler information, MTC took the lead in creating the multi-organizational TravInfo system. This multi-modal effort was initiated in 1993 as a field operational test (FOT) sponsored by the USDOT. One of the first projects was to create a telephone operator-based system of integrated travel information and trip planning. Both the telephone services and the AIP systems are available in MTC’s nine county service area. The itinerary planner was launched on the MTC Web page in July 2001. According to the telephone interview, the Web interface was added because management felt it provided an additional medium for information. However, a fundamental issue that affected the decision to deploy the Web service was evaluating the trade-off between waiting to perfect the trip planning system against losing the "business" that could be generated by it. MTC ultimately decided to go on-line even though the AIP was not perfected at that time. 5.1.1 System Design and Functionality As shown in Figure 5.1, the MTC trip planner allows its customers to identify origins and destinations by address, intersection, or landmark. Customers can also define the day of their trip, departure time, and other options, including: • Itinerary preference (fastest itinerary, fewest transfers, minimal walking, or lowest fare); • Fare category (adult, senior, disabled, child, youth, or school trip); and • Maximum walking distance to the first leg of a trip (1/8, 1/4, 1/2, 3/4, or one mile). This interface provides a high degree of flexibility for defining trip planning criteria21. Like most of the other AIP systems discussed in this section, all of the trip information is input on a single page. Another useful component is the "coverage area" map link on the main AIP page. Shown in Figure 5.2, the map allows customers to identify where agencies’ coverage areas are by holding the cursor over the map, which highlights the area in green and labels it. For example, Figure 5.2 demonstrates this by showing AC Transit's service area in green and the service areas of other agencies included in the itinerary planner in gray. Further, the customer can click on the map to bring up detailed information about the agency. This feature includes both service areas for AC Transit, County Connection, Emery Go- Round, MUNI, Union City Transit, Tri-Delta Transit, Westcat, as well as lines representing Caltrains, BART, Bay Area Ferries, and Altamont Commuter Express (ACE) services. 21 Trip planning criteria include the definition of origin and destination, as well as other trip parameters such as day or time of travel, itinerary selection criteria (shortest trip, fewest transfers), etc.

5-3 Figure 5.1: MTC TakeTransit Input Page Figure 5.2: TakeTransit Coverage Area Link As discussed later in the report, an important part of AIP systems is how they handle landmarks. The MTC's landmark error trapping feature, shown in Figure 5.3, allows a customer to re-specify a landmark location if the AIP system does not recognize the

5-4 Figure 5.3: TakeTransit Landmark Correction Page initial input. MTC staff indicated during the telephone interview that the landmark interface is very important. MTC works closely with each of its member transit agencies to identify the important landmarks, a list which is regularly updated. MTC does not know which form of origin and destination input is preferred by its customers, but the agency assumes that customers use a combination of origin and destination types when creating an itinerary. The landmark list is in a typical database and not geocoded (this point will be discussed further in Future Plans). Figure 5.4 shows the output that the customer is given. Of particular note are the following features of the itinerary page: • The walking maps and detail of the associated system map, as shown in Figure 5.5 and 5.6, provided even for transfers; • Fare by trip leg and total fare; and • The Revise Your Trip feature. The fare by trip leg is particularly important for regional multi-modal itinerary planning systems where a leg on intercity rail could raise the fare significantly. Note that although only one itinerary is provided, unlike other AIP systems explored in this study, the Revise Your Trip feature makes it simple for the customer to modify the itinerary characteristics without having to start the process over again.

5-5 Figure 5.4: TakeTransit Itinerary Output Figure 5.5: MTC Walking Map

5-6 Figure 5.6: Detail of the Relevant Bay Area System Map (MUNI) 5.1.2 Project Objectives The MTC’s itinerary planner was designed to provide transit customers with consistent trip itinerary information across modes and transit service providers. This means that a customer wanting to take trips that involve more than one agency and/or cross service areas or modes need not be concerned with different agencies and their service boundaries. This approach is especially important for multi-modal services with dense transit service across an entire region. The Web-based AIP information is available to customers at their fingertips, 24 hours per day. MTC designed the AIP service based on serving three customer market segments. These include: • Regular transit customers: This group generally comes to the site to check schedules or make changes to their regular travel plans. For this group, it is important to maintain consistency of the site. • Intermediate transit customers: For this group, the trip planner gives the agency the opportunity to pull people into using transit. Because this group may be less familiar with the system, they may need more help than regular customers when planning a trip, and this must be kept in mind when making changes to the AIP design. • Tourists and infrequent customers: MTC believes there will be significant growth in the tourist market. This is the market segment that MTC is really targeting with their improved map interfaces (discussed below). MTC believes that tourists are unlikely to know addresses and intersections, but may be able to find locations on a map.

5-7 The other "market" MTC considers constantly is its member transit agencies. MTC works closely with these agencies and considers their needs when planning changes to the AIP system. 5.1.3 Implementation Issues Designing the System Since MTC originally chose the TranStar automated transit trip planning system developed by the Southern California Association of Governments (SCAG) for its call center, it decided to use the same system when it deployed its Web-based service.22 Consumer response to the telephone service was strongly oriented to transit. For example, a February 1997 study showed that approximately 82% of TravInfo calls were about transit. MTC’s information system now involves over 25 separate transit agencies in the region. Initially, MTC was limited in designing its AIP Web service since it had to function within the limits of the SCAG software, and the AIP system remains similar to other SCAG sites because it still contains much of what was licensed from SCAG. MTC visited other AIP Web sites and found that most provide the same basic information. Nevertheless, staff stays on top of developments at other AIP sites in order to keep their own site up-to-date. MTC’s Web-based AIP program has evolved and continues to evolve from the original application of the TranStar system developed for the call centers. When the on-line trip planner was first deployed, MTC decided to use SCAG's existing Web interface. However, MTC is improving the Web interface and making some basic AIP design changes to the processing logic, database, and communications. (SCAG will continue to own the rights to license the basic software.) MTC views its changes as developments in the public domain and is willing to license these improvements back to SCAG should they be interested in such an arrangement. Costs The MTC’s Web-based travel information service was initially designed to collect and prepare travel information for dissemination by private sector partners. Over time, the MTC reexamined the feasibility of operating a profitable, self-sustaining service as a public-private partnership. The Web program is now supported solely by public funding. MTC discussed assigning costs to participating agencies but decided not to ask them to contribute financially. Since the itinerary planning system represents a regional public service, MTC decided it should bear these costs. They also thought it would be too complex to determine a cost sharing structure that included system maintenance and communications costs. Additionally, MTC recognized that the agencies already contribute indirectly since there is a cost associated with preparing, providing, and maintaining data. This point will be discussed in more detail in later sections. The trip planner (and the Web site in general) competes for funds, as would any regional project the MTC oversees. In order to maintain funding for the itinerary planner, the 22 See SCAG’s TranStar page at http://www.scag.ca.gov/transit/.

5-8 MTC must justify its utility to partnership agencies by analyzing the costs and benefits of the system. Start-up and Growth While planning the first phase of the AIP system, four agencies – BART, MUNI, AC Transit, and the County Connection – pushed to add the itinerary planner and were first to be included in the AIP system. Initially, MTC and the partner agencies thought that integrating different schedules and routes into a coordinated system would be simple. However, this process turned out to be fairly complex and time consuming. With only four of the region’s transit service providers participating initially, expansion has been a significant implementation issue. MTC’s position has been to expand the AIP system incrementally, using a two-fold strategy: • The basic strategy is "inside-out growth.” In order for an agency to be added, it must be contiguous with the existing AIP network. So, for example, MTC wants to add Golden Gate Transit before adding some of the local Sonoma County operators. • The schedule for adding agencies is determined mutually by the agency and MTC. MTC requires a strong commitment from the transit agency. Often, joining the AIP system requires a change in organization, such as changing an agency's work rules or assigning responsibility to certain individuals. A new agency must be fully prepared before MTC brings it on-line. MTC will not launch an agency prematurely, believing that providing inaccurate information to the public is worse than not providing information at all. MTC hopes to add Golden Gate Transit and SamTrans into the system by April 200323. Santa Clara VTA should be added by June 2003. Maintaining Data Accuracy Ensuring that the AIP system’s data is up-to-date and accurate is one of the most difficult issues for MTC. Many of the member agencies' customers rely on the Web site as their primary source of information, so it is crucial for the trip planner to work reliably. The MTC has memoranda of understanding (MOUs) with each of its member agencies specifying institutional responsibility for the AIP system. These MOUs specify exactly what staff members at participating agencies are responsible for and explicitly describe the requirements for updating data. MTC performs a number of “fairly elaborate” checks to ensure data accuracy and integrity. MTC staff work with agencies to make sure new schedules are uploaded into the database before they become effective. In some cases, the process is automated through an interface with an agency's run-cutting system. This interface allows an agency to automatically generate a file that is input directly to the AIP system. Quality Control Quality control involves ensuring that the itineraries provided by the trip planner are accurate. This requires efforts on the part of both participating agencies and the MTC. 23 This process has been delayed because MTC is trying to automate the data entry.

5-9 When new data is entered into the system, MTC requires agencies to plan and validate a series of itineraries to ensure that they are consistent with the new schedules. The MTC also checks some itineraries itself, particularly for inter-agency trips, and receives assistance from individual agencies, particularly in checking that critical transfers are working correctly. 5.1.4 Outcomes/Benefits Customer Satisfaction The MTC has received tremendously positive feedback from its customers regarding the AIP system. The agency knows that its ridership is growing, but cannot ascribe the increase directly to the AIP, even though it believes that the system encourages ridership. Customers have expressed that obtaining consistent information across agencies is quite valuable. However, MTC recognizes the importance of maintaining realistic customer expectations by clearly defining what the trip planner actually can do. MTC is also cognizant that the AIP system is just one part of its overall customer information strategy. Impact on Call Centers MTC representatives believe the AIP system has benefited the call centers. However, the agency has not yet established a direct relationship between the AIP and a reduced number of calls. MTC is currently working with member agencies to develop a tracking mechanism to measure this impact and identify the actual relationship between the two systems. As noted earlier, the TranStar database is used for both call centers and the Web-based AIP system, and call centers at participant agencies access the AIP information in two ways. Smaller agencies can use the same Web interface as the public, as long as they have a reasonably fast Internet connection his. Larger agencies, who must process a large volume of itineraries, can get direct access to the standard desktop interface. 5.1.5 Planned Improvements The MTC is planning a major redesign of its Web site that will result in major improvements to the itinerary trip planning process. As discussed below, MTC is planning to customize the AIP system by adding features to the basic SCAG product. MTC views these improvements to SCAG's system as investments, and may consider licensing new components to other customers. Three significant parts of MTC’s AIP system will be improved during the Web site upgrade: • Database: The database contains schedule and route data, organized by individual operator. This database will migrate from its current platform to an Oracle database environment, making it accessible to multiple applications (in addition to the trip planner). This is also expected to speed up itinerary processing. • Geographic Information System (GIS): This component provides address mapping. MTC is changing the current GIS engine to the industry standard ESRI GIS platform. • Application logic: This is where the application calculates which itineraries to produce, using information from the database and the GIS. MTC and SCAG are re- writing the business logic in contemporary, object-oriented programming languages

5-10 (Visual Basic and C++). The objective is to make the AIP system more efficient and functional, with better integration of information from different agencies. Mapping Capabilities As shown in Figure 5.5, the AIP system displays schematic walking maps. It also provides static graphics supplied by the local bus operator, which help orient customers to the location where they will pick up transit service. This was shown in Figure 5.6. However, these maps are not interactive. With the change of GIS platforms, MTC will be able to replace the simple, static walking and transit location maps with more complex maps generated by a GIS server. This change is also intended to enable MTC to provide maps covering the full itinerary, a functionality that is not currently available to customers. Customers will also be able to define the origin and/or destination by pointing and clicking on a map, rather than entering in text for address, intersection, or landmark. MTC already has a prototype for the mapping features but is concerned that it might attract too much use on the AIP system, acting as an alternate to on-line mapping services such as MapQuest or MapBlast. 24 This could overburden the AIP servers and impact performance, so MTC wants to ensure that this functionality is limited to information about transit trips. Landmark Improvements According to the telephone interview, MTC believes that the way landmarks are managed is a very important aspect of the Automated Itinerary Planner. The MTC is currently working on converting its existing landmark database to the new GIS platform, which is expected to provide greater accuracy and flexibility in how landmarks are defined spatially. Multiple Itineraries Showing just one itinerary is the default for TranStar, and MTC is trying to decide whether to change this when its AIP improvements are implemented. As noted, Web- based AIP systems at some other transit agencies provide multiple itineraries. MTC is using focus groups to help redesign the overall Web site, and participants will be asked whether they prefer the single or multiple itineraries. (Note that, as discussed above, the AIP output provides many options for optimizing a customer’s itinerary, including calculating the next best itinerary. This functionality may minimize the need to provide customers with multiple itineraries.) An important objective of the MTC is to keep the trip planner as straightforward as possible for customers and minimize the number of steps in the itinerary planning process. One solution MTC is considering to achieve both goals is to have the itinerary planner produce a table of summarized itinerary options, from which the customer could then select a specific itinerary option for which to display compete details. 24 View MapQuest at http://www.mapquest.com/ or MapBlast! at http://www.mapblast.com/.

5-11 CRM The MTC is currently developing a program to implement aspects of CRM (previously defined in Section 4.1) that will be called My Take Transit. The feature will allow customers to create a user name and password, and then save preferences for trips they take frequently. The registration module is already programmed but not yet implemented. Real-time Information The MTC has considered adding real-time information to their Web site, but feels this would be a difficult task given the multi-agency nature of their system. The addition of real-time information is dependent on MTC’s member agencies are collecting real-time vehicle location data. Currently, some agencies are and others are not. According to the telephone interview, the upgraded AIP system that MTC is designing will have the capability to handle real-time data and combine it with its static data. Nevertheless, the agency feels that the technologies in use by its member agencies are currently too diverse to integrate. In order to get a real-time Web-based customer information system implemented, the MTC would need a strong commitment from and coordination with its member transit agencies. 5.2 Ventura County Transportation Commission At the Ventura County Transportation Commission (VCTC), Web-based automated itinerary trip planning has been available to customers for six years. According to the telephone survey, VCTC was one of the earliest agencies to bring AIP to the Internet for its customers, having deployed the system in April 1996. Before this time, VCTC was using SCAG's TranStar AIP system in its call center. The agency saw an opportunity to make the AIP service available to its customers via the Web and hired a Web services consultant to convert the trip planner to an Internet application. A separate project to provide real-time bus location information is expected to commence in spring 2002. At present, there are no plans for electronic notification of service conditions, nor any CRM application. The interview respondents expressed doubts that CRM would be a valuable feature. 5.2.1 System Design and Functionality While many of the features on the VCTC itinerary planner represent functionality inherited from SCAG's AIP system, VCTC managers have been steadily improving the feature over the past six years. One key improvement has been simplifying customers’ on-line trip criteria data entry. Because its system has been on the Web for several years, VCTC has had sufficient opportunity to tailor the system in response to customer feedback. As shown in Figures 5.7 and 5.8, the VCTC trip planner allows its customers to identify origins and destinations by address, intersection, or landmark. In addition to the text boxes available for entering different types of origins and destinations, VCTC provides customers the option of choosing landmarks from one of three drop-down lists. One of these lists provides locations in Ventura County, the second lists major transit hubs, and the third provides locations in other areas of Southern California (outside of Ventura County).

5-12 Figure 5.7: VCTC Itinerary Planning Input Page Figure 5.8: VCTC Spanish Language Itinerary Planning Input Page

5-13 On the trip criteria input form, customers can also define the day of their trip (today, tomorrow, two days from now, etc.), departure time, and other options, including: • Itinerary preference (fastest itinerary, fewest transfers, or minimal walking distance); • Fare category (regular, senior, disabled, blind, pre-school, elementary, high school, or college); and • Special accommodations (wheelchair or bicycle accommodations). This interface provides a high degree of flexibility for defining trip planning criteria. Like most of the other AIP systems discussed in this section, all of the trip information is input on a single page. Figures 5.7 and 5.8 show how VCTC’s AIP provides several ways for customers to enter origins and destinations using landmarks. These Figures also show that landmark options are not limited to Ventura County, but rather include any landmark found in the SCAG system. As discussed during the telephone interview, the Ventura County AIP system also allows the customer to convert the input and output pages into Spanish, as shown in Figure 5.8. This is an important feature since Ventura County, and Southern California in general, have a relatively large Hispanic population. In fact, the Ventura County AIP is the only such system in Southern California that offers conversion into Spanish. The telephone interviewee suggested that since the Spanish language version is unique, this feature is accessed by many users outside the VCTC service area, extending its AIP site usage throughout the entire Southland region. Figures 5.9 and 5.10 show the itinerary output that the customer receives, which includes both the directions and the options for changing an itinerary (this information is provided on the same Web page; it is split in this report because it could not be depicted as a single screen). Unlike some AIP systems included in this study, Ventura County's application includes only one itinerary option for the customer. Of particular note are the following features of the itinerary output results page: • Fare by trip leg and total fare; • Option to show a detailed schedule for each trip leg; and • Link to a walking map. Like the MTC AIP, the fare by trip leg is particularly important for regional multi-modal itinerary planning systems where a leg on intercity rail, for instance, could raise the fare significantly. As shown in Figure 5.10, the detailed schedule option allows the customer to see the schedule for a particular bus, at a particular stop throughout the day.

5-14 Figure 5.9: VCTC Itinerary Planning Output Page, Part 1, Directions (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.)25 Figure 5.10 VCTC Itinerary Planning Output Page, Part 2, Options (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) 25 For example, Web pages such as this are produced by CGI or ASP programs. See Webopedia.com for a definition of CGI at http://www.pcwebopaedia.com/TERM/C/CGI.html and http://www.pcwebopaedia.com/TERM/A/Active_Server_Pages.html for a definition of ASP.

5-15 Therefore, if the customer misses a particular bus, the expanded schedule allows him/her to see when the next bus will be arriving at the particular stop of interest. However, the schedule page is static and the customer cannot choose a different departure time to have the system automatically recalculate the itinerary. This would need to be done manually by the customer, since headways on different legs may not match. The AIP output page, as shown in Figure 5.10 allows a customer to generate a new itinerary. Customers can select from the following options: • Show the return trip (after entering all trip criteria except the origin and destination); • Show another trip leaving from the destination of the initial itinerary (which requires the customer to define all trip criteria except the destination of the previous itinerary, without the help of the landmark); or • Show another trip entirely. Similar to other SCAG AIP systems, the VCTC trip planner provides customers with “stick Figure” walking maps, as shown in Figure 5.11. These maps were developed by a private mapping company and initially were used with the call center version of the AIP. When VCTC decided to put the AIP on the Web for its customers, the agency had to negotiate an agreement with the mapping vendor because the firm did not want its maps so widely distributed. As a result, the walking maps were added to the Web site slightly later than the other features. Figure 5.11: VCTC Itinerary Walking Map (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.)

5-16 5.2.2 Project Objectives The primary objective of VCTC implementing its AIP on the Web was to attract new customers to the transit system by making it more accessible and easy to use. While the agency realized that it might reduce telephone inquiries as well, its main motivation was to provide a greater public service. The AIP facilitates transit usage within the County. Based on the telephone interview, it appears that many potential customers have informational barriers to taking transit, such as how to ride the bus, where to catch it, how much it costs, etc. The AIP gives customers detailed information about how to ride transit, including exactly where to stand on the street to catch the bus and how much the total trip will cost. It makes it easier for people to learn how to ride transit and helps them feel more comfortable, therefore increasing the accessibility of the transit system. In addition, before the VCTC AIP went on-line, customers were constrained to getting information during the call center’s operating hours. Now, the on-line trip planner allows them to access information 24 hours per day, seven days per week. In developing the Web-based trip planner, the VCTC’s primary market was Ventura County residents. At the time of implementation, the county’s population was highly computer literate – 90% of households had computers. Consequently, they thought it would be advantageous to offer residents better on-line services, allowing them access to the AIP information 24 hours per day, seven days per week. By doing this, the agency was hoping to increase transit system usage among county residents. 5.2.3 Implementation Issues Designing the System While the basic functionality of VCTC’s Web-based AIP is similar to that originally offered, some features were added after the site went on-line, such as the option to plan a return trip. Additionally, the agency made some changes to the customer interface of the AIP. It also added and changed landmarks based on feedback from customers. Another feature added after initial deployment was providing transit route schedules for the links on an itinerary. VCTC visited other transit AIP Web sites but found it hard to compare its site to others because Ventura County has so many different operating agencies and modes. The agency reviewed MTC's AIP page concluded that VCTC’s is more comprehensive because it includes features such as bike maps. VCTC surveyed customers for suggestions about the AIP design in its early days. However, since then the agency has done little market research. They depend on customer comments for planning changes, although VCTC is receiving fewer comments as time goes by. This may be because the agency’s continued improvement of this advanced transit Web site service has addressed most outstanding customer needs. Costs Before the trip planner was put on the Web, VCTC was already paying SCAG approximately $4,000 annually to license the TranStar system for its customer service agents. This fee has since increased to approximately $10,000 a year for the use of SCAG’s software and services. SCAG ensures that participating transit agencies keep

5-17 schedules up-to-date and maintains data required to compute itineraries, such as landmarks. VCTC paid $20,000 to a Web services vendor to convert the TranStar system into a Web application. (The county’s entire Web site only cost about $60,000 to develop, including the AIP.) Quality Control When the AIP was first implemented, VCTC performed its own quality control on the system. In recent years, however, they have depended on customer feedback to identify problems with the system. An ongoing problem discussed below is how TranStar defines geographic barriers. Geographic Barriers One aspect of the system that could be improved is how TranStar defines geographic barriers, which sometimes causes strange results. For example, the system does not recognize geographic characteristics such as mountains, and therefore computes the distance across a mountain or hill as a straight line. In reality, the mountain may increase walking distance. The VCTC would like the trip planner to calculate distances more accurately. 5.2.4 Outcomes / Benefits Usage Patterns When the Web-based AIP was first introduced, VCTC was required to track usage very closely in order to justify the system’s utility to member agencies. However, now that the AIP is well established, VCTC does very little system tracking. It continues to collect usage data, but staff constraints have limited the agency’s ability to perform in-depth data analyses. Early in the project, VCTC also examined when customers were using the system to see if it was necessary to have a 24 hour service, rather than just during business hours. The statistics showed that the system should operate at all hours. Usage statistics can also show VCTC if there are local or regional trips that are not being served, or if the AIP system is not providing the right information. Responses to the telephone interview suggested that the AIP system had roughly six times as many page views as the VCTC home page. However, this statistic may be misleading, since customers may have bookmarked the AIP page, thus skipping the home page. Customer Satisfaction As indicated above, one of the agency’s primary goals in implementing the Web-based trip planner was to make it easier for the public to use transit. VCTC feels that this goal has been undoubtedly realized. Based on customer feedback, the agency believes customers' expectations are well served. Even during times when the system experienced problems, the number of customer complaints did not rise appreciably. The telephone interview indicated that VCTC managers feel the AIP has been an excellent business investment, especially considering that creating the Web interface only cost about $20,000.

5-18 Impact on Call Centers VCTC’s AIP also reduced telephone inquiries. As mentioned earlier, the call centers also use the TranStar system, although their interface is slightly different. Customer service agents receive slightly more information than the public gets on the Internet site. They can also override some of the functions. The VCTC has not analyzed whether the AIP program has lowered the workload for the operators at the call centers, but they believe it probably has done so. 5.2.5 Planned Improvements Improvements to Trip Planning Criteria One function VCTC would like to provide its AIP customers is the option of specifying a mode of preference (so customers could choose rail-only, bus-only trip, etc.). The ability to specify mode preference is especially important for a regional, multi-modal AIP system such as VCTC’s, where fare can vary significantly depending on which modes are selected by the AIP. Additionally, the agency plans to improve its "day of travel" option, which they have found to be confusing to customers. Currently, customers can choose travel today, tomorrow, two days from now and up to one week in advance. The project team did not ascertain how VCTC intends to change this option. Real-time Information The VCTC is currently working with NextBus to provide real-time customer information throughout the county. The agency has equipped all buses operating in the county with GPS-based AVL systems to implement this program. In addition to the on-line information provided on the NextBus Web site,26 there will be variable message signs at bus stops showing the expected bus arrival times. This will be discussed further in Section 6. Landmarks Although the telephone interview revealed that usage tracking has become less prominent for VCTC than it was initially, the agency still tracks origin and destination entries. This is done to ensure that the AIP system provides the most appropriate and accurate landmarks for its customers. E-mail Notification and CRM According to the responses during the telephone interview, VCTC has not considered implementing e-mail or other electronic customer notification mechanisms for service disruptions. It sees no benefit from such a system, since riders will now be able to use NextBus to see exactly where the buses are and when they are predicted to arrive. Consequently, it would be time consuming and unnecessary for the agency to develop an e-mail notification system. However, VCTC did note that NextBus should be making the real-time information available via mobile devices. 26 See the NextBus home page at http://www.nextbus.com/predictor/newUserWelcome.shtml.

5-19 5.3 Washington Area Metropolitan Transit Authority WMATA reported during the project telephone interviews that it was one of the early pioneers of itinerary planning via customer service agents. It now provides AIP service on the Web via its RideGuide system. Just as Ventura County created a new customer interface to put information designed for trained telephone operators onto the Web for the general public, WMATA also employed private sector vendors to design a new customer interface from scratch. With approximately two million planned trips per year and growing steadily, the WMATA RideGuide feature is among the busiest AIP systems in the United States. WMATA does not currently offer Web-based real-time information or electronic notification of system conditions. Note, however, that the agency is testing the NextBus product, provides real-time train arrival information on Metro platforms, and has a generic e-mail notifications system. The e-mail notification is targeted at two different markets – employers and commuters.27 5.3.1 System Design and Functionality WMATA’s AIP system interface is different than most of the other deployments reviewed by the project team. Instead of using a single input page for trip criteria, WMATA uses an “Its as easy as 1- 2- 3” format, which is presented in Figure 5.12. With this format, the customer is encouraged to believe that the itinerary planning process will be easy and not take a long time. The three-step process is also viewed as a branding approach for WMATA. In practice, a customer uses the first two screens to define trip criteria, while the third screen shows the itinerary. Figure 5.13 shows the first input screen, in which the user enters an origin and destination. Figure 5.14 shows a helpful origins and destinations “examples” pop-up window. Figure 5.15 shows the second input screen for trip criteria. Figure 5.16 shows part of the itinerary output. Several features on these Web pages are interesting, such as: • All of the pages have a prominent “help” button; • Figure 5.14 shows customers the correct format to enter origin and destination information, whether it is an address, intersection, or landmark; • Figure 5.15 shows that customers can calculate a trip itinerary based on departure or arrival time and can decide whether they prefer to travel by any mode or by rail only or bus only; and • Although not shown, the entire screen from which Figure 5.16 was selected provides customers with three different itineraries. It also has links to walking directions, shows regular and senior/disabled fares, and has a button that allows a customer to automatically calculate the itinerary for a return trip. 27 Visit the WMATA e-mail signup page at http://www.wmata.com/riding/email_signup.htm.

5-20 Figure 5.12: WMATA RideGuide 1-2-3 Start Page Figure 5.13: RideGuide Input Screen 1 – Origin/Destination

5-21 Figure 5.14: RideGuide Origins/Destinations Examples Pop-up Screen Figure 5.15: RideGuide Input Screen 2 – Trip Criteria (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.)

5-22 Figure 5.16: RideGuide Output Screen (3) (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Another useful design element on the itinerary output page is the walking, bus, and rail icons, which make it easy to determine what mode a particular leg of the trip is on. Finally, the “print” button is not typically included on Web-based AIP systems. The print button formats the itinerary pages to eliminate much of the unnecessary on-line graphics and separates the three itineraries onto separate pages. During WMATA’s recent redesign of its Web home page, the RideGuide was made more prominent and accessible. The home page allows customers to initiate a trip itinerary in a frame on the right side of the page by entering origin, destination, time, and date of travel, as shown in Figure 5.1728. Once the customer clicks "Go,” he/she is taken directly to the itinerary options. The original three-step process can still be accessed at this point by clicking on a RideGuide icon. However, the more pared down approach provides a quick alternative to the three-step process, particularly for customers who are already familiar with the itinerary planning system. 28 View this at http://www.wmata.com/.

5-23 Figure 5.17: New WMATA Home Page with Itinerary Planning Frame While the original itineraries produced provide only brief walking directions, the customer has the option to obtain more detailed walking directions if desired WMATA’s AIP system does not provide maps because the agency believes this feature would considerably slow down the performance of RideGuide (see Section 7 for a discussion of performance and mapping.) The agency considered offering mapping by processing maps on a dedicated server, but since customers have not asked for maps, the agency has little motivation to add them. In general, WMATA feels that customers are content with the text directions. However, its customer service agents do have mapping capability on the software they use for telephone inquiries so that they can give customers more detailed directions. The option to plan a return trip, which is at the bottom of the itinerary page shown in Figure 5.16, is a useful function that provides added flexibility for the customer. When the customer clicks on this button, the trip planner automatically reverses the origin and destination choices, taking the customer directly to Step 2 of the RideGuide process. Therefore, planning a return trip is quick, easy, and accurate. 5.3.2 Project Objectives About four years ago, the WMATA team came up with a set of goals for the improvement of their trip planner and other call center functions. The “Call Center Improvement Goals” were to:

5-24 • Provide customers with an automated alternative that would give them access to information 24 hours per day, seven days per week; • Provide customers with the ability to do seamless trip planning; • Introduce technology blending (i.e. so they would not have stand-alone systems. For example, the synergy between their on-line trip planner and the phone-based trip planner they’re currently implementing); and • Provide new and innovative solutions that pull customers away from live operators. Because WMATA knew that its call center could not keep growing commensurate with its ridership growth, the agency’s primary goal in offering automated systems was to reduce the number of calls to live agents. When WMATA evaluated call centers calls, it determined that most were questions about routing and scheduling. When the Web became a more popular medium for information, the agency saw this as an opportunity to pull calls away from live agents. The resulting system provides 24/7 access to its AIP function on the Web site. When first developing the trip planning system, the managers did not really think about their target market because the main impetus was to divert calls away from the call center. Since then, they have realized that the trip planner is a useful application for tourists and an excellent marketing tool. WMATA managers believe that most people who use the RideGuide are planning a trip well in advance of their desired departure time. 5.3.3 Implementation Issues Designing the System WMATA’s original, service agent trip planning application is called ARTS (Automated Routing Transport System). It was developed by Mantech, which is now a unit of Trapeze.29 The vendor calls its product ATIS (for Automated Travel Information System). WMATA decided, however, to give its version a different name (ARTS) so that it would have a unique identity. The proprietary part of the system is Mantech’s Rapid Routing Module, which combines a geographic database with the transit schedule database to formulate trip itineraries (i.e., it is the itinerary planning logic). All of WMATA’s trip planning applications run off ARTS. Like many other agencies with Web-based AIP systems, WMATA employed a separate Web development firm, e.magination, to design RideGuide’s customer interface, based on research undertaken at the transit agency.30 Quality Control The WMATA AIP system has built-in diagnostic software to catch errors before the agency actually implements service changes. In addition, the agency sometimes asks customers into its offices to test the system by making queries and seeing if they look 29 Visit the Mantech Web page at http://www.mantech.com/main.asp?page_id=165&menuspot=_1_6_4_2&topspot=1. Visit the Trapeze Web page at http://www.trapezesoftware.com/home.asp. 30 Visit the e.magination Web site at http://www.emagination.com/.

5-25 correct. WMATA also check complaints from customers concerning incorrectly generated itineraries. Finally, telephone agents have the ability to flag itineraries that do not look correct. Flagged itineraries are placed in a particular database table, so staff can review and correct the offending inputs later. According to the project manager, WMATA’s trip planning system is 99.8% accurate. 5.3.4 Outcomes / Benefits Usage Patterns WMATA originally estimated that RideGuide would produce around 100,000 itineraries in its first year. However, RideGuide planned around one million trips during the first year it operated. That Figure has now risen to two million completed itineraries per year on the Web. Use of Data for Service Planning At WMATA, the data collected in the itinerary planning process is not used for service planning. Some managers believe that the information provided is not detailed enough to do this. In addition, since WMATA covers many jurisdictions, the agency is cautious of tackling institutional issues that might arise regarding use of the data. Finally, the agency believes that RideGuide is more accessible by the wealthier, high-tech market, so that the data may be biased for service planning purposes.31 5.3.5 Planned Improvements When considering improvements to the its AIP systems, WMATA puts customers needs first, so it does not get caught into applying technological solutions for their own sake. The agency plans to expand its AIP system to include Baltimore and Annapolis. Other locations in northern Virginia are also being considered. The goal would be to create a seamless system throughout the Washington metropolitan area. WMATA would need to resolve several significant institutional issues, such as the source of funding, before it could embark on this expansion. WMATA’s technical working group, comprised of member agency representatives, is also evaluating technological issues involved with expanding the system. WMATA might benefit from consulting with MTC, described earlier in this section, which has specific guidelines and requirement for adding agencies to its AIP system, codified in its MOUs. Voice-Enabled Version of RideGuide WMATA is in the process of adapting RideGuide to an interactive voice response telephone system (IVR), in part to provide: • AIP services to customers that lack Internet access; and • A phone alternative that customers can access anywhere, if for example, they are in their car and they get into a traffic jam or if they are away from the office or home and do not have access to their usual Internet connection. 31. Note that this contrasts the views of UTA, described in Section 6.

5-26 CRM WMATA has considered developing a personalized customer interaction feature for RideGuide (i.e., what the project team would call CRM), but is not planning to pursue the project in the near future. WMATA has not identified any value it would provide customers, suggesting that customers do not often plan trips using the same origin and/or destination. Thus, allowing customers to save this information for easy access at a later time may not be helpful. Similar to the previous discussion about incorporating mapping capabilities on RideGuide, customers have not asked for this functionality, so WMATA is not anxious to add it. Long-term Improvements WMATA has two long-term visions for the RideGuide system. The first is to convert RideGuide to a digital application so that, for example, a customer could access it via cable TV. WMATA’s second long-term vision is to integrate the IVR and the Web application so that itineraries could be sent to a mobile phone or PDA device. Alternately, trip itineraries planned with the IVR system could then be sent to a designated computer with Internet access. While WMATA is interested in technology blending, the agency remains guided by the objective of adding value and serving customer needs. Currently, no funding exists to pursue either of these initiatives. 5.4 San Diego Metropolitan Transit System The San Diego Metropolitan Transit System's (SDMTS’s) Web site offers automated trip planning, but at present does not offer real-time information or advanced feature registration to personalize the customer experience (CRM). As WMATA was finalizing its RideGuide program, San Diego began working with the same vendor to develop a program designed for its customers needs. The itinerary planning tool was added sometime in 1999. At the time, SDMTS’s trip-planning vendor had developed its own Web interface. The agency had funds available and decided to implement the trip planner, figuring that it would be a good public information tool for customers. Their system is called the On-line Transit Information System (OTIS). OTIS plans trips that could include the services of SDMTS, the Coaster commuter rail line, DART (Direct Access to Regional Transit), the San Diego Trolley, and Amtrak. 5.4.1 System Design and Functionality As shown in Figure 5.18, SDMTS's trip planner allows its customers to identify origins and destinations by address, intersection, or landmark. In addition to the text box available for entering landmarks, customers may select from a scrolling menu of popular landmarks in the region. On the input form, customers have the ability to define the following: • Day of trip - While many of the AIP sites reviewed include the option to specify date or day of trip, few include a design like San Diego's OTIS. Their system provides scroll down boxes for the month, day, and year of travel. • Desired departure or arrival time - The customer can plan the itinerary based on desired departure or arrival time.

5-27 Figure 5.18: San Diego Transit's Itinerary Planning Input Page • Itinerary preference - Itineraries can be formulated based on fastest way, fewest transfers, or minimal walking distance. In the telephone interview, the project team learned that the "fastest way" itinerary preference is set as the default because MTS believes it is the most frequently used preference. • Maximum acceptable walking distance - The customer can select from a maximum acceptable walking distance of 1/4 mile, 1/2 mile, 3/4 mile, or one mile. Like most of the other AIP systems discussed in this Section, all input of trip information and preferences is on a single Web page. The input page also includes a link to trip planning process tips, which guide the customer through the steps in using the itinerary planner. 32 As mentioned above, SDMTS’s Web-based AIP system includes several ways in which customers can enter origins and destinations. If an origin or destination entered by the customer cannot be found, the AIP system provides a user-friendly error trapping screen, shown in Figure 5.19. The screen allows the customer to choose from a scrolling list of acceptable locations. One notable aspect of Figure 5.19 is that it shows the system’s ability to trap address input errors, a function that other AIP systems do not provide. Similarly, good error trapping is provided if there are no stops within the walking distance specified on the input form, as shown in Figure 5.20. 32 See the OTIS “tips” page at http://www.sdcommute.com/service/otis_help.htm.

5-28 Figure 5.19: SDMTS Origin or Destination Error-Trapping Screen (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.20: Maximum Walking Distance Error-Trapping Screen (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.)

5-29 Figure 5.21 shows the itinerary output information customers are given. Like some of the other itinerary planners included in this study, San Diego's AIP provides multiple itinerary options for the customer. Each itinerary option includes the following information: • Total fare for the trip for both regular and senior/disabled riders; • The boarding and alighting time for each trip leg; • Total trip time; and • Links to schedules and maps for each trip leg. Figure 5.21: San Diego Transit's Itinerary Planning Output Page (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Unlike some of the other itinerary planners included in this study, San Diego's system provides only the overall trip cost, rather than the cost for each leg. While the itineraries provide links to schedules and maps for the routes selected, these schedule pages are static and the customer cannot choose a different departure time and then have the system automatically recalculate the itinerary. As noted in the project telephone interview, SDMTS is planning to add walking directions (but not walking maps) to its itineraries within the next couple of months. An interesting feature of SDMTS’s OTIS itinerary output page is the link to detours that may affect the itineraries generated. Clicking on this link takes the customer to a list of routes that may be affected by detours. This is shown in Figure 5.22. However, the itinerary planner and the detours are not linked - the detour page shows all routes rather than just the routes selected for the itineraries. While this issue was not discussed during

5-30 Figure 5.22: Detours Page on the SDMTS Web Site the telephone interview, it appears that the trip planner does not consider route detours when calculating optimal itineraries. Therefore, customers would have to check if a route on their itinerary might be affected by a detour and, if so, choose an alternate itinerary. The project team suggests that this could be difficult for an AIP customer who is unfamiliar with the SDMTS system or the general geography of the San Diego area. 5.4.2 Project Objectives One of SDMTS’s main objectives for implementing the Web version of OTIS was to give its customers access to information at any time for a trip they need to make. The AIP also enables customers to print out an itinerary and take it with them. The system is an excellent marketing tool for attracting new customers who might be unfamiliar with the system. SDMTS reports that feedback from customers has been very positive, with many people stating they would not have made a trip via transit had the Web-based trip planner not been available. The agency’s primary market for the trip planner is occasional and new riders, since these groups tend to be unfamiliar with the transit system. SDMTS feels that existing riders have fixed trips, so they are unlikely to need the trip planner. The site is currently not oriented to tourists, but the agency is planning to work with the Convention and Visitor's Bureau in the future to explore enhancements. A simple step would be for Visitor's Bureau to put a link to the trip planner on its own Web site.

5-31 5.4.3 Implementation Issues Designing the System Development of the Web-based Itinerary planner was a joint venture between the transit agency and their parent agency, the Metropolitan Transit Development Board (MTDB). The transit agency already had Mantech doing their trip planning system for the call center, so they just asked the vendor to develop it for the Web. Their parent agency took care of the graphic design because the agency wanted the "look" to be consistent with the rest of their Web page. The technology folks at their agency then worked with the other two parties for the final integration. The agency is still using Mantech (now Trapeze) for maintenance, but it is doing more of this work internally. For example, the upgrades they are currently doing (including Spanish and walking directions) are being developed internally because they have the resources available to do this. Quality Control Quality Control for the trip planner is done in-house on an occasional basis. They agency also relies heavily on customer feedback for quality control purposes. Of course, the problem with customer feedback is that the agents do not know what inputs the customer has entered into the system, making it difficult to diagnose problems. 5.4.4 Outcomes/Benefits The San Diego managers believe that the AIP program definitely adds value to their “business.” The application gives customers better information, 24 hours per day, and is an excellent marketing tool for the agency. It gives transit a good image by showing that the agency is at the forefront of technology. Usage Patterns Consistent with Mantech sites, the agency tracks trips planned per month (i.e. completed itineraries). Their peak month was 48,000 trips planned. Impact on Call Centers While the agency assumed that the trip planner would have an impact on telephone inquiries, this was not their primary reason for developing the application. Saving money or staff time was not as much of a consideration in developing the feature as the benefit for customers. Since introduction of the trip planner, calls to the agency's call center have dropped by 15-18%. Of course, it is difficult for the agency to attribute this decrease solely to the itinerary planner. They expect that the trip planner has decreased the number of calls from people who are already familiar with transit since these people can now get the information from the Web site. The calls that are now coming into the call center are likely to be from riders who need more personalized assistance, such as elderly and disabled persons. 5.4.5 Planned Improvements Improvements to the Automated Itinerary Planner San Diego Transit is hoping to make some improvements to their trip planner in the near future, including the provision of better walking directions and maps. Currently, the

5-32 agency offers some very nice maps on their Web site, as shown in Figures 5.23 and 5.24, but these maps are not linked to the AIP. The regional transit map shown in Figure 5.23 is interactive, allowing the customer to move to different geographic areas, return to the larger regional map (by clicking on the "M"), or return to the public transit homepage (by clicking on the "H"). Clicking on the route tabs in the regional map allows the customer to access more detailed route maps, as shown in Figure 5.24. As described in the applications section, customers are currently able to access these route maps from the itineraries generated by the AIP. In addition to adding improved maps to their Web site, San Diego Transit is also planning to add the option to convert the itinerary planning page into Spanish, an important improvement given the large Spanish-speaking population in the San Diego region. Real-time Information The agency is in the process of acquiring a new vehicle location system (AVL) and is hoping to incorporate the information provided by this system with their Web applications, their voice response system, and in their customer call center. They are not yet sure whether they will have a dynamic map display on the Web for the real-time information or whether it will just be a static map that can be regularly updated. They are planning to integrate the real-time information with their trip planning system. E-mail Notification The agency is also looking at providing automatic e-mail notification, which will be integrated with the acquisition of a new radio system. The reason the new radio system will be used is that they feel the real-time data is not as good a source of information for disruptions as what the drivers actually see on the road. Therefore, driver reports will be the main source of information for the notifications. CRM The agency does not currently have a CRM-type application, but is looking into developing one. The timing of such an implementation depends on their funding constraints. Given these constraints, the agency feels that providing real-time customer information is a higher priority than developing a CRM component. 5.5 Twin Cities Metro Transit Twin Cities Metro currently offers automated itinerary trip planning, but does not offer real-time transit information, e-mail notification, or CRM capabilities. The Twin Cities’ itinerary planning system provides a good case study on the synergistic relationship between the basic system supplier and the local transit agency’s desire to customize its services. The Web site offers an innovative customer interface and some basic solid products for the consumer. Their program of Rider Alerts and program to create customized personal schedules could be interpreted as a first step towards personalization of features for the customer. 5.5.1 System Design and Functionality Twin Cities Metro Transit has put considerable thought into the design of their automated itinerary planner. When designing the site, managers at Metro visited a variety of other

5-33 Figure 5.23: San Diego Regional Transit Map Figure 5.24: San Diego Route Map

5-34 transit Web sites in order to better shape their idea of what Metro's itinerary planner should look like. The result is a tool that is user-friendly and provides a high level of functionality and responsiveness for the customer. Metro's trip planner allows its customers to identify origins and destinations by address, intersection, or landmark. The interface is very interesting in that it changes based on which origin-destination input option the customer selects. For example, in Figure 5.25, the customer has chosen to enter origin by intersection and destination by landmark, thus changing the appearance of the input forms for these variables. In case the customer has trouble with this sophisticated input form, Metro's input page contains a link that accesses the more simplified input form shown in Figure 5.26. On this alternate form, all three location options are shown for both origin and destination. Within each of the origin/destination input categories, Metro has tried to make the input as straightforward as possible. For example, the option to enter street directionality is offered since many of the streets in the Twin Cities area have directionality. Additionally, the input form provides two different text boxes for intersecting streets in order to avoid confusion in how to enter intersections (for example, using "First & Main" vs. "First and Main"). The landmark option allows the customer to either type in a landmark or select from a drop- down list of popular locations in the Twin Cities region. On the input form, customers can also define the following trip characteristics: • Date of trip - like San Diego, the Twin Cities' itinerary planner provides scroll down menus for the month, day, and year of travel; • Desired departure or arrival time - The customer can plan the itinerary based on either desired departure or desired arrival time; • Itinerary preference - Itineraries can be formulated based on faster trip, fewer transfers, or less walking; • Maximum acceptable walking distance - The customer can select from a maximum acceptable walking distance of 1/4 mile, 1/2 mile, 3/4 mile, or one mile; and • Whether a wheelchair accessible trip is needed - this preference is especially important for agencies that do not have an entirely wheelchair accessible fleet of vehicles or agencies with transit stations that are not accessible to people with disabilities. Figure 5.27 shows the output that the customer is given with Metro's itinerary planner. Metro's AIP provides multiple trip itineraries if they are available, and also includes a schedule adjustment box (which will be discussed in more detail below). Each itinerary includes the following information: • Total fare for the trip for both regular and senior riders; • Total trip time; • Links to schedules for each trip leg; • Brief walking directions; and • A link to detailed walking directions.

5-35 Figure 5.25: Twin Cities Metro Transit's Itinerary Planning Input Form Figure 5.26: Alternate Version of Itinerary Planning Input Form (Note: Figure cannot be hyperlinked because it is produced by a dynamic interface program.)

5-36 Figure 5.27: Twin Cities Metro Transit's Itinerary Planning Output Page (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.28 shows the walking directions provided by the automated itinerary planner. Walking directions are offered for both the origin and destination end of the trip and include total walking distance. While Metro would like to add mapping capability, the agency has been told by their vendor that this functionality would be difficult to add and, consequently, has not aggressively pursued the option. “Schedule Adjust” and “Plan Return Trip” Boxes The “Schedule Adjust” and “Plan Return Trip” boxes, shown in Figure 5.29, are design elements not seen in many other AIP tools. According to Metro staff, these features were not standard functionality offered by the vendor and were developed for Metro at an additional cost. However, managers felt that the features provided enhanced usability for the customer and were therefore willing to put forth the investment for their development33. The schedule adjustment box allows the customer to easily manipulate the itinerary planning system by choosing a travel time that is earlier or later than the time originally selected. The customer can choose a time that is anywhere from five to 60 minutes earlier or later (times are provided in 5-minute increments). Since selecting a different departure or arrival time may affect routing or transfer options, changing these times may 33 Apparently, the cost for developing these features was not significant compared to the overall AIP cost

5-37 Figure 5.28: Detailed Walking Directions from Twin Cities Metro AIP (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.29: "Schedule Adjust" and "Plan Return Trip" Features produce completely different itineraries than those originally created. The option to plan a return trip automatically reverses the origin and destination locations and allows the customer to select a return date and time, again providing for added opportunity to easily manipulate the system. Figure 5.29 also shows the "New Trip" and "Print" buttons that appear at the end of the itineraries produced by Metro's AIP. The former allows the customer to easily access the (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.)

5-38 original input form in the event that they would like to plan a trip in which parameters other than the time of travel are changed. For example, if they wanted to plan a trip from a different origin or to a different destination, this button would quickly return them to the original input form and allow them to re-start the itinerary planning process. Unlike the print feature offered by WMATA's RideGuide, Twin Cities Metro's print button does not re-format the itineraries, but simply prints out what the customer sees on the screen. Personalized Schedules While Metro's Web page does not currently offer CRM functionality per se, the agency has developed an interactive personalized schedule maker, shown in Figure 5.30, which may be considered an initial step towards providing CRM capabilities. While the personalized schedules cannot be accessed directly from the itineraries produced in the AIP, it is clear that this feature is linked to the itinerary planning engine. Like the AIP input screen, the personalized schedule maker asks the customer to input origin and destination by address, intersection, or landmark. However, the preferences available are quite a bit different from those in the itinerary planner. By default, the date for the trip is set to the current day, but the customer may change this by pointing and clicking on a different date from the interactive calendar. The customer must then choose the starting and ending times for the personalized schedule, as well as the maximum acceptable walking distance. Once the customer has entered origin, destination, date and time of travel, and maximum walking distance, the personalized schedule maker finds the routes that meet the specified criteria. All relevant routes are saved to the customer's personalized bus schedule, and he can then choose which schedules to display, as shown in Figure 5.31. The tool then allows the customer to print out schedules with minimized wasted space or unneeded information, as seen in Figure 5.32. While the customer cannot save these bus routes to a profile (as would be expected in a full CRM application), the tool provides a higher level of customization than most transit agencies have at this time. 5.5.2 Project Objectives The J-09 interviews revealed that the managers at Metro developed the trip planner because they wanted their riders to be more independent. The agency also wanted to be more responsive to customer needs, and the on-line AIP does this by decreasing the wait time for getting an itinerary - it is much quicker than using the call center. The agency's goal was to have trip planning readily available to customers so that they would not have to rely on the call center. The trip planner made information more accessible (24 hours per day) and faster for customers to get, allowing customers to manipulate the system to get the itinerary they want. We were told that the primary market was regular riders; the tourist and infrequent rider market was secondary. The managers do not feel there is a large tourist market in Minneapolis.

5-39 Figure 5.30: Metro Transit's Personalized Bus Schedule Maker, Step 1 (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.31: Metro Transit's Personalized Bus Schedule Maker, Step 2 (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.)

5-40 Figure 5.32: Results of Constructing a Personalized Bus Schedule (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) 5.5.3 Implementation Issues Designing the System As stated earlier, Metro managers visited a number of other AIP sites when designing their system. One of the sites they visited was WMATA’s RideGuide. While they liked the graphics on the WMATA site, they found some problems with the data input and error trapping processes. They did consider adopting a “1-2-3” three screen approach like RideGuide, but found during their market research phase that customers really didn't like this feature and preferred to just have the entire input screen on the first page. The itinerary planning system was implemented in two phases, and took approximately a year and a half to develop. The first phase used a standard vendor interface, which had already been developed and was therefore reasonably priced. It was a simple interface, and Metro used it to get customer feedback for the development of their "real" site. After completing market research on this simple site, they hired an advertising agency to do the interface design and to perform additional customer research. The initial site went on- line in July 2000 and the current site went on-line in March 2001. The personalized schedule option went on-line a few months after that. They agency did not promote the AIP system until they had the new design up and running. Metro customized the AIP vendor’s standard package quite a bit. For example, the options to adjust the time, schedule a return trip, and develop personalized bus schedules were all customized options. They also did some customization on the initial input form because addressing is such a "huge problem" and they felt it was important for origin and

5-41 destination input to be as simple and error-free as possible for the customer. For example, by design, origins and destinations cannot include an ampersand. However, when someone inputs an intersection, he/she is likely to try to enter it using an ampersand (like Main & Broadway). Therefore, they designed the input form with two boxes for intersection streets so that this would not be an issue. Additionally, many of the streets in Minneapolis are directional - in order to make data entry clear for the customer, the agency created a drop-down box for the directionality. Metro really focused on making the AIP customer friendly. The managers have spent a lot of time thinking about the ability to choose landmarks from a pre-specified list. They recognize that there is a trade-off between giving people an adequate list of landmarks and not making the list so long that it is unruly. Therefore, they finally decided on a short drop-down landmark list. As indicated above, the agency did quite a bit of market research in designing their trip planner. Initially, they used a Mantech interface, which they acquired relatively inexpensively since it had already been developed. They used this site for their market research in order to expose people’s preferences. They brought in a number of individuals, both riders and non-riders, and asked them to use the site and comment on what they liked and did not like. This customer input was then used by the advertising agency in developing the final site design. Costs The interface design work cost approximately $60,000, including the market research done by the advertising firm. Since the agency already had the trip planning system in use by the call center, the programming for the Web site was reasonably straightforward and cost about $50,00034. However, most of the money did not come from the agency, but rather was part of the ORION project sponsored by the Minnesota Department of Transportation. The ORION project is a large ITS project and a couple of years ago the DOT was looking for a transit component. Metro was able to convince the DOT to fund a trip planning system; therefore, the $1 million cost of developing this system was taken care of by the DOT. Maintaining Data Accuracy Minor schedule adjustments are downloaded weekly into the system by the service development department. For major service changes (like route or stop changes), the system must be manipulated manually. This is a major effort and takes two staff members approximately six weeks of time before implementation of the changes. Quality Control Since their customer information center uses the same Trip Planner as the one on the Web, the information center staff serves as quality control agents. Their feedback is invaluable in learning where glitches are in the system and where changes need to be made. 34 Overall, approximately $1 million went into the trip planning system.

5-42 5.5.4 Outcomes / Benefits Metro feels that its trip planning program gives people information and creates a good image for transit. It gives customers the impression that the transit system is "forward- looking, current, and part of the technology age,” a sentiment also expressed by managers in San Diego. While Metro managers have not seen a significant drop in call center calls, they believe that the trip planner has likely taken some of the burden off the call center or at least altered the nature of calls received by customer service agents. 5.5.5 Planned Improvements Real-time Information Twin Cities Metro is in the process of installing GPS on their buses, and once this is completed, they may be able to work on having real-time or near real-time customer information on the Web. CRM The Twin City transit managers do not have plans to develop customized account services for customers, because they believe it would be too expensive to develop and funding is an issue. However, they are currently looking at implementing a new feedback system, similar to the one Portland has. Portland's system captures what the user has entered into the AIP system (such as origin and destination) so that when a customer service agent looks at their comment (or problem), they see what the person entered and is better able to diagnose the problem. 5.6 Southeastern Pennsylvania Transportation Authority (SEPTA) In the Philadelphia region, SEPTA currently provides automated itinerary trip planning, and provides dynamic information on its Web site. Currently, it does not have a program for automatic e-mail notification, or a program to personalize its communications with its customers. The itinerary planning feature was implemented in November 2000. The AIP program has two parts – a desktop version for their customer service agents and the Internet version for customers. 5.6.1 System Design and Functionality SEPTA's itinerary planner, TransitQuest, is slated for a number of changes that will improve upon the functionality and design seen in the existing system. Figure 5.33 shows TransitQuest's data input form. The current system only recognizes a pre-defined set of origins and destinations (primarily landmarks, intersections, and transit stops); therefore, the customer cannot truly enter an address into the system. For example, in Figure 5.34, the customer has entered "100 Main Street" as the origin and the system has returned with a drop-down list of valid origins from which the customer must choose. When its AIP was initially developed, SEPTA had hoped it would be a useful tool for tourists and occasional riders, possibly enticing these people who would otherwise not ride transit. However, while the system does offer a high level of functionality, the agency has since found that some of the features are not transparent to people who are not already familiar with the system (such as having to know what the transit stops are, as

5-43 Figure 5.33: TransitQuest Input Form Figure 5.34: SEPTA's Error-Trapping Mechanism for Origins and Destinations (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program)

5-44 discussed above). Therefore, improving usability of the AIP has been a major impetus in the decision to undergo a significant system design. TransitQuest's input form has a few notable features that were originally developed to improve the robustness of the system, but are likely to be redesigned in the next phase of development. One feature of interest is the "Means of Transport" button, which takes the customer to the screen shown in Figure 5.35. This screen allows the customer to limit the transit modes included in the itineraries by checking or un-checking the boxes under the symbols for these modes. A legend at the bottom of the page describes the symbols used to represent different modes in the system. Additionally, this screen allows the customer to specify whether to include only direct connections in the itinerary, a feature that is often seen on air travel planning sites (such as Expedia or Travelocity35), but rarely seen on transit AIP systems. Figure 5.36 shows the result of hitting the "Help" button on the itinerary planning input form. The help screen steps the customer through each stage of the itinerary planning process and makes clear that the tool only recognizes stations, stops, intersections, or landmarks. The "Station Schedules" button provides functionality similar to that seen in Ventura County's AIP system, allowing the customer to see all of the scheduled departures from or arrivals to a specific stop throughout the day. Figure 5.37 exhibits the input screen for the Station Schedule tool. Geographically, the functionality is similar to that in the AIP in that only stations, stops, landmarks, or intersections are recognized. The customer can then select whether to view departures or arrivals for the selected stop or station. Figure 5.38 illustrates the result of requesting a station schedule. On the top of the page, the customer can select the time period for which he/she would like to view the schedules. All of the buses serving the selected stop are shown for that time period. The customer can then view the entire schedule for a route by clicking on the route number, or view the station schedule for a different station by clicking on its name. Additionally, some basic information about the station is presented at the bottom of the schedule page (not shown in the Figures). The output produced by TransitQuest, which includes a number of different features, is shown in Figure 5.39. The AIP produces a number of itineraries, which are briefly summarized on the original output screen. The customer can then choose to look at earlier or later itineraries by clicking on the up and down arrows above and below the itineraries shown. The summary itinerary descriptions show the departure and arrival time, total travel time, number of transfers, and modes utilized. The customer can then select the desired itineraries and view more detailed descriptions, as shown in Figure 5.40. The detailed itinerary descriptions show arrival and departure time for each leg of the trip, as well as which legs are handicap accessible. Additionally, the customer can click on the route number to obtain a full schedule for that route, or on the station name to pull up a station schedule, illustrating the coordination between the AIP and the station 35 See the Expedia page at http://www.expedia.com/ or the Travelocity page at http://www.travelocity.com/.

5-45 Figure 5.35: Result of Clicking on TransitQuest's "Means of Transport" Button (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.36: TransitQuest Help Screen

5-46 Figure 5.37: SEPTA's Station Schedule Request Form Figure 5.38: Result of Station Schedule Request

5-47 Figure 5.39: Initial Output from TransitQuest (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.40: TransitQuest Itinerary Details (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.)

5-48 schedule feature. One drawback of the detailed screen is that the legend does not include a description of the mode symbols. In order to view the legend for these symbols, the customer would have to return to the original input screen and click on the "Means of Transport" button. On the bottom of the itinerary planning output pages are a number of buttons that the customer can click on to obtain more detail about the trips. The "Trip Guide" button takes the customer to the screen shown in Figure 5.41. The trip guide shows every stop on every leg of each itinerary. The customer can also choose to view TransitQuest's connection graphics by clicking on the "Graphics" button, as seen in Figure 5.42. Whereas the trip guide provides a text description of the stops along the various routes, the connection graphics show a schematic of the routes. Customers can look at different legs of an itinerary by clicking on the "next connection" or "previous connection" buttons, and can toggle the stop names on and off by clicking on the "+" and "-" symbols. Additionally, the "Print View" button allows the customer to print out a printer-friendly version of the itinerary, without unneeded graphics. The "Return" button takes the customer back to the original itinerary planning input screen, but automatically reverses the origin and destination locations. 5.6.2 Objectives / Promise One of the major objectives in implementing automated itinerary planning on SEPTA’s Web site was to allow their customers to plan trips without a human interface. In this way, customers have better access to information and some of the strain is taken off the call centers. A primary consideration in designing the system was the type of skills that would be required by telephone agents to be able to use the trip planner. Before they had the automated system, customer service agents essentially had to be transit system experts in order to be able to plan trips for people who called in. When they hired new agents, they would have to go through several weeks of training and, in reality, it would take a couple of years for them to know the system well. Now that the trip planning function isautomated, training for agents is only two weeks in duration and the agents no longer have to become experts on the system. Essentially, the human intelligence necessary has been reduced because the system is now intelligent and does the thinking for the agents. One of the other considerations in system design was consistency of the information provided to customers. Prior to automation, two different people could call in asking about the same trip, talk to two different agents, and get two different itineraries. Now, there is consistency in the itineraries provided. When SEPTA designed the system, they were really thinking more about attracting new riders and tourists than about serving existing customers, which is why it was very important to allow customers to enter landmarks for origins and destinations (tourists often know locations as landmarks rather than addresses). However, the agency believes they missed the mark somewhat in terms of designing the system for new riders and tourists since origins and destinations are defined as stops on the system. In other words, customers have to be familiar enough with the system to be able to enter acceptable origins and destinations, and new customers and tourists often do not have this level of familiarity.

5-49 Figure 5.41: TransitQuest Trip Guide (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.42: TransitQuest Connection Graphics (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.)

5-50 The agency will be fixing this aspect of the system (to have it recognize addresses) in their next phase of development. 5.6.3 Implementation Issues Designing the System Both the on-line version of the trip planner and the desktop version for the customer service agents were done by a team headed by Teleride, which is part of a large European firm called HaCon36. Teleride is also doing the next phase of the project. Most of the implementation was standard – the only thing SEPTA customized was putting in their data and making it look like a SEPTA interface (consistent with the Web site). The changes they are currently doing are partially standard and partially customized. The agency conducted focus groups with riders, non-riders, customers of the trip planner, and non-customers alike, both in the original design of the system and in the re-design that is currently occurring. However, the majority of feedback comes from the customers of the trip planning system. Costs The entire project, both desktop and Web components, cost $1.8 million (including software, hardware, training, installation, etc.). The most costly part was surveying and geocoding SEPTA’s stops, a task that Teleride had a subcontractor do. The second phase is also being done by Teleride and will be completed by the end of June 2002. The cost for these augmentations to the system is $130,000. Changes are being made to the Internet version of the trip planner only – not the system used by customer service agents. Maintaining Data Accuracy All of SEPTA’s scheduling is done by Trapeze. The agency makes major schedule changes 3-4 times per year, although minor schedule adjustments are made on a more frequent basis. When they make major adjustments, Trapeze puts out a file for the downstream systems (they have two of these). The other systems, such as the trip planning systems, pick up on these files. Minor schedule changes are easy because the files are just replaced. Bigger changes (like changes to routes/stops) take more effort. Changes are first made to the system used by the customer service agents and then transferred to the Internet system. They have an automated system that looks at old schedules and new schedules and tells them where the differences are that need to be resolved – staff then manually have to go in and make the changes. Quality Control SEPTA does quite a bit of quality control on their itinerary planning system. Often, the customer service agents perform the quality control function. They also have a staff member dedicated to the trip planner, and this individual regularly performs quality control on the system. 36 Visit HaCon's Web site at: http://www.hacon.de/hafas_e/index.shtml

5-51 5.6.4 Outcomes / Benefits Managers at SEPTA feel that the AIP feature gives the agency a good reputation. While they do not necessarily think the short-run benefit is greater than the cost of developing the system, they do believe the benefit will be realized in the long-term. It will take a while to realize the return on their investment since the investment was so significant. There is also a significant benefit for tourists since they can use the system to Figure out how to get from place to place via public transportation. Usage Patterns SEPTA tracks usage of their itinerary planner by the number of planned itineraries. The number of trips planned has essentially reached a plateau at 11,000 – 12,000 per month. The agency hopes that the enhancements they are currently making will dramatically increase this number, possibly even double it. Impact on Call Centers Whenever a function is automated, the managers always think about the effect on customer service agents. However, in reality, it is difficult to measure the actual effect for two reasons. Firstly, there are always people who call and cannot get into the system, so they get a busy signal. Therefore, it may be difficult to detect decreases in calls since it’s possible that people who couldn’t get into the system before are now getting in. Secondly, even if there is a decrease in calls, it is difficult to attribute the decrease to any particular automated function. What is likely to change is not the number of calls, but rather the complexity and length of calls since people with simple questions can now get that information through the Internet or the automated voice response system. The call centers use a different version of the trip planner, although it was designed by the same contractor as the Internet version. The Web version has most of the functions that the customer agent version has, but the look and feel is different because the two applications are geared towards two different audiences. However, the algorithm used for producing itineraries is the same for both systems. The data for the Internet system is stored at the Internet Service Provider (ISP) and the data for the customer service system is stored on a server in SEPTA’s building. They did it this way for security purposes – they did not want to give the public direct access to any data in their system. 5.6.5 Planned Improvements Improvements to the Automated Itinerary Planner SEPTA receives many suggestions from customers, mostly saying, “I really like the trip planner, but have you considered adding x, y, or z.” The two things they hear most is that people want to know the calculated fare for each itinerary and that they want to be able to specify origin and destination by address. In the next phase of development, SEPTA will be adding both of these functions. Specifically, Phase II will include the following system improvements: • The system will operate at the address level – stops will be geocoded on a map and the system will have an algorithm that will calculate where the closest stop is to an address; • Walking directions and a stick walking map will be provided;

5-52 • Total fare will be calculated for each itinerary; and • The interface will be redesigned to be more intuitive and user-friendly. Real-time Information, E-mail Notification, and CRM SEPTA does not currently have an AVL system, but recently received the funding for one. The system will be installed on trains first and eventually on buses as well. They are currently working on an e-mail notification system, which should be on-line in the Spring of 2002. This system will not be a CRM application per se; rather, customers will sign-in once on a sign-in screen and indicate which routes they want to receive information for. SEPTA does not have plans to do any customization like that being done by New Jersey Transit and the Utah Transit Authority (see Section 6). The managers do not believe the benefit of such a system would be worth the cost of developing it. 5.7 Anchorage Public Transportation At Anchorage Public Transportation (APT), Internet-based services include automated itinerary planning, but currently do not include any real-time information, electronic notification services, or any personalized customer services. The Anchorage case study is included in our review because of the early and innovative commitment to itinerary trip planning undertaken in Alaska. It is the story of a transit rider who built a stop-to-stop itinerary trip planning system out of a personal commitment to transit. The system debuted on the Internet about four years ago, making it one of the earliest trip planning systems documented in this study. The developer of the system worked with the company providing the agency’s overall Web services, and supplied the system on his own time. Now that the agency is seeking a major upgrade, they are seeking competitive bids to advance the original work. 5.7.1 System Design and Functionality APT’s Dynamic Route Generator is a very simple AIP that provides basic functionality that was developed at a very reasonable price. The existing system does not attempt to provide address-to-address trip planning capability, but rather makes a series of simplifying assumptions. The system is based on the existing “time points” catalogued by the bus agency, i.e., those points where the driver makes a cross check to see if the bus is ahead of, or behind, the published schedule. The system generates itineraries by referring to a matrix with key time-points along the routes on each axis. Because there are so many stops in the bus system, the agency could not put a full list of bus stops in the trip planner; thus the decision to include only key time points. Anchorage's simple input form is shown in Figure 5.43. The form includes the following trip parameters: • Starting Location and Destination Location - the customer selects from a drop- down list of time points in the bus system; • Departing After and Arriving Before Fields - the customer can choose to depart and/or arrive anytime, or can select from a drop-down list of times, offered in 30- minute increments;

5-53 Figure 5.43: APT’s Dynamic Route Generator Input Form • Travel Day - the customer can choose to travel on a weekday, Saturday, or Sunday; • Transfers - the customer can either choose to accept one transfer or can specify that only trips without a transfer are acceptable; • Sorting of Results - results can either be sorted by arrival time, departure time, or total travel time; and • Maximum results - this field is where the customer specifies the number of itineraries to show. The AIP can show 5, 10, 15, or all itineraries generated. Once the customer has completed all of the input fields, she can then click on the "Show Results" button, which brings up the formulated itineraries in the right-hand frame of the page, as shown in Figure 5.44. The original input remains in the left-hand frame. The output page tells the customer the number of itineraries generated, whether routes without a transfer were available, and the total travel time for each itinerary. In order to change certain parameters of the trip (such as departure or arrival time), the customer can simply change the appropriate fields in the input form and re-run the AIP tool. Usability of the Trip Planner The agency’s statistics from about a year ago said that people took 35 to 60 seconds to generate the first report, and then often generated additional reports. Once the initial report had been generated, customers took less time to generate additional reports since they were better acquainted with the system.

5-54 Figure 5.44: APT’s Dynamic Route Generator Results (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) 5.7.2 Objectives / Promise According to APT, usage statistics show that 80% of customers are local and 20% are from out-of-town. Their primary target market is, therefore existing customers, although they recognize that they likely get some tourist use of the trip planning system as well. The trip planner gives riders the ability to have easy access to bus schedules and to specify the time at which they want to travel. The agency has found that most of the activity on the trip planning trip is for planning current trips rather than future trips. They also know that they get many hits from outside of Alaska, so, as stated above, the tool is probably useful for the tourist market. Since recent studies have found that 60% of the population in Alaska has Internet access, they believe the trip planner is a necessary feature to offer their customers. 5.7.3 Implementation Issues Since APT has such a simple trip planning system, they have not really had any implementation problems. However, as will be discussed in a later section, the agency is planning to make major improvements to the itinerary planner. 5.7.4 Outcomes / Benefits Agency managers feel that the minimal investment in the trip planner has paid off, and that it helps them provide good customer service for their riders. It makes them more

5-55 customer-service oriented and provides them with a tool to increase communication with their customers. Usage Patterns APT’s trip planner gets approximately 50 to 100 hits per day. The agency tracks the number of hits to the page and whether hits are in-state or out-of-state. The schedule page gets the most hits; the trip planner is second. Their statistics from a year ago estimated that they get 15 - 20% repeat usage. Impact on Call Centers The automated system has brought about a reduction in calls to APT's call center. However, the limited-featured itinerary trip planner is not used in the call centers; agents just use schedule books. The agents know the routes and the geography very well, so it is quicker for them to just look up routes by hand than to use a computer. This allows them to provide more personalized information to the customers, particularly since the itinerary planner has a very limited set of origins and destinations. 5.7.5 Planned Improvements Improvements to the Automated Itinerary Planner Anchorage Public Transportation is planning to redesign the system to deal with address- to-address trip planning. They have plans to integrate their GIS system into the trip planner so people will have access to an interactive map for selecting origin and destination. The improvements will provide the option to enter an address and will provide a list of common landmarks from which the customer may select. In the new system, they would also like to have walking directions and a walking map. Real-time Information Anchorage currently has GPS in their vehicles, which is used to run the annunciation system on their buses. They are in the process of acquiring the software that will allow them to put real-time information on the Web. They will also have kiosks at key locations, such as shopping malls and transit hubs. These kiosks will have access to real- time transit information via their Web site. Additionally, they hope to add an e-mail notification service with the addition of real-time customer information, as well as notification via beeper, cell phone, or PDA. All this is slated for implementation in two years. CRM The agency is also hoping to move towards a strategy of Customer Relationship Management. As noted above, they are planning to add real-time information and e-mail notification. They have not really thought of doing registration to personalize the customer experience, but think it is a good idea. For its paratransit system, every customer has a personalized file, and the agency thinks that CRM would be like having something similar on the fixed route system.

5-56 5.8 Greater Manchester Public Transport Executive The Greater Manchester Public Transport Executive's (GMPTE's) Web site offers automated itinerary trip planning, but neither real-time information, nor programs to notify customers of system conditions are available. The itinerary planner was added to the Web about three years ago. The case study of the GMPTE site provides a good example of the evolution of itinerary trip planners from early text-based systems to the growing direction towards map-based systems, fully integrated with local GIS. 5.8.1 System Design and Functionality The existing GMPTE itinerary planning system (called the "Journey Planner") represents an interesting example of early, text-based systems. As such, it does not attempt to provide address-to-address itinerary planning. Rather, it uses a rather elaborate combination of two data entry systems for the specification of origin and destination by the customer. As shown in Figures 5.45 and 5.46, a limited number of landmarks and local streets are included in the drop down menu associated with trip origin and trip destination. If the customer cannot find a meaningful landmark from the short list, he/she can enter a word to help narrow the search of locations actually in the system. In addition to the origin and destination location, the Journey Planner allows the customer to define a number of other trip criteria, including: • Day of Travel - the customer can either select the day of week from a drop-down menu or can enter the desired date of travel; • Departure or Arrival Time - the customer selects either departure or arrival time and then can either choose to click on the time from a drop-down menu or can enter the time in the corresponding text box; • Travel Via a Specific Location - if the customer would like to travel through a certain city, it can be specified in one of these fields; and • Exclusion of a mode - customers can choose to exclude travel by bus or by rail. Figure 5.47 exhibits the output produced by GMPTE's Journey Planner. The AIP presents the customer with a number of different itineraries, and includes links to timetables and printable versions of the itineraries. Each stop along the route is shown schematically for each itinerary. Clicking on a station name allows the customer to access a map of the station location, as shown in Figure 5.48. These maps are provided by an outside vendor, Multimap.com37. Figure 5.49 illustrates the aerial photographs available on the vendor's Web site. These maps and photographs, on which the station location is circled in red, can provide additional context and geographic reference for customers unfamiliar with the station area. 37 View Multimap.com's Web site at http://uk.multimap.com/

5-57 Figure 5.45: GMPTE's Itinerary Planning Input Form Figure 5.46: Error Trapping for Origin or Destination (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.)

5-58 Figure 5.47: GMPTE's Journey Planner Output Screen (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.48: Link to Mapping Page from GMPTE's Journey Planner

5-59 Figure 5.49: Aerial Photos Showing Location of Transit Stop (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) 5.8.2 Project Objectives As explained to us in the J-09 interview, the trip planner allows customers to find their way around the network and look at different ways of getting from point A to point B. It also allows them to print out hardcopies of timetables, which they cannot do if they talk to a live agent. Additionally, they can print out maps showing the locations of relevant stops. Since the call center is only open from 8am to 8pm, the on-line trip planner offers an alternative for getting information during hours when then call center is closed. In addition, since it provides an alternative to live agents, it takes some of the load off the call center. According to GMPTE, when they first initiated the itinerary planning system they were really thinking about serving their existing customers, but had tourists and occasional riders in the back of their minds as well. They have since realized that the application is a good tool for attracting new riders and tourists to transit. 5.8.3 Implementation Issues Costs The original itinerary planning system cost about £5,000 – £10,000. The license fee is about the same. The new system is costing them about £40,000 and will also have a licensing fee.

5-60 Maintaining Data Accuracy The agency maintains a transit database – in this database, routes are set up as a series of stops, which are geocoded into the system. This information is what they had to give the contractor – the trip planner feeds off this database. Schedules are being updated on a continuous basis. Operators are permitted to change schedules with 56 days notice. Quality Control GMPTE does not have a formalized quality control system, but staff enter the system from time to time and generate itineraries to test the system. Customers can also e-mail the agency if they are having trouble with the system, which serves as a method of quality control. Additionally, if customer service agents find problems with the itineraries generated, they tell their supervisors so that the problems can be fixed. Operational Problems GMPTE had one or two operational problems initially with the existing trip planner. They had problems with the data and it took a while for their vendor to deliver the product because they were such a small company. It has also taken a long time to get the new system up and running, primarily because of some data interface issues and because they have been doing a significant amount of testing prior to going live with the system. 5.8.4 Outcomes/Benefits GMPTE believes that, although they are not really a “business,” but rather a public service, the trip planner adds a good dimension for their customers. They estimate that the system is meeting expectations about 50% of the time – the new system they are developing (see later discussion) should be much better. Their system was top notch when it was installed, but customer expectations have changed in the past couple of years. Impact on Call Centers Impact on call centers was a secondary consideration in deciding to put a trip planner on- line. It is difficult to make any solid cause and effect connection between the trip planner and the change in number of calls to the customer service agents. The call center agents are also using the itinerary planner, although they have a copy of the program on their computers and are therefore not using the Internet. 5.8.5 Planned Improvements Improvements to the Automated Itinerary Planner At the time of its implementation, the existing GMPTE system was one of the most advanced on the market. However, the agency found that it worked well for customers on the Internet, but not very well for their call center since not enough detail was provided. Consequently, they decided to vastly upgrade the tool. They had a company called Information Limited look at a number of trip planners on the market and recommend one. The one they chose is by an Australian company called OpCom38 – the 38 Visit OpCom's Web site at: http://www.opcom.com.au/

5-61 actual company that did their trip planner is called Action Information Management. Action Information Management won the contract in a competitive process – the company is a provider of map-based software and telecom software and is just moving into supplying trip planners. The company has a base in the development of 911 emergency access systems. The new tool is now being used in the call center, and will be available on-line within the next few months. Their new system will have mapping capability, walking directions, more input options (such as parameters like shortest time, fewest transfers), and be much faster than their current system. The new journey planner will also provide information to the Authority’s new network of electronic information points, which will soon begin to be installed at bus stations and other transport interchanges across Greater Manchester. The new software will allow for faster and more efficient update of the information points to ensure that public transport customers always have access to the most up-to-date information possible. There will be two phases of implementation for this new trip planner. The first phase is to put the basic trip planner on the Web. The second phase will be to develop a more sophisticated front-end, including mapping capability (so a customer can choose an origin and destination by clicking on a map). Action Information Management is dong both phases. The GMPTE has explained that the new system “will eventually replace the existing text- based journey planner available via GMPTE’s Web site. It will be a much more powerful and easy to use tool for passengers wanting access to integrated timetable and route information.” Real-time Information GMPTE currently has a contract for equipping 300 buses with a GPS system. GMPTE is an oversight agency for service delivery in the greater Manchester region, so they deal with multiple modes of transport. Initially, the real-time information will just be available at the bus stops, but they intend to also make it available on the Internet at some point. They also hope they will be able to integrate it somehow with the trip planner. The call center staff will have the ability to see the real-time location of buses on a map during the first phase of implementation.