Post on 09-Feb-2017
Center for Urban Transportation Research | University of South Florida
Sean J. Barbeau, Ph.D.Principal Mobile Software Architect for R&DCenter for Urban Transportation Research
University of South Florida
Concept of Operations for Deploying a Mobile Transit Fare Collection App
2
• Planning phase, important to engage all staff• Learn from other agencies’ experiences• Budget for marketing, training, and beta testing
process• Build redundancy in back office functions• Factor reporting requirements into procurement • Think long-term before committing
Key Presentation Take-Aways
3
Acknowledgement
PM: Diane Quigley, FDOT Transit Planning Administrator
CUTR’s Research Team:PI: Nevine Labib GeorggiCo-PI: Dr. Sean BarbeauResearcher: Ann Joslin Consultant: Dr. Candace Brakewood, Assistant Professor, Department of Civil Engineering, City College of New York
4
• Industry Scan of Mobile Fare Technology (March 2016)
• Summary of Features by Different Vendors• Case Examples: Lessons Learned (Interviews)• Points to Ponder
Overview
5
• Visually verified electronic “ticket” on phone• Machine-readable two-dimensional Quick
Response (QR) Code• Both # 1 and #2
Transit Mobile Fare Payments:A brief overview
6
• Near Field Communication (NFC) – contactless, tap and go
Transit Mobile Fare Payments:A brief overview
7
• Bytemark, New York, NY 2011– New York Waterway (NYPP app);– Capital Metro in Austin, Texas (CapMetro app);– Massachusetts DOT (BusPLus+)
• CooCoo, New York, NY, 2009– CDTA in Albany (iRide); – NCTD in San Diego (mTicket)
Industry Scan of Mobile Fare Technology(1 of 5) (March 2016)
8
Industry Scan of Mobile Fare Technology(2 of 5) (March 2016)
• Masabi, London, UK (US HQ in NY, NY), 2001– Boston’s MBTA (mTicket); – San Diego's MTS and CrossCountry Trains
(mTicket); – NICE Bus on Long Island (go Mobile); – New York’s MTA for Metro-North and Long
Island Railroad (eTix)
9
Industry Scan of Mobile Fare Technology (3 of 5) (March 2016)
• Passport , Charlotte, NC, 2010– Columbia, SC Comet Bus (Catch the Comet)– Jacksonville Transportation Authority (MyJTA), FL
• Unwire, Copenhagen, Denmark, 1999– Dallas Area Rapid Transit (DART);
• DART is changing to GlobeSherpa/Moovel (Announced March 2016)
– Fort Worth Transportation Authority (The T); – Denton County Transportation Authority (GoPass)
10
Industry Scan of Mobile Fare Technology (4 of 5) (March 2016)
• Moovel, Germany (Formerly GlobeSherpa, Portland, OR, 2010)– TriMet in Portland (TriMet Tickets); – Virginia Railway Express (VRE Mobile); – Pilot program with Los Angeles DOT (LA Mobile);– Planned with SFMTA; – Partnering with Cubic for CTA Ventra App in Chicago– Dallas Area Rapid Transit (DART) (upcoming)
11
• Xerox, Norwalk, CT (Parent Company), 1906 – NJ TRANSIT (MyTix)– SunRail in Central Florida
Industry Scan of Mobile Fare Technology (5 of 5) (March 2016)
12
Agency NJ TRANSIT MBTAName of App NJ TRANSIT App (MyTix) mTicket (JustRide)
Validation Process
Visual; barcodes scanned at a small number of fare gates
Visual; barcode scanned by inspector
Modes with app
Bus, rail, light rail Commuter rail and ferry
Forms of Payment
Credit and debit cards; PayPal
Credit and debit cards
Summary of Features by Different Vendors (1 of 3)
13
Agency TriMet NY Waterway (EDC)
Name of App TriMet Tickets NY Waterway
Validation Process
Visual and barcode scanned by inspector
Visual
Modes with app
Commuter rail, light rail, bus Ferry, bus
Forms of Payment
Credit and debit cards Credit and debit cards
Summary of Features by Different Vendors (2 of 3)
14
Agency NCTD The COMET DARTName of App
COASTER Catch the COMET App
GoPass
Validation Process
Visual and barcode
Visual Visual
Modes with app
Commuter rail Bus Bus, light rail
Forms of Payment
Credit and debit cards
Credit and debit cards
Credit and debit cards
Summary of Features by Different Vendors (3 of 3)
15
• DART (Unwire)• NICE (Masabi)• COMET (Passport)• CTA (GlobeSherpa)• NJ Transit (Xerox)
Case Examples: Interviews (March 2016)
16
• Significant planning and technical expertise is necessary– Learn from the experiences of other agencies.
• Build redundancy in back office functions/servers is recommended in case of any interruptions in communications.
Lessons Learned from Case Examples(1 of 5)
17
• Carefully evaluate the desired data (e.g. utilization by route and stop) and reporting needs when defining technology – Should be factored into procurement decisions– Have a good dashboard system to track sales
trends and system performance.
Lessons Learned from Case Examples(2 of 5)
18
• Beta Test: – Represent a good cross section of transit service
area demographics and should be users of the specific modes where mobile payments can be used
– Solicit input during and after pilot
Lessons Learned from Case Examples(3 of 5)
19
• Engage all levels of transit agency employees in the planning process in preparation for deployment.– Employees involved in beta testing of mobile
payment systems have valuable insight to offer.
Lessons Learned from Case Examples(4 of 5)
20
• Mobile ticketing requires extensive marketing activities to be successful
• Agencies should build customer outreach activities into their planning activities and deployment budgets
Lessons Learned from Case Examples(5 of 5)
21
• Agencies see visual validation / QR Code scanning as a low barrier to entry for mobile ticketing where the integration needs are not as intense, and therefore cheaper/quicker to implement. Examples:– The Comet and NICE, 6 months from concept
to deployment
Points to Ponder . . .
22
• A pilot requires almost as much work as a full deployment – you still need staff and public training time, marketing, etc. So, don’t underestimate the effort for a “pilot” if you want it to be successful.
Points to Ponder . . .
23
• Survey - Information needed for deciding on mobile fare payment option– 70% need to know costs– 60% need to see cases studies documented– 60% need specifications– 30% need to see RFP examples
Points to Ponder . . .
N=15
24
• Survey - “Technologies in fare systems have far exceeded our current system. We want to make sure we are entering into a system that will allow us the maximum flexibility in fare collection and providing convenience to our patrons.”
Points to Ponder . . .
N=15
25
• Experience of vendor• Flexibility of mobile app– Require Application Programming Interface (API) and
“deep link” ability to allow future integration/expansion– Long-term strategic plan for multiple features/apps
• Impact of future vendor change– Do all riders need to download new app?– What happens to unused fares?– Ownership of improvements?
• Ownership of data
Considerations for procurement
26
TRB paper:• http://bit.ly/TRB-Mobile-Fare
Final report (March 2016):• http://bit.ly/FDOT-Mobile-Fare
(Case-sensitive)
27
Thanks!
Sean J. Barbeau, Ph.D.barbeau@cutr.usf.edu813.974.7208
Principal Mobile Software Architect for R&DCenter for Urban Transportation ResearchUniversity of South Floridahttp://www.linkedin.com/in/seanbarbeau