Business Models for Mobile Fare Apps (2020)

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.

16 This chapter presents the results of an online survey of transit agencies conducted in the spring of 2019. The first section in this chapter summarizes the data collection procedure, the second section presents the results organized by topic, and the final section summarizes key findings. Survey Data Collection Procedure The survey data collection procedure is summarized in this section. This includes developing the sampling plan, drafting the survey instrument, and collecting survey data. Survey Sampling Plan First, the survey sampling plan was developed. To create a sampling frame, a list of transit agencies that had mobile fare payment apps was compiled. This list included agencies that met the following criteria: • The agency or operator is located in the United States or Canada. • The agency had deployed a mobile fare payment app as either a pilot program (e.g., a tempo- rary deployment) or a permanent solution. • For multiple agencies within a region that shared a common app (such as Pace/CTA/Metra in Chicago), each agency was contacted separately because agencies could have different approaches. • Transit agencies that contract service out to private operators were included. For each agency, a point of contact was identified and an e-mail address for each contact was gathered. In total, a list of 105 e-mail addresses was assembled. E-mail was used as the primary form of communication because the survey was conducted online using the software Survey Monkey. Survey Instrument The survey instrument was developed in an iterative process in parallel to creating the survey sampling plan. First, a document outlining draft survey questions was provided to the TCRP panel for review. After receiving feedback on the draft questionnaire, the survey questions were updated and programmed into a web-based survey software program. Next, the online survey was pretested with the TCRP panel and a small number of volunteers who had prior experience with mobile fare payment apps. Input from the pretest was incorporated into the survey, and the survey instrument was finalized in early March 2019. The final version of Transit Agency Survey C H A P T E R 3

Transit Agency Survey 17 the survey questionnaire is available in Appendix B. There were 11 sections by topic, which are as follows: 1. Respondent Information, 2. Agency Information, 3. Background Information on Mobile Fare Payment Apps, 4. Mobile Payment App Fare Policy, Activation, and Validation, 5. App Developer, 6. Contractors, Roles, and Responsibilities, 7. Costs and Funding Sources, 8. Other Products and Tools, 9. Performance Metrics, 10. Motivation, Challenges, and Future Plans, and 11. Wrap-up, Future Case Studies, and Other Agencies. The first two sections (Respondent Information and Agency Information) and the last section (Wrap-up, Future Case Studies, and Other Agencies) were largely for administrative purposes to gather contact information and ensure a diverse sample of agency respondents. Therefore, the results from these three sections are not presented. The other eight parts pertain to mobile fare payment apps, and key findings on these topics are summarized in the Survey Results section. Survey Data Collection Invitations to complete the survey were sent to transit agency representatives in mid-March 2019. The survey remained open for approximately 8 weeks, and follow-up e-mails to remind participants to complete the survey were sent periodically throughout this period. The online survey was closed in mid-May 2019. After data cleaning, 62 unique, usable responses remained. Responses were deemed usable if the participants completed at least the first three sections of the survey, which included background information on their mobile fare payment app. Unless otherwise noted, all of the results presented in the following section are for 62 transit agencies (n = 62). Survey Results by Topic This section presents the survey results organized by topic, beginning with background information on mobile fare payment apps. Background Information on Mobile Fare Payment Apps This section gathers a snapshot of the current state of mobile fare payment apps in the United States and Canada. Results from these survey questions are presented in the following paragraphs, focusing on quantitative results that demonstrate industrywide trends. • Mobile Platforms/Devices: Survey respondents were asked what device riders could use to access their mobile fare payment. All 62 respondents (100%) selected both Android and iPhone/iOS devices. This is consistent with mobile phone industry trends, in which Android and iPhones are known to be widely adopted by consumers. • System Status: Survey respondents were asked about the current state of their mobile fare payment app. The majority (48 of 62 = 77%) said that their mobile fare payment app was a permanent deployment. Nearly one quarter of respondents (13 of 62 = 21%) stated that their mobile fare payment app was part of a pilot program. This may be because agencies like the

18 Business Models for Mobile Fare Apps opportunity to test new technologies prior to permanent deployment; alternatively, it may help to simplify the initial procurement process. Last, one respondent selected “other” because that agency was in the process of transitioning to a new fare payment system. • Year of Deployment: The next question asked when their mobile fare payment app was made available to riders, and the results are shown in Figure 4. The first mobile fare payment app to deploy was NY Waterway in 2011, two agencies launched in 2012 [the Massachusetts Bay Transportation Authority (MBTA) in Boston and CapMetro in Austin], and two more agencies made their apps available in 2013 (DART in Dallas and NJ TRANSIT in New Jersey). The remaining agencies launched in 2015 to 2019, demonstrating rapid growth. It is also worth highlighting that multiple agencies (7 of 61 = 11%) responding to this question launched their mobile fare payment app in 2019, but the year was less than halfway done at the time of survey data collection. Percentages shown in Figure 4 may not sum to 100% due to rounding. • Transit Modes Accepting Mobile Fare Payments: Survey respondents were asked about the modes in their transit system that riders could access using a mobile fare payment app. The results are shown in Figure 5, which reveals that the majority (52 of 62 = 84%) of agencies responding to the survey accepted mobile fare payments on buses (either local, express, or bus rapid transit service). Numerous respondents accepted mobile fare payments on light rail (15 of 62 = 24%) and commuter rail (15 of 62 = 24%). Only 2% of respondents selected heavy rail. The lack of agencies accepting mobile fare payments on heavy rail is likely due to the validation process, which is typically done via fare gates on heavy rail systems; mobile fare payment validation is discussed in more detail in the next section. Some respondents wrote in other answers, which included responses such as streetcars, cable cars, and water taxis. Last, the percentages shown in Figure 5 do not sum to 100% because respondents could select all that apply. 2% 3% 3% 0% 8% 16% 31% 25% 11% 2011 2012 2013 2014 2015 2016 2017 2018 2019 0% 5% 10% 15% 20% 25% 30% 35% Note: as of spring 2019. Figure 4. Year of mobile fare payment app deployment (n = 61). 84% 2% 24% 24% 11% 29% 23% Bu s (L oc al B us , Bu s R ap id Tr an sit , a nd /o r Ex pr es s Bu s) H ea vy R ai l Li gh t R ai l C om m ut er R ai l Fe rry D em an d- R es po ns iv e Tr an sp or ta tio n (e .g ., Pa ra tra ns it) O th er (p le as e sp ec ify ) 0% 20% 40% 60% 80% 100% Figure 5. Transit modes accepting the mobile fare payment app (n = 62).

Transit Agency Survey 19 • Regional Integration: To further understand the scope of each mobile fare payment system, survey respondents were asked if other transit agencies or operators in their region used the same mobile app for fare payment. Many transit agencies (35 of 62 = 56%) said no, and a smaller number (23 of 62 = 37%) said yes. The remaining respondents selected “other” and wrote in responses such as “not yet but will very soon.” The results of this question demonstrate that many geographic areas did not have integrated mobile fare payment apps, but a number of regions planned to, and this trend is likely to continue. • Accessibility Features: Because transit agencies have diverse riders with varying abilities to use apps, one question on the survey asked about the feature(s) transit agencies made avail- able in their mobile fare payment apps to increase accessibility. Survey respondents could select all that applied. The results reveal that numerous agencies (25 of 62 = 40%) offered large fonts, and another 40% also had high contrast in their apps; both of these features can help those with visual impairments. Many respondents (18 of 62 = 29%) also had an audio assist feature, which can facilitate app use by those with hearing impairments. • Other Forms of Fare Media: Another background question asked survey respondents what other forms of fare media were accepted by their transit agency, and the results are shown in Figure 6. Most transit agencies continued to accept cash payments; paper tickets and magnetic stripe tickets were also common. Some respondents wrote in other answers, which included responses such as wearables (e.g., watches), tokens, and student identification cards. Last, it should be noted that the percentages shown in Figure 6 do not sum to 100% because respondents could select all that apply. Mobile Payment App Fare Policy, Activation, and Validation This section presents the results of questions about the fare policy available through mobile payment apps, the process for activating mobile fare products, and the process for validation. • Fare Products: Respondents were asked two questions about the fare products available in their agency’s mobile app. The first asked what type(s) of fare products riders could purchase through their mobile fare payment app, and respondents could select all that applied. The results are shown in Figure 7, which reveals that most agencies offered regular single-ride fares (59 of 62 = 95%) and reduced fares such as student or senior fares (56 of 62 = 90%) in their mobile fare payment app. Period passes such as weekly or monthly passes were also common (51 of 62 = 82%), as were multiple-ride fares such as 10-ride tickets (43 of 62 = 69%). Some agencies wrote in other fare products, such as special event tickets. • Availability of Fare Products: Survey respondents were asked to describe the availability of the fare products offered through their mobile fare payment app, and the results are shown 16% 42% 58% 68% 97% 23% Contactless bankcard / prepaid card Smart cards Magnetic stripe tickets Paper tickets Cash Other 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Figure 6. Other forms of fare media (n = 62).

20 Business Models for Mobile Fare Apps in Figure 8. Nearly half of agencies (29 of 62 = 47%) stated that they offered all of their fare products in their mobile fare payment app, and many others (26 of 62 = 42%) made most of their fare products available through their mobile fare payment apps. • Activation: After riders purchase fare products via their mobile fare payment app, passengers often need to take an additional step before the fare product can be used, which is known as activating their mobile ticket. Activation of a mobile fare product starts the time period during which the product is valid, and this is particularly important for period passes such as weekly or monthly passes. The process of activating a fare product can be performed in one of two ways. The first way is online activation, which requires that the app user have a cellular network or Wi-Fi connection to activate their mobile fare product. The second way is offline activation, in which the fare product has been stored locally on the app user’s phone and does not require a cellular or Wi-Fi connection to activate the ticket. Survey respondents were asked how passes purchased through their mobile fare payment app could be activated, and half (31 of 62 = 50%) stated that a rider’s mobile phone could either be offline or online when passes were activated. Numerous agencies (24 of 62 = 29%) stated that the rider’s phone must be online when activating a ticket. Online activation may provide increased security to ensure that passes are valid; however, because of the dispersed nature of many transit systems, there are likely areas such as tunnels underground with limited cellular and Internet availability. 95% 69% 82% 90% 19% Regular single ride fare Multiple ride fares Period passes Reduced fares Other 0% 20% 40% 60% 80% 100% Figure 7. Fare products in the mobile fare payment app (n = 62). 47% 42% 2% 5% 5% All fare types are offered through the mobile fare payment app Most fare types are offered through the mobile fare payment app Some fare types are offered through the mobile fare payment app A few fare types are offered through the mobile fare payment app Other 0% 10% 20% 30% 40% 50% Figure 8. Availability of fare products in the mobile fare payment app (n = 62). Activation: The process of making a mobile fare product valid for a given period of time. Online Activation: An Internet connection is required to activate a mobile fare product. Offline Activation: An Internet connection is not required to activate a mobile fare product.

Transit Agency Survey 21 • Primary Method of Validation: Transit agencies require a mechanism to ensure that fare products purchased through the mobile fare payment app are valid. To explore this, survey respondents were asked two questions about the validation process. The first question asked about the primary method for validating fare products purchased through their mobile fare payment app, and the results are shown in Figure 9. As can be seen, the majority of respondents (54 of 62 = 87%) selected visual validation (e.g., by a conductor, inspector, or operator). • Additional Methods of Validation: Survey respondents were then asked a second question about additional methods for validating fare products purchased through their mobile fare payment app, and the results are shown in Figure 10. Many respondents selected QR Codes/ barcodes (19 of 62 = 32%). A small number of survey respondents selected Bluetooth (3 of 62 = 5%) or near field communication (4 of 62 = 7%). These results demonstrate that mobile fare payment systems largely relied on transit agency staff (conductors, inspectors, or drivers) to ensure that tickets were valid; however, there is likely to be increasing use of other technologies (e.g., QR Codes, NFC, or Bluetooth) in the future. App Developer, Contractors, Roles, and Responsibilities This section presents the results of questions about the primary party responsible for mobile fare payment app development and transit agency relationships with vendors, including roles and responsibilities. • App Developer: Survey respondents were asked who was responsible for development of their mobile fare payment app. Nearly all (61) respondents said that a vendor was the primary party responsible for software development, which implies that transit agencies were not using in-house staff for app development. Survey respondents were then asked the name of the vendor that was contracted for mobile fare payment app development, and the results 87% 6% 0% 0% 6% Visual validation QR codes / barcode Bluetooth Near field communications Other 0% 20% 40% 60% 80% 100% Figure 9. Primary method of validation (n = 62). 18% 32% 5% 7% 43% 10% Visual validation QR codes / barcode Bluetooth Near field communication None Other 0% 10% 20% 30% 40% 50% Figure 10. Additional methods of validation (n = 60).

22 Business Models for Mobile Fare Apps are shown in Figure 11. The most common answer was the vendor Token Transit; this was particularly common for smaller-sized agencies (in terms of unlinked passenger trips). Medium and larger-sized agencies most commonly hired companies such as Bytemark, Masabi, and moovel (recently branded as REACH NOW). A smaller percentage of respondents selected Americaneagle.com, Conduent, Passport, and Unwire. Additionally, some respondents wrote in other answers, which included responses such as Cubic Transportation Systems, Routematch, and Ecolane. Last, it should be noted that the percentages shown in Figure 11 do not sum to 100% because respondents could select all that apply. • Level of Customization: Survey respondents were then asked to characterize the level of customization done on the app that their agency procured. The most common answer was specific ticket types integrated into the app, which for some app vendors was a straight- forward configuration. Other respondents (12 of 61 = 20%) had major app customizations, such as integrating their app into existing fare payment systems. An important difference in terminology emerged from the variety of answers to this question. In software development, there is a distinction between the terms “configuration” and “customization.” Configuration generally uses existing tools to meet specific require- ments without new code, requiring less work. Customization typically involves writing new code to meet specific requirements and there- fore requires more effort. • Procurement Process: Survey respondents were then asked about the procurement process that was used to acquire their mobile fare payment app. The most common response was a request for proposals (RFP) with a scope that was only for the mobile fare payment app (18 of 61 = 30%). The second most common answer was a pilot program (17 of 61 = 28%). Other responses included an RFP for a mobile fare payment app after a pilot program (10 of 61 = 16%) and an RFP for a larger fare collection system that included a mobile fare payment app (2 of 61 = 3%). Some respondents also wrote in other responses, such as sole source or procured through a preexisting contract. • Specifications: The next question asked how the specifications were written for the procure- ment process, and the most common answer (21 of 60 = 35%) was that the specifications were written in-house at the transit agency. Other respondents did not write specifications 3% 13% 2% 10% 18% 3% 48% 2% 11% 0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% Am eri ca ne ag le. co m Un wir e Ot he r By tem ark Co nd ue nt Ma sa bi mo ov el Pa ssp ort To ke n T ran sit Figure 11. Vendors that were contracted for mobile fare payment app development (n = 61). Configuration uses existing tools to meet specific requirements without new code, generally requiring less work. Customization typically involves writing new code to meet specific requirements and therefore requires more effort.

Transit Agency Survey 23 (17 of 60 = 28%), had a request for information (RFI) process (6 of 60 = 10%), or hired a consultant (5 of 60 = 8%). Some respondents also wrote in other responses, such as jointly writing the specs with a consultant. • Other Vendors: Survey respondents were also asked if they had contractual relationships with other companies for products or services pertaining to their mobile fare payment app. The vast majority of respondents selected no (54 of 61 = 89%); however, the remaining respondents (7 of 54 = 11%) said that they did. Further probing about this revealed that most of these contracts pertained to hardware and were with companies such as INIT, SPX/ Genfare, and Scheidt & Bachmann in Germany. • Roles and Responsibilities: Respondents were asked which party had the primary respon- sibility for various tasks related to their mobile fare payment app, and the results are shown in Table 2. Most vendors had the primary responsibility for payment processing, hosting the app, and PCI compliance, where many transit agencies took the lead on customer service and marketing to riders. Costs and Funding Sources This section presents the results that pertain to the costs and funding sources for the initial development and continuing operations of mobile fare payment apps. Survey respon- dents were first asked about the upfront costs to acquire their mobile payment app. Then, they were asked about the payment processing fees for their app. This was followed by questions pertaining to ongoing operational costs paid to vendors. The results are summarized as follows. • Upfront Costs: The first question asked respondents to estimate the upfront costs to acquire their mobile fare payment app, and the results are shown in Figure 12. More than half of respondents (33 of 57 = 58%) selected that there were no upfront costs, and most of these respondents (23 of 33 = 70%) contracted the same vendor (Token Transit). Moreover, many of these respondents were smaller-sized agencies (smaller in terms of unlinked trips). As can be seen in Figure 12, another 11% of respondents spent $1 to $49,999 in upfront costs, and numerous others (16%) spent between $100,000 and $499,999. For those respondents that had upfront costs, they were then asked about the funding source to cover the initial costs. The most common answer (13 respondents) was the agency capital budget, and the second most frequent answer was a grant (nine agencies). It should be noted that the percentages shown in Figure 12 do not sum to 100% due to rounding. • Payment Processing Fees: Survey respondents were then asked about payment processing fees. Just over half of respondents (33 of 59 = 56%) said that the transit agency covered payment Primary Responsibility for Vendor Agency Othera N/Ab Count (n) Payment processing 85% 7% 8% 0% 61 Hosting the app 98% 2% 0% 0% 61 Customer service for riders 43% 56% 2% 0% 61 Marketing the app to riders 7% 93% 0% 0% 61 PCI Compliance 85% 7% 3% 5% 60 Note: One respondent skipped this question, so n = 61. Numbers are rounded to the nearest percentage and therefore may not sum to 100%. aThe survey contained “Other” as a response, allowing agencies to write in other answers. bThe survey allowed agencies to select N/A if the question was not applicable. Table 2. Roles and responsibilities.

24 Business Models for Mobile Fare Apps processing fees, whereas about one-third of respondents (19 of 59 = 32%) stated that their vendor paid processing fees. The remaining agencies selected other or N/A. • Operating Costs: The next question asked respondents how operating costs were paid to the vendor, and the results are shown in Figure 13. Most agencies had an arrangement with their vendor that was based on a percentage of each fare sold via the mobile app. Some of these arrangements based on percentage of sales included payment processing fees (29 of 57 = 51%), whereas others excluded payment processing fees (12 of 57 = 21%). Another common arrangement was a fixed fee (e.g., flat rate per month or year) either excluding payment pro- cessing fees (6 of 57 = 11%) or including payment processing fees (2 of 57 = 4%). The third arrangement was a flat rate per ticket sold (e.g., 10 cents per ticket sold), which was used by six agencies (combined total including and excluding payment processing fees). Additionally, some respondents wrote in other answers, which included responses that were combinations of the choices (e.g., annual fee plus percentage of each fare), monthly licensing fees, and other software maintenance fees. Respondents for whom this question was not applicable were instructed to select N/A. Last, the percentages shown in Figure 13 do not sum to 100% because respondents could select all that apply. • Percentage of Sales: As a follow-up to the most common answer on the previous question, respondents were asked to quantify the percentage of sales that they paid to their vendor, and 51% 21% 4% 7% 4% 11% 4% 12% Percent of fare including payment processing fees Percent of fare excluding payment processing fees Flat rate per ticket including payment processing fees Flat rate per ticket excluding payment processing fees Fixed fee including payment processing fees Fixed fee excluding payment processing fees N/A Other 0% 10% 20% 30% 40% 50% 60% Figure 13. How operating costs are paid to the vendor (n = 57). 2% 0% 4% 5% 16% 5% 11% 58% $1 0 m illio n o r m ore $5 .0- 9.9 m illio n $1 .0- 4.9 m illio n $5 00 ,00 0-$ 99 9,9 99 $1 00 ,00 0-$ 49 9,9 99 $5 0,0 00 -$9 9,9 99 $1 -$4 9,9 99 No up fro nt co sts 0% 10% 20% 30% 40% 50% 60% 70% Figure 12. Upfront costs (n = 57).

Transit Agency Survey 25 the results are shown in Figure 14. The most common answer was 10%, which was selected by numerous respondents (18 of 44 = 41%); all 18 of these respondents used the same vendor (Token Transit). Most of the respondents who selected 10% (17 of 18) did not pay any upfront costs to acquire their mobile fare payment app, and many of them stated that payment processing fees were included in this percentage. The remaining respondents selected 8% or less; some included payments processing fees whereas others did not. Respondents for whom this question was not applicable were instructed to select N/A. Last, it should be noted that the percentages shown in Figure 14 do not sum to 100% due to rounding. • Items Included in Operating Costs: Survey respondents were asked about specific items included in these operating costs that were paid to vendors, and the most common answers were app patches and upgrades (44 of 55 = 80%), fare updates (39 of 55 = 71%), data center- related costs (35 of 55 = 64%), and PCI-related costs (29 of 55 = 53%). Other Products and Tools This section presents results from survey questions pertaining to other mobile fare payment app-related products or tools. This includes features or tools that were integrated into mobile fare payment apps (e.g., customer facing) and tools that were used by the transit agency (e.g., in the back office). • Customer-Facing Features: Survey respondents were asked what other customer-facing features were integrated into their mobile fare payment app, and the results are shown in Figure 15. The most common features were trip planning (20 of 58 = 34%), transit schedules (also 20 of 58 = 34%), and real-time transit information (17 of 58 = 29%). Some respondents 41% 0% 7% 5% 2% 7% 2% 7% 7% 7% 2% 14% 10% 9% 8% 7% 6% 5% 4% 3% 2% 1% Less than 1% N/A 0% 5% 10% 15% 20% 25% 30% 35% 40% 45% Figure 14. Operating costs paid as a percentage of sales (n = 44). 29% 34% 34% 12% 5% 3% 48% 24% Real-time transit vehicle information Transit schedules Trip planning Reporting Bikeshare Uber/Lyft None Other 0% 10% 20% 30% 40% 50% 60% Figure 15. Other customer-facing features in the app (n = 58).

26 Business Models for Mobile Fare Apps wrote other answers such as service alerts and rate my ride. It should be noted that the percentages shown in Figure 15 do not sum to 100% because respondents could select all that apply. • Integration with Other Apps: Survey respondents were asked if they had a method or tool to integrate mobile fare payments into other third-party apps, which could include an API or an SDK. Most agencies (41 of 59 = 69%) did not, some did (11 of 59 = 19%), and the remainder (7 of 59 = 12%) wrote in other responses. Respondents who said that they did were then asked to describe the method or tool that they used to integrate mobile fare pay- ments into other third-party apps, and many of them mentioned APIs or SDKs from their vendor that provided their app. This appears to be a growing trend in the industry and will be discussed in more detail in Chapter 5. • Fare Evasion: Respondents were asked if they had a method or tool to monitor fare evasion for their mobile fare payment app. Most agencies (32 of 59 = 54%) did not, some (20 of 59 = 34%) said that they did, and the remainder (7 of 59 = 12%) wrote in other responses. Respondents who answered positively were then asked to describe the method or tool that they used to monitor fare evasion, and the write-in responses had a lot of variation. Some respondents mentioned the built-in dynamic security features within apps that have visual validation (e.g., changing color of the day and clocks). A small number of respondents mentioned back- office tools that were built into their customer service hubs. • Tracking Sales: Respondents were asked if they had a method or tool to track sales via the mobile fare payment app, and all agencies who answered this question said that they did (n = 60; 2 respondents skipped this question). They were then asked to describe the method or tool, and there was a wide variety of responses. Many mentioned vendor-provided dash- boards or web portals. Others mentioned regular (e.g., weekly or monthly) summaries provided by their vendor. • Fare Subsidy Programs: Survey respondents were asked if they had a method or tool to manage fare subsidy programs or other partnership programs (e.g., university pass pro- grams) via their mobile fare payment app. Many agencies (35 of 60 = 58%) stated that they did not; however, approximately one-third (20 of 60 = 33%) had a mechanism to manage fare subsidy programs. They were then asked to describe the method or tool, and again, there was a variety of write-in answers. The remaining respondents (5 of 60 = 8%) wrote in other answers. Performance Metrics This section presents survey results about how transit agencies measured the performance of their mobile fare payment app, which was done in numerous ways. • Customer Surveys: Survey respondents were asked if their agency had conducted a survey to measure user satisfaction with their mobile fare payment app. Most agencies (39 of 57 = 68%) said that they had not conducted a survey to measure satisfaction. About one-quarter (14 of 57 = 25%) of respondents had conducted some form of survey, and these agencies were then asked a follow-up question about the results of their survey. Numerous agencies wrote in answers about incorporating questions related to mobile fare payments into their regular (e.g., annual or semiannual) customer satisfaction surveys. Many of the agencies that provided additional details found that customer satisfaction levels were generally high. • Downloads: Survey respondents were then asked if they tracked the number of downloads of their mobile fare payment app. This is possible for white label apps that are branded specifically for some transit agencies. Over half of agencies (33 of 59 = 56%) stated that they did track app downloads. These agencies were then asked to estimate the total number downloads that they had since their mobile fare payment app was launched. Six agencies

Transit Agency Survey 27 estimated 1 million or more downloads, another six agencies estimated between 100,000 and 999,999 downloads, zero selected 50,000 to 99,999, and 17 agencies estimated less than 50,000 downloads. An important caveat to this question is that downloads are difficult to track for a shared app that was used by many of the respondents (from Token Transit) because of the multicity nature of this app, which will be discussed more in Chapter 5. • Accounts: Since mobile fare payment apps are account-based systems, respondents were also asked if their agency tracked their number of mobile fare payment app accounts. Just over half (33 of 58 = 57%) of agencies that responded stated that they did track the number of accounts, and they were then asked a follow-up question to estimate the number of accounts. Three agencies estimated that they had 1 million or more accounts, five agencies estimated between 100,000 and 999,999 accounts, another three agencies selected between 50,000 to 99,999, and 16 agencies selected less than 50,000 accounts. • Percentage of Trips: Survey respondents were asked to estimate the percentage of trips on their transit system made using the mobile fare payment app, and the results are shown in Figure 16. Surprisingly, the most common answer (16 of 51 = 31%) was less than 5% of trips, and the second most common answer was 5% to 14% (14 of 51 = 27%). Respondents that did not know the answer to this question were instructed to select N/A. • Percentage of Fare Revenue: Survey respondents were also asked to estimate the percent- age of fare revenue from their transit system collected using the mobile fare payment app, and the results are shown in Figure 17. Similar to the previous question, the most common answer (19 of 53 = 36%) selected was less than 5%, and many of these respondents (14 of 19) contract with Token Transit. The second most common answer (16 of 53 = 30%) selected was the range 5% to 14%. Respondents that did not know the answer to this question were instructed to select N/A. • Other Performance Measures: Survey respondents were also presented with an open-ended question asking for any other measures of success that their agency collected or monitored to understand the performance of their mobile fare payment app. Numerous respondents wrote in that they tracked customer complaints. Additional answers included app ratings, active users, and driver comments. 0% 2% 6% 4% 8% 27% 31% 22% More than 75% 50-74% 35-49% 25-34% 15-24% 5-14% Less than 5% N/A 0% 10% 20% 30% 40% Figure 16. Percentage of trips made using the mobile fare payment app (n = 51). 0% 2% 4% 6% 11% 30% 36% 11% More than 75% 50-74% 35-49% 25-34% 15-24% 5-14% Less than 5% N/A 0% 10% 20% 30% 40% Figure 17. Percentage of fare revenue collected using the mobile fare payment app (n = 53).

28 Business Models for Mobile Fare Apps Motivation, Challenges, and Future Plans This section presents results from the final part of the survey, which pertains to the motivation for deploying a mobile fare payment app, challenges, and future plans. • Motivation: Survey respondents were asked about the primary reason(s) for deploying a mobile fare payment app, and the results are shown in Figure 18. The most common reason (55 of 59 = 93%) was improving the customer experience. The second and third most common responses were reducing cash handling (41 of 59 = 69%) and reducing the overall cost of fare collection (30 of 59 = 51%), respectively. Some agencies wrote in other responses, which includes decreasing boarding times and increasing ridership. Last, the percentages shown in Figure 18 do not sum to 100% because respondents could select all that apply. • Challenges: Respondents were then asked an open-ended question about the biggest chal- lenges or hurdles that they faced in deploying a mobile fare payment app. These write-in responses varied between agencies, but some common themes included (1) training of front- line staff, (2) customer education and awareness, and (3) a lack of integration either regionally or with their existing fare payment system. • Future Plans: The last question asked respondents if their agency had plans to make changes to their mobile fare payment app. Most respondents (39 of 59 = 66%) said that they did have plans, and there was a wide variety of write-in responses describing these plans. This suggests that these deployments are likely to continue evolving in the future. Survey Results by Key Findings This section presents a summary of key findings from the survey. • The first mobile fare payment app was deployed in the United States in 2011. Most agen- cies have made their mobile fare payment app available to the public within the last 5 years, suggesting that this is a new and rapidly growing area in the transit industry. • The primary reasons that transit agencies deployed mobile fare payment apps include improv- ing the customer experience, reducing cash handling, and decreasing the cost of fare collection. • The platforms used for mobile fare payments were Android and iOS; all transit agencies that responded to the survey had mobile fare payment apps on both platforms. • Adoption of mobile fare payment apps varied by transit mode. Numerous agencies that provide bus, light rail, commuter rail, or ferry service had mobile fare payment apps. 69% 51% 37% 14% 93% 15% Reduce cash handling Reduce overall cost of fare collection Reduce use of ticketing vending machines Reduce fare evasion Improve customer experience Other 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Figure 18. Motivation for launching a mobile fare payment app (n = 59).

Transit Agency Survey 29 However, there were few examples of heavy rail services that offered mobile fare payment apps; this is likely due to the validation process, which is typically done via fare gates on heavy rail systems. • The primary method for validating fare products purchased through mobile fare payment apps was visual validation by a conductor, inspector, or driver. Additional mechanisms of validation were use of QR Codes or barcodes. There was limited use of Bluetooth or near field communication technology for fare validation. • Transit agencies hired outside vendors to develop apps; in-house transit agency staff were not the primary party responsible for the software development. A few companies (five to six) had most of the market in the United States and Canada. • Many agencies deployed mobile fare payment apps in business arrangements that did not have any upfront costs; instead, these agencies commonly paid their vendor based on a percentage of sales (e.g., 10% of the fare value). This was more common with smaller-sized transit agencies that contracted with a single vendor (Token Transit). • Some transit agencies procured mobile fare payment apps from vendors with preexisting apps that could be quickly and easily configured, such as to provide specific fare types. Other agencies procured apps that required significant customization and software development. • In terms of roles, most vendors had the primary responsibility for payment processing, hosting the mobile fare payment app, and PCI compliance. Many transit agencies took the lead on customer service for riders and marketing. • Many transit agencies (16 of 51 = 31%) stated that fewer than 5% of trips were made using a mobile fare payment app on their transit system. This relatively low level of utilization was a surprising finding.