NEORide_Mobility_Platform_and_Turnkey_SOW.pdf

Mobility Platform & Turnkey Services NEORide

Mobility Platform and Turnkey Service Statement of Work i

Contents 1 Introduction

1.1 Project Overview

1.2 Document Overview

2 Agencies and Scope

2.1 Interested Agencies

2.2 Mobility Platform Scope

2.3 Turnkey Services Scope

3 Mobility Platform Requirements

3.1 Infrastructure and Data

3.2 Rider Applications and Booking

3.3 Vehicle and Operator Applications

3.4 Central Dispatch and Administration

3.5 Reporting

3.6 ADA Paratransit

3.7 Fleet and Rider Commingling

3.8 Integrations and Electronic Payments

3.9 Optional Capabilities

4 Implementation Services

4.1 Requirements Traceability and Project Management

4.2 Design and Configuration

4.3 Testing and Acceptance

4.4 Documentation and Training

5 Support Services

5.1 Service Level Agreements and Technical Support

5.2 Incident Reporting

5.3 Software Upgrades and Additional Training

6 Turnkey Microtransit Requirements

6.1 Fleet and Maintenance

6.2 Service Delivery

6.3 Operators and Staffing

6.4 Dispatch and Scheduling

6.5 Safety and Facilities

6.6 Customer Service

6.7 Performance Reporting and Billing

6.8 Subcontractors and Third Party Providers

6.9 Mobilization and Service Closeout

7 Proposal and Pricing Requirements

7.1 Appendix B Compliance Matrices

7.2 Appendix C Pricing Sheets

1 Introduction

1.1 Project Overview

NEORide is seeking proposals for a Mobility Platform supporting microtransit and ADA paratransit, together with turnkey microtransit services for Participating Agencies. NEORide will select two vendors, each providing both the Mobility Platform and turnkey microtransit services.

This Statement of Work describes the platform, operational services, implementation, and support to be provided. The requirements below summarize the scope, the detailed requirements remain in the accompanying Turnkey Microtransit compliance matrix in Attachment B and Mobility Platform compliance matrix in Attachment E.

1.2 Document Overview

Section 2 identifies the interested agencies and the two components of the scope. Section 3 describes the Mobility Platform requirements. Section 4 covers implementation services.

Section 5 covers support services. Section 6 describes turnkey microtransit requirements.

Section 7 addresses proposal capabilities, pricing, and the accompanying requirements and pricing documents.

2 Agencies and Scope

2.1 Interested Agencies

The following 12 agencies have indicated interest in this project. Their office locations are listed below.

Agency Office location State

BCRTA Hamilton OH

SORTA Cincinnati OH

KRT Charleston WV

TANK Ft. Wright KY

HIRTA Urbandale IA

DART Des Moines IA

Dayton RTA Dayton OH

NKADD Florence KY

Richland Richland OH

BATA Traverse City MI

Lorain Elyria OH

Indygo Indianapolis IN

2.2 Mobility Platform Scope

The Mobility Platform includes the following:

• Central dispatch and administration

• Vehicle and operator applications

• Rider mobile and web applications

• Reporting

• Trip booking and scheduling

• Third-party provider management

• ADA paratransit eligibility

• Operations

• Billing Required integrations include EZFare, GTFS Flex and trip planning, and EZConnect.

Implementation includes project management, design, configuration, testing, documentation, training, and data migration.

2.3 Turnkey Services Scope

Turnkey Services include the following:

• Mobilization and transition

• Vehicles and accessible fleet capacity

• Operators

• Maintenance

• Facilities

• Human dispatch

• Customer service

• Safety and compliance

• Performance reporting

• Billing support

• Service closeout

3 Mobility Platform Requirements The Mobility Platform shall support the agency-configured services and the core functionality identified in the Mobility Platform requirements workbook. Optional capabilities are identified separately in Section 3.9.

3.1 Infrastructure and Data

3.1.1 Cloud Hosting and Continuity

1. The Contractor shall provide the platform through a SaaS model and maintain at least a test and production instance for each agency.

2. Designated NEORide and agency users shall be able to test updates and configuration changes before production deployment.

3. The Contractor shall test changes internally and obtain NEORide approval for material production changes, except emergency security patches or critical incident remediation.

4. The system and services shall maintain 99.95% availability, measured on rolling monthly and annual bases with the exclusions specified in the workbook.

5. The Contractor shall provide monthly availability reports, operational backups, and a disaster recovery plan addressing redundancy, failover, recovery, and escalation.

6. Recovery time shall not exceed one hour.

7. Failover and failback shall preserve data integrity, and disaster recovery procedures shall be tested at least annually.

Detailed requirements: Platform requirements 1–17.

3.1.2 Security and Access Control

1. The Contractor shall provide encrypted data exchange and storage, monitoring of access and attempted access, a system security plan, a security incident response plan, annual compliance assurances, and independent security assessment.

2. Agency data access shall be limited to authorized users, with expressly authorized access for regional coordination.

3. The platform shall provide role and agency-based access controls, minimum necessary permissions, multi-factor authentication for privileged and sensitive access, account administration, and auditable login, logout, and configuration-change records.

4. Vulnerability, breach, data-loss, and privacy-loss notifications shall meet the timelines specified in the workbook.

Detailed requirements: Platform requirements 18–44.

3.1.3 Data Access and Portability

1. Each Participating Agency shall receive automated, direct, unmetered access at the base contract price to its authorized record-level data through documented APIs and scheduled bulk exports.

2. Export frequency shall be configurable to at least daily; historical data shall remain accessible throughout the contract term.

3. The Contractor shall provide interface documentation, data dictionaries, machine-readable formats, and raw data suitable for database and business-intelligence ingestion.

4. Each agency shall own its data and agency-specific configurations, data models, reports, and dashboards, excluding the Contractor’s pre-existing intellectual property.

5. Export, return, and secure-deletion obligations shall follow the detailed data access and portability requirements.

Detailed requirements: Platform requirements 45–53.

3.2 Rider Applications and Booking

1. The Contractor shall provide native Android and iOS rider applications, a web application, agency applications, and a NEORide branding option.

2. Rider-facing functions shall conform to WCAG 2.1 Level AA and applicable federal accessibility requirements, supported by accessibility conformance documentation and remediation of identified defects.

3. Customers and authorized users shall be able to register, manage profiles and communication preferences, submit accommodation and eligibility information, plan trips, book eligible services, modify or cancel trips, and obtain trip status.

4. Trip planning shall support available connections to fixed-route service and booking of the demand-response leg.

5. The platform shall validate locations and service-area eligibility and display the applicable fare before booking confirmation.

6. The client self-service portal shall support account management, eligibility applications and documents, program enrollment, trips, payments, and agency communications.

7. AI-assisted voice or text booking and scheduling shall apply agency rules and shall not be enabled without the agency’s prior written approval.

8. Each agency shall be able to configure, limit, suspend, or disable AI functionality.

Detailed requirements: Platform requirements 54–166 and 803–810; IVR requirements 88–97 and 800– 802.

3.3 Vehicle and Operator Applications

1. The Contractor shall provide a native Android and iOS vehicle application supporting operator login, assigned manifests, pickup and drop-off events, trip information, and communication with dispatch.

2. Essential driver functions shall support offline or degraded-network operation where feasible, with secure storage, synchronization, and prevention of operational-data loss.

3. The vehicle application shall support agency-configured canned messages, message delivery status, and priority assistance requests with audible and visual dispatcher alerts.

4. Rider information shown to operators shall be limited to information needed to complete assigned trips.

5. The interface shall support safe operations and discourage device interaction while the vehicle is moving.

6. Vehicle hardware responsibilities shall follow the applicable service arrangement: the platform workbook assigns procurement and maintenance of vehicle application hardware to agencies, while the turnkey workbook assigns required vehicle hardware and cellular connectivity to the Contractor unless otherwise specified by the agency.

Detailed requirements: Platform requirements 167–246; turnkey requirements 18–21.

3.4 Central Dispatch and Administration

1. The web-based central application shall provide authorized users with customer profiles, mapping and visualization, service configuration, real-time operational views, trip manifests, and vehicle and driver assignments.

2. Each agency shall be able to configure service boundaries, hours, booking rules, service models, fares, eligibility, funding, and program-specific reporting without a cap on the number of demand-response programs.

3. Scheduling and optimization shall apply the agency’s configured booking and service rules.

4. Dispatchers shall be able to manage active and scheduled trips, revise assignments, and respond to service disruptions.

5. The platform shall support trip brokerage and third-party provider management, together with fixed-route connectivity, as specified in the central-system requirements.

Detailed requirements: Platform requirements 247–364 and 816.

3.5 Reporting

1. The platform shall provide reporting within the central application and the service, fleet, trip, and operations data needed for the reporting requirements in the workbook, including applicable National Transit Database reporting.

2. Reporting shall preserve agency, service, and program distinctions and support audit and export of the underlying data.

3. Required reporting includes service supplied and consumed, vehicle and operator profiles and utilization, and pre-trip and post-trip odometer records.

4. The detailed matrix defines the required data fields and report capabilities.

Detailed requirements: Platform requirements 365–403.

3.6 ADA Paratransit

1. The platform shall support ADA complementary paratransit and general public demand-response services within a single integrated platform, with independently configurable programs.

2. It shall support applicable ADA service requirements and agency policies for eligibility, booking windows, fares, service areas, attendants, companions, mobility devices, and visitors.

3. Eligibility functionality shall support web and mobile applications, agency review and status tracking, customer notifications, and appeals.

4. Customer database conversion and duplicate detection shall preserve the profile, assistance, conditional eligibility, and funding information needed for agency operations.

5. Scheduling and real-time operations shall preserve pickup windows, drop-off commitments, accommodations, and assistance requirements.

6. Authorized overrides, notices, exceptions, disputes, and outcomes shall be documented for compliance review.

7. Cost allocation and billing shall support multiple funding sources, configurable funding-entity rules, invoices, and reconciliation of trips, fares, allocated costs, and funding charges.

Detailed requirements: Platform requirements 405–512.

3.7 Fleet and Rider Commingling

1. The platform shall support fleet commingling and rider commingling only under the applicable configured rules.

2. Fleet commingling allows vehicles or drivers to serve different programs or services during a service period; rider commingling allows riders associated with different programs or services to share a vehicle when expressly permitted.

3. Assignments shall preserve eligibility, accessibility, safety, vehicle capacity, driver qualifications, service commitments, and other hard constraints.

4. Non-ADA optimization shall not cause an ADA trip denial, missed trip, delay, excessive ride time, or other service-standard violation.

5. Rider notifications shall protect other riders’ personal information.

6. Authorized dispatchers shall be able to review, approve, modify, prevent, or suspend commingled assignments as permitted by the configured rules.

7. The system shall maintain assignment audit trails and reproducible, exportable reporting by agency, program, service, vehicle pool, provider, eligibility, and funding source.

Detailed requirements: Platform requirements 704–798.

3.8 Integrations and Electronic Payments

1. The Contractor shall generate and maintain a valid GTFS Schedule feed supporting GTFS

Flex features for applicable services, including service zones, pickup and drop-off windows, booking rules, and contact or booking information.

2. The feed shall be published at an agency-approved stable URL and validated against the official specification.

3. EZFare/Masabi integration shall use approved interfaces and support fare calculation or retrieval, payment and validation workflows, cancellations, refunds or reversals where supported, authorized overrides, data protection, and reconciliation.

4. For agencies on EZConnect, customer calls shall be routed through the EZConnect call center and onward to agencies as needed, except for agencies excluded by NEORide.

5. Native electronic payments shall support credit cards, debit cards, supported mobile wallets, transaction lifecycle management, duplicate-charge prevention, security, fee disclosure, settlement, and trip-level reconciliation.

6. Payment functionality shall be vendor neutral.

7. Third-party fees shall be passed through at actual cost unless additional fees or markup are expressly identified and approved in the resulting contract.

Detailed requirements: Platform requirements 404, 685–703, 799, and 811–825.

3.9 Optional Capabilities

1. The workbook separately identifies optional IVR capabilities, Masabi/TappPay integration, and multimodal operations management.

2. Optional functions shall remain distinguishable from core requirements in the proposal and pricing.

3. The optional multimodal scope includes fixed-route schedule planning, publishing assignments to operator devices, GTFS Schedule import and export, unified vehicle monitoring, schedule adherence, transfer coordination, and GTFS Realtime publishing.

4. Optional Masabi/TappPay integration shall operate under the agency’s existing Masabi agreement without requiring replacement or transfer of that agreement.

Detailed requirements: Platform requirements 800–801 and 826–853; apply core and optional classifications as listed in the workbook.

4 Implementation Services

4.1 Requirements Traceability and Project Management

1. The Contractor shall establish and maintain a separate Requirements Traceability Matrix for each deploying agency to track compliance with the contract requirements.

2. The Contractor shall attend project meetings in person when required, with virtual attendance permitted when approved.

3. The Project Management Plan shall identify the functionality needed for revenue service, design and testing approach, acceptance, vehicle and operations rollout, software and feature delivery, consolidated schedule, progress, and risks.

4. The plan shall be updated at least monthly.

5. The Contractor shall host and participate in bi-weekly meetings, provide agendas covering open actions and high-priority risks, and issue detailed notes and actions within two business days.

Detailed requirements: Platform requirements 513–537.

4.2 Design and Configuration

1. The Contractor shall submit a Design Review Document covering the common system design and each agency’s configuration.

2. It shall address software modules, interfaces, screens, reports, data exchange fields, networks, user access, and data conversion procedures.

3. The Contractor shall incorporate agency feedback and identify agency-specific configurations before finalizing the design.

4. NEORide and the applicable Participating Agency shall sign off before implementation proceeds for that agency.

5. Implementation includes the configuration, integrations, and data migration identified in the scope and detailed requirements.

Detailed requirements: Platform requirements 538–555 and 427.

4.3 Testing and Acceptance

1. Each agency deployment shall include Sandbox Testing, Mini-Fleet Testing, System

Acceptance Testing, and Burn-in Testing.

2. The Contractor shall prepare agency-approved Acceptance Test Procedures and map test cases to the Requirements Traceability Matrix.

3. Written results shall identify test outcomes, retests, deficiencies, and responsible parties.

4. Burn-in Testing shall occur over 30 days after System Acceptance Testing.

5. It shall stop and restart as specified in the workbook when deficiencies cause outages, prevent operations, or create material risks.

6. Production customer data shall not be used in non-production environments without

NEORide and agency approval.

7. Final System Acceptance requires delivery of required equipment, systems, and services;

demonstration and validation of functionality; completion of training and documentation;

signed-off testing; and resolution of all issues in the deficiency list.

8. Advancement with unresolved deficiencies requires the approvals and corrective action plan specified in the workbook.

Detailed requirements: Platform requirements 556–598.

4.4 Documentation and Training

1. The Contractor shall provide tailored documentation, online materials available on demand at no additional cost, training videos, and role-specific courses for agency personnel, EZConnect Mobility Center staff, and NEORide staff.

2. Each agency shall receive separate training tailored to its deployed configuration.

3. NEORide and agencies shall have rights to record sessions and reproduce training materials.

4. Each agency training plan shall identify objectives, topics, duration, attendees, prerequisites, required resources, follow-up, and learning evaluation.

5. Materials shall be submitted for review at least two weeks before training.

6. The Contractor shall provide training for new modules, at least two refresher sessions for each agency annually covering its used modules, and annual IT security awareness and applicable role-based training.

Detailed requirements: Platform requirements 599–630.

5 Support Services

5.1 Service Level Agreements and Technical Support

1. Before project closeout, the Contractor shall negotiate Service Level Agreements with

NEORide and each applicable Participating Agency.

2. The agreements shall define support roles, incident reporting, response and resolution processes and timelines, priority and criticality criteria, incident examples, and exclusions from service-level calculations.

3. The Contractor shall provide maintenance and support to NEORide and agencies, with 24-hour, seven-day support for High Priority Incidents and business-day and business-hour support for Medium and Low Priority Incidents.

4. Maintenance Releases shall be provided at no additional fee during the Agreement and shall include release notes.

5. Production rollout shall follow release, testing, and approval.

6. Agency configuration activities identified in the requirements shall be included in the base contracted price throughout the contract term.

7. Any proposed configuration exception shall be identified in the proposal with a complete fee schedule or rate card covering the term and renewal periods.

Detailed requirements: Platform requirements 631–650.

5.2 Incident Reporting

1. High Priority Incidents shall be reportable by telephone and web at all times.

2. Medium and Low Priority Incidents shall be reportable by telephone during Contractor business hours and through the web at all times.

3. Web reporting shall provide an incident tracking number and confirmation of receipt.

4. NEORide shall provide available incident details and the requested priority.

5. The Contractor shall assign and communicate a priority if none is provided.

6. Either party may request priority review with supporting information.

Detailed requirements: Platform requirements 651–666.

5.3 Software Upgrades and Additional Training

1. Software Upgrades shall be available to NEORide and agencies at no additional license fee when the Maintenance Statement of Work has remained in force without interruption since original installation.

2. Upgrades requiring Contractor implementation services shall be addressed through a new Statement of Work identifying implementation fees, maintenance and support adjustments, and applicable approved third-party license fees.

3. The Contractor shall provide optional refresher training pricing, including base pricing and annual escalation, exercisable over the system’s lifetime for administrators, customer service representatives, planners, dispatchers, supervisors, and operators.

4. This optional pricing shall be distinguished from the annual training already required under Section 4.4.

Detailed requirements: Platform requirements 667–684.

6 Turnkey Microtransit Requirements Turnkey Services shall use the Mobility Platform and follow each Participating Agency’s service configuration. The Contractor shall provide the operational resources and functions described below and in the Turnkey Microtransit requirements workbook.

6.1 Fleet and Maintenance

1. Each agency shall select an agency-provided, Contractor-provided, or mixed fleet.

2. The Contractor shall provide, own, or lease vehicles only when the agency elects a

Contractor-provided fleet and shall operate and maintain assigned vehicles to the applicable standards regardless of ownership.

3. The Contractor shall submit a fleet plan and replacement schedule, provide sufficient accessible capacity, maintain the required active and spare fleet, and supply onboard equipment and connectivity as specified.

4. Vehicle approval, age, mileage, accessibility, safety equipment, cleanliness, preventive maintenance, breakdown recovery, and maintenance records shall meet the detailed requirements.

Detailed requirements: Turnkey requirements 1–42.

6.2 Service Delivery

1. The Contractor shall execute trips using Mobility Platform manifests and agency service rules.

2. Pickup, drop-off, assistance, fare collection, no-show and cancellation practices shall follow the agency’s configured policies and applicable requirements.

3. The Contractor shall manage delays, rider notifications, service disruptions, safe boarding and alighting, operator conduct, and service recovery.

4. Performance shall be measured against the agency’s service configuration and the detailed operational requirements.

Detailed requirements: Turnkey requirements 43–72.

6.3 Operators and Staffing

1. The Contractor shall source, qualify, train, supervise, and remove operators as needed, including operators supplied through subcontractors.

2. Licensing, driving records, background screening, drug and alcohol testing, initial and recurring training, conduct, and recordkeeping shall meet the detailed requirements.

3. The Contractor shall provide a staffing plan, agency contract contact, management, supervisory coverage, backup staffing, and local operations presence.

4. Staff availability, employment records, recurring staffing reports, and in-person response to material operational issues shall follow the workbook.

Detailed requirements: Turnkey requirements 73–104 and 179–194.

6.4 Dispatch and Scheduling

1. Qualified dispatch staff shall monitor and manage operations during all scheduled service hours, using the Mobility Platform and approved procedures.

2. Dispatch shall manage assignments, manual overrides, communications, disruptions, escalation, and operational records.

3. Where regional coordination applies, dispatch shall coordinate trip assignments, vehicle availability, and capacity with the regional mobility center or EZConnect.

4. Brokered and third-party services shall be coordinated and monitored to the standards in the detailed requirements.

Detailed requirements: Turnkey requirements 105–135.

6.5 Safety and Facilities

1. The Contractor shall maintain a safety program covering personnel, vehicles, and facilities, investigate accidents and incidents, preserve relevant footage and chain-of-custody records, and provide required safety and regulatory reporting.

2. Emergency preparation, service suspension, security, and support for applicable agency safety-plan obligations shall follow the detailed matrix.

3. The Contractor shall provide or contract for the facilities needed for fleet storage, fueling or charging, dispatch, and operator support.

4. Facility locations and layouts require agency approval.

5. Facilities shall meet the applicable security, accessibility, environmental, safety, insurance, and inspection requirements, with fueling or charging contingency procedures.

Detailed requirements: Turnkey requirements 136–178.

6.6 Customer Service

1. An agency may perform some or all customer service functions directly or divide them with the Contractor.

2. The Contractor shall provide the platform access, trip and account information, field support, and documented handoffs needed for the agency’s elected arrangement.

3. Contractor customer service shall follow agency-approved standards, scripts, policies, hours, and communication arrangements.

4. Booking changes, inquiries, complaints, lost-and-found, staff training, and customer service records shall meet the detailed requirements and response timelines.

Detailed requirements: Turnkey requirements 195–199 and 292–310.

6.7 Performance Reporting and Billing

1. The Contractor shall meet agency performance standards and provide KPI reporting with definitions, underlying measures, results, targets, variances, trends, and explanations.

2. The reports and supporting data shall distinguish the applicable agency, service, and provider.

3. Invoices shall be itemized in the approved format and supported by verifiable operating-unit or trip-level data.

4. Shared-trip cost allocations, fixed and recurring items, cost summaries, and reconciliation to Mobility Platform and operational records shall follow the detailed reporting and billing requirements.

Detailed requirements: Turnkey requirements 200–239.

6.8 Subcontractors and Third Party Providers

1. The Contractor shall remain responsible for subcontractor and non-dedicated service provider performance.

2. Provider approval, qualifications, accessibility, service continuity, monitoring, and reporting shall meet the requirements applicable to the provider and service model.

3. Transportation network company assignments shall follow agency authorization, monthly quotas, spending limits, exception approvals, and monitoring requirements.

4. Authorized transportation charges shall be passed through at actual documented eligible cost without markup, net of applicable credits and discounts.

5. Coordination fees shall be separately identified, with monthly trip-level invoice support and third-party billing records available for agency review.

Detailed requirements: Turnkey requirements 240–273.

6.9 Mobilization and Service Closeout

1. Mobilization and transition are included in the Turnkey Services scope and shall coordinate the vehicles, workforce, facilities, dispatch, customer service, compliance, and launch activities identified in the accompanying pricing sheet and applicable requirements.

2. At expiration or termination, the Contractor shall support an orderly service transition, provide a transition-out plan, coordinate transfer of data and ongoing service responsibilities, meet applicable workforce and facility notice requirements, and remove or transfer equipment and branding as applicable.

3. Agency and rider data shall be returned or securely deleted following confirmation of successful transfer, subject to required retention.

Detailed requirements: Turnkey requirements 274–291; accompanying Turnkey Service Price Sheet.

7 Proposal and Pricing Requirements Proposers shall provide a brief outline of their capabilities and complete both pricing sheets, including fixed implementation costs, recurring platform charges, turnkey start-up costs, operating rates, and applicable escalation percentages. Pricing shall include all costs necessary to deliver the specified services and clearly identify assumptions, exclusions, and optional items.

NEORide follows a procurement process that ensures free and open competition and requires prices to be fair and reasonable.

See the Mobility Platform and Turnkey Microtransit requirements workbooks and accompanying pricing sheets for the full scope.

7.1 Appendix B & E Compliance Matrices

The detailed compliance matrices are provided in Attachment B (Turnkey Microtransit Requirements) and Attachment E (Mobility Platform/SaaS Requirements).

Proposers shall complete both matrices using the compliance statuses and response instructions included in each workbook. Platform and turnkey requirement numbers are separate sequences; references in this document identify the applicable matrix.

7.2 Appendix C & D Pricing Sheets

The accompanying pricing sheets are provided separately.