NEORide_SaaS_Requirements.xlsx

XLSX spreadsheet 74 KB Posted Oct 12, 2026

Attached to: Microtransit, Paratransit and Turnkey Transportation Services
Solicitation number: 2026-RFP -3
Issued by: Summit County, Ohio

About this file

Written by GovTribe AI · Oct 13, 2026

This is a SaaS Requirements Compliance Matrix for NEORide, a regional transportation consortium in Ohio, outlining comprehensive specifications for a Microtransit, Paratransit, and Turnkey Transportation Services platform. The RFP solicits proposals for an integrated mobility platform capable of managing demand-response transportation, ADA paratransit, and microtransit services across multiple participating agencies. The platform must be delivered as a Software-as-a-Service (SaaS) model and include rider-facing mobile and web applications for Android and iOS devices, vehicle operator applications, central dispatch and operations management systems, interactive voice response (IVR) capabilities, and comprehensive reporting functionality. Proposals must be submitted electronically by Friday, November 20, 2026 at 4:00 PM EST. The contract will be established through a Master Service Agreement with NEORide, with individual Participating Agencies executing partnership agreements to utilize the platform. The contract term and renewal options are subject to the Master Service Agreement terms referenced in the solicitation attachments.

The requirements matrix specifies 507 core functional requirements organized into categories including IT infrastructure, cloud services, cybersecurity, data access and portability, rider-facing applications, vehicle operations, central system management, ADA paratransit compliance, and GTFS Flex feed generation. Critical infrastructure requirements include 99.95% system availability, disaster recovery with one-hour recovery time objectives, geographic redundancy, data encryption at rest and in transit, and multi-factor authentication for administrative users. The platform must provide agencies with automated, unmetered access to trip-level data through APIs and bulk exports at no additional cost. Proposers must indicate compliance status (C for comply, N for not comply, or CM for conditional compliance) for each requirement and provide specific proposal section and page references. Pricing terms, set-aside provisions, incumbent contractor information, and detailed funding sources are not specified in this requirements document and are addressed separately in the RFP solicitation materials.

View the file

Other files

File	Type	Posted
Microtransit,_Paratransit_and_Turnkey_Transportation_Services.pdf	PDF	Oct 12, 2026
NEORide_Tunkey_Service_Price_Sheet.xlsx	XLSX spreadsheet	Oct 12, 2026
NEORide_microtransit_turnkey_Requirements.xlsx	XLSX spreadsheet	Oct 12, 2026
NEORide_Mobility_Platform_and_Turnkey_SOW.pdf	PDF	Oct 12, 2026
Sample_Participation_Agreement.pdf	PDF	Oct 12, 2026
NEORide_SaaS_price_sheet.xlsx	XLSX spreadsheet	Oct 12, 2026
Sample_MSA_.pdf	PDF	Oct 12, 2026

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Compliance Matrix

Instructions for filling out the matrix

The proposer is required to indicate the compliance status relative to each individual requirement listed in the Compliance Matrix. For each requirement, the proposer must indicate if its proposed system will comply (C); not comply (N); or comply only if NEORide accepts a proposed modified version of the requirement (CM).

No additional commentary shall be provided for responses of “C” or “N” unless the proposer exceeds the requirement (see below). For each requirement marked with a “C” or “CM,” proposers are required to provide a reference to exactly where in the proposal there is a description of how this requirement will be met. Proposers must provide at least the section and page numbers of the part of the proposal that verifies the claim that the proposer complies with the requirement.

A response of “CM” should only be used to indicate that the proposer will comply if the requirement wording is changed to specific alternate text that must be provided by the proposer in the column provided. A response of “CM” will be equivalent to a response of “C” if NEORide agrees to change the requirement as proposed, or equivalent to a response of “N” if NEORide decides to not change the requirement. If alternate requirement wording is not included in the matrix in conjunction with a “CM” response, this will be treated as an “N” response.

In the situation where the proposer exceeds the stated requirement, the proposer must indicate a response of “C” for the compliance status and must provide an explanation as to how that requirement exceeds the original requirement.

Req. No	Core vs Optional	Category	Sub-category	Requirement	Proposed Compliance Status (C/N/CM)	Proposed Modified Requirement Text (required for CM or where the requirement is exceeded)	Proposal Reference (Section No. & Page No.)
1	Core	IT	Cloud Infrastructure	The Contractor shall provide SaaS based model for providing the required functionality described in the scope of work.
2	Core	IT	Cloud Infrastructure	System operation in a multi-tenant platform is acceptable, provided that, in addition to Contractor staff, only authorized NEORide staff and Participating Agency (designated users, have access to NEORide data).
3	Core	Testing	Test Environment	The Contractor shall deliver and maintain at least two instances for each agency: test and production.
4	Core	Testing	Test Environment	The Contractor shall make provisions for designated users at NEORide and Participating Agencies to test any new updates, patches, upgrades and configuration changes to the customer mobile application, and back-office system before being implemented in the production environment.
5	Core	IT	Cloud Infrastructure	The Contractor shall be responsible for designing, configuring, delivering, installing, testing, and ensuring the availability of all required system functionality.
6	Core	IT	Cloud Infrastructure	The system and services shall maintain 99.95% availability as measured on a rolling monthly and annual basis, excluding pre-approved system maintenance down time and issues with networks provided by other Contractors. This applies to all software components (central system, rider app, customer service, website, etc.) procured through this contract.
7	Core	IT	Cloud Infrastructure	The Contractor shall provide monthly availability reports to NEORide and Participating Agencies, including uptime percentage, incidents, duration of outages, root cause summaries, corrective actions, and any excluded maintenance periods.
8	Core	Testing	Test Environment	The Contractor shall test all updates, patches, upgrades, and configuration changes on Contractor's internal development environment prior to being implemented in the production environment. Reports of this testing shall be provided to NEORide and its Participating Agency upon request.
9	Core	IT	Cloud Infrastructure	The Contractor shall provide a Disaster Recovery Plan highlighting how continued functionality can be provided in a disaster scenario (e.g. failover architecture, backup strategy, geographic redundancy, recovery procedures, escalation contacts, fallback, recovery point objective [RPO], and recovery time objective [RTO]).
10	Core	IT	Cloud Infrastructure	The Disaster Recovery Plan shall highlight the redundancy infrastructure and geographic redundancy at NEORide level and Participating Agency.
11	Core	IT	Cloud Infrastructure	The Contractor shall test its disaster recovery and failover procedures at least annually and provide NEORide with a summary of test results, issues identified, and corrective actions taken.
12	Core	IT	Cloud Infrastructure	Any system failover to support disaster recovery shall be completed within a recovery time objective (RTO) of one (1) hour.
13	Core	IT	Cloud Infrastructure	The Contractor shall ensure that failover and failback procedures preserve data integrity and do not result in duplicate records, corrupted records, or loss of committed transactions.
14	Core	IT	Cloud Infrastructure	The system shall automatically switch to geographically redundant secondary (failover) site in case the primary site is unavailable. A secondary (failover) site shall be available when the system goes into revenue service. This applies to all the instances (if running unique instance per Participating Agency).
15	Core	IT	Cloud Infrastructure	The system shall not lose any data when transitioning over from the primary to secondary site during a disaster induced failover or test, or when transition back from the secondary to primary site.
16	Core	IT	Cloud Infrastructure	The system shall maintain a data backup of all the operational data for Participating Agency at all times.
17	Core	IT	Cloud Infrastructure	Contractor shall not deploy material changes to production without NEORide approval, except for emergency security patches or critical incident remediation.
18	Core	IT	Cybersecurity	NEORide shall have access to data from Participating Agencies, as authorized by a Participating Agency for the operation of other NEORide infrastructure like EZConnect or EZData.
19	Core	IT	Cybersecurity	The Participating Agency shall have access to a subset of data that is linked to said agency (e.g. role [agency-based] data access). When agencies in a region intend to coordinate services (e.g., via EZConnect center operations), the Contractor shall enable the Mobility Platform to allow such service coordination.
20	Core	IT	Cybersecurity	Supplied applications shall provide secure data exchange via transport layer security/secure socket layer protocol (version 1.2 or higher).
21	Core	IT	Cybersecurity	Supplied applications shall be digitally signed with established third-party Certification Authorities using methods appropriate to the targeted platforms.
22	Core	IT	Cybersecurity	The system shall track and monitor all access and attempted access, including suspected threats to network resources, field devices, applications, and cardholder data.
23	Core	IT	Cybersecurity	Vulnerabilities or exploits discovered by the Contractor or others shall be reported to NEORide and its Participating Agencies immediately (within 1 [one] business day of identification of issue) with a proposed mitigation strategy and remediation plan with expected resolution dates.
24	Core	IT	Cybersecurity	Application security shall be provided in accordance with best practices identified in the National Institute of Standards and Technology (NIST) Cybersecurity Framework or an equivalent alternative published standard from a recognized security-standards body, if approved by NEORide and its Participating Agencies.
25	Core	IT	Cybersecurity	The Contractor shall inform NEORide and its Participating Agencies of any security breaches or data loss within 1 (one) business day of discovery of the incident.
26	Core	IT	Cybersecurity	The Contractor shall provide a detailed security incident response plan. The incident plan shall include the incident reporting process and how details of an incident will be communicated to NEORide and its Participating Agencies and, if deemed appropriate by NEORide and its Participating Agencies, to the riders.
27	Core	IT	Cybersecurity	The Contractor shall provide a detailed security incident response plan. The incident plan shall include, Process for reporting vulnerabilities or exploits discovered by the Contractor or others and include at minimum a proposed mitigation strategy and remediation plan with expected resolution dates.
28	Core	IT	Cybersecurity	The Contractor shall provide annual assurance statements of recertification and regulatory compliance delivered to NEORide’s Contract Liaison. The Contractor shall provide annual attestations of compliance program certifications relevant to the controls and security plan devised for the solution or system.
29	Core	IT	Cybersecurity	The Contractor shall document a system security plan describing the Contractor's safeguards for the privacy of Participating Agency and customer data.
30	Core	IT	Cybersecurity	The system security plan shall include a description of all customer data collected, used, or stored, in accordance with applicable Federal, State, and Local regulations.
31	Core	IT	Cybersecurity	The system security plan shall include a statement of purpose for the collection of each category of personally identifiable information (PII).
32	Core	IT	Cybersecurity	The system security plan shall include a description of the data quality and integrity checks used to validate and verify PII.
33	Core	IT	Cybersecurity	The system security plan shall include a description of the data minimization and retention checks that ensure PII collected, used, and retained is relevant and necessary for the purpose for which it was originally collected.
34	Core	IT	Cybersecurity	The Contractor shall provide notice of a loss or suspected loss of privacy sensitive data to NEORide and its Participating Agency, within 24 hours of loss or suspected loss.
35	Core	IT	Cybersecurity	The Contractor shall perform annual independent penetration testing or equivalent third-party security assessments and provide NEORide with an executive summary of findings, remediation status, and residual risk.
36	Core	IT	Cybersecurity	The Contractor shall encrypt NEORide and Participating Agency data at rest and in transit using current industry-standard encryption protocols and practices.
37	Core	IT	Access Control	The system shall support agency-based data access controls to ensure each Participating Agency can access only the data, records, reports, users, and functions authorized for that agency, unless broader access is expressly authorized for regional coordination or EZConnect mobility center operations.
38	Core	IT	Access Control	The system shall support privilege access, allowing administrators to assign only the minimum permissions required for a user, role, agency, contractor personnel, or third-party user to perform authorized duties.
39	Core	IT	Access Control	The system shall support multi-factor authentication for administrative users, privileged users, Contractor support personnel, and any user with access to sensitive data or production system configuration.
40	Core	IT	Access Control	The system shall have the ability to regulate access to functionality and access to data for authorized external or third-party users.
41	Core	IT	Access Control	The system shall record login, logout and configuration change activities of all users from NEORide and its Participating Agency.
42	Core	IT	Access Control	The activity log shall be accessible by authorized system administrators from each agency for audit.
43	Core	IT	Access Control	Access control shall be configurable by NEORide and its Participating Agency -authorized system administrators.
44	Core	IT	Access Control	The system shall allow authorized administrators to create, modify, suspend, deactivate, and remove user accounts and role assignments.
45	Core	IT	Data Access	The Contractor shall provide each Participating Agency with automated, direct, unmetered access at the base contract price to its complete trip level, vehicle level, event level, and other authorized record level data through both a documented API and scheduled bulk exports. Export frequency shall be agency configurable to at least daily, and historical data shall remain accessible throughout the full contract term. Access shall not be subject to charges or limits based on API calls, record count, data volume, connection frequency, or export frequency.
46	Core	IT	Data Access	The Contractor shall provide documentation for all data access methods, including API specifications, authentication requirements, data dictionaries, field definitions, update frequency, rate limits, and known limitations.
47	Core	IT	Data Access	The Contractor shall support secure data access using industry-standard authentication, authorization, encryption in transit, and logging for APIs, database connections, file transfers, and other data exchange methods.
48	Core	IT	Data Access	The Contractor shall provide data in commonly used, machine-readable formats, such as CSV, JSON, XML, or other formats approved by NEORide and its Participating Agencies.
49	Core	IT	Data Access	The Contractor shall ensure that agency-specific data access is limited based on authorization, agency ownership, applicable privacy requirements, and any approved regional service coordination arrangements.
50	Core	IT	Data Access	Upon request or contract termination, the Contractor shall provide a complete export of NEORide and Participating Agency data as per NEORIde's direction, machine-readable format and shall certify secure deletion of data not required to be retained by law or approved retention policy.
51	Core	IT	Data Access	At least one data-delivery method shall provide raw, unformatted CSV or Excel-compatible data suitable for automated ingestion into SQL, database, data-warehouse, and business-intelligence tools.
52	Core	IT	Data Access	Upon contract termination or expiration, the Contractor shall securely delete or return all NEORide and Participating Agency data within a specified period (e.g., 90 days) following written confirmation of successful data transfer, except where retention is required by law.
53	Core	IT	Data Access and Portability	Each Participating Agency shall own its data and all Agency-specific configurations, data models, reports, and dashboards developed for it, excluding the Contractor’s pre-existing intellectual property. The Contractor shall provide these materials in documented, editable, and commonly used formats upon request or contract termination at no additional cost.
54	Core	Rider Facing	Rider Application	The rider application shall have the option for NEORide branding.
55	Core	Rider Facing	Rider Application	All rider-facing web and mobile functionality shall conform to WCAG 2.1 Level AA and applicable federal accessibility requirements. The Contractor shall provide a current Accessibility Conformance Report, VPAT, or equivalent documentation and shall remediate identified accessibility defects in accordance with agreed severity and resolution requirements.
56	Core	Rider Facing	Rider Application	The system shall provide individual mobile application for each Participating Agency.
57	Core	Rider Facing	Rider Application	The Rider facing Application shall be capable of managing both Paratransit and DRT/Microtransit trips.
58	Core	Rider Facing	Trip Planning	The rider-facing applications shall present demand-response-to-fixed-route connecting itineraries when available. Customers shall be able to book the demand-response leg.
59	Core	Rider Facing	Mobile and Web Application	The Contractor shall provide a customer-facing mobile application in native format for Android and iOS devices.
60	Core	Rider Facing	Mobile and Web Application	The Contractor shall provide a customer-facing web application that supports the customer functions required in this section.
61	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall permit customers to manage account information, including address, email address, phone number, mobile number, location tracking preferences, notification preferences, and trip history.
62	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall allow customers to plan, book, and modify trips based on the service configuration and policies of the applicable Participating Agency.
63	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall allow customers to save favorite pick-up and drop-off locations for future trip planning.
64	Core	Rider Facing	Mobile and Web Application	Saved favorite pick-up and drop-off locations shall be available, where supported, through the IVR, website, and mobile application.
65	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall permit customers to access historical trip records, including trip details and trip status history such as completed, cancelled, missed, or no-show trips, for at least the most recent 24 months.
66	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall permit customers to access NEORide and Participating Agency-related information, including announcements, fare policies, service bulletins, customer policies, and user training materials.
67	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall provide customer aids, instructions, and help content in accordance with requirements established by NEORide and the Participating Agencies.
68	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall support both single-user accounts and multiple-user account structures, including accounts for dependents, institutions, and wards.
69	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall allow customers to authorize a third party, such as a caregiver, to book and manage trips on the customer’s behalf.
70	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall provide real-time trip status updates to customers based on their notification preferences.
71	Core	Rider Facing	Mobile and Web Application	Real-time trip status updates shall include, at minimum, predicted pick-up arrival time or other vehicle arrival status information when available.
72	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall support customer modifications to existing trips in accordance with applicable Participating Agency policy.
73	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall provide customers with the option to request help and speak with a customer service representative by phone during business hours.
74	Core	Rider Facing	Mobile and Web Application	Calls requested or initiated after business hours shall be routed to the incoming IVR system.
75	Core	Rider Facing	Mobile and Web Application	The customer-facing web application shall provide customers with the option to request help through live web chat during business hours.
76	Core	Rider Facing	Mobile and Web Application	The system shall track the time and pick-up/drop-off locations associated with customer trip search requests, subject to approved configuration.
77	Core	Rider Facing	Mobile and Web Application	The system shall track the time and pick-up/drop-off locations associated with denied trip requests, subject to approved configuration.
78	Core	Rider Facing	Mobile and Web Application	The system shall track the time and pick-up/drop-off locations associated with completed trip requests, subject to approved configuration.
79	Core	Rider Facing	Mobile and Web Application	The system shall track the time and pick-up/drop-off locations associated with unfulfilled trip requests, including no-show, missed, and cancelled trips, subject to approved configuration.
80	Core	Rider Facing	Mobile and Web Application	The system shall track the reason for each unfulfilled trip request when such reason is available.
81	Core	Rider Facing	Mobile and Web Application	The system shall track the payment amount and payment method for each completed trip, subject to approved configuration and applicable privacy, security, and payment-processing requirements.
82	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall allow customers to select and update preferred communication channels, including push notification, SMS/text message, email, automated phone call, or other approved methods.
83	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall provide trip confirmations, reminders, arrival updates, cancellation notices, modification notices, and service disruption notices based on customer notification preferences.
84	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall clearly display trip eligibility, booking rules, cancellation rules, fare information, no-show policies, and any applicable agency-specific service constraints before trip confirmation.
85	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall allow customers to securely reset passwords, recover accounts, and update authentication information.
86	Core	Rider Facing	Mobile and Web Application	The customer-facing mobile and web applications shall protect customer data through secure authentication, encrypted transmission, session timeout, and other safeguards consistent with the cybersecurity requirements of this RFP.
87	Core	Rider Facing	Mobile and Web Application	The system shall maintain audit records of customer account changes, delegated access authorizations, trip bookings, trip modifications, trip cancellations, payment actions, and notification preference changes.
88	Core	Rider Facing	IVR	When IVR trip booking is enabled for a Participating Agency, the IVR shall allow customers to book trips to and from saved favorite pick-up and drop-off locations.
89	Core	Rider Facing	IVR	The IVR shall allow customers to inquire about booked trips, including trip status and other trip details made available by the Mobility Platform.
90	Core	Rider Facing	IVR	The IVR shall allow customers to cancel planned trips in accordance with applicable Participating Agency policies.
91	Core	Rider Facing	IVR	The IVR shall support automated outbound phone calls when a vehicle is approaching for pick-up, if the customer has selected automated calls as a communication preference.
92	Core	Rider Facing	IVR	The IVR shall support SMS/text message notifications when a vehicle is approaching for pick-up, if the customer has selected SMS/text messaging as a communication preference.
93	Core	Rider Facing	IVR	The system shall allow customers to contact Participating Agency customer service representatives through the IVR.
94	Core	Rider Facing	IVR	The system shall provide an API or other approved integration method that allows IVR booking activity to be tracked and reported.
95	Core	Rider Facing	IVR	The system shall track the number of trips booked through the IVR by Participating Agency, customer, date, time, and service type, subject to approved configuration and applicable privacy requirements.
96	Core	Rider Facing	IVR	The IVR shall provide after-hours messaging and routing in accordance with NEORide and Participating Agency requirements.
97	Core	Rider Facing	IVR	The IVR shall support agency-specific service configurations, including eligibility rules, booking windows, cancellation rules, service areas, fare policies, and notification preferences.
98	Core	Rider Facing	Registration and Eligibility	The system shall allow new users to register for demand-response transportation, microtransit, or other applicable services with a Participating Agency.
99	Core	Rider Facing	Registration and Eligibility	The system shall collect registration information required by the applicable Participating Agency, subject to approved configuration.
100	Core	Rider Facing	Registration and Eligibility	The system shall allow users to identify disability-related accommodations, mobility devices, service animals, personal care attendants, companions, and other trip assistance needs as applicable.
101	Core	Rider Facing	Registration and Eligibility	The system shall alert authorized users when a potential duplicate customer account is identified during registration or account creation.
102	Core	Rider Facing	Registration and Eligibility	Potential duplicate account alerts shall be based on configurable matching criteria, which may include name, date of birth, phone number, email address, address, customer ID, or other approved identifiers.
103	Core	Rider Facing	Registration and Eligibility	The system shall allow Participating Agency-authorized users to review registration requests.
104	Core	Rider Facing	Registration and Eligibility	The system shall allow Participating Agency-authorized users to approve registration requests.
105	Core	Rider Facing	Registration and Eligibility	The system shall allow Participating Agency-authorized users to reject registration requests.
106	Core	Rider Facing	Registration and Eligibility	The system shall allow Participating Agency-authorized users to request additional information from applicants before approving or rejecting a registration request.
107	Core	Rider Facing	Registration and Eligibility	The system shall notify users of registration submission, approval, rejection, or requests for additional information, based on the user’s communication preferences.
108	Core	Rider Facing	Registration and Eligibility	The system shall allow users to access trip planning, booking, and information functions in Guest Mode when enabled by the applicable Participating Agency.
109	Core	Rider Facing	Registration and Eligibility	Guest Mode shall require only the minimum information necessary for unique customer identification, communication, trip booking, and service delivery.
110	Core	Rider Facing	Registration and Eligibility	Guest Mode shall support collection of basic contact information, such as email address and phone number, as configured by the applicable Participating Agency.
111	Core	Rider Facing	Registration and Eligibility	The number of trips a customer may book in Guest Mode shall be limited based on applicable Participating Agency policy.
112	Core	Rider Facing	Registration and Eligibility	The system shall allow Participating Agencies to configure whether Guest Mode is available for their services.
113	Core	Rider Facing	Registration and Eligibility	The system shall support agency-specific registration workflows, eligibility rules, required fields, approval steps, and documentation requirements.
114	Core	Rider Facing	Registration and Eligibility	The system shall allow customers to upload or submit required eligibility documentation when required by a Participating Agency.
115	Core	Rider Facing	Registration and Eligibility	The system shall allow Participating Agency-authorized users to record multiple concurrent program-specific eligibility and enrollment records for each customer, including the program, eligibility status, enrollment status, effective date, expiration date, service type, fare category, and conditional eligibility limitations.
116	Core	Rider Facing	Registration and Eligibility	The system shall allow customers to update registration information after account creation, subject to agency review where required.
117	Core	Rider Facing	Registration and Eligibility	The system shall maintain an audit history of registration submissions, edits, approvals, rejections, eligibility changes, and reviewer actions.
118	Core	Rider Facing	Registration and Eligibility	The registration process shall be accessible through the customer-facing web and mobile applications and shall comply with applicable accessibility requirements.
119	Core	Rider Facing	Registration and Eligibility	The system shall allow authorized staff to create or assist with customer registrations on behalf of customers who register by phone, in person, or through another approved channel.
120	Core	Rider Facing	Trip Planning	The system shall allow customers and authorized users to plan on-demand trips for services offered by the applicable Participating Agency.
121	Core	Rider Facing	Trip Planning	The system shall allow customers and authorized users to plan future trips for services offered by the applicable Participating Agency up to at least two weeks in advance.
122	Core	Rider Facing	Trip Planning	The system shall display available multimodal trip options based on the applicable Participating Agency’s service configuration.
123	Core	Rider Facing	Trip Planning	The system shall display real-time vehicle availability when such information is available.
124	Core	Rider Facing	Trip Planning	The system shall display real-time driver availability when such information is available.
125	Core	Rider Facing	Trip Planning	The system shall display the fare or price for each available trip option when fare information is available.
126	Core	Rider Facing	Trip Planning	The system shall display the expected travel time between the selected pick-up and drop-off locations for each available trip option.
127	Core	Rider Facing	Trip Planning	The system shall present fixed-route transit options when fixed-route options are available for the requested trip.
128	Core	Rider Facing	Trip Planning	The system shall present real-time status for fixed-route transit options when real-time status information is available.
129	Core	Rider Facing	Trip Planning	The system shall allow riders to identify mobility preferences and assistance needs for customized trip planning.
130	Core	Rider Facing	Trip Planning	Mobility preferences and assistance needs shall include mobility aids, service animals, personal care attendants, companions, or other agency-approved trip assistance needs where applicable.
131	Core	Rider Facing	Trip Planning	The system shall allow riders to identify applicable funding sources, fare programs, subsidies, eligibility categories, or payment programs used to determine accurate fare information.
132	Core	Rider Facing	Trip Planning	The customer-facing application shall allow customers to select exact pick-up and drop-off locations using a map view.
133	Core	Rider Facing	Trip Planning	The customer-facing application shall allow customers to select pick-up and drop-off locations using points of interest, landmarks, or other searchable location references.
134	Core	Rider Facing	Trip Planning	The system shall apply Participating Agency service rules, service areas, eligibility rules, booking windows, and operating hours when presenting trip planning options.
135	Core	Rider Facing	Trip Planning	The system shall allow customers to save planned trip details before booking where supported by agency policy.
136	Core	Rider Facing	Trip Planning	The system shall support address validation, geocoding, and correction prompts for ambiguous or incomplete pick-up and drop-off locations.
137	Core	Rider Facing	Trip Planning	The system shall identify whether a selected pick-up or drop-off point is within the applicable service area.
138	Core	Rider Facing	Service Configuration	The system shall allow authorized Participating Agency users to configure the service models offered by that agency, including curb-to-curb, door-to-door, door-through-door, corner-to-corner, virtual-stop, and other supported service models
139	Core	Rider Facing	Trip Booking	The system shall allow customers and authorized users to book a trip from eligible demand-response, microtransit, or other non-fixed-route options presented through the trip planning interface.
140	Core	Rider Facing	Trip Booking	The system shall not allow customers to book fixed-route transit options unless specifically configured by NEORide or the applicable Participating Agency.
141	Core	Rider Facing	Trip Booking	The system shall immediately confirm successfully booked trips.
142	Core	Rider Facing	Trip Booking	The system shall provide a unique confirmation number for each successfully booked trip.
143	Core	Rider Facing	Trip Booking	The system shall support booking workflows in which final vehicle assignment occurs on the day of service or within a configurable period before pick-up.
144	Core	Rider Facing	Trip Booking	The system shall reserve required vehicle capacity, vehicle type, accessibility accommodations, mobility device capacity, service animal accommodations, and other approved trip requirements at the time of booking.
145	Core	Rider Facing	Trip Booking	The system shall prevent same-day denial of a confirmed trip due solely to failure to account for reserved vehicle type, accessibility accommodations, mobility device capacity, or other approved trip requirements at the time of booking.
146	Core	Rider Facing	Trip Booking	The system shall allow customers and authorized users to book return trips when requested by the customer and permitted by applicable Participating Agency policy.
147	Core	Rider Facing	Trip Booking	The system shall allow customers and authorized users to book multiple trip legs within the same transaction when requested by the customer and permitted by applicable Participating Agency policy.
148	Core	Rider Facing	Trip Booking	The system shall apply applicable Participating Agency service rules, eligibility rules, booking windows, service areas, fare rules, capacity constraints, and operating hours before confirming a trip booking.
149	Core	Rider Facing	Trip Status	The system shall support approaching vehicle notifications through the customer’s configured communication channels, including IVR, in-app notification, SMS/text message, and email.
150	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall display the real-time location of the assigned vehicle while it is approaching the pick-up location, when available.
151	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall display when the assigned vehicle has arrived at the pick-up location, when available.
152	Core	Rider Facing	Trip Status	The customer-facing mobile application shall allow customers to view their own real-time location during an active trip.
153	Core	Rider Facing	Trip Status	The customer-facing mobile application shall allow customers to share their real-time location with dispatching agents and with the assigned driver or assigned vehicle during an active trip, where enabled by Participating Agency policy.
154	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall allow customers to communicate with the assigned driver during the pick-up stage through approved text, phone, or in-app communication methods.
155	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall display assigned vehicle identifying information when available.
156	Core	Rider Facing	Trip Status	Assigned vehicle identifying information shall include vehicle type, vehicle number, license plate number, make/model, or other approved identifiers available to help the customer identify the correct vehicle.
157	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall display current trip status information for booked trips.
158	Core	Rider Facing	Trip Status	Current trip status information shall distinguish between scheduled, assigned, approaching, arrived, in progress, completed, cancelled, missed, and no-show statuses, as applicable.
159	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall display fallback trip status information when real-time vehicle location data is unavailable.
160	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall display the estimated pick-up time window and estimated drop-off time for each booked trip when available.
161	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall update estimated arrival and trip status information when dispatch assignments, traffic conditions, driver status, or service conditions change.
162	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall clearly distinguish between estimated, scheduled, and real-time trip status information.
163	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall display material changes to a booked trip, including changes to assigned vehicle, estimated arrival time, pick-up window, trip delay, or trip cancellation.
164	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall provide customers with clear instructions when a vehicle is delayed, reassigned, has arrived, or is unable to complete the scheduled pick-up.
165	Core	Rider Facing	Trip Status	The customer-facing mobile and web applications shall allow customers to refresh trip status information on demand.
166	Core	Rider Facing	Trip Status	The system shall make trip status information available to authorized customer service representatives and dispatch users so they can assist customers with booked or active trips.
167	Core	Vehicle Application	General	The Contractor shall provide a native vehicle application for Android and iOS devices.
168	Core	Vehicle Application	General	Participating Agencies shall be responsible for procuring and maintaining vehicle hardware used to operate the vehicle application.
169	Core	Vehicle Application	General	The vehicle application shall allow operators to record arrival at pick-up and drop-off locations.
170	Core	Vehicle Application	General	Participating Agencies shall be responsible for procuring and maintaining cellular connectivity used to operate the vehicle application.
171	Core	Vehicle Application	General	The vehicle application shall allow operators to record odometer readings upon arrival at pick-up and drop-off locations.
172	Core	Vehicle Application	General	The Contractor shall identify vehicle hardware, operating system, device management, and connectivity requirements necessary to support reliable operation of the vehicle application.
173	Core	Vehicle Application	General	The vehicle application shall allow operators to view customer assistance notes necessary to safely complete the assigned trip.
174	Core	Vehicle Application	General	The Contractor shall identify methods used to secure trip data transmitted to and from the vehicle application.
175	Core	Vehicle Application	General	The Contractor shall provide guidance to Participating Agencies regarding appropriate cellular connectivity requirements for use with the vehicle application.
176	Core	Vehicle Application	General	The Contractor shall implement application-level data protection for the vehicle application and shall not rely solely on cellular carrier-provided security controls.
177	Core	Vehicle Application	General	The vehicle application shall provide operators with assigned trip manifests.
178	Core	Vehicle Application	General	The vehicle application shall provide operators with trip details, including current pick-ups, drop-offs, customer assistance needs, scheduled times, and other agency-approved trip information.
179	Core	Vehicle Application	General	The vehicle application shall provide navigation routing to operators upon request.
180	Core	Vehicle Application	General	The vehicle application shall provide the customer's real-time location to the operator for pick-up events, when customer location data is available, only when the vehicle is near the pick-up location and within the applicable pick-up window.
181	Core	Vehicle Application	General	The vehicle application shall allow the operator to mark completion of pick-up events.
182	Core	Vehicle Application	General	The vehicle application shall allow the operator to mark completion of drop-off events.
183	Core	Vehicle Application	General	The system shall allow Participating Agencies to configure geofencing rules for driver-marked pick-up completion.
184	Core	Vehicle Application	General	The system shall allow Participating Agencies to configure geofencing rules for driver-marked drop-off completion.
185	Core	Vehicle Application	General	Geofencing rules shall support validation that customers are picked up and dropped off at the scheduled trip locations or other agency-approved locations.
186	Core	Vehicle Application	General	The vehicle application shall allow the operator to designate a customer as a no-show when the vehicle has arrived at the pick-up location and the customer does not appear within the configurable time window permitted by the applicable Participating Agency.
187	Core	Vehicle Application	General	The vehicle application interface shall be designed to support safe vehicle operations.
188	Core	Vehicle Application	General	The vehicle application shall minimize and discourage operator interaction with the on-board device while the vehicle is in motion.
189	Core	Vehicle Application	Login and Access	The vehicle application shall require drivers to log into their assigned driver profile before viewing assigned manifests.
190	Core	Vehicle Application	Login and Access	The Contractor shall describe the login methods supported by the vehicle application.
191	Core	Vehicle Application	Login and Access	The Contractor shall describe the login validation methods supported by the vehicle application.
192	Core	Vehicle Application	Login and Access	Drivers shall be approved by their employing Participating Agency before receiving access to the vehicle application.
193	Core	Vehicle Application	Login and Access	Participating Agencies shall be able to manage driver account setup for the vehicle application, subject to approved permissions.
194	Core	Vehicle Application	Data Connectivity and Support for Offline Mode	The vehicle application shall support offline or degraded-network operation for essential driver functions, including viewing assigned manifest information and recording pick-up/drop-off events, where feasible.
195	Core	Vehicle Application	Data Connectivity and Support for Offline Mode	The vehicle application shall support offline mode during intermittent loss of connectivity.
196	Core	Vehicle Application	Data Connectivity and Support for Offline Mode	Offline mode shall use secure built-in device storage to retain operational data captured while connectivity is unavailable.
197	Core	Vehicle Application	Data Connectivity and Support for Offline Mode	Offline mode shall support continued capture of location updates when device location services are available.
198	Core	Vehicle Application	Data Connectivity and Support for Offline Mode	Offline mode shall support continued capture of trip status updates entered by the operator.
199	Core	Vehicle Application	Data Connectivity and Support for Offline Mode	The vehicle application shall automatically resynchronize stored offline data with the central Mobility Platform when connectivity is restored.
200	Core	Vehicle Application	Data Connectivity and Support for Offline Mode	The vehicle application shall prevent loss of operational data captured during offline mode.
201	Core	Vehicle Application	Data Connectivity and Support for Offline Mode	The vehicle application shall indicate to the operator when the device is offline, reconnecting, or synchronized.
202	Core	Vehicle Application	Operator communications	The vehicle application shall support two-way communication between operators and authorized dispatchers through agency-configured canned messages.
203	Core	Vehicle Application	Operator communications	The system shall allow each Participating Agency to configure, approve, activate, deactivate, and modify canned-message templates.
204	Core	Vehicle Application	Operator communications	The vehicle application shall display the delivery status of each message sent by an operator.
205	Core	Vehicle Application	Operator communications	The dispatcher application shall display whether an operator has received or acknowledged a message when acknowledgment is required.
206	Core	Vehicle Application	Operator communications	The vehicle application shall queue outbound text messages, trip events, and status updates when data connectivity is unavailable.
207	Core	Vehicle Application	Operator communications	The vehicle application shall transmit queued text messages, trip events, and status updates when data connectivity is restored.
208	Core	Vehicle Application	Operator communications	The system shall preserve the operator-entered event time and system synchronization time for each offline-captured trip activity.
209	Core	Vehicle Application	Operator communications	The system shall preserve the original creation time and system transmission time for each queued message.
210	Core	Vehicle Application	Operator communications	The vehicle application shall support two-way voice communication between operators and authorized dispatchers through VoIP calling.
211	Core	Vehicle Application	Operator communications	The vehicle application shall allow an operator to initiate a VoIP call to an authorized dispatcher.
212	Core	Vehicle Application	Operator communications	The dispatcher application shall allow an authorized dispatcher to initiate a VoIP call to an operator.
213	Core	Vehicle Application	Operator communications	The vehicle application shall provide audible and visual notification of an incoming dispatcher call.
214	Core	Vehicle Application	Operator communications	The vehicle application shall allow an operator to answer, decline, and end a VoIP call.
215	Core	Vehicle Application	Operator communications	The dispatcher application shall display the connection status of each operator–dispatcher VoIP call.
216	Core	Vehicle Application	Operator communications	Voice-call controls available while the vehicle is moving shall support hands-free or single-action operation.
217	Core	Vehicle Application	Operator communications	The system shall notify the operator and dispatcher when a VoIP call cannot be established or is disconnected unexpectedly.
218	Core	Vehicle Application	Operator communications	The system shall record the initiating user, receiving user, vehicle, date, time, call direction, connection status, and call duration for each operator–dispatcher VoIP call attempt.
219	Core	Vehicle Application	Operator communications	The vehicle application shall prohibit operators from composing or sending free-form text messages while the vehicle is moving.
220	Core	Vehicle Application	Operator communications	The vehicle application shall allow operators to compose and send free-form text messages only when the vehicle is not moving and the functionality has been enabled by the Participating Agency.
221	Core	Vehicle Application	Operator communications	The vehicle application shall allow operators to send agency-configured canned messages, including pickup message templates to riders, while the vehicle is moving.
222	Core	Vehicle Application	Operator communications	The vehicle application shall support operator-to-rider text messaging for pickup-related communications.
223	Core	Vehicle Application	Operator communications	The vehicle application shall support VoIP calling between an operator and an assigned rider for pickup-related communications.
224	Core	Vehicle Application	Operator communications	The vehicle application shall allow an operator to initiate a VoIP call to an assigned rider during the applicable pickup communication period.
225	Core	Vehicle Application	Operator communications	The rider application shall allow an assigned rider to initiate a VoIP call to the operator during the applicable pickup communication period when enabled by the Participating Agency.
226	Core	Vehicle Application	Operator communications	Operator-to-rider communication shall be available only within the pickup time window or location distance configured by the Participating Agency.
227	Core	Vehicle Application	Operator communications	The system shall terminate the operator’s access to rider communication controls when the configured pickup communication period ends.
228	Core	Vehicle Application	Operator communications	The vehicle application shall prohibit operators from composing or sending free-form rider messages while the vehicle is moving.
229	Core	Vehicle Application	Operator communications	The vehicle application shall allow operators to compose and send free-form rider messages only when the vehicle is not moving and the functionality has been enabled by the Participating Agency.
230	Core	Vehicle Application	Operator communications	The system shall not disclose an operator's, dispatcher's, or rider's personal telephone number when establishing operator-to-rider or operator-to-dispatcher text or VoIP communication.
231	Core	Vehicle Application	Operator communications	The system shall associate each operator-to-rider communication with the applicable trip.
232	Core	Vehicle Application	Operator communications	The system shall record the sender, recipient, trip, communication type, date, time, delivery status, and connection status for each operator-to-rider communication.
233	Core	Vehicle Application	Operator communications	The system shall restrict operators to communicating only with riders assigned to the operator’s active or imminent trips.

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated Oct 13, 2026.