concept of operations for deploying a mobile transit fare collection app

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


• 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


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


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





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.


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


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.


20

• Mobile ticketing requires extensive marketing activities to be successful

• Agencies should build customer outreach activities into their planning activities and deployment budgets


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.


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


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.”


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)

http://www.dot.state.fl.us/transit/Pages/FinalReportMobileFarePayment20160331.pdf

27

Thanks!

Sean J. Barbeau, [email protected]

Principal Mobile Software Architect for R&DCenter for Urban Transportation ResearchUniversity of South Floridahttp://www.linkedin.com/in/seanbarbeau

mailto:[email protected]

http://www.linkedin.com/in/seanbarbeau