RFI I50437_ MARTA On the Go Application Repla.pdf

2424 Piedmont Rd. N.E.

Atlanta Ga, 30324

January 8, 2024

TO: PROSPECTIVE RESPONDENTS

SUBJECT: REQUEST FOR INFORMATION (RFI): I50437

MARTA ON-THE-GO APPLICATION REPLACEMENT

The Metropolitan Atlanta Rapid Transit Authority (“MARTA” or “Authority”) is preparing to issue a solicitation to retain a firm(s) that can provide services to replace and enhance MARTA’s existing mobile application, MARTA On-the-Go (MOTG). The MOTG replacement will be a single, unified mobile application.

This RFI is issued for the purpose of gathering information from leading firms, at their own expense, to further develop the scope requirements for MARTA’s On-the-Go Application. Because information received in response to this RFI may be used to build requirements leading to a Scope of Work for a future Request for Proposal (RFP), respondents are strongly advised to NOT include information in their responses that might be considered business sensitive, proprietary or otherwise confidential.

MARTA may conduct dedicated sessions with Respondents to review documents, collect feedback, and update the specifications as may be necessary, to be decided solely by the Authority, prior to issuing the final Request for Proposal (RFP) to the community for formal responses.

This RFI shall be conducted subject to the following terms:

1. Definitions: The following definitions shall apply when used throughout this Request for Information

(“RFI”):

(a) Firm(s): A Firm that has or will obtain, prior to the execution of any contract awarded hereunder, all necessary licenses required by the State of Georgia to perform the Services and is authorized to do business in the State of Georgia.

(b) Respondent: Each Firm submitting a response to this RFI.

(c) Response: A written response to this RFI prepared by a Respondent and submitted to the Metropolitan Atlanta Rapid Transit Authority’s (“MARTA”) Office of Contracts, Procurement and Materials (“CPM”).

2. Response Not a Prerequisite to Future Proposal: Responding to this RFI will NOT be a condition or prerequisite for any prospective Respondent in the competitive solicitation process, nor will any entity be selected to provide any service, product, or associated work effort to MARTA as a direct result of RFI submittals.

DocuSign Envelope ID: C2459915-593D-463B-B1F1-FDCA01D3A55E

Page | 2

3. Procurement Questions; Prohibited Contacts: Any questions regarding this RFI should be submitted in writing to MARTA’s contact person, Ms. Saretha Pyant, Contract Specialist II by e-mail at spyant@itsmarta.com, on or before January 17, 2024, at 11:59 p.m. (local time). Questions received after the designated period will not be considered. Any response made by MARTA will be provided in writing to all Respondents by an addendum to this RFI. It is the responsibility of each Respondent to obtain a copy of any addendum issued for this RFI by monitoring MARTA’S website at www.itsmarta.com. No Respondent may rely on any verbal response to any question submitted concerning this RFI. All Respondents and representatives of any Respondent are strictly prohibited from contacting any other MARTA employees or any third-party representatives of MARTA on any matter having to do with this RFI. All communications by any Respondent concerning this RFI must be made to MARTA’s contact person. Respondents are required to conduct the preparation of their submission to MARTA with professional integrity and free of lobbying and similar types of behavior intended to influence MARTA. As used in this RFI, the terms, “Firm(s),” “Respondent” and “MARTA” shall be deemed to include such entities’ respective officers, directors, agents, contractors, subcontractors, professional service providers, employees and any other person or entity owned, controlled, or affiliated with such entities.

4. No Compensation: This RFI is designed to solicit responses from the Respondents who are interested, at their own expense, to share information that will further develop the requirements for MARTA’s On-The Go Application. The Authority will not compensate any Respondent for time spent in responding to this

RFI.

5. Representation: By submitting a Response to MARTA, Respondent acknowledges, represents and warrants that: (a) it has read the entire RFI and acknowledges that Respondent shall be bound by the terms and conditions stated herein; (b) the signatory to the Response is the Respondent (or Respondent’s duly authorized agent or employee of the Respondent with the authority to bind Respondent hereto); (c) any information or disclosure provided in response to this RFI is an accurate representation up to and including the date Respondent submitted its Response to MARTA; and (d) it agrees that it will voluntarily notify MARTA immediately if any information or disclosure provided to MARTA during any part of this RFI process changes, is no longer accurate or would be misleading in any way.

Additionally, Respondents are advised that in the subsequent RFP, Respondents will be required to represent and warrant to MARTA that none of the following, during term of the contract or for six (6) months thereafter, have or will have any interest, direct or indirect, in the contract with MARTA or in any part of the proceeds, hereof: (i) members of the MARTA Board of Directors; (ii) officers or employees or former employees of MARTA, or of any representative of MARTA in the administration of this contract, pursuant to MARTA’s Code of Ethics. This Section also applies to members of or delegates to the United States Congress or the Georgia legislature; and members of the governing body, and all other officers and employees, of the City of Atlanta or the Counties of Fulton, DeKalb or Clayton, Georgia.

6. Availability of Electronic Documents: This RFI is being made available by electronic means. By responding to this RFI, Respondent acknowledges and accepts full responsibility to ensure that it is responding to the correct form of RFI, including any addenda issued by MARTA’s Office of Contracts, Procurement and Material (CPM). Respondent acknowledges and agrees that in the event of a conflict between the RFI in the Respondent’s possession and the version maintained by CPM, the version maintained by CPM shall govern. The Request for Information (RFI) document may be viewed and downloaded from MARTA’s website www.itsmarta.com. On the home page, point to “About MARTA/click Vendor

DocuSign Envelope ID: C2459915-593D-463B-B1F1-FDCA01D3A55E mailto:spyant@itsmarta.com, http://www.itsmarta.com/

Page | 3

Opportunities/Download Invitation for Bids/Request for Proposals/Log-in (first time users must register)/Vendor Opportunities/ RFI I50437 for this Request for Information.

7. Rejection of Responses; Cancellation of RFI; Waiver of Technicalities: MARTA reserves the right to reject any Response or all of the Responses, to waive any technical defect in a Response or to cancel this RFI at any time for any reason or no reason.

8. Georgia Open Records Act: Information provided to MARTA is subject to disclosure under the Georgia Open Records Act (“GORA”). Pursuant to O.C.G.A. § 50-18-72(a)(34), “[a]n entity submitting records containing trade secrets that wishes to keep such records confidential under this paragraph shall submit and attach to the records an affidavit affirmatively declaring that specific information in the records constitute trade secrets pursuant to Article 27 of Chapter 1 of Title 10 [O.C.G.A. § 10-1-760 et seq.].”

9. Submission Deadline: All responses to this Request for Information should be submitted by February 12, 2024 at 2:00 p.m., Local Time. All Respondents should submit one (1) original copy of the firm’s responses, and one (1) USB drives (a.k.a., jump or flash drives). The electronic copy must be in Microsoft Word format.

All responses to this RFI must be received by MARTA’s Department of Contracts, Procurement & Materials, 2400 Piedmont Road N.E., Atlanta, Georgia 30324-3330, on or before February 12, 2024, at 2:00 p.m. (local time). Incomplete responses or responses submitted in any other format may not receive consideration by the Authority.

10. Protests: Any protest or objection to this RFI or the solicitation process related to this RFI must be submitted, in a timely manner, in accordance with the Protest Procedures set forth on MARTA’s website at:

https://www.itsmarta.com/uploadedFiles/MARTA%20CPM%20Procedure%20Manual%20- %20Updated%2009-03-2020%20-%20REV%209%20-%20Bid%20Protest%20Procedures.pdf .

11. Acceptance of Terms: By submitting a response to this RFI, you confirm your understanding and acceptance to the terms and conditions as stated herein.

Sincerely, Jacqueline A. Holland, MBA, CPPB Senior Director, Contracts, Procurement & Materials https://www.itsmarta.com/uploadedFiles/MARTA%20CPM%20Procedure%20Manual%20-%20Updated%2009-03-2020%20-%20REV%209%20-%20Bid%20Protest%20Procedures.pdf https://www.itsmarta.com/uploadedFiles/MARTA%20CPM%20Procedure%20Manual%20-%20Updated%2009-03-2020%20-%20REV%209%20-%20Bid%20Protest%20Procedures.pdf

Page | 4

1. TIMELINE

The following describes the timeline for the RFI process:

Task Date & Objective

RFI Issued January 8, 2024

The Request for Information will be available for downloading on the MARTA web site:

www.itsmarta.com

RFI Questions January 17, 2024, at 11:59 p.m. (local time).

All Respondents must submit questions to Saretha Pyant at spyant@itsmarta.com

Deadline for RFI Response

February 12, 2024 at 2:00 p.m. Local Time

All Respondents should submit one (1) original and one (1) flash drive of their response. All written responses are to be submitted to the address below:

Metropolitan Atlanta Rapid Transit Authority Office of Contracts, Procurement and Materials 2400 Piedmont Road, N.E.

Atlanta, Georgia 30324-3330 Attn: Contract Control (RFI I50437)

MARTA ON-THE-GO APPLICATION REPLACEMENT

Evaluation of Responses MARTA will review the responses after receipt. At MARTA’s discretion, follow-up meetings (e.g., one-on-one meetings, round table discussions, etc.) may be scheduled to further discuss/clarify responses.

Conduct Review Sessions After receipt of responses, the Authority may conduct review sessions virtually.

2. What is your company or organization name, point of contact, telephone number, and email address?

3. How many years has your company/organization been in business?

4. How many years has your company/organization been providing similar services?

https://martabid.marta.net/CurrentOpportunities.aspx mailto:spyant@itsmarta.com

Page | 5

EXHIBIT A

REQUEST FOR INFORMATION (RFI) – I50437

MARTA ON-THE-GO APP REPLACEMENT

1. INTRODUCTION AND PURPOSE

The Metropolitan Atlanta Rapid Transit Authority (“MARTA” or “Authority”) is preparing to issue a solicitation to retain a firm(s) that can provide services to replace and enhance MARTA’s existing mobile application, MARTA On-the-Go (MOTG). The MOTG replacement will be a single, unified mobile application. MARTA is interested in submissions from all Respondents that can provide innovative approaches in the development, operation, and maintenance of a single transit mobile app with features including:

I. Trip Planning (scheduled & real-time);

II. Route & Stop Schedules;

III. Next Train/Next Bus Information;

IV. Interactive Mapping and Real-time Vehicle Location Tracking;

V. Payment & Fare Account Management (AFC 2.0);

VI. On-Demand Transit Discovery & Booking;

VII. Incident Reporting (See & Say); and, VIII. Alerts (Everbridge).

2. MARTA BACKGROUND

The MARTA vision is “People taking people where they want to go today and tomorrow,” with a mission “to advocate and provide safe, multimodal transit services that advance prosperity, connectivity, and equity for a more livable region.” MARTA currently operates bus, rail, streetcar, and Mobility (paratransit) services across the Atlanta metropolitan area and is expanding to include Bus Rapid Transit (BRT) and Arterial Rapid Transit (ART) in 2025.

In 2019, MARTA provided over 117 million unlinked trips to transit users via bus, heavy rail, streetcar, and paratransit around and through Atlanta. The transit system provides travel options to over 1.7 million residents of Metro Atlanta as well as visitors and tourists to the city. MARTA’s four jurisdictions include Fulton County, DeKalb County, Clayton County, and the City of Atlanta. It is an integral part of the region’s economy, promoting growth in local industries and supporting over 24,000 jobs throughout the Atlanta region and the state of Georgia.

3. PROGRAM SCOPE

The primary goal of the MOTG replacement is to deliver a unified, high-quality, multi-purpose native iOS and Android mobile application for MARTA riders to access MARTA information and services. The application will be required to interface with open-source and/or 3rd party vendor provided data and services (e.g., OpenTripPlanner, the AFC vendor, MARTA’s enterprise CRM, on-demand transit software provider) to present a seamless experience for MARTA riders.

Page | 6

4. DESIRED FUNCTIONALITIES

4.1. Trip Planning

MARTA expects the new MARTA mobile application to include a multimodal trip planner with the following capabilities:

(a) Support for all modes of transit that can be represented by GTFS or GTFS-Flex data.

(b) Support for walking, bicycling, micro mobility, and driving as transit access modes using OpenStreetMap (OSM) data for street-level routing. Driving access will support both drop-off and park-and-ride using designated park-and-ride locations as indicated in OSM.

(c) Support for planning ad-hoc trips (based on current service using real-time information from GTFS-RT) and in the future (using the static GTFS).

(d) Support for planning wheelchair-accessible trips as indicated by the user.

(e) Support for planning trips using connecting regional (i.e., non-MARTA) public transit services.

(f) Support for searching for start and end locations using addresses, point-of-interest/landmark name, or transit stop name/ID.

(g) Automatic fare calculation and seamless integration with the application’s fare payment capabilities (see section 2.5).

MARTA’s website, itsmarta.com, uses an OpenTripPlanner (OTP) instance to create trip plans. It is MARTA’s intention to use OpenTripPlanner and its suite of APIs as the foundation of our Trip Planning functionality across our customer-facing channels, including the new mobile app.

4.1.1. Trip Planning Questions

(a) Does your platform currently employ OTP as the Trip Planning engine?

(b) If not, can your platform be modified to employ OTP?

(c) If your platform does not employ OTP, please explain how you would propose mitigating the differences in trip plans between itsmarta.com and the new mobile application.

(d) Please describe your solution’s capabilities for address and point-of-interest resolution (geocoding).

Is it capable of using a geocoding service designated by MARTA (provided that the service provides stable and documented APIs)?

(e) Please describe your solution’s capabilities for saving custom user preferences (e.g., preferred modes, walking speed, accessibility needs) and/or favorite places/trips.

4.2. Route & Stop Schedules

The new MARTA mobile application will include route and stop based schedules based on MARTA’s static GTFS feed and, as applicable, GTFS-RT updates.

4.2.1. Schedule Questions

(a) Please describe your solution’s approach to presenting route and stop schedules to patrons, including the ability to show both scheduled and real-time information derived from GTFS and GTFS-RT feeds (e.g., delays, trip cancellations).

DocuSign Envelope ID: C2459915-593D-463B-B1F1-FDCA01D3A55E https://www.opentripplanner.org/ https://docs.opentripplanner.org/en/v2.4.0/Apis/

Page | 7

(b) MARTA frequently runs “special schedules” that diverge from our standard scheduled service. This may be due to construction work or events. These schedules are NOT currently provided in MARTA’s published GTFS feed. In the future, it is MARTA’s intention to ensure that special schedules are provided to our internal mobile application as well as 3rd parties. Please describe your platform’s ability to retrieve and apply updated GTFS feeds published monthly, weekly, or even daily.

4.3. Next Train/Next Bus Information

The new mobile app will need to present riders with next train and next bus information based on MARTA’s GTFS-RT feeds. Currently for MARTA rail, this requires patrons to select their stop from a map or list. Next bus functionality is not currently provided on the mobile app. It is MARTA’s desire for the future mobile app to use a patron’s current location to present relevant next train and next bus information.

4.3.1. Next Train/Next Bus Questions

(a) Please describe your solution’s approach to presenting location sensitive next train/next bus information.

4.4. Interactive Mapping and Real-time Vehicle Location Tracking

MOTG currently provides customers with the real-time locations of buses based on the GTFS-RT feed. At this time, no real-time vehicle locations are provided in the app for rail or streetcar. In the future, MARTA would like to provide customers with an interactive map-based interface for viewing route alignments, stop locations, and real-time vehicle locations for all modes, as applicable.

4.4.1. Interactive Mapping and Real-time Vehicle Tracking Questions

(a) Please describe your solution’s approach to presenting a map-based view of routes, stops, and real-time vehicle locations.

(b) Does your solution use OpenStreetMap (OSM) as the source of street network data used in the base map? If so, how frequently is this data refreshed? If not, can the solution be modified to use OSM data?

(c) In addition to retrieving vehicle locations from a GTFS-RT vehicle positions feed, would your solution be capable of integrating with a websocket interface to be provided by MARTA for high-frequency streaming of location updates?

4.5. Payment & Fare Account Management

MARTA is currently procuring a new Automated Fare Collection (AFC) system Innovations in Transit (INIT). It is MARTA’s intention to fully integrate the functionality of the new AFC system into our new mobile application, eliminating the need for a separate mobile payment application. MARTA has required Init to expose all account management and payment functionality from their system via APIs. Functionality shall include:

(a) Account credential management;

(b) Fare Media management;

(c) Stored value and fare product management;

(d) Account payments; and,

(e) Alerts and notification.

Page | 8

4.5.1. Payment & Fare Account Management Questions

(a) Please provide your experience fully integrating a 3rd party payment solution into your platform.

Please include vendors with whom you have completed these integrations.

(b) What downsides do you anticipate from fully integrating the payment and fare account management functionality into the mobile app platform? Are there potential solutions for mitigating these downsides?

4.6. On-Demand Transit Discovery & Booking

MARTA plans to procure and implement an on-demand transit service. It is our desire that the MARTA mobile app will integrate with the on-demand vendor for discovery and booking of the on-demand service. MARTA anticipates contractual requirements for the on-demand vendor to expose all account management, booking, and trip making functionality from their system via APIs. Functionality shall include:

(a) Account credential management;

(b) Scheduling a trip, including vehicle ETAs and real-time vehicle location tracking;

(c) Taking a trip, including communicating trip insertions and ETAs; and,

(d) Post-trip communication, including feedback and ratings.

4.6.1. On-Demand Transit Discovery and Booking Questions

(a) Please provide your experience fully integrating a 3rd party on-demand technology solution into your platform. Please include vendors with whom you have completed these integrations.

(b) What downsides do you anticipate from fully integrating the on-demand technology solution into the mobile app platform? Are there potential solutions for mitigating these downsides?

(c) What is the preferred data format by which your platform ingests information relating to on-demand service discovery? Booking? If there is no particular format, please explain your experience integrating APIs for service discovery and booking.

4.7. Incident Reporting

MARTA currently uses an AppArmor platform to support emergency and non-emergency incident reporting.

In the future, MARTA anticipates incorporating the features of the AppArmor platform directly into the new MARTA mobile application. The AppArmor platform allows MARTA patrons to submit issues, and those issues are stored and tracked in the AppArmor backed in and submitted to relevant Departments as needed.

4.7.1. Incident Reporting Questions

(a) Please provide your system’s capabilities regarding emergency and non-emergency incident reporting.

(b) If your solution supports live itinerary tracking (see question 2.1.1 (f)), can this feature be integrated with incident reporting functionality such that a user’s current station, stop, or vehicle ID is automatically included with an incident report?

(c) Please provide your experience integrating a 3rd party incident reporting system into your platform.

What downsides do you anticipate from integrating a 3rd party incident reporting system?

Page | 9

(d) Keeping in mind that MARTA is seeking a single mobile application for all MARTA needs, would you recommend integrating an existing 3rd party incident reporting system into your platform or can your platform manage incident reporting directly?

4.8. Alerts

MARTA alerts currently come from both our Trapeze TransitMaster CAD/AVL system and our Everbridge mass notification system (which pushes alerts to our website, station signage, social media, and patrons via email and SMS). In the future, MARTA intends to communicate service alerts via GTFS-RT, with trip cancellations and delays communicated via a GTFS-RT trip updates feed and all other alerts vis a GTFS-RT service alerts feed. MARTA intends to incorporate alerts into the new mobile application so that patrons can see whether specific routes/trips are cancelled, delayed, or otherwise disrupted.

4.8.1. Alerts Questions

(a) Please explain how your platform handles and displays alerts to customers on the following items:

cancelled trips/runs, delays in service, trip detours, station/stop closures, and elevator/escalator outages.

(b) What is the preferred method by which your platform ingests alerts information?

4.9. Cybersecurity Capabilities

(a) Please provide details of your cybersecurity capabilities and industry best practices.

(b) MARTA currently uses NIST SP 800 53-rev 5, NIST Cybersecurity Framework (CSF), Center for Internet Security (CIS) 18 controls, and the Open Web Application Security Project’s (“OWASP”) “Top Ten Project cybersecurity frameworks and standards.

5. ADDITIONAL QUESTIONS

5.1. Enterprise Customer Relationship Management (eCRM) Integration

MARTA is currently procuring a replacement eCRM system and anticipates using this eCRM as the “source of truth” for rider accounts. We anticipate using the eCRM system to support single sign-on (SSO) across all MARTA customer applications and as a method to store rider preferences, frequent trips, etc.

5.1.1. eCRM Questions

(a) Please describe your experience with integrating an enterprise CRM to manage account credentialing and verification.

(b) Please describe your experience interfacing with an enterprise CRM to store rider preferences and frequent trips. How could you use this information to tailor alerts and route information to patrons?

(c) Does your platform have existing APIs available to communicate user preferences to external systems (e.g., preferred routes/lines, language, etc.)? Which external systems have used these APIs?

(d) What downsides do you anticipate from integrating an enterprise CRM system? Are there potential solutions for mitigating these downsides?

(e) Please describe your experience with a customer transitioning from your platform to another system.

Page | 10

5.2. Customization

MARTA is interested in ensuring that our future mobile application looks and feels like the rest of MARTA’s customer-facing products. We are seeking information on the level of customization available on your platform.

5.2.1. Customization Questions

(a) Please explain the level of visual customization available on your mobile app platform. Would MARTA be able to modify the fonts, colors, icons, etc. used on the system?

(b) If MARTA chooses to engage your firm in the future for our new mobile application, would the application be separately named and downloadable (i.e., new MARTA On The Go) or would our application be a subset or subregion of an existing application (i.e., if VENDOR APP is opened in the Atlanta region, MARTA specific information and customization is presented). Please explain why your proposed approach is preferable.

5.3. Language and Accessibility

MARTA wants to ensure that our new mobile application has provisions in place for language access and accessibility for persons living with disabilities.

5.3.1. Language and Accessibility Questions

(a) Please explain how your platform manages language access. How does a patron indicate their preferred language? Where do translations come from and are they human or machine translated?

How many and which languages does your platform support?

(b) Please describe your application’s accessibility features, particularly for individuals who may be deaf or hard of hearing, blind or have limited vision, and/or have cognitive disabilities.

(c) Please explain the level of accessibility standards conformance your platform meets (e.g., WCAG 2.1 A, AA, AAA). How do you currently test the accessibility of your platform?

5.4. Proprietary vs. Open Source

MARTA is interested in understanding the level of proprietary vs open-source code within your application and the degree to which it utilizes open standards.

5.4.1. Propriety vs. Open-Source Questions

(a) Please explain the level of “openness” of your system. Is any of the source code open source? (Please provide links to public code repositories as applicable.) To what degree does it utilize open standards and specifications?

5.5. Live Tracking and Assistive Technology

MARTA is interested in learning more around potential functionality for live-tracking and indoor navigation.

5.5.1. Live Tracking and Assistive Technology Questions

(a) Does your solution have any capability for live tracking of in-progress trip itineraries, including the ability to automatically re-plan trips in response to real-time disruptions?

(b) Does your platform station navigation based on GTFS-Pathways data?

Page | 11

(c) Please describe your platform’s functionality around assistive technologies for persons with disabilities. This may include indoor navigation features, AR wayfinding, or other assistive tech.

5.6. Regional Application

There are several regional operators in the Atlanta Metropolitan region with overlapping service areas with MARTA. There is interest in understanding how these regional operators can leverage the mobile application developed by MARTA for their riders.

5.6.1. Regional Application Questions

(a) Please explain your system’s functionality regarding incorporating multiple separately operated service providers within one mobile application. Please describe your experience incorporating multiple service providers into one mobile application.

(b) Considering the MARTA specific app integrations outlined above (including Incident Reporting (See & Say), On-Demand, Alerts, and CRM), how would your system incorporate regional operators who do not have these services or have different vendors for these services? For example, if MARTA has a different on-demand platform than say RideGwinnett, how would your system accommodate this?

(c) Considering the use of the MARTA eCRM as the source of SSO for MARTA customers, how would you propose managing account credentialing for other regional operators.

(d) Would it be possible for the platform to provide a unified backend solution with different customer-facing apps for the customer? Please explain any benefits or limitations of this potential approach.

(e) What downsides do you anticipate from integrating multiple service providers within a single application? Are there potential solutions for mitigating these downsides?